Function Calling 怎么解析用户指令?

30 秒回答

1. 理解Function Calling的两阶段流程（意图识别+参数抽取）
2. 知道模型通过特殊token或JSON模式约束输出
3. 了解schema定义和参数校验机制
4. 能说明与普通生成任务的关键区别（结构化输出约束）

回答与解析

答案要点

• 理解Function Calling的两阶段流程（意图识别+参数抽取）
• 知道模型通过特殊token或JSON模式约束输出
• 了解schema定义和参数校验机制
• 能说明与普通生成任务的关键区别（结构化输出约束）
• 了解实际部署中的错误处理策略

Function Calling的核心是让模型学会"按格式说话"，把自然语言翻译成可执行的结构化指令。技术原理分三层：

1. 训练阶段：注入工具使用能力

• 构造大量<用户指令, 工具描述, 正确调用>的三元组数据
• 工具用JSON Schema描述（函数名、参数类型、必填字段）
• 模型学习输出固定格式的函数调用表示，通常是：

  {"name": "get_weather", "arguments": {"city": "北京", "date": "明天"}}
  

2. 推理阶段：约束解码输出

• Schema约束：通过logits processor或grammar-based采样，强制输出合法JSON
• 特殊token引导：部分实现用<function_call>等标记区分普通对话和工具调用
• 两阶段解析：先判断是否需要调用工具（分类），再抽取具体参数（生成/抽取）

3. 执行与反馈循环

• 系统解析模型输出 → 校验参数 → 执行真实函数 → 结果回传给模型
• 模型基于执行结果继续生成回复或进行多轮工具调用

与普通生成的关键区别：不是自由文本生成，而是受约束的结构化预测，本质上把"选哪个工具、填什么参数"建模为条件概率最大化问题。

口语版讲法(约4分钟)

• 一句话定位：本质是结构化输出约束
• 训练阶段：用Schema数据教模型格式
• 推理阶段：约束解码与两阶段流程
• 边界划分：与RAG、Agent的配合
• 落地风险：参数校验与多轮失败

好的，这道题我觉得核心不是在讲模型怎么理解语言，而是怎么让模型学会“按格式说话”，把自然语言翻译成可执行的结构化指令。说白了，这是一个受约束的结构化预测问题，不是自由文本生成。

具体说一下技术原理。首先在训练阶段，我们需要注入工具使用能力。做法是构造大量三元组数据：用户指令、工具描述、还有正确的调用。工具描述用 JSON Schema 来写，包括函数名、参数类型、必填字段这些。模型通过 SFT 学到输出固定格式，比如 {"name": "get weather", "arguments": {"city": "北京", "date": "明天"}}。你可以理解为，模型学会了“看菜谱做菜”，菜谱就是 Schema，做出来的菜必须摆盘整齐。

到了推理阶段，关键是怎么约束解码。模型不能自由发挥，得强制输出合法 JSON。这通常用两种方式：一是通过 logits processor 或 grammar-based 采样，把非法 token 的概率直接置零；二是用特殊 token 引导，比如 <function call 来区分普通对话和工具调用。实际落地时，一般走两阶段流程：先判断是否需要调用工具，这可以看成一个分类任务；再抽取具体参数，这更像生成任务。

这里有个边界划分的问题。很多人会把 Function Calling 和 RAG 或者 Agent 搞混。RAG 解决的是知识缺失，比如客服查政策文档；Agent 解决的是多步推理和工具编排，比如出差订酒店机票需要调多个 API。而 Function Calling 解决的是“一句话触发一个精确动作”，比如用户说“帮我查明天北京天气”，直接映射到天气 API。真正落地时，它们经常混着用：先用 RAG 检索知识，再用 Function Calling 调用业务系统，最后用 Agent 串联多步。

举个例子，在电商客服场景里，用户说“我买了个手机，还没发货，帮我取消订单”。系统先做意图分类，判断需要调用“取消订单”函数，然后抽取出订单号。这里有个坑：用户可能只说“那个手机订单”，订单号需要从上下文或知识库捞。所以上线时我会特别关注参数抽取的准确率，尤其是枚举类型和时间日期，很容易出错。常见失败场景是参数缺失或类型不匹配，比如用户说“明天”但系统需要 yyyy-mm-dd 格式，这时候需要做归一化。

还有一个容易被忽视的点：多轮调用中的状态管理。比如用户说“帮我查北京天气，再和上海比一下”，这实际上涉及两次调用，第二次依赖第一次的结果。模型需要记住前一轮输出，并且决定是继续调用还是返回最终答案。这部分如果处理不好，容易陷入循环或者给出错误结论。

所以我会把 Function Calling 看成结构化输出的工程化落地，前提是 Schema 定义要足够清晰，参数校验要严格，否则召回率再高也没用。我更倾向于在推理层用 grammar-based 约束保证格式，在业务层做参数校验和兜底，这样更稳。

关键一句:多轮调用中的状态管理容易被忽略，比如依赖前序结果的链式调用

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你正在做一个智能客服系统，用户说‘帮我查一下上周五的订单，如果还没发货就催一下’。你打算怎么把这个指令转成具体的函数调用？背后要处理哪些关键步骤？

2. 问法 2 · 层层追问

   大模型怎么从自然语言里知道该调用什么函数？……那它怎么把用户说的‘上周五’填到参数里？……如果用户没说日期或是从上下文推断的，你又是怎么处理的？

3. 问法 3 · 直球架构

   请你解释一下function calling的技术原理，包括模型如何识别意图、如何抽取参数、以及输出时如何保证结构化的约束。