Function Call 不稳定，到底卡在哪

1️⃣ 考察意图

面试官想看你能否从“玄学”中拆出“工程学”——Function Call 不稳定不是模型抽风，而是系统各环节的确定性漏洞。考察类型是 root cause 诊断 + 系统设计。刁钻点在于：候选人常只怪模型（“它不听话”），而忽略 schema 设计、采样策略、上下文污染等可控因素。答好了能展示你具备 端到端调试能力：从 prompt 到后处理，能定位并量化每个环节的失败率，给出可落地的防御方案。

2️⃣ 标准答

Function Call 不稳定，根因可归为四类：Schema 设计缺陷、Prompt 上下文污染、采样策略失控、运行时防御缺失。下面逐类拆解，附带工程取舍和实战坑。

1. Schema 设计缺陷

问题：函数名/参数名歧义、类型约束不严。例如，两个函数 get_user 和 fetch_user_profile 语义重叠，模型可能选错；参数 date 未指定格式（YYYY-MM-DD vs timestamp），模型输出 "2024-01-01" 但后端期望 1704067200。
解法：遵循 OpenAPI 3.0 规范，参数用 enum 限制可选值，description 写清边界条件（如 "date: ISO 8601 format, e.g., 2024-01-01"）。函数名用动词+名词（create_order 而非 order），避免同义词。
取舍：schema 越详细，token 消耗越大（每个函数描述多 50-100 tokens），但能降低 30-50% 的误调用率【通用经验】。对于 10+ 工具的场景，需权衡描述长度与模型上下文窗口。

2. Prompt 上下文污染

问题：工具列表过长或顺序不当。例如，一次给模型 20 个函数，模型可能只关注前 5 个（primacy effect）或后 3 个（recency effect），中间的函数被忽略。另外，历史对话中残留的无关工具描述会干扰当前调用。
解法：动态裁剪工具列表——基于用户意图用 分类器（如轻量 BERT 模型）预选 top-5 相关函数。同时，在 system prompt 中明确排序规则：高频函数放前，低频放后。对历史消息做 滑动窗口截断，只保留最近 2 轮对话。
坑：动态裁剪可能漏掉罕见但正确的函数。例如，用户说“查一下 2023 年财报”，但分类器只选了 get_stock_price 而漏了 get_financial_report。解法：设置 fallback 机制——若模型返回 no_tool 但用户意图明显需调用，则触发全量重试。

3. 采样策略失控

问题：温度（temperature）过高（>0.7）导致模型随机输出非法 JSON 或错误参数名。例如，温度 1.0 时，模型可能把 "city": "Beijing" 写成 "city": "beijing"（大小写不符 schema）。
解法：对 Function Call 场景，强制 temperature=0（或 top_p=1, top_k=1），使输出确定性最大化。若需多样性（如多轮对话），只在非工具调用部分用高温度。
取舍：temperature=0 会降低模型对模糊意图的泛化能力（如用户说“帮我订票”但未指定城市，模型可能拒绝调用）。此时需配合 prompt 引导：在 system prompt 中写“若参数不全，用默认值或询问用户”。

4. 运行时防御缺失

问题：模型输出 JSON 后，无校验直接传给后端。常见失败：参数类型错误（"count": "3" 而非 3）、缺少必填字段、函数名拼写错误（get_uer 而非 get_user）。
解法：实现 三层防御：

JSON 解析校验：用 pydantic 或 jsonschema 验证输出是否符合 schema，失败则触发重试（最多 3 次，每次加 prompt 提示“请检查 JSON 格式”）。
参数类型转换：自动将字符串转数字（如 "3" -> 3），但记录日志以便后续优化。
运行时异常捕获：后端调用失败时（如 API 返回 400），返回错误信息给模型，让模型修正后重试。

坑：重试次数过多会放大延迟。例如，3 次重试每次 2 秒，总耗时 6 秒，用户等不了。解法：设置 超时熔断——若 3 次重试仍失败，返回“无法完成，请稍后重试”并记录 badcase。

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

“这个问题我从四个层面拆解：第一，Schema 设计——函数名和参数歧义导致模型选错或格式错；第二，Prompt 上下文——工具列表过长或顺序不当造成注意力偏差；第三，采样策略——温度过高引入随机性；第四，运行时防御——缺少校验和重试机制。总结一句：Function Call 不稳定不是模型问题，而是系统各环节的确定性漏洞，需要从 schema 规范、动态裁剪、温度控制和防御性编程四个方向逐一封堵。”

4️⃣ 高频追问 & 应对

追问 1：你说温度设为 0，但有些场景需要模型生成多个候选函数调用（如推荐系统），怎么处理？

温度=0 只适用于确定性调用（如查询数据库）。对于需要多样性的场景（如推荐多个商品），可以分两步：第一步用高温度（0.8）生成多个候选函数名（如 recommend_product 的多个参数组合），第二步对每个候选用温度=0 生成精确 JSON。或者用 nucleus sampling（top_p=0.9） 替代温度控制，保留一定随机性但避免极端输出。注意：此时需在后端做去重和排序，避免重复调用。

追问 2：动态裁剪工具列表时，分类器误判怎么办？比如用户说“查天气”但分类器选了“查日历”。

分类器误判是常见问题。解法：第一，分类器训练时加入 负样本（如“查天气”但标签为“查日历”的样本），提升区分度。第二，设置 置信度阈值——若分类器 top-1 置信度低于 0.7，则回退到全量工具列表。第三，在 prompt 中加一句“若提供的工具不匹配，请返回 no_tool”，让模型自己兜底。实际项目中，误判率可控制在 5% 以内【通用经验】。

追问 3：重试机制中，模型可能重复同样的错误（如一直输出非法 JSON），怎么避免？

这是典型问题。解法：在重试 prompt 中注入 错误上下文——例如，“上次输出 JSON 格式错误：缺少字段 city。请确保输出包含所有必填字段。”同时，限制重试次数（最多 3 次），并在每次重试后增加 退避延迟（如 0.5s, 1s, 2s），避免模型陷入死循环。若仍失败，记录 badcase 到日志系统，用于后续优化 schema 或 prompt。

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

❌ “Function Call 不稳定是因为模型能力不够，换更强的模型就行。” → ✅ “模型能力是因素之一，但更常见的是 schema 设计、prompt 上下文、采样策略和防御机制的问题。换模型可能掩盖根因，比如 GPT-4 比 GPT-3.5 更稳定，但若 schema 有歧义，照样出错。”
❌ “温度设为 0 就万无一失。” → ✅ “温度=0 能减少随机性，但无法解决 schema 歧义或上下文污染。例如，若两个函数名相似，温度=0 仍可能选错。需要结合动态裁剪和防御校验。”
❌ “重试机制可以解决所有问题。” → ✅ “重试能修复格式错误，但无法修复逻辑错误（如选错函数）。且重试次数过多会放大延迟，需设置熔断和 badcase 记录。”

6️⃣ 简历呼应

如果你有 RAG 项目：从“工具列表动态裁剪”切入，类比 RAG 中的检索器——用分类器预选工具类似用 embedding 预选文档，都需处理 top-k 截断的精度问题。
如果你只做过传统 NLP：用“序列标注”类比——Function Call 输出 JSON 类似序列标注中的标签约束（如 BIO 格式），需用 schema 做后处理校验，类似 CRF 层。
如果你是校招无项目：聚焦“采样策略”论文复现——读《The Curse of Recursion》和《Temperature Scaling in LLMs》，用一个小 demo 展示 temperature 对 JSON 输出格式的影响，并给出优化建议。
《OpenAI Function Calling Guide: Best Practices for Reliable Tool Use》
《The Curse of Recursion: Training on Generated Data Makes Models Forget》
《Pydantic: Data Validation and Settings Management using Python Type Hints》
《Hugging Face Blog: Dynamic Tool Selection for LLM Agents》
《Anthropic: Building Effective Agents - Tool Use and Error Handling》

—— 本场面试完 ——