RAG系统拆解：离线建库与在线查询两条链路全流程实战-平芜编程栈

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 个 token，overlap 留 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-50，rerank 精排出 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 环节太重	看各环节耗时，做取舍
精确问题答不准	缺关键词检索	加混合检索
关联问题答不了	缺图谱结构	考虑 graphrag

4.4 实操心得：几个反直觉的经验

分享几个我踩坑踩出来的经验，可能和直觉相反：

第一，chunk 不是越小越好。很多人觉得切小点检索更精准，但切太小语义不完整，模型拿到碎片反而答不好。我试过把 chunk 从 500 降到 200，hit rate 反而降了。

第二，top-k 不是越大越好。召回太多噪声，rerank 压力大，还可能把正确结果淹没。找到那个“边际收益递减”的点就停。

第三，rerank 不是必须的。如果你的场景查询简单、文档规整，向量检索加好的切分就够了。rerank 是给复杂场景兜底的，别为了用而用。

第四，离线建库值得多花时间。在线查询调来调去提升有限，但离线阶段把解析、切分、embedding 做扎实，效果提升是立竿见影的。我见过太多团队本末倒置，在线侧疯狂调参，离线侧一塌糊涂。

5. 从零搭一个可复现的 RAG 知识库

前面讲的是原理和拆解，这一节给一个可以直接抄的落地路径。不依赖特定框架，讲清楚每一步做什么。

5.1 环境与依赖准备

先明确技术栈。离线侧需要：文档解析库、embedding 模型、向量库。在线侧需要：查询处理、检索、rerank、大模型调用。

如果追求简单，可以用现成的 RAG 框架，它们把两条链路都封装好了。但我的建议是：至少自己手写一遍基础流程，这样才能真正理解每个环节。框架可以后面再用，但原理得先懂。

本地部署的话，现在有轻量级方案可以跑在自己的机器上，配合本地推理框架，零基础也能搭起来。数据不出本地，对隐私敏感的场景很友好。代价是首次建库速度慢一些，但胜在可控。

5.2 离线建库的可复现步骤

按顺序来：

收集文档：把要入库的文档放到一个目录，按类型分文件夹。
解析：写脚本遍历目录，按格式调对应解析器，输出纯文本加元数据。
清洗：去页眉页脚、去多余空行、统一标点。
切分：用递归切分，chunk size 600，overlap 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，它们就是你下一步优化的方向。