过去半年我几乎每周都会被问到同一个问题“RAG 是不是已经烂大街了”说这话的人多半已经能用一个开源框架半小时跑通一条知识库问答流水线。但当我追问“你的切分规则是按文档结构定的还是拍脑袋定的”“top-k 召回之后有没有算过 hit rate”“跨文档的关系问题能不能答上来”时往往就没人接话了。RAG 确实被讲烂了但烂大街的只是那条流水线——装载文档、切片、向量化、召回、拼 prompt、生成答案。真正把项目做出差距的从来不是这条流水线本身而是流水线周围那六处细节。这篇文章我就围绕这六个分水岭展开把我实践里踩过的坑和验证过有效的方法一次性讲透。1. 先撕掉“烂大街”的标签标准流水线长什么样差距藏在哪里1.1 那条“半小时跑通”的流水线任何一个入门教程都会教你搭这么一套东西把知识文档扔进加载器按固定长度切成 chunk调 embedding 接口转成向量存入向量数据库用户提问时把问题也转成向量做相似度检索取回 top-k 个片段塞进 prompt让大模型基于这些片段生成回答。这套流程在 LangChain、LlamaIndex 或 Dify 这类平台上都能快速搭起来demo 效果也像模像样。问题恰恰出在这里demo 好跑不等于项目能落地。我见过太多团队把这条流水线跑通后就以为 RAG 这件事已经“做完了”剩下的只是多传点文档、换个更好看的界面。等到生产环境一上用户问出来的问题五花八门召回的内容驴唇不对马嘴系统给出的答案要么是幻觉要么是复读机式的“抱歉我无法回答”这时候才意识到问题根本不在流水线本身。1.2 真正拉开差距的三个层次如果把 RAG 项目拆开看差距其实分成三个层次第一个层次是“有没有”。有没有把文档转换成可检索的向量有没有能回答问题的应用这个层次确实烂大街了。第二个层次是“准不准”。问题进来能不能命中正确的知识片段多个相关片段互相冲突时能不能分辨跨文档、多跳类的问题能不能组织出完整答案这个层次已经刷掉一大批项目。第三个层次是“稳不稳”。知识更新后索引能不能平滑重建系统能不能回答“不知道”证据可不可追溯评测指标是不是可量化的这个层次决定了项目能否持续运营。本文要讲的六处分水岭正好覆盖第二个和第三个层次。你可以在同一个框架、同一组模型上通过调整这六处细节把系统从“能聊”提升到“能交付”。下面逐个拆开讲。2. 分水岭一文档解析与切片决定知识库“吃进去的是不是饲料”2.1 非结构化文档的“坑”远比想象的多很多人以为 RAG 的第一步是切分其实第一步是解析。你丢给知识库的原始文档远不是干净的纯文本。最常见的三类坑第一PDF 扫描件。这类文档本质是图片直接文本抽取什么都拿不到必须先过 OCR。而且扫描件还分清晰和模糊清晰的有版式问题模糊的可能连 OCR 都会大面积出错。第二复杂版式。公文、产品手册、论文这类文档里天然存在标题层级、表格、代码块、图注、页眉页脚。如果统一按“读出来的纯文本”处理表格结构就丢了标题层级就扁了页眉页脚还会混进正文污染语义。我处理过一份产品维修手册正文里每一页都有“机密文件禁止外传”的页眉结果检索出来的片段经常是这句废话加正文回答质量明显被拉低。第三图文混排。热词里很多人问“RAG 知识库能存储图片吗”这个问题背后其实是一个认知误区你不一定需要“存图片”你需要的是把图片里的信息变成可检索的语义。产品结构图上的标注、流程图里的分支关系、架构图里的模块连线如果只用纯文本抽取这些信息全部丢失。你问“这个模块的上游依赖是谁”系统会回答不出来因为文档里根本没有一段话直接描述这个关系只有图上有。2.2 切分策略按结构切而不是按字数切解析做完之后才是切分。不少工程团队在切分上只有一个思路定一个 chunk_size再定一个 overlap完事。这种做法的问题在于语义被拦腰截断。一个完整的表格被切成两半一个代码块被硬生生拆到两个 chunk 里一条逻辑完整的条款被拆得七零八落。检索的时候不管召回哪一半给到大模型的都是残缺信息。我现在的做法是“结构感知切分”先按文档的标题层级把文档切成一级块再在一级块内部按段落、表格、代码块、列表这些元素继续细分。表格尽量整块保留——如果表格太大可以按行分组但保持表头代码块整体保留段落只要在语义完整的地方断开。按 Markdown 或 HTML 结构信息来切分比纯按字符数切分要稳得多。这里有一个经验参数可以给刚入门的朋友参考通用文档的 chunk 长度 512~1024 字符比较合适重叠区 10%~15%。但参数只是起点不是标准答案。你真正要观察的是类目繁多、主题频繁切换的文档切片要偏小主题连续、逻辑层层递进的文档切片可以偏大。调整的唯一依据是后续检索阶段的 hit rate这一点我会在下一章展开。2.3 本地文本拆解工具的选型思路很多用户搜“本地 RAG 文本拆解工具”背后的核心诉求是不想把企业内部文档传到外部 API 去解析。这个诉求非常合理——企业知识库里的很多内容都涉及数据安全边界。本地环境下我常用的组合是用 PaddleOCR 这类开源 OCR 引擎处理扫描件用版面分析模型把 PDF 转成带结构的文本流再做规则化的结构切分。Python 生态里也有很多 PDF 解析库可以辅助但要注意没有任何一个库能通吃所有版式最终一定要加一层“自己写的小规则”来修特殊版式比如去掉页眉页脚、把多栏文本按阅读顺序重排。如果项目阶段连本地解析都不想做也可以退一步先用现成工具把文档批量转成 Markdown 或结构化文本再喂给 RAG。这样虽然是半自动但能把“解析质量”这个变量先控制住。等你确认了检索效果还行再回头优化解析链路也不迟。3. 分水岭二混合召回与重排hit rate 是被“做”出来的3.1 先搞清楚 hit rate 到底在测什么“hit rate”是 RAG 项目里最容易被提起也最容易被误用的指标。简单说它是“在测试问题集合中正确答案被包含在系统召回的 top-k 片段里的比例”。它测的是检索器的上限不是整个系统的效果。如果你的 hit rate 只有 50%那无论后面生成模型多强天花板也只有 50%。为什么要单独盯着这个指标看因为 RAG 的绝大多数翻车都发生在召回阶段而不是生成阶段。用户问了一个问题系统压根没有把含答案的片段找回来大模型就算有再强的生成能力也只能靠猜。所以我做项目的第一件事永远是先搭一套测试问题集跑一遍召回把 hit rate 打到一个基准值再谈其他优化。3.2 为什么纯向量的召回会漏只靠 embedding 做语义检索看起来很美实际一测就露馅。典型场景有三类第一专有名词与型号。用户查“保单 HC-2024-088 的兑付状态”embedding 会优先匹配语义接近的“兑付政策”“理赔流程”而不会精准锁定那串编号因为编号本身没有太多语义。第二代码变量和文档里的英文缩写语义向量经常把含义相近但写法不同的词混在一起。第三否定和条件表达。“不包含 A 的情况”和“包含 A 的情况”语义上可能很近但答案恰恰相反。要解决这类问题就得回到信息检索的老办法BM25 这类基于词法匹配的稀疏检索。它不看语义只看字面命中。混合检索hybrid search的本质就是把向量检索的“语义联想”和 BM25 的“字面精确”合并起来。常见的融合方式是 RRFReciprocal Rank Fusion对两种召回结果按排名倒数的加权求和最终得到一个融合后的排序。3.3 混合召回和重排的落地组合我现在的标准方案是向量检索召回 top-100BM25 召回 top-50RRF 融合成 top-50再接入一个重排rerank模型精排到 top-5 或者 top-8 喂给大模型。重排这一步对 hit rate 的贡献非常可观因为向量召回靠的是“粗粒度相似”重排模型会把 query 和 chunk 做深度交叉编码对语义匹配度的判断精细得多。举个例子说明差距同样是“我的订单超过 7 天没发货怎么办”向量召回可能把“平台发货规则”“物流查询方式”都捞出来重排之后能稳稳地把“延迟发货赔偿与投诉入口”这一类真正命中用户意图的文本顶到最前面。用哪种 embedding、哪种重排模型这里不展开品牌推荐但有一个原则值得记住本地小模型 合理调参往往比盲目上最新大模型更值得投入时间。先把检索数据流跑通再逐步放大模型复杂度效果曲线会更可控。4. 分水岭三查询改写与多跳路由从“一问一检”到 agentic RAG4.1 原始提问不能直接拿去检索基础 RAG 有一个大前提用户的问题能直接匹配到检索片段。但真实用户根本不按你的知识库组织方式来提问。他们会说“它什么时候截止”“那个方案后来怎么样了”“合同里对违约是怎么规定的”——这些提问里带着指代词和上下文依赖原样丢给检索器召回质量一定差。所以查询理解这一步不能省。最轻量的做法是加一个查询改写模块在进检索之前先用大模型把用户的原始问题改写成一个或多个适合检索的独立查询。比如“它什么时候截止”结合对话上下文改写为“2024 年度供应商资质审核材料提交截止时间”。这个改写只需要一次轻量 LLM 调用却常常能把 hit rate 拉高十个百分点以上。4.2 多跳问题的处理链路比指代消解更复杂的是多跳问题。用户问“一季度营收下滑的原因里涉及哪些核心供应商”这个问题至少需要两次检索第一次查出“营收下滑的原因是供应链中断”第二次再根据“供应链中断”去查“涉及哪些供应商”。一次检索根本搞不定因为答案散布在多个文档甚至多个数据库中。多跳问题目前有两种主流处理路径。一种是拆解分步检索先用大模型把问题分解成子问题列表按顺序检索每次用前一步的结果去引导下一步的查询最后汇总成答案。另一种是更轻量的做法只拆成子问题并行检索再把各子结果合并。前者更接近链式推理准确率高后者延迟低适合追问关系不太深的场景。我在实践中会用“两跳为界”的原则问题涉及两跳及以内的用分步检索就能解决超过两跳的先优化文档结构和知识组织而不是硬上复杂链路。因为跳数越多错误累积越严重最后一步拿到错误的上文生成阶段再强也救不回来。4.3 从查询改写平滑过渡到 agentic RAG热词里反复出现“agentic RAG”很多人觉得它是另一套东西。我的理解是agentic RAG 就是把前面这些“查询改写、意图判断、多跳拆解、路由选择”从静态流程变成模型按需动态决策的过程。它不再是“用户一问系统就检索一次”而是大模型作为智能体自己判断“这个问题需不需要检索”“要不要先查知识库再查数据库”“当前证据够不够不够就再查一次”。实现路径上我建议先从静态的查询改写模块做起跑通之后再接入工具调用框架逐步 agent 化。不要一上来就直接上全自动 agent原因很简单全自动意味着大模型在每一个环节都有判断权而判断失误是不可见的、难调试的。先用可控流程把各环节的基准值测出来再逐步放开自由度这样出了问题还能定位。5. 分水岭四用知识图谱和本体对抗“知识割裂”5.1 纯向量检索为什么解决不了“知识割裂”纯向量检索的本质是“找相似片段”它天然只能处理点状的、局部的知识。可很多业务问题本质是关系型的某某产品线的供应商和另一个产品线的供应商有没有重叠某个风险事件影响了哪些客户知识库里这些信息分散在不同的文档切片里没有任何一个 chunk 能直接回答这类问题向量检索自然就失效了。这就是“知识割裂”的来源。文档被切成 chunkchunk 之间唯一的关联是语义相似度但你不知道 A 文档里的“甲客户”和 B 文档里的“客户甲”是不是同一个人也不知道 C 文档里提到的风险事件和 D 文档里那家供应商是不是同一个链条上的节点。5.2 图RAG的构建思路与适用边界图 RAG 的思路是在文档之上抽取出实体和关系构建一张知识图谱回答问题时可以在图谱上做路径查询也可以先对图做社区检测生成不同层级的社区摘要再结合这些摘要回答全局性问题。这类方法最适合的场景是“多实体、多关系、需要整体盘点”的问题比如“公司所有业务线中哪些共享了同一家物流商”“这两个案件之间有没有共同被告”。我实测下来图谱的质量高度依赖实体抽取模型的准确率而抽取模型对领域术语的适应性直接决定了项目成败。如果只是把通用模型接上去硬抽图里会有大量错误节点和错误边答案反而被污染。所以我的建议是分阶梯落地第一步先用带业务属性的元数据增强文档切片比如给每个 chunk 打上“产品线”“文档类型”“适用区域”的标签第二步在标签还不够用时引入命名实体识别和关系抽取构建轻量图谱第三步业务复杂性确实高、关系约束确实严格再考虑上本体。5.3 本体RAG让实体关系先有“骨架”本体ontology和图谱的区别可以理解为“先画骨架还是后建骨架”。本体要求在构建之前就想清楚这个领域有哪些实体类型、哪些关系类型、哪些属性约束。比如医疗领域疾病、药物、症状、禁忌是实体类型“与……关联”“不能与……同服”是关系类型生产供应链里供应商、部件、产线、风险事件是实体关系则必须受控在“供货给”“存在于”“引发”这些明确类型里。有了本体约束抽取出来的关系就不再是自由文本而是规范化的三元组查询的时候也能做更准确的推演。热词里有人问“wiki 和 RAG”怎么结合其实很多百科类系统走的就是本体思路用词条自带的分类树、别名、引用关系来约束知识组织再在之上做检索。本体越明确系统对关系型问题的回答就越稳但构建成本也越高。价值不对等的场景不要轻易全量铺开挑核心业务域做试点就够。6. 分水岭五答案生成、引用溯源与事实核查让输出扛得住追问6.1 答案生成的约束方式检索做得再好生成阶段不约束系统照样会产出“看起来很有道理但完全是编的”答案。这一环节prompt 里要写清楚这样几件事只允许基于提供的参考片段回答如果参考片段不足以回答问题必须明确说“无法回答”不要补充外部知识也不要对片段做超出原文范围的引申。一个小技巧是把“无法回答”做成显式出口。很多失败案例是模型在片段不足时硬找补生成一段模糊的废话。你只要在 prompt 里把“不知道就直说”这条权重拉高并且把“宁可说不知道也不编造”写进系统约束行为就会变好。输出的答案越短、越结构化幻觉越少这也是我习惯用“条目式回答”的原因。6.2 引用溯源让每个结论都能找到出处RAG 系统的可信度很大程度取决于能不能溯源。用户得到一个答案如果系统能同时给出“这句话出自《XX手册》第 X 章”信任感完全不一样。技术实现上分三步检索阶段保留每个 chunk 的来源元数据文档名、标题路径、页码生成阶段要求模型在输出关键结论时带上对应的片段编号后处理阶段把这些编号映射成可见的引用标记在界面展示时挂到原文位置。最容易被忽略的一条引用必须在生成之前就确定。你在 prompt 里给模型的就是带编号的片段模型回答时引用编号才会准确如果你让模型生成完再事后补引用大概率会补错或补到不存在的来源上。我见过不少团队在这个细节上翻车这里单独提一句。6.3 幻觉治理与证据冲突处理就算有引用也不能完全放羊。生成之后可以加一道“事实核查”的校验把答案里的核心断言和参考片段做一次语义一致性比对一致性分数低于阈值就拒绝这条输出或触发重新检索。也可以用“双模型互评”的方式让另一个模型判断回答是否忠实于片段。这些方法会增加延迟和成本但对高风险场景法律、医疗、金融非常值得。证据冲突是另一个大坑。同一个问题命中了多个片段但片段内容互相矛盾——比如一个文档说“审核周期 5 个工作日”另一个说“审核周期 10 个工作日”。处理原则是先让模型判断冲突存在再根据文档版本、发布日期、优先级规则决定采信哪边。完全不建优先级规则的系统碰到这类冲突就是在赌运气。7. 分水岭六评测体系给RAG项目装上仪表盘7.1 RAG评测该测哪些指标回到“烂大街”这个话题为什么那么多人觉得 RAG 没用因为他们连“效果差在哪里”都不知道。系统答错了是召回没召回对还是召回了但生成没用好没有指标拆解就只能凭感觉调参越调越玄。我是这样拆指标的检索阶段看 hit rate、MRR、nDCG生成阶段看忠实度、相关性和答案完整性。忠实度衡量答案有没有歪曲或超出参考片段相关性衡量答案有没有绕开问题完整性衡量关键信息有没有遗漏。有条件的话还可以用 RAGAS 这类框架批量评测但注意框架给的分数只能作参考严格场景下还是要人工抽检兜底。7.2 评测集怎么建才不跑偏评测集是整个评测体系的根基。我从真实用户日志里抽样提问再人工标注出每个问题对应的正确答案片段和标准答案按难度分层简单问题单点事实、中等问题需要理解上下文、复杂问题多跳、对比、跨文档。每一层都要有足够的样本量至少 50~100 条起步太少一跑就全是方差。这里有一个容易踩的坑评测问题不要只从文档里翻着出。文档编写者觉得“这一段写好找”真实用户根本不会那么问。从真实日志里抽样哪怕带着口语化、指代和错别字也比自编问题更有代表性。错别字这块也是检索器水平的真实考验不要为了好看把评测集清洗得干干净净。7.3 用bad case驱动迭代闭环评测跑起来之后最重要的一步是逐条看 bad case而不是只盯平均分。我每次优化前会先捞二十条失败样本统计失败发生在哪一段解析丢信息切分断语义召回 top-k 不含答案重排没把正确答案顶上去还是生成阶段没遵循约束。定位到具体环节再决定动哪一块。这个闭环比任何“高级算法”都重要。很多时候你以为要做 agent 化改造结果 bad case 一看80% 的问题是单个文档的切分把表格拆碎了。先把那一个文档的解析规则补好hit rate 和回答质量一起涨。评测体系的价值就是让这类问题能被看见而不是整个系统黑盒一般撞运气。最后分享一点个人体会我做过的大小 RAG 项目里凡是最终效果翻车的十有八九不是栽在模型不够强而是栽在解析、切分、评测这些“流水线之外”的细节上。RAG 不是没有技术含量它的技术含量全藏在流水线的缝隙里。你不用急着追每个新概念——先把自己项目里的这六处打磨到位效果就已经能跑赢大多数“半小时跑通”的同行了。 
长河君 · 2026/10/3 11:02:48 · 阅读 1.2k RAG不烂大街：六个决定项目成败的分水岭细节
过去半年我几乎每周都会被问到同一个问题“RAG 是不是已经烂大街了”说这话的人多半已经能用一个开源框架半小时跑通一条知识库问答流水线。但当我追问“你的切分规则是按文档结构定的还是拍脑袋定的”“top-k 召回之后有没有算过 hit rate”“跨文档的关系问题能不能答上来”时往往就没人接话了。RAG 确实被讲烂了但烂大街的只是那条流水线——装载文档、切片、向量化、召回、拼 prompt、生成答案。真正把项目做出差距的从来不是这条流水线本身而是流水线周围那六处细节。这篇文章我就围绕这六个分水岭展开把我实践里踩过的坑和验证过有效的方法一次性讲透。1. 先撕掉“烂大街”的标签标准流水线长什么样差距藏在哪里1.1 那条“半小时跑通”的流水线任何一个入门教程都会教你搭这么一套东西把知识文档扔进加载器按固定长度切成 chunk调 embedding 接口转成向量存入向量数据库用户提问时把问题也转成向量做相似度检索取回 top-k 个片段塞进 prompt让大模型基于这些片段生成回答。这套流程在 LangChain、LlamaIndex 或 Dify 这类平台上都能快速搭起来demo 效果也像模像样。问题恰恰出在这里demo 好跑不等于项目能落地。我见过太多团队把这条流水线跑通后就以为 RAG 这件事已经“做完了”剩下的只是多传点文档、换个更好看的界面。等到生产环境一上用户问出来的问题五花八门召回的内容驴唇不对马嘴系统给出的答案要么是幻觉要么是复读机式的“抱歉我无法回答”这时候才意识到问题根本不在流水线本身。1.2 真正拉开差距的三个层次如果把 RAG 项目拆开看差距其实分成三个层次第一个层次是“有没有”。有没有把文档转换成可检索的向量有没有能回答问题的应用这个层次确实烂大街了。第二个层次是“准不准”。问题进来能不能命中正确的知识片段多个相关片段互相冲突时能不能分辨跨文档、多跳类的问题能不能组织出完整答案这个层次已经刷掉一大批项目。第三个层次是“稳不稳”。知识更新后索引能不能平滑重建系统能不能回答“不知道”证据可不可追溯评测指标是不是可量化的这个层次决定了项目能否持续运营。本文要讲的六处分水岭正好覆盖第二个和第三个层次。你可以在同一个框架、同一组模型上通过调整这六处细节把系统从“能聊”提升到“能交付”。下面逐个拆开讲。2. 分水岭一文档解析与切片决定知识库“吃进去的是不是饲料”2.1 非结构化文档的“坑”远比想象的多很多人以为 RAG 的第一步是切分其实第一步是解析。你丢给知识库的原始文档远不是干净的纯文本。最常见的三类坑第一PDF 扫描件。这类文档本质是图片直接文本抽取什么都拿不到必须先过 OCR。而且扫描件还分清晰和模糊清晰的有版式问题模糊的可能连 OCR 都会大面积出错。第二复杂版式。公文、产品手册、论文这类文档里天然存在标题层级、表格、代码块、图注、页眉页脚。如果统一按“读出来的纯文本”处理表格结构就丢了标题层级就扁了页眉页脚还会混进正文污染语义。我处理过一份产品维修手册正文里每一页都有“机密文件禁止外传”的页眉结果检索出来的片段经常是这句废话加正文回答质量明显被拉低。第三图文混排。热词里很多人问“RAG 知识库能存储图片吗”这个问题背后其实是一个认知误区你不一定需要“存图片”你需要的是把图片里的信息变成可检索的语义。产品结构图上的标注、流程图里的分支关系、架构图里的模块连线如果只用纯文本抽取这些信息全部丢失。你问“这个模块的上游依赖是谁”系统会回答不出来因为文档里根本没有一段话直接描述这个关系只有图上有。2.2 切分策略按结构切而不是按字数切解析做完之后才是切分。不少工程团队在切分上只有一个思路定一个 chunk_size再定一个 overlap完事。这种做法的问题在于语义被拦腰截断。一个完整的表格被切成两半一个代码块被硬生生拆到两个 chunk 里一条逻辑完整的条款被拆得七零八落。检索的时候不管召回哪一半给到大模型的都是残缺信息。我现在的做法是“结构感知切分”先按文档的标题层级把文档切成一级块再在一级块内部按段落、表格、代码块、列表这些元素继续细分。表格尽量整块保留——如果表格太大可以按行分组但保持表头代码块整体保留段落只要在语义完整的地方断开。按 Markdown 或 HTML 结构信息来切分比纯按字符数切分要稳得多。这里有一个经验参数可以给刚入门的朋友参考通用文档的 chunk 长度 512~1024 字符比较合适重叠区 10%~15%。但参数只是起点不是标准答案。你真正要观察的是类目繁多、主题频繁切换的文档切片要偏小主题连续、逻辑层层递进的文档切片可以偏大。调整的唯一依据是后续检索阶段的 hit rate这一点我会在下一章展开。2.3 本地文本拆解工具的选型思路很多用户搜“本地 RAG 文本拆解工具”背后的核心诉求是不想把企业内部文档传到外部 API 去解析。这个诉求非常合理——企业知识库里的很多内容都涉及数据安全边界。本地环境下我常用的组合是用 PaddleOCR 这类开源 OCR 引擎处理扫描件用版面分析模型把 PDF 转成带结构的文本流再做规则化的结构切分。Python 生态里也有很多 PDF 解析库可以辅助但要注意没有任何一个库能通吃所有版式最终一定要加一层“自己写的小规则”来修特殊版式比如去掉页眉页脚、把多栏文本按阅读顺序重排。如果项目阶段连本地解析都不想做也可以退一步先用现成工具把文档批量转成 Markdown 或结构化文本再喂给 RAG。这样虽然是半自动但能把“解析质量”这个变量先控制住。等你确认了检索效果还行再回头优化解析链路也不迟。3. 分水岭二混合召回与重排hit rate 是被“做”出来的3.1 先搞清楚 hit rate 到底在测什么“hit rate”是 RAG 项目里最容易被提起也最容易被误用的指标。简单说它是“在测试问题集合中正确答案被包含在系统召回的 top-k 片段里的比例”。它测的是检索器的上限不是整个系统的效果。如果你的 hit rate 只有 50%那无论后面生成模型多强天花板也只有 50%。为什么要单独盯着这个指标看因为 RAG 的绝大多数翻车都发生在召回阶段而不是生成阶段。用户问了一个问题系统压根没有把含答案的片段找回来大模型就算有再强的生成能力也只能靠猜。所以我做项目的第一件事永远是先搭一套测试问题集跑一遍召回把 hit rate 打到一个基准值再谈其他优化。3.2 为什么纯向量的召回会漏只靠 embedding 做语义检索看起来很美实际一测就露馅。典型场景有三类第一专有名词与型号。用户查“保单 HC-2024-088 的兑付状态”embedding 会优先匹配语义接近的“兑付政策”“理赔流程”而不会精准锁定那串编号因为编号本身没有太多语义。第二代码变量和文档里的英文缩写语义向量经常把含义相近但写法不同的词混在一起。第三否定和条件表达。“不包含 A 的情况”和“包含 A 的情况”语义上可能很近但答案恰恰相反。要解决这类问题就得回到信息检索的老办法BM25 这类基于词法匹配的稀疏检索。它不看语义只看字面命中。混合检索hybrid search的本质就是把向量检索的“语义联想”和 BM25 的“字面精确”合并起来。常见的融合方式是 RRFReciprocal Rank Fusion对两种召回结果按排名倒数的加权求和最终得到一个融合后的排序。3.3 混合召回和重排的落地组合我现在的标准方案是向量检索召回 top-100BM25 召回 top-50RRF 融合成 top-50再接入一个重排rerank模型精排到 top-5 或者 top-8 喂给大模型。重排这一步对 hit rate 的贡献非常可观因为向量召回靠的是“粗粒度相似”重排模型会把 query 和 chunk 做深度交叉编码对语义匹配度的判断精细得多。举个例子说明差距同样是“我的订单超过 7 天没发货怎么办”向量召回可能把“平台发货规则”“物流查询方式”都捞出来重排之后能稳稳地把“延迟发货赔偿与投诉入口”这一类真正命中用户意图的文本顶到最前面。用哪种 embedding、哪种重排模型这里不展开品牌推荐但有一个原则值得记住本地小模型 合理调参往往比盲目上最新大模型更值得投入时间。先把检索数据流跑通再逐步放大模型复杂度效果曲线会更可控。4. 分水岭三查询改写与多跳路由从“一问一检”到 agentic RAG4.1 原始提问不能直接拿去检索基础 RAG 有一个大前提用户的问题能直接匹配到检索片段。但真实用户根本不按你的知识库组织方式来提问。他们会说“它什么时候截止”“那个方案后来怎么样了”“合同里对违约是怎么规定的”——这些提问里带着指代词和上下文依赖原样丢给检索器召回质量一定差。所以查询理解这一步不能省。最轻量的做法是加一个查询改写模块在进检索之前先用大模型把用户的原始问题改写成一个或多个适合检索的独立查询。比如“它什么时候截止”结合对话上下文改写为“2024 年度供应商资质审核材料提交截止时间”。这个改写只需要一次轻量 LLM 调用却常常能把 hit rate 拉高十个百分点以上。4.2 多跳问题的处理链路比指代消解更复杂的是多跳问题。用户问“一季度营收下滑的原因里涉及哪些核心供应商”这个问题至少需要两次检索第一次查出“营收下滑的原因是供应链中断”第二次再根据“供应链中断”去查“涉及哪些供应商”。一次检索根本搞不定因为答案散布在多个文档甚至多个数据库中。多跳问题目前有两种主流处理路径。一种是拆解分步检索先用大模型把问题分解成子问题列表按顺序检索每次用前一步的结果去引导下一步的查询最后汇总成答案。另一种是更轻量的做法只拆成子问题并行检索再把各子结果合并。前者更接近链式推理准确率高后者延迟低适合追问关系不太深的场景。我在实践中会用“两跳为界”的原则问题涉及两跳及以内的用分步检索就能解决超过两跳的先优化文档结构和知识组织而不是硬上复杂链路。因为跳数越多错误累积越严重最后一步拿到错误的上文生成阶段再强也救不回来。4.3 从查询改写平滑过渡到 agentic RAG热词里反复出现“agentic RAG”很多人觉得它是另一套东西。我的理解是agentic RAG 就是把前面这些“查询改写、意图判断、多跳拆解、路由选择”从静态流程变成模型按需动态决策的过程。它不再是“用户一问系统就检索一次”而是大模型作为智能体自己判断“这个问题需不需要检索”“要不要先查知识库再查数据库”“当前证据够不够不够就再查一次”。实现路径上我建议先从静态的查询改写模块做起跑通之后再接入工具调用框架逐步 agent 化。不要一上来就直接上全自动 agent原因很简单全自动意味着大模型在每一个环节都有判断权而判断失误是不可见的、难调试的。先用可控流程把各环节的基准值测出来再逐步放开自由度这样出了问题还能定位。5. 分水岭四用知识图谱和本体对抗“知识割裂”5.1 纯向量检索为什么解决不了“知识割裂”纯向量检索的本质是“找相似片段”它天然只能处理点状的、局部的知识。可很多业务问题本质是关系型的某某产品线的供应商和另一个产品线的供应商有没有重叠某个风险事件影响了哪些客户知识库里这些信息分散在不同的文档切片里没有任何一个 chunk 能直接回答这类问题向量检索自然就失效了。这就是“知识割裂”的来源。文档被切成 chunkchunk 之间唯一的关联是语义相似度但你不知道 A 文档里的“甲客户”和 B 文档里的“客户甲”是不是同一个人也不知道 C 文档里提到的风险事件和 D 文档里那家供应商是不是同一个链条上的节点。5.2 图RAG的构建思路与适用边界图 RAG 的思路是在文档之上抽取出实体和关系构建一张知识图谱回答问题时可以在图谱上做路径查询也可以先对图做社区检测生成不同层级的社区摘要再结合这些摘要回答全局性问题。这类方法最适合的场景是“多实体、多关系、需要整体盘点”的问题比如“公司所有业务线中哪些共享了同一家物流商”“这两个案件之间有没有共同被告”。我实测下来图谱的质量高度依赖实体抽取模型的准确率而抽取模型对领域术语的适应性直接决定了项目成败。如果只是把通用模型接上去硬抽图里会有大量错误节点和错误边答案反而被污染。所以我的建议是分阶梯落地第一步先用带业务属性的元数据增强文档切片比如给每个 chunk 打上“产品线”“文档类型”“适用区域”的标签第二步在标签还不够用时引入命名实体识别和关系抽取构建轻量图谱第三步业务复杂性确实高、关系约束确实严格再考虑上本体。5.3 本体RAG让实体关系先有“骨架”本体ontology和图谱的区别可以理解为“先画骨架还是后建骨架”。本体要求在构建之前就想清楚这个领域有哪些实体类型、哪些关系类型、哪些属性约束。比如医疗领域疾病、药物、症状、禁忌是实体类型“与……关联”“不能与……同服”是关系类型生产供应链里供应商、部件、产线、风险事件是实体关系则必须受控在“供货给”“存在于”“引发”这些明确类型里。有了本体约束抽取出来的关系就不再是自由文本而是规范化的三元组查询的时候也能做更准确的推演。热词里有人问“wiki 和 RAG”怎么结合其实很多百科类系统走的就是本体思路用词条自带的分类树、别名、引用关系来约束知识组织再在之上做检索。本体越明确系统对关系型问题的回答就越稳但构建成本也越高。价值不对等的场景不要轻易全量铺开挑核心业务域做试点就够。6. 分水岭五答案生成、引用溯源与事实核查让输出扛得住追问6.1 答案生成的约束方式检索做得再好生成阶段不约束系统照样会产出“看起来很有道理但完全是编的”答案。这一环节prompt 里要写清楚这样几件事只允许基于提供的参考片段回答如果参考片段不足以回答问题必须明确说“无法回答”不要补充外部知识也不要对片段做超出原文范围的引申。一个小技巧是把“无法回答”做成显式出口。很多失败案例是模型在片段不足时硬找补生成一段模糊的废话。你只要在 prompt 里把“不知道就直说”这条权重拉高并且把“宁可说不知道也不编造”写进系统约束行为就会变好。输出的答案越短、越结构化幻觉越少这也是我习惯用“条目式回答”的原因。6.2 引用溯源让每个结论都能找到出处RAG 系统的可信度很大程度取决于能不能溯源。用户得到一个答案如果系统能同时给出“这句话出自《XX手册》第 X 章”信任感完全不一样。技术实现上分三步检索阶段保留每个 chunk 的来源元数据文档名、标题路径、页码生成阶段要求模型在输出关键结论时带上对应的片段编号后处理阶段把这些编号映射成可见的引用标记在界面展示时挂到原文位置。最容易被忽略的一条引用必须在生成之前就确定。你在 prompt 里给模型的就是带编号的片段模型回答时引用编号才会准确如果你让模型生成完再事后补引用大概率会补错或补到不存在的来源上。我见过不少团队在这个细节上翻车这里单独提一句。6.3 幻觉治理与证据冲突处理就算有引用也不能完全放羊。生成之后可以加一道“事实核查”的校验把答案里的核心断言和参考片段做一次语义一致性比对一致性分数低于阈值就拒绝这条输出或触发重新检索。也可以用“双模型互评”的方式让另一个模型判断回答是否忠实于片段。这些方法会增加延迟和成本但对高风险场景法律、医疗、金融非常值得。证据冲突是另一个大坑。同一个问题命中了多个片段但片段内容互相矛盾——比如一个文档说“审核周期 5 个工作日”另一个说“审核周期 10 个工作日”。处理原则是先让模型判断冲突存在再根据文档版本、发布日期、优先级规则决定采信哪边。完全不建优先级规则的系统碰到这类冲突就是在赌运气。7. 分水岭六评测体系给RAG项目装上仪表盘7.1 RAG评测该测哪些指标回到“烂大街”这个话题为什么那么多人觉得 RAG 没用因为他们连“效果差在哪里”都不知道。系统答错了是召回没召回对还是召回了但生成没用好没有指标拆解就只能凭感觉调参越调越玄。我是这样拆指标的检索阶段看 hit rate、MRR、nDCG生成阶段看忠实度、相关性和答案完整性。忠实度衡量答案有没有歪曲或超出参考片段相关性衡量答案有没有绕开问题完整性衡量关键信息有没有遗漏。有条件的话还可以用 RAGAS 这类框架批量评测但注意框架给的分数只能作参考严格场景下还是要人工抽检兜底。7.2 评测集怎么建才不跑偏评测集是整个评测体系的根基。我从真实用户日志里抽样提问再人工标注出每个问题对应的正确答案片段和标准答案按难度分层简单问题单点事实、中等问题需要理解上下文、复杂问题多跳、对比、跨文档。每一层都要有足够的样本量至少 50~100 条起步太少一跑就全是方差。这里有一个容易踩的坑评测问题不要只从文档里翻着出。文档编写者觉得“这一段写好找”真实用户根本不会那么问。从真实日志里抽样哪怕带着口语化、指代和错别字也比自编问题更有代表性。错别字这块也是检索器水平的真实考验不要为了好看把评测集清洗得干干净净。7.3 用bad case驱动迭代闭环评测跑起来之后最重要的一步是逐条看 bad case而不是只盯平均分。我每次优化前会先捞二十条失败样本统计失败发生在哪一段解析丢信息切分断语义召回 top-k 不含答案重排没把正确答案顶上去还是生成阶段没遵循约束。定位到具体环节再决定动哪一块。这个闭环比任何“高级算法”都重要。很多时候你以为要做 agent 化改造结果 bad case 一看80% 的问题是单个文档的切分把表格拆碎了。先把那一个文档的解析规则补好hit rate 和回答质量一起涨。评测体系的价值就是让这类问题能被看见而不是整个系统黑盒一般撞运气。最后分享一点个人体会我做过的大小 RAG 项目里凡是最终效果翻车的十有八九不是栽在模型不够强而是栽在解析、切分、评测这些“流水线之外”的细节上。RAG 不是没有技术含量它的技术含量全藏在流水线的缝隙里。你不用急着追每个新概念——先把自己项目里的这六处打磨到位效果就已经能跑赢大多数“半小时跑通”的同行了。