乐于助人但却出错：生产环境 AI Agent 中的操作性幻觉问题

你的 AI agent 刚刚完成了一项复杂的数据库迁移任务。它调用了正确的工具，使用了恰当的术语，引用了正确的库，并返回了看起来完全合理的输出。然后你的 DBA 在一个拥有 5000 万行的生产表上运行它 —— 结果备份标志（backup flag）写错了。这个标志存在于相邻的库版本中，语法上是有效的，但它在静默状态下没有执行备份步骤。

这个 agent 并不是在胡言乱语。它表现得自信、流畅且方向正确。但在操作上，它错得正是会导致数据丢失的那种方式。

这是该领域投入不足的一种幻觉类别，也是你的评估（evals）几乎肯定无法捕捉到的那种。

两种错误

当从业者谈论 LLM 幻觉时，通常指的是两种情况之一。第一种是纯粹的虚构：模型发明了一个统计数据，引用了一篇不存在的论文，或者生成了一个在现实中毫无根据的命名实体。这是那种会被写进论文或在主题演讲中演示的失败模式。

第二种则更为隐蔽，在生产环境中也更糟糕：模型了解正确的领域，选择了正确的工具，调用了正确的概念 —— 但在操作性的关键细节上出错。这种错误在方向上是合理的，但在操作上是失效的。

称之为操作性幻觉 (operational hallucination)：模型的输出能通过表面层面的正确性检查，并能通过大多数事实性评估，但在针对真实系统实际执行时却会失败。

这种区分很重要，因为这两种失败模式有着不同的成因、不同的检测策略以及不同的后果。事实性幻觉通常会表现得很明显 —— 编造的引用是可以追溯的，虚构的统计数据会被搜索结果反驳。而操作性幻觉则是静默失败的：代码运行没有错误，API 调用返回 200，备份显示完成 —— 直到它在某个时刻出问题，且很难追溯回模型。

问题的形态

操作性幻觉通常归为几个反复出现的类别。了解这些分类有助于你决定在哪里部署监控。

错误的参数实例。模型知道正确的 API，调用了正确的方法，但使用了看似合理但错误的参数值。例如，系统要求 DD/MM/YYYY，但指定的日期格式为 YYYY-MM-DD。或者当有效值为 "true" 时，将标志设为 "enabled"。如果你的 schema 比较宽松，这些能通过 schema 验证；如果验证层在下游，它们会静默失败；而且通过阅读输出来检测它们几乎是不可能的。

过时的方法签名。训练数据包含了多个库版本的文档。模型自信地调用 requests.get(url, verify=False, timeout=30, proxies=proxy_dict) —— 但在你环境所锁定的版本中，proxies 不是位置关键字。或者它针对不支持该版本的 Node 环境调用了较新 JS 规范中的 array.toSorted()。一切看起来都对，但错误是时间维度上的，而非概念上的。

概念正确，实例错误。模型理解你需要配置重试策略，选择了适当的 SDK 方法，但将配置应用到了错误的堆栈层级 —— 比如应用到了 HTTP 客户端而不是应用层的重试处理器。代码编译通过，测试通过，但重试在关键点上静默地失效了。

工具使用中的虚构。当给定部分或模糊的工具规范时，模型会虚构出听起来很正确的参数名称。一个名为 send_notification 的工具被调用时带有一个 spec 中并不存在的 recipient_email 字段 —— 因为模型推理出邮件通知需要一个接收者，且这个名称听起来很合理。如果你的工具处理逻辑没有根据 schema 严格验证输入，这就会通过。

为什么评估体系会遗漏它

这是令人不安的部分。大多数团队运行的评估流水线在结构上对操作性幻觉是视而不见的。原因如下。

加载中…