大语言模型的知识主要压缩在参数里。参数记忆擅长概括语言规律，却不适合保存一份每天变化的产品手册，也很难告诉你某个答案究竟来自哪一页。
RAG 是 Retrieval-Augmented Generation 的缩写，中文常译为检索增强生成。它的核心动作很朴素：先从外部知识库找证据，再让模型依据证据回答。
朴素不等于简单。一个真正可用的 RAG 系统至少包含文档处理、索引、查询理解、召回、重排、上下文组装、答案生成和评测。任何一环出错，最终都可能表现成一句流畅但错误的回答。
## RAG 改变了哪一种记忆
2020 年的原始 RAG 论文把模型参数称为参数化记忆，把外部文档索引称为非参数化记忆。前者在训练后相对固定，后者可以独立更新、删除和追踪来源。
这并不意味着 RAG 会让模型忘掉自身知识。生成时，模型仍会同时受到预训练知识、系统指令、用户问题和检索片段影响。工程目标不是让外部文档“压过”模型，而是让需要精确依据的结论可被证据约束。
## 离线阶段：先把知识做成可检索对象
第一步是解析。PDF、网页、表格、演示文稿和扫描件的结构不同，页眉、脚注、双栏排版和图片说明都可能混入正文。若解析顺序错了，后续嵌入再精确也只是在检索乱码。
第二步是分块。整本手册太长，不适合每次全部送入模型；切得过小，又会丢失标题、主体和上下文。常见做法按标题和段落切分，并保留一定重叠，但固定长度不是万能答案。
一个好的块应该能够独立回答某类问题，同时带有文档名、章节、版本、时间和对象等元数据。对代码要保留函数边界，对合同条款要保留层级，对产品目录则要让规格与型号留在同一块。
第三步是索引。语义嵌入把文本映射成向量，意思相近的问法和段落会靠近；词法索引则保留具体字面匹配。两者解决的不是同一个问题。
## 为什么只用向量检索常常不够
“无法登录”和“认证失败”在语义上接近，向量检索很有优势。但错误码 `TS-999`、零件号和人名缩写需要精确匹配，语义近似反而可能把它们稀释。
因此，生产系统常同时运行稠密向量检索和 BM25 词法检索，再用排名融合合并结果。Anthropic 的 Contextual Retrieval 也采用了语义嵌入与 Contextual BM25 的组合。
这项方法还处理了分块丢上下文的问题。原始块可能只有“公司收入环比增长 3%”，却没写公司和季度。系统在建立索引前，为每个块补上一段简短的文档语境，再分别生成向量和词法索引。
补语境不是让模型自由改写事实。原始文本仍应保留，附加说明只是帮助检索器理解这块属于谁、发生在何时、位于哪一章。
## 在线阶段：一个问题会经历什么
用户问题到来后，系统可能先做查询改写。多轮对话中的“那第二种呢”需要展开成完整问题；含有两个子问题的请求也可能被拆开检索。
接着是召回。系统从多个索引取回候选块，并用元数据过滤版本、语言或知识域。召回阶段宁可稍宽，因为遗漏关键证据后，后面没有机会凭空找回来。
随后是重排。重排模型同时阅读问题和候选段落，判断真正相关性，把最有用的证据放在前面。它比简单向量距离更贵，因此通常只处理几十个候选，而不是整个知识库。
最后才是上下文组装和生成。系统要去重、控制总长度、保留来源标识，并明确要求模型只在证据足够时作答。引用应指向真正支持该句的片段，而不是仅仅列出几个相关文档名。
## Top-K 不是越大越好
多给模型一些段落听起来更保险，但无关上下文会分散注意力，还可能引入互相冲突的旧版本。Top-K 太小会漏证据，太大则降低上下文精度并增加延迟和费用。
最优值取决于问题。查一个错误码可能只需一段，比较三个方案则需要跨文档证据。更成熟的系统会根据查询类型动态分配检索数量，而不是所有问题固定取前十条。
## 长上下文能不能取代 RAG
长上下文让整份文档直接进入模型成为可能，适合临时分析少量材料。但知识库持续增长时，全量输入会带来重复传输、成本、延迟和版本选择问题。
RAG 与长上下文更像互补：检索负责从大库缩小范围，长上下文负责在已选材料中进行跨段综合。若文档只有十页，简单全量输入可能比复杂索引更可靠；若有百万段且频繁更新，检索就更必要。
## 常见失败要按环节诊断
答案错误不一定是生成模型的错。解析器可能漏了表格，分块可能拆散标题和数字，嵌入可能不理解内部缩写，过滤条件可能选错版本，重排也可能把真正证据压到后面。
另一种失败是“检索到了但没用”。模型可能忽略中间位置的关键句，或把两个文档的结论混在一起。此时应检查上下文顺序、提示要求和引用对齐，而不是继续调向量数据库。
还有一种是知识库本身没有答案。可靠系统需要识别证据不足，返回缺口并建议补充信息，而不是用模型常识补齐一条看似合理的内部规则。
## 评测必须拆成两层
检索层要问：含有答案的块是否被召回，前几名里有多少真正相关内容，错误版本是否混入。生成层再问：回答是否忠于上下文、是否解决问题、引用是否支持对应陈述。
RAGAS 等框架提出上下文相关性、答案忠实度和答案相关性等维度，但自动评分也会出错。生产评测仍应保留一组人工核对的真实问题，并记录最终任务是否完成。
一次模型升级、分块修改或索引重建都应跑同一套测试。只看聊天界面里的几个成功样例，很难发现召回率在某类问题上悄悄下降。
## 最实用的建设顺序
先收集几十到几百个真实问题，给每个问题标出应命中的文档和可接受答案。再做最小系统：结构化分块、语义与词法混合检索、来源引用和拒答。
只有当评测显示具体瓶颈时，再加入查询改写、父子块、上下文压缩或多轮代理检索。复杂组件越多，延迟和故障面越大，必须用可重复指标证明它真的带来提升。
RAG 的本质不是“让模型知道更多”，而是建立一条从问题到证据再到答案的可检查路径。理解这条路径，比记住某个向量数据库或框架名称更重要。
## 参考资料