大模型幻觉问题的具体表现和解决方法

做业务接入的人常见卡点是：模型答得又顺又像真的，等用户投诉才发现是编的。这篇不给概念科普，而是先把幻觉按表现分几类，让你能一眼认出它；再按「输入约束、外部知识、输出校验、流程兜底」四层给可执行动作，并写清哪些任务压根不该指望模型自己靠谱。

做业务接入的人最常见的卡点不是模型不会答，而是它答得又顺又像真的。用户不会当场告诉你错了，等到投诉或者对账对不上，才发现内容是编的。所以这篇不聊原理，先帮你把幻觉按表现分成几类，让你一眼能认出它长什么样；再按输入约束、外部知识、输出校验、流程兜底四层给动作，最后写清哪些任务压根不该指望模型自己靠谱。

有一个心态要先建立起来：幻觉不是模型「坏了」，而是它的正常工作方式带来的副产品。它擅长的是生成看起来合理的话，不是保证每句话都有出处。所以你要做的不是找一个不会幻觉的模型，而是给输出加几道闸门。下面每一节都对应一道闸门，成本从低到高，能上几道上几道。

先认脸：幻觉在业务里长什么样

认不出幻觉，就没法针对性下药。日常业务里它基本跑不出下面五类，你对照着看自己踩过哪几种。判断的核心信号只有一个：凡是模型给出的可核实事实、数字、专有名词、引用，都默认不可信，除非有外部来源对齐。

什么任务最容易被幻觉咬到

不是所有任务都值得上四层校验，成本划不来。判断标准就一条：输出如果会被直接拿去执行、或者直接对客户展示，那就必须有校验环节；只进人眼的草稿类输出可以放宽。下面按风险粗分一下，帮你决定在哪下功夫。

• 高风险：政策法规解读、价格与报价、医疗与用药、财务数字、合同条款，以及代码里的第三方库 API 名和参数
• 中风险：客服自动回复、摘要提炼、数据分类标注，错了要人工过一遍但后果可控
• 相对低风险：改写润色、格式转换、头脑风暴、初步思路草稿，出错只浪费一点时间
• 线上一句话：会被自动执行或被对外展示的内容，一律当作不可信，先过校验再放行

第一层：把输入的口子收窄

最省钱的一层。目标不是让模型更聪明，而是把它的自由发挥空间压小。两个动作最有效：一是把原始资料直接作为上下文给它，二是把回答的「形状」规定死。要提醒的是，这一层对开放式任务是反效果，创意写作、长文起草这类场景别硬套。

1. 把资料一起喂进去把原文、表格、合同片段放进上下文，并明确写「只依据以上内容回答，找不到就说找不到」。验证办法：拿几条资料里确实没有的问题试，看它是编还是老实说没有。
2. 限定回答形状要求输出固定字段的 JSON，把自由文本压到最小。好处是程序能直接校验字段是否缺失、值是否在枚举范围内，比读一段散文靠谱得多。
3. 约定拒答话术提前定好「资料中没有相关信息」这种标准说法，让模型知道拒答是允许的，不用为了显得有用硬编一个答案出来。
4. 小步验证每次只改一个约束，用同一批测试问题前后对比错误类型分布，别一次改五处，改坏了不知道是哪处的锅。

第二层：用检索和知识库补事实

第一层解决不了「模型压根不知道」的问题。思路是把事实性内容从模型记忆转移到检索结果上，模型只负责归纳和表述，不做事实来源。这一层里，检索质量的影响往往比换模型更大，向量库选型和嵌入模型怎么挑，可以到站内的向量数据库与嵌入模型对照页去看当时的对比口径。

如果文档本身互相矛盾、新旧版本混在一起，检索会把矛盾一起喂给模型，出来的答案忽左忽右。这种情况先做资料治理，把过期版本清掉，再谈检索优化。资料没理干净，换什么模型都救不回来。

第三层：输出侧的校验与拦截

前两层是「尽量让它答对」，这一层是「答错了别让它流出去」。核心思路是把可以机械验证的东西从模型手里拿走，交给代码判。校验失败不要直接抛给用户，而是回炉重问或者转人工。

1. 能算的别让模型算金额、比例、日期差交给代码，模型只负责从文本里抽参数。抽出来的参数格式不对就判失败重问，比让它自己算准得多。
2. 数字与专名回查用正则从输出里抽出数字、编号、引用，跟原文逐条比对，不一致就拦下来。这一步能拦住大部分数字漂移和假引用。
3. 字段与枚举白名单字段名、选项值走白名单，不在名单里的直接判失败。第三方接口的字段名尤其要这么干，模型编参数名是高频事故。
4. 多模型交叉同一问题让两家不同模型各答一次，结论不一致的进人工队列。这比让单模型自我检查更有效，因为自己检查自己很容易一起错。

第四层：流程兜底与人工介入

前三层是技术动作，这一层是流程设计。核心是分级放行：低风险自动通过，中风险抽检，高风险必须人工确认，把有限的人力放在出错代价最大的地方。同时留好证据链，出事能回溯是哪一环漏了。

• 分级放行：按业务风险给输出打标签，自动通过、抽检、必审三档，别所有输出都走同一套流程
• 留证据链：保存提问、检索到的资料、模型原文、校验结果，出问题时能定位到具体哪一层
• 用户侧话术：明确告诉用户哪些内容是生成的、哪些是原文引用，别让人默认全部可信
• 别只写「不要编造」：只在提示词里加一句不许编造基本没用，幻觉是生成机制带来的，必须有实际校验动作配合

这一层还有一个容易忽略的点：人工审核本身要定标准。审什么、按什么判、判错了怎么反馈进测试集，这些不写清楚，人工环节会变成走过场，反而给人虚假的安全感。

上线前怎么把幻觉率量出来

治理幻觉不能靠感觉。准备一批带标准答案的问题集，覆盖三种情况：有资料能答的、没资料应该拒答的、资料本身冲突的。看模型在这三种情况下分别怎么反应，比看一个笼统的准确率有用得多。

另外两件事要养成习惯：一是模型换代或换供应商后重跑同一套题，别凭印象觉得变好了；二是定期复测，文档更新、业务话术变化之后各跑一次。模型能力横向对比的口径可以到站内评测榜看当时的数字，但那只作参考，你自己的测试集才是准的。

一份可以直接照做的排查清单

最后把上面几节压成一套可执行顺序。遇到一个疑似幻觉的问题，按这个顺序走，别一上来就改提示词。顺序本身就是成本从低到高，前面没排干净就别急着上后面的重手段。

1. 先定性分清是幻觉、知识截止还是检索没召回。定性错了，后面所有调整都是碰运气。用一个资料里没有的问题试一下，看它是编还是承认不知道。
2. 收窄输入把资料喂进去、规定输出形状、约定拒答话术，用同一批问题前后对比看错误类型有没有变化。
3. 补检索如果错在知识缺失，去调检索的分块、召回条数和重排。资料冲突的先做资料治理，别指望模型帮你判断哪版是对的。
4. 加输出校验把计算和数值核对交给代码，字段走白名单，高价值场景上多模型交叉，校验失败要有重问或转人工的出口。
5. 流程分级按风险决定自动通过、抽检还是必审，留好证据链，并把人工审核的标准写清楚。
6. 定期复测文档更新、模型换代、业务话术变化后各跑一次测试集，同时看错误率和不必要的拒答率。