企业官网建设流程全解析

幻觉这个话题，做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、后验验证、拒答机制全部铺上，宁可少答不能错答；低风险创作场景，适度放宽，让模型保持发散能力。别一刀切地追求“零幻觉”，那既不现实也没必要。

最后再分享一个小技巧：每次更新提示词或者检索策略之后，固定保留一个“回归测试集”，里面放一些最典型的易错问题，每次调完系统先跑一遍这个测试集，确认历史问题没有复发。我在实际项目中吃过亏，改好了一个问题结果另一个老问题复现了，就是这个动作帮我及时拦截住的。幻觉治理没有终点，但做到“可控、可查、可回归”，你就已经走在正确的路上了。