1. 为什么 RAG 值得拆成两条链路来看很多人第一次接触 RAG脑子里浮现的画面是把文档丢进去问一个问题模型就能答出来。这个画面没错但它把中间最关键的工程结构给藏起来了。真正在生产环境里跑过 RAG 的人都知道RAG 从来不是“一个流程”而是两条完全独立的链路一条在用户看不见的地方默默干活叫离线建库另一条在用户按下回车的那一刻才开始跑叫在线查询。这两条链路的节奏、资源消耗、失败模式、优化手段几乎完全不同。离线建库是批处理思维讲究吞吐、稳定、可重跑在线查询是实时服务思维讲究延迟、命中率、并发。把它们混在一起谈就会出现那种“demo 很惊艳、上线就拉胯”的经典翻车现场。我见过太多团队离线阶段随便切一切、随便 embed 一下就完事结果在线查询怎么调都救不回来——因为垃圾进垃圾出检索的上限在离线阶段就已经被钉死了。这篇文章想做的事情很直接把 RAG 拆成离线建库和在线查询两条链路一条一条讲清楚每一步在干什么、为什么这么干、参数怎么定、坑在哪里。核心关键词会自然穿插在各个环节里包括RAG、离线建库、在线查询、Embedding、向量库以及现在讨论度很高的agentic rag、graphrag、ontology rag这些进阶方向。不管你是刚准备搭第一个 RAG 知识库的新手还是已经在调 hit rate 的老手都能从这两条链路的拆解里找到能直接抄作业的东西。先说清楚适合谁看。如果你只是想跑个 demo 玩玩那随便找个框架十分钟就能出结果但如果你要面对的是真实业务文档、要保证回答质量、要控制成本、要能持续更新那这篇文章里的每一步都值得你认真过一遍。因为 RAG 的瓶颈八成不在模型而在你对这两条链路的理解深度。2. 离线建库链路把原始文档变成可检索的知识离线建库这条链路本质上是把人类可读的原始文档转换成机器可检索的数学表示。它不追求快追求的是准、全、稳。这条链路跑一次可能要几分钟到几小时但它决定了整个 RAG 系统的天花板。下面按数据流动的顺序一步步拆。2.1 文档加载与格式解析别小看这一步离线建库的第一步是加载。听起来很简单但真实世界的文档格式能把人逼疯PDF、Word、Markdown、HTML、Excel、PPT、扫描件、甚至聊天记录导出。不同格式的解析质量差异巨大而解析质量直接决定了后面所有环节的效果。PDF 是最典型的坑。很多 PDF 是扫描件本质上是图片直接读文本会得到空白或者乱码。这种情况必须走 OCR而 OCR 的准确率又参差不齐。即便是文本型 PDF双栏排版、表格、页眉页脚、脚注都会干扰解析。我踩过最深的坑是一个双栏排版的学术 PDF解析出来文字顺序全乱左栏和右栏交错在一起embedding 出来的向量自然一塌糊涂。实操上我的建议是按格式分流处理纯文本类Markdown、TXT、HTML直接读HTML 记得去掉标签只留正文。Office 类Word、PPT、Excel用对应的解析库注意表格要单独处理成结构化文本。PDF先判断是文本型还是扫描型文本型用解析库扫描型走 OCR。图片如果知识库里需要存图片要么用多模态 embedding要么先用视觉模型生成图片描述再入库。提示解析完一定要抽样人工检查。我习惯随机抽 10 个文档把解析结果和原文对照重点看表格、列表、代码块有没有被破坏。这一步花十分钟能省掉后面几小时的排查。2.2 文本切分chunk 策略决定检索粒度解析出来的长文本不能直接 embed因为 embedding 模型有输入长度限制而且太长的文本语义会被“平均”掉检索时反而不精准。所以要做切分把长文档切成一个个 chunk。切分策略是离线建库里最需要动脑子的地方。切太碎语义不完整检索出来的片段答非所问切太大一个 chunk 里混了好几个主题向量表示被稀释命中率下降。常见的几种策略固定长度切分按字符数或 token 数硬切简单但容易切断句子和语义。递归切分按段落、句子、标点的层级递归切尽量保持语义完整这是目前最常用的。语义切分用模型判断句子之间的语义相似度在语义转折处切效果好但成本高。结构化切分按文档本身的标题层级切比如 Markdown 按##、###切这种对结构化文档效果最好。我一般用递归切分打底chunk size 定在 500 到 800 个 tokenoverlap 留 10% 到 15%。overlap 的作用是防止关键信息正好卡在切分边界上被切断代价是存储和检索量略微增加。这个参数没有标准答案得拿你自己的文档试。我的经验是技术文档 chunk 可以小一点400-600叙述性文档可以大一点800-1000。还有一个容易被忽略的点给每个 chunk 加上下文元数据。比如它属于哪个文档、哪个章节、前后 chunk 是什么。这些元数据在检索时能帮大忙尤其是做 rerank 或者上下文扩展的时候。2.3 Embedding 模型选型向量质量的地基切好的 chunk 要变成向量这一步靠Embedding模型。Embedding 模型的选择直接决定了向量库里的“语义地图”质量是整条离线链路里最关键的决策之一。选型时主要看几个维度维度说明实操建议语言支持中文、英文、多语言中文场景优先选中文优化过的模型向量维度维度越高表达力越强但存储和计算成本越高768 到 1024 是常见平衡点最大输入长度决定单次能 embed 多长的文本要大于你的 chunk size检索性能在标准榜单上的表现参考 MTEB 等榜单但别迷信部署方式云端 API 还是本地部署数据敏感就本地追求效果可以云端成本按量计费还是固定成本大规模建库要算清楚现在 embedding 模型排行更新很快每隔几个月就有新模型刷榜。但我的建议是别盲目追榜先拿你自己的数据做小规模评测。方法很简单准备 50 到 100 个真实问题每个问题标注好应该命中的文档片段然后对比不同模型的 hit rate。榜单上的第一名在你特定领域里未必是最好的。本地部署的话现在有不少轻量级方案可以跑在自己的机器上配合本地推理框架零基础也能搭起来。数据不出本地对隐私敏感的场景很友好。代价是首次建库速度慢一些但胜在可控。2.4 向量库选型与写入存储与索引的权衡向量算出来了得有地方存。向量库的选择要考虑数据规模、查询延迟、过滤能力、运维成本。小规模场景几万到几十万向量用轻量级的本地向量库就够了甚至用内存索引都能扛。中等规模百万级可以考虑单机版的专用向量库。大规模千万级以上就得上分布式方案考虑分片、副本、一致性这些问题。写入的时候有几个细节要注意批量写入别一条一条写批量提交能大幅提升吞吐。索引构建很多向量库支持不同的索引类型比如扁平索引精确但慢近似索引快但有精度损失。建库阶段可以先用精确索引量大再换近似。元数据一起存文档来源、时间、分类这些元数据要跟向量一起存方便后面做过滤检索。幂等设计建库要能重跑。用文档 ID 做去重重复写入不会产生脏数据。注意向量库不是建完就完事了。文档会更新、会删除你的建库链路要支持增量更新。我见过太多系统文档改了但向量库还是旧的用户问出来的答案全是过时信息。2.5 离线链路的进阶玩法从朴素 RAG 到 GraphRAG基础的离线建库就是“切分-embed-存库”三步。但如果你的知识库里有大量实体和关系比如人物、组织、事件之间的关联朴素 RAG 就力不从心了。这时候可以上graphrag或者ontology rag的思路。GraphRAG 的核心是在离线阶段额外构建一个知识图谱把文档里的实体和关系抽出来建成图结构。查询时不仅做向量检索还沿着图做多跳推理。这样能回答“A 和 B 之间有什么关系”这类需要关联多个文档的问题。代价是离线建库复杂度大幅上升需要实体抽取、关系抽取、图存储这些额外环节。Ontology RAG 更进一步先定义好领域本体概念、属性、关系再按本体去组织知识。适合领域知识结构清晰的场景比如医疗、法律、金融。建库成本高但检索精度和可解释性都更好。我的建议是先用朴素 RAG 跑通遇到明确的关联推理瓶颈再上图谱。别一上来就搞最复杂的架构很多场景朴素 RAG 加好的切分和 rerank 就够了。3. 在线查询链路从用户提问到精准回答离线建库把知识准备好了在线查询链路负责在用户提问的瞬间从海量向量里捞出最相关的内容喂给大模型生成回答。这条链路的核心指标是延迟和命中率两者经常互相拉扯。3.1 查询理解与改写别拿原始问题直接检索用户的问题往往很口语、很模糊、甚至带错别字。直接拿原始问题去检索效果通常不好。所以在线链路的第一步是查询理解与改写。常见的处理包括查询改写把口语化问题改写成更适合检索的形式。比如“那个啥就是上次说的那个部署的事咋弄”改写成“部署步骤是什么”。查询扩展补充同义词、相关概念扩大检索召回。比如“报错”扩展成“错误、异常、失败”。多查询生成让模型从不同角度生成多个查询分别检索后合并结果。这对复杂问题特别有效。意图识别判断用户是想查事实、要步骤、还是做对比不同意图走不同的检索策略。这一步通常用一个小模型或者规则来做成本低但收益明显。我实测下来加了查询改写之后hit rate 能提升 10 到 20 个百分点尤其是口语化提问的场景。3.2 向量检索召回第一道关查询改写完就进入向量检索。把查询文本用同一个 embedding 模型转成向量然后在向量库里找最相似的 top-k 个 chunk。这里有几个关键参数top-k召回多少个候选。太小容易漏太大引入噪声。一般从 10 到 20 起步配合后面的 rerank 用。相似度度量余弦相似度最常用也有用内积或欧氏距离的要和建库时保持一致。过滤条件如果有元数据过滤需求比如只搜某个时间段或某个分类的文档要在检索时带上过滤。向量检索的瓶颈在于它只懂语义相似不懂精确匹配。用户问一个具体的编号、人名、代码向量检索可能召回一堆语义相近但不对的内容。所以生产环境里向量检索通常要和关键词检索配合这就是混合检索。3.3 混合检索与 Rerank把命中率拉上去混合检索的思路是向量检索负责语义召回关键词检索比如 BM25负责精确匹配召回两路结果合并后再排序。这样既能抓住语义相近的内容又不会漏掉精确匹配的关键信息。合并之后通常还要过一道rerank。向量检索用的是双塔模型查询和文档分别编码速度快但精度有限。Rerank 用的是交叉编码器把查询和文档拼在一起过模型精度高但慢。所以典型架构是向量检索召回 top-50rerank 精排出 top-5再喂给大模型。这个“召回-精排”的两阶段结构是提升 hit rate 最有效的手段之一。我做过对比单靠向量检索 hit rate 大概 60% 到 70%加上混合检索和 rerank 之后能到 85% 以上。代价是延迟增加rerank 那一步通常要几十到几百毫秒得根据你的延迟预算来权衡。检索方式优势劣势适用场景纯向量检索语义理解好实现简单精确匹配弱可能漏关键词语义模糊的开放问题纯关键词检索精确匹配强可解释不懂同义词召回有限编号、代码、专有名词混合检索兼顾语义和精确实现复杂需调权重大多数生产场景混合rerank命中率最高延迟增加成本上升对质量要求高的场景3.4 上下文组装与生成把检索结果喂给大模型检索出来的 top-k 个 chunk不能直接一股脑塞给大模型。要做上下文组装去重、排序、截断控制在模型的上下文窗口内。组装时要注意相关性排序最相关的放前面大模型对开头的内容注意力更高。去重不同 chunk 可能有重叠内容去重能省 token。上下文扩展如果 chunk 是切碎的可以把相邻 chunk 一起带上保证语义完整。引用标注给每个 chunk 标上来源方便生成回答时标注引用也方便排查问题。生成阶段prompt 的设计很关键。要明确告诉模型只根据提供的上下文回答上下文里没有的就说不确定别自己编。这能大幅降低幻觉。同时要求模型标注引用来源方便用户核实。3.5 在线链路的进阶Agentic RAG 与多轮检索基础的在线查询是“一问一检索一生成”。但复杂问题往往需要多步推理这时候就轮到agentic rag出场了。Agentic RAG 的核心是让模型自己决定这个问题需不需要检索、检索什么、检索几次、要不要换个查询再试。它把检索变成了一个 agent 可以调用的工具模型根据中间结果动态调整策略。比如用户问“我们去年 Q3 的营收比 Q2 增长了多少”基础 RAG 可能一次检索就答了但 agentic rag 会先检索 Q3 数据再检索 Q2 数据然后做计算。这种多跳能力对复杂业务问题特别有用。代价是延迟和成本都上去了因为要多次调用模型和检索。所以我的建议是简单问题走基础链路复杂问题才触发 agentic 模式。可以先用一个轻量分类器判断问题复杂度再决定走哪条路。4. 两条链路的协同与常见问题排查离线建库和在线查询不是孤立的它们通过 embedding 模型和向量库这两个“接口”耦合在一起。任何一边出问题另一边都会受影响。这一节讲协同要点和排查方法。4.1 两条链路的耦合点模型必须一致最容易翻车的地方是离线建库和在线查询用了不同的 embedding 模型。向量空间都不一样了检索结果自然乱七八糟。这个错误听起来很低级但实际项目里因为版本管理混乱、多人协作、模型升级不同步真的经常发生。所以第一条铁律embedding 模型的版本要锁死建库和查询必须用同一个。如果非要升级模型必须全量重建向量库不能只换查询端。同理切分策略、文本预处理规则这些也要保持一致。查询时的预处理要和建库时对齐比如建库时去了标点查询时也要去。4.2 命中率低的排查思路Hit rate 低是最常见的问题。排查要按链路顺序来别一上来就怀疑模型。先查离线侧文档解析有没有丢内容抽样对比原文。切分有没有把关键信息切断看命中的 chunk 是不是语义不完整。embedding 模型适不适合你的领域拿标注数据测一下。向量库里数据全不全有没有漏写或写错。再查在线侧查询改写有没有把原意改歪top-k 是不是太小把正确结果挤出去了相似度阈值是不是设太高要不要加混合检索和 rerank我一般会做一个“检索日志”把每次查询的改写结果、召回 chunk、相似度分数都记下来。出问题的时候翻日志一眼就能看出是哪一环掉的链子。4.3 常见问题速查表现象可能原因排查方向答非所问检索没召回正确内容查 hit rate看召回 chunk回答过时向量库没更新查增量更新链路回答不完整chunk 切太碎或 top-k 太小调切分和 top-k幻觉严重prompt 没约束好改 prompt要求只依据上下文延迟高rerank 或 agentic 环节太重看各环节耗时做取舍精确问题答不准缺关键词检索加混合检索关联问题答不了缺图谱结构考虑 graphrag4.4 实操心得几个反直觉的经验分享几个我踩坑踩出来的经验可能和直觉相反第一chunk 不是越小越好。很多人觉得切小点检索更精准但切太小语义不完整模型拿到碎片反而答不好。我试过把 chunk 从 500 降到 200hit rate 反而降了。第二top-k 不是越大越好。召回太多噪声rerank 压力大还可能把正确结果淹没。找到那个“边际收益递减”的点就停。第三rerank 不是必须的。如果你的场景查询简单、文档规整向量检索加好的切分就够了。rerank 是给复杂场景兜底的别为了用而用。第四离线建库值得多花时间。在线查询调来调去提升有限但离线阶段把解析、切分、embedding 做扎实效果提升是立竿见影的。我见过太多团队本末倒置在线侧疯狂调参离线侧一塌糊涂。5. 从零搭一个可复现的 RAG 知识库前面讲的是原理和拆解这一节给一个可以直接抄的落地路径。不依赖特定框架讲清楚每一步做什么。5.1 环境与依赖准备先明确技术栈。离线侧需要文档解析库、embedding 模型、向量库。在线侧需要查询处理、检索、rerank、大模型调用。如果追求简单可以用现成的 RAG 框架它们把两条链路都封装好了。但我的建议是至少自己手写一遍基础流程这样才能真正理解每个环节。框架可以后面再用但原理得先懂。本地部署的话现在有轻量级方案可以跑在自己的机器上配合本地推理框架零基础也能搭起来。数据不出本地对隐私敏感的场景很友好。代价是首次建库速度慢一些但胜在可控。5.2 离线建库的可复现步骤按顺序来收集文档把要入库的文档放到一个目录按类型分文件夹。解析写脚本遍历目录按格式调对应解析器输出纯文本加元数据。清洗去页眉页脚、去多余空行、统一标点。切分用递归切分chunk size 600overlap 100。Embedding批量调 embedding 模型得到向量。写入向量库向量加元数据一起写用文档 ID 做幂等。验证抽几个问题测检索看能不能召回正确内容。每一步都建议落盘保存中间结果方便排查和重跑。别搞成一条黑盒流水线出了问题都不知道哪一步坏的。5.3 在线查询的可复现步骤接收查询拿到用户原始问题。查询改写调小模型改写生成 1 到 3 个查询。向量检索每个查询召回 top-20。关键词检索同时跑 BM25召回 top-20。合并去重两路结果合并去重。Rerank精排出 top-5。上下文组装拼成 prompt控制长度。生成调大模型生成回答要求标注引用。返回回答加引用来源一起返回。这套流程跑通之后再根据实际效果调参数。别一开始就追求完美先跑通再优化。5.4 效果评估与持续迭代RAG 系统不是搭完就完事要持续评估和迭代。评估的核心是构建评测集准备一批真实问题和对应的标准答案或标准文档片段定期跑评测看 hit rate 和回答质量的变化。评测集要覆盖不同类型的问题事实查询、步骤查询、对比查询、关联查询。每类问题的表现可能差异很大分开看才能定位问题。迭代的方向无非几个优化切分、换 embedding 模型、调检索参数、加 rerank、改 prompt。每次只改一个变量看效果变化别一次改一堆否则不知道是哪个起的作用。我个人在实际操作中的体会是RAG 的优化是个长期活没有一劳永逸的配置。文档在变、用户在变、模型在更新系统也得跟着调。但只要两条链路的骨架搭对了后面的优化就是在这个骨架上做微调不会推倒重来。最后再分享一个小技巧把每次线上查询的日志存下来定期分析那些回答不好的 case它们就是你下一步优化的方向。