RAG 解决什么
RAG 用检索把外部资料带进回答，适合处理最新、私有、可引用的知识问题。
RAG（Retrieval-Augmented Generation）解决的是“模型回答时缺资料”的问题。
大模型参数里可能有很多通用知识，但它不一定知道你的公司制度、最新政策、客户合同、内部产品文档，也不一定能给出可核查引用。RAG 的做法是：先从外部资料库检索相关片段，再把这些片段放进上下文，让模型基于资料回答。
什么时候该用 RAG
适合用 RAG 的场景通常有 4 个特征：
| 场景 | 为什么不是只靠模型裸答 |
|---|---|
| 公司制度问答 | 制度会更新，不能靠模型参数记忆 |
| 产品文档助手 | 文档细节多，版本变化快 |
| 合同/研报/论文解读 | 需要引用原文，不能只给结论 |
| 客服知识库 | 答案要跟当前政策和服务规则一致 |
一句话：凡是答案必须依赖某批具体资料，就应该先想到 RAG。
RAG 的基本链路
- 收集文档：制度、网页、PDF、工单、知识库。
- 切片：把长文档拆成可检索的小块。
- 向量化：把文本转成 embedding。
- 检索：根据用户问题找到相关片段。
- 生成：让模型基于片段回答。
- 引用：把答案链接回原文或片段。
这条链路里，每一步都可能出问题。不是“接了向量库”就自动可靠。
RAG 最常见的失败点
1. 文档源头不可信
垃圾进，垃圾出。旧制度、重复文档、错误 FAQ、权限不该开放的资料，都会被检索出来。
2. 切片切坏了
如果一个条款被切成两半，模型可能只拿到前半句。合同、政策、说明书尤其容易出这个问题，因为上下文常常跨段落。
3. 检索没命中
用户问法和文档写法不同，向量检索可能找不到真正相关的内容。很多系统需要关键词检索、向量检索和重排序一起用。
4. 模型没有按证据回答
即使检索到了资料，模型也可能擅自补充。高风险场景要要求它引用来源，并在证据不足时拒绝下结论。
RAG 和微调的边界
RAG 管“用什么资料回答”。微调管“模型更倾向于怎么回答”。
如果问题是“模型不知道公司最新报销政策”，用 RAG。
如果问题是“模型每次都不按法务要求的格式输出风险摘要”，可以考虑微调、模板和评估集。
别为了更新知识去微调。知识更新频繁，应该放在可替换、可审计、可权限控制的资料系统里。
做 RAG 前先问 5 个问题
- 资料是不是可信、最新、去重过？
- 用户有没有权限看到这些资料？
- 文档切片是否保留必要上下文？
- 检索结果是否能解释为什么命中？
- 答案能不能引用回原文？
这些问题没解决，RAG 只会让模型更快、更有底气地胡说。