RAG 这个词从 2023 年火到现在，热度一直没降过。但我在实际项目里观察到一个很普遍的现象：很多团队一上来就自己造轮子，从文档解析、切片、向量化到检索排序全部手写一遍，结果做出来的东西召回率惨不忍睹，用户问三句答错两句。反过来，另一批团队直接拿开源方案套壳上线，跑通了 Demo 却在上量之后发现各种瓶颈——检索命中率上不去、多跳问题答不了、知识库更新一次要重建全量索引。这两种极端我都踩过，所以这篇文章想聊的是一个更务实的思路：把市面上几款成熟的开源 RAG 产品拆开看，逆向理解它们的设计取舍，然后提炼出一套能直接复用到自研项目里的架构蓝图。

这里说的"逆向工程"不是去破解什么，而是把开源项目当成一本活的架构教材，读它的模块划分、数据流走向、关键参数设计，搞清楚每个决策背后的权衡。我会围绕六款有代表性的开源 RAG 实现展开，从它们的共性里抽出可复用的骨架，再结合 agentic rag、graphrag、ontology rag 这些新方向，讲讲自研 RAG 到底该怎么设计才不至于走弯路。不管你是刚接触 rag知识库 的新手，还是已经在做 rag项目 的老手，这套拆解思路应该都能给你一些参考。

1. 为什么自研 RAG 之前必须先读懂开源实现

1.1 自研 RAG 最常见的三种翻车方式

我先说说我见过最多的翻车场景。第一种是"切片迷信"，团队觉得只要把文档切得足够细，检索就一定准。结果切出来的 chunk 全是断句残片，一个完整的业务规则被切成三段，检索时只召回其中一段，LLM 拿到半截信息就开始编。第二种是"向量万能论"，认为 embedding 模型选个大的就万事大吉，完全忽略关键词检索、元数据过滤、重排序这些环节，遇到专有名词、编号、代码符号这类语义向量表达很差的查询就直接歇菜。第三种是"一次性架构"，知识库建好之后不做增量更新设计，每次文档变更就全量重建索引，数据量一上来重建时间从几分钟涨到几小时，运维直接崩溃。

这三种问题的根源其实是一样的：把 RAG 当成了一个"向量检索 + 拼 prompt"的简单管道，而没有把它当成一个有多个可调环节的系统工程。开源 RAG 产品之所以值得研究，正是因为它们在真实场景里被反复打磨过，每个模块的设计都对应着某类具体问题的解法。

1.2 开源实现是"已经被验证过的设计决策集合"

我习惯把开源 RAG 项目理解成一组"设计决策的集合"。比如某个项目选择在检索后加一层 cross-encoder 重排序，这背后是它发现纯向量召回在 Top-K 里混入了太多语义相近但实际不相关的结果；另一个项目选择用父子文档结构（parent-child chunk），是因为它发现小块检索准但上下文不足，大块上下文全但检索不准，于是用小块定位、大块喂给 LLM。这些决策不是拍脑袋来的，是踩过坑之后收敛出来的。

你直接读这些决策，等于跳过了别人踩坑的过程。这就是逆向工程的价值——不是抄代码，而是抄思路。下面这张表是我梳理的几类开源 RAG 在核心环节上的典型取舍，先建立一个全局印象：

看懂这张表，你就明白自研 RAG 不是"选一个最好的方案"，而是"根据你的场景选一组匹配的决策"。

1.3 逆向工程的正确姿势：看数据流而不是看代码

很多人读开源项目喜欢一头扎进源码，结果被各种抽象层绕晕。我的建议是先画数据流：一份原始文档从进系统到被检索出来，中间经过了哪些转换，每一步的输入输出是什么形态。数据流清楚了，再看代码就是验证细节。

具体来说，我会关注四个问题：文档进来后怎么解析和清洗？切片策略是什么，有没有重叠？向量化和索引是怎么组织的，有没有额外的元数据？查询进来后走了哪几条检索路径，最后怎么融合和排序？把这四个问题在六款产品里各回答一遍，共性自然就浮出来了。接下来的章节，我就按这个思路逐层拆解。

2. 六款开源 RAG 的模块拆解与共性提炼

2.1 文档解析层：清洗质量决定了 RAG 的上限

我先说一个容易被低估的结论：RAG 的效果上限在文档解析阶段就基本定死了。你后面检索算法再花哨，如果解析出来的文本里混着页眉页脚、乱码、表格错位，检索质量一定好不了。我拆过的几款开源实现，在解析层普遍做了三件事：格式归一化、噪声过滤、结构保留。

格式归一化是把 PDF、Word、HTML、Markdown 统一转成纯文本或结构化文本。这里有个细节，PDF 解析是最麻烦的，因为 PDF 本质是排版指令而不是语义结构，同一段文字可能被拆成多个文本块。成熟实现通常会结合布局分析，把同一栏、同一段落的文本重新聚合。噪声过滤则是去掉页码、水印、重复的页眉页脚，这一步看似简单，但漏掉的话会在向量库里制造大量"高频噪声向量"，检索时反复被召回。

结构保留是我最看重的一点。好的解析会保留标题层级、列表结构、表格边界，因为这些结构信息在切片时能派上大用场——按标题切比按固定长度切语义完整度高得多。我在自己的项目里就吃过亏，早期用固定长度切片，一份产品手册被切得七零八落，后来改成按 Markdown 标题层级切，召回准确率肉眼可见地提升。

2.2 切片策略：固定长度、语义切分与父子块的三代演进

切片是 RAG 里最容易被轻视、又最影响效果的环节。我把开源实现里的切片策略大致分成三代。

第一代是固定长度切片，按 token 数或字符数硬切，通常带一点重叠（overlap）。优点是实现简单、速度快，缺点是经常切断语义单元。重叠是为了缓解切断问题，但重叠比例不好调，太小没用，太大又造成冗余检索。

第二代是语义切分，按段落、句子边界、标题层级来切，尽量保证每个 chunk 是一个完整的语义单元。实现上一般用递归字符分割器，按优先级依次尝试用段落符、换行、句号来切。这一代明显比第一代好，但对结构不规整的文档（比如扫描件转出来的文本）效果有限。

第三代是父子块结构，这也是我在多个成熟实现里反复看到的设计。核心思路是：用小块（child）做检索，因为小块语义聚焦、向量表达准；命中之后返回它所属的大块（parent）给 LLM，因为大块上下文完整。这样既解决了小块上下文不足的问题，又避免了直接用大块检索不准的问题。实现上需要维护 child 到 parent 的映射关系，检索时先查 child，再回溯 parent。

提示：父子块结构在文档层级清晰（有章节结构）的场景下收益最大，如果文档本身就是零散短文本，收益有限，不必强行套用。

2.3 检索层：从单路向量到混合检索加重的组合拳

检索层的演进最能体现"单一方案不够用"这个道理。早期实现基本是纯向量检索，把 query 向量化后在向量库里做近似最近邻搜索。这套在语义相似查询上表现不错，但遇到三类查询就拉胯：专有名词（比如产品型号、人名）、精确编号（比如条款号、错误码）、短查询（几个词的 query 向量表达信息量太少）。

所以成熟实现普遍上了混合检索：向量检索 + 关键词检索（BM25 或类似算法）并行跑，然后融合结果。融合方式常见的有两种，一种是加权求和，给两路结果各分配权重；另一种是 RRF（Reciprocal Rank Fusion，倒数排名融合），按排名而不是分数来融合，好处是不用关心两路分数尺度不一致的问题。我在项目里更倾向 RRF，因为它对分数归一化不敏感，调参负担小。

混合检索之后通常还有一层重排序。向量检索和 BM25 都是"粗排"，召回 Top-50 甚至 Top-100，然后用 cross-encoder 这类精排模型对 query 和每个候选做联合编码打分，取 Top-5 到 Top-10 喂给 LLM。重排序的代价是延迟增加，但对准确率的提升非常明显，尤其是候选里噪声多的时候。我的经验是，只要你的知识库超过几千个 chunk，重排序这一层就值得加。

2.4 生成层：上下文组织与提示词工程的细节

到了生成层，很多人以为就是把检索结果拼一拼丢给 LLM，其实细节很多。我拆解下来，成熟实现在这一层主要做三件事：上下文去重与压缩、引用标注、提示词结构化。

上下文去重是因为混合检索可能召回内容高度重叠的 chunk，直接拼进去既浪费 token 又干扰 LLM。压缩则是把长 chunk 里和 query 无关的部分裁掉，只保留相关句子。引用标注是给每个上下文片段编号，要求 LLM 在回答时标注引用了哪一段，这样既方便溯源，也能抑制幻觉——LLM 知道自己的话要被核对，编造的概率会降低。

提示词结构化指的是把系统指令、上下文、用户问题、输出格式要求分区块组织，而不是揉成一段。我实测下来，结构化的提示词在复杂问题上表现更稳定，尤其是要求 LLM"如果上下文里没有答案就明确说不知道"这类约束，放在独立区块里比混在段落里更容易被遵守。

2.5 六款实现的共性骨架

把上面几层拆完，六款开源 RAG 的共性骨架就清晰了。它们无一例外都包含这几个模块：文档解析与清洗、切片与索引、多路检索、结果融合与重排、上下文组织、生成与引用。差异主要在每层的具体实现和参数选择上，但骨架高度一致。

这个共性本身就很有价值——它说明 RAG 的架构已经收敛了，你不需要再从头探索"RAG 应该长什么样"，而是应该把精力放在"每一层怎么针对我的场景调优"。下面这张表是我提炼的骨架与各层关键决策点：

3. 从开源实现到自研蓝图：可复用的架构设计

3.1 自研 RAG 的模块划分与接口约定

理解了共性骨架，自研蓝图就有了地基。我的建议是把系统拆成六个独立模块，模块之间用清晰的接口约定通信，这样任何一层想换实现都不影响其他层。这六个模块是：解析器（Parser）、切片器（Chunker）、索引器（Indexer）、检索器（Retriever）、重排器（Ranker）、生成器（Generator）。

接口约定上，我习惯让每个模块的输入输出都是结构化对象，而不是裸字符串。比如切片器的输出不是一串文本，而是带元数据的 chunk 对象，包含内容、来源文档 ID、位置、层级路径等字段。这样检索器在召回时可以带上元数据做过滤，生成器在组织上下文时也能利用层级信息。很多自研项目后期难扩展，就是因为早期接口设计太随意，全是字符串传来传去，想加个元数据过滤发现整条链路都要改。

3.2 索引层设计：向量库选型与元数据字段规划

索引层是自研 RAG 的地基，选型和字段规划要想清楚。向量库选型上，我的经验是小规模（十万级 chunk 以内）用轻量方案就够，部署简单、运维成本低；上了百万级再考虑分布式方案。不要一上来就追求"能扛亿级"的方案，那是给自己找麻烦。

元数据字段规划是我特别想强调的。除了向量本身，每个 chunk 至少要存这些字段：来源文档 ID、文档标题、chunk 在文档中的位置、所属章节路径、创建时间、文档版本。这些字段在检索时能做过滤（比如"只搜某个产品线的文档"），在生成时能做引用标注，在更新时能做增量替换。我见过太多项目只存了向量和文本，后期想加过滤功能发现要重建整个库。

3.3 检索层设计：多路召回与融合排序的落地

检索层的落地我建议分三步走。第一步先上向量检索，把基础链路跑通，确认 embedding 模型在你的语料上表现正常。第二步加关键词检索，用 BM25 或数据库自带的全文检索能力，和向量检索并行跑。第三步加融合和重排，融合用 RRF，重排用 cross-encoder。

这里有个实操细节：多路召回时，每路的 Top-K 要设得比最终需要的多。比如你最终想给 LLM 喂 5 个 chunk，那每路召回至少取 20 到 30 个，融合重排后再截取 Top-5。因为融合和重排的作用就是从更大的候选池里挑出真正相关的，候选池太小，好结果根本没进来，重排也无能为力。

3.4 生成层设计：上下文窗口管理与引用溯源

生成层的核心是上下文窗口管理。LLM 的上下文长度是有限的，你不能把所有召回结果都塞进去。我的做法是给上下文分配一个 token 预算，比如总预算的 60% 给上下文，剩下留给系统提示词、用户问题和输出。然后按重排分数从高到低填充，填满为止。

引用溯源我强烈建议做。实现方式是在每个上下文片段前加编号，提示词里要求 LLM 引用编号。这样用户看到回答后能点开编号核对原文，信任度会高很多。而且这个机制对抑制幻觉有实际作用，我在项目里对比过，加了引用要求之后，LLM 编造不存在信息的比例明显下降。

4. 进阶方向：Agentic RAG、GraphRAG 与 Ontology RAG 的取舍

4.1 Agentic RAG：让检索变成可决策的动作

基础 RAG 是"一次检索一次生成"的固定流程，Agentic RAG 则把检索变成 LLM 可以自主决策的动作。简单说，LLM 拿到问题后，可以决定要不要检索、检索什么、检索几次、要不要换个 query 再检一次。这对多跳问题特别有用——一个问题需要先查 A 再根据 A 的结果查 B，固定流程做不到，Agentic 流程可以。

但 Agentic RAG 的代价是延迟和成本上升，因为多了 LLM 的决策轮次。我的建议是不要一上来就上 Agentic，先把基础 RAG 的检索质量做扎实，确认是"检索不到"而不是"检索到了但没用好"之后，再考虑引入 Agent 决策。很多团队的问题是基础检索就没做好，上 Agentic 只是把问题掩盖了。

4.2 GraphRAG：当问题需要跨文档关联推理

GraphRAG 解决的是另一类问题：答案不在单个文档里，而需要跨多个文档做关联推理。它的做法是先构建实体和关系的图谱，检索时不仅召回文本块，还召回相关的实体和关系路径。比如问"某产品的某个功能依赖哪些上游组件"，答案可能散落在产品文档、架构文档、依赖清单里，GraphRAG 能把这些关联起来。

GraphRAG 的构建成本明显高于基础 RAG，因为要做实体抽取和关系构建。我的经验是，只有当你的业务问题确实存在大量跨文档关联需求时，才值得投入。如果大部分问题都是单文档事实问答，GraphRAG 是杀鸡用牛刀。

4.3 Ontology RAG：用本体约束知识的组织方式

Ontology RAG 是在 GraphRAG 基础上更进一步，引入本体（ontology）来约束实体类型和关系类型。好处是知识组织更规范，检索时的推理路径更可控。代价是前期需要设计本体，这对领域知识要求很高。我目前只在少数领域知识高度结构化的场景见过成功案例，通用场景下投入产出比一般。

4.4 三种进阶方案的选型对照

我的选型原则很简单：能用基础 RAG 解决的，绝不上升级方案。升级方案不是不好，而是成本和收益要匹配。先把基础 RAG 的检索命中率（rag hit rate）做上去，再根据实际解决不了的问题类型，有针对性地引入进阶方案。

5. 自研 RAG 落地中的实测经验与避坑清单

5.1 检索命中率上不去的排查顺序

检索命中率低是最常见的问题，我总结了一套排查顺序，按这个顺序走基本能定位到原因。第一步查解析质量，把召回失败的 query 对应的原文找出来，看解析出来的文本是不是残缺或错乱。第二步查切片，看正确答案所在的 chunk 是不是被切碎了，或者和无关内容混在一起。第三步查 embedding 模型，用几个典型 query 手动算一下和正确 chunk 的相似度，看是不是模型本身在这个领域表现差。第四步查检索策略，看是不是纯向量检索搞不定专有名词，需要加关键词检索。第五步查重排，看正确结果是不是召回了但被排到后面去了。

这个顺序是从上游到下游，因为上游的问题会掩盖下游的问题。我见过太多人一上来就调检索参数，结果根因在解析层，怎么调都没用。

5.2 知识库增量更新的工程细节

增量更新是自研 RAG 必须提前设计的。核心是给每个 chunk 打上来源文档 ID 和版本号，文档更新时先按文档 ID 删掉旧 chunk，再插入新 chunk。这里有个坑：如果切片策略变了，旧 chunk 和新 chunk 的边界不一致，删除时要按文档 ID 全删，不能按 chunk ID 删。所以文档 ID 这个字段一定要在索引时就存好。

另一个细节是更新时的并发问题。如果更新过程中有查询进来，可能查到一半旧一半新的状态。我的做法是给索引加版本，查询时锁定一个版本，更新完成后切换版本，避免读到中间状态。

5.3 几个我踩过的具体坑

第一个坑是 embedding 模型和向量库的维度不匹配。换 embedding 模型时忘了同步改向量库的维度配置，结果写入报错或者检索结果全乱。换模型一定要重建索引，没有捷径。

第二个坑是 chunk 重叠比例设得太大。早期我为了"保险"把重叠设到 50%，结果同一个内容被召回好几次，上下文里全是重复信息，LLM 反而被干扰。后来降到 10% 到 15%，效果好很多。

第三个坑是忽略了 query 改写。用户的问题往往口语化、有指代，直接拿去检索效果差。加一层 query 改写（把口语化问题改写成适合检索的形式，或者补全指代），命中率提升很明显。这一步可以用小模型做，成本不高。

5.4 上线前的自检清单

上线前我会跑一遍这个清单：解析层，随机抽 20 个文档看解析结果是否干净；切片层，抽 10 个 chunk 看语义是否完整；检索层，准备 30 个典型问题看 Top-5 召回率；生成层，看回答是否有引用、是否会在无答案时明确说不知道；更新层，模拟一次文档更新看增量是否生效；性能层，测一下 P95 延迟是否可接受。这个清单跑完，基本能覆盖大部分上线后会暴露的问题。

6. 关于自研 RAG 的一些个人体会

做 RAG 这几年，我最大的体会是：RAG 的难点从来不在"能不能跑通"，而在"跑通之后效果能不能稳住"。Demo 阶段随便一套方案都能出结果，但上量之后，解析的噪声、切片的边界、检索的召回、生成的幻觉，每一个环节都会放大。开源 RAG 给我的最大启发不是某个具体技术，而是它们对每个环节的认真程度——它们把每个环节都当成一个需要单独优化的子系统，而不是一个可以糊弄过去的步骤。

所以如果你正在做自研 RAG，我的建议是先把骨架搭对，六个模块接口清晰，然后一个环节一个环节地打磨，用真实问题去测，别用"看起来能跑"来验收。检索命中率这个指标要持续盯，它是 RAG 效果最直接的晴雨表。至于 Agentic、GraphRAG 这些进阶方向，等基础扎实了再按需引入，不要为了技术新颖而堆砌。

最后分享一个我一直在用的小技巧：建一个"bad case 库"，把每次回答错误的问题和对应的检索结果存下来，定期复盘。你会发现很多问题不是随机的，而是集中在某几类文档、某几种查询上。针对性地修这几类，比盲目调参有效得多。这个库积累到几十上百条的时候，你对自家 RAG 的短板会看得非常清楚。