跳到主要内容

幻觉并不可怕，可怕的是你不知道它什么时候出错

· 阅读需 6 分钟
一介布衣
一介布衣
全栈开发者 / 技术写作者

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-02-18 21:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

大模型幻觉一直是个高频话题，但我越来越觉得，真正难缠的不是“模型会不会出错”，而是“系统知不知道它正在出错”。前者是模型能力边界，后者是工程设计问题。只要是概率系统，出错几乎不可避免；但一个能不能上线、能不能长期维护的 AI 功能，关键在于它出错时是否能被识别、被限制、被回收。

很多团队会把幻觉理解成一个纯模型问题，于是自然会把主要精力放在换模型、换 Prompt、加限制词上。可真正进入业务之后，最危险的往往不是明显胡说八道，而是那种“看起来很像对、实际上悄悄偏了”的结果。因为这类错误更难被用户第一时间看穿，也更容易混进流程。

所以我现在的看法是：幻觉并不可怕，可怕的是系统既没有提前识别风险的机制，也没有在出错时给出信号。

幻觉为什么很难彻底消灭​

先说结论，我不太相信“完全消灭幻觉”这件事。原因有三层：

1. 模型本质上是在预测，不是在查询真相​

哪怕它看起来像在“回答问题”，底层仍然是在根据已有上下文和训练分布生成最可能的下一个结果。

2. 业务输入永远不完整​

真实用户的问题往往不带够前提、不讲清边界、会混用口语和缩写。输入一旦不完整，模型就容易自行补全。

3. 上下文本身可能就不可靠​

检索错、文档过期、工具返回异常、系统拼装上下文时丢字段，这些都会让模型在错误材料上继续“认真推理”。

所以在工程上，与其追求“绝不出错”，不如追求“出错时尽量能被看见和拦住”。

我最怕的不是大错，而是小偏差​

很多人一谈幻觉，脑子里浮现的是那种非常明显的错误回答。但在真实场景里，更危险的反而是这些：

  • 数字差一点点
  • 条件漏了一条
  • 时间范围说窄了或说宽了
  • 结论方向对，但例外情况没提
  • 语气非常笃定，但证据并不足

这类错误比“完全胡说”更难处理，因为它很容易混进人工审核和业务流程里。尤其当系统输出看起来格式整齐、用词专业时，人反而更容易降低警惕。

所以我现在会更强调“风险可见性”，而不是只盯“平均正确率”。

一个更工程化的看法：幻觉不是单点，而是链路风险​

如果把 AI 功能看成一条链路，幻觉可能出现在多个地方：

1. 输入层​

用户表达模糊，系统误解问题。

2. 知识层​

召回了错误或过期内容。

3. 推理层​

模型把多段上下文拼错了、推断过度了、补足了不存在的信息。

4. 输出层​

本来不确定的结果，被系统包成了一个确定答案。

真正可怕的不是模型自己某一次出错，而是整条链路没有任何一个环节愿意承认“我其实不够确定”。

我更在意的四种信号​

如果想降低幻觉带来的风险，我现在更在意这四类信号设计。

1. 证据信号​

回答是不是能指出依据来自哪里。

例如：

  • 引用了哪篇文档
  • 引用了哪条规则
  • 调用了哪个工具
  • 数据时间点是什么

没有证据的答案，在高风险场景里就不该被轻易信任。

2. 不确定性信号​

系统能不能明确表达“我可能不确定”。

这不一定要做成复杂的概率分数，很多时候只要做到：

  • 信息不足时明确说明
  • 上下文冲突时提示冲突
  • 检索为空时拒答

就已经比“硬答一个看起来完整的结果”要安全得多。

3. 异常模式信号​

有些错误不一定靠单次结果能看出来，但从链路上可以看出异常，例如：

  • 没有召回到任何有效上下文
  • 召回内容主题分散
  • 输出字段缺失或多出无关字段
  • 工具调用失败后模型仍然继续回答

这些信号不一定能直接证明“幻觉发生了”，但能提示这次结果风险偏高。

4. 回收信号​

用户或运营有没有办法把错答案标出来。

只要错误样本不能被回收，系统就永远只能靠下一次运气更好，而不是靠上一轮经验变得更稳。

我不会只靠 Prompt 解决这个问题​

Prompt 当然可以降低一部分幻觉，比如：

  • 强调“只能基于上下文回答”
  • 没证据时明确拒答
  • 输出时不要编造来源

但 Prompt 的问题是，它只能约束表达，不能保证上下文本身正确，也不能替代校验和回退。

所以我现在更愿意把 Prompt 放在整个治理体系里看，而不是把它当成唯一手段。

一个更稳的最小闭环​

如果一个团队问我“最小可行的幻觉治理怎么做”，我会先建议这套基础闭环：

  1. 给答案带证据来源。
  2. 对结构化结果做校验。
  3. 信息不足时允许拒答。
  4. 高风险场景必须能转人工。
  5. 记录失败样本并定期回放。

这套闭环看起来不花哨，但它比“继续打磨更强 Prompt”更接近生产现实。

一个简单示意​

const result = await answerWithContext(query)

if (!result.sources || result.sources.length === 0) {
  return fallback('暂无足够依据，请转人工确认。')
}

if (!validate(result)) {
  return fallback('结果校验未通过，请人工复核。')
}

return result

这段逻辑的核心不是“让模型更聪明”，而是“当系统发现自己不稳时，别装作很稳”。

真正值得追求的是可管理，而不是完美​

我现在越来越认同一个现实主义原则：AI 系统不需要先做到完美，才配进入业务；但它必须先做到可管理，才配进入业务。

所谓可管理，至少意味着：

  • 出错能发现
  • 风险能提示
  • 结果能追溯
  • 问题能回放
  • 必要时能接管

如果这些事情都没有，那么哪怕模型平均表现不错，我也会对上线保持谨慎。

总结​

幻觉并不可怕，因为任何概率系统都一定会有边界。真正可怕的是系统没有能力识别自己的边界，还把不确定的结果包装成确定答案。

所以我越来越少问“怎么完全消灭幻觉”，而更愿意问：“系统在什么时候知道自己可能错了？”这个问题一旦开始被认真对待，很多 AI 功能才算真正进入工程化阶段。