★ FEATURED ARTICLE 你有没有遇到过这种情况问大模型一个问题它回给你一段逻辑严谨、语气笃定、专业名词满天飞的答案但只要拿关键细节去核实就发现人名是编的、数字是瞎凑的、引用来源也是对不上的。这就是大模型幻觉Hallucination圈内人管它叫“一本正经地胡说八道”。想根治这个问题过去两年被验证最有效、落地最快的方案就是RAGRetrieval-Augmented Generation检索增强生成。这篇文章不打算讲概念车轱辘话而是从原理、流程、参数到日常踩坑给想摆脱幻觉的开发者一份能直接照着调的实操手册。1. 先搞清楚前提大模型为什么会一本正经地胡说八道1.1 本质原因模型骨子里是个“概率猜词机器”很多人第一次接触大模型容易把它当成“会说话的知识库”。实际上主流大模型的底层逻辑更像一个高级版“猜词游戏”给定前文逐字预测下一个最可能出现的token词元。它并不知道自己“知道什么”或“不知道什么”只是在概率分布里采样出一串听起来合理的内容。训练过程决定了它有两个先天缺陷第一训练数据有截止时间拿不到当时之后的新信息第二模型用参数压缩训练语料本质上是“记了一个大概”细节会被模糊化、合并甚至扭曲。调用模型时如果你问了一个它没“记牢”的问题它不会老实说“我不会”而是会沿着语言惯性硬生生补出一段结构完整、语气自信的答案。这种补全在语义上往往非常流畅所以特别有欺骗性。说句不好听的模型最擅长的事情就是“用你没听过的内容、一本正经地骗你”。不信的话你随便问某一个封闭式模型“帮我回忆我上个月在某平台下单的订单号是多少”它大概率会编一个格式工整、但完全不存在的单号。这就是“猜词”机制在起作用跟“它太笨”是两回事。1.2 幻觉的类型远比想象中隐蔽光说“胡说八道”太笼统实际落地时幻觉大概分成四类事实捏造模型生成的人名、机构、日期、数值纯属虚构比如“某某论文在2023年证明了什么”但根本没有这篇论文。信息过时答案本身曾经正确但训练数据过期比如“目前某平台支持单笔转账限额50万”实际上规则早就改成了20万。推理错误模型把几个知识点捏在一起逻辑链条断裂。比如“A包含BB包含C所以A包含C”但在具体场景里并不成立。来源错配模型确实引用了一段上下文但它把张三的观点安到李四头上或者把某个时间点的政策说成了当前政策。这四类幻觉的危害差异很大。个人用大模型写代码、写文案幻觉顶多是多改几遍但在企业场景里幻觉可能直接导致客户投诉、错误决策甚至合规风险。例如客服机器人告诉用户“可以人工全额退款”实际上没有这个政策投研助手引用了一个不存在的监管文件可能导致用户做错误判断。这也是为什么越来越多团队宁可牺牲一点“话多”也要强制模型“先查再答”——这正是RAG要解决的核心问题。2. RAG的思路让模型学会“先翻书再回答”2.1 RAG和微调的区别闭卷考试与开卷考试要理解RAG最好用一场考试来类比。微调Fine-tuning相当于给模型继续“补课”把新知识强行灌进它的参数里本质上还是闭卷考试。你问它它从“大脑”里找答案找不到就只能编。RAG则相当于给模型一张允许带进考场的资料夹考试时先翻资料再根据资料写答案。具体来说RAG的完整链路是用户提问后先把问题拿去检索一个外部知识库可能是文档、数据库、网页找出与问题最相关的若干片段再把“问题 检索到的片段”一起交给大模型让模型基于这些片段生成回答。这样一来模型不用靠记忆硬扛事实细节只需要做好一件事理解检索到的上下文然后把答案组织出来。很多团队一上来就想用微调解决幻觉这是个经典误区。微调更适合改变模型的表达风格、输出格式或固定能力比如让模型学会用SQL回答表格问题但如果纯粹是“业务知识不够新、不够全”微调的成本很高而且效果不一定稳。你可以想象让一个学生背一本1000页的手册他背完也可能把第300页和第600页的知识点搞混但你让他考试时翻手册只要手册够清楚他就能给准确答案。对比维度RAG微调知识来源外部文档/数据库随时可更新写入模型参数更新要重新训练落地成本主要是检索链路建设GPU需求不高需要训练样本和训练算力事实准确性高答案可溯源到文档中取决于训练样本和模型容量时效性极好换文档即换知识差新知识要等新版本模型擅长场景知识库问答、企业文档、事实查询风格迁移、指令跟随、特殊输出格式2.2 RAG不是“检索一次就完事”现在已经有三种常见形态这几年RAG被玩出了很多花样但核心逃不开三种姿势第一种是朴素RAGNaive RAG。用户query进来直接经过向量检索从知识库召回top_k片段拼进Prompt里交给模型。优点是简单易懂适合刚起步或问题比较单一的场景缺点也很明显用户问法稍微口语化一点或者知识分散在多段文档里召回效果就崩。第二种是查询改写/多路召回RAG。它会在检索之前加一个“问题加工”环节用大模型把“今天天气怎么样我想知道要不要带伞”改写成“今日某地天气、降水概率、风力大小”或者同时做向量检索和关键词检索最后用排序算法融合。这个阶段可以用HyDE让模型先生成一个假设答案再用假设答案去检索也可以用子问题分解把“A公司去年的营收和员工人数是多少”拆成“A公司去年营收”和“A公司去年员工人数”两个检索任务。第三种是模块化/Agent式RAG。这种RAG把检索、重排、生成都变成可被大模型动态调用的模块。大模型先判断“这个问题需要检索吗检索哪几个来源”再执行检索、读答案如果发现不够就再检索一次。它对复杂问题的控场能力强但对链路稳定性要求也高因为不能每次都让模型乱试。我在实际调试中最大的感受是不要指望一个朴素RAG解决所有问题。绝大多数情况下你要先跑通朴素RAG再根据失败样本决定要不要加“查询改写”“混合检索”或“多轮检索”这些增强模块。3. 从零搭一个可落地的RAG流程、参数和操作细节3.1 知识库准备与切块策略切不好后面全白搭RAG的检索对象不是整本书而是“块”。在向量检索阶段系统会把文档切成若干小片段分别转成向量存进数据库。切块策略直接决定召回质量。切太大一个片段里塞了多个主题向量被平均化检索出来不痛不痒切太小片段缺少上下文模型拿到手也不一定能看懂。我建议从这几个维度去控制切块切块大小chunk_size中文场景经验值在256~512个token之间。如果文档结构非常清晰比如每段讲一个点可以放宽到600~800如果文档是连续的描述型文本256更安全。重叠窗口overlap相邻两个块之间建议保留20~50个token的重叠防止切块时把一句完整的话从中间截断。比如原文本是一个句子的后半段被切进了下一块模型读起来就会很割裂。切块方式不要只用固定字符数切优先按段落、标题、列表结构切。有一种做法是“递归切分”先按段落切段落太长再按句子切句子还太长再按固定长度切。举个例子。假设你有这样一段文档“2023年公司推出A计划。该计划覆盖三个城市分别是S市、T市、G市。S市已于5月启动试点T市预计6月……”如果用512个token固定切很可能把“该计划覆盖三个城市”和后面的具体列表切到两个块里导致用户问“三个城市是哪些”时只召回了一半。改用按语义段落切分先把“计划是什么”保留在一个完整块里问题就解决了。数据清洗同样不容忽视。知识库如果是从PDF抽来的会有大量页眉页脚、目录、水印和乱序文本。这些噪声一旦进入向量库检索时经常会“灵魂出窍”——明明用户问退货政策召回结果里全是“版权所有”“目录”这些垃圾片段。所以建库前必须做一遍简单的去噪声去掉页眉页脚、统一编码、识别表格结构。顺便提醒一句PDF抽取表格如果抽成一个矩形块向量化效果非常差建议对表格转成Markdown或HTML结构再入库。3.2 Embedding选型别只看公开榜单领域语料才是试金石切好块之后每个块需要被转成向量。Embedding模型的作用就是把“文本语义”映射到一个高维空间里让语义相近的句子距离更近。选Embedding模型时我建议关注四个点是否支持中文很多英文模型在中上表现尚可但处理中文口语、专有名词、长难句时会有一言难尽的表现。优先选中文语料充分训练的模型。输入序列上限有的模型最多只能编码512个token你的默认chunk_size设到600就会被迫截断。务必先确认上限再定切块大小。向量维度常见的有768、1024、1536等。高维度上限更强但存储和计算开销更大。如果知识库在百万级以下768~1024通常够用别为了“感觉更细腻”盲目上大维度。领域适配性通用领域的Embedding模型对法律、医疗、代码这类强专业词汇理解有限。建议用你的领域样本跑一个小规模“召回命中率对比”用数据说话而不是只看公开榜单。向量检索的距离度量一般用余弦相似度Cosine Similarity。它专注于夹角的差异对向量长度不敏感适合文本语义匹配。代码实现上就是把query向量和库里所有向量算一遍余弦相似度取最高的top_k个。这步听起来简单但知识库一上百万条暴力计算就扛不住了所以实际会用向量数据库或支持ANN索引的组件来做近似最近邻检索速度能快几个数量级。3.3 检索与重排召回百条不如精准三条很多初学者直接把召回的top_5拼接进Prompt效果却很差。核心问题是向量检索的“相关”不等于生成答案的“有用”。用户问“有哪些退货条件”召回结果里可能有5段都提到“退货”两个字但真正写清楚条件集合的只有其中1段。把5段全塞给模型模型反而容易被带偏。正确的做法是召回和精排分离。召回阶段预留足够候选比如每轮检索召回top_20~top_50然后交给一个重排Rerank模型对所有候选再做一次精细打分最终只取3~5个最相关的片段进入上下文。重排模型比向量模型更“聪明”它通常是一个交叉编码器会把query和每一个候选文档拼起来逐字判断相关性所以精度高但速度慢不适合对所有库直接跑只适合对第一轮召回的少量候选跑。如果暂时不想引入重排模型有一个低成本补救方案混合检索。向量检索擅长“语义相关”BM25这类关键词检索擅长“词面完全命中”。两者结果用RRFReciprocal Rank Fusion之类的简单算法融合能明显改善专有名词和代码类查询的召回。我对纯代码场景做过对比单独用向量检索很多包含特定变量名的上下文召回不到加入关键词召回后命中率一下子提高了不少。3.4 生成侧调教让“不确定就不答”变成系统级约束检索做得再好生成侧不约束模型照样会发挥想象力。系统Prompt里至少要写清楚三条规则只允许使用给定上下文中的信息作答不使用模型自身记忆补全。如果上下文中没有答案必须明确回复“根据现有文档无法回答”不要编造。回答中需要标注信息来源例如“根据《XX操作手册》第二章”。接着把上下文在Prompt里组织成清晰的字段建议给每一段加一个编号和来源标签。比如以下是检索到的资料片段 [1] 来源退货政策.md第3章第2节 [2] 来源售后常见问题.docx 你的任务只根据以上片段回答问题。这样模型在生成时更有可能在答案里写“根据退货政策消费者可以在签收后7天内申请退款”而不是从自己脑子里捞一个别的数字。我试过在几百个真实问答样本上做对比加了来源标签之后答案可溯源率明显上升用户也更愿意信任模型输出。另外把temperature调低一点通常建议0.1~0.3。温度太高模型倾向于自由发挥即使上下文里有正确答案也可能换一种“说得漂亮”的方式组织温度低模型更愿意紧密跟随上下文虽然会显得呆板但幻觉率会下降。你要的如果是一个可靠的知识库问答助手宁可呆不要飘。4. 实操中最容易踩的坑从上一节到下一节都是排雷现场4.1 检索命中率低问题往往出在“用户问法”上做客服问答时我见过最典型的一类翻车用户问“这个怎么退啊我昨天才买的”向量模型直接把它编码成“如何退货”的语义向量结果在文档库里匹配到的全是“退换货流程”之类的大标题段落没有匹配到“7天无理由退货条件”这一核心条款。检索命中率一低模型当然只能瞎编。解决思路是“先改问题再检索”。用一个轻量大模型或规则模块把口语化query改写成标准检索query。例如“这个怎么退啊我昨天才买的”可以改写为“如何进行退货操作 昨日购买 退货条件”。这种改写不需要模型很强大但效果提升非常明显。另一个思路是HyDE让大模型先基于当前问题生成一个“假设答案”拿这个答案去检索因为假设答案中的表述往往比用户原话更接近文档语言相似度匹配会准确很多。还有一类更隐蔽的问题query太复杂。比如“帮我对比A和B两个城市的补贴政策并告诉我在S市补贴是否包含租房补贴”这个query揉合了“对比”“筛选”“判断”多个意图直接整体检索大概率一个都抓不准。这种问题建议拆解成多个子查询分别检索后再合并上下文这也属于“查询改写”的进阶用法。4.2 召回了一堆“相关但没用”的片段噪音上下文比没有上下文更危险很多人以为召回数量越多越好于是把top_k设成10甚至20结果上下文里混杂了大量“看似相关、实则是泛泛而谈”的内容。比如用户问“逾期还款的违约金比例是多少”召回结果里可能包含“逾期还款会影响征信”这种句子。虽然相关但没有回答用户要的数字。模型面对这种前后矛盾的信息可能做出混乱的回答。处理这类问题有两道闸门。第一道是相关度阈值在向量检索或重排打分之后设置最低相关分低于阈值的片段直接丢掉哪怕候选数不到预期的top_k。第二道是重排排序按相关性从高到低排好后只截断前3~5个片段宁可上下文短也不要硬塞一堆噪声。实际测试中某些场景把top_k从10降到3答案准确率反而上升——因为上下文噪音少了模型更容易聚焦。如果阈值和重排都做了仍然经常召回无用片段就要回查Embedding模型的领域适应性问题。这时可以用一批领域样本做一次“query-正样本-负样本”微调让模型学会区分“触发退货话题的相关片段”和“真正说明退货规则的片段”。这也是我之前提到的通用Embedding模型在专业场景里经常不够用。4.3 上下文太长导致“中间迷失”离真相越近反而越容易答错即使检索质量很高长上下文本身也会带来新幻觉。Transformer的注意力机制有“Lost in the Middle”现象模型对上下文开头和结尾的内容感知较强对中间部分容易忽略。如果你把5段、每段800字的上下文一次性塞进Prompt模型很可能只盯着第一段和最后一段漏掉最核心的中间段落。控制策略有三个。第一压缩上下文块大小不要让单块超过500个token必要时对长块做抽取摘要后再入库。第二调整块顺序优先把重排分最高的段落放在Prompt靠前或靠后的位置。具体放哪儿要实测根据你用的模型不同位置的效果可能不一样。第三限制最终进入Prompt的片段数量不要贪多。我的经验是对于文档问答场景最终上下文总长控制在1500~2500个token之间是比较平衡的区间超过3000后答案准确率的下降经常能肉眼可见。4.4 上线前不做好评估调参全靠玄学RAG链路里能动的配置实在太多切块大小、重叠窗口、Embedding模型、检索方式、重排模型、top_k、阈值、Prompt、temperature。如果不建立一套评估体系你根本不知道改动一个参数是变好还是变差。最推荐的做法是建立“回归评测集”准备50~100个具有代表性的问题每个问题标注正确答案、最少需要的上下文片段ID、预期来源。每次改配置就在这套评测集上跑一遍记录三个核心指标召回命中率正确答案对应的片段是否出现在最终上下文里。生成准确率模型生成答案是否与参考答案一致或逻辑等价。幻觉率模型答案中是否出现与上下文矛盾、或上下文未提及的内容。人工逐条评估太慢可以先用大模型自动打分。具体做法是把“用户问题、模型答案、上下文片段”一起交给另一个大模型让它判断“答案是否严格基于上下文、是否存在推理跳跃”。但要注意“大模型法官”自身也有偏好所以自动评估只能筛出明显问题上线前仍然需要人工抽检一批。没有评估体系的RAG优化基本等于蒙眼开车。5. 什么时候RAG不够用边界、进阶与更稳的出路5.1 别迷信RAG有些场景它天生别扭RAG适合“知识库里的内容回答知识库里的问题”但如果你遇到三类场景就要谨慎评估。第一模型需要在固定模板下生成内容比如每周自动生成一份固定格式的销售周报。RAG负责检索本周数据但“周报格式”这件事用微调或Few-shot更有效。你说什么格式、用什么措辞RAG可能会钻到上下文里找不存在的格式要求。第二答案需要精确计算、跨多行表格聚合。比如“上个季度华南区所有门店的员工总数是多少”如果这些数据分散在很多张表格里RAG把整张表塞进上下文也容易出错。这种场景更适合用SQL查询、API调用等结构化工具。第三知识高度重叠、关系复杂。普通RAG把每段文档独立向量化检索时容易“只见树木不见森林”。比如问“哪些政策文件影响S市的补贴申请条件”答案可能横跨三个政策文件单靠向量检索很难同时召回所有关联信息。在这种情况下你需要考虑进阶方案。5.2 进阶方向Agent式RAG和GraphRAG帮你补短板进阶方向不外乎两条路。一条是Agent式RAG让大模型当调度员拆解问题、多次检索、自我反思。比如处理“对比A和B两个城市的补贴政策”这种问题Agent可以先把问题拆成“A城市政策”“B城市政策”“两者差异”分三次检索再汇总而不是一次性用整个query去撞运气。这种方案灵活但链路更长需要做好超时、失败重试和风险控制。另一条是GraphRAG。它在建库阶段不只有向量索引还会从文档中抽取实体如“S市”“补贴方案”“申请条件”和关系“属于”“要求”“调整”构建一张知识图谱。检索时不仅能找到语义相关的片段还能沿着关系路径找到隐藏关联。对于“哪些政策影响X”这类多跳问题GraphRAG的召回效果明显比纯向量RAG好。不过这两条路的开发成本都不低。如果你的知识库规模不大、问题以单点事实问答为主老老实实把朴素RAG的切块、检索、重排、评估打磨好效果收益反而是最高的。很多团队连朴素RAG都还没跑稳就上全套Agent编排最后只收获了排错地狱。工具不是越复杂越好能稳定解决业务问题的链路才是好链路。最后再分享一个我反复跟人强调的体会RAG要做到“不胡说”关键并不在某一个环节多厉害而在整条链路是否闭环。检索不准模型没东西可用上下文太杂模型又会学坏不设来源模型会自由发挥不评估你不知道下次改动是变好还是变坏。哪怕只用最简单的向量检索加一个高质量Prompt只要每次改动都有评测数据兜底效果也会比盲目堆一堆高级模块强得多。如果你正被大模型幻觉折磨我建议从今天开始用最小的知识库跑通一遍“切块-向量化-检索-生成-评估”再把top_k和上下文长度当成第一批调参对象。这条路不性感但真的能落地。
阅读完成 · 觉得有帮助？
