RAG工程全流程：切分、嵌入、召回、重排、引用、评测和线上监控
摘要
研究聚焦 RAG 从演示到生产的关键断点：为什么“文档进向量库、片段进提示词”不足以支撑可核验知识问答。方法上，文章把 RAG 拆为知识摄取、切分、嵌入、召回、重排、上下文组装、引用生成、评测监控七个闭环，并分别分析每个闭环的质量风险。结论是，生产级 RAG 是面向业务事实的知识供应链；回答质量来自知识覆盖、检索命中和生成约束同时成立，任何单点优化都无法替代端到端评测。
关键词
RAG；知识摄取；切分；嵌入；召回；重排；引用；线上监控
研究问题与方法
本文的研究问题是：RAG 系统如何在知识库动态变化、用户问题表达多样、权限约束复杂的情况下，持续生成可追溯答案。方法上，文章采用流水线失效分析：每个阶段都追问输入是什么、输出是什么、错误如何传播、如何观测、如何回滚。这样可以把“答案错了”拆成知识未覆盖、解析错误、切分破坏语义、召回遗漏、重排失准、上下文组装冲突或生成阶段歪曲证据。
图中的闭环说明，RAG 不是一次性索引项目，而是持续维护的证据系统。可以用一个端到端质量分解式表达：
其中， 表示用户得到正确且可引用答案的概率， 表示知识库中存在足够答案依据的概率， 表示检索和重排把依据送入上下文的概率， 表示生成阶段忠实使用证据并在不足时拒答的概率。任一环节低，最终质量都会被压低；因此 RAG 评测必须分层，而不能只看最终回答是否顺眼。
引言：RAG 的生产问题
RAG不是把文档塞进向量库再把片段拼到提示词里。生产级RAG是一条持续运行的知识供应链：从资料进入系统开始，就要决定哪些内容可信、哪些内容可检索、哪些内容能被模型引用、哪些回答必须拒答、哪些问题要触发人工补充知识。它的目标也不是让大模型显得“知道更多”，而是让最终用户在需要事实、制度、产品说明、技术步骤、合同条款、案例证据时，拿到可核验、可追踪、可改进的答案。
一套成熟RAG系统至少包含七个闭环。第一是知识摄取闭环，负责把网页、文档、表格、工单、代码、邮件、会议纪要等资料转成结构稳定的知识单元。第二是切分闭环，负责在语义完整、检索粒度、上下文预算之间做平衡。第三是嵌入闭环，负责选择向量模型、规范文本、处理多语种和增量更新。第四是召回闭环，负责用关键词、向量、元数据、图谱、查询改写等方式找到足够候选证据。第五是重排闭环，负责在候选证据中挑出真正能回答当前问题的片段。第六是生成和引用闭环，负责让模型只基于可用证据作答，并把引用落到用户能检查的位置。第七是评测和监控闭环，负责发现答案错、证据错、召回漏、延迟高、成本失控、知识过期这些线上问题。
如果这七个闭环缺一个，RAG都会退化。只有向量库没有清洗，答案会被脏数据污染；只有切分没有重排，模型会在一堆相似片段里抓错依据；只有引用没有评测，页面看起来可信但没人知道引用是否支撑结论；只有离线评测没有线上监控，系统会在知识更新、用户提问变化和模型版本变化后慢慢失真。工程师设计RAG时，应先把它看成面向业务事实的检索生成系统，再选择框架、模型和数据库。
RAG 能回答什么
RAG最适合回答有外部依据的问题，例如政策解释、产品知识库、内部流程、技术文档、法务条款摘要、客服问答、研究报告检索、代码库问答、课堂资料答疑。它不适合把所有问题都硬接住。没有资料的问题应拒答或转入通用模型能力；资料互相冲突的问题应指出冲突；权限不足的问题应明确无法访问；需要实时状态的问题应连接实时工具，而不是依赖静态索引。
正式建设前，先写问题边界，而不是先选向量库。边界应包含资料范围、用户角色、答案形态、引用要求、时效要求、禁止回答范围和升级路径。比如企业制度助手可以回答“年假怎么计算”，但不能凭空判断“我这次劳动仲裁能赢吗”；代码库助手可以解释函数调用链，但不能承诺线上故障根因；医疗资料助手可以整理指南证据，但不能替代医生诊断。边界越清楚，后面的切分、召回、提示词和评测越容易收敛。
RAG的回答质量来自三个条件同时成立：知识库里有答案，检索能找到答案，生成阶段不会歪曲答案。很多失败案例只盯最后一个条件，以为换更强模型就能解决。实际排查时应把问题拆开：如果知识库没有覆盖，应该补资料；如果资料存在但没召回，应该调索引和查询；如果证据召回正确但答案错误，才重点调提示词、上下文布局、引用约束和模型选择。
知识摄取与可靠知识单元
文档进入RAG系统前，必须经过解析、清洗、规范化、去重、权限绑定和版本记录。这里的目标不是把文本“读出来”就结束，而是保留用户以后核验答案需要的上下文。一个合格知识单元至少应带有来源地址、文档标题、章节路径、页码或段落位置、发布时间、更新时间、权限标签、业务标签、语言、解析器版本和内容哈希。没有这些元数据，后续引用、追责、增量更新、权限过滤都会变得困难。
解析阶段要警惕两类错误。第一类是结构丢失，例如PDF里的标题层级、表格列名、脚注、页眉页脚、代码块、图片说明被混成一段。结构丢失后，切分器无法判断上下文边界，模型也很难知道“以下条件同时满足”还是“以下选项任选一个”。第二类是噪声进入正文，例如导航栏、版权声明、重复页脚、广告、目录编号、页码、乱码、扫描识别错字。噪声不会平均地降低质量，而是会在相似检索中频繁被召回，成为稳定的错误来源。
知识摄取还应做文档级去重和段落级去重。公司制度、接口文档、产品手册常常存在多个版本，重复内容里夹杂少量差异。简单地全部入库，会让召回结果被旧版本淹没。更稳的做法是把文档版本作为一等元数据，默认只开放当前有效版本，同时保留历史版本供审计；对相同段落保留主来源，避免重排阶段把重复片段当成多个独立证据。
权限必须在索引阶段就绑定，而不是生成阶段才提醒模型“不要泄露”。检索前过滤是基本要求。用户没有权限的文档不应进入候选集，更不应进入模型上下文。对于多租户系统，租户、部门、项目、密级、有效期都应参与过滤。权限过滤后，还要监控“有权限候选数量”，否则用户可能因为权限范围太窄而得到看似合理但证据不足的答案。
增量更新需要内容哈希和来源记录。每次文档变化后，系统应能判断哪些知识单元新增、修改、删除，哪些向量需要重算，哪些缓存需要失效，哪些评测集需要重跑。直接全量重建虽然简单，但在大规模知识库里会造成长时间不可用、版本混乱和成本浪费。生产环境更适合采用“源文档快照、解析产物、切分产物、向量产物”分层保存，让每一层都能比对和回滚。
切分让片段可检索也可阅读
切分是RAG里最容易被低估的环节。片段太短，检索粒度细，召回看似准确，但模型拿到的上下文缺少条件、例外和定义；片段太长，语义完整性好，但向量表达变钝，召回容易被无关内容稀释，重排和生成成本也会上升。切分的本质是为检索和生成同时服务，而不是追求某个固定长度。
通用做法是按结构优先，再按长度补刀。网页和Markdown先按标题层级切；PDF先恢复章节、段落、表格和页码；代码先按文件、类、函数、注释块切；客服记录先按问题、回答、时间线切；合同先按条款、定义、附件切。只有在结构单元过长时，才用字符数或token数继续切分。这样做能避免把“适用条件”和“例外条款”切到不同片段里。
重叠窗口不是越大越好。适度重叠可以保留跨段语义，尤其适合定义后接解释、问题后接答案的资料。但重叠过大，会制造大量近重复片段，导致召回结果看起来有很多证据，其实都来自同一小段文本。建议把重叠当作补救手段，而不是主策略。更好的方式是保留父子结构：检索时用较小子块提高命中率，生成时回填父段落或相邻段落，既能找得准，也能读得完整。
表格要单独处理。很多业务答案藏在表格里，例如价格、权限矩阵、版本差异、报销标准、接口字段。把表格按行直接拼成自然语言，常会丢失列名和单位。更稳的做法是为每个表格生成表题、列说明、行标识和单元格上下文；对于宽表，可以按主题列拆分；对于数值表，应保留单位、币种、时间范围和适用对象。模型引用表格时，要能指出来自哪张表、哪一行或哪一列。
代码知识库的切分应避免只按固定长度。函数签名、注释、调用关系、类型定义、配置项、测试用例之间存在强关系。问“这个参数在哪里校验”时，答案可能不在函数本体，而在上游路由、中间件或测试断言里。代码RAG适合把语法树、符号索引、文件路径、依赖关系和文本向量结合起来。片段内容不仅要包含代码，还要包含路径、符号名、导出名和最近的注释说明。
切分质量可以用小规模人工集快速验证。选二十个真实问题，人工标注答案所在文档和段落，然后检查切分结果是否把证据完整保留下来。如果一个答案需要三段才能成立，切分产物至少应能通过相邻扩展或父块回填把三段一起送入生成阶段。不要等到全链路上线后才发现切分把关键否定词、适用条件或时间范围切掉。
嵌入是检索索引而非语义魔法
嵌入模型把文本映射为向量，使相似语义可以通过距离计算找到。它解决的是“用自然语言找相关内容”的问题，不解决资料正确性、权限、时效、结构理解和答案生成问题。选择嵌入模型时，应看语言覆盖、领域适配、上下文长度、向量维度、吞吐、成本、稳定性和能否本地部署。中文知识库尤其要用中文问题做评测，不要只看英文榜单。
入库文本和查询文本的规范化要一致。标题、正文、标签、路径、时间、产品名、缩写、同义词会共同影响向量表示。很多系统只把正文送去嵌入，导致“报销上限”“差旅标准”“城市等级”这类问题找不到表格，因为表格正文没有自然语言标题。更稳的做法是构造检索文本：把标题层级、摘要、关键字段和正文合并成面向检索的文本，同时把原文单独保存给引用和展示。
嵌入前要处理专有名词和缩写。企业内部有大量简称、项目代号、系统名、接口名、课程名。向量模型可能不知道“灵犀台”和“知识运营后台”指同一系统，也可能把“RAG”“检索增强生成”“知识问答”分得过远。可以通过词表扩展、查询改写、同义词召回、元数据标签和少量微调来改善。不要把所有同义词都塞进正文，否则会污染引用；更适合把它们放入检索字段或查询扩展层。
向量维度和索引类型会影响性能。小知识库可以直接精确搜索，大知识库通常需要近似最近邻索引。Faiss等向量检索工具提供多种索引方式，能在速度、内存和召回率之间做取舍。工程上要用自己的查询集测召回率，而不是只看索引构建速度。一个索引快但漏掉关键证据，最终会让大模型编出漂亮错话。
向量更新要和文档版本同步。嵌入模型升级后，旧向量和新向量不能随意混用，因为向量空间可能变化。更好的方式是给每批向量标记模型名称、版本、维度和生成时间。升级时建立新索引，跑离线评测和影子流量，再切换线上读流量。对于关键业务，保留旧索引回滚窗口，避免模型升级后召回质量突然下降。
多路召回与证据覆盖率
生产级RAG很少只靠单一路径召回。向量检索擅长语义相近的问题，关键词检索擅长专有名词、编号、代码、报错、精确条款和罕见实体。元数据过滤擅长缩小范围，图关系擅长沿组织、产品、依赖、章节和引用关系扩展。多路召回的目标是提高候选证据覆盖率，然后交给重排和融合层控制精度。
第一阶段召回应宽一些。很多团队把top-k设得很小，导致重排器没有机会纠错。合理做法是让不同召回器各自返回一批候选，再做去重、合并和初步过滤。比如关键词返回二十条，向量返回三十条，标题匹配返回十条，元数据命中返回十条，最后合并成三十到六十条给重排。具体数量要看延迟预算和文档粒度，不要照搬固定值。
混合检索可以用简单加权，也可以用倒数排名融合等方式。核心不是公式多复杂，而是每条候选都要保留来源、分数和命中原因。线上排查时，工程师需要知道某段证据是因为标题命中、关键词命中、向量相似还是同义词扩展被召回。没有命中原因，调参会变成猜测。
查询改写对RAG很重要，但不能失控。用户问题常常短、口语化、省略上下文，例如“这个怎么开”“有上限吗”“失败了咋办”。系统可以结合对话历史、用户角色、当前页面和已选资料改写成完整查询。改写后应保留原问题，并限制改写只服务检索，不应悄悄改变用户意图。对高风险场景，最好把改写结果也纳入日志和评测。
多轮对话里的召回要处理指代。用户第二轮问“那试用期呢”，如果只拿这一句检索，系统很可能找错主题。应把上一轮已确认主题、实体和文档范围带入查询。与此同时，也要允许用户切换主题。如果用户说“换一个问题”，系统不应继续把旧上下文强塞进去。多轮RAG需要对话状态管理，而不是把所有历史消息无差别拼接。
召回阶段还要考虑时间。制度、价格、接口、模型能力都会变化。检索时应优先当前有效资料，必要时允许用户指定历史时间点。答案中出现“目前”“最新”“现行”这类词时，证据必须有明确更新时间或生效时间。没有时间元数据的知识库，不能稳定回答时效问题。
重排选择可回答证据
召回得到的是候选，不是最终证据。向量相似不等于能够回答问题。比如用户问“哪些情况不能报销”，向量检索可能召回“可以报销的范围”；用户问“接口返回401怎么办”，可能召回“登录接口说明”而不是“鉴权失败排查”。重排器通过同时阅读查询和候选文本，判断候选是否真正相关，通常比单纯向量距离更适合做第二阶段筛选。
重排器可以是专用rerank模型、交叉编码器，也可以是较小语言模型打分。专用模型速度快、输出稳定，适合高并发；语言模型打分灵活，能处理复杂意图和结构化判断，但成本和延迟更高。实际工程中常见组合是：第一阶段用混合检索召回几十条，第二阶段用rerank模型排序，第三阶段用规则和轻量模型做证据压缩，最后只把最有用的若干段送入大模型。
重排前要先做硬过滤。权限、租户、语言、文档类型、时间范围、产品线、状态字段这些确定条件应在重排前处理。不要把用户无权访问或已废弃的文档交给重排器再期望它自动排低。确定性约束越早执行，候选集越干净，成本越低。
重排结果需要阈值。没有足够相关证据时，系统应拒答或要求用户补充信息，而不是把低分候选硬塞给模型。阈值不能只靠主观感觉，应通过评测集估计：在可回答问题上，正确证据分数通常落在哪里；在不可回答问题上，误召回分数通常落在哪里。阈值还可以按场景不同设置，客服知识库可以宽一点，财务制度和法律条款应更保守。
证据压缩要保持可引用性。压缩不是让模型随意总结候选文档，而是提取与问题相关的句子、表格行、条件和例外。压缩后仍要保留原始来源位置。否则最后答案引用的是原文，实际上下文却来自压缩摘要，审计时很难解释模型为什么那么写。
上下文组装与证据位置
生成阶段的输入不应是一堆无序片段。上下文应按问题需要组织：先放高置信证据，再放补充证据；同一文档的相邻片段合并；冲突资料并列展示；表格和定义保留结构；每段证据带短引用标识。模型更容易使用清晰证据，也更容易在答案里建立引用关系。
上下文预算要留给答案思考和引用。很多系统把上下文窗口塞满，以为证据越多越好。实际模型在超长上下文中容易忽略中间位置、混淆相似段落、引用错误来源。更稳的做法是控制证据数量，只放能回答问题的片段；对于需要综合多份资料的问题，用分步检索或分段摘要，而不是一次性塞入所有内容。
提示词应明确三件事：只依据给定证据回答；证据不足时说明无法确认；每个关键结论附引用。不要在提示词里写大量内部流程说明，也不要让模型向最终用户暴露“我在检索上下文”。用户只需要看到清楚答案、必要解释和可点击来源。对最终用户而言，RAG的存在感应体现在答案可靠，而不是页面里堆满系统术语。
模型还需要处理冲突证据。真实知识库会出现旧政策和新政策并存、不同部门口径不同、文档正文和附件不一致。生成阶段不应强行二选一。更好的答案是指出冲突来源、各自生效时间和适用范围，并建议以当前有效版本或主管部门文件为准。如果系统无法判断哪个版本有效，应明确无法确认，而不是创造一个折中结论。
引用让答案回到原文
引用不是装饰，而是RAG区别于普通聊天的重要能力。引用应支撑答案中的关键事实，而不是只在段末堆几个来源。每个涉及数字、条件、步骤、限制、定义、责任、时间的结论，都应能对应到一条或多条证据。用户点击引用后，应看到原文附近内容，而不是只打开文档首页。
引用粒度要合适。太粗的引用，例如只引用整份PDF，会让用户无法核验；太细的引用，例如每个词都标注来源，会影响阅读。常见做法是引用到章节、页码、段落或表格行。对于网页，引用到标题锚点和段落；对于PDF，引用到页码和高亮区域；对于表格，引用到表名和行列；对于代码，引用到文件和符号。
答案中的引用要避免“引用漂移”。引用漂移指答案说的是A，引用打开后只有B，或者引用片段只是相似背景，并不能支持结论。解决办法包括：生成前给每段证据分配稳定编号；要求模型在写关键句时选择证据编号；生成后用校验模型检查结论与引用是否一致；对无法支撑的句子删除或改写。
引用也要处理权限。用户能看到答案，就应能看到支撑答案的证据；如果证据来自用户无权查看的资料，系统设计已经失败。对于摘要级场景，如果只能展示摘要不能展示原文，页面必须说明来源受限，并避免输出敏感细节。最稳的权限模型仍然是检索前过滤。
分层评估召回、证据、答案和体验
RAG评测不能只问“答案像不像”。要把链路拆开评估。召回评测看正确证据是否进入候选集，常用命中率、召回率、MRR、NDCG等指标。重排评测看正确证据是否排在前面。答案评测看事实是否准确、是否完整、是否只依据证据、是否承认不知道。引用评测看每个关键结论是否被引用支撑。体验评测看答案是否清楚、是否有下一步、是否符合用户角色。
评测集应来自真实问题。冷启动时可以从客服记录、搜索日志、工单、文档目录、销售问答、课堂提问中抽样。每条评测样本最好包含用户问题、用户角色、期望答案要点、相关证据、不可接受答案和难点标签。难点标签很有价值，例如“跨文档综合”“表格数值”“多版本冲突”“权限边界”“否定条件”“代码调用链”“中文缩写”。有标签后，团队才能知道优化到底改善了哪类问题。
不要只保留可回答问题。生产系统必须识别不可回答问题。评测集应包含知识库没有覆盖的问题、用户权限不足的问题、需要实时工具的问题、意图不清的问题和带有错误前提的问题。一个RAG系统如果永远回答，看起来积极，实际上风险很高。拒答能力是质量的一部分。
自动评测要和人工评审结合。RAGAS等工具提供了上下文精确率、上下文召回率、忠实度、答案相关性等指标，可以高频跑回归。语言模型评审也能快速发现明显幻觉和引用不一致。但关键场景仍要人工抽检，尤其是政策、财务、医疗、法律、教育评价和安全生产。自动分数适合趋势监控，不能完全替代业务专家判断。
评测要版本化。每次切分策略、嵌入模型、索引参数、召回融合、重排模型、提示词、生成模型变化，都应记录版本并跑同一套评测。否则一次优化可能只提升某类问题，却悄悄伤害另一类问题。评测报告应展示总体分数、分场景分数、失败样例和成本延迟变化。只报一个平均分，会掩盖真正的上线风险。
线上监控与持续变化
上线后，RAG质量会因为知识变化、用户变化、模型变化和流量变化而漂移。监控不能只看接口是否可用，还要看答案是否可信。基础指标包括请求量、成功率、延迟、token消耗、检索耗时、重排耗时、生成耗时、上下文长度、候选数量、引用数量、拒答率、缓存命中率和错误类型。
检索质量指标同样重要。应记录每次查询的召回来源、候选分数、重排分数、最终证据、被引用证据和用户反馈。这样当用户投诉“答错了”时，团队能判断是知识缺失、召回漏掉、重排排错、生成歪曲，还是引用展示失败。没有链路日志，只看最终答案，排障会非常慢。
线上反馈要进入知识改进流程。用户点踩、搜索无结果、低置信拒答、人工转接、重复追问，都可能说明知识库或检索策略需要更新。反馈不应只存进日志，而应形成待处理队列：补文档、改标题、加同义词、调整权限、修切分、更新评测样本。RAG的优势不是一次建完，而是能随着真实问题持续变好。
监控还要关注知识时效。系统可以统计每条被引用资料的年龄、过期状态、版本分布和使用频次。高频引用但长期未更新的资料应提醒负责人复核；已废弃资料如果仍被召回，应触发告警；用户频繁问到但知识库没有覆盖的主题，应进入内容建设计划。
成本监控要按链路拆开。嵌入成本、向量库成本、重排成本、生成成本、缓存收益、长上下文成本都应可见。很多RAG系统刚上线时成本可控，随着文档增长和top-k变大，重排和生成费用会快速上升。优化成本不能只换便宜模型，也可以从切分、候选数量、缓存、证据压缩、批量嵌入和冷热索引入手。
隐私和安全监控不能省。日志中可能包含用户问题、内部资料片段和模型答案。应做脱敏、访问控制和保留期限管理。高风险词、越权访问、异常批量查询、提示注入攻击、资料外泄尝试都应有检测。RAG引入了外部知识，也扩大了攻击面，尤其要防止恶意文档诱导模型忽略系统约束、泄露上下文或执行不该执行的操作。
常见失败模式和修复方向
第一种失败是“知识库有答案，但系统答不知道”。这通常是召回漏掉了。排查顺序是看文档是否入库、切分是否保留答案、嵌入文本是否包含标题和同义词、关键词检索是否启用、元数据过滤是否过窄、top-k是否太小、查询改写是否偏题。不要直接改提示词，因为模型没拿到证据时，提示词无法凭空补回事实。
第二种失败是“找到了相关资料，但答案说反”。这常发生在否定条件、例外条款、多版本制度和表格解释里。修复方向是改善切分，让条件和结论在同一证据块；重排时提高对否定词和问题意图的敏感度；生成时要求逐条列出适用条件；引用校验阶段检查关键结论是否被证据支持。
第三种失败是“引用看起来很多，但都不支撑答案”。这说明引用只是按检索结果附加，没有和答案句子绑定。应改为证据编号驱动生成，并在生成后做引用一致性检查。对于无法找到证据支撑的句子，宁可删掉，也不要让答案显得丰富。
第四种失败是“延迟太高”。RAG链路长，慢点可能在解析、检索、重排、生成或网络。线上应记录分段耗时。常见优化包括向量索引调优、减少候选数量、批量重排、缓存热门查询、缓存长前缀、压缩证据、使用更快的生成模型、对简单问题跳过重排。不要盲目砍掉重排，因为它可能是质量关键。
第五种失败是“用户觉得答案啰嗦”。RAG系统容易把检索到的内容都讲一遍。面向最终用户的答案应先给结论，再给必要依据和下一步。引用放在关键结论旁边，不要把原文大段复制出来。对于操作型问题，按步骤写；对于政策型问题，按条件写；对于排障问题，按优先级写；对于比较问题，按维度写。
第六种失败是“评测分数不错，真实用户不满意”。原因通常是评测集太干净，没有覆盖口语问题、多轮省略、权限限制、资料冲突和长尾实体。解决方式是持续从线上日志抽样，把失败问题回灌到评测集。评测集不是一次性资产，而是产品理解的沉淀。
上线前检查
资料侧要确认来源可信、版本明确、权限完整、解析正确、去重完成、更新路径可运行。切分侧要确认结构保留、表格可读、父子块可回填、片段有稳定编号。嵌入侧要确认模型版本记录、中文效果评测、增量更新可回滚。召回侧要确认混合检索、元数据过滤、查询改写、候选去重和召回日志。重排侧要确认阈值、延迟、失败降级和证据压缩。生成侧要确认只基于证据、证据不足拒答、冲突资料不强答、答案文案面向最终用户。引用侧要确认引用能打开到原文位置，关键结论都有支撑。评测侧要确认可回答和不可回答样本都覆盖，版本变化会自动回归。监控侧要确认链路日志、质量反馈、成本、时效、安全和告警。
这份清单的价值在于把RAG从“模型功能”拉回“工程系统”。真正可用的RAG不是一次演示成功，而是资料每天更新、用户问题每天变化、模型版本不断迭代时，仍然能保持可解释、可评估、可恢复。它需要检索工程、内容治理、产品设计、评测体系和运维监控共同工作。
可落地的迭代路线
第一阶段做最小可信闭环。选择一个边界清楚的资料域，建立解析、切分、嵌入、混合召回、重排、生成、引用和日志。评测集不必很大，但必须包含真实问题和人工标注证据。这个阶段的目标不是覆盖所有知识，而是证明链路可解释、可评估。
第二阶段扩大资料和问题类型。加入表格、PDF、网页、工单、多轮对话和权限过滤。开始跟踪失败样例，建立知识补全流程。此时要特别关注切分策略是否还能支撑复杂文档，召回融合是否被某一路结果支配，引用是否仍能稳定落到原文。
第三阶段做线上质量运营。引入用户反馈、低置信拒答、热门问题、无答案主题、过期资料提醒、成本看板和安全审计。RAG团队的日常工作会从“调模型”变成“维护知识质量和证据链”。这也是生产级RAG和演示型RAG真正分开的地方。
第四阶段再考虑高级能力，例如多跳检索、图谱增强、代理式检索规划、自动查询分解、跨模态检索、个性化答案、主动知识发现。高级能力应建立在稳定基础链路上。基础链路不稳时，引入更多智能步骤只会让问题更难排查。
阶段性结论
RAG工程的核心判断很朴素：用户问的问题，系统有没有可信资料；资料能不能被准确找到；模型有没有严格依据资料回答；用户能不能检查来源；团队能不能知道哪里错并持续修。切分、嵌入、召回、重排、引用、评测和监控不是孤立模块，而是一条证据链。每个环节都要为最终答案负责。
做RAG不要迷信单个模型、单个框架或单个参数。更可靠的路线是先定义业务边界，再治理资料，再让检索和重排给模型提供干净证据，最后用评测和监控守住线上质量。这样建出来的RAG，才不是把大模型接到文档库上的聊天框，而是一个能被用户信任、能被团队维护、能随着业务成长的知识系统。
不同资料类型的处理差异
企业知识库常常把所有资料都叫“文档”，但不同资料的RAG处理方式差别很大。制度类文档重视版本、生效时间、适用范围和例外条款；产品手册重视功能入口、操作步骤、限制条件和截图位置；技术文档重视接口、参数、返回码、版本兼容和示例代码；工单记录重视问题现象、环境、根因、处理动作和复盘结论；会议纪要重视决议、责任人、截止时间和未决问题。切分和元数据设计必须反映这些差异。
制度类资料最怕旧版本干扰。入库时应把发布日期、生效日期、废止日期、发文部门、适用对象和版本状态作为核心字段。召回时默认排除废止版本，除非用户明确查询历史政策。答案里涉及义务、限制、金额和审批条件时，要引用到具体条款。若同一主题存在多个部门制度，系统应优先显示适用范围，而不是把它们混成一个结论。
产品和客服资料最怕步骤不完整。用户问“怎么开通”“怎么退款”“为什么失败”，答案通常需要按顺序说明入口、条件、操作和异常处理。切分时要保留前后步骤关系，不能把第一步和注意事项拆散。召回时除了命中问题文本，还要命中产品模块、用户身份、渠道和版本。生成时应把答案写成可执行步骤，不要输出文档摘要。
技术资料最怕符号和版本错配。接口名、字段名、错误码、配置项、依赖版本、环境变量都需要精确匹配。这里关键词检索的价值很高，不能只依赖向量。代码块和命令行示例应保留原格式；参数表要保留字段类型、是否必填、默认值和限制。用户问排障问题时，系统应优先召回错误码、日志片段和已知问题，而不是只召回概念说明。
研究报告和长文章适合做分层摘要，但摘要不能替代原文证据。可以为文档生成章节摘要、主题标签和关键结论，帮助召回和导航；真正回答时仍应回到原始段落。摘要层如果写错，会放大错误，因此要明确区分“检索辅助摘要”和“可引用原文”。最终引用应指向原文位置，而不是只引用模型生成的摘要。
RAG 与智能体的配合
RAG负责把可信资料交给模型，智能体负责在任务复杂时规划步骤、调用工具、追问用户和执行动作。两者可以结合，但不能互相替代。把RAG包装成智能体，并不自动变聪明；让智能体随意检索，也不自动可靠。生产系统应把“查资料”“判断证据是否足够”“调用业务工具”“生成最终答复”拆成清楚阶段，每个阶段都可记录、可评测。
当用户问题简单且答案明确时，不需要智能体绕一大圈。一次查询、一次重排、一次生成就够。比如“报销发票抬头要求是什么”，RAG直接回答更快。只有当问题需要多步拆解时，才让智能体参与。例如“帮我判断这份合同付款条款有哪些风险”，系统可能需要先识别合同类型，再检索公司付款政策，再抽取合同条款，再比较差异，最后列出风险和建议。
智能体式RAG必须防止无边界搜索。代理如果每次都改写查询、扩展关键词、递归检索，很容易浪费成本并引入无关证据。更稳的策略是限制检索轮数、要求每轮说明缺什么证据、对已找到证据做去重，并在证据不足时及时追问用户。智能体的“会思考”应体现为有目标地补证据，而不是无限增加步骤。
工具调用和RAG也要分清。知识库适合回答稳定事实，业务工具适合查询实时状态和执行动作。用户问“我的订单现在到哪了”，应调用订单系统；用户问“订单状态有哪些含义”，应查知识库；用户问“为什么我的订单卡住了”，可能需要先查实时订单，再检索对应异常说明。把实时问题硬交给静态RAG，会产生过期答案；把稳定说明都做成工具查询，又会增加不必要复杂度。
团队分工与内容运营
RAG不是单个后端工程师能长期独自维护的模块。工程团队负责解析、索引、检索、重排、生成、监控和权限；产品团队负责定义使用场景、答案形态、用户反馈和拒答体验；内容负责人负责资料权威性、版本、结构和缺口补齐；业务专家负责评测样本和高风险答案审查。没有内容运营，技术链路再强也会慢慢被旧资料和知识缺口拖垮。
内容负责人应能看到知识使用情况。哪些文档被高频引用，哪些主题经常无答案，哪些资料被用户点踩，哪些旧版本仍被检索到，哪些问题需要人工转接，这些都是知识运营指标。RAG系统最好提供面向内容负责人的工作台，让他们能补标题、改摘要、标记废止、合并重复、补充问答和提交复核，而不是每次都找工程师改数据库。
工程团队应避免把所有质量问题都归因于提示词。提示词当然重要，但RAG质量更多来自资料、切分、召回和评测。一个稳定团队会把失败样例归类：资料缺失交给内容建设，解析错误交给摄取管道，召回失败交给检索策略，生成歪曲交给提示和模型，引用错误交给证据绑定，权限问题交给访问控制。分类越清楚，迭代越快。
从演示到生产的关键转变
演示型RAG追求“问一个问题能答出来”，生产级RAG追求“每天大量真实问题都能被可信处理”。这两个目标差距很大。演示可以手工挑文档、手工调prompt、手工忽略异常；生产必须处理脏数据、权限、版本、并发、投诉、成本、监控和回滚。上线前如果只看几个成功样例，很容易把偶然命中误判成系统能力。
生产级RAG要接受“不回答”也是好结果。用户问题超出资料范围、证据冲突、权限不足、时间不明确、意图不清时，系统给出边界清楚的回应，比编造答案更专业。拒答不是失败，无法判断还强行判断才是失败。面向最终用户的拒答文案应给出下一步，例如建议补充产品版本、上传相关文件、联系负责部门或查看指定资料入口。
最后，RAG的质量应以用户完成任务为准。不是检索分数高就一定好，也不是答案长就一定专业。用户能不能找到制度依据，能不能完成操作，能不能定位故障，能不能理解差异，能不能放心引用，这些才是最终指标。技术链路服务于这个目标，所有参数、模型和框架都应围绕它取舍。
参考资料
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks: https://arxiv.org/abs/2005.11401
- Karpukhin et al., Dense Passage Retrieval for Open-Domain Question Answering: https://arxiv.org/abs/2004.04906
- LangChain Retrieval 文档: https://docs.langchain.com/oss/python/langchain/retrieval
- LangChain RAG 文档: https://docs.langchain.com/oss/python/langchain/rag
- LlamaIndex 文档: https://docs.llamaindex.ai/
- OpenAI Embeddings 文档: https://platform.openai.com/docs/guides/embeddings
- Faiss 官方文档: https://faiss.ai/
- Cohere Rerank 文档: https://docs.cohere.com/docs/rerank-overview
- Ragas 指标文档: https://docs.ragas.io/
- LangSmith Observability 文档: https://docs.langchain.com/langsmith/observability-concepts