=LLM的幻觉问题是其落地的最大困境=
人类具有泛化能力，一朝被蛇咬，十年怕井绳，人类的大脑会把“蛇（危险信号）”的特征（细长、弯曲、可能突然出现）“推广”到相似的事物（井绳）上，哪怕井绳本身没危险，也会先产生警惕,帮我们避开潜在危险（比如真遇到类似蛇的毒虫时能更快反应），是演化中保留下来的“生存技能”。

• 人类的泛化：是“主动筛选+灵活调整”的——比如你怕井绳，但如果走近看清楚是绳子，会立刻修正“危险”的判断，不会一直怕； -
• AI的泛化：更像“被动的、机械的特征拼接”——当系统提示里的工具太多（比如几十上百个），LLM没法精准记住每个工具的“专属信息”（比如“只能用A工具做文档翻译，没有B工具做视频转文字”），就会把相似工具的特征“乱拼”：看到“文档翻译”“图片编辑”都是“处理文件”，就误以为有“视频转文字”这种同类工具，本质是对信息的“机械延伸”，而不是像人类一样有“判断边界”。

=所以，需要我们告诉LLM：这不是蛇，这是井绳=
接下来我将分享在agent工程实践的经验

工具幻觉问题

工具幻觉问题可以分为两大类，工具选择幻觉和工具使用幻觉

1. 工具选择幻觉

1. 捏造不存在的工具
2. 调用工具的名称有些偏差

方案：

在事前：在prompt中强调“你只能使用以下列表中的工具：[daily_line,hk_daily_line]”
在事中：工具执行层校验、工具名称不存在，返回提示错误,并通过RAG检索3个最接近的工具，告诉agent：你调用的工具不存在，你可能想要的是这些工具？
这给了LLM准确的纠错指导

2. 工具使用幻觉

1. 参数类型错误
   reuqire string but receive int
   工具参数需要字符串trade_date=‘20190904’，LLM却给了int
2. 参数名称偏差
   ts_code 而不是 stock_code
3. 捏造参数值
   股票日线工具的日期范围时效不对
   start_date='20190101', end_date='20190904'

方案

1. pydantic参数校验和转换
   pytdantic可以自动将int转换需要的string
2. 当为参数名称偏差错误，返回对应的工具参数，让agent能够准确调用
   特别的，模型偏好stock_code,于是在工具层面用更清晰的stock_code来映射第三方接口的ts_code参数，这样模型就能一次性成功调用工具。这也揭示了工具参数命名的重要性
3. 工具原子化-参数简化-功能明确
   分离出最近三天港股日线、最近七天港股日线的子工具，模型只需要输入股票代码这一个参数，工具成功率就上去了。

**第三方接口示例**
pro = ts.pro_api()

#获取单一股票行情
df = pro.hk_daily(ts_code='00001.HK', start_date='20190101', end_date='20190904')

#获取某一日所有股票
df = pro.hk_daily(trade_date='20190904')

更多经验分享

Agent工具调用优化技巧

工具设计

1. 控制工具数量

   • Why：工具太多模型容易产生幻觉、选错工具
   • How：OpenAI建议不超过20个，专家建议4-6个；可拆分成多个Agent分工合作

2. 功能单一化

   • Why：单一职责让模型更容易理解
   • How：避免一个工具同时处理多个功能（如不要同时查天气和订酒店）

3. 减少参数量

   • Why：减轻模型解析负担
   • How：能通过程序直接获取的参数就不要让模型解析（如用户ID、地址等信息）

4. 减少工具调用

   • Why：提高效率
   • How：简短信息直接塞给模型，让模型自行判断使用（如用户性别信息）

5. 后端补救措施

   • Why：预防模型出错
   • How：使用pydantic库校验参数、根据错误类型让模型重新生成参数

提示词设计

6. 完善工具和参数说明

   • Why：让模型准确理解工具用途
   • How：包括工具名称、作用、使用时机；参数名称、作用、必填字段、枚举值等

7. 规范调用格式

   • Why：确保后端程序顺利解析
   • How：指定输出格式（JSON或XML），统一格式标准

8. 增加调用示例

   • Why：提供学习参考
   • How：提供few-shot案例，结合用户提问检索历史相似问题的工具调用记录

9. 强调使用规则

   • Why：避免常见错误
   • How：结合实际易错点，强调准确输出参数、遵守指定格式等规则

10. 改写用户问题

    • Why：避免因问题模糊导致工具选择错误
    • How：提取关键信息、明确意图、简化表述；可设置专门Agent完成改写

模型选择

11. 优先选择支持工具调用的模型

    • Why：经过专门训练，工具调用能力更强
    • How：选择能输出结构化调用指令的模型，特别适合Agent任务

12. 测试择优使用

    • Why：确保模型能力符合需求
    • How：在可用模型中进行测试比较，选择表现最佳的模型

13. 有条件进行微调

    • Why：提升模型在特定场景的表现
    • How：根据当前场景构造训练数据（用户提问+工具调用指令）

效果监测

14. 上线前充分测试

    • Why：提前发现问题
    • How：准备测试集，测试工具选择和参数生成准确率，达标后才能上线

15. 上线后持续监测

    • Why：发现问题、优化方向
    • How：记录调用细节（用户输入、模型输出、执行结果），通过日志分析指导优化

【尾声】

关于LLM的幻觉问题，你在实践中遇到过哪些有趣的bad case？或者有什么独特的解决思路想分享？欢迎在评论区聊聊