刚接触 RAG 这个概念的时候，我和一个朋友聊起来。

我说：我知道为什么要用 RAG——因为省 token 嘛。把整个文档丢给大模型太贵了，RAG 只挑相关的几段发过去，省钱。

朋友愣了一下，说：不对，RAG 的核心是增强检索，不是省钱。

图片

当时我没太懂。因为从我看到的定义来说——“从知识文档中抽取与用户问题最匹配的几个片段，只把这几个片段发给 LLM”——这不就是在减少输入量吗？减少输入量不就是省 token 吗？

后来我才意识到，我的关注点跑偏了。

我盯着的是“只发几个片段”这个动作，却忽略了一个更根本的问题：为什么要带着知识发给大模型？如果大模型什么都知道，你带不带知识有什么区别？

这个思维偏差特别有意思。作为程序员，我们太习惯从“资源优化”的角度看问题了——内存够不够、带宽省不省、调用次数多不多。所以看到 RAG 的第一反应是“哦，这是个降本方案”。但它真正要解决的问题，根本不在成本层面。

今天我想用产品思维重新拆一遍 RAG，搞清楚它到底在解决谁的什么问题，以及为什么我认为它是程序员转型 AI 应用开发的第一块拼图。

RAG 到底在解决什么问题

先说全称：Retrieval Augmented Generation，检索增强生成。

关键词是“增强”。增强谁？增强大模型。增强什么？增强它回答问题的能力。

用产品思维拆一下。服务对象是谁？大模型。场景是什么？用户问了一个专业问题，比如“我们公司的报销流程是什么”或者“这份合同里的违约条款怎么理解”。需求是什么？大模型需要回答，但它训练的时候压根没见过你公司的报销制度，也没读过你那份合同。

这就是核心矛盾：大模型很聪明，但它的知识有边界。它知道全世界的公开信息，却不知道你抽屉里那份文件写了什么。

那怎么办？三条路。

第一条路，把问题问清楚。你觉得大模型回答得不好，可能是你没说明白你要什么。这对应的是提示词工程——本质上是在优化“需求文档”。你把需求写得越清楚，开发同事（大模型）理解得越准确。

第二条路，给它背景资料。大模型不知道你公司的报销流程？那你把流程文档发给它，让它“带着资料答题”。这就是RAG——本质上是在给开发同事发参考资料，让他基于这些资料来回答你的问题。

第三条路，让它重新学。如果某个领域的知识它系统性地缺失，那就用这个领域的数据重新训练它。这对应的是微调——本质上是让人回炉重造，学一门新技能。

三条路的成本和适用场景完全不同。提示词工程最轻量，改改 prompt 就行；微调最重，需要数据、算力、时间；RAG 在中间，工程化程度适中，见效快，适用面广。

所以 RAG 的本质是什么？是“信息过滤+精准投喂”。从一堆知识里挑出和当前问题最相关的几段，喂给大模型，让它基于这些信息来回答。

你发现没有，这个逻辑和我们做产品时的“场景化推荐”一模一样——用户不需要看到所有商品，只需要看到和他当前需求最匹配的那几个。RAG 做的事情，就是给大模型做了一个“知识推荐系统”。

用开发思维拆一遍 RAG 的技术架构

理解了 RAG 在解决什么问题，接下来看它怎么解决的。整个流程分三个阶段，我切换到程序员熟悉的场景来类比。

图片

第一阶段：数据预处理——需求评审前的资料整理

在开始开发之前，你得先把需求文档、设计稿、接口文档整理好。RAG 也一样，在回答问题之前，得先把知识库准备好。

具体做三件事：

首先，知识库构建。把你的文档、网页、数据库里的信息收集整理好，形成一个外部知识库。这就像项目启动前把所有相关文档归档到一个共享目录里。

然后，文档分块。一份几万字的文档不能整个丢进去，得切成适当大小的片段。比如设定每块1000个字符，相邻块之间有10%的重叠（overlap），保证语义不被截断。这个过程就像把一本厚书拆成一章一章的——切太细会丢失上下文，切太粗检索时不够精准。除了按固定大小切，还可以按语义切分，比如按段落、按标题层级来分。

最后，向量化处理。把每个文本块用嵌入模型（Embedding Model）转成一个向量——一串数字，存到向量数据库里。为什么要转成向量？因为计算机不认识“语义相近”，但它认识“向量距离近”。把文本变成向量，就能用数学方法计算两段话的相似程度。常用的嵌入模型有 BGE、M3E 等，选型时主要看你的语言场景和精度要求。

第二阶段：检索——在代码库里精准定位 bug

用户问了一个问题，现在要从知识库里找到最相关的片段。这个过程特别像你在一个庞大的代码库里定位 bug——你不会从第一行开始逐行看，而是根据报错信息、关键词、调用链快速缩小范围。

具体分两步：

第一步，查询处理。把用户的问题也转成向量，然后在向量数据库里做相似度检索，找出距离最近的几个文本块。比如取 Top 5，就是找出最相关的5个片段。

第二步，重排序。初步检索的结果可能不够精准——有些片段虽然向量距离近，但实际相关性不高。这时候需要一个重排序模型（Reranker）对结果做二次排序，把真正相关的排到前面。这就像你用搜索引擎搜到一堆结果，但你心里清楚第三条才是你要的——重排序就是在做这个“心里清楚”的判断。

第三阶段：生成——基于定位结果写修复方案

找到了相关片段，接下来把它们和用户的问题拼在一起，发给大模型，让它基于这些信息生成回答。

这一步分两个动作：上下文组装和生成回答。

上下文组装就是把检索到的片段和用户问题组合成一个完整的 prompt，类似于：“以下是相关参考资料：【片段1】【片段2】…… 请基于以上资料回答用户的问题：【用户问题】”。

然后大模型基于这个增强过的上下文，生成最终答案。因为有了参考资料的约束，它不容易“编造”答案，回答的准确性和可靠性都会提升。

整个流程串起来就是：用户提问→问题向量化→在知识库中检索相关片段→重排序→拼装上下文→大模型生成回答。

用一句话概括：先检索，再生成。检索负责“找对资料”，生成负责“说对话”。

大模型上下文越来越长，RAG 还有意义吗

这是我学 RAG 过程中认真想过的一个问题。

现在的大模型动不动就支持128K、甚至百万级token的上下文窗口。既然能一次性塞这么多内容进去，为什么不直接把整个文档丢给它，还费劲做什么检索呢？

这个问题用开发思维里的“资源研判”来回答特别合适。

数据库能全表扫描，不代表你不需要建索引。能处理，和高效处理，是两回事。

图片

具体来说，RAG 的不可替代性体现在四个维度：

第一，效率与成本。上下文窗口大了，不代表往里塞东西不要钱。LLM 处理长上下文时，计算资源消耗是非线性增长的，响应时间也会明显变长。RAG 通过预先检索，只把相关片段送进去，本质上是在做“过滤”——过滤掉不相关的信息，减少计算量。这和数据库索引的逻辑一模一样。

第二，知识更新。大模型的训练数据有截止日期。你今天新发布的产品文档、刚更新的政策条款，它不知道。但如果你把这些文档放进知识库，RAG 可以实时检索到最新内容。这就是“连接外部知识库”的价值——让大模型的知识保持时效性，不用每次有新信息就重新训练。

第三，可解释性。RAG 的检索过程是透明的——它告诉你“我是基于哪几段资料回答的”。这意味着你可以追溯答案的来源，验证它有没有编造。在企业级应用里，这个特性非常重要。没有人愿意用一个“给了答案但说不清依据”的系统来做决策。

第四，数据隐私与定制化。很多企业的核心知识不能上传到第三方模型的训练数据里。RAG 的方案是：知识留在你自己的数据库里，只在查询时临时检索、临时送入模型，不参与训练。数据不出域，隐私有保障。同时它天然支持轻量化定制：你可以按需接入不同的私有知识库，让通用大模型快速变身适配特定业务的专属助手，不用改动模型本身，就能输出符合企业规范、匹配业务场景的定制化答案。

所以答案很明确：上下文窗口再大，RAG 依然有意义。它解决的不是“能不能放得下”的问题，而是“该不该全放进去”的问题。

回到开头那个问题

现在再回看我最初的回答——“RAG 是为了省 token”——不能说全错，但确实把结果当成了原因。

RAG 的初心是“增强”。增强大模型回答专业问题的能力，增强答案的准确性和时效性，增强系统的可解释性和可控性。省 token 是这个过程的附带好处，不是设计目标。

就像我们做一款办公工具，核心目标是帮用户提升做事效率，而不是 “帮用户少开几个软件”。减少软件开销是效率提升带来的结果，不是产品设计的出发点。搞反了这个因果关系，后续的技术决策就容易跑偏。

对于正在考虑转型 AI 应用开发的程序员来说，我觉得 RAG 是一个特别好的切入点。原因有三个：

首先，它的工程化程度高。数据处理、检索、排序、接口调用——这些都是我们熟悉的后端开发范畴。你不需要从零学深度学习，就能搭出一个可用的 RAG 系统。

其次，它连接了“你的专业知识”和“大模型的能力”。你在某个行业干了好几年，积累了大量领域知识和文档。RAG 让你能把这些知识“喂”给大模型，做出只有你能做的垂直应用。这是真正的差异化竞争力。

最后，它是 AI 应用开发的基础设施。无论后面你做 AI 客服、智能文档助手、知识库问答、还是企业内部的 AI 工具，RAG 几乎是绑定出现的底层能力。学会它，后面的路会顺很多。

图片

所以如果你也在纠结“想转型 AI 但不知道从哪入手”，我的建议是：先把 RAG 搞明白。不用一开始就追 GraphRAG、RAFT 这些进阶方案，先理解基线 RAG 的完整链路，动手搭一个，跑通从文档到问答的全流程。

这就是 AI 应用开发的第一课。不难，但很重要。