为什么大模型会出现幻觉 怎么解决

你大概遇到过这种情况：demo 阶段模型答得有模有样，一上线就编引用、编字段、编不存在的接口名，用户一问就露馅。这篇不谈玄学，按「成因分类 → 风险评估 → 缓解手段 → 上线后怎么兜」的顺序走一遍，帮你在自己项目里定出该上哪几层。所有跟版本、价格相关的数字都不写死，去站内对应页面核对当时的数字。

你大概遇到过这种情况：demo 阶段模型答得有模有样，一上线就编引用、编字段、编不存在的接口名，用户一问就露馅。这篇不谈玄学，按「成因分类 → 风险评估 → 缓解手段 → 上线后怎么兜」的顺序走一遍，帮你在自己项目里定出该上哪几层。

先把一个预期摆正：幻觉没法被彻底消灭，只能被压到业务能接受的概率以下。所以真正要做的不是找一个「不会编的模型」，而是设计一套「就算它编了，也进不了用户眼睛或数据库」的流程。下面每一节都落到具体动作，看完你应该能在自己项目里排出改造顺序。

先分清：哪些是幻觉，哪些不是

很多人把所有「答得不对」统一叫幻觉，结果用同一套手段去治，效果自然差。第一步是分类。事实性编造是模型说了一个不存在的客观事实；格式性编造是内容没错但结构崩了，比如 JSON 少括号、字段名拼错；引用性编造最常见，它说「根据某文档第几节」但那段话压根不存在。三类原因的触发机制不同，兜底方式也不同。

事实性编造

可被外部证据证伪的陈述错误，靠检索与外部比对拦

格式性编造

结构不合法，靠 schema 校验与重试拦

引用性编造

出处与正文对不上，靠片段回查拦

知识截止造成的不知道

不是幻觉，是覆盖不足，正确做法是允许拒答

判断标准很简单：这句话有没有可核验依据？如果没有依据，而模型又表现得像有依据，那就是幻觉；如果模型直接说「我查不到」，那是好行为，不该被当成失败去惩罚。同一句话在不同业务里容忍度也完全不同，客服寒暄说错能兜，合同条款、金额、接口名说错就是事故，所以分类之后必须接一次风险分级。

成因拆开看：模型为什么会「编」得这么流畅

根本原因是训练目标。模型学的是「给定前文，下一个词最可能是什么」，优化的是流畅和像人话，不是「这句话在世界上是否为真」。这两件事大多数时候同向，但在冷门事实、精确数字、内部接口这类地方就会分叉。模型没有「我不确定」这个内在信号，它能输出的只有概率分布里较高的那一串字。

• 训练目标错位：追求语言合理性，不追求事实正确性，流畅和真实本身就不是同一个目标
• 被输入带偏：上下文里给了半截信息、互相矛盾的材料或错误示范，模型会顺着编下去
• 解码放大：采样随机性调得越高、上下文越长越脏，跑偏概率越大
• 覆盖不足硬答：让它答训练时压根没覆盖的领域，等于逼它猜，猜出来的东西还特别像真的

这四条里，只有第一条是模型本身的属性，剩下三条都是工程问题，也就是说你可以动手改。被输入带偏靠清理上下文和校验素材来源解决；解码放大靠按任务调参解决；覆盖不足靠检索补知识解决。理解这一点，后面的缓解手段就不再是玄学调参，而是有针对性的工程动作。

先做风险分级：不是每个场景都值得上全套

很多团队一上来就想把所有场景都做到零幻觉，结果成本爆炸、迭代停滞。正确做法是先标出哪些字段绝对不能错，其余放宽。你可以按「错误后果有多严重」和「用户有多容易自己识破」两个维度，把业务里的输出类型过一遍。

落地动作是列一张「可核验字段清单」：数字、日期、人名、链接、代码接口、法律条款，凡是在清单里的，后面每一层校验都要专门照顾。不适用的情况也要说清楚：纯创意写作、发散灵感、文案扩写这类任务，用户本来就不指望「真实」，你硬加上一堆校验和限制，输出会变得又干又没用，属于把手段用错了地方。

检索与上下文：把「凭记忆答」改成「看着答」

最有效的一层是让模型别靠记忆答。把相关资料在提问时一并给它，让它从材料里找答案并标注来源。听起来简单，但做不好的地方全在细节：切片方式、召回质量、提示里的引用格式。这三点任何一个没做好，检索反而会制造新的幻觉，因为它给了模型一堆看似权威的碎片。

1. 切片段不要只按字符长度硬切，按语义单元切，保证每片能独立读懂。切碎了模型会跨片拼接，拼出原文没有的意思。
2. 控召回设定相关性阈值，召回为空或分数过低时，明确告诉模型「没有找到相关资料」，而不是硬塞几条低质结果进去。
3. 定格式提示里写清引用格式，并给「有依据怎么答」和「没依据怎么答」两种示例，拒答示例一定要放，否则模型会默认必须答。
4. 可回查要求回答附上引用的原文片段或段落标识，便于后面自动比对片段是否真的支持结论。

知识库本身的质量也要管。如果原始资料里就有过时信息、互相矛盾的说法，模型只会把矛盾原样输出或强行融合。检索层不是「接上一个向量库就完事」，素材的时效性和一致性要有人负责维护，这部分工作量往往比调提示大得多。

输出层校验：把不确定性挡在业务之外

无论前面做得多好，最后一道闸门必须放在输出层。核心思路是：让错误变得容易被机器发现。自由文本最难查，结构化数据最好查。能要求模型输出 JSON 就别让它写散文，字段缺失比字段编造好发现得多，也更容易触发重试或降级。

• 结构校验：按 schema 检查必填字段、类型、枚举值，不合规直接重试或降级
• 白名单比对：接口名、产品名、分类这类有限集合，直接查表验证
• 外部比对：数字、日期、链接去权威源核一遍，对不上就走兜底
• 独立复核：用另一个模型或规则引擎只判断「结论有没有依据」，不让它重新生成内容
• 降级路径：校验失败要有人能接住，转人工、给模板话术或明确提示无法回答

这里有个容易踩的坑：复核层不要又变成一个生成模型。让 A 模型生成、B 模型再自由发挥一遍，只会引入一套新的幻觉。复核的职责应该是判别式的，输出「有依据 / 无依据 / 部分支持」这类有限标签，判完就走分支逻辑，这样它才可控。关键链路连复核都拿不准时，宁可转人工，也不要让用户看到半成品。

提示与解码参数：成本最低的一层

这一层几乎不花钱，改起来也快，值得先做。最常见的问题是任务塞太满：一段提示里让它同时算数、引用、总结、翻译，出错概率自然高。拆成多次调用，每次只让它做一件事，稳定性会明显提升。多花的那点调用量，通常比后面补校验省事。

提示侧还有两点：一是别把互相矛盾的材料一起塞进去，矛盾本身就是编造的诱因；二是少样本示例里要有「正确拒答」的样例。至于具体温度、top_p 该设多少，不同模型、不同版本差异很大，别照抄别人的参数，到站内模型资料库核对当前模型的能力说明，再拿自己的固定题集实测决定。

上线后怎么发现：幻觉不能只靠人肉抽查

上线不是终点。幻觉比例会随着换模型、改提示、更新知识库而波动，没有监控你根本不知道是变好还是变坏。第一步是建固定题集：一批带标准答案、涵盖你核心业务的题目，每次改动前都跑一遍对比。题集不用大，但要有代表性，特别要覆盖你那张可核验字段清单。

• 无依据输出比例：有结论但找不到支撑材料的占比，最直接的幻觉指标
• 校验拦截率：输出层拦下多少条，突然升高通常说明上游出问题了
• 用户追问率：用户对同一问题反复追问，往往是没被识破的幻觉在露头
• 拒答率：太低可能是提示逼着它必须答，太高可能是检索没做好
• 坏例回灌：线上发现的错例定期加进题集，形成闭环

人工抽查不能省，但要按风险等级分配。高风险字段每一条都值得看，低风险场景抽个比例就行。另外，换模型、换版本前先跑固定题集，别看单次观感就切，主观感受对模型评价特别不靠谱。想横向了解各家中转站的稳定性表现，可以去站内评测与排行页面看当时的数字，再结合自己的题集做决定。

落地清单：从今天开始按顺序做哪几件事

1. 盘点可核验字段把业务里所有不能错的字段列出来，这条清单是后面所有动作的靶子。
2. 定拒答话术与路径明确「查不到时说什么」以及这句话怎么落到产品界面上，先把这个兜底打开。
3. 补输出校验规则按字段清单写 schema、白名单和外部比对，配好失败后的降级分支。
4. 再做检索优化切片、召回阈值、引用格式，这三项改完要用固定题集验证，别凭感觉。
5. 最后调模型和提示前面的机制都到位了，再去对比模型、微调参数，这时候的改动才看得清效果。

把缓解手段按成本排一下：提示和拒答最便宜，改几句话就能上线；检索次之，要维护知识库；输出校验和独立复核更重，但拦得也最死；人工复核最贵，只留给高风险字段。别一上来就上最重的那套，先用轻量手段把明显能拦的拦住，再按监控数据决定要不要加码。这套顺序的核心思路就是：先保证错了能被发现，再追求让错误少发生。