这次想认真聊聊大模型幻觉问题。做了几年大模型应用落地从最早的客服机器人到后面的行业知识问答几乎每个项目都绕不开“一本正经胡说八道”这个坎。很多刚接触大模型的人会觉得幻觉是模型“笨”其实真相远没那么简单——它是数据、训练方式、解码策略、用户提问方式共同作用的结果。这篇文章我会把幻觉的成因、检测手段、缓解方案以及我们在实际项目中踩过的坑一次性讲清楚希望能给正被幻觉折磨的同行一点参考。1. 什么是大模型幻觉先分清哪些算“病”哪些不算幻觉这个词在学术界的定义是模型生成的内容看起来流畅、语法正确、逻辑自洽但与事实不符或者根本没有任何事实依据。通俗点说就是模型“编”了一个答案而且编得特别像真的。1.1 幻觉的两种主流分法现在业界普遍接受的分法是两种事实性幻觉Factuality Hallucination和忠实性幻觉Faithfulness Hallucination。事实性幻觉主要指模型输出的内容与真实世界事实不一致。比如你问“某市面积多大”模型报出一个和官方数据对不上的数字。这类幻觉多发生在涉及时效性信息、具体数字、近期事件、小众知识时。忠实性幻觉指的是模型输出与用户指令、上下文不一致。比如你给了一段产品文档让模型写摘要它却自己加了文档里根本没有的结论。这种情况在长文档处理里特别常见模型沿着上文“顺着往下编”编着编着就跑偏了。还有一种很常见的分法是把幻觉分成“内在幻觉”和“外在幻觉”。内在幻觉指模型输出的内容与检索到的上下文冲突外在幻觉则指内容无法被任何已知事实验证但也不能说它错——比如让你做一道开放性设计题模型给你提供的方案。1.2 为什么大模型的幻觉问题尤其严重很多人会拿传统搜索来做对比搜索引擎返回的是网页用户自己判断相关性但大模型直接给你一个最终答案而且没有提供任何参考链接。它天生就有“生成自信感”——语气笃定、结构工整这让用户很难分辨对错。更麻烦的是生成式模型在解码时会倾向于选择“概率上最合理的下一个词”而不是“事实正确的下一个词”。在模型内部事实正确性和语言流畅性是分开优化的这本质上是个“表达能力”和“世界知识”拧巴在一起的问题。所以不要指望某个算法能“彻底消灭”幻觉。幻觉是大模型本身的属性我们要做的是控制在可接受的范围。就像你不可能让一个健谈的人永远不说错话但可以通过准备材料、转述规则、核对流程把说错话的概率降到最低。2. 幻觉从哪来我把成因拆成三层看只有理解了成因你才能在具体场景里对症下药。我把幻觉的来源归纳成数据侧、训练解码侧、用户交互侧三个层面。2.1 数据侧的根因高质量事实知识占比太低大模型的核心能力来自预训练语料但语料本身的“知识密度”是参差不齐的。预训练数据里包含大量重复的论坛帖子、营销文案、小说对话、代码注释模型在这些数据上学会了“语言的组织形式”但并没有形成稳定的事实知识。比如你让它解释“牛顿第一定律”它能写出标准定义因为它见过成百上千遍但你要问“某冷门作家的生平经历”语料里只有零星片段模型就只能靠语言习惯拼凑一个“看起来合理”的答案。数据侧还有一个隐蔽问题时效性缺失。模型的知识截止日期是固定的之后发生的新闻、产品发布、人事变动完全不在知识范围内。如果用户问的是截止日期之后的事模型会被迫“推理”出一个答案幻觉就不可避免。2.2 训练与解码不确定性被强行“抹平”了从训练角度看交叉熵损失函数鼓励模型给“标准答案”分配高概率。当一个问题的上下文出现多个可能的实体、数字和事件时模型会被迫选择一个最高概率的路径而不是表达“我不知道”。再加上人类反馈强化学习RLHF阶段标注员通常会倾向于给流畅、完整的回答打高分这变相鼓励了模型“多编一点别留空白”。从解码角度看采样参数也有讲究。温度太高时生成随机性增大更容易出现语义漂移温度太低时模型容易陷入重复但也可能陷入“高频词陷阱”——比如在所有不确定的环节都填上一个最常见的答案让错误变得隐蔽。2.3 用户交互侧提问方式能放大幻觉这一点很容易被忽略。当用户给出一个带有预设的、误导性的问题时模型会顺着用户的思路回答。比如你问“A公司和B公司哪家研发投入更高”这个问题本身默认了“两家都高”模型不会主动纠正这个前提而是直接给出对比结果。更常见的是问题过于模糊、范围太宽模型只能“猜”你的意图猜得越努力编得越远。还有一个典型场景多轮对话中的“语境粘附”。前面几轮聊的内容如果出现了错误信息模型会在后续回复中沿用这个错误因为对话历史本身就是它的上下文依据。这就是为什么有时候你越追问模型错得越“坚定”。3. 怎么发现幻觉我常用的三类检测思路聊完成因下面说检测。幻觉检测在生产环境里不是可选功能而是一个必须落地的质量关卡。我的经验是不要依赖单一检测手段至少叠两到三层。3.1 基于事实核查的检测这是一种“事后校验”思路让模型生成了答案之后我们用另外一个模型或者检索工具去核对答案里的“事实性断言”。具体做法是先把答案拆成若干个最小的事实单元称为原子断言然后逐个验证。举例说明。假设模型回答“结构化提示是2025年3月起面向企业用户开放。”拆成的断言是“结构化提示在2025年3月推出”“企业用户可以访问”。我们拿这些断言去检索如果找不到对应信息就标记为“无法验证”如果找到的信息与断言冲突就标记为“错误”。这种方法适合信息密度高的场景比如新闻摘要、医疗知识问答。3.2 基于一致性的检测一致性检测的核心逻辑是让模型对同一个问题重复回答多次比较答案是否一致。如果多次回答不断出现关键实体、数字、结论的变化大概率是在“编”。这里有两种常用做法一种叫“采样一致性”就是固定温度高于1.0对同一个问题生成5到10次编辑距离或者语义相似度低于阈值就判为高风险另一种叫“反向校验”——先生成答案再故意提出一个和答案相反的断言问模型是否同意。如果模型对自己生成过的答案表现出高度不确定说明本身就不稳。3.3 基于不确定性的检测模型在输出时其实对每个 token 都有一个概率值。很多时候模型“知道自己不确定”只不过最后输出的那一串文本掩盖了这一点。我们可以通过捕获这些概率值来评估不确定性。我在项目里常用的一种方法是序列概率归一化——对生成的答案计算平均对数概率。平均概率越低幻觉风险越高。我在这里用一段伪代码说明思路from transformers import pipeline import numpy as np generator pipeline(text-generation, model某开源7B模型) def sample_generation(prompt, temperature1.0): # 额外返回每个token的logprob return generator( prompt, max_new_tokens200, temperaturetemperature, return_full_textFalse, output_scoresTrue, return_dict_in_generateTrue, ) def avg_logprob_score(sample_result, tokenizer): scores sample_result[scores] # 每个token位置的概率分布 sequences sample_result[sequences] logprobs [] for pos, score in enumerate(scores): expected_tokens sequences[0][pos 1] # 实际被选中的token logprob score[0, expected_tokens.item()] logprobs.append(logprob.detach().numpy()) return float(np.mean(logprobs)) prompt 某公司的股东结构是怎样的 gen_result sample_generation(prompt) if avg_logprob_score(gen_result, generator.tokenizer) -1.0: print(低风险)注意这里的-1.0是经验值不同模型差异很大使用前先在自己数据集上校准一下。基于不确定性的检测好处是速度快、不依赖外部检索适合在低延迟要求的场景中做第一道初筛。4. 缓解幻觉的实操方案RAG、微调、Prompt 与解码策略检测是发现问题的缓解才是核心目标。接下来分享我们项目里真正用下来有效的几套方案。4.1 RAG 不是万能药关键在于“召回密度”与“提示构造”检索增强生成RAG是目前生产环境中的主流方案但它经常给人一种虚假的安全感——觉得接了知识库就不会幻觉了。实际上RAG 的幻觉问题经常出在“上下文没被用到”。我在实际项目里观察到一个现象当检索到的文档与问题相关度足够高时模型会优先参考文档。但相关度一旦出现“模糊”比如检索到了两篇互相矛盾的文档模型就会自由发挥了。为了缓解这个问题我建议在三个位置做精细处理。第一检索阶段不要只用一个向量数据库同时做关键词检索混排。向量检索擅长语义匹配BM25关键词检索擅长精确匹配二者结果做 RRF 融合召回质量提升明显。第二提示词里要明确给出“引用约束”“你只能基于以下上下文回答。如果上下文不包含答案请回答不清楚不要猜测。”第三对检索文档做重排序把最相关的段落放在距离问题最近的位置。上下文顺序对生成效果有直接影响。训练数据的经验是必须加入“对抗性样本”——即在上下文中故意不包含答案迫使模型学会说“不清楚”。如果 RAG 数据里全是“上下文刚好有答案”的场景模型就会被训练成默认上下文里一定找得到答案这反而会加剧幻觉。4.2 微调别指望微调能补充新知识很多人误以为微调可以让模型“记住”大量新知识进而减少幻觉。这里必须说清楚低秩适配微调的参数量远不足以编码大量事实知识。它的作用是改变模型的“行为模式”而不是更新知识库。如果你要做领域微调我建议把重点放在“形式规范”和“拒答行为”上。比如让模型面对超出知识范围的问题时统一回复为“当前知识库暂无相关资讯建议咨询专业人士”让模型在生成答案时强制以“根据提供的信息”作为开头让模型输出结构遵循固定的 JSON 或者“结论-论据-来源”三段式。这些都是微调能切实改变的东西比硬塞知识有效得多。有一个必须避开的坑微调数据不能直接从公开数据集里复制要针对你自己的领域做清洗。如果微调数据里本身就存在前后矛盾的句子模型学会的就不是正确决策而是“混乱”。我之前踩过这个坑某次微调用了自动抓取的产品页面数据没有做时效性过滤结果模型把已废弃产品的信息当成了新特性输出整个线上应用出了问题。4.3 解码策略与 Prompt 约束“让模型承认不知道”是训练出来的解码层面的调整是成本最低的干预。温度参数的影响很多人知道但很少有人会刻意调高top_p和frequency_penalty的组合效果。在事实问答场景我通常会把温度设到 0.2 或更低top_p设为 0.9。但这里有个细节如果任务带有创意性质比如写营销文案、头脑风暴温度则要放开到 0.7 以上否则会显得机械重复。不同任务的性质决定了要调适度的参数。Prompt 约束也很重要。在提示词里加入“事实核查指令”能显著降低幻觉明确要求模型在回答之前先自检把每一个断言和自己知道的事实进行比对要求模型把不确定的部分标注出来。同时支持让模型明确说“不确定”——这在很多场景中其实比错误答案更有价值尤其是医疗、法律、金融这类高风险领域。我们可以把规范化的拒答句式写进提示词系统层类似“对不起我无法确认该信息的真实性请提供更多上下文或查阅官方来源。”4.4 评估闭环没有评估体系的幻觉缓解都是空谈很多团队做幻觉优化是“拍脑袋式”的出一个方案人工看几个例子觉得不错就上线。这样在大规模场景下完全不可靠。我强烈建议搭建一个自动化评估集至少包含三类样本样本类型数量建议示例标准问答样本200-500条领域内高频问题附带标准答案陷阱样本100-200条问题上下文不包含答案检验拒答能力对抗样本50-100条包含预设错误前提的问题检验纠错能力评估指标上声誉法可以用快速精确匹配计算准确率但更推荐用模型作为评判员给答案打分再结合事实核查对断言进行验证。这样能同时覆盖“是否回答正确”和“是否包含幻觉断言”两个维度。顺便提醒一下评估集要定期加入线上出现的真实错误样本。每次线上用户反馈出幻觉问题就把它纳入回归测试集。这个做法帮我避免了很多次“修了东墙漏西墙”的情况。5. 一个可落地的综合案例给某行业知识问答系统做幻觉治理下面结合我在一个模拟项目里的经历完整介绍一套从问题发现到效果提升的实施路径。这个系统服务于某垂直行业从业者的日常查询答案必须准确、可溯源对幻觉容忍度极低。5.1 场景与方案设计系统上线初期的基础模型是某开源大模型直接调用。刚上线时的问题率高得惊人经过人工抽检我们认为有“明显错误或无可验证依据”的回答占比约25%。这个数字对于内部测试或许尚可接受但对生产环境来说完全无法忍受几乎每四条答案里就有一条存在问题。我做了三步整改。第一步放弃直接裸用基础模型接上领域知识库做 RAG同时对提示词进行了严格的引用约束。第二步用领域语料做了低秩适配微调训练重点是规范化输出格式和拒答行为而不是灌输知识。第三步搭建了基于事实核查和采样一致性的双层幻觉检测服务对模型的输出进行实时把关拦截。5.2 效果实测经过两周的迭代我们对三个阶段的版本都做了乱序测试每组 300 条问题。这三个版本分别是基础模型、加了 RAG 的版本、RAG微调检测的完整版本。结果如下指标基础模型RAG版本完整版本事实性准确率71%82%89%拒答率回答“不清楚”5%10%18%答案可追溯率0%68%74%明显幻觉占比25%11%6%这个表里的数据有几个值得注意的地方。加了 RAG 之后拒答率反而提高了这不是坏事——说明模型开始意识到“没有资料就不能硬答”。完整版本中明显幻觉占比降到了 6%剩余的错误集中出现在用户提供的专用名词、缩写拼写不规范等小众场景说明数据侧仍存在边缘盲区这类问题没法靠模型层彻底解决只能靠持续补充知识库。5.3 踩坑记录与经验沉淀整个改进过程踩了不少坑挑三个最典型的分享。第一个坑最初测试 RAG 时把检索段落数量设成了 6以为“上下文给得越多越好”。结果模型把多个不相关段落里的信息做了“缝合”反而产生了幻觉。后来把段落数量缩到了 3并加了“只引用与问题最相关的一段”的指令错误明显下降。第二个坑微调数据里加入了一批“带标准答案”的问题模型在微调后答题率大幅度提升的同时出现了“过度自信”问题。它对所有问题都倾向给出一个答案哪怕没有依据。后来我们在微调数据里专门增加了一批“无答案”样本告诉模型什么是“不知道”才算扭回来。第三个坑事实核查依赖外部检索时如果检索库本身数据质量差会把正确的答案标记成幻觉。我们在项目里花了很多精力清洗知识库、建立同义词映射然后才让核查服务上线。检测服务只有在知识库可靠的前提下才可信。6. 最后分享几个实用小技巧上面讲了这么多方法论最后分享几个可以直接抄作业的经验点。技巧一做知识库预处理的时候统一将文档按语义切块同时保留块与块之间的标题层级关系。每个块都附上来源标签、更新日期、所属分类这样在生成阶段可以强制模型输出来源便于用户溯源。溯源成本很低但对治理幻觉有奇效因为它倒逼模型“引用而不是胡编”。技巧二部署线上系统时对所有模型输出都做一遍“低置信度拦截”。我们内部的做法是当序列平均对数概率低于阈值时不直接输出给用户而是把回答降级为“我未能找到足够权威的资料请换个说法重试”或者触发人工客服介入。与其让用户看到错误答案不如让用户看到诚实的回应。技巧三每隔一段时间用“错误案例复盘会”的方式找几个线上典型幻觉样本让研发和标注团队一起定位出错环节。你会发现很多问题的根因不是单一模块而是检索召回错误、知识库信息过期、提示词指令含糊等多个环节叠加的结果。这种复盘比任何新算法都更帮你理解系统短板。幻觉问题不会消失但随着你对模型行为、数据质量、交互设计三者的理解加深它是可以被压到可接受范围的。我个人的体会是治理幻觉没有银弹但系统性工程手段一定比任何花哨的模型技巧都有效。先用评估体系把问题量化再用 RAG、微调、检测拦截逐层压实你就能在一个“会说错话”的模型上构建出可靠的产品。