你大概率遇到过这种情况：问一个AI助手产品问题，回答的头头是道，结果照着操作发现完全对不上。上个月我就在某智能客服系统里抓到一条典型case——用户问“报销单提交后多久能到账”，模型引用了《差旅报销管理办法》里的打款周期，理由是“两者都有报销两个字”。回答结构完整、语气笃定，但错得离谱。这就是大语言模型幻觉的真实形态：模型不是没有知识，而是把记忆里似是而非的片段拼装成了一个极具说服力的结论。
RAG（检索增强生成）正是围绕这个痛点诞生的技术路线：与其让模型凭内部参数“猜”答案，不如先把检索到的可靠资料放到它眼前，再让它照着资料作答。这篇文章不聊抽象概念，我会从一条真实的幻觉case出发，把RAG从文档清洗、切片、向量召回、重排序到生成约束、效果评测的完整链路拆开讲，标注清楚每一步为什么这样做、踩过哪些坑。适合正在做知识库问答、企业智能助手、文档解析类项目的工程师，也适合还在评估RAG可行性的技术负责人。
1. 幻觉为什么盯上大语言模型：问题本质与RAG的生态位
1.1 一次线上事故还原：当模型把两套制度拼接在一起
我接手的某企业内部知识库问答系统，上线两个月，满意度不升反降。最扎眼的用户反馈就是开头那条报销问题——用户想知道日常费用报销的到账时间，系统却在引用《差旅报销管理办法》。如果只是“回答不准确”，用户顶多骂两句；但它给出的打款周期恰好又是差旅场景的真实规则，语气笃定、格式完整，用户差点把错误的流程当成正式制度去推进，这就不是体验问题，而是业务风险了。
我拉日志追了一遍链路，真相藏在检索环节里。用户的问法触发了向量召回，候选块里既有《差旅报销管理办法》的条款，也有《费用报销流程指引》的段落。但后者因为原始PDF里表格跨页、切块时被拦腰截断，语义不完整，排在候选列表的很后面，最后进入生成上下文的只剩差旅报销那几块。模型看到的是“报销”相关的局部材料，又没被明确告知“只能基于材料回答”，于是它动用了内部记忆里关于报销打款的先验知识来补全，最终产出了这份张冠李戴的答案。
这个case给我最大的提醒是：我们总把幻觉归罪于模型爱胡说，实际生产环境里，一半以上的幻觉是链路设计问题——召回漏掉了关键材料，生成阶段又缺乏约束，模型只能靠猜。RAG的价值从来不是“让模型更聪明”，而是把“只靠记忆作答”改成“先看材料再作答”，从机制上降低自由发挥的空间。
1.2 幻觉的三层形态：每一层都要单独防控
做RAG项目久了，我发现把幻觉笼统称为“胡说八道”没法指导优化。按根因可以拆成三层：
| 幻觉类型 | 典型表现 | 主要根因 | 工程防线 |
|---|---|---|---|
| 事实性幻觉 | 把A制度的规则安到B制度头上 | 召回错误、上下文片段缺失 | 高质量分块、混合检索、引用校验 |
| 相关性幻觉 | 回答在话题内但答非所问 | 查询意图理解粗糙、候选块不精准 | 查询改写、重排序、元数据过滤 |
| 逻辑性幻觉 | 模型自行脑补出原文没有的因果关系 | 生成阶段约束不足 | 强提示词约束、知识边界声明、拒答兜底 |
事实性幻觉最常见，也最好定位——多半是召回链路的问题；相关性幻觉通常在意图识别和排序阶段就能拦下一部分；逻辑性幻觉最隐蔽，因为模型生成的句子在语法上无懈可击，只能靠生成阶段的硬规则去压制。我后面会按这三层给出对应的工程解法，但先记住一个结论：RAG优化不是调一个环节，而是整条链路的协同。
1.3 微调为什么治不了根，RAG架构为什么能
经常有团队问：直接微调不行吗？把企业文档喂给模型再微调一遍，不就记住了吗？这个思路在早期项目里确实常见，但落地时会碰到两个根本问题。
第一个是知识的时效性。企业的规章制度、产品参数、客服话术是持续变化的，微调一次要整理数据、清洗标注、训练、评测、灰度上线，一套流程走下来至少两到三周。制度三个月改一版，微调团队就成了永远在补课的救火队。第二个是精确性。微调改变的是模型的参数分布，让模型“更熟悉”这批语料的风格，但它不保证模型在回答具体事实问题时逐字逐句引用原始条款。参数化记忆本身就是模糊的，遇到的边界情况越多，出错概率越高。
RAG的思路完全不同：知识存在外部索引里，模型参数不动。文档更新时只需要对索引做增量维护，几十分钟就能完成，而且回答时模型是“看着材料说话”，引用路径可追溯。我常跟人打比方：微调是让学生把课本背下来再考试，RAG是开卷考，允许学生边翻书边答题。开卷考的翻书速度、翻到哪一页，就是检索链路要解决的问题。
1.4 RAG的演进：从Naive到Modular，先选好基线再谈优化
RAG不是一种固定实现，它有一条演进脉络。Naive RAG是最朴素的“检索→拼接→生成”三段式，适合验证可行性和搭基线；Advanced RAG在前后端加了查询改写、重排序、递归检索等环节，是目前企业落地的主流形态；Modular RAG把检索、记忆、生成、验证等拆成独立模块灵活组合，像Self-RAG、GraphRAG都属于这个方向。
我不建议团队一上来就奔着最复杂的形态去。GraphRAG听起来很酷，但图谱构建的工程量和维护成本都不低，对于大部分以“制度问答、产品手册问答”为核心场景的团队，先把Advanced RAG的几个关键点做好，效果就能超过市面上大多数Demo。这篇文章后面展开的，也主要是Advanced RAG这条主线的工程细节。
2. 召回质量的地基：文档清洗、分块策略与元数据设计
2.1 脏数据是第一批幻觉源头：PDF解析与表格结构保留
很多人以为RAG的起点是“向量化”，实际上起点是文档解析。企业知识库里大量文档是PDF格式，而PDF的解析往往比想象中脏得多。扫描件PDF没有文字层，必须先OCR；文字型PDF也可能存在页眉页脚混入正文、目录页残留、多栏排版错乱的问题；最头疼的是表格，跨页后列与行的对应关系被彻底拆散，纯文本提取出来的内容，人和模型都很难还原原意。
我的习惯是在解析后做一轮逐页抽检，随机抽10%页数人工核对。如果OCR乱码率高于某个阈值，优先联系原始编辑文件重新导出，不要指望后处理能救回所有坏字符。表格部分尽量转成Markdown或JSON结构化形式，因为报销金额、产品型号、参数对照这类信息一旦丢失列对应关系，模型就只能靠猜，而这正是事实性幻觉的高发区。这一环节枯燥，但决定了整个知识库的地基质量，值得多花时间。
2.2 分块参数不是玄学：chunk_size与overlap的真实取舍
分块策略直接决定召回单元是否“语义完整”。固定长度分块是最省事的方案，但参数不能拍脑袋。我常用的一组基线是：FAQ、条款类内容用512 token左右，每块聚焦单一语义；制度章节、技术手册这类需要跨段对比的内容用1024-2048 token，保证上下文连贯。重叠窗口（overlap）一般取10%-20%，防止跨块实体被拦腰切断，比如“报销单提交后”和“5个工作日内到账”被分到两块，检索时只命中前半句，答案就缺了关键信息。
但重叠不是免费的，它会把重复文本塞进多个块，增加索引体积和生成阶段的token开销。更推荐的做法是语义切块：按标题、段落边界来切，而不是机械地按固定token数切。比如劳动合同按“第X条”切，制度文件按小节切，技术手册按“标题+正文”切。不同文档类型用不同的切块配置，才是生产级做法。我实测过的一个例子：《员工手册》的“休假制度”整章作为一个大块，当用户问年假和事假能否连休时，模型能看到全局规则，回答的准确性明显优于把它切成七八小段的方案。
2.3 父子块结构：让模型看得全、引得准
分块总会在“粒度细”和“上下文全”之间打架。块太小，召回精度高但缺乏语境；块太大，上下文全但检索噪声大。兼顾两者的工程方案是父子块结构：检索时使用较小的“子块”提高命中率，构建生成上下文时把子块所属的“父块”整体送入模型。
举个例子，一份制度文件按章节切成父块，再按段落切成子块。用户的提问命中了某个子块，但生成阶段拿到的是整个父块内容，模型既能精确定位到相关段落，又能看到章节层面的完整语境。我在项目里验证过，仅增加父子块这一层，答案准确率和引用完整度就有肉眼可见的提升。实现上也不复杂，给每个子块记录父块ID，召回后做一次ID映射即可。
2.4 元数据挂载：页码、章节、更新时间一个都不能少
给每个块挂载文档标题、章节路径、页码、更新时间，很多人觉得这只是为了展示引用来源，好看而已。实际上元数据在检索阶段就能发挥大作用：可以做元数据过滤，比如“只检索2024年之后更新的制度”“只在某产品线的文档范围内搜索”。对大型知识库来说，这是抑制跨域污染最有效的手段之一。
举一个我踩过的坑：某团队的知识库里同时存在新旧两代产品的操作手册，用户问新产品的某项功能，向量召回却把老产品的手册排到了前面，因为两代产品的手册在语义和结构上高度相似。后来加上“产品线+版本号”的元数据过滤，跨代污染立刻下降。元数据还能支撑后面的引用溯源，所以分块阶段就要把来源信息完整记录，不要等到上线后补课。
3. 检索不止Embedding：混合召回与重排序的工程组合
3.1 向量检索解决“语义相似”，却栽在精确匹配上
Embedding模型擅长语义召回，这是它的核心价值。“工资什么时候发”和“薪酬发放日”在语义上是同一件事，纯关键词匹配会漏掉这种改写，向量检索则能稳定命中。但向量检索有一个明显的盲区：对精确信息不敏感。型号“Model-X2000”和“Model-X3000”在向量空间里的距离可能非常近，金额“5000元”和“50000元”的向量差距也没有想象中那么大。
企业知识库恰恰充满了这类精确条件：产品型号、合同编号、金额、日期。我见过一个开发者排查了很久的case——用户搜索“X3000型传感器量程”，向量召回返回的候选里几乎全是X2000型的资料，因为两者属于同一系列、文档结构相似，向量距离极近。这种问题靠“换一个更强的Embedding模型”很难根治，因为它不是语义理解的问题，而是精确匹配的机制缺失。
3.2 BM25与向量召回的混合：RRF分数融合怎么做
解决精确匹配问题，就要把传统的关键词召回拉回来。BM25在短文本关键词匹配上依然很能打，尤其擅长处理专有名词、编号、数字组合。所以生产级RAG系统通常不是“二选一”，而是并行跑两路：一路BM25，一路向量检索，各自取Top 30到50个候选，再做分数融合。
不同召回源产生的分数不在同一个量纲上，直接相加没有意义。我首推RRF（Reciprocal Rank Fusion）融合法：对每个文档，按它在各个召回列表中的名次取倒数求和，名次越靠前贡献越大。这个方法实现简单、参数少、鲁棒性好。伪代码如下：
def rrf_score(rank, k=60): return 1.0 / (k + rank) # 假设有两个召回列表：bm25_hits 和 vector_hits # 每个元素是 (doc_id, rank_index) scores = {} for doc_id, rank in bm25_hits + vector_hits: scores[doc_id] = scores.get(doc_id, 0) + rrf_score(rank) # 按 scores 降序取 TopN 进入下一阶段RRF的核心思想是“多个召回源都排在前面”的文档更值得信任，它不需要校准不同模型的分数量纲，换Embedding模型也不用重新调融合权重，省心。
3.3 重排序的真正作用：把预算花在刀刃上
粗召回阶段的使命是“别漏”，所以候选池越大越好。但多召回意味着大量无关块也混了进来，直接全部塞进大模型上下文，既浪费token，又稀释注意力——模型看到一堆杂讯，幻觉概率反而升高。所以需要一个更强的排序模型来负责“精排”：对粗召回的候选重新打分，只保留最相关的Top 5到8块进入生成阶段。
重排序模型通常比Embedding模型更大、更贵，但它在线的收益非常直接：候选从100压到5，生成阶段的上下文质量大幅提升。我建议团队至少做一次三档对比——不做rerank、用轻量级rerank模型、用更强的大模型评分——根据延迟预算和效果差异做决策。延迟敏感的场景里，一个几百毫秒的rerank模型如果换来明显的幻觉率下降，这笔账是划算的。
3.4 多路召回结果的合并：取并集还是交集
另一个容易被忽略的决策：BM25和向量召回的候选，合并时取并集还是交集？取并集召回率高，但垃圾块也多；取交集精度高，但两路都命中的情况实际没有想象中那么多，容易漏掉正确答案。我个人的习惯是取并集，把过滤和排序的任务交给重排序去完成。召回阶段的目标是保证召回率，排序阶段才是提升精度的主战场，各司其职，不要提前做激进的过滤。
4. 生成阶段的硬约束：提示词、引用溯源与拒答策略
4.1 提示词里的三条硬规则：写法与为什么管用
检索做得再好，生成阶段没有约束，幻觉依然会抬头。我在生产环境里用的提示词模板里固定包含三条硬规则，几乎适用于所有RAG场景：
你是企业知识库助手。请严格遵循以下规则： 1. 只能使用参考材料中的信息回答，不要使用模型内部记忆中的知识； 2. 如果参考材料无法回答问题，请明确回答“资料库中未找到相关信息”； 3. 回答时按句子标注引用编号，例如[1][2]，引用的内容必须确实来自对应编号的材料； 4. 不要将多个来源的信息拼接成一个新结论，除非参考材料中明确存在这种关联； 5. 如果不同材料之间存在矛盾，请指出矛盾之处，不要自行调和。很多人觉得提示词写得再明白，模型也不一定遵守。实测下来，规则越具体，模型的违规率越低。“只能使用参考材料”这一条把回答空间强制约束在检索结果内；“按句子标注引用编号”迫使模型在生成时不断回头核对材料；“指出矛盾而非调和矛盾”则防止模型为了给出“漂亮答案”而强行缝合矛盾信息。提示词约束不是100%可靠，但它是成本最低、见效最快的防线，必须做。
4.2 引用溯源：让每个结论都可核查
引用溯源是RAG系统在企业场景里最体现价值的功能之一。它要求答案的每一句话都能指向具体的知识库来源，用户或客服人员可以一键点开原始文档核对。实现上需要在分块阶段就给每个块分配全局ID，把ID与文档标题、章节路径、页码关联，再让生成模型在回答时输出引用ID，最后在展示层渲染成可点击的来源条目。
这里有一个容易做假的细节：很多团队只做了“答案旁边有引用编号”的展示，但编号对应的块里其实并没有那句话的结论，引用是凭空生成的。这种假引用在严肃场景里等于没有溯源。我的做法是在后处理阶段加一层忠实度校验，把答案的每个句子与对应引用块的文本做相似度比对，低于阈值的句子直接降级处理或剔除。宁可答案短一点，也不能给出无法核验的内容。
4.3 知识边界声明：区分“文档结论”与“模型推测”
模型在生成答案时，天然倾向于把所有话都说成既定事实。这会让用户误以为知识库里确实存在某种规定，从而做出错误决策。所以在提示词里要强制模型区分“文档里明确写了什么”和“根据文档我推测什么”两类内容，甚至建议允许模型坦率地说“这部分文档没有覆盖”。
举个客服场景：用户问“系统什么时候修复故障”，知识库里只有故障描述和处理流程，没有修复时间。对这类问题，模型应当回答“暂未查询到平台公布的修复时间，已为你记录问题并转人工跟进”，而不是估算一个时间。知识边界声明说起来只是表达习惯的调整，但它在用户侧建立的信任，比任何一个花哨的功能都更能提升系统口碑。
4.4 拒答策略与兜底：避免幻觉的最佳姿势就是不回答
RAG系统终极的防幻觉手段，其实是“不知道就不回答”。很多系统做不好这一点，是因为产品经理要求“必须回答所有问题”，于是模型被迫在信息不足时去猜，幻觉率自然居高不下。我的建议是明确定义可拒答的边界：资料不足、问题超出知识库范围、问题涉及实时状态信息时，直接走“资料未收录”或“转人工”流程。
拒答率升高会让某些“覆盖率”类指标短期下降，但用户的真实满意度通常反而上涨。“不知道但诚实”比“错误自信”更可信，这个原则在B端场景里尤其成立。落地节奏上，我建议先放开拒答，观察用户日志，再逐步把高频问题对应的文档补进知识库，扩大覆盖范围，而不是一开始就要求模型“什么都能答”。
5. 评测与持续调优：把幻觉率变成一个可追踪的数字
5.1 构造评测集：从真实日志出发，而不是标准题库
不做评测的RAG优化就是瞎调参。我见过太多团队把“感觉效果好了点”当结论，结果换个问题集就露馅。构造评测集的正确做法是从用户日志出发：抽取高频问题、代表性疑难问题、以及历史上答错过的case，人工标注标准答案和期望引用的文档块。一批200到500条就足够跑通基线。
不要只做“标准题库”，那种死亡之问式的教科书问题会掩盖真实场景的噪声。真实用户的问题往往口语化、有错别字、信息不全，恰恰是这些不标准的问题才能测出系统的鲁棒性。标注时除了标准答案，还要标注期望引用的文档块ID，这样评测时可以同时评估召回质量和生成质量，一举两得。
5.2 双维度评估：检索质量与生成忠实度分开看
RAG系统的效果评估要拆成两个独立的维度，否则出了问题都不知道该改哪一环。检索侧看Recall@K、MRR这类指标，衡量正确答案是否在候选集中；生成侧看忠实度（faithfulness）和答案相关性（relevance），前者衡量答案是否忠于引用材料，后者衡量答案是否真正回答了用户的问题。
我还会额外跟踪两个产品向指标：拒答率和用户差评率。拒答率不是越低越好，它反映了系统在边界情况下的诚实程度；用户差评率则是体验侧的最终裁决。工程上可以用LLM作为评判者给忠实度打分，但必须先拿一批人工标注结果和评判者对齐标准，否则容易用一个不靠谱的评价器去评测另一个模型，甚至出现“评判者自己也在幻觉”的荒诞局面。
5.3 问题归因：召回挂了还是生成挂了，一查便知
线上出了幻觉case，最怕眉毛胡子一把抓。我习惯用三步排查法快速归因：
- 查TopK候选块里有没有正确答案。没有，就是召回问题，去调分块策略、Embedding模型、混合召回权重；
- 如果候选块里有正确答案，但答案还是错的。那就是生成问题，优化提示词、加强引用校验、可能需要调整送入模型的上下文组合；
- 如果答案内容与候选块一致，但用户依然投诉。那多半是源文档本身过期或有误，需要去更新知识库，而不是动RAG链路。
这三步说起来简单，但如果不记录下来反复验证，很容易被某一个具体case带偏方向。我建议团队内部把每次线上case的归因结果沉淀成文档，形成错误案例库，后续调整参数时都拿这批case回归一遍。
5.4 数据更新与版本管理：文档变了，索引不能装睡
知识库不是一次性建好的，制度会修订、产品会迭代、文档会下架。增量更新索引时，最容易被忽略的是“删除动作”：被废弃的旧文档如果不从索引里清除，就会变成幽灵数据。用户问一个已经被废止的制度，系统还能检索出旧版本并煞有介事地引用，这就是幻觉的另一种死灰复燃。
我的处理方式很朴素：给每个文档块挂上版本ID和生效时间，检索时带上时间过滤；增量更新时，先比对变更文档清单，再同步更新、新增和删除三类操作；每隔一段时间做一次全量重建，彻底清理索引碎片。这些操作琐碎、不性感，但它们在长期运营中的价值，丝毫不低于任何一个亮眼的算法模块。
6. 我踩过的坑与RAG落地的现实建议
做了几个RAG项目之后，有些经验是花了不少成本才换来的。第一个教训是：不要第一个版本就上复杂的GraphRAG或Self-RAG架构。先用Naive加上Advanced那几板斧把基线跑通，把数据、评测、链路工具都搭好，再去考虑更高级的形态。复杂架构带来的收益如果无法被评测体系度量，就只是团队的自我感动。
第二个建议是：混合检索和重排序是性价比最高的两个改进点。它们围绕“怎么把对的材料送到模型面前”这件事发力，比换更大参数量的生成模型更直接。尤其是重排序，对答案质量的提升几乎是立竿见影的。
第三个经验是：没有评测集之前，不要大规模调参。没有客观基准，你根本不知道一次改动是进步还是退步。哪怕评测集一开始只有200条，也比没有强得多。
最后分享一个小技巧：我习惯在开发环境里做一个“答案溯源检查”工具，凡是答案句子里找不到对应引用ID的，自动标红。上线前把标红内容全部过一遍，能拦下大量的伪引用和脑补结论。这个工具不需要多复杂的实现，但它相当于给模型加了一道免疫系统的最后一环，每次跑完评测都能揪出一批漏网之鱼。
