一句话：模型参数里没有你公司昨天刚定的规则。RAG 的做法是每次回答前先去查资料，把查到的原文塞进上下文，再让模型基于证据组织答案。
它解决什么问题
大模型在企业落地时有三个硬伤，RAG 各解决一部分：
- 知识时效：训练数据有截止时间，新的制度、报价、工单它不知道。
- 私有知识：内部文档不可能拿去重新训练，也不该进训练集。
- 可溯源：业务场景需要「这句话出自哪份文件第几条」，纯生成给不了。
反过来说，RAG 不解决推理能力不足、不解决流程执行，它只负责把正确的资料放到模型眼前。
四段链路
1. 索引（离线）
- 解析：PDF / Word / 网页 / 表格统一转成文本，保留标题层级与表格结构。
- 切分：按语义边界切块（标题、段落、条款），块长常见 300～800 字，块间留 10%～20% 重叠避免语义被切断。
- 向量化：用嵌入模型把每个块编码成向量，写入向量库，同时保留原文与元数据（来源、章节、版本、生效日期）。
2. 检索（在线）
用户的问句先做改写（补全指代、拆分子问题），再走向量检索。工业界几乎都做混合检索：
| 方式 | 擅长 | 短板 |
|---|---|---|
| 向量检索 | 语义相近、换种说法也能召回 | 精确编号、专有名词容易漏 |
| 关键词检索（BM25） | 合同号、型号、人名精确命中 | 同义表达召回差 |
两路结果做融合（RRF 倒数排名融合是常用做法），再用重排模型（Rerank）按与问题的相关性精排，取 Top-N 进上下文。
3. 生成
把命中的原文块拼进提示词，要求模型：
- 只依据给定资料回答，资料里没有就明确说「未找到依据」；
- 每个结论后标注来源编号，前端渲染成可点击的角标；
- 遇到资料之间互相矛盾时，列出冲突并指出各自出处，而不是自行择一。
4. 评估
离线用标注集看召回率（该出现的块有没有被召回）与忠实度（答案是否都能在原文找到支撑）；线上看点击溯源的比例、追问率、人工纠错率。没有评估集的 RAG 项目，基本无法迭代。
真实落地里的四个坑
- 切分粒度决定上限。切太碎，语义不完整；切太大，噪声淹没重点。条款类文档建议按「条」切，技术手册按「小节」切。
- 跨文档冲突是常态。同一制度存在新旧两版、两个部门口径不一。正确做法不是让模型猜，而是把冲突显式暴露给用户，并附上生效日期。
- 长上下文不能替代检索。把 100 万字全塞进去，成本高、注意力分散、延迟不可接受。上下文窗口变大是缓解，不是解法。
- 多轮对话的指代。第二句「那它呢」如果直接检索，几乎必然跑偏，必须先把问题改写成独立完整的问句。
什么时候不该用 RAG
- 文档总量很小（几十页）：直接全量放进提示词更简单可靠。
- 需要跨文档做复杂计算、比对、流程判断：这是 Agent 编排的活，检索只是其中一步。
- 知识本身是结构化数据库：走 Text-to-SQL 或接口查询，比向量检索精确得多。
判断标准很朴素：如果人来做这件事也需要先翻资料再回答，RAG 就是对的；如果需要计算、执行、审批，那就要往上走一层到 Agent。