RAG工程化落地全链路指南：切片、召回与生成调优

RAG这三个字母最近两年做AI应用的人应该耳朵都听出茧了。检索增强生成说白了就是给大模型外挂一个知识库让它在回答之前先去“查资料”。我接手过的不少项目从客服问答到内部文档助手底层都是这同一个套路文档切碎、向量化、召回、让LLM照着资料回答。这条链路说起来简单真正落地时几乎每步都有坑切片切不好、召回召不准、提示词写不对都可能让最终成果直接垮掉。这篇文章不聊概念就按实际项目里的推进顺序把RAG的完整链路拆开过一遍文档切片怎么做才算合理、Embedding模型怎么选、向量检索怎么调参、召回之后为什么还要加Reranker、最后怎么把检索结果交给LLM生成靠谱的回答。每个环节我会结合自己做过的项目补充一些可以直接抄走的参数和排查思路适合正在搭RAG系统的开发者也适合被“看着简单、做起稀烂”折磨的产品和技术同学。1. RAG的整体链路别急着写代码先把三个环节的边界理清楚RAG的标准链路是“文档切片→向量化检索→LLM回答生成”但实际工程里还要在中间加上一环索引构建也就是把切片后的内容向量化写入向量数据库供后续检索使用。更完整的链路应该是文档解析与清洗→切片Chunking→Embedding向量化→构建索引→检索Retrieval→重排序Rerank→组装Prompt→LLM生成回答。这九个环节里大部分人把精力放在“Embedding选什么模型”“向量数据库用哪家”上这也是一开始常见的误区。实际跑过几个项目之后我的感受是决定RAG系统上限的是切片和检索决定最终体验的是Prompt组装而Embedding模型和向量数据库只是中间的基础设施。模型建得再漂亮切片把语义切碎了检索阶段找回来的就是一堆残骸检索回来的内容不相关后面Prompt写得再花哨LLM也只能一本正经地胡说。所以理清链路边界本质上是理清每个环节的“责任范围”。文档解析负责把PDF、Word、网页这些异构格式变成干净的纯文本切片负责把长文本切成适合检索的最小语义单元Embedding负责把文本映射成向量让语义相近的内容在向量空间里距离更近向量数据库负责存储和近似最近邻搜索检索负责在用户query和文档向量之间算相似度拿回候选集Rerank负责从候选集里把真正有用的内容捞到最前面Prompt组装负责把用户问题、参考片段、历史对话揉成一个LLM能理解的上下文LLM则负责基于这些信息生成最终回答。我在带几个模拟项目的时候会把每个环节单独设置一个可观测的指标切片效果看“单切片的语义完整度”检索效果看“召回#-5命中率”生成效果看“回答引用准确率”。只有每个环节都有明确的观测点后面排查问题时才不用靠猜。1.1 为什么RAG这一套“笨办法”仍然主流先回答一个不少初学者问过的问题现在长上下文模型越来越大直接把整本文档塞进Prompt不就行了为什么还要折腾切片和检索这个问题的答案其实相当现实。当知识库达到几百个文档、几万个切片之后即使模型的上下文窗口能容纳海量token每次请求把全量内容塞进去也会带来三个问题第一是成本直接起飞每轮对话都烧掉大量输入token第二是响应延迟暴涨用户等不起几秒钟的预处理第三是无关噪声过多会显著稀释模型对关键信息的注意力反而不如精准给几千字上下文时的回答质量高。RAG的本质是“用检索来缩小生成时的注意力范围”。它不追求把全部知识装进Prompt而是先把知识库做成索引回答问题时只取与当前问题最相关的几个片段。这种做法在工程上非常务实也因此成为目前私域知识问答、企业智能助手、智能客服这些场景的主流方案。理解了这一点就明白链路里真正决定成败的是你“怎么找到那几段最相关的片段”而不是模型本身有多强。1.2 链路在不同规模下的真实表现拿两个我拆过的典型项目举个例子。一个是内部知识库问答文档量大约几百份每份几千字涉及规章制度、产品手册若干类。这种规模下用通用Embedding模型加基础向量检索就能获得不错的体验。另一个是在某课程项目里模拟的文档问答系统数据源高度异构有扫描版PDF、表格型文档、技术博客网页。这种项目里如果只做简单切片加向量检索召回质量就会明显不稳定PDF解析出来的文本乱码、表格内容被切碎、网页里的导航噪声干扰向量相似度每一环都会拉低最终答案质量。综合两个项目的经验我总结出RAG工程的一条铁律在数据源复杂、查询模式多样的情况下“混合检索 Rerank”几乎是必需品单纯靠向量相似度很难扛住所有类型的query。后面我会具体展开这部分的调优细节。2. 文档切片整个RAG的地基最容易被低估的一步如果说RAG是一条流水线那文档切片就是进料口。进料口的料切坏了后面再怎么优化也白搭。切片看似就是“把长文本切成几段”但切多长、按什么边界切、要不要重叠直接决定了检索能找回什么。我在实际项目里发现切片对最终效果的影响往往大于换Embedding模型。这里先给一个直观类比把一个长文档想像成一头整牛你需要先切成牛排才能下锅。如果顺着骨头和筋膜乱切肉是碎了但每一块都不完整如果知道纹理再切每块都能保留完整的口感和营养。文档切片就是要顺着“语义纹理”来切而不是按固定的字符数硬切。2.1 切片长度没有万能参数但有参考区间切片长度通常由chunk_size每个切片的token数或字符数和overlap相邻切片的重叠量两个参数控制。我在实践中最常见的设置是中文场景下chunk_size取300~500个字符overlap取50~100个字符。为什么是这个区间因为切片太短会切断语义。比如一个完整的“退款政策说明”被切成两三段每段各自有“退款条件”“退款流程”的不同内容检索时用户问“退款要满足什么条件”可能召回的切片里只有流程而没有条件信息就不完整。切片太长则有两个问题一是向量表示的粒度变粗一段里杂糅多个主题会导致语义互相稀释相似度计算结果不准确二是检索召回后占用的上下文窗口太大一次只能塞下很少几个片段反而浪费了上下文空间。所以chunk_size的本质是一个“语义单元”的选择。你希望检索的最小单位是什么粒度切片就按这个粒度来。做产品FAQ问答时用一个完整QA对作为切片效果比按字数随机切好得多因为语义单元天然完整。做长文档问答时尽可能按“标题段落”来切让每个切片拥有一个相对独立完整的论点。这个设计取舍需要在每个项目里自己试但我建议先按以下搜索范围启动中文纯文本、段落结构清晰用300字左右初始切英文或多语混排先按200~250个token试如果文本有明确的标题层级则优先按标题分块。2.2 重叠切片的作用以及为什么必须设重叠overlap的作用是缓存边界语义。切到500字时前一段的结尾很可能是一个正在展开的概念下一段的开头刚好是同一个概念的解释。如果没有重叠这个词的完整语义会被硬生生拆成两半向量化时两边都“缺钙”。加了重叠之后这个概念会在两个切片里各出现一次检索时至少能有一侧完整命中。不过重叠不是越大越好。重叠过大会产生大量高度相似的冗余切片检索时同一个内容被召回好几遍白白浪费上下文窗口。我通常把overlap控制在chunk_size的10%~20%之间。比如说定400字重叠50到80字就足够覆盖常见英文和中文的语义冗余边界了。正式项目里我会先跑几个不同的参数组合用小规模测试集对比最终召回命中率而不是凭感觉定死。2.3 结构化文档的切片头号难点是保持层级做了两三个RAG项目之后我认为最难处理的不是纯文本而是有结构的文档。一份几十页的合同、产品规格书、技术手册天然存在“章节和小节”的层级。如果无视结构硬切一个关键表格可能被拦腰切断一个章节约定义可能只剩一半。检索时用户问“本产品的保修期限是多久”召回切片里只包含某个条款的第一行后边的具体数字却在另一段里模型拼不出来。我的解决思路是“先结构化再切片”先做章节识别利用文档里已有的Heading标记或按标题样式抽取目录把文档按章、节形成一棵树然后以“最小独立语义单元”为叶子节点把每个小节里的内容做成切片如果小节内容仍过长再按段落或固定长度二次切分。这样得到的切片天然保留了上下文归属信息后面还能拼回标题路径比如“产品手册 保修政策 保修期限”对检索和生成都有帮助。另外要特别提一下表格的切片。表格类内容如果直接用文本提取很容易变成一串丢失结构的数字和标签向量化后基本就是废的。我常用的做法是把表格按行转成“键值对描述”比如“保修期限24个月保修范围非人为损坏”每一行成一条独立记录。这样做切片后问答系统在回答涉及表格的问题时能明显看到召回效果提升。2.4 实际参数参考与切片效果的观测方法以某课程模拟项目中处理过的一份混合型知识库为例文档集包括约几十份长文和十几份表格型FAQ。我最终采用的参数是普通长文按标题结构切片chunk_size设为400字符overlap 60字符FAQ文档按单条QA切不做重叠表格文档按行转描述式文本每条单独成切片。效果对比下来在数据集上手工标注的50个测试问题上命中率从统一随机切片的60%出头提升到了80%以上。这个提升完全是切片策略换来的。判断切片好不好除了看最终问答质量还可以用一个简单的“自检问题”方式随机抽取几个切片看一眼它们是否在语义上自洽也就是“不看前后文单看这一段能否大致理解它在说什么”。如果一段内容读起来像被截断的句子那说明切点设置有问题需要调整边界策略或减小chunk_size。3. Embedding与索引构建选对模型只是开始检索质量的重点在索引设计切片做完下一步就是把每个切片转成向量写入索引。这一块很多新手容易卡在选择恐惧症上模型用哪个、向量库用哪个、索引参数怎么调。我先把结论放前面没有完美的Embedding模型也没有绝对最好的向量库你需要做的是为自己的数据场景找到“够用且可控”的组合。3.1 Embedding模型的选择逻辑不要只看刷分榜现在可选的Embedding模型非常多有开源的也有商用API。判断一个Embedding模型好不好不能只看公开榜单因为榜单数据分布通常偏通用很难代表你手里的文档类型。我一般按三个维度评估领域适配度在与你业务相近的语料上模型给出的向量相似度是否与“人工判断的相关性”一致语言覆盖中英文混排场景下比单语模型更稳定的多语模型往往表现更好最大输入长度Embedding模型的max_sequence_length决定了单条切片的长度上限。如果模型最大支持token只有128而你的切片是400字是不匹配的实际做项目时我会准备一个几十到上百条的小型验证集每条包含“一个query、一个正相关片段、若干个负相关片段”。用候选的Embedding模型分别跑一遍看看在验证集上召回的排序是否把正相关排在前面这个测试比盲看分数可靠得多。像某项目中我们测试过几个通用模型最终选了一个在中长文本段落和表格型文本上表现更稳的模型理由是它在“相似概念不同场景”的区分上更锐利而榜上分数最高的模型在这类任务上反而有点钝。3.2 向量数据库的选型与索引参数向量数据库方面可选项也很多。选型时我主要看四个点是否支持过滤条件的有效混合检索、索引参数可否定制、数据规模下查询延迟是否可控、运维与部署成本是否匹配团队能力。对于百万级向量以下的场景一个常见选择是用支持向量检索的轻量库建在本地配合元数据过滤已经足够。对于更大的规模和更高并发才需要考虑分布式方案。不管选哪个有两类索引参数要特别关注一是索引类型常见的ANN索引会牺牲少量精度换速度所以存在“召回率不是100%”的问题二是查询时的候选集规模通常对应参数中的probe或nprobe它控制着实际遍历多少聚类中心这个值太小会漏掉高质量的向量太大则查询变慢。我在模拟项目里采用过一个稳妥的组合建立索引时把待检索向量按文档来源打上元数据标签查询时先按文档类型过滤再在子集内算相似度。这么做的好处是显著减少无关向量的干扰尤其在知识库里同时存在产品手册和客服日志时用户问维修流程不会被日志类内容干扰。3.3 混合检索向量相似度解决不了“精确匹配”问题向量检索擅长处理语义相近的表达比如“怎么退货”和“退款流程怎么走”能匹配上。但它对精确匹配很不敏感用户在文档里明明写了“SN码”它的同义词是“序列号”如果单词出现频率很低且上下文不明显向量可能把“SN码保修查询”和另一个无关内容算得很近。这就是为什么我在生产级RAG里基本都会加入BM25关键词检索把“向量召回”和“关键词召回”的结果做融合。关键词检索负责精确命中向量检索负责语义模糊匹配两者互补之后整体召回稳定性会好很多。融合方式也不复杂两个通道各自取前若干条合并去重后按得分加权排序也可以在向量库里先用关键词过滤再做向量检索。具体哪种好取决于你的用户查询习惯——如果更多是闲聊式或长句提问向量权重高一点如果更多是短词、专有名词提问关键词权重高一点。4. 检索与重排序决定用户能不能搜到正确答案的关键环节切片和索引都准备好以后检索阶段看起来就是“算相似度取top-k”。但实际操作中这个环节恰恰是问题和性能差异最大的地方。我见过不少初次搭RAG的项目检索结果里前几条明显不相关几条相关的内容反而排在后面最终回答自然就“文不对题”。4.1 相似度计算内积、余弦还是欧氏距离向量检索的相似度计算方式主要有三种余弦相似度、内积、欧式距离。一般默认用余弦相似度因为它对向量长度不敏感更关注方向适合文本语义场景。但如果你用的向量库或模型要求特定度量比如某些模型训练时就用了内积作为优化目标这时用内积可能效果反而更好。我的建议是在正式项目里用同一批验证集把几种度量方式都跑一遍比较召回排序效果。实际经验中中文文本场景有余弦和内积差距并不大的情况但个别模型在欧氏距离下表现会明显变差所以至少要做一次交叉验证再确定。4.2 召回深度与候选集设计top-k不是越大越好一开始做RAG时我习惯把top-k设得很大比如返回20条甚至30条觉得内容给得越多模型知道的就越多。后来发现效果并不好上下文里塞满低相关度的片段模型会因为“夹带私货”降低对准确信息的注意力回答反而变差。现在我做召回时会把两个参数分开召回阶段取候选集top-20到top-50重排序阶段再压到传给LLM的top-3到top-5。这个“先宽后窄”的设计既保证不遗漏相关问题也避免上下文被噪声污染。不过需要说明的是top-k的取值和你的切片粒度强相关。如果切片比较短、粒度细传给模型的片段数量可以适当多几条如果每条切片本身就很长再传5条可能已经超出预期上下文占用。所以最终的k值要结合切片长度、模型上下文限制和实际回答效果一起调。4.3 Rerank重排序向量检索之后的关键一跃只有向量相似度排序很难保证最相关的内容排在第一位。因为向量检索的效率来自“近似最近邻”它追求的是“快速找到差不多的”而不是“精确找到最对的”。为解决这个问题我基本都会在检索之后加一层Rerank。Rerank并不是再算一遍向量相似度而是用一个更强的交叉编码器模型把“用户query候选片段”成对输入直接判断它们之间的相关性并重新打分。这里有个经常被忽略的细节Rerank模型的输入上限通常比较小所以候选片段如果太长需要做截断或分段后分段打分再取最大分。成本方面Rerank需要对每一条候选都跑一次推理所以候选集一般控制在20~50条以内过多会拖慢响应速度。实际项目里加了Rerank之后top-5命中率通常会有明显提升尤其是查询表述和文档原文用词差别较大时效果格外显著。4.4 一个可参考的检索调优流程我在项目中沉淀了一套可复用的调优流程。第一步准备包含真实用户问题的测试集并标注每个问题期望命中哪几个文档片段。第二步用默认参数跑一遍检索统计top-5和top-10命中率。第三步分别调整切片参数、Embedding模型、检索类型、Rerank开关观察命中率变化。第四步把命中效果最好的参数组合固定下来再进入生成阶段的调优。注意这一步不要把最终回答好不好作为指标因为回答受生成阶段影响大用它来调检索会稀释问题来源。5. LLM回答生成最后一公里的提示词工程与上下文组装检索环节拿到了靠谱的参考片段LLM生成这个环节如果做不好前面的功夫照样白费。很多项目死在“模型知道答案但回答时不用检索内容自顾自脑补”或是“引用了片段但答非所问”。这部分的调优重点其实不在模型本身而在“你如何把检索结果和用户问题组装成一个让模型容易正确回答的Prompt”。5.1 提示词结构角色定位、任务指令、引用约束三者缺一不可我常用的一套Prompt结构包含四个部分。第一是角色和任务描述比如“你是一名售后客服助手严格基于提供的资料回答用户问题不得使用资料以外的信息”第二是检索到的参考片段按相关度顺序编号并明确标注“以下是参考资料”第三是用户问题第四是对输出的约束比如“如果资料中没有提及直接回答不知道不要编造”。这样明确的约束能大幅减少模型的自由发挥空间。这里有一个真实教训早期版本Prompt里没有提“无法回答时”模型面对问“产品停产时间”而资料里没有相关内容时还是会自作主张给一个“推测性回答”。后来我在Prompt中强制加入“若资料中无相关内容请明确回复未提供相关信息”并配合采样参数调低一点温度回答的编造率才显著下降。5.2 上下文窗口的分配给检索片段合理的占比LLM的上下文窗口是有限的在Prompt设计上要精打细算。以一个8k上下文窗口为例除了系统提示词和用户问题能分给检索片段的大概在3000~5000token左右。如果你切片较短top-5检索片段全部塞进去可能没问题如果切片较长就只保留Rerank得分最高的前2~3条并把每条截断到合理长度避免把所有候选都塞进去。我在项目里做过一组对比同一批测试问题一组给top-8不加截断另一组给top-5但做了截断且按相关度排序。结果显示后者回答的引用准确率更高生成的文本也更聚焦。原因是信息越精简LLM越容易把注意力集中到正确片段上。5.3 引用标注与可解释性让回答“可追溯”在面向企业内部使用的RAG系统里回答是否给出了出处直接影响用户对系统的信任度。我的做法是在组装Prompt时就要求LLM在回答末尾标注引用来源编号比如“依据[2]”“来自《产品手册》第三节”。同时在代码层面把检索结果的来源文档ID与这个编号对应起来这样界面上就能展示“该回答参考了哪些文档”一旦回答有误排查起来也非常快。关于幻觉问题前面说过要约束模型不知道时明确说不知道但还有一个更实操的技巧把每条检索片段的内容原样放进Prompt时特意加上片段标题和来源路径。模型看到资料来自《某公司产品手册》的“保修政策”小节会天然倾向于使用这段信息而不是凭空编造因为上下文里提供了足够的“事实感”。5.4 采样参数与回答风格的控制生成阶段的采样参数也值得单独调一调。温度太低回答会显得机械温度太高模型可能开始自由发挥偏离参考片段。我在知识库问答类项目里通常把温度设在0.1~0.3之间与代码生成类任务的设置类似都是为了“尽量贴近输入事实”。如果你的产品偏向对话式、需要一定拟人化风格可以把温度提到0.4~0.6但前提是Retrieval质量稳定否则更容易暴露出无关上下文被模型加工的问题。6. 常见问题与排查实录链路调优中踩过的坑和解决经验实际的RAG项目调试不会有“一跑准成”的好事。我把常见的坑整理成速查表按“症状→排查链路→解决思路”来写大家可以当排查手册用。6.1 召回效果差检索结果和问题不相关排查思路按顺序走先看切片效果抽样观察是否存在语句被截断、语义不完整再看Embedding模型是否适配你的文本类型再看是否需要对query做改写或扩展尤其是用户query与知识库原文用词差异过大时可以尝试先用LLM把query改写得更精确减少歧义最后确认向量检索的候选集规模是否过小比如nprobe太低导致检索时错过了正确聚类。有一次在模拟项目里发现用户问“退款”时召回质量尚可但问“退款多久到账”时召回明显变差。查了一通才发现切片的文本内容是“退款申请将在审核通过后若干工作日内至原支付账户”而“工作日”“原支付账户”这些词在查询中完全没有出现向量相似度被稀释了。后面加了Rerank并在索引里补充了同义词扩展后这个case才过掉。6.2 检索到了正确内容但LLM回答还是不对这种症状通常不是检索问题而是生成环节出了问题。先检查Prompt是否明确要求只基于参考资料回答再检查塞入的检索片段是否被截断关键结论在截断处被切掉了还要看是不是多个片段之间互相矛盾模型选择了错误的一方。解决方法是把相关度高的片段放前面在Prompt中声明“若片段冲突以编号靠前的为准”或者用票决方式让模型倾向多数一致的信息。6.3 响应延迟高长尾问题回答慢RAG系统的延迟通常在检索和生成两个环节。检索慢一般有两种原因一是候选集过大Rerank逐条推理耗时增加二是向量索引参数没调好查询遍历的聚类过多。生成慢则多半是塞入的上下文太长模型token解码量变大。我这里常用的优化策略是在召回阶段用性能更强的轻量索引保证粗召回在Rerank阶段限制候选数量不超过30条并把传给LLM的片段数压到3~5条通常能把延迟降到可接受范围。6.4 评估与迭代定期用测试集兜底RAG链路变长之后很容易出现“改这里坏那里”的回归问题。我习惯在项目里维护一份固定的测试问题集按功能模块分类标注期望输出每次改动链路后都回归一遍。这个测试集不用很大50~100条就够但需要覆盖不同提问风格直白提问、口语化提问、含专有名词的提问、跨文档的提问。有了它调优就不再是拍脑袋而变成了可以量化对比的过程。7. 一些收尾的体会就我个人的经验说RAG系统的复杂度不在于单个环节多难而在于链路太长、环节之间的错误会互相放大。文档解析多了一个乱码切片就多了一批坏数据向量化就多了一批垃圾向量检索就更容易召回错误内容LLM在错误内容上就会自信地给出错误答案。一滴水滴灌到下游就变成一股浊流。所以我们调试时我是坚持一个原则让每个环节都有独立可观测的指标一旦出问题用“二分法”定位而不是一上来就怀疑模型不行。最后再说一个小技巧做RAG不要一上来就追求完美效果先让全链路跑通用最朴素的配置搭出基线哪怕top-5命中率只有50%有参考价值的“端到端可跑通”比只在单点环节上精雕细琢要重要得多。拿到基线之后再按影响权重依次优化先改切片再调检索最后再折腾Rerank和Prompt。这个顺序能让你的调试和返工周期大幅缩短。