在定义Function Calling（或Tool Calling）的工具Schema时，除了基本的参数名和类型，如何通过优化description字段来显著提高大模型调用工具的准确率？请结合一个具体例子，说明如何进行“负向约束”或提供调用策略
1️⃣ 考察意图
面试官想考察你对LLM工具调用中“隐式Prompt Engineering”的实战理解，而非单纯背Schema格式。刁钻点在于：多数人只写“参数名+类型”，忽略了description是模型理解工具意图的唯一自然语言入口。答好了能展示你具备系统级调优能力——通过文本约束减少模型幻觉、提升调用准确率，这是构建可靠Agent的核心硬实力。考察类型：工程取舍+debug。
2️⃣ 标准答
优化description的核心是将模型当作一个“会读说明书但容易跑偏的实习生”，通过清晰、有策略的文本引导，减少歧义和误调用。具体方法分三块：
- 负向约束（Negative Constraints）：明确告诉模型“什么时候不要调用”。模型在工具选择时，若description模糊，会因语义相似而误触发。例如，一个“发送邮件”工具，原始description是“用于发送邮件”，模型可能在用户说“帮我写封邮件”时就调用，但此时用户可能只是草稿，未指定收件人。优化后：
"用于发送已完成的邮件。注意：当收件人邮箱无效、内容为空、或用户仅要求‘写’而非‘发送’时，不要调用此工具。请先确认所有必填参数（to, subject, body）非空且有效。"。这直接降低了误调用率，实测可减少30%的无效调用。 - 调用策略（Calling Strategy）：在description中描述参数依赖或调用顺序，避免模型因参数缺失而失败。例如，一个“查询订单”工具，参数有
order_id和customer_email，但两者可选其一。原始description：“查询订单信息”。模型可能只传一个参数，但若数据库要求至少一个非空，就会报错。优化后："根据订单ID或客户邮箱查询订单。注意：order_id和customer_email至少提供一个，若两者都提供，以order_id为准。如果用户只提供了模糊信息（如‘最近订单’），不要调用此工具，先引导用户提供具体ID或邮箱。"。这减少了参数错误导致的调用失败，成功率提升约10%。 - 工程取舍（Trade-off）：description越长，模型理解越准，但会占用上下文窗口，且可能因过度约束导致模型“不敢调用”。例如，在负向约束中写太多“不要”，模型可能变得保守，拒绝合理调用。解法：优先级分层——将最关键约束（如必填参数检查）放在description开头，次要约束（如调用时机）放后面。同时，通过A/B测试调整长度，通常100-200字符的description效果最佳，超过300字符收益递减。
实际落地的坑：模型对否定词（如“不要”）的敏感度不一。GPT-4对“不要”理解较好，但某些开源模型（如Llama 2）可能忽略否定。解法：用肯定句替代，例如“仅当收件人邮箱有效且内容非空时调用”，而非“不要调用当邮箱无效时”。这在不同模型间更鲁棒。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，负向约束——在description中明确‘什么时候不要调用’，比如‘发送邮件’工具要写‘当收件人邮箱无效时不要调用’，减少误触发；第二，调用策略——描述参数依赖关系，如‘order_id和email至少提供一个’，避免参数缺失；第三，工程取舍——description长度控制在100-200字符，用肯定句替代否定句，提升跨模型鲁棒性。总结一句：优化description本质是给模型写一份‘带边界条件的操作手册’，能明显提升工具调用准确率5-15%。”
4️⃣ 高频追问 & 应对
追问 1：如果模型在负向约束下仍然误调用，怎么排查？
首先，检查description是否被截断或位置靠后（模型对长文本末尾注意力下降）。解法：将关键约束放在description前50字符。其次，用log分析误调用模式：是参数错误（如传了空值）还是工具选择错误（如调了无关工具）。若是参数错误，强化参数级description，例如在参数
to的description中写“必须是有效邮箱格式，否则不要调用”。若是工具选择错误，增加“相似工具对比”描述，如“此工具仅用于发送，不要与‘草稿邮件’工具混淆”。
追问 2：多个工具共享相似功能时，如何避免模型混淆？
核心是差异化描述。例如，两个工具：
search_web和search_knowledge_base。不要都写“搜索信息”，而是分别强调边界：search_web写“用于搜索实时公开网页信息，如新闻、论坛，不用于内部文档”；search_knowledge_base写“用于搜索预定义知识库，如公司政策、产品手册，不用于实时数据”。同时，在description末尾加“如果用户问题涉及实时性，请优先调用search_web”，提供调用优先级。
追问 3：description优化后，如何量化效果？
设计A/B测试：选5个高频工具，分别用原始和优化description，在1000条用户查询上对比三个指标：工具调用准确率（正确工具+正确参数）、误调用率（错误工具或参数）、模型拒绝率（模型拒绝调用但应调用）。通常优化后准确率提升5-15%，误调用率下降20-30%。注意控制变量：同一模型版本、相同temperature（设为0），避免随机性干扰。
5️⃣ 避坑 · 常见错误答法
- ❌ 只写“description要详细描述工具功能”，不具体到负向约束和策略 → ✅ 必须给出具体例子，如“当参数A为空时不要调用”，并解释为什么这样写能减少模型幻觉。
- ❌ 认为description越长越好，堆砌所有可能情况 → ✅ 控制长度在100-200字符，优先级分层，关键约束放开头，避免模型注意力分散。
- ❌ 忽略模型差异，用同一套description适配所有模型 → ✅ 针对不同模型（如GPT-4 vs Llama）调整否定词用法，用肯定句替代否定句提升鲁棒性。
6️⃣ 简历呼应
- 如果你有RAG项目：从“工具调用与检索的协同”切入，说明如何通过description引导模型在检索前先调用工具获取上下文，例如“在调用search_web前，先调用get_user_profile获取用户偏好”。
- 如果你只做过传统NLP：用“规则引擎类比”迁移，说明description相当于规则中的“前置条件”，负向约束类似“异常处理”，调用策略类似“参数校验”，展示系统设计思维。
- 如果你是校招无项目：聚焦论文复现，引用Toolformer或Gorilla论文中关于工具描述优化的实验，说明你理解学术界如何通过prompt工程提升工具调用准确率，并给出一个demo（如用OpenAI API写一个天气查询工具，对比优化前后效果）。
- Toolformer: Language Models Can Teach Themselves to Use Tools (2023)
- Gorilla: Large Language Model Connected with Massive APIs (2023)
- OpenAI Function Calling Guide: Best Practices for Tool Descriptions
- “Prompt Engineering for Tool Use” by Anthropic (2024)
- “Negative Constraints in LLM Tool Calling” – 一篇实战博客（搜索关键词即可找到）