一文理解 RAG：让大模型连接真实知识
RAG 为什么出现，它究竟修复了参数记忆的哪些缺陷？从知识更新与证据追踪问题出发，分析完整链路、失败模式和适用边界。
大模型能够回答大量事实问题，于是一个自然疑问是：既然知识已经存在参数里，为什么还要建设文档解析、向量索引和检索链路？
因为模型参数是一种强大的压缩表示，却不是一个可查询、可更新、可授权、可追溯的知识库。RAG 的出现，不是为了让模型“知道更多”这么简单，而是为了改变知识进入生成过程的方式。
What：RAG 是什么
RAG 是 Retrieval-Augmented Generation，即检索增强生成。它在模型生成答案前，从外部知识源检索与问题相关的材料，把这些材料作为上下文交给模型。
原始 RAG 论文把预训练模型的参数称为参数化记忆，把稠密向量索引称为非参数化记忆。两者结合：模型提供语言和推理能力，外部索引提供可替换的事实依据。
工程上通常包含两条链路：
索引链路：文档 → 解析 → 切分 → 元数据 → Embedding → 索引
查询链路：问题 → 查询改写 → 召回 → 重排 → 上下文组装 → 生成 → 引用
RAG 不是“接一个向量数据库”。任何一环出错，最终答案都可能流畅但错误。
Why：参数记忆解决不了什么
第一是更新成本。公司制度、产品价格和代码接口每天变化，不可能每次都重新训练模型。外部知识库可以按文档粒度更新和删除。
第二是来源问题。模型无法可靠指出某个参数知识来自哪份文档，而许多业务答案必须给出证据。
第三是私有性与权限。企业知识不应全部固化进共享模型；即使使用私有模型，不同用户也只能访问授权范围内的资料。
第四是时间性。训练数据有截止点，而问题可能要求当前状态。检索允许系统在推理时连接最新信息。
因此 RAG 解决的不是语言生成，而是知识供应链：让事实能够被治理后再进入模型。
为什么切分是第一个难题
检索的对象不是原始文档，而是切分后的 Chunk。切得过大，命中片段携带大量噪声；切得过小，标题、条件和上下文被割裂。一个包含“退款条件”的句子如果失去前面的适用地区和产品版本，语义相似但业务上可能完全错误。
固定字数切分只适合起步。技术文档更适合按标题层级和代码符号切分，FAQ 适合按问答单元，表格需要保留行列语义。每个 Chunk 还应携带来源、版本、时间、权限和父级结构。
切分决定了召回上限：索引阶段丢失的关系，生成阶段无法凭空恢复。
检索为什么会失败
向量检索擅长语义近似，却可能忽略错误码、型号和专有名词；关键词检索擅长精确匹配，却难以处理同义表达。因此常见系统会结合稠密检索与 BM25，再用 Cross-Encoder 或模型进行重排。
但召回的根本困难是“用户问题”和“答案所在文本”未必长得相似。用户问的是故障现象，文档写的是底层原因；一个问题还可能需要组合多个片段。查询改写、分解检索和图结构能够改善，却增加延迟与错误路径。
Corrective RAG 等工作进一步指出：如果检索到的文档本身不相关，生成模型会在错误证据上认真作答。因此系统需要评估召回质量，在证据不足时扩大搜索、换数据源或明确拒答。
权限必须早于召回
一种危险设计是先从全库召回，再在 Prompt 中要求模型忽略无权限内容。此时敏感信息已经进入模型上下文，边界已经失守。
正确顺序应是先根据身份、租户和文档策略过滤可见集合，再执行检索。缓存也必须包含权限维度，否则另一个用户的检索结果可能被错误复用。
这说明 RAG 不只是 AI 算法，也是一套数据基础设施。
如何知道问题出在哪一层
最终答案错误时，直接改 Prompt 往往无效。评估需要拆开：
- 索引阶段：正确资料是否被解析和切分；
- 召回阶段：正确片段是否进入候选集；
- 重排阶段：关键证据是否排在预算以内；
- 生成阶段：答案是否忠实于证据；
- 引用阶段：引用是否真的支持对应结论。
这对应 Retrieval Recall、Ranking、Faithfulness 和 Answer Correctness 等不同指标。端到端分数只能告诉我们系统不好，分层指标才能告诉我们为什么不好。
RAG 的缺点与边界
RAG 增加了索引更新、数据清洗、权限同步和评估成本。检索延迟会进入每次请求；文档变化后，旧向量和缓存可能继续存在；多个来源冲突时，模型未必能正确选择。
RAG 也无法保证消除幻觉。模型可能无视材料、错误综合，或者在证据缺失时补全答案。它提供了事实通道，不提供正确性的数学保证。
如果知识集合很小且稳定，直接放入上下文可能更简单；如果目标是改变写作风格和输出行为，微调更合适；如果答案来自结构化实时数据，应优先查询数据库或 API，而不是把数据转成文本后做模糊检索。
一个典型失败是怎样形成的
假设员工询问“上海地区试用期员工今年有几天年假”。索引中同时存在全国制度、上海补充规定和上一年度旧版本。向量检索可能优先命中措辞最相似的旧全国制度；重排器没有把地区和生效日期作为特征；生成模型随后把两份文档拼成一个自信答案。
这里 Prompt 并不是主因。修复需要让文档携带地区、生效时间和版本状态，在检索前过滤适用范围，在重排时提升现行补充规定，并要求答案引用具体条款。若资料仍冲突，系统应返回“无法确定”并展示冲突来源。
这个例子说明 RAG 的质量上限来自数据治理，而不是 Embedding 模型排行榜。未经版本管理的知识库，只会让模型更高效地检索混乱。
研究方向：从检索片段到验证主张
传统 RAG 的单位是 Chunk，但用户需要验证的是答案中的 Claim。一段回答可能包含五个主张，其中只有三个被证据支持。未来系统需要把回答拆成可验证主张，为每个主张寻找证据，识别证据之间的蕴含、矛盾和时效关系。
这会让 RAG 从“检索后生成”变成“提出—搜索—验证—修正”的循环，也更接近研究过程，而不是一次向量查询。
我的判断
建设顺序也很重要：先用一组真实问题建立可重复评估，再选择切分和检索方案，最后才是替换更大的模型。没有问题集和证据标注，任何“效果提升”都可能只是演示样例变好了。
RAG 最重要的价值不是 Vector Search，而是让模型的回答重新连接到可治理的外部事实。它把“模型大概记得”变成“系统此刻找到了哪些证据”。
未来 RAG 的重点会从一次性 Top-K 检索转向更主动的知识使用：Agent 判断缺少什么证据，逐步搜索、验证冲突并在证据不足时停止。检索不再只是生成前的插件，而会成为推理过程的一部分。