2023 年，几乎每个企业大模型方案都会提到 RAG（Retrieval-Augmented Generation，检索增强生成）。它的想法很直接：不要要求模型凭参数记住所有知识，而是在回答前先检索企业文档，把相关片段连同问题一起交给模型。
这条路线快速流行，是因为它同时缓解了知识过时、私有数据接入和答案可追溯三个问题，而且不必为每次文档变化重新训练模型。
一条 RAG 链路包含什么
离线阶段先收集文档，解析格式，按合适粒度切片，为片段生成向量并写入索引。在线阶段把用户问题转成检索请求，召回候选片段，必要时重排，再把最相关内容放入 Prompt，由模型生成答案和引用。
向量检索适合寻找语义相近内容。例如用户问“账号被冻结怎么办”，即使文档标题写的是“异常登录处置”，两者也可能被召回。但关键词搜索对产品型号、错误码和人名更精确，因此生产系统常把稀疏检索与向量检索混合，而不是押注一种方法。
最难的环节往往是切片和数据治理
演示系统把 PDF 按固定字符数切开就能运行，真实知识库却有目录、表格、代码、版本和权限。片段太小会丢失上下文，太大又会引入噪声并占用上下文窗口。
更重要的是，检索必须继承原系统的访问控制。如果一个员工无权查看薪酬文档，向量库也不能因为语义相似就把片段召回。删除和更新同样要同步，否则模型会继续回答已经失效的制度。
所以 RAG 首先是数据工程问题，其次才是 Prompt 问题。文档质量、元数据、权限和更新延迟，决定了答案上限。
RAG 不能消灭幻觉
检索可能没找到正确内容，也可能返回相似但错误的版本；模型即使拿到材料，仍可能忽略证据或自行补全。把温度调低并不能解决这些链路错误。
更可靠的做法是分别评测：检索阶段是否召回正确片段，重排是否把它放在前面，生成结果是否忠于证据，引用是否真的支持结论。找不到证据时，系统还应允许明确回答“不知道”，而不是强行凑出内容。
对于金额、政策条款和操作指令，可以让模型只做解释，最终数值或规则由结构化服务返回。RAG 是增强，不是把所有确定性系统都塞进向量库。
我的理解：RAG 是给模型安装一层可维护的记忆
模型参数像压缩后的长期常识，更新慢且难以追溯；检索库像外部工作记忆，可以频繁变化并保留来源。二者结合，才更接近企业需要的知识系统。
不过，记忆不是越多越好。一个成熟 RAG 系统应当知道哪些资料可信、何时过期、谁能访问，并能解释答案依据。真正的竞争力不是“接了一个向量数据库”，而是把组织中散乱、冲突、不断变化的知识整理成可检索、可验证的资产。
参考资料
- 论文：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
- AWS：What is Retrieval-Augmented Generation?
本文是 2026 年整理断更期时写下的回顾，发布日期按事件所处阶段归档。