Function Calling 不稳定，面试里到底该怎么回答

1️⃣ 考察意图

面试官想看的不是“Function Calling 不稳定”的背书式定义，而是你能否从系统设计和工程落地角度拆解问题。考察类型是工程取舍 + Debug。刁钻点在于：多数人只抱怨模型幻觉，但真正考验的是你能否识别出Schema 设计缺陷、Prompt 污染、采样温度过高、以及防御机制缺失这四个根因。答好了，能展示你对 LLM 应用层稳定性的硬核把控力——这是大厂做 Agent 产品的核心能力。

2️⃣ 标准答

Function Calling 不稳定，本质是模型在不确定的上下文（用户意图模糊、历史对话噪声、Schema 歧义）里做确定决策（选函数、填参数）。我从四个维度拆解，每个维度给一个具体坑和解法。

1. Schema 设计：减少歧义，增加约束

坑：函数名和参数描述太模糊。比如一个 get_weather 函数，参数 location 只写“城市名”，模型可能把“北京”填成“Beijing”或“beijing”，导致调用失败。
解法：用 JSON Schema 的 enum 和 pattern 约束参数格式。例如 location 用 enum: ["北京", "上海"] 或 pattern: "^[\u4e00-\u9fa5]+$"。函数名用动词+名词（如 query_weather_by_city），避免歧义。
Trade-off：Schema 越严格，模型越容易拒绝调用（因为参数不匹配），需要平衡召回率和精确率。实践中，对高频函数放宽约束，对关键函数收紧。

2. Prompt 设计：控制上下文噪声

坑：系统提示词里塞了太多无关指令，比如“你是一个友好的助手”，模型可能优先回复闲聊而不是调用函数。
解法：把 Function Calling 指令放在系统提示词最前面，用 ## 可用工具 标题明确分隔。参考 OpenAI 官方最佳实践：用 "strict": true 强制模型只输出函数调用（如果业务允许）。对多轮对话，用 滑动窗口 截断历史，只保留最近 3-5 轮，避免旧意图干扰。
实际落地坑：用户说“帮我查下天气，然后推荐个餐厅”，模型可能只调天气函数，忽略第二个意图。解法是拆分多意图：在 Prompt 里加 如果用户有多个请求，请依次调用函数，并设置 max_turns=2 的循环调用。

3. 采样参数：降低随机性

坑：temperature=0.7 时，模型可能随机选错函数（比如把查天气误判为查机票）。
解法：对 Function Calling 场景，强制 temperature=0，甚至用 top_p=0.1 进一步压缩采样空间。如果业务需要多样性（如创意生成），用 两阶段策略：先低温度选函数，再高温度生成参数。
Trade-off：temperature=0 会降低模型对模糊意图的容错，比如用户说“今天冷吗”，模型可能不调用天气函数。需要配合 Fallback 机制：如果模型没调用函数，用规则引擎（如关键词匹配）兜底。

4. 防御机制：校验与重试

坑：模型输出了格式正确的函数调用，但参数值不合理（如查询未来 10 天的天气，但 API 只支持 7 天）。
解法：后校验：用 Pydantic 或 JSON Schema validator 校验参数范围，失败时触发重试。重试策略：把错误信息注入 Prompt，让模型重新生成。例如：“参数 days 超出范围（1-7），请重新调用。”
实际落地坑：模型可能陷入重试循环（一直报错）。解法是设置最大重试次数（3 次），超过后返回默认值或报错给用户。

总结：稳定性不是靠模型，而是靠系统设计。Schema 约束、Prompt 隔离、低温度采样、后校验重试，四层防御缺一不可。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从 Schema 设计、Prompt 控制、采样参数、防御机制四个层面回答。Schema 层面用 enum 和 pattern 减少歧义；Prompt 层面把指令前置并用滑动窗口降噪；采样层面强制 temperature=0；防御层面用 Pydantic 校验并设置重试上限。总结一句：Function Calling 不稳定是系统问题，不是模型问题，需要四层防御来兜底。”

4️⃣ 高频追问 & 应对

追问 1：如果用户意图非常模糊，比如只说“帮我查点东西”，你怎么让模型正确调用函数？

应对策略：这是典型的意图识别失败场景。解法是多级 Fallback：第一级，让模型用 temperature=0 尝试调用最可能的函数（如 search_general）。第二级，如果模型没调用，用规则引擎（如关键词匹配“查”触发 search_general）。第三级，如果还不行，让模型反问用户：“您想查天气、新闻还是其他？” 这里的关键 trade-off 是：过度反问影响体验，但能避免误调用。实践中，对高频意图（天气、新闻）用规则兜底，对低频意图（如查股票）才反问。

追问 2：你提到用 temperature=0，但有些场景需要多样性（比如推荐系统），怎么平衡？

应对策略：用两阶段策略。第一阶段：temperature=0 选函数和关键参数（如 recommend_restaurant 的 cuisine 字段）。第二阶段：对非关键参数（如 style 字段）用 temperature=0.7 生成多样性。或者用 Chain of Thought：让模型先输出思考过程（如“用户可能想吃辣的”），再基于思考结果调用函数。这样既保证函数选择稳定，又保留参数多样性。实际落地中，我在一个推荐项目里把误调用率从 15% 降到 3%，同时用户满意度没下降。

追问 3：如果模型输出了不存在的函数名（幻觉），你怎么处理？

应对策略：这是Schema 污染问题。解法是白名单校验：在代码层维护一个函数名列表，模型输出后先校验是否在白名单内。如果不在，直接拒绝并触发重试。同时，在 Prompt 里加一句：“你只能使用以下函数，不要创造新函数。” 另外，检查 Schema 是否包含同义词（如 get_weather 和 fetch_weather），统一命名。如果幻觉频繁，考虑用 JSON mode（如 OpenAI 的 response_format: { "type": "json_object" }）强制输出结构，减少自由生成。

5️⃣ 避坑 · 常见错误答法

❌ 答：“Function Calling 不稳定是因为模型幻觉，没办法，只能等模型升级。” → ✅ 正确切入：“模型幻觉只是表象，根因在系统设计。从 Schema 约束、Prompt 隔离、低温度采样、后校验重试四个维度可以大幅降低不稳定率，我曾在项目中把误调用率从 20% 降到 5%。”
❌ 答：“把 temperature 设成 0 就解决了。” → ✅ 正确切入：“temperature=0 是基础，但还需要配合 Schema 校验和重试机制。比如参数超出范围时，temperature=0 也救不了，必须用后校验兜底。”
❌ 答：“用更强大的模型（如 GPT-4）就好了。” → ✅ 正确切入：“模型能力是上限，但稳定性靠系统设计。即使 GPT-4，在模糊意图下也可能误调用。关键是四层防御，而不是依赖模型本身。”

6️⃣ 简历呼应

如果你有 RAG 项目：从“检索结果不稳定”类比到“函数调用不稳定”，强调 Schema 设计（类似索引结构）和重试机制（类似查询改写）。举例：在 RAG 中，用 enum 约束检索字段，类似 Function Calling 的参数校验。
如果你只做过传统 NLP：用“意图分类”类比“函数选择”，用“槽位填充”类比“参数提取”。强调传统方法（规则+分类器）和 LLM 方法的互补：规则做兜底，LLM 做灵活调用。
如果你是校招无项目：聚焦论文复现，比如复现 Toolformer 或 Gorilla 的 Schema 设计思路，并自己写一个 demo：用 temperature=0 + Pydantic 校验实现一个简单的天气查询 Agent，量化误调用率。
OpenAI Function Calling 官方文档与最佳实践（2023）
Toolformer: Language Models Can Teach Themselves to Use Tools（2023）
Gorilla: Large Language Model Connected with Massive APIs（2023）
Pydantic 官方文档：数据校验与 JSON Schema 生成
《LLM 应用开发实战：Function Calling 稳定性优化》博客（常见于技术社区）

—— 本场面试完 ——