你大概是在两个场景里搜到这个词的：一是别人说「我们知识库接了 RAG」，你没听懂；二是模型答你公司的事，答得一本正经但全是编的，你怀疑该上检索。这篇不堆论文词，就讲清 RAG 三个字拆开各自指什么、它替模型补上了哪块短板、什么情况下它反而不划算，最后给一份能照着走的落地顺序。
你大概是在两个场景里搜到这个词的：一是同事说「我们知识库接了 RAG」，你没听懂还要点头；二是你问模型自家公司的事，它答得特别自信，但一核对全是编的，你怀疑得给它接点资料。这篇不堆论文词，就把 RAG 三个字母拆开讲清各自指什么、它替模型补上了哪块短板、什么情况下反而不划算。
先给一句能记住的话：RAG 就是让模型开卷考试。它不靠训练时背下来的东西回答，而是每次答题前先去你的资料里翻一翻，把翻到的几页摊在桌上，再照着这几页组织语言。所以它不是模型变聪明了，是你在模型外面搭了一套「翻书—递纸条」的流程。
RAG 三个字母分别指什么
- Retrieval（检索）
- 先从你自己的资料里捞出跟这个问题最相关的几段，不是让模型凭记忆直接答
- Augmented（增强）
- 把这些捞出来的片段当成补充材料，和用户的原始问题一起塞进这次请求的上下文里
- Generation（生成）
- 模型只负责基于「问题 + 捞出来的材料」组织语言，把答案说成人话输出给你
三个字母里，真正决定成败的是第一个。检索捞错了，后面生成再流畅也是错的，而且错得很像真的。很多团队抱怨「上了 RAG 还是胡说」，追下去八成是切片太碎或者资料本身没洗干净，模型拿到手的材料就是断章取义的。
为什么不直接把资料贴进提示词
初学者最常见的做法是：把整份文档复制粘贴进对话，让模型照着答。资料只有一两页时确实能用，问题是一旦资料变多，这条路会同时撞上三堵墙。
- 上下文长度有限：资料一多就塞不下，硬塞进去还会稀释模型对真正问题的注意力，它开始答非所问
- 成本按次累加：每问一次就把全部资料重贴一遍，问十次付十次的钱，而其中九成内容是这次根本用不到的
- 维护说不清：资料更新后要回去改提示词，这些提示词散落在代码、配置和几个人的聊天记录里，改了哪一份没人说得清
- RAG 的做法是把资料放进一个可检索的库，按需取用，改资料不用改代码
不过要说明一点：如果你的资料总共就几百字、半年才更新一次，那手工把这段文字拼进提示词反而更省事，别为了架构好看去搭一套向量库。什么情况下值得上，看下一节。
什么情况该上 RAG，什么情况别上
| 你的情况 | 建议 | 理由 |
|---|---|---|
| 资料条目多、更新频繁 | 优先考虑 RAG | 按需检索，资料改了不用动代码 |
| 答案需要指明出自哪份文件 | 优先考虑 RAG | 能顺带把来源片段一起返回给用户核对 |
| 资料总共几百字、很少变 | 先手工拼接 | 一上来搭库属于杀鸡用牛刀 |
| 要的是实时数据（股价、库存） | 先看有没有现成接口 | RAG 查的是文档，不是实时数 |
| 问题靠通用常识就能答 | 不用 RAG | 检索反而引入无关材料干扰 |
还有个关键边界要记牢：RAG 治的是「模型不知道」，治不了「知道但算错」和「指令没听明白」。如果模型明明看到了正确材料，却算错了数或者格式一团糟，那是另一类问题，加检索库帮不上忙，得从提示词结构或者后处理去解决。
一个能跑的 RAG 最少要有哪几块
- 资料处理把 PDF、网页、表格洗成一段段纯文本；扫描件先做文字识别。别把图片或整页截图直接扔进流程，否则后面检索到的就是一堆乱码。
- 切片与入库按语义或固定长度把长文切成小段，用向量模型转成向量存进库里。切片太长会掺进无关内容，太短会丢上下文，得拿真实问题试几轮才定得下来。
- 召回把用户问题也转成向量，找出最相近的若干段。觉得不够准可以再叠一层重排，把候选段重新排个序再往下走。
- 拼装与回答把召回的段落按固定模板塞进请求，并明确要求模型只依据这些材料作答，材料里没有就说不知道。这一步不做约束，模型很容易自己加戏。
- 评测留一批有标准答案的问题，每次改切片策略或换模型都跑一遍，看答对比例有没有变化。没有这套评测，优化只能靠感觉。
这五块里，最容易被跳过的是评测和「没依据就说不知道」的约束。前者让你不知道自己改好还是改坏了，后者让模型在检索失败时仍然编出一个像样的答案。想知道各家中转站在长上下文和稳定性上的实测表现，可以去站内的检测页面对照当时的数字。
几个容易搞混的说法
- RAG 不是模型的一种能力，是应用层搭出来的一套流程，换哪个模型都不影响这套骨架
- RAG 不等于知识库：库是存资料的地方，RAG 是取用资料回答问题的方式，有库不一定有 RAG
- RAG 和微调不是二选一的对立面，一个管「查得到」，一个管「语气和格式稳」，任务不同可以并存
- RAG 和 Agent 也不在同一层：RAG 是给模型供料，Agent 是让模型自己决定要不要去查、查几次
搞混这些概念本身不影响你把东西跑起来，但会影响你在出问题时往哪个方向排查。比如模型答得流畅却没依据，问题多半在检索；答得有依据但格式乱，问题多半在提示词和生成约束。
下一步想动手之前，先确认你要接的模型在长上下文下表现稳不稳，再决定切片长度和召回条数。站内整理了各家模型资料与中转站可信度检测结果，相关数字以页面当时显示的为准。→常见问题
RAG 是不是就是把文档喂给模型训练一遍？
不是。训练/微调是改模型权重，成本高、周期长、改完不好回退；RAG 是在请求时临时把相关资料塞进上下文，资料改了下次请求就生效，模型本身一个参数都不动。两者解决的问题也不同，一个管查得到，一个管答得像。
资料量很小，比如就十几页说明，还需要搭 RAG 吗？
多数情况不用。十几页纯文本可能一次就能放进上下文，直接在提示词里带上更省事，也少一层出错的地方。等到资料开始频繁更新、条目上百、每次只该给模型看其中几段的时候，再考虑上检索，收益才明显。
用了 RAG 是不是就不会瞎编了？
不是保证，是降低概率。模型仍可能忽略你给的材料、或者把两段不相关的拼在一起。常见做法是要求回答里标明依据来自哪一段，没找到依据就明确说没查到；再配上固定的评测问题集，每次调参都跑一遍看有没有变差。
