#幻觉问题专题总览

很多团队讨论 AI 幻觉时，会直接跳到某个技术方案：换更强模型、接 RAG、加引用、做 Eval、上人工审核。

这些方案都有价值，但它们不是同一层问题的答案。客服回复、文档问答、代码助手、数据分析、医疗法律咨询，对幻觉的容忍度完全不同。一个写作润色助手偶尔措辞不准确，可能只是体验问题；一个合规判断助手编造法规条款，可能就是业务事故。

所以进阶理解幻觉，不能从“有没有幻觉”开始，而要先问：

• 这个场景里，什么输出算错？
• 错了以后谁承担成本？
• 用户有没有能力发现错误？
• 系统有没有事实来源可以校验？
• 答案是建议、摘要、判断，还是会触发真实操作？
• 需要把幻觉压到多低，才值得投入更多工程成本？

这篇总览先拆场景和幻觉类型，再给出从易到难的方案阶梯。核心观点很简单：降低幻觉不是追求一个万能架构，而是为不同业务风险选择刚好足够的可靠性设计。

#先看具体场景

幻觉在不同产品里长得不一样。

在客服场景里，模型可能编造退款政策、承诺不存在的补偿、误判用户情绪，或者把内部处理流程说给用户听。它的价值是提升响应速度和覆盖率，但错误会直接影响用户信任和运营成本。

在文档问答里，模型可能根据检索到的片段过度概括，引用了文档但答案并不被文档支持，或者在资料缺失时仍然给出自信结论。它的价值是降低找资料成本，但可靠性关键在于“答案是否 grounded in documents”。

在代码助手里，模型可能编造 API、生成不可运行的代码、忽略项目约束，或者给出存在安全问题的实现。它的价值是提升开发效率，但代码可以通过类型检查、测试、lint 和审查来逐步校验。

在数据分析里，模型可能误读指标口径、使用错误时间范围、把相关性说成因果，或者生成无法执行的 SQL。它的价值是让业务用户更快探索数据，但错误结论会影响经营决策。

在医疗、法律、金融、合规等高风险场景里，模型可能编造诊断依据、法规条款、投资结论或合规判断。它的价值通常不是直接替代专家，而是辅助整理资料、形成草稿、暴露不确定点。这里的关键不是“模型能不能回答”，而是“系统是否阻止它越界回答”。

这个图不是精确坐标，而是提醒团队：同样叫“幻觉”，治理优先级取决于业务风险和校验能力。风险高、校验弱的场景，不能只靠 Prompt；风险低、校验强的场景，也不必一开始就上很重的架构。

#幻觉类型不是一个维度

“AI 胡说”这个词太粗。工程上需要把它拆细，因为不同类型对应不同治理手段。

这里最容易被忽视的是推理幻觉和边界幻觉。

事实幻觉看起来更明显，比如“这个 API 参数不存在”。但在真实产品里，很多严重问题来自“事实没错，结论错了”。例如系统查到“本月退款率上升 2%”，模型却说“新定价策略失败”。中间缺少足够证据，这就是推理越界。

边界幻觉也很常见。模型说“你应该立即停药”“这份合同没有风险”“我已经帮你提交了申请”，这些句子的问题不一定在语法或知识点，而在产品责任边界。

#场景分析：先定义错误成本

治理幻觉的第一步，不是写 Prompt，而是定义错误成本。

可以用四个问题快速判断：

如果四个问题都偏低风险，简单提示词、边界文案和用户反馈可能已经足够。比如内部写作润色、会议纪要草稿、低风险信息整理。

如果其中两个以上偏高风险，就应该进入更系统的可靠性设计：检索、工具、引用、结构化输出、人工确认、Eval 和监控。

#从易到难的方案地图

降低幻觉可以理解成一条阶梯。不是每个场景都要走到最顶层，但团队应该知道每一层解决什么问题、成本在哪里。

第一层是提示词边界。明确回答范围、拒答条件、输出风格、不能编造来源。这一层便宜，适合大多数场景作为起点。有时它就够了，尤其是低风险、用户可编辑、无事实承诺的场景。

第二层是上下文和引用。把可用资料、时间、来源 ID、权限范围放进上下文，并让答案标注依据。它解决“模型不知道该依赖什么”的问题。

第三层是 RAG。适合知识库、文档问答、内部政策、产品手册等场景。RAG 的重点不是“向量数据库”，而是文档解析、权限过滤、检索质量、上下文组装和拒答策略。

第四层是工具校验。订单状态、余额、库存、日程、权限、数据指标、代码执行结果，不应该让模型凭语言生成。让工具成为事实源，模型负责解释工具结果。

第五层是结构化输出。把模型输出限制在 schema 内，便于程序校验、重试和渲染。它不能保证事实正确，但能减少格式漂移、字段缺失和不可控文本进入业务流程。

第六层是人工审核。适合高风险结论、高金额操作、对外承诺和不可逆动作。人工审核不是失败，而是系统承认风险边界。

第七层是 Eval。上线后持续用评估集、线上反馈和 trace 判断改动是否降低质量。没有 Eval，团队会靠感觉调 Prompt，幻觉问题会反复出现。

#收益和成本判断

不同方案的收益和成本差距很大。

一个常见误区是低估简单方案的价值。很多早期 AI 功能只需要把 Prompt 写清楚、把缺资料时的拒答做好、把“建议”和“事实”分开展示，就能明显降低风险。

另一个常见误区是低估复杂方案的系统成本。RAG 不是接一个向量库，Eval 不是写几条测试，人工审核也不是加一个“确认”按钮。它们都需要产品、数据、后端、前端和运营一起定义流程。

#方案选型表

下面是一张更实用的选型表，可以作为项目评审时的检查清单。

选型时可以先做最低可行治理，而不是一次性堆满所有方案。好的可靠性设计应该能渐进升级。

#常见反模式

第一种反模式：把幻觉当成模型厂商问题。

模型能力当然重要，但很多幻觉来自系统没有提供事实源、没有约束输出、没有展示依据、没有处理工具失败。换模型可以改善一部分问题，却不能替代产品和工程边界。

第二种反模式：把 RAG 当成幻觉保险。

RAG 只是把知识片段放进上下文。检索错、切分差、权限过滤漏、上下文污染、引用不校验，都会让 RAG 变成“有依据外观的幻觉”。

第三种反模式：要求模型“不要幻觉”。

这句话可以写进 Prompt，但不能当成治理方案。更有效的是告诉模型在什么条件下拒答、答案必须来自哪些来源、每个结论需要绑定什么证据、工具失败时如何表达。

第四种反模式：只看最终答案，不看链路 trace。

没有检索结果、工具调用、Prompt 版本、模型参数、输出解析和用户反馈，团队很难定位问题到底发生在哪一层。

第五种反模式：对所有场景使用同一套可靠性策略。

低风险场景过度治理会拖慢产品；高风险场景轻量治理会制造事故。可靠性要和业务风险匹配。

#小结

幻觉问题不是一个单点 bug，而是 AI 应用的系统可靠性问题。

更有效的处理方式是先分清业务场景、错误成本和幻觉类型，再选择合适的治理层级。低风险场景可以从提示词、拒答和用户反馈起步；知识问答需要引用和 RAG；实时数据和操作类场景需要工具校验；高风险场景需要人工审核和 Eval 闭环。

这个专题的后两篇会继续展开：

• 不同业务场景下的幻觉问题：为什么客服、文档问答、代码助手、数据分析和高风险专业场景不能用同一套标准。
• 降低幻觉的方案阶梯：如何从简单提示词逐步升级到引用、RAG、工具、结构化输出、人工审核和 Eval。