1. 从一条流水线说起为什么大多数 RAG 项目止步于 Demo过去两年我参与过不下二十个 RAG 相关的项目从内部知识问答到面向客户的智能客服从法律文书检索到工业设备手册查询。一个很明显的感受是RAG 的门槛已经被拉得极低但天花板依然高得吓人。低到什么程度一个刚入门的开发者花一个下午就能用现成的框架搭出一套“文档上传→切块→向量化→检索→拼 Prompt→调模型”的完整链路跑起来还能给出像模像样的回答。高到什么程度同样这套链路一旦放到真实业务里面对几千上万份文档、面对用户千奇百怪的提问方式、面对“答错一次就失去信任”的场景几乎立刻崩盘。这就是标题里说的“烂大街的只是那条流水线”。那条流水线本身没有错它是 RAG 的骨架是每个项目都必须走通的第一步。但问题在于太多人把这条流水线当成了终点以为把 LangChain 或者 LlamaIndex 的模板代码跑通RAG 就算做完了。实际上流水线只是入场券真正的分水岭在于流水线之外的六个关键处。这六处决定了你的 RAG 是一个只能演示的玩具还是一个能扛住真实业务压力的系统。我写这篇东西不是要再教你一遍怎么切块、怎么调 embedding 接口那些教程已经够多了。我想做的是把这六处分水岭拆开讲清楚每一处到底难在哪、为什么难、以及我在实际项目里是怎么处理的。如果你已经搭过至少一个 RAG Demo正准备往生产环境推进那这篇内容应该对你有用。如果你还在纠结用哪个框架那也不冲突框架选型只是工具层面的问题下面要讲的这些才是决定成败的东西。2. 分水岭一检索质量——从“能查到”到“查得准”2.1 向量检索的天花板在哪里先说一个很多人不愿意承认的事实纯向量检索在真实场景下的召回质量往往比 Demo 里差得多。Demo 里你用的是几篇结构清晰的文档问题也是你自己设计的当然查得准。但真实业务里文档格式五花八门有 PDF 扫描件、有 Excel 表格、有带层级编号的规章制度、有口语化的会议纪要用户的提问方式也千奇百怪有的一句话十几个字有的一段话几百字还带错别字。向量检索的本质是把文本映射到一个高维空间然后找距离最近的邻居。这个机制决定了它擅长“语义相似”但不擅长“精确匹配”。举个例子用户问“第三章第二节提到的那个审批流程是什么”向量检索很可能召回一堆讲“审批流程”的段落但未必能精准定位到“第三章第二节”。再比如用户问一个产品型号“XG-2000A 的额定功率”向量检索可能召回所有提到“额定功率”的段落但未必能锁定到那个具体型号。我在一个工业设备手册项目里就踩过这个坑。手册里有几百个型号每个型号的参数表结构相似向量检索经常把不同型号的参数混在一起返回。后来我们引入了BM25 关键词检索做混合召回把向量检索和关键词检索的结果做融合排序召回准确率才明显提升。这个思路现在有个流行的叫法叫Hybrid Search但核心逻辑很简单向量负责语义泛化关键词负责精确命中两者互补。2.2 Contextual Retrieval给每个块补上“上下文”混合检索解决了召回渠道的问题但还有一个更隐蔽的问题切块本身会丢失上下文。你把一份文档切成一个个 chunk每个 chunk 单独看可能语义完整但放到整篇文档里它可能只是一个论据、一个例子、一个补充说明。当这个 chunk 被单独召回时模型看到的是一段“没头没尾”的文字自然容易答偏。Anthropic 提出的Contextual Retrieval思路很值得借鉴在切块之后、向量化之前先用一个轻量模型给每个 chunk 生成一段简短的上下文说明把这段说明拼接到 chunk 前面再去做 embedding。比如一个 chunk 原文是“该参数应设置为 0.5”单独看完全不知道在说什么但加上上下文“这是 XG-2000A 型号在高温模式下的额定功率参数说明”之后检索和生成的质量都会大幅提升。这个做法听起来简单但实操中有几个细节要注意。第一上下文说明不能太长否则会稀释 chunk 本身的语义一般控制在 50 到 100 字比较合适。第二生成上下文的模型不需要太强一个小模型甚至本地模型就够用因为它的任务只是“概括这段文字在原文中的位置和作用”不是做复杂推理。第三如果文档量很大给每个 chunk 都生成上下文会带来额外的计算成本需要权衡。我的经验是对于结构清晰、chunk 本身语义完整的文档可以跳过这一步对于结构松散、chunk 依赖上下文的文档这一步的收益非常明显。2.3 重排序把“相关”和“最相关”分开混合检索解决了“召回哪些”但召回回来的结果往往有几十条直接全部塞给模型既不经济也不利于生成质量。这时候就需要Rerank也就是重排序。它的作用是把召回结果按照与问题的真实相关度重新排一遍把最相关的几条排到前面。Rerank 模型和 embedding 模型是两回事。Embedding 模型做的是“粗筛”追求速度和召回率Rerank 模型做的是“精排”追求准确率通常是一个交叉编码器把问题和候选文档一起输入输出一个相关度分数。代价是计算量更大所以一般只对 Top 20 到 Top 50 的结果做重排再取 Top 3 到 Top 5 送给生成模型。我实测下来在混合检索之后加一层 Rerank端到端的回答准确率通常能提升 10 到 20 个百分点这个投入产出比非常高。选型上开源的 BGE-Reranker 系列和 Cohere 的 Rerank 接口我都用过前者适合本地部署、数据不出内网后者适合快速验证、省去运维成本。具体选哪个看你的数据敏感度和预算。3. 分水岭二知识组织——从“一堆块”到“一张网”3.1 为什么扁平化的向量库不够用大多数 RAG 项目的知识库是一个扁平的向量库所有 chunk 平铺在那里检索就是找最近的邻居。这种结构对于“单跳问题”够用比如“公司的年假政策是什么”检索到相关段落就能回答。但对于“多跳问题”比如“我入职三年今年休了五天年假还剩多少天”就需要把“年假政策”“工龄计算规则”“已休天数”几个信息拼起来扁平检索很难一次性召回所有需要的片段。更麻烦的是扁平结构丢失了文档之间的关系。一份文档里提到的某个概念可能在另一份文档里有详细解释一个流程的某个步骤可能引用了另一个流程的输出。这些关系在切块和向量化之后就消失了模型只能靠“碰运气”看能不能同时召回相关片段。3.2 GraphRAG把知识连成图GraphRAG是这两年很热的一个方向核心思路是在向量检索之外额外构建一个知识图谱把实体、概念、事件以及它们之间的关系显式地存下来。检索的时候不仅做向量匹配还沿着图谱的边做多跳扩展把关联信息一起召回。我拿一个实际项目举例。我们做的是一个企业内部制度问答系统制度文档之间有大量交叉引用比如“报销流程”引用了“审批权限表”“审批权限表”又引用了“岗位职级定义”。用扁平向量库的时候用户问“部门经理能批多少钱的报销”系统经常只召回“报销流程”的片段答不出具体金额。后来我们构建了一个简单的图谱把“岗位”“审批权限”“金额区间”作为节点把“拥有权限”“适用于”作为边检索时先定位到“部门经理”这个节点再沿边扩展到“审批权限”最后找到对应的金额区间。准确率提升非常明显。当然GraphRAG 不是没有代价。构建图谱需要额外的实体抽取和关系抽取步骤这部分工作量和成本都不低。我的建议是不要一上来就搞全量图谱先从业务中最核心的那几个实体和关系入手做一个最小可用的图谱验证收益之后再逐步扩展。另外图谱的维护也是长期成本文档更新时图谱也要同步更新这个流程要提前设计好。3.3 Ontology RAG给知识一个“骨架”比 GraphRAG 更进一步的是Ontology RAG也就是引入本体Ontology来定义知识的结构。本体说白了就是一套概念体系规定了有哪些类型的实体、它们有哪些属性、之间可以有哪些关系。比如在医疗领域本体可能定义“疾病”“症状”“药物”“治疗方案”几类实体以及“疾病表现为症状”“药物用于治疗疾病”等关系。Ontology RAG 的价值在于它让检索从“找相似文本”变成了“按结构查知识”。用户问“哪些药物可以治疗高血压”系统不需要去猜哪段文本相关而是直接在本体里查“高血压”这个疾病节点沿“治疗”关系找到对应的药物节点。这种方式的准确率和可解释性都远高于纯向量检索。但本体的构建门槛很高需要领域专家参与而且一旦定下来就不容易改。我的经验是本体适合那些知识结构相对稳定、领域边界清晰的场景比如医疗、法律、金融合规对于快速变化、边界模糊的场景强行上本体反而会束缚手脚。如果你不确定要不要上本体可以先从轻量级的“实体类型 关系类型”开始不追求完整的本体体系够用就行。3.4 结构化知识库与 RAG 的分工这里还要澄清一个常见的混淆RAG 知识库和结构化知识库不是一回事也不应该互相替代。结构化知识库比如关系型数据库、图数据库擅长精确查询和聚合计算比如“上个月销售额是多少”“有多少员工在华东区”RAG 擅长处理非结构化文本比如“客户对产品的反馈主要集中在哪些方面”。在实际系统里这两者往往是配合使用的。用户的问题先经过一个路由层判断是走结构化查询还是走 RAG 检索或者两者都走、最后做结果融合。我见过一些项目试图把所有东西都塞进向量库结果连“今年第三季度营收”这种简单聚合都答不准这就是没有做好分工。4. 分水岭三Agentic RAG——让检索变成“主动行为”4.1 传统 RAG 的被动性传统 RAG 的流程是线性的用户提问→检索→生成。检索是一次性的不管召回结果好不好都直接送给模型。这种被动模式在简单问题上够用但遇到复杂问题就力不从心。比如用户问“对比一下 A 产品和 B 产品在续航和价格上的差异”一次检索很难同时召回两个产品的完整信息模型只能基于不完整的上下文硬答。Agentic RAG的核心思路是让模型自己决定“要不要检索”“检索什么”“检索几次”。模型不再是被动接收检索结果而是主动规划检索策略。比如上面那个对比问题模型可以先检索 A 产品的信息再检索 B 产品的信息最后做对比。如果第一次检索结果不理想模型还可以调整查询词重新检索。4.2 查询改写与多轮检索Agentic RAG 最实用的两个能力是查询改写和多轮检索。查询改写是指模型根据对话历史和当前问题生成更适合检索的查询词。用户口语化的提问往往不适合直接做向量检索比如“那个啥就是上次说的那个报销的事”直接拿去检索效果很差但改写成“报销流程和审批权限”之后就好多了。多轮检索是指模型可以根据第一轮检索的结果判断信息是否充分如果不充分就发起第二轮检索。这个能力对于多跳问题特别有用。我在一个技术文档问答项目里用了这个思路用户问“怎么配置 X 功能并验证生效”模型第一轮检索到配置步骤第二轮检索到验证方法最后拼成完整回答。如果只做一轮检索很可能只召回配置步骤漏掉验证部分。4.3 工具调用与外部知识融合Agentic RAG 的另一个价值是工具调用。模型在检索之外还可以调用计算器、数据库查询、API 接口等工具。比如用户问“这个月销售额同比增长多少”模型可以先查数据库拿到两个月的数据再用计算器算增长率最后生成回答。这种能力让 RAG 从“文本问答”扩展到了“任务执行”。不过 Agentic RAG 也有明显的代价延迟更高、成本更高、可控性更差。多轮检索意味着多次模型调用和多次向量检索响应时间可能是传统 RAG 的好几倍。而且模型自主决策意味着行为不完全可预测在需要严格控制的场景下要谨慎使用。我的建议是对简单问题走传统 RAG 快速通道对复杂问题才启用 Agentic 模式这样兼顾效率和能力。5. 分水岭四多模态与富文本处理——图片、表格、扫描件怎么办5.1 RAG 知识库能存图片吗这是热词里出现的一个问题也是实际项目中绕不开的。答案是能存但怎么存、怎么检索、怎么用差别很大。最简单的做法是把图片 OCR 成文字然后当普通文本处理。但 OCR 会丢失图片里的布局信息、图表关系、视觉强调对于流程图、架构图、数据图表这类内容OCR 出来的文字往往支离破碎。更好的做法是多模态 embedding用支持图文联合编码的模型把图片和文本映射到同一个向量空间。检索时可以用文字查图片也可以用图片查文字。比如用户问“那个系统架构图长什么样”系统可以召回对应的架构图。不过多模态 embedding 的模型选择还比较有限效果也参差不齐需要根据具体场景测试。还有一种做法是图片描述生成用视觉模型给每张图片生成一段文字描述把描述和原图一起存起来。检索时匹配描述返回原图。这个做法实现简单效果也还不错适合图片内容相对固定的场景。5.2 表格处理的特殊性表格是富文本里最难处理的一类。一个表格拆成 chunk 之后行和列的对应关系很容易丢失。比如一个产品参数表拆成 chunk 后可能变成“XG-2000A0.5高温2000W”这样一串没有表头的数字检索到了也不知道什么意思。我的处理方式是表格不拆行整表作为一个 chunk同时生成一段表格摘要。摘要里说明这个表格是什么、有哪些列、大概内容是什么。检索时先匹配摘要命中后把整表送给模型。如果表格特别大可以按列拆或者按语义分组拆但一定要保留表头信息。5.3 扫描件与版式还原扫描件是另一个坑。很多企业的历史文档都是扫描的 PDF没有文字层直接抽取只能拿到空白。这时候需要 OCR但普通 OCR 只能拿到文字流丢失版式。对于合同、报表这类版式重要的文档还需要版面分析识别出标题、段落、表格、页眉页脚等区域再分别处理。我在一个合同审查项目里用过一套组合方案先用版面分析模型识别区域表格区域走表格识别文本区域走 OCR最后按阅读顺序拼接。这套流程跑下来抽取质量比直接 OCR 好很多但成本也高需要根据文档价值和数量做权衡。6. 分水岭五评估与迭代——你怎么知道系统变好了还是变坏了6.1 没有评估就没有迭代这是最容易被忽视的一处分水岭。很多团队做完 RAG 系统之后靠“感觉”判断好不好用户说不好就调一调 prompt调完也不知道是真好了还是碰巧。没有系统化的评估迭代就是盲人摸象。RAG 的评估至少要覆盖两个层面检索质量和生成质量。检索质量看召回率、准确率、MRR 等指标生成质量看忠实度有没有胡编、相关性有没有答非所问、完整性有没有漏关键信息。这两个层面要分开评估因为检索不好和生成不好是两回事混在一起看不出问题在哪。6.2 构建评估集的实操方法评估集不需要一开始就很大50 到 100 条高质量的问题-答案对就能看出很多问题。构建方法是从真实用户提问里采样覆盖不同类型的问题单跳、多跳、精确匹配、语义泛化然后人工标注标准答案和应该召回的相关文档。这里有个技巧评估集要包含“负样本”也就是那些知识库里没有答案的问题。很多 RAG 系统的问题是“不知道说不知道”遇到没有答案的问题也硬编一个回答。把这类问题放进评估集能有效暴露这个问题。评估频率上我建议每次改动检索策略、切块策略、prompt 模板之后都跑一遍评估集对比改动前后的指标变化。这样能快速判断改动是正向还是负向避免拍脑袋决策。6.3 线上反馈的收集与利用评估集是离线指标线上反馈是真实信号。我在项目里通常会加两个机制点赞点踩和追问率。点赞点踩直接反映用户满意度追问率高说明第一次回答没解决问题。这两个信号结合起来能定位到具体哪些问题类型表现差。更进一步的做法是记录完整的检索和生成链路包括召回了哪些 chunk、重排后的顺序、最终送给模型的上下文、模型的原始输出。当用户点踩时可以回溯整个链路定位是检索没召回、还是召回但没排好、还是模型没用好。这个日志体系是迭代的基础设施越早建越好。7. 分水岭六工程化与成本控制——从能跑到能扛7.1 延迟优化的几个抓手RAG 系统的延迟主要来自三块检索、重排、生成。检索和重排的延迟相对可控生成是大头尤其是用大模型的时候。优化延迟的几个实用手段一是缓存对高频问题缓存检索结果和生成结果命中缓存直接返回二是并行检索和重排可以并行做多个检索渠道也可以并行三是流式输出让用户先看到部分结果感知延迟降低四是模型分级简单问题用小模型复杂问题才用大模型。我在一个项目里把首字延迟从 3 秒压到了 1 秒以内主要靠的就是缓存加流式。缓存命中率做到 30% 左右整体平均延迟就降了一大截。7.2 成本结构的拆解RAG 的成本主要是向量化成本、存储成本、检索成本、生成成本。向量化是一次性投入文档更新时增量做存储成本相对固定检索成本跟查询量线性相关生成成本跟 token 数线性相关而且大模型和小模型的价格差可能几十倍。控制成本的关键是分级处理。不是所有问题都需要走完整链路简单问题可以走轻量通道复杂问题才走完整链路。另外控制送给模型的上下文长度也很重要召回 20 条和召回 5 条token 消耗差好几倍但效果未必差那么多。我的经验是经过重排之后取 Top 3 到 Top 5 通常就够了再多边际收益很低。7.3 本地化部署的取舍热词里有人问“怎么在 Mac 上搭建 RAG 知识库”这反映了一个真实需求数据敏感场景下本地化部署是刚需。本地化部署的好处是数据不出内网、可控性强、长期成本可能更低代价是效果可能不如云端大模型、运维成本高、硬件投入大。我的建议是分层部署embedding 和 rerank 用本地小模型生成用云端大模型或者本地中等模型敏感数据在本地处理非敏感环节用云端。这样兼顾了数据安全和效果。如果完全不能出内网那就全本地但要对效果有合理预期选型上优先考虑那些在中文场景下表现好的开源模型。8. 几个实操中踩过的坑和对应解法8.1 切块策略没有银弹切块大小、重叠长度、切分方式这些参数没有通用最优解。我试过固定长度切、按段落切、按语义切、按标题层级切每种都有适用场景。固定长度切最简单但最容易切断语义按标题层级切最符合文档结构但依赖文档格式规范语义切效果不错但计算成本高。我的做法是准备几套切块策略根据文档类型自动选择同时保留人工调整的入口。8.2 中文分词的坑中文没有天然空格分词质量直接影响 BM25 检索效果。我试过 jieba、HanLP、以及一些领域词典方案结论是通用分词器在专业领域往往不够用需要补充领域词典。比如医疗领域的“房颤”“心梗”通用分词器可能切成“房”“颤”检索就废了。补充领域词典的工作量不大但收益很明显。8.3 模型幻觉的抑制RAG 的一个核心价值是抑制幻觉但 RAG 本身也会产生幻觉尤其是当召回内容不相关或者不充分的时候。抑制幻觉的几个手段一是在 prompt 里明确要求“只基于给定上下文回答上下文没有就说不知道”二是在生成之后加一层校验用另一个模型检查回答是否忠实于上下文三是降低 temperature减少随机性。这几个手段组合使用能把幻觉率压到可接受范围。8.4 文档更新的处理知识库不是一次建好就完事文档会更新、会新增、会删除。增量更新是个工程问题新文档要切块、向量化、入库修改的文档要找到旧块删除、新块插入删除的文档要清理对应的向量和图谱节点。这个流程要自动化否则维护成本会越来越高。我在项目里通常会做一个文档版本管理每次更新记录变更出问题时可以回滚。9. 常见问题速查问题现象可能原因排查方向解决思路答非所问检索召回不相关检查召回结果与问题的相关度加 Rerank、优化查询改写回答不完整召回片段不全检查是否有多跳需求启用多轮检索、GraphRAG精确信息答错向量检索不擅长精确匹配检查是否涉及型号、编号、数字引入 BM25 混合检索表格数据混乱表格被拆散检查表格切块方式整表存储、生成表格摘要图片内容无法检索图片未处理检查图片是否入库OCR 或图片描述生成响应太慢生成环节耗时检查模型调用和上下文长度缓存、流式、模型分级成本太高上下文过长或模型过大检查 token 消耗控制召回数量、分级处理幻觉严重上下文不充分或 prompt 不当检查召回质量和 prompt加校验层、明确拒答指令10. 关于 DeepWiki 和 wiki 类知识库的一点观察热词里出现了DeepWiki和“wiki 和 rag”的对比这其实指向一个有意思的话题wiki 类知识库和 RAG 知识库的边界在哪里。Wiki 的核心是人工维护的结构化知识页面之间有明确的链接关系适合沉淀稳定、共识性的知识RAG 的核心是自动检索非结构化文本适合处理大量、动态、格式不一的内容。我的观察是这两者不是替代关系而是互补关系。Wiki 可以作为 RAG 的高质量知识源因为 wiki 页面通常结构清晰、内容准确、有明确的主题边界切块和检索的效果都比杂乱文档好。反过来RAG 可以作为 wiki 的补充入口用户不需要知道知识在哪个页面直接提问就能拿到答案。DeepWiki 这类工具的思路我理解是把代码仓库或者文档仓库自动转成可问答的知识库本质上还是 RAG只是针对特定类型的语料做了优化。这类垂直场景的 RAG 往往比通用 RAG 效果好因为语料格式统一、问题类型集中、评估标准明确。如果你在做 RAG 项目不妨先找一个垂直场景做深做透再考虑泛化。11. 我个人的一点经验做了这么多 RAG 项目最大的体会是RAG 的难点从来不在“R”也不在“G”而在中间那个“A”——Augmented也就是怎么把检索到的东西有效地增强到生成里。检索技术已经相对成熟生成模型也在快速进步但“怎么把对的东西在对的时机用对的方式送给模型”这件事依然高度依赖具体场景的打磨。另一个体会是不要追求一步到位。我见过太多项目一开始就想把 GraphRAG、Agentic RAG、多模态全部上齐结果每个都做得半吊子整体效果反而不如一个打磨好的基础 RAG。正确的做法是先把基础流水线跑通、把评估体系建起来然后针对评估暴露出的短板逐个引入对应的技术。每引入一个技术都用评估集验证收益没有收益就果断砍掉。最后一个建议多和真实用户聊。评估集能告诉你系统哪里不好但只有真实用户能告诉你他们真正需要什么。我遇到过用户抱怨“答得太长”也遇到过用户抱怨“答得太短”这些都不是技术指标能反映的但直接影响用户体验。RAG 系统最终是给人用的技术再先进用户不买账就是白搭。
