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,50070B 模型直接乘以 10。更关键的是你的文档每周都在更新——你愿意每周花上万元、等几天只为让模型记住最新的产品价格吗方案成本更新速度适用场景微调$500-15,000/次几天到几周改变模型说话风格全量塞上下文$2-9/次对话实时文档 5 万字RAG$0.003-0.01/次对话分钟级文档量大、更新频繁RAG 的每次对话成本之所以低是因为它只检索最相关的几段文字通常 3-10 段总计 1,000-3,000 Token而不是把所有文档都送给模型。二、RAG 到底怎么工作RAG 的全称是Retrieval-Augmented Generation检索增强生成。核心思路用一句话说清楚不要把知识烧进模型而是在回答问题时先去知识库里搜相关内容把搜到的片段塞进 Prompt再让模型基于这些片段回答。整个流程分两个阶段阶段一离线索引Indexing把你的文档变成可搜索的状态。原始文档 → 分块(Chunking) → 向量化(Embedding) → 存入向量数据库分块把长文档切成小段Chunk每段通常 200-800 Token向量化用 Embedding 模型把每段文字转成一个高维向量比如 1024 维的浮点数组存储把向量存到向量数据库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通常 K3 到 10最相似的结果返回。向量数据库的作用暴力计算所有向量的余弦相似度在小数据集上可行1 万条文档毫秒级。但当文档量到百万级时暴力搜索需要数秒——对实时系统来说太慢了。向量数据库通过ANNApproximate Nearest Neighbor近似最近邻算法加速搜索。主流算法包括 HNSW分层可导航小世界图和 IVF倒排文件索引能把搜索时间从秒级降到毫秒级代价是放弃约 1-5% 的精度。向量数据库特点适用场景Pinecone全托管开箱即用快速上线、不想运维Weaviate开源支持混合搜索需要 BM25 向量混合Milvus开源超大规模十亿级向量Qdrant开源Rust 实现追求低延迟Chroma轻量嵌入式本地开发、原型验证四、最容易出错的环节分块策略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 关键词搜索的结果合并用RRFReciprocal Rank Fusion倒数排名融合算法统一排序。混合搜索 向量搜索结果 ∪ BM25搜索结果 → RRF 融合排序 RRF 公式score(d) Σ 1/(k rank_i(d)) k 通常取 60rank_i(d) 是文档 d 在第 i 个搜索系统中的排名混合搜索在几乎所有场景中都优于纯向量搜索或纯关键词搜索。Weaviate、Qdrant 等主流向量数据库都原生支持混合搜索。重排序Re-ranking向量搜索返回的 Top-K 结果排序未必最优。重排序用更强的**交叉编码器Cross-Encoder**模型对候选文档重新打分。向量搜索用的是双编码器——问题和文档分别编码成向量然后算相似度。优点是快文档向量可以预计算缺点是精度有限。交叉编码器把问题和文档拼在一起送进模型让模型直接判断这段文档是否回答了这个问题。精度高很多但速度慢——所以只用在 Top-K 结果的重排序上通常 K20 到 50不用在全库搜索上。完整检索流程 用户问题 → 混合搜索(向量 BM25) → Top-50 候选 → Cross-Encoder 重排序 → Top-5 最终结果 → 拼接到 Prompt → LLM 生成回答Towards Data Science 的生产 RAG 测试数据显示加入混合搜索和重排序后Answer Relevancy答案相关性和 Faithfulness答案忠实度在每个阶段都有提升——从基础向量搜索到混合搜索再到重排序是累积收益。六、RAG 的评估怎么知道你的系统好不好RAG 系统上线后你需要回答一个关键问题检索到的文档是不是对的生成的回答是不是准的RAGAS 框架RAGASRetrieval-Augmented Generation Assessment是目前最常用的 RAG 评估框架它定义了四个核心指标指标衡量什么计算方式Faithfulness忠实度回答是否只基于检索到的文档没有瞎编把回答拆成多个声明逐一检查每个声明是否有文档支撑Answer Relevancy答案相关性回答是否切题用 LLM 从回答反向生成问题看生成的问题和原问题多相似Context Precision上下文精度检索到的文档中有多少是真正相关的相关文档数 / 检索文档总数Context Recall上下文召回率回答所需的信息是否都被检索到了回答中有文档支撑的声明数 / 回答中的声明总数工程实践中最关键的是 Faithfulness 和 Context Recall。Faithfulness 低意味着模型在幻觉——用自己编的内容回答而不是基于文档Context Recall 低意味着检索没找到正确的文档模型巧妇难为无米之炊。七、什么时候该用 RAG什么时候不该该用 RAG 的场景私有知识问答公司内部文档、产品手册、HR 政策实时性要求高新闻、股票、产品更新等信息每天变化需要溯源法律、合规、医疗等场景回答必须标注信息来源文档量大超过上下文窗口能容纳的量 5 万字不该用 RAG 的场景文档量小于 5 万字直接塞进上下文窗口更简单、效果更好需要改变模型的说话风格这是微调的领域RAG 解决不了推理密集型任务数学证明、代码生成等不依赖外部知识的任务训练数据已经覆盖问通用知识“什么是 HTTP 协议”模型本来就知道一句话工程结论RAG 解决的是知识注入问题不是能力提升问题。如果模型的问题是不知道用 RAG如果问题是知道但做不好用微调或 Prompt Engineering。八、总结RAG 的本质是一个工程范式不改模型改输入。传统方式用户问题 → LLM → 回答可能幻觉 RAG 方式用户问题 → 检索相关文档 → 文档 问题 → LLM → 有据可查的回答整个系统的质量取决于四个环节按影响力排序分块策略——决定检索能不能找到完整的、语义连贯的文档片段检索策略——混合搜索 重排序 纯向量搜索 纯关键词搜索Embedding 模型——影响向量质量但影响力低于分块策略LLM 生成质量——在前三步都做好的前提下差异最小如果你正在搭建一个 RAG 系统把 80% 的精力放在分块和检索策略上而不是纠结用哪个 Embedding 模型或哪个向量数据库。参考来源Vectara, “Impact of Chunking on RAG Performance”, NAACL 2025Weaviate, “Chunking Strategy Benchmark”, September 2025MDPI Bioengineering, “Adaptive Chunking for RAG Systems”, November 2025Towards Data Science, “Hybrid Search and Re-Ranking in Production RAG”, 2025Angelo Sorte, “RAG Architectures Every AI Developer Must Know in 2026”, Medium, February 2026这里是引用https://blog.csdn.net/zhailuxu/category_13179845.html