RAG 不是一个新技术。
它的核心那块------把文字变成坐标，然后找坐标最近的邻居------1970 年代的搜索引擎就在用了。2013 年 Word2Vec 让"词变向量"成为主流，2019 年前后 Milvus、Pinecone 这类专业向量数据库陆续出现，2020 年 RAG 的论文发表，比 ChatGPT 还早两年多。今天说的 RAG，本质是把这套几十年的老检索技术，拼在了一个新的生成模型前面。
也正因为老，它在今天的技术话题里显得不那么高级。大家在追 Agentic、多模态、各种新框架，这时候讲 RAG，像是在讲一件早就该翻过去的事。
但有一个判断需要拆开：一项技术"听起来不新"，和"做起来不难"，是两回事。
RAG 的机制确实简单，简单到一张四步流程图就能画完，任何人十分钟都能给别人讲明白。可在企业里真正落地过的人知道，那张图描述的是 RAG 顺利工作的样子；项目里绝大部分功夫，花在它不顺利的那几种状态上。
更关键的是它的位置：企业做 AI 落地，"让模型知道自己的业务知识"是所有应用绕不开的第一道关。 这一步不做，上面所有东西都建不起来。而这一步目前的标准答案，就是 RAG。
所以对做 AI 转型的人来说，RAG 不是"可以先随便看看"的东西，而是必经的第一项。它不新，但它难；它不高级，但它是地基。
这篇不讲那张谁都会画的流程图，讲那张图之外的四道坎。
一、RAG 是什么：回答之前，先查资料
一句话：RAG = 让模型在回答之前，先去查一遍资料。
它要解决的是模型知识的三重先天不足：训练截止之后的事不知道、公司私有的资料进不去、不知道的时候它会编。前两条决定它必须能"读到"外部资料，第三条决定它必须被约束着读。
链路分两段。准备阶段 做一次：把文档切块，每块转成向量（一串数字坐标），存进向量库。回答阶段每次问都走：问题也转成向量，去库里找最接近的几块，把这几块和问题一起交给模型，生成答案。
这条线是 RAG 的"正常路径"。所有 RAG 入门内容都这么写，也没写错。
但这条路径描述的是 RAG 工作顺利的样子。 项目做久了会发现，RAG 的功夫几乎不花在这条线上，而是花在四种非正常状态上------它们出现的频率比正常状态高得多。不过在讲这四种状态之前，得先纠正一个更基础的误会。
二、检索不是"搜关键词"，是"在地图上找邻居"
一个很自然的假设是：RAG 的检索就是搜索引擎那种搜索------输入"高温储存上限"，把含这些词的文档捞出来。
对了一半。关键词搜索做的是字面匹配，它不懂意思：搜"怎么给电池降温"，它不会因为"降温"和"温度上限"意思相近，就把相关标准递过来。
向量检索不是这个逻辑。它把每段资料变成一个坐标，意思相近的文字，坐标就靠得近------"锂电池"和"电池"住同一个街区，"高温"和"温度上限"在斜对面。提问时把问题也变成一个坐标，然后在地图上找离它最近的几个点，取出对应的原文。
与其说这是"搜索"，不如说是"定位"------不是在字里找字，是在一张语义地图上找邻居。
三、大模型"接话茬"，向量"看地图"
既然检索和生成拼在一条链路上，很容易以为它们是同一套逻辑。其实不是。
一个常见的直觉是："模型预测下一个字，依据的也是整句的意思啊，不然它凭什么接得合适？"------这个直觉完全正确。预测下一个字确实要先理解整句。但"理解整句"之后，两个动作就分道扬镳了：
| 生成（预测下一个 token） | 嵌入（把文字变向量） | |
|---|---|---|
| 读完整句干嘛 | 为了接着往下写 | 为了把它放上地图 |
| 操作方向 | 向前延伸（续写未来） | 整体压缩（提炼成一个点） |
| 产出 | 下一个词的概率分布 | 一个坐标点 |
| 类比 | 接话茬------听懂前面说的，好接下一句 | 归档员------读完一张卡，归类放进格子 |
机制上还有个硬差别：生成必须"只看前面" ------模型预测第 5 个字时只能看到前 4 个字，未来是被蒙住的，因为它要预测的正是后面的内容。嵌入能"看整段"------资料是已经写完的文本，可以从头到尾读一遍，再浓缩成一个点。
同一个脑子，干两件不同的活：一个把理解用在"续写"，一个把理解用在"定位"。
理解这个区别，是为了理解后面四道坎里的第一道------模型的本能是往下接，不是停下来判断。
四、正常路径之外的四道坎
坎一：查不到
模型的本能不是"诚实说不知道"，而是硬答。
给模型一段资料和一个问题，它的默认行为是"生成一段通顺的回答"，不是"先判断资料够不够"。资料不够它不会停，它会用自己脑子里的东西把空缺补上------这就是幻觉在 RAG 里的回归路径。（也正是上一节说的"接话茬"本能在起作用。）
所以指望在提示词里写一句"资料里没有就直说不知道"就解决问题，是想当然。"该拒答时拒答"是一项需要被专门训练出来的能力，不是模型的自然行为。做过的项目里，模型在未经针对性训练前几乎做不到正确拒答，专门训过之后才能稳定做到------这个能力的有无，是两套完全不同的系统。
这里还有一层更值得玩味的东西：在同一个产品里，"拒答"既是必须的能力，又是明确的缺陷。
- 常规问答场景：查不到就说"没有"，这是对的，甚至可以写进验收标准
- 文档总结、差异对比场景：回答"未检索到相关内容"，直接判不合格
差别在于后一种场景里，资料就摆在手上，任务是"基于给定文档产出总结"，系统没有拒绝的权利------拒答在这里不是安全兜底，是任务失败。
同一个动作，在一条产品线里既是正确答案又是错误答案，分界线是场景，不是技术。 这类判断通用教程不会讲，因为它不是知识，是产品决策。
还有一个附带代价值得记住：为了教会模型拒答而做的微调，可能同时削弱它别的能力------拒答学会了，简答掉了下去。治一个坑挖出另一个坑，这在真实项目里发生过。
坎二：查太多
不是查不到才叫失败，查一堆同样是失败。
一个真实出现过的缺陷形态：检索环节不精准，不会匹配到真正相关的那几份文档，而是把知识库里的文档大面积铺给模型。表面看"资料给足了"，实际上上下文被无关内容稀释、模型注意力被带偏、答案看起来有依据而依据是错的，还白白烧掉大量 token。
为什么它比"查不到"更危险？因为它伪装成了正常。查不到，系统至少知道自己没查到；查太多，系统以为自己在正常工作，输出一份看起来很扎实的答案，错误被藏在"有依据"的外观里。
这里牵出两个落地细节。第一，向量检索找的是"意思像 "，不是"能回答 "------问某个指标的上限，语义上最接近的那块可能是一篇讲这个指标影响的文章，意思很像，但不回答问题。所以好的 RAG 在"找邻居"之后还有一道精挑（重排序），专门把"意思像但不回答"的压下去。第二，入库和查询必须用同一个 embedding 模型，否则等于在两套不同刻度的地图之间算距离。
一个旁证：翻真实项目的预算表，花在"问题改写、问题路由、重排优化"这些检索质量环节上的投入，远多于花在"切块 + 向量化 + 生成"这条主线上的。
如果 RAG 真的就是"检索 + 生成"四个字，钱不该这么花。预算是不会说谎的。
坎三：查到冲突
知识库里两份资料互相矛盾时，怎么办？ 四种做法，好坏差别很大：
| 做法 | 评价 |
|---|---|
| 随便挑一个答 | 最差。凭空制造确定性，用户无从察觉 |
| 直接拒答 | 看起来安全，其实是懒政------把判断责任推给用户，却不给判断材料 |
| 把两边缝合起来答 | 最危险。这正是模型混合上下文时的默认行为，会生成一个"谁都不是"的答案 |
| 两个答案连同各自依据都摆出来，标注"存在冲突"，让用户裁决 | 对的做法 |
第三种值得单独说：模型面对两份冲突材料时，本能不是"裁决"而是"调和"------它会写出"一般在 A 到 B 之间，具体视情况而定"这样的话。表面周全，实则两边都不对，而且无法溯源。这不是模型不够聪明，是它的工作方式就是生成通顺的话，不是审校证据。
第四种明明最好，为什么行业里少见？不是不知道好，是被验收机制逼的。 如果验收是让评委模型逐条判"答案是否正确"，那"展示两个冲突答案"很难被判对------评委模型的判定模板认的是"有没有给出确定答案"。于是项目组在"能被判对"和"体验更好"之间选了前者。
这是验收机制的妥协，不是设计上的最优解。看清这一点就知道该往哪改：改验收口径，而不是改模型。
坎四：查到但不该给
前三道坎是"答不好"，这第四道是"事故"。
检索到 ≠ 允许你看。 知识库里确实有这段内容，检索也命中了，但当前用户没有权限看。
这一类要求零容忍，覆盖范围比想象的宽：无权用户不该在结果里看到标题、摘要、片段、引用、答案------任何一个都不行。因为片段只要露出来一点，信息就已经泄漏了。
由此推出一条容易做错的工程原则：权限过滤必须在检索阶段执行，不能等生成完了再删。 只要无权内容进了上下文，它就可能以某种形式出现在生成结果里------改述、暗示、被当成背景知识用。等在输出端过滤，是在漏了之后堵。
前三道坎做不好，是"这个系统不太好用"；第四道做不好，是"这个系统不能用"。
五、RAG 治不了的三件事
说完成功路径之外的四种状态，还得说清 RAG 的边界------这三件事它做不到，且都不是靠调它能解决的：
第一，知识库里真没有的，RAG 变不出来。 这是数据问题不是模型问题，而且它往往是"拒答率高"的真正根因。看到一堆"未检索到"的日志，第一反应不该是改提示词，而是回头查知识库覆盖率------很多时候不是没查到，是切块把资料切碎了，或者压根没入库。
第二，检索到的资料本身是错的、过期的。 RAG 只负责"有据"，不负责"据是对的"。库里存着旧版标准，它会一本正经引用旧版条款告诉你答案------来源是真的、条款是真的、结论是错的。最麻烦的是用户看到"有依据"就信了。这是数据治理的活。
第三，模型乱说你的知识。 有一类内容格式极其严格------物料编号、标准条款号、工艺参数。模型一旦自由发挥，就会编出"格式看起来对、实际不存在"的值。这种情况 RAG 拦不住：资料明明喂进去了，它照样编。因为问题不出在"它没看到"，出在"生成这一步没有被约束"。RAG 解决"模型看不到你的知识"，管不住"模型乱说你的知识"------后者要靠另一层：把领域规则显式定义出来，让输出必须通过校验。
六、什么时候选 RAG
| 场景 | 用什么 |
|---|---|
| 基于一堆文档 / 标准 / 制度做问答、总结、提取 | RAG |
| 需要联网、调工具、多步操作完成一件事 | Agent |
| 要深度改变模型的"气质"（风格、领域行为） | Fine-tuning（下篇） |
| 简单生成，模型本来就擅长 | Prompt 就够 |
一句话判断：答案是"某份文档里写了什么"，用 RAG；答案需要"做一系列动作才能得到"，用 Agent。
七、收尾
RAG = 检索 + 生成。这个定义没有错，但它描述的是正常路径。
而真实项目里决定成败的，是四道坎：查不到、查太多、查到冲突、查到但不该给。
它们没有一道在"检索 + 生成"这四个字里。所以当有人说"RAG 很简单"，他说的其实是"正常路径很简单"------这句话没错，只是没什么用。
RAG 真正值钱的部分，是让这四道坎每一道都有明确答案：拒答要专门训练、检索要精排、冲突要呈现而非回避、权限要在检索阶段就拦住。 这些东西没有一样是技术难题，全是产品判断------而它们决定了这套系统是"能用"还是"不能用"。
预告
到这里，五种主流范式讲了四种：Prompt、Skill、Agent、RAG。
最后一种叫 Fine-tuning（微调）。RAG 是"把知识喂给模型看"，微调是"把知识喂进模型脑子"------它直接改变模型本身，代价是贵、慢，知识更新还得重新训练。
什么场景值得花这个代价？下一篇：Fine-tuning------当 RAG 喂不动的时候。