那个本该计算却随口编造数字的智能体

询问你的智能体上季度的流失率，它会用一个简洁的句子回答 4.2%。这个数字看起来很合理。周围的文字描述也显得很有信心。然而，当有人最终检查仪表盘时，显示的却是 6.8%。智能体根本没有进行任何查询——它只是产生了一个符合“流失率”特征的 Token 序列，因为对于语言模型来说，口述一个数字和计算一个数字在输出过程中看起来是一模一样的。

这是一种能躲过所有 Demo 的隐形失败模式。一个虚构的工具名称会抛出你可以捕获的错误。一个格式错误的参数会通不过 Schema 校验。但是，一个表达流畅的虚构 数值，会穿透你的整个流水线，看起来与真实数值毫无二致。没有异常，没有日志记录，没有红字。唯一的错误信号是某个恰好知道正确答案的人——而使用智能体的初衷本就是为了让人们不必亲自去查。

之所以值得专门为此写一篇文章，而不是将其作为“幻觉”的一个脚注，是因为常规的针对幻觉的建议在这里并不适用。你无法通过 RAG 来解决它，因为模型明明拥有工具却选择不去使用。你无法通过提示词完全可靠地解决它，因为“始终使用分析工具获取数字”这种指令，模型大部分时间会遵守，但其余时间会悄悄忽略。修复方法必须是结构性的：你必须在关键环节让“复述数字”变得 不可能，并让它产生的每一个数字都带上它的“凭据”。

为什么流畅性掩盖了缺失的工具调用

语言模型通过对基于先前所有内容的概率分布进行采样来生成下一个 Token。当上下文询问“上季度的流失率”时，高概率的后续内容是一个个位数的百分比，因为训练数据中的流失率通常就是这个样子。模型并不是在查阅事实，而是在补全模式。输出的 4.2% 和实际 SQL 查询的结果属于相同的数据类型——字符串——而产生虚假数字的生成过程，与格式化真实数字的过程在机制上是一模一样的。

这就是为什么流畅性是最好的伪装。我们已经习惯于将迟疑、推托和格式错误的输出视为疑点。而一个虚构的数字完全没有这些征兆。它以与正确答案相同的节奏出现，因为从机制上讲，它 就是 同一种输出。关于 LLM 智能体幻觉的研究将其分为两类：忠实性错误 (faithfulness errors)，即智能体违背了其检索到的证据；以及事实性错误 (factuality errors)，即在没有任何证据的情况下妄言。复述的数字属于第二类，而且更难被发现，因为没有任何证据可以反驳——只有缺失，而缺失是无法被渲染出来的。

针对定量问题，情况会变得更糟，因为模型非常不擅长那些被它们跳过工具而直接进行的算术运算。最先进的模型在 7 位数除法上的得分低于 40%。一项针对 48 项医疗计算任务的研究发现，大约三分之一的测试结果是错误的。模型并不是以某种可以纠正的方式“偷懒”——Transformer 推理本质上是一个概率文本生成器，而不是计算器，无论你如何提示，它都无法可靠地执行确定性的算术运算。因此，复述的数字具有双重危险：模型既拒绝调用工具，又在结构上无法产生工具本该提供的答案。

答案不等于有出处的答案

你的系统需要明确区分的是 答案 (answer) 和 有出处的答案 (sourced answer)。它们不是同一种事物的两个等级，而是两种不同的对象。

“答案”是一个占据数字位置的字符串。而“有出处的答案”是一个字符串加上一个可验证的计算指向：哪个工具运行了、使用了哪些参数、针对哪些数据、在什么时间运行。前者是一个断言，后者是一个带有凭据的断言。

现今大多数智能体技术栈产生的都是前者，却表现得像是后者。用户看到 4.2%，理所当然地认为系统 知道 这个数字，因为系统连接到了分析数据库——它肯定查过了。但“连接到”和“查阅过”是不同的事实，而输出结果并没有区分它们。界面暗示了数据并不具备的出处 (provenance)。

将这些视为不同的对象会改变工程逻辑。有出处的答案是可以验证的：你可以检查追踪 (trace) 中是否存在工具调用，其结果是否与文中的数字一致，以及它触及的数据是否足够新鲜。而没有出处的答案只能被盲目信任。而信任，对于一个失败模式是“自信地编造”的系统来说，并不是一种保障，而是一个漏洞。

因此，设计规则是简单粗暴的：智能体输出中任何没有出处的数字都是缺陷 (defect)。这不是风格上的瑕疵，也不是可以接受的近似值——它就是一个缺陷，其严重程度等同于 500 错误。它应该导致校验失败，而不是被耸耸肩放过。

加载中…