幻觉这个话题做AI应用的人早晚都得正面硬刚。我这段时间集中处理了几个线上项目的“胡说八道”问题从客服机器人到内容生成工具都碰上了。说实话刚开始很头大因为幻觉不是偶发bug而是大模型这种“概率生成”机制的底层特性你没法用修代码的思路去修只能靠整套系统设计去围堵。这篇文章把我踩过的坑、试过有效的方法、还有踩完坑之后的反思原原本本写出来希望能给正在做AI落地的同行一些参考。1. 我把幻觉拆成了三类才真正看懂它1.1 幻觉不是“说错话”而是“一本正经地编”先给还不熟悉这个概念的读者说清楚所谓AI幻觉就是大模型生成了一段非常流畅、结构完整、听上去很有道理的内容但这段内容和事实对不上。比如问一个智能客服“你们支持哪些支付方式”它回答“我们支持现金付款”实际上这家电商平台早就只支持线上支付了。更麻烦的是当你追问“你确定吗”它会继续给出更多编造的细节比如“现金支付请在收货时交给配送员”越描越像真的。有个类比我一直觉得特别贴切大模型本质上是一个特别擅长“接龙”的玩家。它拿到你给的提示词之后做的事情是预测“下一个最合适的字词是什么”一路预测下去生成一整段内容。它根本没有“查证事实”这一步也没有“我知道自己不知道”的内置机制。这就好比一个记忆力超强但从不怀疑自己的朋友你问他任何事他都能说出一套完整的故事而且他真心相信自己说的是对的。1.2 三种常见的幻觉形态对应不同处理策略我把项目里遇到的幻觉问题分成了三类分类之后处理思路就清晰多了第一类是事实性幻觉。模型把事实信息搞错了比如把某个产品的上市时间说错、把API参数名字写错、把行业统计数据张冠李戴。这类幻觉最常见也相对容易治理因为它有明确的对错标准可以用外部知识库或工具去校验。第二类是逻辑性幻觉。模型生成的推理链条有问题比如数学计算错误、步骤顺序颠倒、结论和论据互相矛盾。这类问题靠RAG也很难完全解决因为外部知识未必能覆盖到推理过程本身更多要靠提示约束和推理框架来限制。第三类是编造性幻觉。模型直接捏造了不存在的实体或事件比如“根据某权威机构2024年发布的报告显示”但这个报告根本不存在比如“请联系田经理电话138xxxx”但这位经理和这个号码都是模型编的。编造性幻觉最危险因为你无从溯源也很容易误导用户做实际决策比如联系一个不存在的联系人。搞清楚了类别才能对症下药。接下来我分享一下这几年做幻觉治理总结出的几个层级方案。2. 幻觉治理的四个层级从提示工程到系统架构2.1 第一层提示词约束成本最低但别指望它根治先说提示词层面这是每个人最开始都会尝试的方式也是最容易产生“我好像解决了问题”错觉的方式。我常用的提示约束包括三个方向一是角色限定明确告诉模型“你是一名售后客服只回答与产品售后政策相关的问题”二是范围限定告诉它“如果问题超出你掌握的资料范围请直接回复‘该问题我无法确认’”三是格式限定强制它用结构化格式输出比如“请以JSON格式返回包含confidence_score字段”。实测下来这三招能让幻觉率下降一些主要原因是它减少了模型“自由发挥”的空间尤其是“不确定就拒绝回答”这条能把很多低置信度的生成截断。但它的局限性也很明显提示词只是引导不是硬性约束。你让模型“不要编造”它下次照样会编因为它根本没有自我校验能力。我见过一个团队在提示里写了200多字的安全约束结果测试的时候模型照样把竞品数据编得有模有样。所以请记住一个判断标准如果你的场景只允许绝对准确提示词方案撑不起这个要求。它适合当作第一道防线绝不能当作唯一防线。2.2 第二层检索增强生成RAG目前性价比最高的方案接下来是检索增强生成也就是常说的RAG。核心思路很简单既然模型本身没有可靠的知识来源那就给它接一个外部知识库让它在回答问题之前先去检索相关资料把检索到的内容当作参考依据再生成答案。我做一个完整的RAG流程通常包含四个环节第一步是知识库准备。把业务文档、FAQ、产品说明书等资料做切片处理每片控制在200到500字左右然后通过嵌入模型转换成向量存入向量数据库。切片大小很关键切太大了检索出来噪音多切太小了语义又不完整。我一般会用标题和段落结构作为天然切分边界再叠加固定长度效果比纯按字数切好不少。第二步是检索触发。用户提问过来之后先判断这个问题是否需要检索。像“你好”这种寒暄就没必要走RAG直接聊天就行。我常用的做法是让一个轻量模型做意图判断或者设定关键词规则能省掉不少无效检索的延迟开销。第三步是相关度排序。检索出来的候选片段不能一股脑全塞给大模型既浪费上下文空间又容易引入噪音。我一般会做两轮筛选先用向量相似度粗筛Top20再用重排模型精排到Top5。这个重排步骤对最终回答准确率的提升非常明显值得投入。第四步是注入与生成。将筛选出来的片段拼接进提示词明确告诉模型“请仅根据以下资料回答问题如果资料中没有相关信息请明确回复‘未找到相关信息’”。RAG这套方案的好处是知识可维护——业务信息变了更新知识库就行不用重新训练模型。但它也不是装了就能万事大吉如果文档本身质量差、切片策略不合理检索出来的内容驴唇不对马嘴模型照样会用这些错误材料“一本正经地编”。关于怎么排除这些问题我在第4章节会展开细说。2.3 第三层输出后验验证给答案装一道安检闸门如果你对准确率的要求更高比如金融、医疗、法律这类领域光靠RAG还不够得在模型生成完成之后加一道独立的验证环节。这一步我习惯叫它“后验验证”相当于给模型输出的内容装一个安检闸门。常用的后验验证手段有这么几种第一种是规则校验。针对结构化输出比如模型需要生成JSON数据那就用正则或者格式解析器核对字段是否完整、类型是否正确。生成SQL语句的可以直接拿到数据库里跑一遍EXPLAIN看能不能执行。第二种是交叉验证。同一个问题让模型以不同方式回答两次比如一次直接回答、一次带检索回答或者分别用两个不同模型生成答案然后再比较一致性。如果高度不一致说明答案可靠性存疑宁可告诉用户“暂时无法确认”。第三种是工具调用校验。让模型先把答案里的关键实体提取出来再去调用外部API校准。比如客服场景模型回答“您当前套餐内流量剩余2.3GB”这个数字不能只由模型说了算得让它去调用真正的计费系统接口拿到真实余额再回填。举个例子我做过一个合同审核的辅助工具。模型会从合同文本中抽取关键条款并给出风险提示但我们要求所有抽取出来的条款编号必须能在原合同里精确定位到原文定位不到的统统标记为“疑似幻觉”。就这一个规则把严重幻觉问题几乎清零了剩下的都是些措辞问题不影响决策。2.4 第四层模型侧优化治本但代价最大前面的方案都是在模型外围做文章管的是输入和输出。如果你想从源头降低模型本身产生幻觉的倾向就得动模型本身这属于“治本”路线但代价也最大。重点说一下模型微调。在垂直领域用几千条甚至几百条高质量数据做参数高效微调模型对特定业务场景的口吻和事实基准会有明显提升。比如一个做企业知识库问答的团队发现预训练模型在回答企业内部术语时经常混淆概念找了几百条标准问答对做了微调混淆率降了不少。但我必须提醒的是微调解决不了所有幻觉问题甚至可能引入新的幻觉。因为微调数据里如果存在互相矛盾的信息模型会把矛盾也“学会”。微调更适合用来校准风格和基本事实的表达方式真正动态的事实和百科类知识还是得靠RAG。还有一个思路是解码策略优化。简单说降低生成时的随机性把温度参数调低、使用更保守的采样方式模型的“发散性”会下降但代价是回答变得机械、缺乏创造力。这个策略在事实问答类场景可以适当用在创作类场景就别用了否则生成的内容会变得干巴巴的。这四层方案没有绝对的优劣实际项目里应当叠加使用。我自己习惯的做法是先用提示约束和RAG把基础准确率做上去再根据业务风险决定要不要加后验验证模型侧微调放到后期稳定阶段再做。接下来用我最近做的一个案例把这套思路串起来完整过一遍。3. 一次完整的幻觉处理实操某电商问答系统改造实录3.1 场景与问题定义先交代一下背景。这是一个模拟项目我管它叫“某电商平台的智能客服问答系统”核心功能是让用户用自然语言咨询订单、物流、退货政策和商品参数。系统上线第一周人工坐席收到的用户投诉里有相当比例指向同一个问题机器人给出的回答看起来规范得体但很多细节是错的。用户反馈集中在三处一是把退货政策说错了明明只支持七天无理由退货机器人说成了三十天二是把商品规格张冠李戴把A型号的屏幕尺寸安到了B型号头上三是凭空捏造客服电话给用户一个不存在的400号码诱导用户拨打后打不通体验极差。这个问题的严重等级很高因为客服回答是要让用户照着做决策的说错退货政策用户按错误信息寄回商品最后被拒收直接引发投诉升级。而且这类错误还不是固定重复的每个用户问到的错误都不一样你都没法提前写话术规避。我们定下的目标是在回答涉及订单、物流、退货、商品参数这几类高事实密度问题时事实性错误率降到可接受范围遇到知识库覆盖不到的问题模型必须老实承认“不知道”而不是硬编一个答案。3.2 检索管道搭建与关键参数选择明确了问题之后我第一件事是梳理知识来源。这个系统的知识库包含三个部分一是商品库含全部SKU的参数和图文描述二是售后政策文档含退货、换货、维修流程三是订单物流接口能实时查询真实状态。前两部分整理成静态知识文档第三部分作为实时工具接入。知识库切片时我踩了第一个坑。最初我用固定300字切分商品详情页一个段落可能就超过500字硬切之后一个完整规格表被拆成了好几段检索“屏幕尺寸”只召回一半内容答案自然残缺。后来改成按标题层级加固定长度的混合切片策略把每个参数表独立成片召回准确率立刻就上来了。向量化环节我选了中文场景下常用的嵌入模型。这里有一个经验产品级应用一定要做两轮检索第一轮用嵌入向量粗排第二轮用一个重排模型精排。一开始我图省事只做一轮就塞给大模型结果经常出现搜出来一段只跟问题沾边、核心信息缺失的内容大模型就抓着一句边角料开始发挥。加上重排之后Top5片段的相关性明显提升回答质量上了一个台阶。还有一个细节可能是很多人忽略的检索出的片段必须附带来源标识。每个片段入库时都带着文档ID和原文位置生成回答时我要求大模型在内部格式化输出里带上引用的来源ID这样后验验证能定位到具体是哪个文档为这句话提供了依据。没有来源支撑的句子被标记为“无据”系统会重新检索或者直接拒绝回答。3.3 提示词重设计把“不知道”变成系统能力RAG管道通了之后下一个关键动作是重写提示词。原来系统里的提示词只有一句废话“你是一个智能客服助手请友好地回答用户问题。”这种提示等于什么都没约束模型自然是放飞自我地回答。我重新设计了提示模板核心包含四个部分第一个部分是角色与任务边界明确模型是“电商售后问答助手”知识来源限定在提供的资料里。第二个部分是检索资料的呈现方式告诉模型每段资料都有标识回答时先引用资料再作答。第三个部分是拒答策略如果资料不足以回答必须回复“抱歉我暂时无法确认这个信息建议咨询人工客服”禁止生成猜测性回答。第四个部分是兜底指令对于计算题和时效性较强的问题告诉模型不要自行推理必须调用工具获取数据。这个重设计之后最直观的变化是模型的“拒答率”从不到1%上升到接近15%。一开始产品同事觉得拒答率太高是不是体验变差了但后来看用户评价发现用户对“坦诚说不知道”的接受度远高于对“一本正经胡说八道”的厌恶度。这个反直觉的现象我后面还会细说。提示词的措辞也需要不断打磨。最初我在提示里写“请根据上下文回答问题”模型经常忽略上下文直接调取预训练知识。我把措辞改成了“请仅凭检索资料回答检索资料中没有的信息默认视为不存在”效果立刻不一样。这不算玄学本质上是把模型的注意力更集中地锁定在组织好的资料上压缩它调用内部记忆的自由度。3.4 验证评估与量化结果系统改造过程中持续评估是必不可少的环节别等全部改完才想起测试。我搭了一套简易但有效的评估流程分成三个层面。第一个层面是黄金问答集。我手工整理了约五百条典型问题每一条都标注了标准答案和知识库内对应的源文档。改造前跑了一遍有近两成的回答存在事实性错误改造后跑了一遍错误率降到了个位数。这里面有个重要指标值得强调——引用准确率也就是回答里的关键事实有多少能正确定位到源文档。改造前这个数字很惨大部分回答都查不到出处改造后达到了九成以上。第二个层面是线上A/B测试。我们选了一部分流量走新系统一部分走旧系统观察用户投诉率和转人工率。新系统的转人工率确实有所上升因为模型开始学会承认自己不知道了但转人工之后的投诉率大幅下降用户从“机器人给错误答案”变成了“机器人建议我找人工”心情完全不同。第三个层面是负面案例复盘。所有用户反馈“回答不对”的对话都被单独存下来每周做一次复盘看错误的根因类型。这个环节虽然费时间但对系统迭代特别有价值——你会发现有些错误跟检索无关而是提示词措辞引发理解偏差有些错误是知识库本身内容有误模型忠实地复述了错误信息。根因不同解法完全不同。这套组合拳打完之后我再回头看最开始的问题突然意识到幻觉治理不是一次性的技术修补它更像给系统持续施加一个“事实约束力场”。具体做下来它的本质是建立一套流程体系让模型生成的内容从自由发挥变成有据可依。这个体系里最难的部分不是技术选型而是组织内部确立一条共识模型的流畅表达不等于可信输出系统的责任边界必须有人明确。4. 幻觉处理的常见问题与排查心得4.1 为什么我加了RAG模型还是胡说八道这是我在社区里被问得最多的问题。大部分人的第一反应是检索没做好但实际排查下来根因常常不止一个我总结了几类高频原因。第一类是知识库本身质量不合格。如果你喂进去的文档本身就有错误、前后矛盾或者已经过期模型只是诚实地复述了这些坏材料最后的效果当然是错的。知识库的维护者往往低估这件事的重要性以为随便丢几个PDF进去就完事了。我的做法是每个文档入库前做一轮人工抽检核对关键数字文档更新时保留版本记录出问题时能定位到具体哪个文档引错了。第二类是检索召回不足或相关度不高。向量检索不是万能的用户的问法和文档的写法往往是两套语言。比如用户问“这手机卡不卡”而文档里写的是“搭载八核处理器运行内存12GB”这两种表达在语义模型里可能有相关性但不够紧密。解决方案是扩充查询表述也就是对用户问题做改写生成多个角度的检索子查询然后合并召回结果。第三类是上下文堆太满。一些开发者为了让回答更稳把Top20的片段全部塞进提示词认为参考资料越多越好。结果模型被大量无关信息干扰反而更容易抓着某个边角料开始发挥。我一般限制在Top3到Top5宁可少而精也不要多而杂。第四类是模型自身能力边界问题。小模型的指令跟随能力和事实整合能力本来就不如大模型同样的提示和资料不同模型的表现差距很大。如果你的检索管道已经做得很规范但幻觉率还是高换一个更强的基础模型可能是最直接的解法。4.2 什么时候应该让模型说“不知道”很多人不敢让模型说“不知道”担心影响用户体验。我从几个项目的用户反馈数据分析来看这个担心实际上站不住脚。关键在于区分场景。在事实问答、客服、医疗健康、金融咨询这类场景用户的核心需求是准确。你给一个错误答案用户按错误信息行动后果可能很严重相比之下你说“我不确定”用户顶多觉得你能力有限但不会因此受到实际损失。我在客服场景观察到的结果是用户对坦诚承认不知道的机器人满意度反而更高因为至少它不会误导人。而在内容创作、头脑风暴、写文案做策划这类场景用户要的是发散和启发这时候模型“编造”一些合理但非事实的内容反而是有价值的。比如让AI帮忙想一个宣传活动方案它设计了一个虚构的成功案例作为参考这对创作没有危害反而能启发思路。这种幻觉就没必要治理甚至应该保留。所以做幻觉治理之前先想清楚自己的产品容错空间在哪里“零幻觉”不一定是对的但“该准的地方必须准”永远是底线。4.3 评估幻觉率你不能只靠“肉眼看看”还有一件特别容易被忽视的就是评估方式。很多团队在改进幻觉问题后拿十几条样例跑一遍感觉回答挺像那么回事就宣布搞定了。这种评估方式会骗人因为大模型的生成是随机的平均质量和极端情况要分开看。我的实践经验是把评估拆成两个维度平均质量和严重错误率。平均质量可以用黄金问答集跑分看log-prob或者让更强模型打分严重错误率则专门统计那些“误导用户做错误决策”的回答占比。后者才是要盯紧的核心指标因为它直接影响业务安全和用户信任。具体操作上我会在测试集里故意混入一些“知识库没有答案”的问题来测试模型会不会硬编。如果模型对于这些未知问题大部分都能拒答说明约束是有效的如果模型还在强行输出那就得回头查提示词和检索设计。这种“注入测试”虽然简单却特别好用。4.4 团队落地时的组织建议最后聊一个容易被技术团队忽略的问题幻觉治理的可持续性。这不是一个人做完就能一劳永逸的事知识库会变化、用户问法会变化、模型底座会升级幻觉问题会不断以新形态冒出来。我建议项目组设立一个**“事实安全”的常态化角色**这个角色既要有技术能力又要有业务判断力。每周做一次线上反馈复盘重点看那些被用户标记为“回答错误”的对话每月做一次知识库审查清理过期文档和错误数据每季度做一次全量评估确认幻觉率没有反弹。同时我强烈推荐在系统里建立完整的问题追踪日志。每条用户的负面反馈除了记录错误回答内容还要记录当时的检索片段、引用来源、模型版本、提示词版本。这样当幻觉问题出现时你能顺着日志一路追查到根因。没有这套日志体系所有问题都只能靠猜排查成本会翻好几倍。我自己在做这个系统复盘的时候最大的感触是幻觉治理真正考验的不是模型调优技巧而是你有没有建立一套能够持续发现错、定位错、修正错的工程机制。这比任何一个孤立的提示词技巧都重要得多。从实践角度来说我可以给你的最直接建议是先判断你的场景容错空间再确定治理投入力度。高风险场景把RAG、后验验证、拒答机制全部铺上宁可少答不能错答低风险创作场景适度放宽让模型保持发散能力。别一刀切地追求“零幻觉”那既不现实也没必要。最后再分享一个小技巧每次更新提示词或者检索策略之后固定保留一个“回归测试集”里面放一些最典型的易错问题每次调完系统先跑一遍这个测试集确认历史问题没有复发。我在实际项目中吃过亏改好了一个问题结果另一个老问题复现了就是这个动作帮我及时拦截住的。幻觉治理没有终点但做到“可控、可查、可回归”你就已经走在正确的路上了。