RAG落地实战：分块、召回、重排的6个优化结论

RAG项目真正落地从来不是把LangChain或LlamaIndex的demo跑起来就算完事。我在过去一年多里做过几个知识问答类RAG项目从分块、召回到重排每一条链路都踩过不少坑也沉淀了一些能直接复用的结论。这篇文章就把围绕“分块、召回、重排”三个核心环节的6个实战结论整理出来适合已经跑通基础demo、但觉得准确率差强人意、不知道下一步往哪优化的团队。这里没有花哨的概念包装只有我踩出来的取舍经验希望能帮你少绕几个弯。1. 别急着调Prompt三个环节决定RAG效果天花板1.1 分块、召回、重排为什么是地基一个典型的RAG流程是把文档切成若干块分块为每个块生成向量并建索引用户提问时从索引里找回相关内容召回再把召回结果按相关性排序、挑选出最佳片段重排最终把精选内容交给LLM生成答案。很多团队把大量精力放在调Prompt上觉得最后一步写得好答案就漂亮。但我在项目里见过太多“Prompt怎么调都没用”的case追根溯源往往是分块没切好或者召回环节根本没把该有的上下文找回来。我的体感是RAG效果的上限在分块下限在召回重排决定你能不能把召回到的好东西稳定发挥出来。这三个环节彼此牵制任何一个掉链子后面的优化都事倍功半。这里有个容易被忽视的点分块和召回其实在LLM介入前就已经决定了答案的候选范围。LLM再聪明也只能在你喂给它的上下文里做推理。所以RAG质量和模型聪明程度的关系远没有很多人想得那么大。与其花时间研究更复杂的prompt模板不如先把分块、召回、重排当成一个整体系统来看。1.2 六条实战结论速览先把结论亮出来方便你有个整体框架后续每一节都会展开细节和依据。序号结论一句话概括影响环节1分块大小必须结合模型上下文、文档结构动态决定默认值只能起步不能上线分块2重叠能救回跨块信息但比例失控会让索引膨胀、召回噪声变大分块3纯向量检索对专有名词和长尾不友好混合召回是生产环境标配召回4Top-K不是越大越好后面没有好的重排召回再多也是负担召回/重排5cross-encoder重排效果好但必须做延迟与成本的取舍重排6用Hit Rate和MRR评估而不是只看单次问答的对错评估这6条结论的先后顺序基本也就是我调优时从头到尾的排查顺序。先检查数据进索引之前的分块再检查召回策略最后才考虑要不要加重排否则很容易出现“重排模型换了四五个问题却出在分块把信息切断了”的情况。我自己就干过这种蠢事重排模型换了一圈没效果最后发现是分块把表格从中间劈开了。1.3 为什么我只聊这三个环节有人可能会问RAG不是还包括query改写、路由、多跳检索这些吗当然进阶玩法很多比如agentic RAG、GraphRAG这些概念现在也很热。但我的观点是如果你的分块、召回、重排这三层地基没打好上再多复杂机制都是往沙地上盖楼。很多被包装成“智能体RAG”的失败项目拆开看问题依然是“召回结果不对”或“上下文信息缺失”。所以这篇文章刻意收窄范围只聊三个基础但决定成败的环节。2. 分块很多人第一步就把知识库切坏了2.1 分块大小别拍脑袋要从上下文窗口倒推我第一次做RAG时分块参数直接抄开源项目默认值大概是text-embedding-ada-002时代比较流行的800 token结果业务文档里的产品参数表被切得稀碎。用户问“这个型号的防护等级是IP65吗”系统死活答不出来。后来才意识到分块大小不能只盯embedding模型的输入限制也不能只盯大模型窗口而是要从你想要的“最终答案形态”倒推。具体算一笔账。假设你用的是128K上下文窗口的模型看起来块切大点没事但你要考虑一次问答会往Prompt里塞几个块。如果答案需要来自5个不同文档片段每块1500 token光上下文就占了7500 token如果再把历史对话加进去总量其实很容易接近限制。反过来如果把块切到100 token定位精度是高了但语义完整性被破坏一段连贯的技术描述被拦腰截断召回回来的只有半句话模型再强也没法补全上下文。所以分块大小本质上是一个“定位精度”和“语义完整性”之间的权衡。我现在的经验是通用文本初始分块放在512到1024 token之间但一定要根据文档类型调整。产品手册这类信息密度高的工具类文本每个小节、每个参数表最好单独成块技术博客、长篇叙事块可以适当放大用段落边界做切分保留前后文逻辑。之前踩过的坑就是“一刀切512”导致代码示例和说明文字被拆开召回倒是命中率高答案却总是东拼西凑。2.2 重叠和分隔符两个最容易被忽略的参数分块里的overlap重叠参数很多人直接设为0或者随便填个数字。但我实测下来重叠能明显提升召回质量尤其是当一个知识点恰好跨在分块边界上的时候。文档里的“安装步骤”经常写到一半换页标题在上一块关键步骤在下一块没有重叠就只能靠运气。比较实用的起始值是块大小的10%到20%比如512 token的块重叠给64到128 token大部分跨块信息都能被兜住。但重叠也不是越高越好。我试过把重叠开到30%以上索引体积明显膨胀embedding的存储成本变高而且召回时经常返回好几块几乎一样的文本占用了大量上下文额度答案反而被冗余信息带偏。所以重叠解决的是“边界断裂”不是“内容冗余”这一点分清楚参数就容易定。另外重叠还会直接影响后续重排的候选质量如果候选列表里前几名全是高度相似的重叠块重排模型也很难从里面挑出更优答案。另一个容易被忽略的是分隔符。固定按token数切是最省事的做法但在很多场景下效果并不好。更好的方案是先按结构化边界切Markdown的标题、代码块、表格、换行明显的段落都可以作为优先分隔符。我在用LangChain的RecursiveCharacterTextSplitter时一般会把separators配置成“标题-段落-句子-字符”的优先级顺序这样能最大程度保留语义边界。from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap64, separators[\n## , \n### , \n\n, \n, . , ], )这个配置看着简单但实际跑起来比默认分隔符的效果稳定很多。尤其是Markdown文档标题本身就是天然的语义边界先用标题切再往下一级细化比直接按字符数硬切合理得多。2.3 结构感知分块好在哪语义分块能不能用结构感知分块说白了就是让切块尊重文档本身的骨架。比如一页公司内部运维手册一级标题是“故障处理”二级标题是“服务重启”底下每个小节是完整操作步骤。如果按固定token切很容易把步骤2和步骤3切开。用结构感知分块之后每个二级标题下的内容作为一个独立块检索时用户问“服务重启要几步”直接命中完整步骤块回答质量自然好。语义分块是另一条路不对文本做固定切分而是用embedding去计算相邻句子之间的语义距离距离变化大的地方当作边界。这种方式的优点是块边界更符合人的阅读直觉缺点也很明显计算成本高、需要先跑一次embedding模型、实时性差而且语义距离阈值并不好调线上稳定性不如结构感知分块。我在实际项目里语义分块主要用在说明书、合同这类没有明确格式、但每段主题分明的长文本上凡是有明确标题层级或表格结构的文档直接用结构感知法就够了。做知识库清洗时我还会把页眉页脚、模板字段先去干净不然这些噪声会被当成正文一起切块检索时疯狂命中一些没价值的块。清不清洗同一个分块参数跑出来的效果能差好几个点这个后面在问题排查小节里会详细说。3. 召回你的搜索不只是向量检索3.1 纯向量检索为什么覆盖不了专有名词和长尾纯向量检索的做法是把用户query和每个候选块都embedding成向量然后算余弦相似度。听起来自然但实际跑起来会发现一个很核心的问题稠密向量擅长语义相似对精确匹配一点都不敏感。比如电子行业文档里出现“CADENCE位号重排”这是一种很具体的EDA工具操作embedding很容易把它泛化成“layout中元件标号调整顺序”当你问“cadence位号重排的约束规则”时向量检索反而会把别的相似说法拉进来精确的原文片段却没进候选。我再举个例子之前做设备维修知识库文档里全是型号编码像“S7-1200”这种词向量检索经常把S7-1200和S7-1500混在一起因为它们语义太接近了。而用户的问题是“S7-1200的CPU日志怎么导”模型返回一堆S7-1500相关的内容看似相关实际全错。纯向量检索解决不了长尾精确匹配尤其是产品型号、工单号、报错码这类字符串要解决只能把稀疏检索加回来。3.2 混合召回怎么做权重怎么调混合召回就是用BM25为代表的稀疏检索配合向量检索一起找候选。BM25看的是词频和文档长度能精确匹配“S7-1200”这类关键词向量检索看语义能召回“怎么导出CPU日志”这种换了说法的表达。两者互补性非常强我用下来的效果是单独向量检索Hit Rate可能只有60%到70%加了BM25之后普遍能到80%以上。工程上怎么落地如果用的是Elasticsearch或OpenSearch可以直接配好hybrid query把BM25得分和vector得分做加权求和用Qdrant、Milvus这类向量库可以配合BM25插件或者单独上一个ES做精排。之前用LangChain的EnsembleRetriever最省事把BM25Retriever和VectorStoreRetriever拼在一起通过weights参数分配权重。from langchain.retrievers import EnsembleRetriever from langchain_community.retrievers import BM25Retriever from langchain.vectorstores import FAISS bm25_retriever BM25Retriever.from_documents(documents, k50) vector_retriever FAISS.from_documents(documents, embedding).as_retriever( search_kwargs{k: 50} ) ensemble_retriever EnsembleRetriever( retrievers[bm25_retriever, vector_retriever], weights[0.4, 0.6], )权重我一般从0.6/0.4向量/BM25开始调纯文档型业务把向量权重调高代码、配置、日志这类精确内容BM25权重反而要高些。调参别靠感觉最好准备一个几百条真实问题的评估集在评估集上跑不同权重看Hit Rate和MRR的变化选最高分组合。3.3 用Hit Rate和MRR判断召回好不好线上RAG问答效果差很多团队第一反应是改Prompt结果改完发现没变化。问题常常在检索引擎本身。为了判断召回好不好我建议指标只用两个Hit Rate和MRR。Hit Rate是所有测试问题里能召回相关文档块的比例。比如100个问题有80个问题能在Top-5里看到正确答案Hit Rate就是80%。这个指标直观反映“该找的内容找没找回来”。MRR稍微复杂一点是算第一个正确答案排在第几位每个问题取1/排名然后平均。假设某个问题正确答案排在第一位得1分排在第二位得0.5分排得越靠后分越低。MRR衡量的是“排序质量”它和你后续重排能不能发挥作用强相关。举个例子。A方案Hit Rate很高但MRR很低说明正确答案总在很靠后的位置如果重排能力不强这些正确答案根本到不了LLM手里回答该错还是错B方案Hit Rate不如A但MRR高说明只要命中了基本排在前两位这种场景用重排救起来效果会更快。所以召回优化阶段两个指标都要看缺一个都可能走偏。4. 重排最后一公里能救回不少准确率4.1 从bi-encoder到cross-encoder为什么重排有效向量召回阶段用的是bi-encoderquery和文档块分别编码成向量最后只在向量空间里算个相似度速度快但缺乏深层的交互。重排阶段用的通常是cross-encoder模型把query和文档块拼在一起共同编码能捕捉到它们之间更细的语义交互。简单说bi-encoder快但糙cross-encoder慢但准。我在项目里用的比较多的是bge-reranker系列小模型用base追求效果就上large。跑起来之后效果提升是肉眼可见的一段query“无法启动设备”向量召回可能把“设备启动失败的处理步骤”排到很后面cross-encoder会因为在“启动”和“失败”之间建立更细的关联把这个块排到前面。上线重排后最终答案的准确率提升通常在5到10个点远超你花同样时间调Prompt的收益。4.2 重排的工程取舍速度与准确率怎么平衡cross-encoder准是准但慢也是真慢。我之前在一台没有GPU的服务器上跑bge-reranker-large对一个Top-50候选池重排一次要2到3秒这个延迟加在问答链路里显然不可接受。所以重排必须分层设计。我的做法是第一阶段先用轻量策略把候选池从50压缩到10比如混合召回已经能排得比较好的Top-10直接用RRF排序结果第二阶段才对最终的10到20个候选做cross-encoder重排只取前5个喂给LLM。如果没有GPU建议换小模型比如bge-reranker-base或者FlashRank实测在延迟敏感场景下性价比更高。还有一种玩法是缓存相同query的检索和重排结果缓存一定时间把热门问题压到个位数毫秒日常很多重复问题就直接命中缓存了。这里给一个简单的耗时参考。同样在CPU环境下Top-50候选全部做cross-encoder重排可能要2秒以上但先压缩到Top-20再重排耗时可以控制在500毫秒左右。做决策时不要只看离线效果还要看线上P95延迟否则系统上线后会被用户不断投诉“太慢”。4.3 一个完整可复用的Pipeline混合召回 RRF 重排聊完单独环节给一个完整可落地的流程做参考先用BM25和向量分别从索引里各取Top-N比如各50得到两个候选集。用RRFReciprocal Rank Fusion把两边的候选合并排序。RRF的核心思路是同一个文档在多个检索结果里排名都靠前融合分就越高。公式为score(d) sum(1 / (k rank_i(d)))k常见取60。这一步比直接加权求分更稳因为不用反复调权重。从RRF结果里取前20作为精排候选交给cross-encoder重排。重排后取前5按得分排序塞进Prompt。这个流程跑下来比单纯做加权混合检索再直接进LLM效果明显稳定。现在主流的LangChain、LlamaIndex也都支持类似组件比如EnsembleRetriever和各类Rerank模块。需要留意的只有一点整个链路会多一些计算开销最终要用延迟监控说话不能让“多环节”变成“慢查询”。我见过有的团队为了炫技把链路搭得很长最后发现大部分时间都花在内部调用上真实收益反而不大。def rrf_score(doc_id, ranks, k60): score 0 for rank in ranks[doc_id]: score 1 / (k rank) return score把RRF和重排放在一起用最大的好处是重排模型不必处理太多低质量候选它只需要在一批“已经相当靠谱”的候选中做最后筛选效果自然更稳定。5. 常见问题与调优实录5.1 召回率高但答案不对先查数据清洗有段时间我很困惑Hit Rate到85%了用户还是觉得问答结果不靠谱。后来一条条看上下文才发现召回是对的但块里有大量模板信息——“本文档由系统自动生成”“版本号V1.0.3”这些文本占了半个块真正有用的内容被挤到末尾模型生成的答案自然被稀释。所以数据清洗这一步别省把页眉页脚、固定模板、水印、乱码、无关链接都处理掉再做分块和embedding。清洗前后同样参数跑下来Hit Rate可能只多3到5个点但问答质量提升是质的。我一般会先跑一遍文档统计脚本看每个文档前几行和后几行是不是重复模板如果是直接做正则删除。对于PDF文档还要检查OCR是否引入了乱码或换行错乱这些噪声不清理分块边界会被严重干扰。很多团队觉得清洗数据不是RAG的事结果把大量时间耗在后续调参上实际上大部分“玄学问题”都出在数据没洗干净。5.2 问答响应越来越慢重排往往是元凶RAG变慢链路每个环节都可能是瓶颈。我把排查顺序固定下来先看LLM生成时间再看重排时间再看向量检索和索引构建。大多数情况下你会发现问题不在LLM而在重排。如果重排占整条链路一半以上的时间果断降级把候选池从50减到20或换成更小的rerank模型。另一个容易被忽略的点是embedding生成。如果整个索引库非常大每次查询时使用一些实时计算逻辑也可能拖慢链路。不过大多数RAG项目的响应瓶颈最终都落在“候选集太大重排太慢”这个组合上。建议在监控面板里把每个阶段的耗时都打点不然只能靠猜。5.3 从62%到91%一套知识库调优的完整过程最后放一个真实案例。某次给一个内部运维知识库做RAG初始状态Hit Rate只有62%MRR大概0.4用户反馈“答案经常文不对题”。我梳理出来三个核心问题第一文档统一按512 token切块表格和代码全都被截断第二只用了向量检索S7-1200这类型号匹配全靠缘分第三没有重排Top-5里经常混进低相关内容。针对性地改了三步步骤调整内容效果分块改成“Markdown二级标题优先切分表格和代码块单独保留”重叠10%跨块信息被切断的问题得到改善召回换混合召回BM25和向量权重先用0.5/0.5Hit Rate明显上升重排加cross-encoder base版候选池Top-50压缩到Top-20再精排到Top-5MRR显著提升调整之后同一批评估集上Hit Rate升到91%MRR升到0.78。整体链路延迟从原来的3.2秒降到2.4秒多花在重排上的时间被候选集压缩抵消了。这个过程里最值钱的思路是先解决数据进索引之前的问题再动检索策略最后才考虑拿模型做重排。顺序反了会很反复。5.4 一些可以照抄的参数经验平时被问到最多的就是“你用的参数到底是多少”。我把通用起点整理成一张表但记得这只是起点不是标准答案参数建议起点说明chunk_size512信息密度高的文档用256到512长文用768到1024chunk_overlap64约为块大小的10%到20%混合召回权重0.6向量 / 0.4 BM25精确类内容可以反过来召回Top-K50混合检索各取50再压缩重排候选数20压缩到20后做cross-encoder重排最终喂给LLM的块数5超过5块内容容易稀释答案反而发散这些参数不是拍脑袋定的都是从评估集上一个一个试出来的。你手里的业务数据不一样参数一定会有变化但起点和排查思路可以复用。6. 最后说点个人体会这几年做RAG我最大的体会是大模型本身不是效果瓶颈数据管道才是。你在Prompt上纠结半天不如回头看看分块是否合理、召回是否混了路、重排是否筛掉了噪声。这篇文章里列的6条结论没有一条是凭空想出来的都是业务问题和真实评估集一条条喂出来的。如果现在的RAG效果不太行建议先从指标和评估集开始把Hit Rate和MRR拉起来再决定要不要花钱升级模型或重排服务。如果让我给一句最朴素的建议RAG落地的第一步不是选模型而是建一套能反映真实业务的评估集然后把分块、召回、重排当成一个整体系统来调。这一步走稳了后面的优化才有方向。