1. 为什么“RAG 烂大街”是个伪命题这两年但凡跟大模型沾点边的团队几乎人手一套 RAG 流水线。文档切片、向量化、存库、检索、拼 prompt、丢给模型生成——这套东西已经标准化到随便找个开源框架半天就能跑通 demo。于是圈子里开始流行一句话“RAG 烂大街了”。我一开始也这么觉得。直到去年接手一个企业知识库项目客户丢过来 12 万份文档涵盖产品手册、工单记录、合同模板、内部 Wiki要求“问什么都能答准”。我拿最熟悉的 Naive RAG 跑了一版Top-5 召回率勉强 60%答非所问的比例高得离谱。那一刻我才意识到烂大街的从来不是 RAG 本身而是那条最粗糙的流水线。真正拉开差距的地方藏在六个关键分水岭上。这篇文章就把这六处逐一拆开讲清楚每一处为什么是分水岭、怎么判断自己卡在哪、以及具体怎么改。不管你是刚搭完第一个 RAG demo 的新手还是正在被召回率折磨的老手应该都能找到能直接抄作业的东西。先给个全局认知一条完整的 RAG 链路从数据进来到答案出去大致经过数据解析、切片策略、索引构建、检索召回、重排过滤、生成编排六个环节。Naive RAG 在每个环节都用了最省事的默认方案而生产级 RAG 需要在每个环节做针对性设计。下面逐个说。2. 分水岭一数据解析与切片策略2.1 为什么切片是第一个分水岭很多人把切片当成“预处理”随便按 512 token 一刀切就完事。这是最致命的误区。切片质量直接决定了检索的上限——切错了后面检索再花哨也救不回来。我见过一个典型案例一份产品故障排查手册每个故障现象和解决方案是一一对应的。按固定长度切片后某个故障现象的描述在 chunk 3 的末尾对应的解决方案在 chunk 4 的开头。用户问“XX 报错怎么解决”检索命中了 chunk 3但解决方案根本没被召回模型只能瞎编。固定长度切片的根本问题在于它假设语义边界和字符长度边界重合而现实中这两者几乎从不重合。2.2 分层切片的具体做法我的做法是分层处理不同文档类型用不同策略文档类型切片策略切片长度重叠理由结构化手册按标题层级切按章节自然长度无章节本身就是语义单元合同/法律文本按条款切按条款条款号重叠条款独立性极强工单记录单条工单为单元整条无问答对天然完整长篇文章语义切片256-512 token10%-15%平衡粒度与上下文表格数据整表 行摘要按表表头重复表格脱离表头无意义语义切片的核心思路是先按句子切分再计算相邻句子的语义相似度在相似度骤降的地方断开。这样切出来的每个 chunk 内部语义连贯边界落在真正的语义转折处。具体实现上我常用一个组合方案先用规则做粗切按标题、段落再用语义相似度做细调。纯语义切片计算量大纯规则切片又不够灵活两者结合性价比最高。2.3 实操心得切片长度不是拍脑袋定的切片长度怎么定我的经验是看检索粒度需求。如果你希望检索返回的是“一个完整答案”切片就要包含完整答案如果你希望检索返回的是“相关线索”切片可以更细。一个可参考的计算方法假设你的文档平均每 100 字包含一个完整信息点用户提问通常需要 2-3 个信息点才能回答那么切片长度应该在 200-300 字左右。太短则信息不完整太长则噪声过多。注意切片重叠不是越多越好。重叠 10%-15% 足够覆盖边界信息超过 20% 会导致检索结果大量重复浪费上下文窗口。3. 分水岭二索引构建与向量化选型3.1 向量模型不是越贵越好索引构建环节最大的坑是盲目追求“最强向量模型”。我见过团队用最大的 embedding 模型结果检索效果还不如一个小模型——因为向量模型和你的数据领域不匹配。通用向量模型在通用语料上训练对专业术语、行业黑话的表示能力有限。比如医疗领域的“心梗”和“心肌梗死”在通用模型里可能距离较远但在专业模型里应该很近。选型时我会做三件事拿真实 query 做小规模评测从历史提问里抽 100 条人工标注正确答案然后对比不同模型的召回率。这比看论文榜单靠谱得多。考虑维度与成本高维向量检索慢、存储贵。如果 768 维和 1536 维效果差不到 5%果断选 768。测试领域适配性如果通用模型效果差考虑用领域数据做微调或者用领域预训练模型。3.2 混合索引向量 关键词 图纯向量检索有个硬伤对精确匹配不敏感。用户问“产品型号 XR-2000 的保修期”向量检索可能召回一堆“保修期”相关但型号不对的文档。我的方案是混合索引三路并行向量索引负责语义相似召回解决“意思相近但用词不同”的问题。关键词索引BM25负责精确匹配解决型号、编号、专有名词的召回。图索引负责关系推理解决“A 的上级部门是谁”这类需要多跳的问题。三路结果用加权融合Reciprocal Rank Fusion 是常用方法权重根据业务调。一般场景下向量 0.5、关键词 0.3、图 0.2 是个不错的起点。3.3 GraphRAG 到底解决了什么问题GraphRAG 这两年很火但很多人没搞明白它到底解决什么。简单说当答案需要跨多个文档、多跳推理才能得出时纯向量检索无能为力。举个例子文档 A 说“项目 Alpha 由张三负责”文档 B 说“张三隶属于技术二部”文档 C 说“技术二部的预算审批人是李四”。用户问“项目 Alpha 的预算谁审批”。纯向量检索可能只召回文档 A答不出李四。GraphRAG 通过实体关系图能从 Alpha 走到张三、走到技术二部、走到李四完成多跳推理。但 GraphRAG 不是银弹。构建知识图谱的成本很高实体抽取、关系抽取都需要额外模型而且图谱质量直接决定效果。我的建议是只有当你的业务确实存在大量多跳推理需求时才上 GraphRAG。否则混合索引 重排就够了。4. 分水岭三检索召回与 Contextual Retrieval4.1 召回阶段的核心矛盾召回阶段永远在解决一对矛盾召回率与精确率的平衡。召回太少答案可能不在候选里召回太多噪声会干扰模型判断。Naive RAG 通常设 Top-K3 或 5这是拍脑袋的值。我的做法是动态 Top-K根据 query 的复杂度调整。简单事实性问题 Top-K3 足够复杂分析性问题可能需要 Top-K10 甚至更多。判断 query 复杂度可以用一个轻量分类器或者直接用规则包含“对比”“分析”“为什么”等词的 query 判为复杂扩大召回。4.2 Contextual Retrieval 的关键改进Contextual Retrieval 是这两年检索侧最重要的改进之一。它的核心思想是切片在脱离原文后会丢失上下文信息导致检索和生成都受影响。具体做法是在切片入库前用模型为每个切片生成一段上下文说明然后把这段说明拼接到切片前面一起向量化。比如一个切片内容是“保修期为 24 个月”单独看不知道是什么的保修期。加上上下文说明“本段来自产品 XR-2000 的售后条款”检索时就能准确匹配到“XR-2000 保修期”的 query。这个改动的成本很低——一次额外的模型调用——但效果提升明显。我在多个项目里实测召回率能提升 10-20 个百分点。4.3 实操召回结果去重与多样性召回阶段还有一个容易被忽略的问题结果高度重复。尤其是切片有重叠时Top-10 里可能有 5 条内容几乎一样真正有用的信息只占 2-3 条。我的处理方式是做 MMR最大边际相关性去重在保证相关性的前提下优先选择与已选结果差异大的候选。这样能在有限的名额里塞进更多样的信息。具体参数上MMR 的 lambda 设 0.7 左右比较合适——偏向相关性但保留一定多样性。lambda1 就是纯相关性排序lambda0 就是纯多样性都不好用。5. 分水岭四重排与过滤5.1 为什么需要重排召回阶段用的是向量相似度这是个“粗筛”。向量相似度高不代表真的相关——可能只是用词相似。重排阶段用更精细的模型通常是 cross-encoder对候选做二次打分能显著提升精度。我做过对比同一批 query召回 Top-20 直接给模型生成准确率约 65%经过重排后取 Top-5 再生成准确率能到 82%。重排是性价比最高的精度提升手段之一。5.2 重排模型的选型重排模型分两档轻量档小型 cross-encoder延迟低适合对响应速度敏感的场景。重量档大型 cross-encoder 或 LLM 打分精度高但延迟大。我的建议是线上用轻量档做初排离线用重量档做评测和调优。如果业务对精度要求极高且能接受延迟再考虑线上用重量档。5.3 过滤规则的设计重排之后还需要过滤把明显不相关或低质量的结果剔除。常用过滤规则相似度阈值低于阈值的直接丢避免“矮子里拔将军”。时间过滤如果业务对时效敏感过期文档降权或剔除。权限过滤不同用户能看到的文档不同检索前就要做权限隔离。去重过滤内容重复的只保留一条。注意过滤规则不要设得太激进。我见过团队把阈值设太高导致召回结果被砍到只剩 1-2 条模型反而没足够信息生成。阈值应该通过评测确定而不是拍脑袋。6. 分水岭五生成编排与 Agentic RAG6.1 从“一次检索”到“多轮编排”Naive RAG 是“一次检索 一次生成”但很多问题需要多轮检索才能回答。比如“对比 A 产品和 B 产品的保修政策”需要分别检索 A 和 B 的信息再对比。Agentic RAG 的核心就是把检索变成 Agent 的一个工具让 Agent 自主决定检索什么、检索几次、什么时候停止。这需要一套编排框架来管理流程。6.2 LangGraph 在 RAG 编排中的角色LangGraph 是目前做 Agentic RAG 编排比较顺手的框架。它把流程建模成图节点是操作检索、生成、判断边是流转条件。相比链式编排图编排能表达循环、分支、并行更适合复杂 RAG 流程。一个典型的 Agentic RAG 图结构入口节点接收 query判断复杂度。检索节点执行检索可多次调用。判断节点判断当前信息是否足够回答。生成节点信息足够时生成答案。回退边信息不足时回到检索节点调整 query 再检索。这个结构的关键在于判断节点——它决定了要不要继续检索。判断逻辑可以用规则比如“召回结果相似度都低于阈值就继续检索”也可以用模型判断。6.3 实操控制 Agent 的检索轮次Agentic RAG 最大的风险是无限循环——Agent 一直觉得信息不够一直检索。必须设上限。我的做法是设两个上限最大轮次比如 3 轮和最大 token 消耗比如 8000 token。任一超限就强制进入生成节点用现有信息回答并在答案里标注“信息可能不完整”。另外每轮检索后要更新 query。第一轮用原始 query第二轮用“原始 query 缺失信息点”第三轮再调整。这样每轮检索都有针对性而不是重复检索同样的内容。7. 分水岭六评测与持续迭代7.1 没有评测就没有优化前面五处改进怎么知道有没有效果靠评测。没有评测的 RAG 优化就是盲人摸象。RAG 评测分两个层面检索层召回率、精确率、MRR、NDCG。衡量检索系统找到相关内容的能力。生成层答案准确率、忠实度是否基于检索内容、完整性。衡量最终答案的质量。7.2 评测集的构建评测集是评测的基础。我的构建方法从真实提问中采样历史提问是最真实的评测数据。人工标注答案每条 query 标注标准答案和对应的源文档。覆盖各类场景简单事实、多跳推理、对比分析、否定查询都要有。定期更新业务在变评测集也要跟着更新。规模上100-200 条 query 就能给出有参考价值的评测结果。太少波动大太多标注成本高。7.3 常见问题速查表问题现象可能原因排查方向解决思路召回结果不相关切片粒度过粗/过细检查切片长度和边界调整切片策略加语义切片答案答非所问检索没命中正确文档看召回结果里有没有正确答案加混合索引加 Contextual Retrieval答案编造内容模型没基于检索内容检查 prompt 和忠实度强化 prompt 约束加引用要求多跳问题答不出缺少关系推理能力看是否需要跨文档推理上 GraphRAG 或 Agentic RAG响应太慢检索或重排太重看各环节耗时轻量化模型加缓存结果重复度高切片重叠过多检查重叠比例降重叠加 MMR 去重7.4 持续迭代的节奏RAG 系统不是一次搭好就完事。我的迭代节奏是每周看线上 bad case归类问题。每月跑一次完整评测对比指标变化。每季度review 整体架构看有没有新的技术值得引入。迭代时一次只改一个变量否则无法判断是哪个改动带来的效果。这是做实验的基本纪律。8. 我在实际项目中的几点体会踩了这么多坑有几个体会特别深。第一不要迷信新技术。GraphRAG、Agentic RAG 都很火但如果你的业务就是简单事实问答上这些就是杀鸡用牛刀徒增复杂度和成本。先把基础流水线做扎实再考虑进阶方案。第二数据质量比算法重要。我见过太多团队在算法上反复调优但源文档本身就有大量错误、重复、过期内容。垃圾进垃圾出数据不清洗算法再强也白搭。第三评测要趁早。很多团队做到一半才想起来评测结果发现前面做的改动都没法量化效果。评测集应该和系统同步建设甚至先建评测集再搭系统。第四简单方案往往够用。混合索引 重排 Contextual Retrieval 这套组合能解决 80% 的召回问题。剩下 20% 再考虑 GraphRAG 或 Agentic RAG。不要一上来就上最复杂的方案。最后分享一个我常用的小技巧给每个 chunk 打上来源标签文档名、章节、更新时间生成答案时要求模型标注引用来源。这样既能提升答案可信度又方便排查问题——答案错了直接看引用的 chunk 就知道是检索错了还是生成错了。这个习惯帮我省了大量排查时间。