我们组做了个内部知识库问答系统，刚上线那会儿，老板亲自测试。他问了一句：“咱们公司上个月请假天数最多的人是谁？”

系统秒回：“根据 HR 系统的数据，上个月请假天数最多的是张三，共请假 5 天，原因是婚假。”

老板差点把茶杯扔屏幕上。

因为我们组根本没有叫张三的人，也没有什么婚假。这全是模型编的。更离谱的是，它编得有理有据，语气斩钉截铁，新人根本看不出毛病。

从那天起，我被下了死命令：“想办法，把这破毛病治了。”

于是我开始了长达一个月的“防幻觉”实验。试了 RAG、Prompt 约束、Self-RAG、多模型校验、结构化输出，把市面上能找到的方案全跑了一遍。今天把结果和踩的坑一次性全倒出来。

一、先说清楚：幻觉到底是怎么来的
很多人觉得幻觉就是模型“抽风了”。其实从工程角度看，幻觉分三种：

1. 知识缺失型幻觉：模型训练数据里根本没这个信息，但它不肯说“不知道”，于是开始编。就像你去面试，面试官问了一个你完全不懂的问题，你开始自由发挥。

2. 检索干扰型幻觉：你用了 RAG，但检索回来的文档片段不相关，模型被错误信息带偏了。相当于你问了 A 问题，秘书给你找了 B 资料，你基于 B 资料给出了看似合理但完全答非所问的回答。

3. 推理错误型幻觉：模型拿到了正确的信息，但推理过程中把逻辑搞错了。数据全对，分析错了，这种情况最隐蔽。

知道病因，才能对症下药。下面五种方案，分别针对不同类型的幻觉。

二、方案一：RAG 检索增强——防知识缺失型幻觉的标配
RAG 的核心理念特别朴素：模型不知道的，就从外部知识库里检索出来，塞进 Prompt，让它照着回答。

实测流程
我用一个 500 篇内部文档的知识库做了对比测试。

不用 RAG：模型回答内部流程相关问题的准确率只有 45%。有一半的问题它都在编。问“公司的报销流程是什么”，它给我编了一套标准化的报销流程，跟我们的实际流程完全对不上。

上了 RAG 之后：准确率涨到 78%。问报销流程，它能把我们真实的报销制度原文引出来，有板有眼。

关键配置
核心就是三个参数，别小看它们：

分块策略：512 token 一块，64 token 重叠

召回数量：top_k = 4，别贪多，多了反而不准

相似度阈值：0.7，低于这个分的直接扔掉，防止不相关内容干扰模型

为什么 RAG 不能根治幻觉
哪怕上了 RAG，还是有 22% 的问题在胡说八道。我看了日志，原因有两个：

一是检索失败。用户问“张三的请假记录”，但知识库里用的是“员工编号 A001”，检索没召回正确文档，模型又开始编。

二是模型不听文档。检索召回来了正确信息，但模型在生成时部分忽略或曲解了文档内容，加了自己的“脑补”。

结论：RAG 是防幻觉的基础，但不能只用 RAG。它能解决“模型不知道”的问题，但解决不了“模型不听话”的问题。

三、方案二：Prompt 硬约束——成本最低的防幻觉手段
这个方案最简单：在 Prompt 里直接给模型戴上紧箍咒。

我实测的约束语句
我在 System Prompt 里加了这几句：

text

1. 只根据提供的文档内容回答，不要使用文档外的知识
2. 如果文档中没有相关信息，直接回复“根据现有资料无法回答”，不要猜测
3. 回答时引用文档原文或指出信息来源
4. 不要编造任何数据、日期、人名
   效果
   加约束前，模型面对未知问题，90% 的情况会编一个答案。加约束后，未知问题的拒绝率提升到了 70%。但还有 30% 的时候它仍然会编，尤其当问题特别具体、模型“觉得”自己能回答的时候。模型太想帮忙了，你让它闭嘴它不完全听。

意外发现
约束语句本身要简洁。我一开始写了一堆“你是一个诚实的助手，你的首要原则是不编造信息”这种道德教化型语句，效果很差。后来改成“文档中没有依据的内容，一律回答‘不确定’”，直接给行动指令，效果反而好得多。模型需要的是行为约束，不是道德教育。

四、方案三：Self-RAG（自我反思）——让模型自己检查自己
Self-RAG 是目前比较前沿的做法，核心思路是让模型生成后先自查，确认可靠再输出。

我的实现
我用了两步走：

Step 1：模型根据检索到的文档生成回答

Step 2：把生成结果再发给同一个模型（或另一个模型），追问：

请检查以上回答：

回答中的每一条事实，是否都能在提供的文档中找到出处？

有没有任何猜测或编造的内容？

如果有不确定的地方，请标注出来并重新修正回答。

实测效果
100 个问题的测试集，加了 Self-RAG 后，幻觉率从 22% 降到了 12%。

降得不少，但代价也大。每次问答都要调两次大模型，Token 消耗翻倍，延迟也翻倍。我试过用便宜的小模型做第二步检查，但小模型能力不够，检查不出来大模型的错误。

我的折中方案
只在“高风险场景”启用 Self-RAG，比如涉及具体数字、日期、人名的问答。普通闲聊不触发自查。我加了个正则判断，如果回答里包含数字或日期格式的内容，自动触发二次检查。这样既控制了成本，又在关键场景兜了底。

五、方案四：多模型交叉校验——用“别人”的眼光审视
这个方案的逻辑像“陪审团”：同一个问题扔给两个不同的大模型，如果答案一致，基本可信；如果不一致，说明可能有一个在编。

实测配置
我用 GPT-5.4 做主模型，DeepSeek V4 做校验模型。两个模型都基于同一份检索到的文档生成答案，然后做对比。

效果
不一致率在 15% 左右。不一致的时候，人会介入判断——系统把两个答案并排展示给用户，标注“该回答存在分歧，请人工核实”。

这个方案防住了不少隐蔽的幻觉。有次用户问“去年第三季度的营收”，GPT-5.4 答了一个数，DeepSeek V4 答了另一个数。一查，GPT-5.4 把第二季度和第三季度的数据搞混了。

明显的缺点
贵：每次问答调两次大模型，成本直接翻倍。

慢：两个模型串行或并行调，用户体验上会有延迟。

不一致不一定代表有幻觉：有时候两个答案都对，只是表述不同。需要做语义层面的相似度比对，而不仅仅是字符串匹配。

结论：多模型校验效果好但成本高，适合对准确率要求极高的场景，比如金融、医疗。一般的企业内部知识库，用这个方案有点大炮打蚊子。

六、方案五：结构化输出——从根源上限制模型的发挥空间
这个方案换个思路：我不让模型生成自然语言，我让它生成 JSON。

实测
对于一个“查订单”的问答，我不让模型输出“您的订单已发货，预计明天到达”，而是要求它输出：

json
{
“orderId”: “ORD123456”,
“status”: “已发货”,
“estimatedArrival”: “2025-06-01”,
“confidence”: “high”
}
然后我的前端代码根据这个 JSON 拼成自然语言展示给用户。

为什么能防幻觉
自然语言里，模型很容易“顺嘴”加戏。JSON 格式下，每个字段都有严格的定义，模型自由发挥的空间被压到最小。它不能说“您的订单已发货，物流小哥正在路上，请注意接收，祝您生活愉快”这种带猜测的话。

效果
结构化输出方案上线后，数据类问答的幻觉率直接降到 3% 以下。因为它本质上把“生成”变成了“提取”，模型只负责从文档中提取字段值，而不是写一段话。

但这个方案的局限也很明显：只适合数据提取类任务。你让它写一篇行业分析报告，不可能用 JSON 输出。有边界的任务用结构化输出，没边界的任务还得靠其他方案兜底。

七、终极方案：组合拳
试了一个月，结论是：没有任何单一方案能根治幻觉。

但把上面五种方案组合起来，能压到一个可接受的水平。我最终上线的方案长这样：

层级 方案 解决的问题
第一层：知识保障 RAG 检索增强 知识缺失型幻觉
第二层：行为约束 Prompt 硬约束 无边界脑补
第三层：输出限制 结构化输出（数据类场景） 自由发挥型幻觉
第四层：兜底机制 Self-RAG（高风险场景） 残留幻觉检测
备选：高精度场景 多模型交叉校验 隐蔽幻觉排查
实际跑下来，组合方案的幻觉率稳定在 5% 以内。内部知识库问答这种场景，这个水平已经能用了。

但有一点要诚实地说：永远不可能到 0%。大模型本质上是个概率系统，概率就意味着一辈子都有“意外”。我们能做到的是让幻觉越来越少、越来越不明显、出了问题能及时发现和纠正。

八、最后说两句掏心窝的话
做 AI 产品，幻觉问题是最难解决的，也是最容易被忽视的。很多 Demo 跑得欢，一上线就翻车，就是低估了幻觉的破坏力。

我有两个心得，可能比上面的技术方案更重要：

第一，让用户知道“AI 会犯错”。我们在产品界面上明明白白写了一行灰字：“回答仅供参考，重要信息请核实原始文档。”这不是甩锅，是建立正确的预期。

第二，建立反馈机制。每个回答下面放个“这个答案准确吗”的按钮。用户点“不准确”，这个 case 自动进入我们的优化池，定期分析、改进知识库和 Prompt。越多人用的系统，应该越准确，前提是你有渠道让他们告诉你哪里错了。

幻觉问题是个长期斗争，不要指望一朝一夕解决。但只要你持续优化，用户会感受到你的用心。