RAG 全解：从检索增强原理到生产级工程落地
"RAG 不就是把文档切一切、算个向量、检索出来塞进 prompt 吗？"
这句话不算错，但它掩盖了这个领域几乎所有会让你在生产环境里熬夜的部分。
比如：为什么你的 RAG demo 在几十篇文档上效果惊艳，一上到几万篇就开始胡说？为什么明明检索出了正确的段落，模型却视而不见、照样编一个答案？为什么"把 chunk 切大一点"有时候救命、有时候致命？以及那个每隔半年就要被人重新问一遍的问题——上下文窗口都几百万 token 了，RAG 是不是该退休了？
这篇文章按工程实战的顺序把这些逐层拆开。它是 AI 系列的延续：《一次 LLM 请求的全链路解剖》讲了一次请求怎么走完全程——而 RAG，本质上就是在那次请求发出之前，往里塞进"对的上下文"的一整套工程。《AI Agent 的长期记忆》讲的记忆检索，骨架和 RAG 是同一套。
关于本文的定位与证据
本文定位是面向读者的深度技术解析，不是某个具体产品的说明书。所有例子都用构造的典型场景（比如"给一家公司的内部文档做一个问答助手"），你可以直接对应到自己的项目。
技术密度较高的地方，我尽量做到三件事：讲原理时说清"为什么这么设计"（而不是只给结论）、讲参数时逐个说清"是什么 + 干什么用 + 填错会怎样"、讲选型时给可判定的判据（而不是"看情况")。
时效提示：RAG 是 2023 年以来变化极快的领域，尤其检索基础设施、进阶形态（GraphRAG / Agentic RAG）和"RAG vs 长上下文"这三块。本文时间戳是 2026 年 9 月，涉及具体模型名次、向量库热度、框架能力的地方，请当作"截至此刻的图景"，核心机制则相对稳定。凡是会随时间漂移的具体事实（哪个模型最强、哪个库最流行），我会尽量给判据而非只给名字——因为名字会变，判据不会。
一、先把 RAG 说清楚
1.1 一句话定义，和它背后的三个词
RAG 全称 Retrieval-Augmented Generation，检索增强生成。拆开这三个词，定义就出来了：
在让大模型"生成"答案之前，先去外部知识源"检索"相关资料，用检索到的内容"增强"模型的输入。
再压缩一次：让模型开卷考试，而不是闭卷默写。
闭卷默写就是普通的大模型问答——你问它，它凭训练时"背下来"的东西回答。开卷考试是 RAG——你问它，系统先翻出相关的资料页，连同你的问题一起递给模型，让它照着资料回答。
这个类比不只是好记，它精确对应了 RAG 要解决的问题。
1.2 RAG 到底解决什么问题
大模型有四个先天缺陷，RAG 是目前最务实的应对手段：
第一，知识会过期（knowledge cutoff）。 模型的知识冻结在训练数据的截止日期。你问它"我们公司上周发布的新政策是什么"，它不可能知道——那时它已经训练完了。RAG 让它去查你实时更新的知识库，绕过这个冻结。
第二，不知道私域知识。 你公司内部的合同、代码、工单、产品文档，从来没进过任何大模型的训练集。模型再聪明也变不出它没见过的东西。RAG 把这些私有资料作为检索源，让模型能回答"只有你们内部才知道"的问题。
第三，会一本正经地胡说（幻觉）。 模型的生成本质是"预测下一个最可能的词"，它没有"我不知道"的本能——不确定时，它倾向于编一个听起来合理的答案。RAG 给它一份参考资料，把"凭记忆瞎猜"变成"照着材料回答"，幻觉率显著下降（注意：是下降，不是归零，后面会讲为什么）。
第四，答案无法溯源。 普通问答给你一段话，你无从知道它凭什么这么说、对不对。RAG 因为答案是基于检索到的具体文档片段生成的，天然可以附上"这句话来自哪篇文档的哪一段"，让答案可核查。这一点在企业场景里往往比"准确率高几个百分点"更重要——能溯源的八十分，胜过不能溯源的九十分。
一个判断"该不该上 RAG"的快速标准
如果你的问题满足下面任意一条，RAG 大概率是对的方向：
- 答案依赖会变化的信息（价格、库存、政策、新闻）
- 答案依赖私有的、模型没见过的信息（内部文档、个人数据）
- 你需要答案能指出出处，供人核查
- 知识量大到塞不进一次 prompt，且大部分内容和当前问题无关
反过来，如果你要的是"改变模型的能力或风格"（比如让它更擅长写某种代码、模仿某种语气），那是微调的活，RAG 帮不上——RAG 改变的是"模型看到什么材料"，不是"模型本身会什么"。
1.3 RAG、微调、长上下文：三条路的边界
这三者经常被拿来比较，但它们解决的其实是不同的问题。用一张表划清边界：
| RAG（检索增强） | Fine-tuning（微调） | 长上下文（Long Context） | |
|---|---|---|---|
| 改变的是 | 模型看到的材料 | 模型本身的参数 | 单次能塞进去的材料量 |
| 擅长 | 注入会变的、私有的、需溯源的知识 | 改变能力、风格、格式、领域适应 | 一次性处理一整篇长文档 |
| 知识更新 | 改知识库即可，分钟级 | 要重新训练，天级到周级 | 每次请求现塞，即时但不持久 |
| 成本结构 | 检索 + 存储，边际成本低 | 训练一次性投入高 | 每次请求都为长输入付费，越用越贵 |
| 可溯源 | 天然支持 | 不支持 | 弱（在超长上下文里模型也会"迷路"） |
| 典型翻车 | 检索不准、模型不用检索结果 | 灾难性遗忘、过拟合 | lost-in-the-middle（中间内容被忽略）、成本爆炸 |
它们不是三选一，而是可以叠加
生产系统里最常见的组合是 RAG 打底 + 微调兜风格 + 长上下文兜整篇：用 RAG 注入知识，用轻量微调让模型更懂你的领域术语和输出格式，遇到"必须看完整份合同"的场景再动用长上下文。把它们当竞品是新手视角，当工具箱才是工程视角。关于"长上下文会不会取代 RAG"这个具体争论，本文第八节专门展开。
二、一条最小 RAG 链路：把每一环拆到"为什么"
理解 RAG，最好的方式是跟着一份文档走一遍：它是怎么从"一个 Word 文件"变成"模型答案里的一句引用"的。
整条链路分两个阶段：离线的索引阶段（把知识库预处理好，存起来）和在线的查询阶段（用户提问时实时走的流程）。
【离线 · 索引阶段】只在知识库更新时跑
原始文档 (PDF/Word/网页/数据库)
│
▼ ① 解析 & 清洗 把各种格式抽成纯文本
│
▼ ② 切分 chunking 切成一段段"检索单元"
│
▼ ③ 嵌入 embedding 每段算成一个向量
│
▼ ④ 入库 indexing 向量 + 原文 存进向量库，建索引
│
[向量数据库] ←── 建好就等着被查
【在线 · 查询阶段】用户每次提问都跑
用户问题
│
▼ ⑤ 问题嵌入 把问题也算成一个向量
│
▼ ⑥ 检索 retrieval 从库里捞出最相似的 N 段
│
▼ ⑦ 重排 rerank 对这 N 段重新精排，留下最相关的几段
│
▼ ⑧ 组装 prompt 问题 + 检索到的段落 → 拼成完整输入
│
▼ ⑨ 生成 generation 大模型照着材料回答，附上出处
│
最终答案下面逐环拆。每一环我都会讲清"它在干什么"和"为什么非它不可"——因为工程上出问题时，你得知道是哪一环坏了。
2.1 解析与切分（chunking）：被严重低估的第一道坎
解析是把 PDF、Word、PPT、HTML、扫描件这些五花八门的格式，抽成模型能读的纯文本。听起来简单，实际是 RAG 里最脏最累、又最影响最终效果的活——一个把三栏 PDF 按整页横读成"串行乱码"的解析器，能让后面所有环节白费。表格、公式、图片里的文字、页眉页脚，每一样都是坑。
**切分（chunking）**是把长文本切成一段段较小的"检索单元"（chunk）。为什么非切不可？两个硬约束：
- 嵌入模型有输入长度上限，一篇长文档整个塞不进去，必须切小。
- 检索的粒度决定精度。如果一个 chunk 是一整章，那检索出来给模型的就是一整章——里面大部分和问题无关，等于让模型在噪音里找答案。chunk 太大，精度差；chunk 太小，又会把一个完整意思切断，检索到半句话。
这就带出 chunking 最关键的两个参数，逐个说清：
chunk_size（切片大小）：每段多长，通常按 token 或字符数算。是什么：一个检索单元的体量。填大了会怎样：召回的内容里无关信息多，稀释了相关信号，还浪费 prompt 空间和钱。填小了会怎样：语义被切碎，一个完整的因果、定义、步骤被拆到两段里，检索时只捞到一半，模型拼不出完整答案。实践含义：没有万能值，取决于你文档的"意义密度"。条款型、FAQ 型文档意义单元小，可以切小；叙述型、技术文档逻辑连贯，要切大些。经验区间常在几百 token，但请用你自己的问题去测，而不是抄一个默认值。chunk_overlap（重叠长度）：相邻两段重叠多少内容。是什么：让第 N 段的结尾和第 N+1 段的开头有一段重复。为什么要有：防止一个关键句正好被切在两段的边界上，导致两段都只有半句。重叠相当于给边界"打个补丁"。填 0 会怎样：边界处的信息容易丢，跨段的句子被腰斩。填太大会怎样：存储和计算翻倍（同样内容被嵌入多次），且检索时容易返回大量高度重复的段落，挤占了本该给其他内容的名额。实践含义：通常取chunk_size的 10%-20% 作为起点。
切分不止"按长度切"这一种
最原始的切法是"每 500 字切一刀"（固定长度切分），简单但粗暴，经常拦腰截断句子。进阶的做法是按结构切（沿着 Markdown 标题、段落、句子的自然边界切，尽量不破坏语义单元）和语义切分（用 embedding 判断相邻句子是否还在讲同一件事，话题一变就切一刀）。还有一类思路叫 父子切分 / 小切大用：用小 chunk 去做精准检索（命中率高），但真正喂给模型时，返回这个小 chunk 所在的大段落（父块），兼顾"检索准"和"上下文全"。这是生产环境里非常实用的一招，第五节还会展开。
2.2 嵌入（embedding）：把语言变成可以算距离的坐标
嵌入是 RAG 的数学核心。它把一段文字，通过一个专门的嵌入模型（embedding model），变成一个高维向量——一串几百到几千个浮点数。
"如何申请年假？" → [0.021, -0.334, 0.187, ..., 0.052] (比如 1024 维)
"请假流程是什么？" → [0.019, -0.341, 0.203, ..., 0.048] (和上面很接近)
"公司食堂几点开门？" → [0.512, 0.088, -0.667, ..., 0.301] (离得很远)关键在于：这个向量不是随机编码，而是让意思相近的文字，向量也相近。"如何申请年假"和"请假流程是什么"字面几乎不重叠，但意思相通，它们的向量在高维空间里挨得很近；而"食堂几点开门"意思无关，向量离得很远。
有了这个性质，"找语义相关的内容"就变成了一个纯数学问题：在向量空间里找离问题向量最近的那些点。
怎么衡量"近"？最常用的是余弦相似度（cosine similarity）——衡量两个向量方向的夹角，方向越一致，值越接近 1，越不相关越接近 0（甚至为负）。你不用记公式，只要记住：它比的是"方向"而不是"长度"，也就是"意思像不像"而不是"文字多不多"。
为什么 embedding 能理解"意思"
简单说：嵌入模型是在海量文本上训练出来的，训练目标就是"让经常出现在相似语境里的词/句，向量也相似"。"年假"和"请假"总是出现在相近的上下文里，模型就学会了把它们放到相近的位置。这和大模型本身的原理一脉相承——都是把语言先变成向量再计算。区别是嵌入模型专门为"表示整段话的意思"优化，输出一个能代表全文的向量。
嵌入模型的选择直接决定检索质量的天花板，几个要看的维度：
- 向量维度（dimension）：向量有多少个数。维度高通常表达能力强、检索更准，但存储更大、计算更慢。有些模型支持"套娃"式降维（可以砍掉后面一部分维度只用前面的，精度略降但省空间），是个实用的权衡旋钮。
- 是否支持中文 / 多语言：一个只在英文上训练的模型，中文检索会很差。做中文 RAG 必须选中文能力强的模型，这是硬门槛。
- 最大输入长度：决定了你的 chunk 能切多大——chunk 不能超过嵌入模型的输入上限。
- 是对称还是非对称检索：有些模型专门为"短问题 ↔ 长文档"这种不对称场景优化过（问题短、答案长），比通用模型更适合 RAG。
具体哪些模型是当下第一梯队，会随时间变，第三节结合最新情况给判据。
2.3 存储与索引：为什么不能"挨个比一遍"
现在每段文档都成了一个向量，用户问题也是一个向量。检索就是"找最近的邻居"。
最朴素的做法是暴力搜索：拿问题向量和库里每一个向量都算一次相似度，排序取前几个。几千条没问题，但知识库动辄几十万、几百万甚至上亿条，每次查询都全库算一遍，慢到不可用。
于是有了向量数据库和 ANN（近似最近邻，Approximate Nearest Neighbor）索引。核心思想是：用一点点精度换巨大的速度——不保证找到"绝对最近"的邻居，但保证极快地找到"几乎最近"的那些，而这在 RAG 里完全够用。
最主流的 ANN 索引是 HNSW（分层可导航小世界图）。你不用懂它的图论细节，但要理解它的两个关键参数，因为它们直接决定你 RAG 的快慢和准度：
M（每个节点的连接数）：是什么：索引图里每个向量和多少个邻居相连。调大：检索更准（路径选择多），但索引占用内存更大、构建更慢。调小：省内存、建得快，但可能漏掉真正的近邻。实践含义：建索引时定死，改它要重建索引，所以要一开始想清楚。ef_construction（构建时的搜索宽度）：是什么：建索引时，为每个点找邻居的努力程度。调大：索引质量高、检索更准，但建索引更慢。调小：建得快但索引质量差。实践含义：这是一次性成本，为了长期检索质量，通常值得调大一些。ef_search（查询时的搜索宽度）：是什么：每次查询时探索多少候选。调大：召回更准、更全，但每次查询更慢。调小：查得快但可能漏。实践含义：这是运行时旋钮，可以随时调，是你平衡"快"和"准"最常用的开关。用户抱怨"搜不全"就调大它，抱怨"太慢"就调小它。
另一大类索引：IVF
除了 HNSW，还有一类叫 IVF（倒排文件索引）：先把所有向量聚成很多簇（cluster），查询时只在最相近的几个簇里找，跳过其余。它的关键参数是 nlist（分多少簇）和 nprobe（查询时搜几个簇）——nprobe 调大更准更慢，是和 ef_search 类似的运行时旋钮。IVF 常配合量化压缩（把每个浮点数用更少的位表示，比如 PQ 乘积量化）来省内存，代价是精度损失。选型直觉：数据量没到亿级、追求召回质量，HNSW 通常是默认之选；到了超大规模、内存吃紧，IVF + 量化更省钱。
除了向量本身，向量库还要存每个 chunk 的原文和元数据（metadata）——比如这段来自哪篇文档、哪一页、什么时间、什么部门。元数据不是可有可无的装饰，它撑起了 RAG 里极其重要的一招：元数据过滤（metadata filtering）。比如用户问"2026 年的报销标准"，系统可以先用元数据把范围限定在"年份=2026"的文档，再在里面做向量检索。这一步能挡掉大量"语义相似但事实错误"的干扰（比如 2024 年的旧标准），是生产环境的必备。
2.4 检索（retrieval）：向量检索并不万能
到这一步，把用户问题嵌入成向量，去库里捞出最相似的 N 段，N 就是那个著名的参数：
top_k（返回数量）：是什么：检索返回多少段最相似的 chunk。调大：召回更全，正确答案更可能被捞到，但塞进 prompt 的噪音也更多、更贵、更容易让模型"迷失在中间"。调小：精准但可能漏掉正确答案。实践含义：这是 RAG 里最需要调的参数之一。常见做法是检索时 top_k 放大（比如取 20-50，宁可多捞），再靠下一环的重排收窄（精排后只留 3-5 段喂给模型）。
这里必须戳破一个新手常有的幻觉：纯向量检索并不万能。 它擅长"意思相近"，却恰恰不擅长几件事：
- 精确匹配。你搜一个产品型号 "SKU-8842-X"、一个函数名
get_user_by_id、一个法条编号——这些是"符号"，不是"语义"。向量检索会给你一堆"意思相关"的东西，却可能漏掉那个字符完全匹配的目标。 - 专有名词和缩写。生僻的人名、内部黑话、行业缩写，嵌入模型可能没见过，向量化后位置很随机。
- 数字和实体。"金额大于 1 万"这种条件，语义检索无能为力。
传统的关键词检索（如 BM25 算法）恰好相反：它擅长精确的字面匹配，却不懂"年假"和"请假"是一回事。
于是有了 RAG 里几乎已成默认的做法——混合检索（hybrid search）：向量检索 + 关键词检索双管齐下，各取所长，再把两路结果融合。 向量负责"意思像"，关键词负责"字要对"。融合时常用一个叫 RRF（倒数排名融合，Reciprocal Rank Fusion） 的方法，简单说就是"在两个榜单里都排得靠前的，综合得分就高"。
"召回"是 RAG 成败的命门
记住一条：检索这一步没捞到的东西，后面全环节都救不回来。 模型再强、prompt 写得再好，如果正确答案压根没被检索出来，结果一定是错的（要么胡编，要么答"不知道"）。所以工程上有个铁律——召回优先于精排：宁可先多捞一些（高 recall），再靠重排去粗取精，也不要一开始就卡得太死而漏掉正确答案。你的 RAG 效果差，第一件事永远是先查"正确答案到底被检索出来了没有"，而不是去调 prompt。
2.5 重排（rerank）：召回之后的精挑细选
检索为了保召回，往往放宽了口子（top_k 取几十），结果里难免混入不那么相关的。直接把几十段全塞给模型，既贵又会干扰它。**重排（rerank）**就是在检索和生成之间加一道精筛。
为什么不能靠检索时的相似度直接排？因为检索用的相似度是"粗筛"——它是问题向量和文档向量各自独立算好后比距离，快，但不够精。**重排模型（reranker）**是另一类模型，它把"问题"和"某一个候选段落"成对地一起读进去，直接输出一个精确的相关性分数。因为它让问题和文档"当面对质"（术语叫 cross-encoder，交叉编码），判断精度远高于"隔空比向量"，代价是慢——所以只能用在"几十个候选"这种小范围精排上，不能用来扫全库。
于是标准的两段式检索成型了：
全库 (百万级)
│ ① 向量检索 / 混合检索 —— 快、粗，负责"别漏"
▼
候选 (几十个)
│ ② reranker 精排 —— 慢、准，负责"排对"
▼
最终 (3-5 个) —— 喂给模型先用便宜快速的方法从百万里捞出几十个（保召回），再用精准昂贵的方法从几十里挑出最好的几个（保精度）。 这个"粗筛 + 精排"的两段式结构，是几乎所有成熟检索系统（搜索引擎、推荐系统）的通用范式，RAG 只是又一次复用了它。
加了 rerank，通常是 RAG 效果提升性价比最高的一步
在很多实际项目里，从"纯向量检索直接喂模型"改成"向量检索 + rerank 再喂模型"，答案质量的提升非常明显，而工程改动很小（就是在中间加一次模型调用）。原因就在 2.4 说的：检索为了召回放宽了口子，噪音多；rerank 把噪音精准剔掉，模型看到的材料干净了，答案自然准。如果你的 RAG 还没上 rerank，这通常是第一个该补的。
2.6 生成（generation）：检索到了，不等于模型会用
材料备齐，最后一步是把用户问题 + 检索到的几段材料组装成一个完整的 prompt，交给大模型生成答案。这一步的 prompt 大致长这样（构造示例）：
你是公司内部知识助手。请严格根据下面提供的【参考资料】回答用户问题。
要求：
1. 只依据参考资料作答，资料里没有的，就回答"根据现有资料无法确定"，不要编造。
2. 在答案中用 [1][2] 标注每句话依据的资料编号。
【参考资料】
[1]（来自《员工手册》第 12 页）年假申请需提前 3 个工作日在 OA 系统提交……
[2]（来自《2026 假期政策》）2026 年起，年假可跨年结转，上限 5 天……
【用户问题】
我今年没休完的年假明年还能用吗？看起来只是"把材料拼上去"，但这里藏着 RAG 后半程最反直觉的一个真相：
检索到正确材料，模型照样可能不用它
这是生产 RAG 里最让人抓狂的现象之一。正确的段落明明就在 prompt 里，模型却视而不见，要么继续用它自己记忆里的（可能过时的）知识回答，要么干脆编一个。原因有好几层：
- 材料和模型的内在记忆冲突时，模型不一定听材料的（尤其材料反常识时）。
- 材料放在长 prompt 的中间时，容易被忽略——这就是著名的 lost-in-the-middle（迷失在中间）：模型对上下文开头和结尾的注意力，明显高于中间。
- **prompt 没明确要求"只依据材料"**时，模型会自由发挥。
- 检索进来的噪音段落太多，正确信息被淹没。
所以"生成"这一环的工程重点，不是让模型更聪明，而是用 prompt 和材料组织去"逼"它老实用检索结果：明确指令（"资料没有就说不知道"）、把最相关的材料放在头尾而非正中、控制喂进去的段落数量和质量、要求它标注引用（标引用这个动作本身就会"拽"着它去对照材料）。这些都是第五节优化方案里的具体招数。
到这里，一条完整的 RAG 链路就走通了。回头看这九个环节，你会发现一个规律：RAG 的难点不在任何单一环节的"高深算法"，而在整条链路的"没有短板"。 切分毁了语义、嵌入选错了模型、检索漏了召回、重排缺席、生成没约束——任何一环拉胯，最终答案就崩。这也是为什么 RAG "demo 五分钟，生产半年"——demo 只需要跑通，生产需要每一环都不掉链子。
三、开源技术栈与选型：2026 年该拿什么搭
RAG 有一个对工程师非常友好的性质：它几乎全套都有成熟的开源件，你不需要自己造轮子。真正难的是"从一堆能用的里面选哪个"。
这一节给的不是"用 X 就对了"——具体哪个模型最强，每隔几个月就要重排一次名次。给的是选型时该盯住哪些判据。判据不会过时，名次会。
3.1 嵌入模型：先看判据，再看榜单
一个 2026 年必须先知道的背景
如果你还停留在"要最好的 embedding 就上 OpenAI"，这个认知已经过时了。2025-2026 年最大的结构性变化是：开源嵌入模型（以大模型为底座训练的那批）在公开榜单上已经全面追平甚至反超闭源 API。 也就是说，"想要顶级效果就必须调用付费 API"这个前提，现在不成立了——你完全可以自托管一个开源模型，拿到第一梯队的检索质量，还省掉每次调用的费用和数据出境的顾虑。
榜单本身叫 MTEB（Massive Text Embedding Benchmark，大规模文本嵌入基准），多语言版叫 MMTEB，中文子榜叫 C-MTEB。具体名次半衰期以"周"计，本文不写死，你选型前自己去榜单点一眼即可。
选嵌入模型，逐条对着这几个判据看：
- 中文 / 多语言能力：一个只在英文上训练的模型，中文检索会差得离谱。做中文 RAG，这是一票否决的硬门槛——先在 C-MTEB 这类中文榜上看，别拿英文榜的名次做决定。
- 向量维度：维度高通常更准，但存储更大、检索更慢。有些模型支持"套娃降维"（可以只用向量的前一部分，精度略降换存储和速度），是个实用旋钮。
- 最大输入长度：它卡死了你的 chunk 能切多大——chunk 不能超过嵌入模型的输入上限。做长文档、想切大块，就要选支持长输入的。
- 对称还是非对称检索：RAG 是典型的"短问题 ↔ 长文档"非对称场景。有些模型专门为这个优化过，比通用模型更合适。
- 许可证（最容易被忽略、后果最严重）：开源不等于可商用。有些效果很好的模型（比如某些中文检索榜靠前的），许可证是"仅限研究、禁止商用"。你拿它做了商业产品，是法律风险。 选型第一步就该看清许可证，别等上线了才发现踩雷。
截至 2026 年 9 月，中文场景一个常见的分档思路（具体型号请以最新榜单为准，这里只给分档逻辑）：追检索质量、算力充足，选大模型底座的顶级开源嵌入模型；要性价比、中小团队，选那类"一个模型同时支持稠密向量 + 稀疏向量 + 多向量、还支持 8K 长文"的全能型开源模型（BGE-M3 是这一档的代表）；文档特别长，选专为长文档优化的那批。
换嵌入模型 = 全库重新灌一遍向量
这是个必须写进架构设计里的硬约束：不同嵌入模型的向量空间互不兼容。 模型 A 算出的向量和模型 B 算出的向量，压根不在一个坐标系里，没法混用、没法比较。所以一旦你想换嵌入模型（升级新版、或换一家），意味着整个知识库的所有向量都要用新模型重新算一遍、重新入库——几百万条的库，这是一次不小的离线工程。
实践含义：从第一天就在数据表里存一个"嵌入模型版本"字段，标清每条向量是哪个模型哪个版本算的。将来迁移时，你才能分批灰度、新旧并存、逐步切换，而不是"停服一整天重灌全库"。
3.2 重排模型：托管还是自托管
重排（reranker）的选型，主要是两条路线的取舍：
- 托管 API（如 Cohere Rerank、Voyage rerank 这类）：零配置，接一个 HTTP 调用就能用，省去自己部署和调优 GPU 的成本。代价是每次重排都要付费、数据要出境（对合规敏感的场景是硬伤）、且受制于服务商的可用性。
- 开源自托管（如 BGE-reranker、Qwen3-Reranker 这类）：自己部署，数据不出门，无调用费，许可证通常也更宽松（同样要逐个确认——有的开源 reranker 权重是"禁商用"的）。代价是要自己扛部署、扩容、延迟优化。
判据很直接：数据能不能出境（合规）是第一道分水岭，出不了境就只能自托管；调用量大不大决定托管的费用是否划算；团队有没有 GPU 运维能力决定自托管的门槛。
要额外留意延迟：重排是在线查询链路里实打实的一环，用户每次提问都要等它。候选段落越多、重排模型越大，延迟越高。所以重排的输入数量（把检索来的几十个候选喂给它）要和延迟预算一起定。
3.3 向量库：按"你已有什么"选，别按"谁最火"选
向量数据库是选型里最容易"追新踩坑"的地方——看到某个库很火就上，结果发现和自己的技术栈格格不入。正确的判据不是"谁最强"，而是"哪个和你已有的底座最贴"。
| 你的情况 | 务实之选 | 为什么 |
|---|---|---|
| 已经在用 PostgreSQL，向量规模不大（千万级以内） | pgvector（Postgres 扩展） | 不引入新组件、复用现有运维和备份、事务和过滤天然一体。这是 2026 年被反复推荐的默认起点 |
| 要零运维、最快上线，能接受厂商锁定 | 托管型向量服务 | 不用自己扛扩容和调优 |
| 要强混合检索、多租户隔离 | 专业向量库（Weaviate 一类） | 这些能力是它们的一等公民 |
| 追求最低延迟、成本可预测 | Rust 系向量库（Qdrant 一类） | 资源占用和延迟表现好 |
| 数据到十亿级、有 GPU 预算 | 分布式向量库（Milvus 一类） | 为超大规模和 GPU 加速设计 |
| 只是本地原型、嵌入式 | 轻量库（Chroma / LanceDB 一类） | 几行代码就能跑起来 |
| 已经在重度用 Elasticsearch | 直接用 ES 的向量能力 | 顺手，不用多养一个系统 |
pgvector 为什么值得单独说一句
"能不能不新增基础设施，就在我现有的 Postgres 上做 RAG"——这个务实问题，2026 年的答案基本是"能，且推荐"。pgvector 近两年补齐了关键能力：0.8.0（2024 年 10 月）引入了迭代索引扫描（解决"带条件过滤时召回不够"的老毛病——比如你又要按向量相似、又要 WHERE 部门='法务'，以前容易过滤完就没剩几个了）；0.8.1（2025 年 9 月）补上了新版 Postgres 支持，并优化了二值量化的性能（二值量化是把向量压成 0/1 存储、大幅省空间的技术，更早的版本就已引入）。
一个容易忽略的细节：迭代索引扫描默认是关着的，要手动开 hnsw.iterative_scan 才生效——不知道这点的人会以为"pgvector 过滤召回不行"，其实是没开开关。
判据：千万级向量以内、已经有 Postgres、不追求极致延迟——别过早上专业向量库，pgvector 先扛着，等真的撞到规模或性能墙再迁移。过早引入基础设施是中小团队最常见的浪费。
3.4 编排框架：LlamaIndex / LangChain / Haystack
把上面这些零件串成一条流水线，通常会用一个 RAG 框架。三个主流的，定位其实分得挺清楚：
- LlamaIndex：检索优先。数据连接器最全、专注"把各种数据灌进来、建索引、查询"这条主线。如果你的核心诉求就是"把一堆文档做成能问答的库"，它是最顺手的默认。
- LangChain：通用编排。强项是把 LLM、工具、检索、多步流程串成复杂的 agent 逻辑（它的 LangGraph 是做复杂流程的主力）。功能全，但版本演进快、有迁移成本，老 API 时不时被弃用。
- Haystack：面向生产和受监管行业。管线是显式、可序列化、可审计的，可观测性是一等公民。金融、医疗这类"每一步都要能审计"的场景更合适。
别被框架对比里的营销数字骗
这类框架对比文章里经常出现"用了 X 准确率提升 78 倍""性能提升 35%"之类的数字——它们绝大多数是厂商营销话术，不是可复现的基准测试。选框架看的是定位匹配度和团队熟悉度，不是这些数字。而且现实中很多成熟系统是组合用（比如 LlamaIndex 管检索 + LangGraph 管编排），不是二选一。
3.5 一套"最小可用"的起步栈
把上面的判据落成一个具体的、构造的起步建议（适合"先跑起来、别过度设计"的团队）：
解析切分： 按文档结构切（沿标题/段落），先不上花哨的语义切分
嵌入模型： 选一个中文能力强、许可证可商用的开源模型，自托管
向量存储： 已有 Postgres 就上 pgvector；没有就用一个轻量向量库
检索： 混合检索（向量 + 关键词），RRF 融合 ← 别省这一步
重排： 加一个开源 reranker，top_k 检索 20-30 → 精排留 3-5
生成： prompt 里明确"只依据材料、无依据就说不知道、标引用"
评测： 从第一天就搭最简评测集（后面第七节讲）这套东西没有任何一个环节是"高精尖"，但它每一环都不缺——而 RAG 的效果，恰恰取决于"没有短板"而非"某一环特别强"。等它跑起来、你有了真实的失败案例和评测数据，再针对性地升级某一环，比一开始就堆满花哨技术要靠谱得多。
四、工程级 RAG 的真相：为什么 demo 惊艳，生产翻车
这一节是全文的重心之一。
RAG 的入门体验是"骗人"的好：找几十篇文档，用最基础的流程搭起来，一问一答，效果惊艳。于是很多团队信心满满地推向生产——然后撞上一堵墙。demo 和生产之间隔着的，不是"再优化一点"，而是一整类在小数据、低并发下根本不会暴露的问题。
下面把生产 RAG 最常见的坑逐个列出来。每个坑给"症状 → 根因 → 怎么判定"，因为工程救火时，你最需要的是"快速定位是哪一环坏了"。
4.1 坑一：正确答案压根没被检索出来（召回失败）
症状：模型答"根据现有资料无法确定"，或者干脆胡编。但你手动一翻，正确答案明明在知识库里。
根因：这是 RAG 第一大坑，且原因往往叠加——切分把关键语义切碎了（正确信息分散在两个 chunk 里，各自都不完整）；嵌入模型对你的领域术语不敏感（内部黑话、专有名词，它没见过，向量位置很随机）；纯向量检索碰上了它的死穴（用户搜一个精确的型号、编号、函数名，语义检索给不出字面匹配）。
怎么判定：这是排查 RAG 问题的第一步，永远先做这个——把检索环节单独拎出来，看"正确的 chunk 到底进没进 top_k"。进了但模型没用，是生成环节的问题（坑二）；压根没进，是检索环节的问题。别一上来就调 prompt——如果东西没检索到，prompt 再神也没用。
一条贯穿始终的铁律
检索这一步没捞到的，后面全链路都救不回来。 这是 RAG 和普通问答最根本的区别：普通问答错了是"模型不行"，RAG 错了大概率是"没检索到"。所以工程精力的分配也该反过来——大部分团队花 80% 时间调 prompt、20% 调检索，而正确的比例往往应该反过来。
4.2 坑二：检索到了，模型却不用（生成不忠实）
症状：正确段落就在 prompt 里，模型却视而不见，用它自己的（过时）记忆回答，或者编一个更"顺"的答案。
根因：前面 2.6 讲过——材料和模型内在记忆冲突时它不一定听材料的；材料放在长 prompt 中间容易被忽略（lost-in-the-middle，迷失在中间）；prompt 没硬性要求"只依据材料"；噪音段落太多把正确信息淹没了。
怎么判定：把检索到的材料和最终答案对照着看——答案里的关键事实，能不能在材料里逐条找到出处？找不到，就是模型在"自由发挥"。一个快速验证：把 top_k 调小、只留最相关的那一两段干净材料，如果答案立刻变对，说明是噪音淹没或迷失在中间；如果还错，就是指令不够硬或模型不信材料。
4.3 坑三：需要"综合多篇 / 多跳推理"的问题答不了
症状：单点事实问得很准，但一问"对比一下 A 方案和 B 方案""把去年到今年的政策变化梳理一下""这个问题涉及的所有部门规定汇总一下"，就答得残缺。
根因：基础 RAG 的检索是"找相似"，不是"做推理"。它能捞出和问题最像的几段，但如果答案需要把分散在五篇文档里的信息拼起来再推导，向量检索给不了这种"结构化的关联"。它捞到的可能全是"和问题相似"的段落，却漏掉了那些"本身不相似、但推理链上必需"的中间环节。
怎么判定：看你的失败案例里，是不是集中在"对比类、汇总类、多步推理类"问题。如果是，这不是调参能解决的，是基础 RAG 的能力边界——这正是第六节 GraphRAG 和 Agentic RAG 要解决的问题。
4.4 坑四：知识库更新了，检索结果还是旧的
症状：文档明明改了/删了，RAG 还在拿旧内容回答；或者同一个问题，检索出互相矛盾的新旧两版内容。
根因：这是最容易被 demo 掩盖的工程坑——demo 的知识库是静态的，生产的知识库是活的。 文档更新后，对应的向量没重新计算；文档删除后，向量还留在库里变成"幽灵段落";同一份文档的多个历史版本都在库里，检索时新旧打架。
怎么判定：这是架构问题不是效果问题，要在设计阶段就想清楚：知识库的增删改，怎么同步到向量库？有没有版本和时效字段？删除是真删还是软删（软删要在检索时过滤掉）？如果你的 RAG 上线时没设计"更新链路"，这个坑迟早爆。
4.5 坑五：表格、图片、PDF 版面里的信息全丢了
症状：知识库里明明有一张关键的价格表 / 参数表 / 流程图，用户问相关问题却答不上来。
根因：栽在最开头的解析环节（2.1）。传统解析器把 PDF 抽成纯文本时，表格的行列结构被拍平成一串乱序文字、图片里的文字直接丢失、多栏版面被横着读成乱码。信息在第一步就没了，后面再强也无米下炊。
怎么判定：把你的解析结果（抽出来的纯文本）直接打开看一眼——表格还成形吗？关键的图表信息还在吗？这是最直接的判定，也是最容易被跳过的一步（大家默认"解析肯定没问题"）。解决方向是版面感知的解析、或者干脆走多模态 RAG 把页面当图片处理（第六节）。
4.6 坑六：垃圾进，垃圾出（数据质量）
症状：RAG 一本正经地给出过时的、错误的、自相矛盾的答案——而且因为它"有据可查"（真的引用了文档），显得特别可信，反而更危险。
根因：RAG 只负责"忠实地转述检索到的内容"，它不负责判断内容本身对不对。如果你的知识库里躺着三年前作废的政策、没清理的错误文档、互相矛盾的多个版本，RAG 会忠实地把它们端出来。能溯源的错误答案，比不能溯源的错误答案更有欺骗性——因为用户看到"来源：员工手册第 12 页"就信了。
怎么判定：这个坑不在技术链路里，在数据治理里。RAG 上线前，知识库该有一次清理：作废内容下架、重复版本合并、时效信息打标。指望技术手段补救数据质量，是本末倒置。
4.7 把优缺点摆到台面上
坑列完了，公允地总结 RAG 的优缺点——没有银弹，只有权衡：
| RAG 的优势 | RAG 的代价 / 局限 |
|---|---|
| 知识实时更新，改库即可，无需重训 | 多了一整条链路（解析/切分/嵌入/检索/重排），每一环都可能是短板 |
| 能注入私有、模型没见过的知识 | 效果强依赖"数据质量"和"检索质量"，垃圾进垃圾出 |
| 答案可溯源、可核查 | 单点事实强，多跳推理/跨文档综合弱（基础 RAG） |
| 显著降低幻觉（不是消除） | 检索到错误/陈旧内容时，会"有据可依"地给出错误答案 |
| 边际成本低，比长上下文省钱 | 在线链路更长，延迟和工程复杂度更高 |
| 全套开源件成熟，不用造轮子 | "选型 + 调优 + 数据治理 + 更新链路"是持续的工程投入，不是一次性的 |
一句话概括这一节：RAG 的门槛低、天花板高。跑通一个 demo 是一周的事，做出一个生产级可信系统是持续几个月的工程。 而这几个月的工作，绝大部分不是"算法"，是"把每一环的短板一个个补平"。下一节就讲怎么补。
五、优化方案：按链路逐环补短板
上一节说 RAG 的效果取决于"没有短板"。这一节就是逐环补短板的清单。
先给一个组织这些技术的经典框架，来自被引用最多的 RAG 综述（Gao 等，arXiv:2312.10997）——它把 RAG 分成三代：
- Naive RAG（朴素）：就是第二节那条最小链路，切分→嵌入→检索→塞进去。够跑 demo，不够扛生产。
- Advanced RAG（进阶）：在检索前和检索后都加优化——查询改写、混合检索、重排、上下文压缩。本节讲的绝大多数就是这一代，也是当前生产系统的主流形态。
- Modular RAG（模块化）：把各环节做成可编排、可循环的模块，能按需组合、多轮迭代——通往第六节的 Agentic RAG。
下面按"在链路的哪个位置动手"分四组。每条给"它解决什么 → 代价 → 什么时候值得上"。
5.1 查询前：让"问题"变得更好检索
用户的原始提问，往往不是最适合拿去检索的形式——太口语、太短、有指代、有歧义。在检索之前先加工一下问题，是性价比很高的一类优化。
查询改写 / 扩展（query rewriting / expansion）：用一个 LLM 把用户的口语问题改写成更规范、信息更全的检索语句，或者补上同义词。解决：用户问"这玩意儿咋弄"这种检索不友好的问题。代价：多一次 LLM 调用，增加延迟。何时上：用户提问普遍口语化、多轮对话有大量指代（"它""上面那个"）时。多轮对话里，还要做指代消解——把"它明年还能用吗"补全成"年假明年还能用吗"，否则检索到的是一堆无关内容。
多查询（multi-query）：把一个问题让 LLM 生成几个不同角度的变体，分别检索，再把结果合并去重。解决：单一表述可能只命中一部分相关文档。代价：检索次数翻几倍，成本和延迟上升。何时上：问题往往有多种问法、单次召回不全时。
HyDE（假设性文档嵌入）：反直觉但有效的一招——先让 LLM 凭空编一个"假想答案"，然后拿这个假答案去检索，而不是拿原问题。为什么有用：问题和答案在文字形态上差异很大（问题短、疑问句；答案长、陈述句），而"假答案"和"真文档"形态相近，向量更容易匹配上。代价：多一次生成、且假答案可能带偏。何时上：问题和文档表述差异大、直接用问题检索召回差时。
查询前优化的共同代价：延迟
上面这些都要在检索前多插一次（或几次）LLM 调用，直接加在用户等待时间上。所以它们不是"免费的午餐"——要和你的延迟预算算账。一个折中是只对"检索召回明显不足"的难问题触发这些重加工，简单问题走直路，这本身就是一种朴素的 Agentic 思路（第六节）。
5.2 检索中：从"只找相似"到"又准又全"
混合检索 + RRF 融合：向量检索（管语义）+ 关键词检索（管精确匹配）双路并行，用 RRF（倒数排名融合，只看排名不看原始分，规避两种分数量纲不可比）合并。这在 2026 年已经是生产 RAG 的默认标配，不是可选项。 它专治纯向量对"专有名词、型号、编号、代码符号"的死穴。代价：要维护两套索引。何时上：几乎总是——除非你的语料特别小（几十上百篇，此时混合反而可能不如纯向量，RRF 的默认参数会失灵）。
元数据过滤：检索前先用结构化条件缩小范围（部门、时间、文档类型）。解决：把"语义相似但事实不对"的干扰（比如去年的旧政策）直接挡在门外。代价：要求入库时认真存好元数据。何时上：知识库有明确的结构维度（时间、部门、产品线）时，几乎必上——它常常比调检索参数更能提升准确率。
调索引参数：召回不全就调大
ef_search（HNSW 的运行时搜索宽度）或nprobe（IVF 的查询簇数），用速度换召回。这是最直接的运行时旋钮。
5.3 检索后：把噪音清掉再喂给模型
检索为了保召回放宽了口子，返回的几十段里必然有噪音。喂给模型前，这一步专门做"去粗取精"。
重排（rerank）：加一个 cross-encoder 重排模型，把检索来的几十个候选精排，只留最相关的 3-5 个。前面 2.5 说过，这通常是 RAG 提升性价比最高的一步。 如果你的系统还没上 rerank，这是第一个该补的。
上下文压缩（context compression）：把留下的段落里，和问题无关的句子删掉，只保留相关部分再喂模型。解决：段落里往往只有一两句是关键，其余是陪衬，既占 prompt 又是噪音。代价：多一步处理、可能误删。何时上：chunk 切得较大、单段里无关内容多时。
重排后的"位置安排"：把最相关的材料放在 prompt 的开头和结尾，别埋在正中间——直接对冲 lost-in-the-middle（模型对上下文中间注意力最低）。这是零成本的一招，只是调整拼接顺序，却常常立竿见影。
5.4 生成时：逼模型老实用材料
材料干净了，最后靠 prompt 把模型"摁"在材料上：
- 硬指令约束：明确写"只依据参考资料回答，资料里没有的就说'无法确定'，不要编造"。解决：坑二里模型自由发挥的问题。这是最基本、也最有效的一条。
- 强制引用：要求模型给每句话标注来源编号
[1][2]。一举两得：既让答案可溯源，标引用这个动作本身又会"拽"着模型去逐句对照材料，间接压低幻觉。 - 拒答机制：允许并鼓励模型在材料不足时说"不知道"。反直觉但重要：一个"该说不知道时就说不知道"的 RAG，比一个"什么都敢答"的 RAG 可信得多。宁可漏答，不可错答——尤其在企业场景。
5.5 系统层：缓存与评测
语义缓存（semantic cache）：把"问题→答案"缓存起来，新问题来了先看有没有语义相近的老问题（用向量比一下），命中就直接返回。解决：高频重复问题反复走全链路的浪费。代价：要处理缓存失效（知识库更新后旧缓存要作废）。何时上：查询有明显热点、重复率高时，能大幅降本降延迟。
评测驱动迭代：这不是某一环的优化，而是让所有优化能被验证的前提——没有评测，你上面每一招都是"感觉变好了"，无法确认。第七节专门讲。
优化不是"全都上"，是"按失败案例上"
上面十几招，千万不要一次全堆上去——每一招都有代价（延迟、成本、复杂度），全上一遍你会得到一个又慢又贵又难维护的系统，还搞不清是哪招在起作用。
正确的姿势是评测驱动、单点验证：先搭一个有真实失败案例的评测集，看你的 RAG 到底败在哪一环（召回？生成？多跳？），针对那一环上对应的优化，量出效果，再决定留不留。 优化 RAG 是一个"诊断—对症—验证"的循环，不是一张"最佳实践全家桶"清单。这也是为什么第七节的评测，是这一切的地基。
六、进阶形态：当基础 RAG 撞到天花板
第四节的坑三（多跳推理答不了）和坑五（版面信息丢失）、以及"一次检索不够用"的场景，靠调参补不平——它们是基础 RAG 的能力边界。2024-2026 年，RAG 演化出三条主要的进阶路线，各自撞开一堵墙。
6.1 GraphRAG：用知识图谱做"跨文档的关联"
解决的问题：基础 RAG 的检索是"找相似片段"，答不了"把分散在多篇文档里的信息串起来推理"的问题（坑三）。
核心思路：不只是把文档切块存向量，而是先用 LLM 从文档里抽取出实体和它们的关系（谁隶属谁、什么导致什么、A 和 B 什么关系），构建成一张知识图谱。检索时不只是找相似段落，而是能沿着关系链跳转——从实体 A 找到关联的 B，再到 C，把一条推理链上的信息都聚起来。这样"对比类、汇总类、多跳类"问题就有解了。
微软 2024 年的 GraphRAG 立起了这条路的标杆，但它的问题也很快暴露：
GraphRAG 别急着上生产
微软版 GraphRAG 有三个公认的硬伤：构建极贵（要用 LLM 把整个知识库的实体关系抽一遍，大语料的建图成本可能高得吓人）、构建慢、以及最要命的——不支持增量更新（知识库新增一批文档，往往要把整张图重建，这对"活的"知识库几乎不可接受）。
所以 2025-2026 出现了一批更务实的变体：一类是"结构更轻的图"（LightRAG、nano-graphrag、MiniRAG 这类，简化图结构降本）；一类是"直接压构建成本"（LazyGraphRAG 等，把重活推迟到查询时按需做）。其中 HippoRAG 系列（借鉴神经科学、用 PageRank 类算法在图上传播）被反复点名为多跳推理里最省成本的方案之一。
一个反直觉的点：名字带"light"的不一定真便宜——有基准显示某些轻量方案的构建 token 消耗反而偏高。别看名字，看你自己语料上的实测成本。
判据：只有当你的失败案例确实集中在多跳、跨文档综合上，且这些问题有足够业务价值，才值得付 GraphRAG 的建图成本。如果你的问题大多是单点事实查询，GraphRAG 是杀鸡用牛刀，纯属烧钱。（本文提到的成本量级来自社区实测和论文估算，会随模型价格变化，仅供判断数量级，别当权威定论。）
6.2 Agentic RAG：让模型自己决定"要不要查、查几次"
解决的问题：基础 RAG 是"固定流程"——不管什么问题，都雷打不动地检索一次、生成一次。但现实是：有的问题根本不用检索（"你好"），有的问题一次检索不够（需要先查 A、根据 A 的结果再查 B），有的检索回来一看质量太差、该换个方式重查。固定流程应付不了这些。
核心思路：把"要不要检索、检索什么、检索够没够、要不要再查一轮"的决策权交给模型，让它像 agent 一样自主循环。这正是 Agent 那套"感知—决策—行动"的循环用在了检索上。截至 2026 年，它已经从"实验性玩具"变成"基础 RAG 触顶后的成熟架构"。几个代表范式：
- Self-RAG（自反思 RAG）：让模型在生成过程中吐出"反思标记"，自评"这里要不要检索""证据够不够""我的答案有没有依据"。强，但和特定模型训练绑定较深。
- CRAG / Corrective RAG（纠错 RAG）：用一个独立的"检索质量评估器"给检索结果打分——判成"可靠 / 不可靠 / 模棱两可"，不可靠时自动改走网络搜索等兜底，再生成。因为它和具体模型无关，被认为最适合企业落地。
- Adaptive RAG（自适应 RAG）：做"路由"——按问题难度选路径，简单问题直接答、中等走一次检索、复杂走多轮，把算力花在刀刃上。
框架侧，2026 年比较收敛的组合是用 LangGraph 做流程编排 + 用 LlamaIndex 做检索层。想深入可参考 Agentic RAG 综述（arXiv:2501.09136）。
判据：当你发现"一次固定检索"满足不了需求——有大量需要多步查证、或需要按难度分流的问题——再上 Agentic RAG。它的代价是延迟和成本不可控（模型可能循环好几轮，每轮都是 LLM 调用 + 检索），所以要设好"最多查几轮"的熔断。
6.3 多模态 RAG：让表格和图片也能被检索
解决的问题：坑五——表格、图表、PDF 版面里的信息，在传统"抽成纯文本"的解析里全丢了。
核心思路：不再把文档硬抽成文本，而是直接把页面当图片处理。以 ColPali 为代表的"视觉 RAG"路线，用多模态模型把 PDF 页面整页编码成向量（跳过 OCR 这个丢信息的环节），保住表格结构、图表、版面布局。检索时直接匹配"最相关的页面图像"，再交给多模态大模型看图回答。
截至 2026 年，这条线的工程化程度已经相当高，被视为高精度文档 RAG 的主流模式之一。它依赖前面 3.1 提过的 late-interaction（延迟交互 / 多向量） 技术，所以要求你的向量库支持多向量存储。另一条更轻的路是用原生多模态的嵌入模型（一个模型同时能编码文字和图片），省掉复杂的 OCR 管线。
判据：如果你的知识库重度依赖表格、图表、扫描件、复杂版面（金融报表、产品手册、科研论文、合同），且传统解析明显丢信息，多模态 RAG 值得上。如果你的文档就是纯文字为主，没必要背上它的算力开销。
七、怎么评测你的 RAG：一切优化的地基
前面反复说"评测驱动"。这一节把它讲透——因为没有评测，前面所有优化都是"我感觉好像变好了"，你既不知道该优化哪一环，也不知道优化完到底有没有用，甚至改坏了都不知道。
RAG 评测难在它有两段：检索得好不好、生成得好不好，要分开量。目前事实标准是 RAGAS 定义、全行业采纳的四个核心指标，正好一边两个：
检索侧（材料捞得对不对）：
- Context Precision（上下文精确率）：检索回来的这些段落，有多少是真正相关的？衡量的是"信噪比"——捞回来一堆里混了多少没用的。低了说明检索太宽、噪音多，该收紧或加重排。
- Context Recall（上下文召回率）：回答问题所需要的信息，有多少真的被检索到了？衡量的是"漏没漏"。这是 RAG 的命门指标（对应坑一），低了说明正确答案压根没进来，后面白搭。（注意：算这个需要人工标注"标准答案该用哪些材料"，成本较高。）
生成侧（答案答得对不对）：
- Faithfulness（忠实度）：答案里的每一条主张，是不是都能在检索到的材料里找到支撑？衡量的是"有没有编"——这是直接对标幻觉的指标（对应坑二）。低了说明模型在自由发挥、没老实用材料。
- Answer Relevancy（答案相关性）：答案切不切题，有没有答非所问、答一堆废话。
这四个指标合起来，能帮你把问题定位到具体环节：召回率低 → 修检索；精确率低 → 加重排/压缩；忠实度低 → 修 prompt 约束；相关性低 → 修生成。这就是"诊断—对症"里的"诊断"。
工具上，三个主流的分工也很清楚，是分层组合用，不是三选一：
| 工具 | 定位 | 适合 |
|---|---|---|
| RAGAS | 四大指标、多数免人工标注、上手快 | 早期实验、快速摸底 |
| DeepEval | 指标多、原生集成测试框架（像写单元测试一样写评测） | 接入 CI/CD 做回归门禁（改动后自动跑，掉分就拦住） |
| TruLens | feedback function + 全链路追踪 | 生产环境的持续监控 |
评测跑分高 ≠ 你的 RAG 可信（一个必须知道的盲点）
这是 2026 年最值得记住的一个反直觉点：上面这些评测框架，用的都是"让大模型当裁判"（LLM-as-judge），它们评的是"管线做得好不好"，不是"底层数据是真是假"。
什么意思？假设你的知识库里躺着一份三年前作废的旧政策。用户提问，RAG 忠实地检索到它、忠实地照它回答——这时候 Faithfulness（忠实度）会给出很高的分（因为答案确实"忠于"检索到的材料），Context Precision 也不低（材料确实"相关"）。评测一片飘红，业务答案却是错的。
也就是说，一个 0.95 忠实度的 RAG，完全可能因为数据本身陈旧/错误，而给出危害业务的答案。 评测能保证"模型没在瞎编"，但保证不了"材料本身是对的"。有人把"上下文可信度 / 数据新鲜度"称为缺失的第五个评测维度——它不在任何自动跑分里，只能靠数据治理（坑六）来兜。
实践含义：别把评测分数当免罪金牌。跑分是"管线体检"，数据质量是另一回事，两个都要抓。
八、RAG 会被长上下文取代吗
这是每隔半年就被重新问一遍的问题——上下文窗口从几千 token 涨到几十万、上百万，很多人的第一反应是："既然能一次塞进整个知识库，还要 RAG 这套检索干嘛？直接全塞进去让模型自己看不就行了？"
截至 2026 年，这个问题其实已经有了相当稳固的共识，而且答案不是"取代"，是"互补"。三条理由：
第一，长上下文有个治不好的病：lost-in-the-middle（迷失在中间）。 把关键信息放在超长上下文的中间位置，模型的注意力明显低于开头和结尾，准确率显著下降。更麻烦的是——窗口越大，"中间"越大，这个问题不但不随窗口变大而消失，反而被放大。100 万 token 的窗口，不代表 100 万 token 都被"读进去"了。
第二，"宣称的长度"不等于"有效的长度"。 有评测（如 RULER 一类工作）反复发现：模型标称支持的上下文长度，和它真正能可靠利用的长度，往往有不小差距，尤其中小模型在长文本中段掉得厉害。"能塞进去"和"能用好"是两回事。
第三，成本和时效算不过来。 生产级 RAG 面对的是大语料 + 高频查询。每次查询都把整个知识库（哪怕只有一小部分相关）塞进窗口，等于每次都为海量无关 token 付费、付延迟。就算有 prompt 缓存帮忙省一点，也改不了"迷失在中间"这个准确率问题。而 RAG 只精选几段最相关的喂进去——又省钱、又躲开了中间迷失。
别从一个极端跳到另一个极端
澄清一下，免得矫枉过正："RAG 准确率一定高于长上下文"这个说法也不成立。 有评测（如 arXiv:2501.01880）对比下来是**"各有胜负、没有一方通吃"**——维基百科式的知识问答，长上下文往往更好；对话式、需要精准定位的场景，RAG 更好。
所以公允的结论是：RAG 的结构性优势在成本、时效、和可溯源上（这几条长上下文补不了，尤其"能指出答案来自哪份文档"这一点，是架构决定的，不是跑分决定的）；而准确率高低取决于任务类型和模型，不能一概而论。
那么当下的赢家模式是什么？RAG 先精选 + 长上下文再推理——用 RAG 从海量知识里快速筛出最相关的一批材料（解决"从哪找"和"成本"），再把这批（而不是全库）交给长上下文窗口去做深度理解和推理（发挥"一次看得多"的长处）。它们不是替代关系，是流水线上的上下游。
所以回到那个反复被问的问题：上下文窗口再大，也不会让 RAG 退休。窗口变大改变的是"什么时候该用哪个、怎么配合用"，不是"要不要用 RAG"。
结语
回到开头那句"RAG 不就是切一切、算个向量、塞进 prompt 吗"。
现在你知道，这句话描述的是 Naive RAG——那个五分钟能跑通、也只能跑通 demo 的版本。而它和一个能上生产的可信系统之间，隔着解析、切分、混合检索、重排、查询改写、上下文压缩、拒答约束、数据治理、评测闭环……以及在这一切之上的进阶形态。
这条链路上，有三件事我觉得最值得记住：
第一，RAG 的难点不在"算法高深"，在"链路没有短板"。 它没有一个环节需要你发明新算法，但任何一环拉胯——切分毁了语义、召回漏了答案、生成不用材料、数据本身是错的——最终结果就崩。所以救火时的第一直觉不该是"调 prompt"，而是"先看正确答案到底检索出来没有"。检索没捞到的，后面全链路都救不回来，这是 RAG 区别于普通问答最根本的一条。
第二，优化 RAG 是"诊断—对症—验证"的循环，不是堆一张最佳实践清单。 本文列了十几种优化，但把它们一次全堆上去，你只会得到一个又慢又贵又说不清哪招在起效的系统。正确的路径永远是：先有评测、看清败在哪一环、针对性上一招、量出效果、再决定去留。没有评测，所有优化都是自我感动。
第三，RAG 不是"要不要用"的问题，是"和谁怎么配"的问题。 它和微调、和长上下文不是三选一的竞品，而是工具箱里各管一段的工具——RAG 注入会变的、私有的、要溯源的知识，微调改能力和风格，长上下文啃整篇。把它们当竞品是新手视角，当流水线才是工程视角。 上下文窗口再大，也取代不了"从海量知识里精准、便宜、可溯源地找出那几段"这件事——而这，正是 RAG 存在的理由。
参考与延伸
本文涉及的会随时间漂移的具体名次、版本号、成本数字，请以最新的官方榜单和 release notes 为准。几个相对稳定、可作深入起点的锚点：
- RAG 综述经典（Naive / Advanced / Modular 三分法的来源）：Gao 等，Retrieval-Augmented Generation for Large Language Models: A Survey（arXiv:2312.10997）
- Agentic RAG 综述：arXiv:2501.09136
- 长上下文 vs RAG 的对比评测：arXiv:2501.01880
同系列文章：《一次 LLM 请求的全链路解剖》（RAG 拼好的 prompt 最终就走这条链路）、《AI Agent 的长期记忆》（记忆检索和 RAG 是同一套骨架）、《到底什么是 Agent》（Agentic RAG 的思想源头）。