RAG — 给模型装上“外部大脑“

RAG — 给模型装上"外部大脑"

你花了两周把 Claude 接入客服系统，结果客户问"你们上周发布的新功能支持什么平台"，模型回答"我没有这方面的信息"。官网明明写了，模型就是不知道。

这篇文章讲清楚一件事：RAG 是什么、为什么需要它、它的工程原理是怎样的。读完你能自己判断在什么场景该用 RAG，以及用的时候哪些环节最容易出错。

一、先看问题有多痛

痛点 1：知识有"保质期"

LLM 的知识是训练时"烧进去"的。训练数据有截止日期——这意味着截止日期之后发生的一切，模型都不知道。

用户：Anthropic 最新的模型叫什么？ 模型：据我所知，Anthropic 最新的模型是 Claude 3.5 Sonnet... ← 实际上 Claude Sonnet 4.6 早就发布了 模型的训练数据停在了更早的时间点

你可能会说：“上下文窗口现在都 200K Token 了，把文档全塞进去不就行了？”

算一笔账：一家中等规模公司的内部文档（产品手册 + HR 政策 + 技术文档 + 销售资料），通常在 50 万到 200 万字之间。换算成 Token，大约75 万到 300 万 Token。200K 的上下文窗口塞不下，即使塞下了，按 Claude Sonnet 4.6 的价格（$3/1M 输入 Token），每次对话成本在 $2.25 到 $9——一天处理 1000 次咨询，光输入 Token 就要$2,250 到 $9,000/天。

而且"全塞进去"还有一个隐蔽问题：模型在超长上下文中会"迷路"。多项研究表明，当相关信息被埋在上下文中间位置时，模型的召回率会显著下降——这就是"Lost in the Middle"现象。

痛点 2：模型永远不知道你公司的事

员工：年假需要提前几天申请？ 模型：一般来说，建议提前 1-2 周申请年假... ← HR 手册明确写着"5 个工作日" 模型给的是互联网上的"通用答案"

这两个痛点的本质一样：模型的知识是静态的，而现实世界是动态的。

微调不是答案

面对"模型不知道内部文档"这个问题，工程师的第一反应通常是微调。

现实是：微调一个 7B 参数模型需要 40-80 GPU 小时，云端成本约 $500-1,500；70B 模型直接乘以 10。更关键的是，你的文档每周都在更新——你愿意每周花上万元、等几天，只为让模型"记住"最新的产品价格吗？

RAG 的每次对话成本之所以低，是因为它只检索最相关的几段文字（通常 3-10 段，总计 1,000-3,000 Token），而不是把所有文档都送给模型。

二、RAG 到底怎么工作

RAG 的全称是Retrieval-Augmented Generation（检索增强生成）。核心思路用一句话说清楚：

不要把知识"烧进"模型，而是在回答问题时，先去知识库里搜相关内容，把搜到的片段塞进 Prompt，再让模型基于这些片段回答。

整个流程分两个阶段：

阶段一：离线索引（Indexing）

把你的文档变成"可搜索"的状态。

原始文档 → 分块(Chunking) → 向量化(Embedding) → 存入向量数据库

1. 分块：把长文档切成小段（Chunk），每段通常 200-800 Token
2. 向量化：用 Embedding 模型把每段文字转成一个高维向量（比如 1024 维的浮点数组）
3. 存储：把向量存到向量数据库（Pinecone、Weaviate、Milvus、Qdrant 等）

阶段二：在线检索 + 生成（Retrieval + Generation）

用户提问时，实时执行"搜索 → 拼接 → 回答"。

用户提问 → 问题向量化 → 在向量数据库中搜索 Top-K 相似段落 → 把段落塞进 Prompt → LLM 生成回答

整个过程对用户完全透明——用户只看到一个"聪明的 AI"在回答，不知道后面有一套检索系统在运转。

一个完整的 RAG 交互示例

用户问题："年假需要提前几天申请？" Step 1 - 向量化问题 "年假需要提前几天申请" → [0.023, -0.117, 0.445, ..., 0.012] (1024维向量) Step 2 - 向量检索 Top-3 相似度 0.94: "员工年假申请需提前 5 个工作日提交审批" 相似度 0.87: "病假可当天提交，事后补齐证明材料" 相似度 0.83: "年假超过 5 天需部门总监审批" Step 3 - 拼接 Prompt "请根据以下公司文档回答用户问题： [文档1] 员工年假申请需提前 5 个工作日提交审批 [文档2] 病假可当天提交，事后补齐证明材料 [文档3] 年假超过 5 天需部门总监审批 用户问题：年假需要提前几天申请？" Step 4 - LLM 回答 "根据公司规定，年假需要提前 5 个工作日申请。 如果年假超过 5 天，还需要部门总监审批。"

注意：模型的回答完全基于检索到的文档，不再是"一般来说"的通用答案。这就是 RAG 的核心价值——让模型的回答有据可查。

三、核心原理：向量和相似度

RAG 能工作，依赖一个关键技术：向量相似度搜索。要理解这个，先要搞懂"Embedding 是什么"。

Embedding：把语义变成坐标

人类判断两句话是否相近，靠的是"语感"。计算机没有语感，它需要一种可计算的方式来衡量语义距离。

Embedding 模型的工作方式是：把一段文字映射到一个高维空间中的一个点。语义相近的文字，在这个空间中的距离也近。

"猫在沙发上睡觉" → [0.23, -0.11, 0.45, ..., 0.08] "小猫躺在沙发上" → [0.22, -0.12, 0.44, ..., 0.09] ← 距离很近，语义相似 "今天股市大跌" → [-0.67, 0.33, -0.21, ..., 0.55] ← 距离很远，语义无关

这不是简单的关键词匹配。传统搜索引擎用关键词匹配（BM25），搜"年假申请"只能匹配到包含"年假"或"申请"这两个词的文档。但向量搜索能理解语义——搜"年假申请"也能匹配到"带薪休假流程"，因为它们在向量空间中距离很近。

相似度计算：余弦相似度

两个向量之间的"距离"最常用余弦相似度来衡量：

A · B cos(θ) = ────────── |A| × |B| 值域：[-1, 1] 1.0 = 完全相同 0.0 = 完全无关 -1.0 = 完全相反

实际工程中，检索时计算用户问题向量与数据库中所有文档向量的余弦相似度，取 Top-K（通常 K=3 到 10）最相似的结果返回。

向量数据库的作用

暴力计算所有向量的余弦相似度，在小数据集上可行（1 万条文档，毫秒级）。但当文档量到百万级时，暴力搜索需要数秒——对实时系统来说太慢了。

向量数据库通过ANN（Approximate Nearest Neighbor，近似最近邻）算法加速搜索。主流算法包括 HNSW（分层可导航小世界图）和 IVF（倒排文件索引），能把搜索时间从秒级降到毫秒级，代价是放弃约 1-5% 的精度。

四、最容易出错的环节：分块策略

RAG 系统中，分块策略（Chunking Strategy）对检索质量的影响，等于甚至超过 Embedding 模型的选择。这是 Vectara 在 NAACL 2025 会议上发表的研究结论。Weaviate 2025 年 9 月的基准测试进一步显示：错误的分块策略和正确的分块策略之间，召回率差距可达9%。

为什么分块这么重要？

想象你有一本 500 页的员工手册。如果你把整本书当成一个 Chunk，用户问"年假提前几天"时，模型收到的是 50 万字的信息，关键答案被淹没了。如果你每 50 个字切一块，“员工年假申请需提前 5 个工作日"这句话可能被拆成两块——一块包含"年假申请需提前”，另一块包含"5 个工作日提交审批"——语义被打断了。

分块太大：关键信息被稀释。分块太小：语义被打断。

三种主流分块策略

策略一：固定大小分块（Fixed-size Chunking）

最简单——每 512 Token 切一刀，相邻块之间重叠 50-100 Token。

优点：实现简单，适合结构均匀的文档 缺点：不关心语义边界，可能把一个完整段落从中间切断 适用：日志、FAQ、结构化文档

策略二：语义分块（Semantic Chunking）

用 Embedding 模型计算相邻句子的语义相似度，在相似度骤降的地方切分——这意味着每个 Chunk 内部语义连贯，切分点在话题转换处。

优点：保持语义完整性 缺点：计算成本高（需要先对每句话做 Embedding） 适用：长文章、技术文档、叙述性内容

策略三：自适应分块（Adaptive / Agentic Chunking）

结合文档结构（标题、段落、列表）和语义信号，自动决定切分点。MDPI Bioengineering 2025 年 11 月的研究显示，自适应分块在检索准确率上达到87%，而固定大小分块只有13%。

优点：效果最好 缺点：实现复杂度最高 适用：异构文档（既有表格又有自然语言的混合内容）

工程结论：如果你的文档类型单一且结构规整（比如 FAQ 列表），固定大小分块够用。如果文档类型混杂（PDF + Markdown + 网页），直接上语义分块或自适应分块——分块策略的投入产出比远高于换一个更贵的 Embedding 模型。

五、让检索更准：混合搜索 + 重排序

纯向量搜索有一个盲区：它擅长理解语义，但对精确关键词匹配反而不如传统搜索。

用户问：错误码 ERR_4012 是什么意思？ 向量搜索可能返回： × "常见错误码列表及其含义"（语义相近但不精确） × "HTTP 401 认证失败的处理方式"（语义相近但错误） BM25 关键词搜索会直接匹配到： ✓ "ERR_4012: 用户会话过期，需要重新登录"

混合搜索（Hybrid Search）

把向量搜索和 BM25 关键词搜索的结果合并，用RRF（Reciprocal Rank Fusion，倒数排名融合）算法统一排序。

混合搜索 = 向量搜索结果 ∪ BM25搜索结果 → RRF 融合排序 RRF 公式：score(d) = Σ 1/(k + rank_i(d)) k 通常取 60，rank_i(d) 是文档 d 在第 i 个搜索系统中的排名

混合搜索在几乎所有场景中都优于纯向量搜索或纯关键词搜索。Weaviate、Qdrant 等主流向量数据库都原生支持混合搜索。

重排序（Re-ranking）

向量搜索返回的 Top-K 结果，排序未必最优。重排序用更强的**交叉编码器（Cross-Encoder）**模型对候选文档重新打分。

向量搜索用的是双编码器——问题和文档分别编码成向量，然后算相似度。优点是快（文档向量可以预计算），缺点是精度有限。

交叉编码器把问题和文档拼在一起送进模型，让模型直接判断"这段文档是否回答了这个问题"。精度高很多，但速度慢——所以只用在 Top-K 结果的重排序上（通常 K=20 到 50），不用在全库搜索上。

完整检索流程： 用户问题 → 混合搜索(向量 + BM25) → Top-50 候选 → Cross-Encoder 重排序 → Top-5 最终结果 → 拼接到 Prompt → LLM 生成回答

Towards Data Science 的生产 RAG 测试数据显示，加入混合搜索和重排序后，Answer Relevancy（答案相关性）和 Faithfulness（答案忠实度）在每个阶段都有提升——从基础向量搜索到混合搜索，再到重排序，是累积收益。

六、RAG 的评估：怎么知道你的系统好不好

RAG 系统上线后，你需要回答一个关键问题：检索到的文档是不是对的？生成的回答是不是准的？

RAGAS 框架

RAGAS（Retrieval-Augmented Generation Assessment）是目前最常用的 RAG 评估框架，它定义了四个核心指标：

工程实践中最关键的是 Faithfulness 和 Context Recall。Faithfulness 低意味着模型在"幻觉"——用自己编的内容回答而不是基于文档；Context Recall 低意味着检索没找到正确的文档，模型巧妇难为无米之炊。

七、什么时候该用 RAG，什么时候不该

该用 RAG 的场景

• 私有知识问答：公司内部文档、产品手册、HR 政策
• 实时性要求高：新闻、股票、产品更新等信息每天变化
• 需要溯源：法律、合规、医疗等场景，回答必须标注信息来源
• 文档量大：超过上下文窗口能容纳的量（> 5 万字）

不该用 RAG 的场景

• 文档量小于 5 万字：直接塞进上下文窗口更简单、效果更好
• 需要改变模型的"说话风格"：这是微调的领域，RAG 解决不了
• 推理密集型任务：数学证明、代码生成等不依赖外部知识的任务
• 训练数据已经覆盖：问通用知识（“什么是 HTTP 协议”），模型本来就知道

一句话工程结论

RAG 解决的是"知识注入"问题，不是"能力提升"问题。如果模型的问题是"不知道"，用 RAG；如果问题是"知道但做不好"，用微调或 Prompt Engineering。

八、总结

RAG 的本质是一个工程范式：不改模型，改输入。

传统方式：用户问题 → LLM → 回答（可能幻觉） RAG 方式：用户问题 → 检索相关文档 → 文档 + 问题 → LLM → 有据可查的回答

整个系统的质量取决于四个环节，按影响力排序：

1. 分块策略——决定检索能不能找到完整的、语义连贯的文档片段
2. 检索策略——混合搜索 + 重排序 > 纯向量搜索 > 纯关键词搜索
3. Embedding 模型——影响向量质量，但影响力低于分块策略
4. LLM 生成质量——在前三步都做好的前提下，差异最小

如果你正在搭建一个 RAG 系统，把 80% 的精力放在分块和检索策略上，而不是纠结用哪个 Embedding 模型或哪个向量数据库。

参考来源：

• Vectara, “Impact of Chunking on RAG Performance”, NAACL 2025
• Weaviate, “Chunking Strategy Benchmark”, September 2025
• MDPI Bioengineering, “Adaptive Chunking for RAG Systems”, November 2025
• Towards Data Science, “Hybrid Search and Re-Ranking in Production RAG”, 2025
• Angelo Sorte, “RAG Architectures Every AI Developer Must Know in 2026”, Medium, February 2026

这里是引用
https://blog.csdn.net/zhailuxu/category_13179845.html