RAG 落地做了几个月我最大的感受是demo 跑通和业务能跑是两个物种。尤其是当你搭建了一个看似完善的知识库问答系统领导随手问一个具体数字模型却一本正经地给出了一个原文里根本不存在的答案——那一刻你才知道问题往往不在生成模型而在检索侧根本没有把证据捞对。我们团队在三个真实项目里反复迭代了分块、召回、重排的策略有制度问答、产品手册问答也有代码库问答。这篇文章就是把落地过程中沉淀下来的 6 个实战结论写出来。不聊太虚的原理只讲改了什么、效果涨了多少、在什么条件下会失效。如果你正在做企业内部知识库、长文档问答或者本地 RAG 方案这里面的经验大概率能帮你少走几轮弯路。1. 项目背景先定位瓶颈再谈分块、召回、重排1.1 初版系统的失败方式我们接到的项目分三类制度文本问答、产品手册 QA、代码知识问答。第一版流程很标准解析文档为纯文本按固定字符大小分块向量化后放入向量库问问题时取 top 5 相似块直接塞给大模型生成回答。表面上看链路完整实际上问题处处都在。举三个当初印象很深的例子制度问答里用户问“年假和病假累计规则”两个条款分别在不同章节固定分块把一个章节从中间切开召回时只拿回了其中一半。模型看到半截条款只能靠“脑补”把答案补完整补出来的自然是编的。产品手册里大量表格固定分块算法把表格从中间断开检索出来的块只有半张表数字对不上几乎是必然的。代码问答里接口文档和实现代码混杂固定分块把函数签名和函数实现拆成了两块。用户问某个接口参数怎么传召回结果里根本没有函数签名。归结起来就是同一个病根信息单元被切碎了。大模型没见过完整的信息单元那么无论生成能力多强都难以还原真实答案。1.2 用命中率把“效果差”变成可优化指标那段时间我们反复调整模型、改提示词模板投入大提升小。直到有一天我们决定不看生成结果回头专门检验检索链路本身才有了转机。具体做法很简单挑选 50 个真实业务问题对每个问题人工标注出标准答案所在的 chunk 编号固定检索参数看 top 5 结果里是否包含了目标 chunk统计命中比例。这个指标就是常说的 hit rate。我们第一版系统的 hit rate 只有 52%。换句话说用户问 10 个问题有一半的情况下正确答案所在的段落根本不在这 5 个候选里。生成模型在剩下一半的候选里翻来翻去能答对才怪。后来我们把 hit rate 从 52% 提升到 82%最终问答质量肉眼可见地上了一个台阶。所以第一个建议是做 RAG 优化不要先盯着模型答案先建立一套带人工标注的检索评估集把问题量化。1.3 三个环节的链条顺序分块、召回、重排这三个环节不是孤立的而是漏斗关系。分块决定信息的边界召回决定候选集合的覆盖度重排决定最终进入生成上下文的段落。我的理解是分块是一条链路的天花板。如果分块已经把一个表格从中间切断那么后面召回和重排做得再好也很难拼回一个完整的表。只有分块把语义单元完整地保留下来召回和重排的优化才有意义。所以接下来的顺序就是先分块再召回最后重排。2. 分块这一步决定了后面所有环节的天花板2.1 固定大小分块为什么容易挂早期的做法非常简单就是按字符数或 token 数硬切比如每块 500 个字符相邻之间重叠 100 个字符。这种做法看着客观其实忽略了语义边界。法律文本里的例外条款、表格里的一行、代码里的一个函数都可能横跨好几个固定分块。最典型的场景是检索回来的块末尾是半句话——大模型看到半句话会下意识地补齐你在生成的文字层面很难察觉但答案已经偏了。合理分块思路其实是在三个约束条件里找平衡语义边界完整尽量保持段落、条款、函数不被切开长度不能太长否则向量表征会被局部关键词稀释长度也不能太小否则上下文不足模型无法理解概念。单纯按字符去切本质上是在赌“语义边界恰好落在某个字符位置”这个概率并不高。2.2 重叠设多少合适10%-20% 的经验值固定分块方案里有一个 overlap 参数用来缓解边界截断问题。我们一开始用 chunk_size500、overlap100相当于 20% 的重叠效果中等。后来调成 overlap50也就是 10% 重叠准确率和索引体积之间取得了更好的平衡。重叠的作用是给边界两侧保留线索。比如一个操作步骤的最后一个关键词正好落在块 A 的结尾、块 B 的开头如果两块完全不重叠那关键词的上下文就被拆散了。有 10%-20% 的重叠能明显减少这种边界损失。但重叠并不是越多越好。我见过有人把 overlap 调到 30%、40%结果索引体积膨胀明显而且向量库里出现了大量高度相似的重复块。召回的时候top 5 里可能出现 3 块内容几乎一样等于候选集合的有效覆盖度反而降低了后续重排的去重压力也更大。2.3 结构化分块跟着文档骨骼走真正做到生产环境后我强烈建议放弃“纯字符切分”改用“结构感知切分”。几乎所有真实文档都有骨架Markdown 的标题层级、PDF 里的目录和章节标题、表格的行列结构、代码里的函数和类这些本身就是天然的语义边界。我们调整后的策略是这样的Heading 型文档先用标题层级做递归切分把每个二级标题下的内容作为一个大块如果这个块还是太长再按段落做二级切分而不是硬性按字符数。表格型文档按行切成“表头 数据行”的记录块或者把每个表格块连同表头一起打包保证检索回来的表格是完整的。代码型文档按函数、类、import 依赖切块函数体尽量带上前面的注释和调用关系这样检索一个接口用法时能看到完整签名。举一个代码问答场景的例子之前我们用固定 800 字符的 chunk一个 50 行的函数被拆成 3 块检索经常只拿到中间那段缺了函数签名。换成按函数边界切块后每个函数作为一个独立 chunk接口类问题的回答准确率瞬间改观——因为模型看到了完整的“输入-输出-实现”而不是拼凑出来的片段。3. 召回纯向量只是 demo 级别的基线3.1 为什么纯向量搜索会漏掉“显而易见的答案”很多 RAG 项目的第一步是“向量化 相似度检索”我一开始也这么干但实测下来纯向量检索在不少场景里就是个花架子。向量检索擅长语义相似比如“怎么请假”和“请假流程”这类说法不同但意思相近的表达。但它在精确匹配上很弱数字、错误码、版本号、商品型号、人名、缩写这些信息在向量空间里的距离表达并不一定比关键词更准。最典型的还有否定句。文档里写“不支持远程调用”你问“支持远程调用吗”向量语义上两句话高度相关模型很容易把否定当成肯定来理解。而关键词检索至少会把这个高度相关的文本块原本地返回让重排阶段再做精细判断。在我们的代码问答和工程手册场景里纯向量检索的 hit rate 比混合检索平均低 12-18 个百分点。这说明单靠语义向量很难覆盖真实的业务查询。3.2 BM25 向量混合融合方式可以很简单既然纯向量不够我们的做法是引入稀疏检索也就是传统的 BM25。它不依赖语义空间直接按关键词出现情况打分对精确名词和编号类问题极其有效。流程就是两条路并行向量检索取 top NBM25 取 top N然后把两个结果做融合。我用的融合算法是 RFF 变体也就是倒数排名融合。核心逻辑是同时被两种方案命中的文档融合得分天然高于只被一种方案命中的文档。def rff_fusion(sparse_results, dense_results, k60): scores {} for rank, doc_id in enumerate(sparse_results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) for rank, doc_id in enumerate(dense_results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) return dict(sorted(scores.items(), keylambda x: x[1], reverseTrue))这个实现简单到不能再简单不需要训练不需要调复杂的权重。实测下来混合检索的 hit rate 比纯向量高 10-15 个百分点代价只是多维护一个倒排索引、多一次查询工程成本可以接受。3.3 元数据过滤投入产出比最高的召回优化这是我最想强调的一点也是最容易被忽略的一点。很多 RAG 项目把文档一股脑塞进一个 collection没有字段区分结果用户问“2023 年的版本号”系统把 2020 年的旧手册也召回来了而且因为语义相近排名还挺高。我们在制度问答和产品手册场景里给每个 chunk 打了元数据标签包括文档类型、日期、版本、章节路径、权限级别然后查询时先做过滤器再检索。实际操作中有两类做法在向量库层面用 metadata filter比如只查 doc_type policy 且 year 2023在应用层面解析 query抽取年份、部门、产品线转成过滤条件。我们初期吃了不少亏因为过滤条件写得不够仔细比如忘了限制版本导致旧版本文档被召回hit rate 直接掉了 15%。后来把过滤条件做细干扰项少了约 30%业务满意度明显提升。元数据过滤往往比换一个 embedding 模型带来的提升更大而且代价极低。4. 重排把 top 20 变成 top 3 的决定性一环4.1 双编码器和交叉编码器的区别向量召回用的 embedding 模型是双编码器query 和 document 分别过一遍模型各自映射成一个向量再算余弦相似度。这种架构快但代价是 query 和 document 之间没有交互很多细微的相关性判断会被几何距离吞噬。重排阶段用的是交叉编码器把 query 和 document 拼在一起进入同一个 Transformer最后输出一个相关分。计算量比双编码器大得多但相关性判断的准确性也高得多。用生活化类比来说双编码器像相亲平台只看双方资料卡打分交叉编码器是一对一深聊之后再做判断。后者费时间但判断更靠谱。4.2 实测重排流程与效果我们最终跑的流程是混合检索产出 top 20 候选喂给交叉编码器逐一打分再取 top 3 进入生成上下文。候选不到 20 个的时候重排延迟在 200 毫秒级别可以接受。在合同问答数据集上我们有意对比过几个配置配置top 3 命中率纯向量直接取 top 30.66混合检索后直接取 top 30.74混合检索 重排再取 top 30.83这组数据很直观重排带来的提升约 9 个百分点相对提升接近 12%。这个数字可能因场景而异但在我们做过的几个项目里重排几乎一定是 hit rate 提升最大的单点杠杆。当然重排有一个前提候选集合里得真的有正确答案。如果 top 20 里根本没有目标 chunk重排再怎么打分也救不回来所以重排永远是在前面环节之上的增强。4.3 重排实施中的几个坑候选数别设太小。我们一开始重排只取 top 3后来改成混合检索 top 20 再重排到 top 3效果差异非常大。候选数太小会让正确结果根本没机会进入后置环节。记得先做去重。如果同一来源的多个 chunk 内容近似会同时出现在候选里重排分数可能分散在近似内容上。我们在进入重排前做了去重同一个章节最多保留 2 条候选最终进入生成上下文的文本多样性更好。重排 score 不等于事实正确性。交叉编码器输出的是相关性不是“这句话是否真实”。如果模型生成了事实错误还是要靠文档内容校验不能指望重排自动纠正。延迟与效果的平衡要看场景。在线问答对延迟敏感候选数量可以从 top 30 降回 top 20离线或者半离线场景则可以放宽到 top 50让重排慢慢挑。5. 六个实战结论先记住结论再动手这篇文章标题叫“6 个实战结论”这里集中列一下方便你直接对照。结论一句话对应环节1固定大小分块必须是最后的选择优先结构化分块分块2重叠设 10%-20%不要贪多分块3混合检索是基线纯向量只配做原型召回4元数据过滤往往比换 embedding 模型更有效召回5重排是 hit rate 提升最大的单点杠杆重排6hit rate 和用户满意度不完全相等需要贴近业务评估集评估逐条展开说一下。第一结构化分块降低的是整个工程链路的复杂度。模型不用再靠猜检索也能更精准重排时也不用面对碎片化的候选内容。你只是跑 demo怎么切都行一旦要上生产先把分块切对再优化其他环节。第二重叠不是越大越好。在 1 万个 chunk 的基础量上把重叠从 10% 调到 30%索引规模可能膨胀上千条重排阶段还会反复看到近似内容。我们最终把重叠控制在块长的 10%-20%收益稳定且资源开销可控。第三纯向量检索的定位应该是快速验证。正式业务环境里强烈建议加一路 BM25 或者别的稀疏检索。RFF 融合实现简单又能同时兼顾语义相关和字面匹配性价比很高。第四元数据过滤是很多人忽略的优化手段。把 query 中抽出的部门、时间、文档类型作为预筛条件等于告诉检索器“别去无关空间里瞎找”。这个操作对 hit rate 的提升很直接而且不会给系统增加推理负担。第五重排模型直接使用开源的 cross encoder 就行完全不需要自己训练。类似 bge-reranker 这类的模型可以直接接入配合混合检索输出 top 20 再重排到 top 3是比较通用且效果稳定的方案。第六最重要的一点真实业务场景里hit rate 提升也不代表用户满意度一定提升。你需要按业务分段建立各自的评估集定义 hit rate、MRR 等指标的期望值持续回放对比。否则你只是在优化一个“测试集分数”很可能偏离用户真正的问题分布。6. 本地 RAG 工具链与工程化的细节6.1 基于 Ollama 的本地部署经验有些数据不允许出内网我们就在内网搭过基于 Ollama 的本地 RAG 方案。整体流程不算复杂拉取模型、启动服务、加载 embedding 模型、建立索引、起一个轻量 API 处理查询。但有两个细节值得记录。第一embedding 模型要选对。多语言和领域词典的覆盖度直接决定了中文环境下命名实体和数字相关的检索效果。第二Ollama 默认的上下文窗口不一定够用需要在模型文件里显式设置 num_ctx否则输入超长会被静默截断。类似这样的配置片段可以用FROM llama3 PARAMETER num_ctx 8192 PARAMETER temperature 0.2真实项目中本地 RAG 最容易出问题的不是模型能力而是配置碎片化。模型版本、模型文件路径、向量库版本这些都需要强制记录方便复现。我们曾因为一台机器上 Ollama 缓存了旧版模型导致本地结果和其他环境对不上排查了很久。6.2 框架的边界LangChain 和 LangChain4j工具框架方面LangChain 和 LangChain4j 都只是工具链不是方案本身。LangChain4j 在 Java 生态里用得比较多封装了向量存储、retriever 等接口方便集成。但我个人的实际感受是框架默认的 RetrievalQA 把分块策略和调用细节藏在内部一旦出了问题排查链路会很痛苦。所以用框架时我会建议把核心链路自己掌握分块代码自己写检索交互可以走框架的 API但日志一定从自己的流程里打印出来而不是依赖框架内部的隐式行为。6.3 可观测性把每次请求的证据链记录下来这是我认为 RAG 工程化中最容易被低估的事情。模型答错了最可怕的不是答错本身而是你不知道它到底看了哪段文本做出这个判断。我们后来给系统加了完整日志每条请求记录四样东西query、top 20 候选 ID、重排后的 top 3 列表、最终生成结果。有了这份日志用户反馈某个问题答错时几分钟内就能定位是检索没命中还是生成阶段把内容改写了。有一段时间我们被一连串“简单问题答错”困扰日志一查才发现元数据过滤条件被 query 解析到了错误的部门也就是过滤条件本身错了而不是检索模型不行。这类的坑没有日志几乎没法排。6.4 GraphRAG 与本体 RAG 什么时候值得尝试GraphRAG 和本体 RAG 最近讨论很多。从一个落地执行者的角度看如果只是单文档问答知识图谱和本体带来的提升有限但维护成本明显更高。文档里本来就是一个章节一个主题线性 RAG 足够覆盖。真正适合 GraphRAG 的场景是跨多文档、需要回答实体之间的关系、或者做全库层面的总结。这时传统 RAG 确实容易“只见树木不见森林”GraphRAG 的全局能力能补上这块短板。但代价很现实建图耗时、查询链路复杂、知识更新时要定期同步图谱。我们在一个中型文档库上试过一次把所有实体都展开建图结果后续文档一变同步图的时间比问答收益还多。Ontology RAG 更偏向一个领域建模方案预先定义概念和关系让召回结果不偏离领域框架。如果知识点之间是靠关系连接而不是靠相似度连接确实值得试一下。我的建议是默认基线继续用“结构化分块 混合检索 重排”只有当你在测试集上明确证明 GraphRAG 或本体方案带来额外收益时才引入不要为了追热词而增加复杂度。最后分享一个小习惯当评估集命中率卡住不再提升时不要盲目调参先回头翻那 10% 的失败样本。绝大多数情况你会在分块结果里发现证据被切没了或者某个元数据过滤条件挡错了路。把失败样本倒回分块阶段看一眼往往比重新测十组参数更有用。这也是我把分块放在全文最前面讲的原因——它虽然不起眼却是整个 RAG 系统真正的起点。
RAG 落地做了几个月我最大的感受是demo 跑通和业务能跑是两个物种。尤其是当你搭建了一个看似完善的知识库问答系统领导随手问一个具体数字模型却一本正经地给出了一个原文里根本不存在的答案——那一刻你才知道问题往往不在生成模型而在检索侧根本没有把证据捞对。我们团队在三个真实项目里反复迭代了分块、召回、重排的策略有制度问答、产品手册问答也有代码库问答。这篇文章就是把落地过程中沉淀下来的 6 个实战结论写出来。不聊太虚的原理只讲改了什么、效果涨了多少、在什么条件下会失效。如果你正在做企业内部知识库、长文档问答或者本地 RAG 方案这里面的经验大概率能帮你少走几轮弯路。1. 项目背景先定位瓶颈再谈分块、召回、重排1.1 初版系统的失败方式我们接到的项目分三类制度文本问答、产品手册 QA、代码知识问答。第一版流程很标准解析文档为纯文本按固定字符大小分块向量化后放入向量库问问题时取 top 5 相似块直接塞给大模型生成回答。表面上看链路完整实际上问题处处都在。举三个当初印象很深的例子制度问答里用户问“年假和病假累计规则”两个条款分别在不同章节固定分块把一个章节从中间切开召回时只拿回了其中一半。模型看到半截条款只能靠“脑补”把答案补完整补出来的自然是编的。产品手册里大量表格固定分块算法把表格从中间断开检索出来的块只有半张表数字对不上几乎是必然的。代码问答里接口文档和实现代码混杂固定分块把函数签名和函数实现拆成了两块。用户问某个接口参数怎么传召回结果里根本没有函数签名。归结起来就是同一个病根信息单元被切碎了。大模型没见过完整的信息单元那么无论生成能力多强都难以还原真实答案。1.2 用命中率把“效果差”变成可优化指标那段时间我们反复调整模型、改提示词模板投入大提升小。直到有一天我们决定不看生成结果回头专门检验检索链路本身才有了转机。具体做法很简单挑选 50 个真实业务问题对每个问题人工标注出标准答案所在的 chunk 编号固定检索参数看 top 5 结果里是否包含了目标 chunk统计命中比例。这个指标就是常说的 hit rate。我们第一版系统的 hit rate 只有 52%。换句话说用户问 10 个问题有一半的情况下正确答案所在的段落根本不在这 5 个候选里。生成模型在剩下一半的候选里翻来翻去能答对才怪。后来我们把 hit rate 从 52% 提升到 82%最终问答质量肉眼可见地上了一个台阶。所以第一个建议是做 RAG 优化不要先盯着模型答案先建立一套带人工标注的检索评估集把问题量化。1.3 三个环节的链条顺序分块、召回、重排这三个环节不是孤立的而是漏斗关系。分块决定信息的边界召回决定候选集合的覆盖度重排决定最终进入生成上下文的段落。我的理解是分块是一条链路的天花板。如果分块已经把一个表格从中间切断那么后面召回和重排做得再好也很难拼回一个完整的表。只有分块把语义单元完整地保留下来召回和重排的优化才有意义。所以接下来的顺序就是先分块再召回最后重排。2. 分块这一步决定了后面所有环节的天花板2.1 固定大小分块为什么容易挂早期的做法非常简单就是按字符数或 token 数硬切比如每块 500 个字符相邻之间重叠 100 个字符。这种做法看着客观其实忽略了语义边界。法律文本里的例外条款、表格里的一行、代码里的一个函数都可能横跨好几个固定分块。最典型的场景是检索回来的块末尾是半句话——大模型看到半句话会下意识地补齐你在生成的文字层面很难察觉但答案已经偏了。合理分块思路其实是在三个约束条件里找平衡语义边界完整尽量保持段落、条款、函数不被切开长度不能太长否则向量表征会被局部关键词稀释长度也不能太小否则上下文不足模型无法理解概念。单纯按字符去切本质上是在赌“语义边界恰好落在某个字符位置”这个概率并不高。2.2 重叠设多少合适10%-20% 的经验值固定分块方案里有一个 overlap 参数用来缓解边界截断问题。我们一开始用 chunk_size500、overlap100相当于 20% 的重叠效果中等。后来调成 overlap50也就是 10% 重叠准确率和索引体积之间取得了更好的平衡。重叠的作用是给边界两侧保留线索。比如一个操作步骤的最后一个关键词正好落在块 A 的结尾、块 B 的开头如果两块完全不重叠那关键词的上下文就被拆散了。有 10%-20% 的重叠能明显减少这种边界损失。但重叠并不是越多越好。我见过有人把 overlap 调到 30%、40%结果索引体积膨胀明显而且向量库里出现了大量高度相似的重复块。召回的时候top 5 里可能出现 3 块内容几乎一样等于候选集合的有效覆盖度反而降低了后续重排的去重压力也更大。2.3 结构化分块跟着文档骨骼走真正做到生产环境后我强烈建议放弃“纯字符切分”改用“结构感知切分”。几乎所有真实文档都有骨架Markdown 的标题层级、PDF 里的目录和章节标题、表格的行列结构、代码里的函数和类这些本身就是天然的语义边界。我们调整后的策略是这样的Heading 型文档先用标题层级做递归切分把每个二级标题下的内容作为一个大块如果这个块还是太长再按段落做二级切分而不是硬性按字符数。表格型文档按行切成“表头 数据行”的记录块或者把每个表格块连同表头一起打包保证检索回来的表格是完整的。代码型文档按函数、类、import 依赖切块函数体尽量带上前面的注释和调用关系这样检索一个接口用法时能看到完整签名。举一个代码问答场景的例子之前我们用固定 800 字符的 chunk一个 50 行的函数被拆成 3 块检索经常只拿到中间那段缺了函数签名。换成按函数边界切块后每个函数作为一个独立 chunk接口类问题的回答准确率瞬间改观——因为模型看到了完整的“输入-输出-实现”而不是拼凑出来的片段。3. 召回纯向量只是 demo 级别的基线3.1 为什么纯向量搜索会漏掉“显而易见的答案”很多 RAG 项目的第一步是“向量化 相似度检索”我一开始也这么干但实测下来纯向量检索在不少场景里就是个花架子。向量检索擅长语义相似比如“怎么请假”和“请假流程”这类说法不同但意思相近的表达。但它在精确匹配上很弱数字、错误码、版本号、商品型号、人名、缩写这些信息在向量空间里的距离表达并不一定比关键词更准。最典型的还有否定句。文档里写“不支持远程调用”你问“支持远程调用吗”向量语义上两句话高度相关模型很容易把否定当成肯定来理解。而关键词检索至少会把这个高度相关的文本块原本地返回让重排阶段再做精细判断。在我们的代码问答和工程手册场景里纯向量检索的 hit rate 比混合检索平均低 12-18 个百分点。这说明单靠语义向量很难覆盖真实的业务查询。3.2 BM25 向量混合融合方式可以很简单既然纯向量不够我们的做法是引入稀疏检索也就是传统的 BM25。它不依赖语义空间直接按关键词出现情况打分对精确名词和编号类问题极其有效。流程就是两条路并行向量检索取 top NBM25 取 top N然后把两个结果做融合。我用的融合算法是 RFF 变体也就是倒数排名融合。核心逻辑是同时被两种方案命中的文档融合得分天然高于只被一种方案命中的文档。def rff_fusion(sparse_results, dense_results, k60): scores {} for rank, doc_id in enumerate(sparse_results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) for rank, doc_id in enumerate(dense_results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) return dict(sorted(scores.items(), keylambda x: x[1], reverseTrue))这个实现简单到不能再简单不需要训练不需要调复杂的权重。实测下来混合检索的 hit rate 比纯向量高 10-15 个百分点代价只是多维护一个倒排索引、多一次查询工程成本可以接受。3.3 元数据过滤投入产出比最高的召回优化这是我最想强调的一点也是最容易被忽略的一点。很多 RAG 项目把文档一股脑塞进一个 collection没有字段区分结果用户问“2023 年的版本号”系统把 2020 年的旧手册也召回来了而且因为语义相近排名还挺高。我们在制度问答和产品手册场景里给每个 chunk 打了元数据标签包括文档类型、日期、版本、章节路径、权限级别然后查询时先做过滤器再检索。实际操作中有两类做法在向量库层面用 metadata filter比如只查 doc_type policy 且 year 2023在应用层面解析 query抽取年份、部门、产品线转成过滤条件。我们初期吃了不少亏因为过滤条件写得不够仔细比如忘了限制版本导致旧版本文档被召回hit rate 直接掉了 15%。后来把过滤条件做细干扰项少了约 30%业务满意度明显提升。元数据过滤往往比换一个 embedding 模型带来的提升更大而且代价极低。4. 重排把 top 20 变成 top 3 的决定性一环4.1 双编码器和交叉编码器的区别向量召回用的 embedding 模型是双编码器query 和 document 分别过一遍模型各自映射成一个向量再算余弦相似度。这种架构快但代价是 query 和 document 之间没有交互很多细微的相关性判断会被几何距离吞噬。重排阶段用的是交叉编码器把 query 和 document 拼在一起进入同一个 Transformer最后输出一个相关分。计算量比双编码器大得多但相关性判断的准确性也高得多。用生活化类比来说双编码器像相亲平台只看双方资料卡打分交叉编码器是一对一深聊之后再做判断。后者费时间但判断更靠谱。4.2 实测重排流程与效果我们最终跑的流程是混合检索产出 top 20 候选喂给交叉编码器逐一打分再取 top 3 进入生成上下文。候选不到 20 个的时候重排延迟在 200 毫秒级别可以接受。在合同问答数据集上我们有意对比过几个配置配置top 3 命中率纯向量直接取 top 30.66混合检索后直接取 top 30.74混合检索 重排再取 top 30.83这组数据很直观重排带来的提升约 9 个百分点相对提升接近 12%。这个数字可能因场景而异但在我们做过的几个项目里重排几乎一定是 hit rate 提升最大的单点杠杆。当然重排有一个前提候选集合里得真的有正确答案。如果 top 20 里根本没有目标 chunk重排再怎么打分也救不回来所以重排永远是在前面环节之上的增强。4.3 重排实施中的几个坑候选数别设太小。我们一开始重排只取 top 3后来改成混合检索 top 20 再重排到 top 3效果差异非常大。候选数太小会让正确结果根本没机会进入后置环节。记得先做去重。如果同一来源的多个 chunk 内容近似会同时出现在候选里重排分数可能分散在近似内容上。我们在进入重排前做了去重同一个章节最多保留 2 条候选最终进入生成上下文的文本多样性更好。重排 score 不等于事实正确性。交叉编码器输出的是相关性不是“这句话是否真实”。如果模型生成了事实错误还是要靠文档内容校验不能指望重排自动纠正。延迟与效果的平衡要看场景。在线问答对延迟敏感候选数量可以从 top 30 降回 top 20离线或者半离线场景则可以放宽到 top 50让重排慢慢挑。5. 六个实战结论先记住结论再动手这篇文章标题叫“6 个实战结论”这里集中列一下方便你直接对照。结论一句话对应环节1固定大小分块必须是最后的选择优先结构化分块分块2重叠设 10%-20%不要贪多分块3混合检索是基线纯向量只配做原型召回4元数据过滤往往比换 embedding 模型更有效召回5重排是 hit rate 提升最大的单点杠杆重排6hit rate 和用户满意度不完全相等需要贴近业务评估集评估逐条展开说一下。第一结构化分块降低的是整个工程链路的复杂度。模型不用再靠猜检索也能更精准重排时也不用面对碎片化的候选内容。你只是跑 demo怎么切都行一旦要上生产先把分块切对再优化其他环节。第二重叠不是越大越好。在 1 万个 chunk 的基础量上把重叠从 10% 调到 30%索引规模可能膨胀上千条重排阶段还会反复看到近似内容。我们最终把重叠控制在块长的 10%-20%收益稳定且资源开销可控。第三纯向量检索的定位应该是快速验证。正式业务环境里强烈建议加一路 BM25 或者别的稀疏检索。RFF 融合实现简单又能同时兼顾语义相关和字面匹配性价比很高。第四元数据过滤是很多人忽略的优化手段。把 query 中抽出的部门、时间、文档类型作为预筛条件等于告诉检索器“别去无关空间里瞎找”。这个操作对 hit rate 的提升很直接而且不会给系统增加推理负担。第五重排模型直接使用开源的 cross encoder 就行完全不需要自己训练。类似 bge-reranker 这类的模型可以直接接入配合混合检索输出 top 20 再重排到 top 3是比较通用且效果稳定的方案。第六最重要的一点真实业务场景里hit rate 提升也不代表用户满意度一定提升。你需要按业务分段建立各自的评估集定义 hit rate、MRR 等指标的期望值持续回放对比。否则你只是在优化一个“测试集分数”很可能偏离用户真正的问题分布。6. 本地 RAG 工具链与工程化的细节6.1 基于 Ollama 的本地部署经验有些数据不允许出内网我们就在内网搭过基于 Ollama 的本地 RAG 方案。整体流程不算复杂拉取模型、启动服务、加载 embedding 模型、建立索引、起一个轻量 API 处理查询。但有两个细节值得记录。第一embedding 模型要选对。多语言和领域词典的覆盖度直接决定了中文环境下命名实体和数字相关的检索效果。第二Ollama 默认的上下文窗口不一定够用需要在模型文件里显式设置 num_ctx否则输入超长会被静默截断。类似这样的配置片段可以用FROM llama3 PARAMETER num_ctx 8192 PARAMETER temperature 0.2真实项目中本地 RAG 最容易出问题的不是模型能力而是配置碎片化。模型版本、模型文件路径、向量库版本这些都需要强制记录方便复现。我们曾因为一台机器上 Ollama 缓存了旧版模型导致本地结果和其他环境对不上排查了很久。6.2 框架的边界LangChain 和 LangChain4j工具框架方面LangChain 和 LangChain4j 都只是工具链不是方案本身。LangChain4j 在 Java 生态里用得比较多封装了向量存储、retriever 等接口方便集成。但我个人的实际感受是框架默认的 RetrievalQA 把分块策略和调用细节藏在内部一旦出了问题排查链路会很痛苦。所以用框架时我会建议把核心链路自己掌握分块代码自己写检索交互可以走框架的 API但日志一定从自己的流程里打印出来而不是依赖框架内部的隐式行为。6.3 可观测性把每次请求的证据链记录下来这是我认为 RAG 工程化中最容易被低估的事情。模型答错了最可怕的不是答错本身而是你不知道它到底看了哪段文本做出这个判断。我们后来给系统加了完整日志每条请求记录四样东西query、top 20 候选 ID、重排后的 top 3 列表、最终生成结果。有了这份日志用户反馈某个问题答错时几分钟内就能定位是检索没命中还是生成阶段把内容改写了。有一段时间我们被一连串“简单问题答错”困扰日志一查才发现元数据过滤条件被 query 解析到了错误的部门也就是过滤条件本身错了而不是检索模型不行。这类的坑没有日志几乎没法排。6.4 GraphRAG 与本体 RAG 什么时候值得尝试GraphRAG 和本体 RAG 最近讨论很多。从一个落地执行者的角度看如果只是单文档问答知识图谱和本体带来的提升有限但维护成本明显更高。文档里本来就是一个章节一个主题线性 RAG 足够覆盖。真正适合 GraphRAG 的场景是跨多文档、需要回答实体之间的关系、或者做全库层面的总结。这时传统 RAG 确实容易“只见树木不见森林”GraphRAG 的全局能力能补上这块短板。但代价很现实建图耗时、查询链路复杂、知识更新时要定期同步图谱。我们在一个中型文档库上试过一次把所有实体都展开建图结果后续文档一变同步图的时间比问答收益还多。Ontology RAG 更偏向一个领域建模方案预先定义概念和关系让召回结果不偏离领域框架。如果知识点之间是靠关系连接而不是靠相似度连接确实值得试一下。我的建议是默认基线继续用“结构化分块 混合检索 重排”只有当你在测试集上明确证明 GraphRAG 或本体方案带来额外收益时才引入不要为了追热词而增加复杂度。最后分享一个小习惯当评估集命中率卡住不再提升时不要盲目调参先回头翻那 10% 的失败样本。绝大多数情况你会在分块结果里发现证据被切没了或者某个元数据过滤条件挡错了路。把失败样本倒回分块阶段看一眼往往比重新测十组参数更有用。这也是我把分块放在全文最前面讲的原因——它虽然不起眼却是整个 RAG 系统真正的起点。
