最近帮一个团队做知识库问答系统的选型评审聊到 RAG检索增强生成的时候我明显感受到一种“概念通货膨胀”。有人说 RAG 无非是向量数据库加提示词拼接有人说纯 RAG 已经过时该上知识图谱还有人把 RAG 和模型微调对立起来争了半天。这些说法不能说全错但它们都各自盯着一个点很少把“RAG 技术演进”这条完整线索拉出来看。所以我想花两篇的篇幅把 RAG 的来龙去脉梳理一遍。上篇从 RAG 为什么会出现讲起一路拆到 Advanced RAG 对朴素流水线的系统性修补下篇再聊模块化 RAG、图状知识组织和评测体系如何反过来推动演进。这篇适合正在做 RAG 选型、准备搭 POC或者只想系统搞懂 RAG 的朋友看完你应该能判断自己项目里缺的到底是哪一环。1. RAG 的出身它在补大模型哪块短板1.1 大模型的“参数化记忆”天生有边界要理解 RAG 为什么会出现得先接受一个有点反直觉的事实大模型并不是一个“知道很多事的数据库”它更像一个把训练语料压缩成权重经验的系统。训练完成之后它记住的所有知识都以参数形式固化在神经网络里。你可以继续对话、推理、生成但它内部那份“世界知识快照”已经定格在训练截止日期。这个机制带来了三个连环问题知识新鲜度差、回答无法溯源、以及产生幻觉。幻觉的本质不是模型故意骗你而是当它不知道答案时仍然会用一种极其流畅自然的方式把最像正确答案的表述编出来。很多人觉得上下文窗口变大以后这些问题就解决了其实只解决了一半。上下文变长意味着你可以在一次对话里塞进更多资料但塞进去的资料如果没有经过筛选、定位和引用模型依然可能被无关信息干扰甚至从一堆互相矛盾的段落里“缝合”出一个错误结论。长上下文解决的是“能不能容纳”RAG 解决的是“该用哪些内容作为依据”这是两个不同的问题。1.2 “开卷考试”思路是怎么被逼出来的在 RAG 这个概念流行之前给大模型补充外部知识主要就两条路我都踩过坑。第一条是堆上下文把相关文档全文塞进提示词。看起来直接有效但很快会撞上成本和效果的双重天花板一个几千页的产品手册显然塞不进一次请求即便塞得进去模型也很难在超长上下文里准确定位关键证据反而是开头结尾的内容更容易被记住中间的关键细节被忽略。第二条是微调用业务文档继续训练模型。微调的问题是周期长、成本高、更新一次要重跑训练流程而且它把知识固化进权重之后同样面临不可溯源的问题。你很难判断模型回答里那句“系统支持自动重试”到底是来自真实文档还是来自训练数据里的相似表述。于是“检索 生成”的开卷考试思路就顺理成章地出现了平时不背书考试时允许翻资料。系统先根据问题去外部知识库里检索相关内容再把检回来的内容作为上下文交给模型生成答案。这样知识库可以随时更新答案可以引用依据模型也不需要在权重里硬记每一份业务文档。当时一批早期的检索式问答工作本质都是沿着这个思路在做探索只是后来 RAG 把这条路径系统化、工程化了。1.3 RAG 和微调解决的不是同一类问题我在评审时经常被问到一个问题有了 RAG是不是就不用微调了我通常用一个不太严谨但很好用的类比来回答微调负责教模型“怎么说话”RAG 负责给模型“说话的资料”。微调擅长改造模型的表达风格、输出格式、领域术语习惯RAG 擅长注入最新知识、私有资料、可追溯的依据。一个客服系统如果希望回复必须温柔礼貌同时又能查最新的优惠活动那它大概率需要两者结合——微调定调性RAG 供内容。选型时可以用下面这张表快速判断需求类型优先选择原因知识需要高频更新RAG换向量库里的文档即可生效回答必须可溯源RAG生成时携带检索证据可做引用输出风格、话术需要统一微调让模型学会特定表达习惯领域术语理解差微调 RAG微调打底子RAG 补知识冷门数据资料极少两者都要慎用没有数据基础RAG 也检不到理解了 RAG 的出身再去看它最早期的形态就会明白为什么一切从“三段式流水线”开始。2. 范式确立Naive RAG 的三段式流水线RAG 早期被称为 Naive RAG不是因为它幼稚而是因为它的流程足够朴素像一条传送带先把知识切成块、转成向量存进数据库再根据问题召回相关块最后拼接上下文生成答案。2.1 索引阶段切块、向量化与入库建立知识库索引是整条流水线的第一站也是后来所有优化环节里最容易被低估的一步。流程看起来很简单文档加载、清洗、切块、用嵌入模型转成向量、写入向量数据库。但每一步都有细节。切块大小是第一个坑。块太大向量里塞满了无关噪声检索时容易被整体相似度误导块太小语义不完整模型只能看到答案的一部分。我当时做某知识库项目时从 200 个 token 一路试到 800 个 token最后发现 300 到 500 个 token 是一个比较稳的区间——既能保留完整语义又不会因为信息过杂拖低召回精度。但这个数字不是金科玉律具体要看文档类型比如条文类的文档适合按条款边界切技术文档适合按段落结构切。向量化环节同样不能掉以轻心。嵌入模型的选择会直接影响检索效果通用模型可能在专业术语上表现平平领域内微调过的嵌入模型往往有明显优势。我当时测过一个通用嵌入模型和一个小规模领域微调模型在同一批法律条款上的召回准确率差了近十个点。向量数据库选型则更看重扩展性和过滤能力具体选哪家取决于你的数据量级和是否需要复杂的元数据筛选。2.2 检索阶段向量相似度的直觉与误区检索阶段的核心是算相似度。用户问题转成一个向量和库里的候选块向量做距离计算取 Top-K 返回。这里最常见的操作是调向量相似度阈值但很多人对相似度的理解是有误差的。常规做法是余弦相似度它只看方向不看模长对嵌入向量的尺度差异不那么敏感所以在大多数语义检索场景下表现稳定内积和欧几里得距离也不是不能用但它们更容易受到向量长度的影响除非你有明确理由否则我建议默认余弦。Top-K 的选择也有讲究K 太大会把一堆“有点相关但没用的块”塞进上下文K 太小又容易漏掉真正关键的证据。结合我的实践经验K 从 5 起步配合后续的重排来调比一上来就调大 K 更有效。还有一个新人容易踩的误区以为向量检索就是 RAG 检索的全部。实际上关键词检索比如经典的 BM25 算法在很多场景下依然能打。特别是用户问题里包含明确的产品名、报错码、合同编号这类精确词时关键词检索往往一枪命中而向量检索反而会被语义相近的无关内容带偏。“向量为主、关键词为辅”的双路召回是我在有明确专有名词场景下的默认起手式。2.3 生成阶段把资料拼进提示词只是第一步检索回来的块最终要拼进提示词再交给大模型生成。这个阶段的模板看起来平平无奇但里面藏着很多影响生成质量的细节。一个最简的提示词骨架大概长这样请根据以下资料回答问题。如果资料中没有相关信息请直接回答“资料中未找到相关内容”不要编造。 资料 {检索到的文本块} 问题{用户问题}这个模板里有三个值得展开的细节限定范围、拒绝机制、引文要求。限定范围是告诉模型“一切答案必须以资料为准”尽可能减少模型原有记忆的干扰拒绝机制是让模型在查不到答案时诚实说查不到而不是硬编引文要求则是把答案和资料中的某一段对应上方便用户验证。但提示词只是生成质量的最后一道闸门。如果前面检索回来的内容本身就是错的、是碎的、是互相矛盾的提示词写得再好也只能在坏地基上盖楼。所以我后来在评审项目时判断一个 RAG 系统好不好从来不只是看它回答得流不流畅而是先看它检索出来的那几段资料到底对不对路。2.4 朴素流水线在真实项目里的四个痛点Naive RAG 搭起来很快我见过最快的 demo 半天就能跑通。但从“能跑”到“能用”要过的坎非常多。总结下来是四类典型痛点而且它们彼此之间会互相放大。第一召回不准确。用户的提问往往是口语化的简短句子比如“这个东西多久能到”而知识库里对应文档写的是“配送时效说明”。一字不沾向量检索靠语义相似度勉强能拉回来但相关度经常不够高。第二切块不当导致语义断裂。一个完整方案被切在一刀两断的位置模型只看到半截上下文自然容易答残。第三召回内容冗余甚至互相冲突。多份文档对同一件事说法不一致模型不知道该信谁可能中和出一个两边都不疼的错误结论。第四无答案硬答。知识库里根本没有相关内容模型依然会给出流畅但错误的回答。这四个痛点单独看都是工程问题合起来却指向一件事RAG 不是“检索 生成”两个环节简单拼凑而是一条需要全链路协同优化的系统。对朴素流水线的系统性修补就构成了我们今天说的 Advanced RAG。3. Advanced RAG把朴素流水线拆开逐段修补Advanced RAG 并没有发明一套全新的革命性架构它做的事情更像外科手术把 Naive RAG 的三个环节拆开针对每一个环节暴露出的问题做精准修补。你可以把它理解为“在传送带旁边加质检员、加分流闸、加倒装工序”。3.1 查询侧优化先搞清楚用户到底想问什么很多团队做优化时第一反应是换更好的嵌入模型或者调切块大小但我会先看查询侧。因为用户的问题天然带着“语言不对齐”问题用户用自己的话描述需求知识库里的文档用专业术语表述两边向量算出来的相似度自然偏低。查询改写是目前最实用的手段之一。做法是先把用户原始问题交给大模型做一遍改写比如把“这个东西能不能退”改写成“哪些情况支持退货退款政策”让改写后的问题更接近文档里的表述方式再做检索。这个步骤不仅能提升命中率还能顺便把一句多意的问题拆成几个子问题分别检索再合并结果。另一种常见做法是展开式检索思路是让模型根据用户问题先补写几个不同侧重点的子问题或者生成一段“假设性答案”再用这段更完整的文本去检索。假设性答案这类做法的好处在于它把一句信息量极少的短问题扩写成一段更接近文档语言风格的描述检索时更容易命中语义近邻。代价是多一次模型调用延迟会略微增加但很多场景下收益远大于成本。查询路由同样值得投入它的作用是判断用户问题该走哪条数据通道是走向量知识库还是直接走 API 查实时数据还是交给通用大模型回答。在客服场景里库存查询、订单状态这类问题根本不该走 RAG而应该直接调用业务接口路由逻辑就是那个“分诊台”让每个问题流向最合适的处理通道。3.2 索引侧优化让知识以更好用的形态入库查询侧改好了接着要处理的就是知识库本身的结构。我参与过的几个项目里索引侧优化带来的收益往往比换一个更贵的嵌入模型还明显。切块策略从单纯固定窗口进化成了多种模式。最通用的是递归切块优先按标题、章节这类结构边界切边界不存在时再退到段落、句子层级去切直到满足大小约束。我自己的经验是结构边界的优先级永远高于固定的 token 数——宁可让某一两个块稍微超长也不要在一句话的中间切断。再往上走一步就是父子分块。做法是检索时用小的语义单元比如一个段落或几个句子去跟问题计算相关度召回命中后再把对应的小块所在的更大一级文档块取出来交给模型。这样做的好处很直观小块负责“定位准确”大块负责“上下文完整”。比如有人问“这个接口超时怎么办”小块能精准命中包含“超时”的那个句子而大块则把这个句子所属的整个小节的报错处理流程完整提供给模型避免它只看到半截话。元数据过滤也是索引侧性价比很高的改进。给每个块打上来源文档、章节、更新时间、适用范围等标签检索时先按这些标签把候选集缩小再算向量相似度。例如知识库里同时存在旧版和新版产品说明如果不按版本过滤模型很可能会拿已作废的旧参数去回答新问题。这个坑我就踩过加了版本过滤之后准确率提升非常直观。3.3 结果侧优化召回之后别急着拼进提示词如果说索引侧和查询侧是“提高召回质量”那么结果侧优化负责的是“从一堆可能相关的候选中挑出真正可用的证据”。这里最不能省的一步就是重排。向量检索本质上是在几千个候选块里粗筛一遍召回 Top-K 靠的是嵌入向量之间的相似度但这个相似度未必等于“真正回答问题的可用度”。重排的做法是把粗筛出来的候选块交给一个更精细的模型重新打分排序比如交叉编码器——它能把问题和候选块逐对拼在一起做精细语义匹配速度慢但准确度远高于向量粗排。我习惯先用向量检索召回 Top-50再用重排模型取 Top-5既能控制计算量又能拿到高质量的证据块。结果侧的另一个实用技巧是上下文压缩。检回来的块里经常有大量与问题无关的铺垫内容直接塞给模型既浪费上下文窗口又可能引入干扰信息。可以让压缩模型先做一步提炼把每个块里与问题最相关的部分摘出来甚至顺带把多个块的冗余信息去重合并再拼进提示词。还有融合检索把前面提到过的 BM25 关键词检索和向量语义检索的结果合并起来用 RRF倒数排名融合这类简单有效的算法统一排序。我的使用经验是当用户问题带有明确专有名词时融合检索能明显抬升命中率而那些纯靠语义理解才能找到答案的问题融合检索也不会比单独向量检索差太多。所以它算是一种低成本、稳健的兜底策略。3.4 我实测下来最有性价比的改进组合上面对每一侧给了不少手段但我不建议你一次性全上边际收益会递减排查问题也更困难。按我自己在真实项目里实践过的顺序比较推荐的组合是先做父子分块和元数据过滤这是索引侧的地基然后加融合检索把稀疏和稠密两条路都走起来最后加重排模型把粗筛结果精排一遍。这三步做完一个 RAG 系统通常就能达到比较可用的状态。我印象最深的一个模拟项目初始命中率大概不到 60%badcase 主要集中在专有名词检索不到和答案缺乏依据。做了父子分块后上下文完整性问题明显缓解加上 BM25 融合后报错码、接口名这类精确词召回好了很多再加重排最终命中率上了大概二十个百分点。而查询改写和上下文压缩我是放在第二步才做的——因为前几步已经把检索质量拉起来了这两个手段主要解决的是“问题语言对齐”和“上下文利用率”问题。所以选型时的直觉应该反过来不要一上来就追求更复杂的架构先问自己的 badcase 集中在哪个环节再决定修补哪里。4. 演进暗线为什么技术总是朝这几个方向走前面讲的都是具体技术但如果你想判断 RAG 下一步该往哪走光记住技术点是不够的还要看到这些演进背后的几条暗线。它们解释了为什么那么多方案最后收敛到了相似的打法上。4.1 从“找到相关”到“找到可作答的证据”Naive RAG 的核心目标一直是“召回相关段落”。但“相关”是一个模糊概念向量相似度排名靠前的段落可能只是主题相关根本不是回答问题必需的证据。这个矛盾在复杂的业务场景里会暴露得很彻底用户问“逾期了会有什么后果”召回结果里可能有十段都在讲“逾期定义”但真正讲“后果”的那段反而排在后面。所以 Advanced RAG 里各种手段本质上都在把检索目标从“相关”推向“可作答”。重排模型学的是“这个问题到底能不能用这段话来回答”而不是“这段话像不像”。元数据过滤、上下文压缩、父子分块本质上也都是为了让最终送进生成模型的不是一堆“有可能相关”的内容而是一份真正够用、不冗余、不矛盾的证据包。这条暗线理解清楚了你就明白为什么后来图化的知识组织、模块化流程会把重心放在“推理路径”和“证据链”上。4.2 从固定流水线走向按需编排Naive RAG 是一条单向传送带文档进、答案出中间环节固定不动。但真实场景里问题形态千变万化有些问题需要先改写再检索有些问题需要走 API有些问题需要检索好几轮才能找到答案。强制所有问题走同一条流水线注定有人被迁就有人被耽误。于是查询路由这类组件开始出现在架构图里它的本质是把“流水线”变成“路由图”系统先看用户问题属于哪一类再装配出适合它的处理路径。这个方向继续往前走就是模块化 RAG——把索引、检索、重排、生成这些能力当成积木按需组合甚至可以支持多轮迭代检索。对工程团队来说这种演进意味着 RAG 系统从一个“写死的脚本”变成了“可编排的工作流”遇到问题不用推翻重来只需要调整流程的装配关系。4.3 评测体系反过来推动演进方向RAG 演进的第三个特点是评测驱动。没有一套能衡量“检索质量到底好不好”“生成答案忠实不忠实”的指标技术优化的方向感就会很弱。早期大家评测 RAG 基本靠人工看几个例子主观且不稳定。后来逐渐形成了一套常见的观察维度检索环节看召回准确率生成环节看答案准确率、忠实度答案有没有依据和相关性答案有没有答非所问。有了这些可量化的指标很多一开始被认为“是玄学”的优化手段才被一点点验证。比如重排到底有没有用不是靠感觉而是看同一批测试集上答案准确率的提升幅度。评测体系的成熟也是 RAG 从“demo 阶段”走向“工程阶段”的分水岭。后面出现的各种新型 RAG 架构几乎每一个都在发布时带着对应的评测对比数据这反过来又加速了技术迭代。5. 回顾与选型自测你的系统处在哪一代聊到这里上篇的内容基本覆盖了 RAG 演进的前半程。最后给正在做选型或者正在优化系统的朋友一个自测框架。5.1 快速判断你处在哪一代你可以拿出自己的 RAG 系统对照下面几条来判断处于什么阶段表现所处阶段下一步优先级能检索、能生成但经常答非所问Naive RAG先查索引结构和切块策略检索结果貌似相关但生成的答案没依据Naive RAG加结果侧重排专有名词检索不准口语提问命中率低向 Advanced RAG 过渡加融合检索和查询改写能找到正确答案但回答冗长、上下文浪费Advanced RAG 后期加上下文压缩问题类型复杂单流程难以覆盖面向模块化演进考虑路由和流程编排这个表不能覆盖所有真实场景但能帮你快速定位最值得投入的方向。我见过不少团队在 Naive RAG 阶段就急着接一堆新框架结果复杂度上去了badcase 没有本质变化。先诊断、再下药比跟风更重要。5.2 关于“下篇”我打算聊什么既然标题是“上”这里顺手预告一下下篇的内容我会接着写模块化 RAG 的组件化思路、以图结构组织知识的新形态以及评测体系的具体落地方式。模块化和知识图谱这两个方向之所以值得单独花篇幅是因为它们不再修补单点而是试图重构 RAG 的整体范式评测则是让这些新范式能被验证的基础设施。放在下篇聊也是因为内容比较多拆开才不会让一篇文章变得又长又赶。如果让我用一句话总结上篇的收获我会说RAG 的技术演进表面上是一堆工具和手法在迭代本质上是对“检索到的内容是否真正支撑回答”这个核心问题的层层逼近。下一步当你能看到模块化和图组织各自的适用边界时你选型时的判断力会比只追热点强很多。最后再分享一个小体会我在自己项目里试过很多新方案回头发现真正稳定出效果的往往还是那些把基础环节老老实实做到位的组合——干净的索引、见招拆招的检索、克制的提示词。技术热点会变但这条底线很少变。希望这篇梳理对你也有同样的感受。