查资料时看到 RAG 这个词，一会儿说它是检索、一会儿说它是架构、一会儿又说它能治幻觉，越看越糊。这篇不堆概念，先把 RAG 在大模型里到底扮演什么角色讲明白，再落到你怎么判断自己该不该上、上线前要盯住哪几个指标。想算具体成本或看模型能力数字，去站内对应页面按当时的数字核对。
查资料时看到 RAG 这个词，一会儿说它是检索、一会儿说它是架构、一会儿又说它能治幻觉，越看越糊。这篇不堆概念，先把 RAG 在大模型里到底扮演什么角色讲明白，再落到你怎么判断自己该不该上、上线前要盯住哪几个指标。
如果你只是想算算调用成本、或者对比各家模型的能力档位，那不用在这篇文章里找答案，去站内对应页面按当时的数字核对就行。这里只讲判断标准和可执行动作。
一句话说清 RAG 在做什么
RAG 就是「先查资料再回答」。你把用户的问题拿去自己的资料库里找相关片段，再把找到的片段和原问题一起交给模型生成答案。模型的权重没有任何变化，它只是多了一份临时塞给它的上下文参考。
- 检索 Retrieval
- 从你的资料库里找出与问题最相关的若干片段，这一步决定模型能看到什么
- 增强 Augmented
- 把检索到的片段拼进提示词，让模型带着这份材料作答
- 生成 Generation
- 模型基于问题和材料输出答案，理想情况下还标注引用来源
它解决的是三类问题：知识时效（训练数据截止后的新信息）、私有资料（你公司内部文档）、事实出处（答案能不能溯源）。它不是让模型变聪明，推理能力该弱还是弱。
一次 RAG 请求的链路长什么样
- 进料端文档清洗、切块、算向量、写进向量库。这步的质量直接决定后面天花板，切块切碎了后面的召回再好也白搭。
- 查询端把问题向量化，召回若干候选片段，必要时做重排，再把筛选后的片段拼进提示词。
- 生成端模型基于拼进来的片段作答。最好要求它标注引用来源，这样出问题能回溯到具体片段。
- 排查顺序答非所问先查切块，答得空泛先查召回条数，答得离谱先查模型有没有照片段说。
这条链路里最容易出问题的不是模型，是进料端。很多团队一上来就调模型参数，结果发现是文档切得稀碎、或者向量库压根没更新。
怎么判断你的场景该不该上 RAG
| 场景特征 | 适合上 RAG | 不适合上 RAG |
|---|---|---|
| 回答依据 | 必须依据内部文档、政策、产品手册 | 任务本身不依赖外部事实 |
| 任务类型 | 客服问答、知识库检索、合规查询 | 写代码、做数学、改写文案 |
| 资料更新 | 资料会持续更新，改一次文档就能生效 | 资料基本不动，且格式要求极严 |
| 可溯源性 | 需要标注答案出处 | 不需要溯源，答对就行 |
和微调的分工也要想清楚：知识频繁变、要求可溯源，就走 RAG；要固定语气和输出格式，再考虑微调。两者不冲突，可以叠着用。
和 Agent 的边界在于：需要多步决策、动态调工具才轮到 Agent，RAG 只负责把资料端上桌，不做决策。
上线前必须盯的几件工程事
- 先做一批固定测试问题，每次改动切块或提示词都跑一遍，别靠感觉判断变好没变好。
- 把召回条数、上下文长度和超时设成可调参数，别写死在代码里，线上出问题能快速回退。
- 记录每次请求命中了哪些片段，出问题才有得复盘，不然只能猜。
- 成本按 token 算，检索塞太多片段会推高单次开销，去站内成本计算页按当时口径估算。
- 给模型加一句「只根据提供的资料回答，资料里没有就说不知道」，能压住一部分瞎编。
上线前还要确认一件事：你的资料库有没有权限隔离。内部不同角色的文档混在一个库里，检索时可能把不该给某人看的片段召回出来。这不是模型的问题，是检索层要管的。
下一步想对比不同中转站的实际响应和稳定性，去站内测速页跑一轮，再回来看你的 RAG 链路该压哪一环。→常见问题
RAG 和直接微调模型有什么区别？
RAG 是把资料临时喂给模型，模型权重不变，资料更新只要更新库；微调是把知识或风格写进权重，改起来要重新训练。多数「资料会变、要能溯源」的场景先上 RAG，等格式和语气要求稳定了再考虑微调。
用了 RAG 就不会胡说八道了吗？
不会。如果召回没找到对的片段，或者提示词没约束模型只能用片段回答，它照样会编。要做的是要求模型标注引用、找不到资料就明说没有，再配一批测试问题定期验证。
RAG 的效果主要卡在哪一步？
多数时候卡在进料：文档没清洗干净、切块切碎或切太粗，后面再好的模型也救不回来。先看切块粒度和召回质量，再去看模型选型，顺序别反。
