1. 知识割裂才是第一条分水岭向量检索擅长相似不擅长关系先说个每个 RAG 项目都会撞上的现象你把一份三十页的产品手册切成五十段分别向量化后存库。用户问哪个版本开始支持多仓库部署系统明明有答案却可能召回的是一段完全相关的功能描述甚至碰巧提到版本但完全不搭边的片段。因为向量检索的本质是计算语义相似度它不知道 A 段和 B 段属于同一章节也不知道某一段是结论、另一段是论据更不知道它们之间有没有继承或覆盖关系。这就是知识割裂——所有信息被切碎后变成了一个个语义孤岛。教程里的流水线从来不会告诉你这件事但它恰恰是最容易翻车的地方。1.1 一个最容易被忽略的补救元数据注入在没上复杂图谱之前先把元数据做好收益其实非常大。切分的时候把来源文档、一级章节、二级章节、页码、段落在原文中的序号、文档更新时间这些信息写进 metadata检索的时候允许用户按产品线、按文档版本、按日期范围过滤。我见过不少项目仅仅是加了一个版本过滤Hit Rate 就能涨十个百分点因为用户的很多误召回来自旧文档和新文档打架。这个动作不到半小时能改完但很多人宁可去换 embedding 模型也不愿意看一眼 metadata 设计这属于典型的捡芝麻丢西瓜。1.2 再进一步GraphRAG 与本体Ontology到底在解决什么想要真正解决知识割裂就要从相似度走向结构化语义。这一层社区现在讨论最多的是 GraphRAG 和本体增强的 RAGOntology RAG两个方向但它们解决的问题不太一样别混为一谈。GraphRAG 的做法是先用 LLM 从文档里抽取实体和关系比如多仓库部署是版本 v3.2的功能把抽取结果建成图结构再在图上做社区聚类生成不同粒度的摘要。检索的时候除了向量召回片段还会同时召回关系路径和社区摘要。这样系统就能回答跨片段的问题比如哪些功能是从 v3.2 开始引入的这类问题如果只靠片段向量检索通常很难答全。用图的话功能和版本之间的关系是显式存在的召回路径一旦跟 query 对上准确率和覆盖率都会明显往上走。Ontology RAG 则是另一种思路它不是靠 LLM 事后抽取而是在建库之前先把领域概念、关系和属性定义好比如产品才具有版本版本具有发布时间、支持的功能清单。然后把这些概念做成一个轻量的 schema引导文档拆解和检索。文档入库时先按 schema 归类用户提问时先把问题映射到 schema 上的概念节点再去库里精确找。这个思路最大的价值不是工程上有多少花样而是给了 RAG 一个业务骨架。特别是多产品、多版本、多知识域交织的场景Ontology 能在召回之前就把范围收敛到一个子集大大减少无关干扰。1.3 落地顺序的建议别一上来就搞图谱如果你在现有系统里要补知识割裂这一课我建议按这个顺序来先做 metadata 过滤再做父子分块如果还不够考虑做文档级别的轻量图谱最后才上完整 GraphRAG 或 Ontology 工程。这里有个认知要纠正GraphRAG 的效果不是用了就有它严重依赖文档质量和实体抽取质量。很多团队一上来就要 GraphRAG结果图抽得稀碎最终效果反而比普通向量检索还差。先把基础坑填上再谈图是更稳妥的路径。2. Hit Rate 上不去锅大多不在 LLM 而在召回链路我调试 RAG 类项目时习惯先用一组固定的 QA 把召回和生成分开测。这个习惯帮我排掉了不少误导项。很多人发现答案不对第一反应是LLM 不会答于是换更强的模型、改 prompt折腾半天发现效果没变化最后才排查到向量库里正确的那一段压根没被检索到。这一步如果用量化指标来说就是 Hit Rate 不够——Top K 结果里包含标准答案片段的比例。Hit Rate 不达标后面生成环节不管怎么调都是花式补救。2.1 混合检索稀疏与稠密的互补向量检索适合语义近似但有一个先天盲区精确词匹配。用户问激活序列号格式是什么文档里写的是License Key 格式如果只有向量检索很容易被同义的泛化信息带走而 BM25 这类稀疏检索擅长精确词和罕见词却完全不懂语义近义。所以现在的主流做法是把两者合并BM25 的得分和向量相似度得分做归一化加权取并集再重排。再加上 metadata 过滤和命中词高亮召回质量会有一个可感知的提升。这一步不需要多少代码一两百行就能实现一个 score 融合是性价比非常高的升级。2.2 查询改写把用户问题变成更利于检索的形态用户输入的自然语言往往不是最好的检索词。常见处理是 multi-query让 LLM 把一个问题拆成几个子问题或生成多个等价改写每个改写单独去检索最后去重合并候选集。比如上个月的报表为什么导不出可以改写成报表导出失败上个月报表导出报错原因导出 上月 报表 失败三个 query 同时查召回面会大很多。这个方案实测在 QA 类知识库里能显著提升召回覆盖。但要注意成本多 query 会让延迟和 token 消耗上升所以建议只在 Top1 明显不满足时才触发而不是每个问题都启动改写流程。2.3 重排把 TopK 从像变成是第一轮检索的目标是宁可多召回不要漏所以 TopK 往往拉到 20 甚至 30但喂给大模型的上下文非常有限必须在精排阶段压缩到 3~5 段。精排推荐用 Cross-Encoder 类的 rerank 模型比如 bge-reranker 系列它会真正逐字比对 query 和候选片段比双塔向量模型精细得多。代价是速度慢一些但因为它只对少量候选做深度匹配整体延迟仍然可控。我见过不少项目把向量检索的 TopK 直接当答案上下文用总觉得大模型自己会分辨但这个假设在实际项目里经常失效。加了 rerank 之后上下文质量提升会直接反映在答案忠实度上。可以说这是整条流水线里最便宜的一跃。2.4 关于 Hit Rate 的两个常见误判一是把用户觉得答案对了等同于召回到正确片段。答案可能来自模型自身知识也可能是猜的这种情况不能用业务正确率代替 Hit Rate 评估。二是用端到端效果反推召回问题。要定位瓶颈必须分层打日志看候选集来源、重排后保留的片段、最终上下文。有时候问题出在 query 改写不足有时候出在 metadata 过滤得太严有时候就是切分把答案切散了。这些只能靠带有链路日志的分层评估去发现凭感觉猜只会不断在错误环节耗时间。3. Agentic RAG 是流水线的第二次进化把单轮检索改成决策循环传统 RAG 的流程本质是一条单向流水线问一句查一次查完拼进 prompt 就结束。这种模式在小知识库、单跳问题上是够用的但一旦遇到需要多跳推理、需要多轮检索、需要实时信息的问题就非常吃力。于是 Agentic RAG 成了社区的新热点它要解决的不是怎么检索而是什么时候查、查几次、查完还要不要继续查。3.1 为什么单轮检索会失效举一个典型场景用户问我们按上个月的销售明细估算这个季度的返点比例大概是多少需要把估算依据一并列出。这个问题的答案可能要跨两张表一张是销售明细表另一张是返点规则文档还涉及上个月估算这两个动作。单轮向量检索很难在一次 query 里同时命中这两类内容就算分别都命中了也缺少把两部分组合起来的推理过程。传统 RAG 面对这种多跳任务要么答不全要么答错。Agentic RAG 的思路是不要一上来就期望一次检索解决所有问题而是让 LLM 作为一个检索调度员它先判断问题是否需要检索决定要不要拆成子问题再决定每轮检索用什么 query。拿到结果后如果发现不够就改写策略再查直到有足够信息才生成最终答案。这套逻辑本质上把 RAG 从流水线升级成了决策循环。3.2 最小可行的 Agentic RAG 结构不需要一上来就接重型框架可以先在一个循环里实现核心逻辑LLM 判断当前问题是否需要外部知识。如果需要生成检索 query可以是多个。执行检索拿到候选片段后让 LLM 评估信息是否足够回答。如果不够根据缺失信息改写 query 再查最多循环两到三次。足够后进入生成阶段并在答案里标注引用来源。这个循环用几十行代码就能搭起来。我团队以 Java 为主早期用过 LangChain4j 的 Easy RAG 起步它的默认流程适合快速验证但真要控制决策循环还是保留手工状态机更直观。等跑明白之后再换框架不迟。这里我想强调一点Agentic 的价值不在炫技而是让系统在复杂问题上有了自查和补查的能力。3.3 检索循环里最容易被踩的坑流水线冲突Agentic RAG 一旦进入多轮检索前后结果之间可能打架。比如第一轮查到的文档说导出的文件格式是 CSV第二轮查到的升级手册说新版本支持 Excel 导出。两份文档都命中但属于不同版本答案如果都塞给用户就会产生冲突。这类流水线中的冲突其实非常普遍只是很多教程刻意回避了。处理冲突没有银弹但有几条经验在 metadata 里带上文档版本和发布时间冲突时优先采用时间戳更新、版本号更高的来源让 LLM 对冲突来源做裁决如果无法裁决就在回答里明确列出两种说法请用户确认不要装作只有一种答案永远不要用沉默掩盖冲突。我在评估时发现模型直接无视冲突、只取其一的比例高得吓人这比答不知道更有误导性因为它会让用户以为另一个可能性不存在。这个矛盾引出一个更深的问题如果没有能对比来源先后关系和可信度的机制多轮检索越多冲突风险越大。所以 Agentic RAG 的上限不只取决于会不会查还取决于会不会裁决。3.4 Agentic 不是万能药别为简单问答强行上药也要说句公道话。Agentic RAG 带来的延迟、token 成本和不确定性是真实存在的。如果知识库只是产品 FAQ、单跳问题占八成固定流水线反而更稳。我个人的建议是先用普通 RAG 做基线用评测集量出哪些问题类型被系统答错了判断这些错误是不是需要多轮检索才能解决如果是再把那部分流量切到 Agentic 分支其余走固定流程。这比一上来全员 Agent 靠谱得多。4. 切分粒度决定上限拆文档要按结构拆不是按字数拆RAG 里最被低估的环节就是文本切分。很多教程一句话就带过去了固定窗口 512 个 token、重叠 128好像拆文档只是调调参数。实际上切分质量直接决定了召回内容是不是可用的完整语义块。我在实际项目里踩过的坑包括把一张 Markdown 表格硬切到两半导致检索到的片段只有半张表列头还没了把一段代码示例从第 6 行断开模型拿到的代码根本补不完整把问题-答案对拆散明明是一个 FAQ 条目却只召回了一半。这些问题的根子都在于固定字符窗口不尊重文档结构。人在阅读时是按章节、段落、列表来理解信息的机器切分也应该按这个逻辑走。4.1 结构感知切分是第一步正确的起点是先识别文档结构再按结构边界切。PDF 先解析出标题层级、段落、表格区域Markdown 先按标题层级构建嵌套关系Word 或 HTML 先按语义块划分。切分时尽量让一个 chunk 落在标题层级之下、语义完整的最小单元里。如果是表格最好保留表格结构或者转成 markdown 格式不要让模型收到一堆断裂的单元格文本。这里顺带回应很多人在问的有没有本地的 RAG 文本拆解工具。当然有Unstructured 是成熟的文档解析和切分开源库MinerU 这类面向 PDF 的解析工具补上了版面分析能力如果用的是 LlamaIndex它的 node parser 和 header 切分器也能实现结构感知切分。工具选型上我建议优先选能输出结构化中间表示的方案比如先解析出文本块和版面坐标再做自定义切分而不是一步到位的固定窗口。这样后续改切分策略你不需要重新解析整个文档库。4.2 父子分块检索召回小的上下文给大的一个更进阶的切分策略是父子分块。父块是一整个大章节子块是把大章节切成的小片段。入库时父子都建向量索引但检索时只根据子块向量找到相关小片段命中后再把它对应的父块整块返回给 LLM 作为上下文。这样做的逻辑是向量检索在小粒度上更精准而大模型推理需要完整的上下文。子块负责定位到正确的段落附近父块负责提供足够上下文让模型完整作答。这对跨句引用、问答对拆散、代码块完整性问题都有明显改善。实测下来父子分块对答案需要上下文铺垫的场景非常有帮助但有一定代价需要把父块也取出来内存和延迟会略增。如果不想增加太多延迟可以在 metadata 里存父块 id检索时先取子块列表再按需批量加载父块。这个方案在不改造切分流程的前提下往往就能带来一轮明显提升。4.3 切分要与重排联合调优切分粒度不是孤立参数。切得太碎召回精度高但上下文不足切得太大上下文完整但噪声和无关内容也会变多。我的经验是把切分策略的评估绑定在 Hit Rate 和 Rerank 之后的 NDCG 上而不是只看能不能查到。实际调整时至少跑三组方案做对比固定窗口、结构感知、父子分块用同一套 QA 集分别测看哪组在召回层和生成层都表现好。这一步虽然耗时但收益往往比你换一个 embedding 模型更明显。不少团队卡了很久的 RAG 效果问题最后都是切分策略调整后解决的。5. 知识库里到底能不能放图片多模态检索的三层落地方式有一类问题网上被反复问起RAG 知识库能存图片吗这个问题其实有点宽。能存但要看你说的存是哪种存法。图片本身不是标准向量库的天然对象你能做的是给图片建立可检索的文本描述或统一的向量表示。5.1 第一层图片转文本索引最简单也最常用对大多数知识库场景第一层就够用了把图片中的文字用 OCR 抽成文本或者用视觉语言模型VLM生成一句对图片的描述把这段文本做 embedding 存入向量库。检索时匹配的是文本但返回的内容里可以带上原始图片路径。比如一个售后知识库里有一张报错弹窗截图你可以生成文本登录页面提示错误码 10086常见原因为账号未激活或网络不可达。用户问10086 是什么错误时检索能命中这段描述回答时附上截图一起返回。这个方案实现成本低覆盖了绝大多数我想把一张说明书里的图存进去的需求。很多团队纠结半天多模态检索本质上只需要这一层。5.2 第二层VLM 描述的精细化与图文混排整合如果第一层不够通常是因为 VLM 生成的一句描述太粗比如这是一张饼状图这种废话。解决方法是把 VLM 生成描述的任务做成结构化让模型输出图表的标题、坐标轴含义、主要数据点、异常值或者对截图输出所在界面、操作路径、关键按钮。这样图片描述就不再是有与没有而是真正可检索的知识。还有一个容易被忽略的细节图文混合文档里图片不是孤立存在的它往往紧跟在一段文字后面。切分时要把上文文字 图片 图片描述作为一个整体块进入索引这样检索时模型能同时拿到图和上下文效果比单独索引图片好得多。如果只是把图片丢进库里不跟上下文绑定召回还是空转。5.3 第三层真的做统一图文向量表示再进一步才是大家常说的多模态 embedding比如 CLIP 或更专业的图文向量模型把文本和图片映射到同一个向量空间这样你可以用一张示意图去检索功能结构相近的文档图或者用自然语言检索到高度匹配的图片。第三层听起来很酷但实际落地要评估三类成本模型部署成本、图片预处理管线、样本标注成本。如果不是内容素材类产品前期性价比通常不高。我个人的建议是先分清需求如果是文档里的图片需要被答案引用第一层足够如果是建立看图搜图的素材库那是多模态检索产品可以直接走第三层如果是混合场景先做第一层加第二层停止过度设计。等业务验证确实有更高需求再投入多模态模型不迟。6. 没有评估闭环的分水岭都是伪命题分层评测最小闭环怎么搭最后这一处恰恰是多数团队最容易跳过的部分。做了上面几个点之后你需要一个客观手段来回答我的 RAG 到底行不行、瓶颈在哪。没有评估闭环前面五个分水岭都只是感觉上的优化无法持续迭代。很多团队花几百小时调整 embedding 模型、重排策略、提示词最后谁也说不出到底哪个改动起了作用这种状态最可怕。6.1 为什么要分层评估而不是只看端到端RAG 是典型的链路型系统召回、重排、生成每个环节都可能出问题。如果只盯着端到端回答质量你会陷入答案不对却不知道是哪一个环节的锅的困局。而且环节之间会有错误传导召回阶段引入的噪声会在重排阶段放大最后生成被误导得更远。这就是为什么你在网上看到有人讨论流水线中的冲突——它不只发生在多轮检索里在评估环节同样存在你用错误的端到端指标去优化一个环节常常得不到预期收益因为另一个环节在拖后腿。6.2 最小可行的评估体系四层指标不需要一开始就搞企业级评估平台先搭一个最小闭环就够了召回层Hit Rate、RecallK、MRR。衡量正确答案是否进入候选集通常一段脚本就能算。精排层在 Rerank 前后分别算 Hit Rate 和 NDCG看重排有没有真实带来提升。生成层用忠实度、相关性、答案完整度三个人工指标从测试集里随机抽样本打分。也可以用 LLM-as-judge 做初筛但最终必须有人看样本。链路日志每次请求记录 query、检索来源、重排结果、最终上下文、模型输出。后面每一次优化都能靠日志快速回溯到瓶颈环节。这套体系不需要多少额外开发量重点在于坚持记录和定期跑分这两件事做到位系统的优化就有了方向。6.3 一个可以直接上手的资料集评估集不需要特别大先从 50 到 100 条高频问题起步就行。每一条问题标注三个字段标准答案、它对应的标准文档片段、问题类型单跳、多跳、需推理、需实时信息。这比你花一个月去做大规模标注有用得多。第一批样本可以从客服聊天记录、内部答疑群、用户反馈里抽取。评估节奏方面我自己的习惯是每次改动后跑一遍全量集对比召回层和生成层指标然后只保留真正带来提升的改动进入下一次测试。这个循环跑上两三周系统的稳定性和可解释性都会上一个台阶。6.4 指标也会骗人样本永远要人工看最后提醒一句指标是工具不是圣旨。社区里经常看到Hit Rate 90%之类的漂亮成绩但如果样本本身只挑简单问题指标再高也没有意义。我见过有人把 RAG 指标跑得非常好看结果一上生产就被真实问题打回原形。所以每周至少抽 20 个实际用户的失败案例人工分析是哪一层出了问题再反过来补测试集。这比追赶任何先进指标都更实际。评估的意义不在证明自己做得对而在让自己下一次改动做对。这几年我做知识库助手的最大感受是RAG 这个词看起来烂大街是因为大家在教程里看到的都是同一条流水线。真正的难度从来不在把流水线搭起来而在让它在复杂文档、复杂问题、真实流量下依然可靠。上面这六处没有一处有银弹但每一处都值得你在上线前认真过一遍。如果你刚跑通第一个 demo我建议从 Hit Rate 和切分这两处入手成本最低、收益最直接。而且一定要先搭一个简单的评估闭环哪怕只有几十条样本否则后面所有的优化都会变成玄学。这大概就是我想分享的全部经验了。
