1. 幻觉到底是个什么“鬼”做LLM应用落地的同学应该都经历过这种场景你精心搭了一个行业知识问答机器人喂了几百份产品文档内测的时候问它“咱们最新版软件支持的并发数是多少”它一本正经地告诉你“支持5000并发是3.0版本新增的特性”。你翻了半天文档发现3.0版本压根不存在真实数据是800。这就是大模型幻觉——模型在生成内容时产出与事实不符、与上下文冲突或纯粹是凭空捏造的信息而且它说这些话的时候语气笃定得让人发慌。我做过的几个实际项目里幻觉问题出现频率相当高不是偶发而是“只要不问那些训练语料里反复出现的内容就大概率翻车”的程度。更麻烦的是幻觉的种类不只一种有的属于事实性错误比如把年份说错、把人名张冠李戴有的是推理逻辑漏洞比如两个条件互相矛盾还能自洽地往下编还有一类是“忠实性幻觉”也就是模型不遵循用户给出的指令或上下文自己去“自由发挥”。你如果不做专门的检测和压制这些问题会在生产环境里把你坑得怀疑人生。这篇是“AI实践”系列的第四篇我把幻觉处理当成一个独立工程问题来拆解。整篇文章不会只讲概念会把我实际用过的检测流程、抑制方案、调参记录、踩坑清单全部列出来。适合正在做RAG问答、智能客服、知识库机器人或者任何“模型输出需要可验证、可追溯”场景的开发者参考。如果你还在MVP阶段模型答错一两次无所谓那这篇文章的很多内容可以先存着等你被用户投诉“AI又在乱说”的时候再回来看也不迟。2. 幻觉是怎么被“逼”出来的2.1 两类幻觉要分开看我给幻觉分类的方法很简单先问“错的哪里”。如果模型把“某厂商发布了A型号芯片”说成“发布B型号芯片”这叫事实性幻觉也就是它输出内容和客观现实不符。如果用户问了A问题模型答了B问题或者用户要求只在给定文档范围内回答模型却去引用文档之外的信息这叫忠实性幻觉它不代表知识错了而是模型没有遵循约束。为什么要分这么细因为处理手段完全不同。事实性幻觉的克制办法主要是给更多可靠上下文、压缩模型自由发挥空间靠RAG和证据绑定来解决。忠实性幻觉则更多依赖指令约束、解码策略调整和“不知道该说不知道”的拒答训练。你把它们混在一个池子里调往往会顾此失彼。2.2 幻觉的真正来源从根上拆幻觉至少来自四个层面。第一是预训练数据的天然缺陷。模型在预训练阶段看过海量文本但文本里本身就充满错误、过时、互相矛盾的信息。模型学到了那些“高频但错误”的模式生成时自然偏向高频词而不是真相。比如你问它“历史上某个冷门事件的日期”它如果只见过两篇自相矛盾的帖子就可能挑一个信誓旦旦地说出来。第二是解码阶段的随机性。模型不是查数据库它是在逐词预测概率分布。温度调高、采样策略激进时低概率但“听起来合理”的token就会被选中累积起来就是一个完整但虚构的句子。第三是注意力机制的长程遗忘。Transformer的注意力是有限的当上下文很长比如塞了10份文档、每份几千字模型往往会聚焦在某些高亮区域而忽略其他部分。这是我做过一个典型案例给模型一份包含新旧两版参数的文档它回答问题时只看到新版参数直接忽略了旧版兼容性说明输出了错误的解决方案。第四是对齐训练的副作用。为了让模型更“有用”指令微调和RLHF阶段往往鼓励模型尽量回答问题而不是承认自己不知道。这种“宁可编一个答案也别冷场”的导向从底层强化了幻觉倾向。3. 幻觉检测的实操方法先知道怎么判定再谈怎么修3.1 先定义“什么算答错了”在着手抑制幻觉之前必须先有一套判定标准否则你调了半天也不知道效果是变好还是变差。我通常定义四类错误实体级错误答案中出现了外部证据中不存在的人名、地名、产品名、参数名。数值级错误数字、日期、百分比与证据明显不一致。逻辑级错误回答内部有矛盾或者与给定上下文的约束冲突。范围级错误模型回答了超出上下文范围的内容尤其是用户没要求的内容。为方便讨论我把它们统称为“幻觉错误”。注意一个细节实体、数值这一类可以通过程序自动比对而逻辑、范围这一类通常需要人工判断。所以检测流程最好是“机器初筛人工复核”的组合而不是纯粹靠人眼一条条看。3.2 四类检测手段的实测对比我实际用过的检测手段主要有四种。第一种是打分评测法也是最基础的做法。构建一个至少200条问题的小型评测集覆盖正常问答、有干扰项的问答、无答案的问答然后设定几个维度比如“信息正确性”、“上下文忠实性”、“信息完整性”。让评测人员打分或者用更强的模型来打分。优点是直观缺点是成本高、评判标准可能不稳定。第二种是语义熵法。同一个问题采样多次当多次输出内容高度不一致时往往说明模型没有可靠依据正在“自由创作”。可以用一个简单指标来量化检测采样N次计算两两之间的语义相似度平均相似度低就标记为疑似幻觉。这个方法实现成本很低适合在测试阶段大规模跑帮我筛出高危问题。第三种是证据比对法。先让模型生成答案再从答案中抽取关键实体、数字然后用这些关键词去检索本地知识库看看能不能找到对应证据。如果找不到或者找到的证据与答案冲突就标记为幻觉。我在RAG场景下用的就是这种思路配合向量检索和正则抽取能做到半自动检测。第四种是人工核查法。这个方法看起来“笨”但在项目初期不可替代。一个懂业务的运营同学花一个下午人工检查200条回答测出来的问题比任何自动化工具都准。大家先别急着追求全自动化很多团队的幻觉问题不是检测工具不够先进而是连“什么是对的”都没定义清楚。3.3 我常用的评测流程模板我的固定流程是四步构建评测集100条普通问题、50条模糊问题、50条明确无答案问题。用流式批量脚本调模型收集回答并保存为结构化记录。跑语义熵检测筛出前30个可疑样本。人工复核可疑样本同时抽检20%的正常样本。这个流程跑下来基本上能对一个问答系统的幻觉水平建立量化认知。做完一轮评测你就有依据判断下一步优化方向是补数据、调提示词、加检索还是换模型。4. 抑制幻觉的组合拳不是只靠一个招单靠一个手段解决幻觉是不现实的我自己的经验是要把“外部知识引入、模型行为约束、系统兜底设计”三方面一起上效果才稳定。4.1 检索增强RAG怎么做才不会“越帮越忙”RAG是目前工程上抑制事实性幻觉最有效的手段。但切记RAG不是一个“开箱即用”的功能做不好反而会加重幻觉。原因很简单塞给模型的片段越多模型注意力越分散越可能抓着一句话就自由发挥。我在项目中采用的参数和流程供你参考文档切分一个chunk控制在300~800字不要贪大。一个chunk太大时检索命中后模型会倾向于“覆盖全部信息”反而容易产生矛盾。检索策略只用向量检索不够建议混合检索结合关键词匹配。原因是向量检索在处理精确技术名词、型号、编号时经常失手关键词能把这一环补上。检索阈值设置相似度下限低于0.7的检索结果直接丢弃宁可让模型说“找不到”。这一步能显著降低凭空引用的概率。上下文组装只把检索到的前2~3个chunk拼进提示词同时按相关性倒序排列最相关的内容放最靠近回答的位置。引用溯源要求模型在回答中标记出处比如“根据文档[1]”。即使内容没错这个动作本身也能让模型更加遵循给定内容减少自由发挥。下面是一段简化但可以直接跑通思路的伪代码展示了检索、阈值判断、组装提示词的过程import numpy as np # 假设 embed_fn 是文本嵌入函数vector_search 是向量检索函数 query B产品支持的最大并发数 query_vec embed_fn(query) # 参数1: 检索数量 top_k 5 # 参数2: 相似度阈值低于阈值直接丢弃 min_score 0.7 results vector_search(query_vec, top_ktop_k) valid_chunks [] for chunk, score in results: if score min_score: valid_chunks.append(chunk) if not valid_chunks: answer 当前提供的资料中未找到与该问题相关的信息建议查看产品规格说明书。 else: # 参数3: 最多带入上下文的chunk数量 max_context_chunks 3 chunks_sorted sorted(valid_chunks, keylambda x: x[1], reverseTrue)[:max_context_chunks] context \n.join([f[文档{i1}]{c[0]} for i, c in enumerate(chunks_sorted)]) prompt f仅根据以下资料回答问题若资料中无相关内容请明确回答未找到相关信息。\n\n资料:\n{context}\n\n问题: {query} answer call_llm(prompt) print(answer)注意一个容易被忽略的点就算做了RAG也不是所有问题都适合走检索。像“帮我写一段营销文案”这种开放生成任务本来就不该伪装成知识问答硬套RAG反而会限制生成质量。实践中我把问题先分成“封闭式知识问答”和“开放式生成任务”前者走RAG后者不做证据约束。4.2 解码策略与提示词的“软约束”RAG解决了“没有证据”的问题但模型还是可能不老实。剩下要做的就是调整解码策略和提示词。在知识问答场景里我一般把温度调到0.1到0.3之间。温度过高会增大低概率token的采样机会幻觉率跟着飙升。如果同一个问题需要多次回答并做投票温度稍微高一点0.3~0.5反而有助于暴露分歧但那是自一致性方案不是单次问答场景。提示词层面有几句话效果立竿见影“如果你不确定答案请直接说‘不确定’不要猜测。”“仅基于以上提供的资料回答问题不要使用外部知识。”“当资料中没有明确说明时请回答‘资料未提及’。”这三句是我在多个模型上测过的能把忠实性错误率压低一大截。原因很简单模型在训练时学习过“不知道就承认”的对话模式只是平时没有触发你在提示词里给了这个触发信号。还有一个进阶技巧是给模型提供“拒答样例”。我在提示词里附加一条“你不知道答案时的回答模板”比如“抱歉根据现有资料我无法确认XX信息建议查阅YY文档或联系相关支持人员”。模型会模仿这个格式减少生硬编造。4.3 系统层的置信度验证与兜底提示词和RAG都不是银弹。在真正面向用户的生产系统里建议加一个验证后置模块对生成答案进行二次校验。这块可以用点规则来实现成本低、效果好实体核对抽取答案中的产品名、型号、人名与检索到的chunk做包含匹配不匹配则标记存疑。数字核对用正则抽取所有数字如果某个数字不在检索chunk中出现提示审核。自一致性校验同一个问题调用模型2~3次如果答案存在矛盾返回低置信度提示或转人工。这一套“软硬结合”的方案跑下来在我参与的实际项目里回答问题本身的幻觉率明显下降虽然还做不到100%消除但已经把生产事故砍掉了大半。我的判断是幻觉不可能清零工程目标应该设定为“将幻觉控制在可接受范围并且保证幻觉发生时系统可以发现、转人工或降级”。5. 实战记录某内部知识问答机器人从翻车到基本稳住5.1 初始方案与翻车现场前阵子我帮某团队优化一个内部知识问答机器人。这个机器人接入了产品文档、技术博客和客户反馈记录基础方案就是最朴素的“文档切分向量检索LLM回答”。第一轮测试直接翻车。测试集里有一条“A服务在什么情况下会返回504错误”知识库里有一篇文档明确写了“当后端响应时间超过5秒网关会返回504”还有另一篇提到“配置了重试机制后客户端最多等待8秒”。模型给出的回答是“当客户端配置了重试等待时间达到8秒时会返回504”这明显是错误合并了两篇文档把不同场景搅在一起了。5.2 三轮优化的完整过程第一轮优化调整检索和上下文策略。把chunk从1000字缩小到500字左右设置相似度阈值0.7上下文只保留相关性最高的3个chunk。采用这套方案后同一测试集上的“事实性错误”从大约32%降到了17%。效果有但不够。第二轮优化重点解决“忠实性”问题。提示词里加了“只基于资料回答”同时要求模型在不确定时输出“未找到相关信息”。这一轮跑完整体的幻觉错误率又下降了一些关键是不再“硬编”了。最明显的例子有一个比较偏门的问题知识库里确实没有答案优化前模型会编一个“根据XX文档推测是……”优化后它老实说“当前资料中未找到对X问题的说明”。第三轮优化加入置信度验证。用实体核对数字核对文本相似度校验三层规则给每个回答打“置信度”标签。低置信度回答在页面上主动展示“仅供参考请核实原始资料”的提示。这不能减少幻觉但能把“幻觉被用户当真”的概率降了下来。实际效果是用户在对话后点击“确认引用原文”的比例变高了侧面说明可信度在提升。5.3 优化数据对比测试项目初始方案第一轮优化后第二轮优化后第三轮优化后含提示事实性错误率32%17%9.5%8.1%忠实性错误率26%14%6.8%6.2%拒答率无答案问题时主动说不知道4%7%21%23%看得出来第三轮之后主要变化集中在置信度提示而不是错误率本身因为它改变的是用户面对幻觉时的“处理方式”。这里也给大家提个醒评估系统时别只盯着错误率一个数拒答率、召回率、用户对提示的信任度都很重要。6. 避坑清单、排查手册与我的心得6.1 排查思路从现象反推原因如果你发现你的模型频繁出现幻觉先别急着改提示词。我建议按这个顺序排查先看检索质量把问题拿去检索看看返回的chunk是不是有效的。如果检索到的文档跟问题驴唇不对马嘴后面无论怎么优化提示词都没用。再看上下文长度chunk数量是不是太多了如果塞了5个以上chunk模型更可能被不相关的信息带偏。再看解码参数温度是不是调太高了sample数量、Top-P这些参数有没有放宽参数放宽会导致输出发散。再试提示词强度否定式指令比肯定式指令更有效“不要编造”比“请遵守事实”更有约束力。最后看模型本身能力。有些场景是模型推理能力不够比如需要多步推理才能得出结论的事实性问题这时候靠提示词无法弥补要么换更强的模型要么把问题拆分得更简单。6.2 高频问题速查表现象可能原因处理方案答案能自圆其说但完全是编造知识库中缺少相关内容设置检索阈值低于阈值的直接拒答多个来源信息互相矛盾上下文塞入过多chunk减少chunk数量按相关性截断数字不准差得不多模型在“四舍五入式”模糊记忆对数字型回答强制引用原文片段用户问题超出知识库范围没有设定“不知道”的退路添加拒答模板提供转人工入口同一个问题不同时间答案不一致解码随机性过强降低temperature或多次采样取多数答案长文档回答丢失靠后的细节注意力失效相关段落重排到靠前位置或压缩单文档长度这里面最容易被忽视的是“检索结果相关性与幻觉的关系”。我实测过检索得分在0.75~0.85之间的chunk最容易出幻觉分数不够高说明相关性不足但模型看到“有点像”的内容就容易顺着编。低于0.7的chunk进了上下文更像是给幻觉提供了“素材”。6.3 项目后续扩展与个人体会幻觉处理不是一次性的工作模型升级、知识库变化、用户问题分布变化都会让幻觉水平漂移。我的建议是把评测集和检测流水线固化下来每个月跑一次回归知识库更新时重点考察与新增内容相关的问题是否引入新幻觉。根据我个人实际操作的经验最后再分享两个比较难想到的细节一是拒答并不丢人。很多做产品的人怕模型说“不知道”会被用户打差评于是强制要求模型必须给出回答。这个大可不必经过实测在知识库没有明确答案时主动承认“资料不足”用户的不满程度远低于得到一个看似专业但错误的答案。二是把“证据”展示给用户会反向约束模型。当UI上把引用的原文片段展示出来模型生成时会更倾向于贴近证据因为提示词里通常会说“回答需要匹配引用来源”。这在产品层是个非常划算的增强手段而且对用户信任度提升很有帮助。幻觉问题做到现在结论其实很简单你不可能让模型不犯错但你可以让模型在犯错之前先想一想犯错发生后尽快被发现以及让用户知道这个回答有多大把握。把这三点做到位幻觉就从“随时会爆的雷”变成了“可控的噪声”。哪天真有大模型能在“事实性”上做到100%可靠我再回来把这篇文章推翻重写。