01-RAG的边界：它解决什么，又解决不了什么

上一篇把 RAG 放在了一条更完整的证据链里看：它更像一套让模型回答时能拿到外部证据的工程系统。“向量数据库 + 大模型”只是最小 demo 里的表层形态。

但只知道这一点还不够。真正使用 RAG 时，更容易出问题的是把所有模型回答不好的现象都归因到“知识不够”，然后默认用 RAG 解决。

模型不知道公司制度，想用 RAG；模型回答格式不稳定，也想用 RAG；模型推理错了，还想用 RAG；甚至模型输出风格不符合要求，也想用 RAG。表面上看，这些都是“模型答得不好”，但背后的原因并不一样。

现象	更像是什么问题
不知道内部制度、产品文档、项目资料	外部知识问题
输出格式不稳定、语气不一致	行为约束问题
多步推理经常出错	模型能力或流程设计问题
需要查数据库、算结果、调接口	工具执行问题

所以这一篇先不急着进入文档处理、chunking 和向量索引，而是先把边界讲清楚：

RAG 适合解决模型回答时缺少外部证据的问题，但它不等于给模型增加永久知识，也不等于让模型天然变得更聪明。

这个边界如果不清楚，后面很容易把 RAG 当成万能补丁。

RAG 主要解决的是外部知识接入

大模型训练完成后，参数里的知识基本就固定了。它可能不知道训练后发生的政策变化、产品更新、接口调整和文档改版，也不会天然知道某个公司的内部制度、客服 SOP、项目文档、代码仓库和个人笔记。

RAG 的价值就在这里：知识可以保留在外部系统中，不必全部写进模型参数。用户提问时，系统先从外部知识库里检索相关证据，再把证据和问题一起交给模型。模型基于当前检索到的资料组织答案。

这让 RAG 特别适合动态知识和私有知识。

动态知识的特点是变化频繁。产品手册会更新，API 会调整，制度会改版，FAQ 会新增。如果每次知识变化都靠重新训练或微调模型，成本和流程都会很重。RAG 的思路更自然：知识留在外部，文档变了就更新知识库和索引。

私有知识的特点是模型原本无法获得。企业内部文档、客服记录、代码库、项目说明、会议纪要，这些内容通常不会出现在通用模型训练数据里。RAG 可以把这些知识作为外部证据接入模型，让模型回答时有资料可查。

还有一类场景很容易被忽略：答案需要引用来源。很多时候，系统不是只要“答得像”，还要知道答案依据了哪份文档。企业制度、技术文档、法律条款、论文资料都属于这类场景。RAG 可以把来源、段落、版本和引用一起带出来，让答案可以被复核。

所以，RAG 的核心价值可以概括成一句话：

它让模型在回答时临时获得一批外部证据，并且让这些证据可以被更新、追踪和审计。

这也是 RAG 和普通聊天模型最大的不同。

RAG 不能让模型永久记住知识

RAG 很容易被误解成“给模型补知识”。

这个说法只对了一半。RAG 确实能让模型在某次回答中使用外部知识，但它并没有把这些知识写进模型参数里。知识只有在被检索出来、进入上下文以后，才会影响当前这次回答。

换句话说：

RAG 更像是在回答前把资料摊到模型面前，而不是把知识永久写进模型参数。

这个区别决定了很多工程选择。

如果某个知识经常变化，RAG 很合适，因为更新外部知识库比更新模型参数更轻。如果希望模型长期稳定地形成某种输出习惯，比如总是用某种格式生成、遵守某类任务模式、形成固定语气，RAG 就不是最直接的方案。

这时更可能需要 Prompt 约束、输出校验、工作流编排，或者微调。

所以，判断一个问题是否适合 RAG，可以先区分当前缺的是可检索的外部证据，还是模型本身的行为能力。

如果缺的是证据，RAG 很自然。如果缺的是能力，RAG 只能提供资料，不能保证模型一定会把任务做好。

RAG 不能替代模型能力

RAG 能把资料找出来，但不能保证模型一定理解得对、推理得对、执行得对。

如果一个问题需要复杂推理，而模型本身推理能力不足，RAG 只能提供更多证据，并不能自动补齐推理能力。如果任务要求严格结构化输出，而模型总是不遵守格式，RAG 也不是主要解法，可能更需要结构化输出约束、函数调用、校验器或重试机制。

还有一些问题本质上更接近工具执行，比如实时计算、数据库查询、代码运行、调用外部 API。RAG 可以提供背景文档，但真正完成任务还需要工具调用或工作流系统。

所以，RAG 解决的是缺证据，不一定解决不会做。

RAG 也不能自动保证检索正确

即使问题确实适合 RAG，也不代表接上知识库以后就一定有效。

RAG 的效果高度依赖检索链路。文档解析不干净，chunk 切得太碎或太大，metadata 缺失，embedding 模型不适合业务语料，用户 query 没有改写，向量检索漏掉精确关键词，Rerank 没有把正确证据排上来，都会导致模型拿不到正确材料。

链路位置	常见失败
文档入库	解析噪声、结构丢失、metadata 缺失
检索召回	query 表达不匹配、精确关键词漏召回
排序整理	正确证据没排上来，或被上下文截断

这时模型回答错，并不一定是模型“不会答”，而可能是正确证据根本没有到场。

这也说明 RAG 不能只看最终答案。一个回答错了，要沿着链路拆开看：正确文档有没有进入知识库，chunk 是否保留了完整语义，embedding 是否能召回，topK 里有没有正确证据，Rerank 是否排序合理，上下文是否被截断或污染。

RAG 的工程价值不只是增强生成，还在于它让错误有了可排查路径。

RAG 不能自动保证生成忠实

还有一种情况更隐蔽：正确证据已经被检索出来了，但模型还是答错。

原因可能是上下文太长，模型没有注意到关键证据；也可能是 topK 里混入了冲突信息，模型把多个版本揉在一起；还可能是 Prompt 没有强约束模型只基于证据回答，于是模型在证据不足时进行了补全。

所以，RAG 不是只要“检索到”就结束了。检索结果还要经过上下文工程，才能变成模型真正可用的证据。去重、排序、压缩、引用编号、冲突处理、低置信度拒答，这些都是让生成更忠实的手段。

更准确地说，RAG 只是把答案从“纯模型生成”变成基于证据生成。但基于证据生成这件事本身，仍然需要约束、评测和校验。

这也解释了 RAG 可以减少幻觉，却不能彻底消灭幻觉。

RAG 和微调：一个偏知识接入，一个偏行为塑造

RAG 和微调经常被放在一起比较。

一个常见判断是：

如果问题主要是“模型不知道这些知识”，优先考虑 RAG；如果问题主要是“模型不会以某种方式完成任务”，才更接近微调的范围。

RAG 更像给模型一个可更新的资料库。知识变化时，更新知识库、重建索引或做增量索引即可。它天然适合需要引用来源、需要权限控制、需要频繁更新的知识场景。

微调更像改变模型的行为习惯。它可以让模型更熟悉某类表达风格、输出格式、任务模式或领域语言，但微调后的答案不天然带引用来源。如果知识本身经常变化，把它们都压进模型参数里，维护成本会很高。

方案	更适合解决	不擅长解决
RAG	外部知识、动态更新、引用来源	稳定行为习惯、复杂能力补齐
微调	输出风格、任务模式、领域表达	高频变化知识、可追溯引用

二者不是互斥关系。

有些系统会用 RAG 接入动态知识，同时用 Prompt 或微调稳定输出格式和语气。一个解决知识接入，一个解决能力和风格适配。真正的方案选择，不应该问“RAG 和微调哪个更好”，而应该问当前问题到底是知识问题、行为问题，还是二者都有。

RAG 和长上下文：一个决定读什么，一个决定能读多少

长上下文能力越来越强以后，RAG 和长上下文的关系也需要重新放回工程链路里理解。

这个问题不能简单回答“需要”或“不需要”。

长上下文确实很有用。它提升了模型一次阅读更多材料的能力，也让很多原来需要切分和检索的问题变得更简单。但“能塞进去”不等于“应该全部塞进去”。

真实业务里，上下文越长，成本和延迟越高，噪声也越多。更重要的是，不同用户能看到的内容可能不同，文档也有版本和适用范围。如果把大量无关材料直接塞进上下文，模型未必更容易找到答案，反而可能被噪声干扰。

RAG 的价值是先筛选再阅读。它通过检索、过滤和排序，把候选范围缩小，再把更相关的证据交给模型。

所以，长上下文和 RAG 更像互补关系：

长上下文解决模型一次能读多少，RAG 解决哪些内容值得被读。

很多生产系统里，两者会一起出现。RAG 负责选证据，长上下文负责容纳更完整的证据和对话背景。

RAG 和传统搜索：更适合组合理解

传统搜索返回的是文档列表，RAG 返回的是基于证据综合后的答案。

这个区别很好理解。用户用搜索引擎时，系统把相关资料排出来，用户自己点进去读；用户用 RAG 问答时，系统先检索资料，再让模型把资料组织成答案。

但这不意味着 RAG 比搜索“高级”到可以抛弃搜索。恰恰相反，RAG 的检索层很依赖搜索系统多年沉淀下来的能力。BM25、倒排索引、过滤、排序、融合、点击反馈，这些在 RAG 里仍然很重要。

很多时候，纯向量检索并不能稳定解决所有问题。涉及精确关键词、编号、专有名词、标题匹配、权限过滤时，关键词检索和结构化过滤反而更可靠。

所以，更稳的理解是：

传统搜索解决把相关资料找出来，RAG 进一步解决基于资料组织成答案。

一个好的 RAG 系统，会把搜索和生成结合起来，而不是简单抛弃搜索。

RAG 仍然会幻觉的原因

把 RAG 当成“幻觉终结者”也是一个常见误区。

RAG 能降低幻觉，是因为模型回答前有了外部证据。但只要证据链任何一环出问题，幻觉仍然会发生。

如果知识库没有收录正确文档，模型拿不到证据；如果 chunk 切坏了，关键上下文断掉；如果 embedding 召回不准，正确证据进不了 topK；如果 Rerank 排序不准，正确证据被挤到后面；如果上下文里混入冲突资料，模型可能融合出错误答案；如果 Prompt 没有要求拒答，模型可能在证据不足时继续补全。

所以，RAG 对幻觉的真正价值在于让错误可定位。回答错了，可以顺着文档、chunk、召回、排序、上下文、生成这条链路逐层排查。

这比单纯指望模型更可靠。

小结

RAG 的价值很明确：它让大模型回答时可以接入外部知识，并且让答案更有机会变得可追溯、可更新、可审计。

但 RAG 也有边界。它不能让模型永久记住知识，不能替代模型能力，不能自动保证检索正确，不能自动保证生成忠实，也不能彻底消灭幻觉。

可以把这一篇的判断压缩成一句话：RAG 适合补证据，不适合单独补能力。

真正理解 RAG，需要知道什么时候该用它，以及用了以后还要为哪些环节负责。

下一篇就进入 RAG 的第一道地基：文档进入知识库之前，到底要经历什么。