RAG 在解决什么问题
大模型的知识停留在训练时刻，无法天然知道你的产品文档、客户数据和最新政策。RAG 的做法是：用户提问时，先从知识库里检索相关内容，再让模型基于这些内容回答。
它本质上是给模型装了一个「可以随时翻阅的资料库」，而不是让它把知识背下来。
三个适用信号
第一，知识会变化：文档、价格、规则经常更新，模型无法及时记住。第二，答案必须可追溯：客户或合规要求能说明「为什么这么答」。第三，知识是私有的：你的数据不能也不应该进模型训练集。
如果三个信号一个都没有，RAG 可能不是最优解。
- 知识变化频率：每周以上更新，RAG 优势明显
- 追溯需求：需要引用来源、原文或版本
- 私有数据：客户资料、内部流程、行业规范
什么时候不该用 RAG
当答案完全依赖模型常识、知识几乎不变、或者用户只需要创意输出时，直接调用模型更简单。RAG 会带来检索延迟、索引维护和召回失败等额外复杂度。
另外，如果知识总量极小（比如只有 10 条 FAQ），把规则直接写进提示词可能比建向量库更可靠。
RAG 的代价
它不会自动让答案更准：检索不到会答错，检索到但切分差也会答错。上线前必须有评测集验证「检索命中率」和「基于资料的准确率」。
RAG 是一套工程系统，不是一行代码。
上线 RAG 前的最小准备
先整理 50 个真实问题，确认知识库能覆盖其中 80%；再检查切分后的片段是否包含完整答案；最后跑一遍「答案必须能追溯到原文」的验证。
这三步都通过，RAG 才值得上线。缺任何一步，检索错误都会被模型包装成看起来很专业的错误答案。
RAG 与微调怎么配合
RAG 负责「知道」，微调负责「会说」。知识经常变化、答案需要追溯时用 RAG；回答风格、领域话术和固定格式需要稳定时，微调更合适。
实践中多数项目先用 RAG 解决知识问题，等积累了大量高质量问答对，再针对高频场景做轻量微调，两者互补而非互斥。
无论选哪条路，评测集都是同一个：能通过评测的方案就是好方案。
RAG 项目的第一周
第一周不要急着搭向量库，先做三件事：收集 50 个真实问题、盘点可用知识源、确认回答的验收标准。这三件事决定了 RAG 项目是「在做产品」还是「在搭玩具」。
第二周再开始切分、索引和检索，并且每天用第一批问题跑一遍召回率。
RAG 项目的节奏应该是「数据先行、工程跟上」，顺序反了就会反复返工。