如何平衡工具描述的详细度与Token消耗
1️⃣ 考察意图
面试官想考察你在工程成本与效果之间的权衡能力，区分你是“只会调 API 的搬运工”还是“有系统优化意识的工程师”。核心刁钻点在于：工具描述不是越详细越好，而是要在“LLM 理解准确度”和“Token 消耗（成本+延迟）”之间找到 Pareto 最优。答好了能展示你对 LLM 调用链路的深度理解，包括 prompt 设计、tokenizer 行为、以及实际落地中的 A/B 测试方法论。
2️⃣ 标准答
这个问题本质是一个多目标优化问题，我从三个层面给出系统解法：描述结构优化、动态策略调整、评估完整流程。
1. 描述结构优化：用“最小必要信息”原则
- 工具名称：必须精确，如
search_web而非search，避免歧义。但不要加冗余修饰，如“高效搜索工具”是废话。 - 参数描述：只写约束，不写解释。例如参数
max_results的描述写“整数，1-50”，不写“这个参数控制返回结果的最大数量，用于限制输出范围”。后者多消耗 20+ Token，但 LLM 理解效果几乎一样。 - 使用场景示例：用 1-2 个极简示例替代长文本描述。例如工具
calculate的描述写“用于数学运算，示例：calculate('2+3')”，比写 50 字参数说明更高效。这是因为 LLM 对示例的泛化能力优于对自然语言规则的遵循。 - 实际落地的坑：早期我写工具描述时，把每个参数都写成“参数名：类型，描述：...”，结果一个工具消耗 800 Token。后来改用 JSON Schema 的
description字段只写关键约束，配合examples字段，Token 消耗降到 300，调用成功率反而从 92% 提升到 96%。原因是冗余描述引入了噪声，干扰了 LLM 的参数提取。
2. 动态策略调整：根据任务复杂度分级
- 简单任务（如单步工具调用）：用精简描述，只保留工具名和参数类型。例如天气查询工具，描述写“
get_weather(city: string)”即可，Token 消耗约 50。 - 复杂任务（如多步推理或工具组合）：用中等详细度，加入 1 个示例和关键约束。例如数据分析工具，描述写“
analyze_data(query: string, format: string)，示例：analyze_data('sales trend', 'json')，参数 format 可选 'json'/'csv'”，Token 消耗约 150。 - 高精度任务（如金融计算或医疗诊断）：用详细描述，加入边界条件和错误处理示例。例如利率计算工具，描述写“
calc_interest(principal: float, rate: float, term: int)，注意 rate 为小数（如 0.05 表示 5%），term 单位为月，示例：calc_interest(10000, 0.05, 12)”，Token 消耗约 300。 - 工程取舍：动态调整需要维护一个任务分类器，这会增加系统复杂度。对于中小规模场景，我建议固定使用中等详细度，因为分类器的误判成本可能高于 Token 节省。只有在大规模调用（日均百万级）时才值得投入。
3. 评估完整流程：用 Pareto 曲线找平衡点
- 设计实验：对同一工具编写 3 种详细度（精简/中等/详细），在 100 个测试用例上跑，记录两个指标：Token 消耗（用 tiktoken 精确统计）和调用成功率（工具参数提取完全正确的比例）。
- 绘制曲线：横轴是 Token 消耗，纵轴是成功率。通常精简版 Token 低但成功率也低（如 80%），详细版 Token 高但成功率饱和（如 97%），中等版在中间（如 95% 成功率，Token 消耗为详细版的 60%）。选择拐点作为生产配置。
- 实际落地的坑：不要只看平均成功率，要分析失败案例。有一次我发现详细版成功率反而低于中等版，原因是冗余描述让 LLM 误以为参数有额外约束（如“注意”一词被理解为强制条件）。所以评估时要做错误类型分析，区分“理解错误”和“参数缺失”。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，描述结构上遵循‘最小必要信息’原则，用 JSON Schema 的 examples 替代长文本描述，可减少 60% Token 消耗；第二，根据任务复杂度动态调整详细度，简单任务用精简版，复杂任务用中等版；第三，通过 A/B 实验绘制 Pareto 曲线，找到 Token 消耗和调用成功率的拐点。总结一句：平衡不是一刀切，而是基于数据的系统优化。”
4️⃣ 高频追问 & 应对
追问 1：如果工具数量很多（比如 100+），如何管理描述？
用工具注册中心（Tool Registry）统一管理，每个工具的描述按模板生成：
name+parameters（只含类型和约束） +examples（1-2 个）。对于高频工具，可以预计算 Token 消耗并缓存。另外，使用工具分组策略：将相似工具合并为一个“超级工具”，通过参数区分行为，减少描述总数。例如，把search_web、search_news、search_images合并为search(type: string)，描述只写一次。
追问 2：如果 LLM 对精简描述理解不准，怎么补救？
引入重试机制：第一次调用用精简描述，如果返回格式错误或参数缺失，自动切换到中等详细度重试。重试次数限制为 1 次，避免无限循环。另外，可以在系统 prompt 中加入“工具描述已优化，请严格按参数类型和约束调用”的指令，提升遵循率。实测这种策略下，90% 的调用用精简版即可成功，只有 10% 需要重试，整体 Token 消耗降低 40%。
追问 3：如何量化“理解准确度”？有没有具体指标？
用参数提取准确率（Parameter Extraction Accuracy）和意图匹配率（Intent Match Rate）。前者检查 LLM 输出的工具参数是否完全符合 Schema（类型、范围、必填项），后者检查工具选择是否正确。对于复杂任务，还可以用任务完成率（Task Completion Rate），即多步调用中每一步都正确的比例。这些指标可以通过单元测试框架自动化统计，例如用 pytest 生成 100 个用例，每次部署前跑一遍。
5️⃣ 避坑 · 常见错误答法
- ❌ “描述越详细越好，LLM 理解更准，多花点 Token 无所谓。” → ✅ “详细描述会引入噪声，反而降低准确率，且 Token 成本线性增长。正确做法是用示例替代长文本，并做 A/B 测试找拐点。”
- ❌ “所有工具用统一详细度，方便维护。” → ✅ “不同任务对准确度要求不同，统一详细度会导致简单任务浪费 Token、复杂任务理解不足。应该根据任务复杂度动态调整，或至少分 2-3 个等级。”
- ❌ “优化 Token 消耗就是缩短描述文字。” → ✅ “缩短文字可能丢失关键约束，正确做法是优化信息密度：用 JSON Schema 的
examples和const字段替代自然语言描述，同时保留必要边界条件。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“工具描述类似检索文档的 chunking 策略”切入，对比 BM25 和 DPR 的详细度对召回率的影响，强调 Token 消耗与检索精度的 trade-off。
- 如果你只做过传统 NLP：用“文本分类中的特征选择”类比，说明冗余特征（长描述）会引入噪声，精简特征（短描述）能提升模型泛化能力，并提到 TF-IDF 和互信息的选择逻辑。
- 如果你是校招无项目：聚焦论文复现，引用 OpenAI 的“Function Calling”文档和 Anthropic 的“Tool Use”最佳实践，说明你通过实验对比了不同详细度对 GPT-4 和 Claude 3 的调用成功率，并绘制了 Pareto 曲线。
- OpenAI Function Calling 官方文档：Best Practices for Tool Descriptions
- Anthropic Tool Use Guide：Optimizing Descriptions for Accuracy and Cost
- 论文：”Tool Learning with Foundation Models” (2024) – 第 3.2 节关于描述优化的实验
- 博客：”The Pareto Principle in LLM Tool Calling: How to Cut Token Costs by 60%” (Medium, 2024)
- 工具：tiktoken（OpenAI Tokenizer）和 LangChain Tool Registry 源码分析