上一篇文章里我们讨论了一个很常见的问题为什么很多 RAG 知识库问答系统看起来能跑 Demo但真正用起来却不稳定。原因并不是 RAG 这个方向不行而是很多系统只做了最表层的流程文档入库、向量检索、模型回答。看起来链路完整实际上每个环节都可能影响最终效果。所以在继续讨论文档切分、Embedding 模型选择、Hybrid Search、Rerank、GraphRAG、Agentic RAG 之前有必要先把 RAG 的最小闭环讲清楚。一个最基础的 RAG 系统通常可以拆成四个核心环节Query用户问题进入系统。Embedding把文本转换成向量。Retriever从知识库中召回相关内容。Generator让大模型基于上下文生成答案。这四个模块串起来才构成了一个最小可运行的知识库问答流程。先从一个问题开始假设用户问公司试用期员工能不能申请年假如果这是一个普通大模型问答模型会直接基于训练阶段学到的通用知识回答。它可能会说一些看似合理的话比如“通常需要根据公司制度判断”也可能根据常见劳动规则进行概括。但问题是用户真正想知道的不是通用解释而是这家公司自己的制度。也就是说答案应该来自企业内部文档比如员工手册。考勤制度。请假管理办法。人事部门发布的补充说明。如果模型没有看到这些资料就算回答得很流畅也不一定可信。RAG 要解决的就是这个问题在模型回答之前先从知识库里找到和问题相关的资料再让模型基于这些资料回答。这也是 RAG 和普通聊天问答最大的区别。普通问答更像是“模型凭已有知识回答”RAG 更像是“系统先查资料再让模型组织答案”。第一步Query不只是用户输入的一句话Query 是整个 RAG 流程的入口。很多人会把 Query 理解成用户输入的原始问题这当然没错但在真实系统里Query 往往不只是简单的一句话。用户输入的问题可能是公司试用期员工能不能申请年假我刚入职三个月可以休年假吗还没转正年假怎么算新员工请年假有什么限制这些问题表达方式不同但背后可能指向同一个业务问题试用期或新员工是否具备年假资格。如果系统只是把用户原话直接拿去检索就很容易漏掉相关内容。比如制度文档里写的是入职未满一年的员工按实际工作月份折算年休假天数。用户问的是“试用期能不能申请年假”文档里却没有直接出现“试用期”这个词。如果检索系统只依赖表层词汇就可能找不到正确片段。所以 Query 这个环节至少要考虑几个问题用户问题是否足够清楚。问题里是否包含口语化表达。是否需要补充业务同义词。是否需要改写成更适合检索的表达。是否需要识别问题里的时间、角色、部门、项目等条件。在最小 RAG 系统里Query 可以直接使用用户原始问题。但在真实系统里Query 处理会逐渐变得重要。这也是为什么后面会出现 Query Rewrite、Multi-query Retrieval、Step-back Question 等优化方法。不过在这篇文章里先记住一个核心点就够了RAG 的起点不是“模型开始回答”而是“系统先理解用户要查什么”。第二步Embedding把文本放进语义空间为了从知识库里找到相关内容系统需要比较“用户问题”和“文档片段”之间的相关性。最常见的做法是 Embedding。Embedding 可以简单理解为把一段文本转换成一组数字向量。比如“试用期员工能不能申请年假”“入职未满一年的员工年休假按实际月份折算”这两句话表面上不完全一样但语义上有关系。Embedding 的目标就是让语义相近的文本在向量空间里距离更近。在 RAG 系统里Embedding 通常会出现在两个阶段。第一个阶段是文档入库阶段。系统会先把文档解析出来切分成一个个片段再把每个片段转换成向量存入向量数据库或向量索引中。第二个阶段是用户提问阶段。当用户输入问题后系统也会把这个问题转换成向量再用这个向量去知识库里查找相似的文档片段。这就形成了一个基本思路文档片段提前向量化。用户问题实时向量化。用问题向量去匹配文档向量。找到语义上最接近的候选内容。这一步很重要但也很容易被误解。Embedding 并不是让系统真正“理解”了所有业务它只是提供了一种语义相似度匹配能力。如果文档切分不合理Embedding 再好也可能召回不到完整信息。如果文档本身质量很差Embedding 只会把脏数据也一起放进索引。如果用户问题和文档表达差异太大通用 Embedding 模型也可能判断不准。所以Embedding 是 RAG 的基础能力但不是万能能力。它解决的是“如何让问题和文档在语义层面可以被比较”不是解决所有问答质量问题。第三步Retriever从知识库里召回候选内容有了 Query 向量和文档向量之后下一步就是检索。Retriever 的作用是根据用户问题从知识库中召回一批可能相关的内容。注意这里说的是“可能相关”而不是“最终答案”。这是很多 RAG 系统容易出问题的地方。系统检索出来的 TopK 片段只是候选资料。它们可能很相关也可能只是看起来相似可能包含答案也可能只是和问题主题接近。比如用户问生产环境数据库备份策略是什么Retriever 可能召回生产环境数据库备份策略。开发环境数据库初始化说明。数据库权限申请流程。运维巡检记录。这些内容都和“数据库”有关但不一定都能回答用户问题。如果系统直接把这些片段全部塞给模型模型就可能受到干扰。所以 Retriever 的质量会直接影响后面的生成质量。一个基础 Retriever 通常会做几件事接收用户问题或问题向量。在向量索引中计算相似度。返回相似度最高的若干文档片段。同时返回文档 ID、标题、来源、分数等元数据。在最小系统里Retriever 可能只是简单的向量 TopK 检索。但在真实系统里Retriever 往往需要更多能力支持关键词检索。支持 metadata 过滤。支持权限过滤。支持多路召回。支持按版本、时间、业务范围筛选。支持召回结果去重。支持和 Rerank 配合。这些能力听起来像优化项但很多时候是生产环境的必需项。因为真实业务里的问题往往不是“有没有相似内容”这么简单而是“能不能找到正确、最新、有权限、可引用的内容”。所以可以这样理解Retriever 是 RAG 系统里连接用户问题和知识库的桥。桥修得粗糙模型后面再努力也很难稳定回答。第四步Generator让模型基于上下文生成答案当 Retriever 找到候选内容后系统会把这些内容和用户问题一起交给大模型。这个阶段就是 Generator。Generator 的任务不是让模型自由发挥而是让模型基于检索结果组织答案。一个简单的输入结构可能是用户问题 公司试用期员工能不能申请年假 检索到的资料 1. 员工年休假按照入职时间和实际工作月份折算。 2. 入职未满一年的员工可按当年剩余工作月份计算年休假天数。 3. 请假申请需要在系统中提交并经过直属负责人审批。 请基于以上资料回答用户问题。如果资料不足请说明无法确定。模型看到这些上下文后就可以生成类似这样的答案根据检索到的制度内容试用期员工是否可以申请年假需要按入职时间和实际工作月份折算。资料中没有直接写明“试用期禁止申请年假”但提到入职未满一年的员工可以按当年剩余工作月份计算年休假天数。因此可以初步判断新员工年假资格应按入职月份折算具体仍应以公司最新制度和审批规则为准。这个答案比模型凭空回答更可靠因为它有资料依据。但这里也有一个关键问题模型必须被约束。如果 Prompt 没有明确要求“只能基于资料回答”模型可能会把自己的常识补进去。如果检索内容不完整模型可能会强行补全。如果多段资料互相冲突模型可能会自行选择一个版本。如果用户追问很诱导模型可能会跟着用户假设继续说。所以 RAG 的 Generator 环节不是简单地把上下文拼上去而是要设计好生成约束。通常至少要考虑是否要求模型只基于检索资料回答。资料不足时是否必须回答“不知道”或“无法确定”。是否需要列出引用来源。是否需要区分确定信息和推断信息。是否需要保留原文依据。是否需要结构化输出。一个好的 Generator不是回答得越长越好而是回答得有依据、边界清楚、可追溯。一个最小 RAG 闭环长什么样把上面四步串起来一个最小 RAG 闭环大概是这样的用户问题 ↓ Query 处理 ↓ 问题 Embedding ↓ Retriever 检索知识库 ↓ 召回相关文档片段 ↓ 构造 Prompt 上下文 ↓ Generator 生成答案 ↓ 返回答案和引用来源文档入库阶段则是另一条链路原始文档 ↓ 文档解析 ↓ 文档切分 ↓ 片段 Embedding ↓ 写入向量索引 ↓ 等待查询时被检索很多人刚接触 RAG 时只关注用户提问后的链路却忽略了文档入库链路。但实际上文档入库质量会直接决定后续检索质量。如果文档解析时表格丢失后面就无法回答表格里的问题。如果文档切分把一个完整规则拆碎后面就可能召回不到完整上下文。如果向量索引里混入过期文档后面就可能基于旧制度回答。所以 RAG 不是只有在线问答流程它还包括离线知识处理流程。一个系统能不能用往往取决于这两条链路是否都设计得足够清楚。最小闭环能跑但不代表生产可用到这里一个最基础的 RAG 系统已经可以跑起来了。它能完成用户提问。问题向量化。检索相关文档。拼接上下文。生成答案。这就是很多 Demo 的基本形态。但它离生产可用还有距离。因为真实业务会不断出现更复杂的问题。比如用户的问题很口语化原始 Query 检索不到资料。文档切分太碎答案需要跨多个片段才能拼完整。向量检索召回了相似但不相关的内容。TopK 里混入旧版本文档。多个文档说法冲突。模型拿到上下文后仍然自由发挥。答案没有引用用户不知道能不能信。用户没有权限查看某些资料但系统仍然召回了。出错后开发者不知道问题发生在哪一环。这些问题不是靠“接一个大模型”就能解决的。它们分别对应 RAG 系统里的不同工程问题Query 需要改写和扩展。文档需要合理切分。Embedding 模型需要评估。Retriever 需要混合检索。召回结果需要 Rerank。Prompt 需要约束生成边界。答案需要引用来源。知识库需要权限和版本控制。系统需要日志、评测和可观测性。所以最小闭环只是起点。它能帮助我们理解 RAG 是怎么工作的但不能保证系统已经足够可靠。RAG 四个模块之间不是孤立的Query、Embedding、Retriever、Generator 看起来是四个独立模块但它们之间会互相影响。Query 表达不清楚Embedding 再好也可能匹配不到正确内容。Embedding 模型不适合当前领域Retriever 的召回质量就会下降。Retriever 召回内容不准Generator 就会拿着错误资料生成答案。Generator 约束不够即使检索内容正确也可能产生额外发挥。这就是 RAG 系统复杂的地方。它不是一个单点能力而是一条链路。链路里的任何一个环节不稳定最终用户看到的答案都会受影响。所以做 RAG 时不应该只问“模型选哪个”也不应该只问“向量库选哪个”。更重要的问题是用户问题如何进入系统文档如何被处理成可检索内容检索结果是否真的相关模型是否严格基于资料回答答案是否能被追溯和验证出错后能不能定位是哪一环的问题这些问题才是 RAG 工程化真正要解决的核心。总结一个最基础的 RAG 系统可以拆成 Query、Embedding、Retriever、Generator 四个核心环节。Query 决定系统如何理解用户要查什么。Embedding 让用户问题和文档片段可以在语义空间中被比较。Retriever 负责从知识库中召回候选内容。Generator 负责基于检索上下文生成答案。这四步串起来就形成了 RAG 的最小闭环。但最小闭环不等于生产可用。真正可靠的 RAG需要继续处理文档切分、检索质量、重排序、Prompt 约束、引用来源、权限控制、评测体系和可观测性。理解这个基本流程是继续深入 RAG 工程化的前提。后面的文章我们可以从文档切分开始继续讨论一个很容易被低估的问题为什么 Chunk 不是越小越好文档到底应该怎么切。