构建更可靠的RAG系统：检索优化的四大核心杠杆

大多数在生产环境中表现失望的RAG（检索增强生成）系统，问题并不出在生成环节，而是栽在检索上：模型基于错误的上下文给出了貌似流畅的答案，或者干脆没有任何上下文可依。做一个能跑的demo只需要一个下午，但要让系统在真实查询、真实文档和真实流量下稳定工作，则需要在流程的每个阶段进行刻意的工程设计。

这篇文章围绕决定RAG系统成败的四个关键杠杆展开：检索前后的处理策略、文档分块方式、嵌入模型与向量库的调优，以及如何衡量这一切是否真正奏效。它们构成一个闭环——评估会告诉你接下来该修复哪一个环节。

一、检索前后的处理与校验策略

用户的查询往往简短、模糊，而且表达方式与能够回答它的文档截然不同。检索前的处理工作在触及索引之前就弥合了这道鸿沟，而检索后的校验则能在糟糕的上下文抵达模型之前将其拦截。

检索之前

查询改写是第一道工序：用LLM把一个含糊的口语化问题转化为独立、适合检索的表达。在对话场景中，这还意味着借助历史记录解析诸如"那第二个呢？"这类指代。

查询扩展与多查询通过生成多个同义改写版本，分别检索再合并结果，当用户和文档使用不同词汇时能显著提升召回率。**HyDE（假设文档嵌入）**则换了个思路——先让模型写出一个看似合理的答案，再嵌入这个答案而非问题本身，因为答案在嵌入空间中往往比问题更靠近真实文档。

此外还有查询分解（将"比较A和B计划的定价与限制"拆成子查询）、路由（把查询分发到特定索引、SQL数据库、网络搜索，或对模型能直接回答的问题跳过检索）以及元数据过滤（从查询中提取日期、产品、语言等约束作为筛选条件）。跳过不必要的检索既能降低延迟，也能避免干扰模型。

HyDE（Hypothetical Document Embeddings） 背后的直觉值得展开说明。在嵌入空间中，短小的问句（如"什么是量子纠缠？"）与长篇的知识性段落在向量表示上天然存在分布差异——前者缺乏领域词汇和语境信息，导致余弦相似度偏低。HyDE的做法是先让LLM凭空生成一段"假设性答案"，这段文字在词汇密度和文体风格上与语料库中的真实文档更为接近，从而让嵌入落在更有利的检索区域。即便生成的答案在事实上有所偏差，其嵌入向量所处的语义邻域往往仍能命中正确的真实文档。这一方法的代价是每次检索多一次LLM调用，因此适合对延迟不敏感但召回率要求较高的场景。

检索之后

**重排序（Reranking）**通常是单位投入下质量提升最大的手段：先检索一个较宽裕的候选集（比如30到50条），再用交叉编码器或重排模型将查询和每段文本一起打分重估。

相关性校验则引入一个轻量级评分器判断检索到的段落是否真的切题，若不相关就改写查询重试或切换数据源——这正是CRAG等纠正式方法的核心思路。配合上下文压缩（将段落裁剪到真正关键的句子）和生成后的接地校验（要求每条论断都有检索文本支撑并附引用，否则宁可返回"我不知道"），整个链路的可信度大幅提升。

需要强调的是，每一步都会增加延迟和成本，因此应当针对实测到的失败案例逐个添加，而非默认全部堆上。

交叉编码器（Cross-Encoder） 与用于初步检索的双编码器（Bi-Encoder）在架构上有本质区别。双编码器分别对查询和文档独立编码再算相似度，速度快但精度受限；交叉编码器将查询和候选段落拼接后一同输入模型，允许注意力机制跨两段文本进行细粒度交互，相关性判断更准确，但因此无法预先离线计算文档向量，只能在检索时实时打分。这使得交叉编码器只适合对已缩小的候选集（通常20–50条）重新排序，而非扫描全量索引。常见的开源重排模型包括 Cohere Rerank、BGE-Reranker 和 ms-marco 系列，可在毫秒级延迟内完成一个批次的打分。

二、分块策略的管理

分块决定了检索器眼中"一个知识单元"长什么样。块太大，相关句子会淹没在噪声里并稀释嵌入；块太小，又会丢失让内容可理解的上下文。不存在普适的最佳尺寸，目标是让分块方式匹配内容的实际结构和查询方式。

常见策略包括：固定大小（按N个token切分，适合快速基线）、递归分块（依次按段落、句子、词切分，是通用散文的稳妥默认选择）、结构感知（按标题、章节、代码块、表格边界切分，适合文档和法律文本）、语义分块（在相邻句子嵌入相似度下降处开启新块）、父子分块（嵌入小块但返回更大的父章节）以及句子窗口（嵌入单句，返回命中处周围的邻句）。

实操建议

从简单做起：递归切分约300到800个token、10%到15%的重叠是合理的基线，之后用评估集而非直觉来调优。切记尊重结构——绝不要把表格、代码块或编号步骤拦腰截断，并让标题始终附着在其下方文本上。

一个容易被忽视却极为关键的技巧是为分块补充上下文：嵌入前在每个块前拼接文档标题和章节路径，或用LLM生成一段简短摘要说明该块在文档中的位置（即所谓的"上下文检索"）。一个写着"它增长了12%"的块，若不知道"它"指什么就毫无价值。此外还应存储丰富的元数据、专门处理非文本内容（表格转为保留行列的文本格式，图片做OCR或配字幕），并为分块方案做版本管理——每次修改分块逻辑都必须重新嵌入。

三、向量库与嵌入的优化

即便分块完美，检索质量的上限仍受制于嵌入能否在你的领域内捕捉语义，以及索引能否在你的规模下找到最近邻。

嵌入选择

按数据选模型，而非看榜单：公开基准只是起点，务必用自己的查询和文档测试两三个候选模型，因为法律、医疗、代码、多语言等领域词汇会改变排名。同时要权衡维度与成本——高维向量通常更细腻但增加存储、内存和搜索延迟，支持截断（Matryoshka式）嵌入的模型可以在质量损失不大的前提下缩减向量。

还需注意使用正确的输入格式（某些模型对查询和文档要求不同前缀）、考虑微调（有标注的查询-段落配对能显著提升专业领域检索，无数据时可用合成查询引导训练），以及保持归一化一致（距离度量须与模型训练方式匹配）。

向量库与索引调优

按规模选索引：小集合用精确（flat）搜索即可，大集合则用HNSW、IVF等近似最近邻索引，以少量召回换取大幅加速，并针对自己数据上的召回目标调优ef_search、M等参数。当内存成为瓶颈时可以量化（标量或乘积量化能大幅压缩索引，召回损失通常很小）。

混合检索值得优先采用：将稠密向量搜索与BM25关键词搜索结合，前者处理语义和改写，后者处理精确术语、产品代码、人名和罕见行话，用倒数排名融合（RRF）或加权分数合并后再重排序。此外还要高效过滤（为过滤字段建索引，并弄清向量库是先过滤还是后过滤）、规划数据新鲜度（更新、删除、换模型重嵌入的传播机制，用别名或版本化索引实现无停机切换），并关注运维侧指标——查询延迟分位、索引构建时间、内存占用和单次查询成本。再准确的方案若太慢太贵也无法上线。

倒数排名融合（Reciprocal Rank Fusion，RRF） 是合并多路检索结果时最常用的无参数方法。其核心公式为：对每个文档，将它在各路排名列表中的倒数排名（加一个平滑常数 k，通常取60）求和作为最终得分。这种方式对排名位置而非原始相似度分数进行操作，因此天然兼容量纲不同的多路信号——稠密向量的余弦分数与BM25的TF-IDF分数无需对齐到同一尺度。实践中RRF在多数任务上表现稳健，不需要针对特定数据集调权重，是混合检索的低成本起点；若需进一步提升，可在RRF之上叠加重排序模型，或学习各路信号的融合权重。

四、评估RAG性能

无法衡量就无法改进。对RAG而言，必须分别衡量两件事：检索有没有找到正确的材料，生成有没有用好它。把两者混为一谈会让故障根本无从诊断。

评估应覆盖四个层面：检索层（是否取回了含答案的段落，用Recall@k、Precision@k、MRR、nDCG等）、生成层（答案是否正确且基于上下文，用忠实度、答案相关性、答案正确性）、上下文利用（是否只检索了必要内容，用上下文精度和召回）以及系统层（是否可用于生产，看延迟p50/p95、单次查询成本、拒答率）。

构建黄金数据集

从50到200个真实问题起步，每个问题配上能回答它的源段落，理想情况下再加一个参考答案。尽量从真实用户日志中提取问题，覆盖简单查找、多跳推理、模糊查询，以及语料中根本没有答案的问题——好的系统应当坦承"我不知道"。从文档合成问题是快速扩充数据集的方式，但务必让人工抽样复核。

多跳推理（Multi-hop Reasoning） 查询是黄金数据集中不可缺少的一类难例。此类问题的答案无法从单一段落直接得出，而需要跨越两个或多个文档片段进行链式推断，例如"负责该项目的工程师在哪所大学取得学位？"——首先要找到负责人姓名，再去另一段落查询其教育背景。标准的单轮检索对这类查询成功率很低，暴露出系统在多步推理、迭代检索或上下文拼接上的能力边界。构建数据集时若完全回避此类问题，评估得分会虚高，系统上线后遭遇真实用户的复合查询时则会出现明显性能断崖。

谨慎评估生成质量

LLM-as-judge是大规模评判忠实度和相关性的实用方法：给评判者清晰的评分标准、问题、上下文和答案，要求给出分数和简短理由。但必须校准评判者——在样本上对比人工标注，警惕它偏爱更长或更自信的答案，换评判模型时重新核验。RAGAS、TruLens、DeepEval、LangSmith等框架已实现了这些指标，但在信任某个数字之前要先理解它到底衡量了什么。

把它跑成一个闭环

改动任何东西前先在黄金集上建立基线；每次只改一个变量（分块大小、嵌入模型、重排器）再重跑；按查询类型拆解结果，因为平均值会掩盖某个崩坏得很严重的类别；逐条手动阅读失败案例，将其归类为检索遗漏、排序问题、上下文问题还是生成问题，再去修复真正该负责的环节；在CI中用评估集卡住发布以拦截回归；并在生产环境持续监控，把难例反哺回黄金集。

整合落地的合理顺序

一个明智的操作顺序是：先建评估集，再用递归分块加一个优秀的嵌入模型拿到简单基线，接着加入混合搜索和重排序（它们往往早期就能见效），然后仅在失败分析指向之处才去调优分块和添加查询端技术。每一次改动都应以可测量的提升赢得自己的位置。

RAG的质量来自整条流水线的协同运转，而真正做得好的团队，是那些能够逐个查询地判断出究竟是哪一环节辜负了用户的团队。