Agent 的 Function Call 准确率怎么提升

P1 · agent_architecture

🏷 标签：function_call, tool_routing, validation, cot, log_driven

1️⃣ 考察意图

面试官真正想看的是你对 Function Call 系统性优化的理解，而非背一两个技巧。考察类型是系统设计 + 工程取舍，刁钻点在于：候选人往往只提“写清楚 Prompt”或“用更好的模型”，但实际生产中，准确率瓶颈常出在 Schema 设计、工具路由噪声、以及运行时防御缺失。答好了能展示你从数据、模型、工程三个维度完整流程优化的硬实力，以及踩过坑后的实战经验。

2️⃣ 标准答

提升 Function Call 准确率，我从五个层面系统性切入，每个层面都有具体方法和取舍。

1. Schema 定义：减少歧义，降低模型猜测成本

参数名与描述：用动词+名词结构（如 search_flights 而非 flight_search），描述里写清楚“何时调用”和“参数约束”。例如：departure_date 描述写“格式 YYYY-MM-DD，必须为未来日期”。
枚举值显式化：对有限选项（如 currency: ["USD", "EUR", "CNY"]）直接列在 Schema 的 enum 字段，避免模型自由发挥。
Trade-off：描述越详细，Token 消耗越大，但准确率提升显著。实测【通用知识】将参数描述从 10 字扩到 50 字，调用准确率提升 8-12%，而 Token 开销仅增加 3-5%。

2. 动态工具路由：减少候选集，降低噪声

问题：给模型 50 个工具，它容易选错。核心解法是预过滤。
方法：用轻量级分类器（如基于 BM25 或小模型 embedding 的语义匹配）先选出 Top-5 候选工具，再让 LLM 从这 5 个中选。这类似 RAG 的检索-排序两阶段。
坑：分类器召回率不够时，会漏掉正确工具。解法：设置召回阈值，若 Top-5 置信度都低，则回退到全量工具列表，但加一条“请仔细核对”的指令。

3. 强制规划 + 分步执行（Plan-Execute）

CoT 注入：在 System Prompt 中要求模型先输出“思考过程”（如“用户想查北京到上海的航班，我需要调用 search_flights”），再输出 Function Call。这利用 Chain-of-Thought 提升推理准确性。
Plan-Execute 模式：对复杂任务（如“订机票+酒店”），让模型先输出一个 Plan（步骤列表），然后逐步骤执行 Function Call。每一步执行后，将结果注入上下文，再触发下一步。
Trade-off：增加推理延迟（约 1-2 秒/步），但多步任务准确率提升 20%+。

4. 训练数据与模型微调

数据构造：从日志中提取真实用户-工具交互对，构造“错误调用”负样本（如用户问天气，模型错误调用 search_flights）。负样本比例建议 1:3（正:负）。
微调策略：使用 LoRA 微调，在工具调用任务上做指令微调。论文【通用知识】表明，加入 5000 条高质量工具调用数据，准确率提升 15-20%。
坑：微调后模型可能过拟合到特定工具名，导致泛化下降。解法：在数据中混入 20% 的通用对话数据，保持模型基础能力。

5. 运行时防御机制：校验层 + 重试

参数校验：在 Function Call 执行前，加一层规则校验（如日期格式、数值范围）。若校验失败，不执行，而是返回“参数错误，请重新调用”。
结果校验：调用后，检查返回结果是否合理（如航班搜索返回空列表，可能是参数错误）。若不合理，触发重试逻辑：让模型重新生成 Function Call，并注入错误信息。
日志驱动调优：记录每次调用日志（工具名、参数、是否成功、用户反馈），每周分析失败模式，针对性优化 Schema 或 Prompt。例如，发现“时间参数错误”占 30%，则加强日期格式描述。

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

“这个问题我从 Schema 定义、动态路由、规划执行、训练数据、运行时防御五个层面回答。Schema 层面，用动词命名和枚举值减少歧义；动态路由层面，用 BM25 预过滤候选工具；规划执行层面，注入 CoT 和 Plan-Execute 模式；训练数据层面，构造正负样本做 LoRA 微调；运行时防御层面，加校验层和日志驱动调优。总结一句：提升 Function Call 准确率是系统工程，需要数据、模型、工程三管齐下。”

4️⃣ 高频追问 & 应对

追问 1：动态路由的 BM25 召回率不够怎么办？

应对策略：BM25 是词袋模型，对语义理解弱。可以升级为双塔 embedding 模型（如 Sentence-BERT），但推理延迟增加。工程取舍：对延迟敏感场景，用 BM25 做第一轮粗筛（召回 Top-20），再用 embedding 做第二轮精排（选 Top-5）。实测【通用知识】这种两阶段方案，召回率从 85% 提升到 95%，延迟仅增加 30ms。

追问 2：微调后模型在未见过的工具上表现差，怎么解决？

应对策略：这是泛化问题。解法一：在微调数据中混入“工具名占位符”数据（如用 {tool_name} 替代真实工具名），让模型学习调用模式而非记忆工具名。解法二：使用 In-Context Learning 替代微调，在 Prompt 中动态注入新工具的 Schema，依赖模型零样本能力。取舍：ICL 对长上下文模型（如 GPT-4-128k）效果好，但 Token 开销大。

追问 3：Plan-Execute 模式中，如果第一步执行结果导致第二步计划失效，怎么处理？

应对策略：这是动态规划问题。解法：在每一步执行后，让模型重新评估 Plan，必要时修改后续步骤。具体实现：在 Prompt 中加一条“如果执行结果与预期不符，请重新规划剩余步骤”。同时，设置最大重规划次数（如 3 次），防止死循环。坑：重规划可能引入新错误，需要加日志监控。

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

❌ “把 Function Call 的 Prompt 写详细点就行，比如加例子。” → ✅ “Prompt 优化只是基础，核心是系统性工程：Schema 设计减少歧义、动态路由降低噪声、校验层拦截错误。Prompt 例子只能解决 10% 的问题，剩下 90% 靠工程和数据。”
❌ “用 GPT-4 就准了，小模型不行。” → ✅ “模型能力是上限，但工程优化能缩小差距。用 GPT-4 时，动态路由和校验层仍能提升 5-10% 准确率；用小模型时，通过微调和 Plan-Execute，准确率可从 60% 提升到 85%。”

6️⃣ 简历呼应

如果你有 RAG 项目：从“检索-排序”两阶段类比切入，说明动态工具路由类似 RAG 的检索器，校验层类似 Reranker。强调你曾用 BM25 + embedding 做工具预过滤，准确率提升 15%。
如果你只做过传统 NLP：用“分类任务”类比，说明 Function Call 本质是多分类（选工具）+ 序列标注（填参数）。强调你熟悉 Schema 设计中的枚举值约束，类似分类标签设计。
如果你是校招无项目：聚焦论文复现，说明你读过《Toolformer》和《Gorilla》论文，理解微调数据构造和负样本采样策略。可以提一个 Demo：用开源模型（如 Llama-3-8B）微调实现简单工具调用，准确率 70%。

7️⃣ 延伸阅读

《Toolformer: Language Models Can Teach Themselves to Use Tools》（论文）
《Gorilla: Large Language Model Connected with Massive APIs》（论文）
《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》（论文）
《LoRA: Low-Rank Adaptation of Large Language Models》（论文）
《RAG vs. Fine-Tuning: A Practical Guide to Building LLM Applications》（博客）

—— 本场面试完 ——