六款开源RAG产品逆向设计：自研RAG系统通用蓝图

所谓自研RAG，很多团队一上来就写代码，结果一半时间花在处理PDF解析、切分粒度、向量库选型这些已经被别人反复验证过的问题上。我这一年多陆陆续续研究了六款开源RAG产品，从LangChain这种大而全的框架，到QAnything这种为检索而生的垂直方案，逐个拆过它们的源码和设计文档。这篇文章就是想把逆向出来的共同设计规律整理成一套可复用的自研蓝图，给正在做RAG或者准备做RAG的团队一个参考。如果你正卡在“召回不准”“上下文塞不下”“检索链路怎么写才优雅”这些问题上，这篇应该能让你少走很多弯路。

我不打算介绍它们怎么用，因为这些项目文档都很全。我更关注的是，它们作为一套系统，是怎么拆分层、怎么定义数据流、怎么处理“文档进入索引”和“问题检索答案”这两条主链路的。把我们自己的需求映射到这套蓝图上，自研从零到一就变成填格子的事。

1. 为什么我要从开源产品逆向RAG设计

1.1 自研之前先看看别人怎么踩坑

很多人以为RAG难在模型，其实不是。模型你直接调API或者部署一个开源模型就行，真正的工程量全部集中在“文档怎么进、碎片怎么存、命中怎么找、上下文怎么拼”这几件事上。这几件事每一个都是一堆隐藏分支：图片要不要解析、表格要不要还原、多级标题要不要保留、召回结果要不要过滤、重复内容怎么去重。如果你没有踩过这些坑，你很难一次性做对。

开源项目最大的价值就是把这些踩坑的痕迹留在代码里。你看RAGFlow花了那么大力气做深度文档解析，你就知道PDF解析不是简单抽文本；你看Dify把知识库和应用编排拆成两个独立模块，你就知道该让知识库做知识库的事，应用做应用的事。所谓逆向工程，并不需要你去反编译二进制，你把架构清楚了、核心代码读明白了，设计意图自然就浮现出来。

1.2 六款产品的选型逻辑和观察维度

我选这六款产品，不是随便凑数，而是它们分别代表了一类设计流派：

观察维度主要是三条：数据从进入到可检索之间的处理链路；检索时做了几次筛选、每次用什么信号；生成时上下文如何拼接裁剪。这三条线走通，一个RAG系统的骨架就出来了。

2. 六款开源RAG各自藏着哪些“宝藏设计”

2.1 LangChain：框架层的抽象边界与可插拔接口

LangChain对我最大的启发，不是它那几千个集成组件，而是它定义了一套非常清晰的抽象。每个Retriever都接一个统一的接口，不管底层是向量库、图数据库还是搜索引擎；每个DocumentLoader都返回统一的Document对象，不管来源是PDF、网页还是API。这就让“组件可替换”从口号变成了工程现实。

自研的时候最容易犯的错就是把业务逻辑和具体实现焊死。你的代码里到处都是elasticsearch.query()，将来想加一个向量检索就很难受。学LangChain的做法，Retriever只做一件事：接收一个问题，返回一组文档。至于文档从哪个存储里来，用不用混合检索，是不是走了重排序，全部是内部实现。这样你的业务逻辑永远只依赖一个抽象的Retrieve接口。

另一个值得学的是它对“链”的处理。LangChain里的Chain可以嵌套，你可以把“检索”和“生成”视为两个环节，也可以把“改写问题”作为一个前置环节插入。这个思想放在自研里，就是你的RAG流程应该是一条可组合的管道，而不是一坨顺序执行的函数调用。

2.2 LlamaIndex：以文档为中心的索引解构

LlamaIndex虽然也带各种高级功能，但它的设计核心其实特别朴素：你把文档给我，我把它变成索引，供你查询。它定义了一套Node边界的理念，文档会被切成节点，每个节点带上结构信息、元数据，节点之间有关联关系。这一点比LangChain那边更贴近“知识管理”的本质。

自研RAG时，很多人直接把整篇文章切成一堆重叠的500字片段，然后一股脑扔进向量库。这个做法不能说错，但会产生很多问题：一个跨章节的上下文被切断了；标题信息丢了；引用的出处对不上了。LlamaIndex的做法提醒我们，切分不仅仅是按字数切，还要理解文档结构。它能保留层级标题、把表格被当成独立节点、甚至维护节点之间的索引关系。

它的另一个宝藏设计是“索引不是只有向量”。你可以对同一份文档构建多种索引：向量索引用来语义召回，摘要索引用来快速定位，关系索引用来跳转到兄弟节点。查询时你可以组合这些索引结果。这比单纯依赖向量相似度要可靠得多，因为向量只理解“语义像不像”，不理解“结构上哪里关联”。

2.3 Haystack：Pipeline化检索与可观测性

Haystack是那种把“流程”做到极致的框架。你怎么定义检索管道，就怎么在代码里搭积木。它的Pipeline允许你把DocumentStore、Retriever、Ranker等节点串起来，并且每个节点都有输入输出名称。这个设计的妙处在于：管道里的每一步都被显式化了，你可以给同一个管道换掉某个节点，而整个数据流不变。

我曾经按照Haystack的思路把自研检索模块改造成了一个Pipeline：query先过关键词召回，再过向量召回，两个结果分别加权合并，送进重排序，最后截断TopK。每一步都是独立的类，分别实现了run()方法。排查问题的时候非常方便，每一步的中间结果都能单独打印出来看。对比之前那种一坨代码写下来，可观测性提升了不止一个档次。

Haystack还带了完整的评估工具，它内置了一套评测集的处理逻辑，能算出retrieval的Recall@K和生成答案的SAS等指标。这对我们自研时的持续优化特别关键。很多人上线之后只能说“感觉还行”，一旦涉及调参就开始瞎试。有了快照化的中间结果和评测指标，优化就变成了科学实验。

2.4 Dify：应用编排与知识库分离的工程智慧

Dify严格来说不是一个RAG引擎，而是一个LLM应用开发平台。但它的知识库模块设计很值得拆。Dify把“知识库管理”和“对话应用”分成两个独立的功能域：你先在知识库里上传文档、分段、建立索引，然后在应用里引用这个知识库，通过“上下文策略”限制检索行为。这个分离看起来简单，做起来很影响后期维护。

自研RAG时我们很容易把知识库和聊天逻辑写在一个服务里，最后用户上传一个文档触发全链路重灌，代价非常高。Dify告诉我，知识库是一个独立资源，有自己生命周期，它可以被多个应用复用。而且知识库的索引方式是可选的：高质量模式用Embedding，经济模式用关键词，还有一种混合的“上下文检索”模式专门为RAG场景设计。

它的检索参数设置也很有意思，不是让你选“用什么检索器”，而是直接让你调“召回数量”“相似度阈值”“得分权重”，把实现细节隐藏起来。这说明成熟产品考虑的是“用户能理解什么”，而不是“技术能提供什么”。自研时，我们也应该把面向业务的参数收拢成这几个核心旋钮。

2.5 RAGFlow：深度文档解析与版面还原

RAGFlow在开源圈子里火得很真实，因为它解决的是一个被低估的痛点：RAG效果差，很多时候不是LLM不行，是文档解析太粗糙。RAGFlow花了很大力气做布局识别、表格抽取、标题层级还原，把传统PDF、扫描件转成了有结构的Markdown，然后再切片。这一步做对了，后面的检索和生成才会通。

我拿一份扫描版合同试过RAGFlow，它不仅能识别出正文，还能保留标题缩进，甚至把表格完整还原成Markdown表格。后来检索“违约金比例”这种埋藏在表格里的信息，也能准确命中了。这对我影响很大，我自研时就把文档解析单独做成一个模块，接OCR和版面分析模型，而不是简单地用pdftotext抽一下。

它另一个亮点是“基于模板的分段策略”，你可以为不同文档类型定义分段规则，比如一个合同按条款分，一个产品手册按章节分。这个设计很聪明，因为通用切分永远无法适配所有场景，只有规则模板才能真正贴近业务知识结构。在自研蓝图中，我把它拆成了“解析器”和“分段器”两层，解析器负责把文件变成结构化中间格式，分段器负责根据模板切分。

2.6 QAnything：基于推理的召回为什么更好

QAnything是网易有道开源的RAG方案，它有一个明显不同：query和document做了分开的两阶段——第一阶段用embedding做粗召回，第二阶段用一个排序模型把答案从对应段落里再选一遍。表面上看它是个重排序，实际上它把“找段落”和“找答案”拆开了。这种做法对答案出处的准确度提升很大。

QAnything的设计对我最大的启发是它引入了“得分阈值”和“文档相关性”两个维度的校验。自研时我们经常遇到向量得分明明不低，但内容压根不相关。其原因在于embedding模型对细粒度语义不敏感，它擅长找“话题相近”，不擅长找“答案正确”。所以必须加一个更强大的排序模型做二次判断。QAnything用开源的bge-reranker做这事，我照搬到了自己的系统里，效果立竿见影。

它还内置了“无法回答则直接拒绝”的机制。当检索结果都低于置信度阈值时，模型不会硬编答案，而是会提示“暂无相关知识”。这个看似简单的设计，其实守住了一条质量底线，至少比瞎编强得多。我在自研时也把这一条作为硬性要求。

3. 逆向归纳出的自研RAG蓝图

3.1 从六款产品提炼的核心架构分层

综合这六款产品的源码和设计思路，一套可复用的自研RAG蓝图，本质上就是五层结构：

1. 数据接入层：负责格式适配、解析、清洗、分段。
2. 知识索引层：负责生成向量、构建倒排索引、维护门面索引。
3. 检索召回层：负责关键词召回、向量召回、多路合并。
4. 精排与上下文组装层：负责重排序、去重、裁剪、拼接。
5. 生成与输出层：负责提示词构建、LLM调用、输出校验。

每一层之间用明确的接口隔离，层与层之间只传标准化的数据结构。谁要换实现，谁就实现对应接口，不影响上下游。这个分层看起来很普通，但很多自研RAG项目没做到。常见的问题是：解析完的数据直接向量化，检索完的结果直接塞给LLM，中间完全缺少独立处理的环节。

你需要一个贯穿所有层的“文档对象标准”。我强烈建议为文档定义统一的数据类，比如KnowledgeChunk，里面至少包含原始内容、清洗后内容、元数据、标题路径、block类型、hash值这六个字段。六款产品各不相同，但最后都能归到这个数据结构上。

3.2 数据接入层：文件解析与切分的通用方案

数据接入层是整个RAG效果的地基。这个层不要自己做复杂业务，而是定义解析器的接口：输入一个文件流，输出一个标准化的Document列表。每个Document里面包含正文、元数据和结构信息。解析器要按文件类型分开写：PDF、Word、Markdown、HTML，各用各的工具。

解析完成后，先做清洗，这个环节很多人跳过。清洗包括：去掉页眉页脚、过滤脚本标记、修正OCR错别字、统一换行符。如果不做，你的向量库里会存很多垃圾片段，检索时它们还会干扰相似度。亲身踩过的一个坑是HTML转文本后留下了无数导航链接文本，检索“价格”时经常把页面上的其他产品链接搜出来。

分段策略不能一刀切。我建议至少提供“固定长度”和“结构分段”两种模式。结构分段就是根据标题、段落、表格等结构切分，借助版面分析结果或Markdown的heading层级。六款开源产品中，RAGFlow的结构分段做得最深，QAnything和Dify也提供了多种分段模式。你自研时可以起步做“固定长度+重叠窗口”，但一定要预留结构化分段的位置，因为真实知识库的文档结构差异太大，早晚要上。

3.3 检索层：混合检索+重排序，别吝啬粗排

检索层的设计直接决定RAG的上限。很多团队的第一个版本就是“向量召回TopK”，这是底线方案，不是完整方案。我的建议是上混合检索：关键词检索（BM25）和向量检索并行，然后在合并结果里做重排序。

为什么需要混合？因为向量检索擅长语义泛化，但不擅长精确匹配。你说“甲公司2023年报里的净利润”，向量模型很可能把“2023年度报告”和“净利润”两个概念在不同向量空间里匹配，结果召回一堆包含“收入”或“2022年”的片段。关键词检索能精确卡住“2023”“净利润”这些字面信号，互补性很强。

合并策略有三种常见选择：互斥加权、RRF（Reciprocal Rank Fusion）、得分叠加。我在实践中更推荐RRF，它不依赖各路的绝对分数，而是按排名位置加权，避免向量得分与BM25得分量纲不一致导致某一方被淹没。示例公式很简单：对每个候选文档，计算Σ(1/(k+rank_i))，k一般取60。谁在两个列表里都排前面，谁的综合排名就高。

重排序是精排层的核心。粗召回数量可以设为30~50，精排后只保留3~5个片段。重排序模型普遍用交叉编码器，比如bge-reranker-base，一次算一个query-文档对的相关性分数，比双塔embedding精度高很多。自研时可以直接在蓝图中预留这个位置，初期甚至可以用一个简单的规则替代，但接口必须留在那里。

3.4 生成层：上下文组装与提示词模板化

生成层要解决的不是“调用LLM”，而是“怎么把检索到的片段变成LLM能理解的高质量上下文”。首先做去重和裁剪。多路召回经常带回来几乎重复的内容，可以通过hash去重，也可以用语义相似度聚类去重。裁剪是为了避免超过模型的上下文窗口，同时减少噪音。

上下文组装的模板我建议用三段式：系统角色、参考知识和用户问题。参考知识不是把片段堆上去就完了，要给它加编号和来源标记，比如【引用1】，然后在提示词里要求模型回答时带上引用编号。这一步能让模型形成“引用必须来源于给定内容”的强约束，大幅减少幻觉。

保留引用的另一个好处是可以通过后处理校验答案。我习惯在输出环节加一个校验器：检查模型回答中的引用编号是否都存在于输入片段列表中，如果引用了不存在的编号，就自动剔除或重新生成。这个做法来自我对QAnything“无答案拒绝回答”思路的延伸。

提示词模板化也很重要，你不太可能对每个query都手写提示词，但可以用Jinja2或F-string做一个模板系统，把检索片段、用户问题、对话历史填入。模板要支持切换，比如“简洁回答”“详细分析”“仅用引用回答”三种预设，方便调试。

3.5 可观测性与评估：没有测评就没有迭代

如果没有评测体系，你的RAG系统就像一辆没有仪表盘的汽车。开源产品中Haystack和LlamaIndex都内置了评测工具，Dify控制台也有日志，但这些对自研来说还只是参考。我建立了一套最小可观测体系：线上记录每次请求的完整链路日志，包含切分片段数、每路召回的TopK明细、重排序后的得分、最终组装的字数。

然后建一个离线评测集，至少要有100条真实业务问题，每条标注了标准答案和它在源文档中的位置。每次改动索引策略、切分参数或模型后，跑一遍评测集，看Recall@K、MRR、忠实度这三个指标。不需要搞得很复杂，但必须坚持跑。

你还可以做A/B测试，把不同切分粒度或不同重排序模型的流量各分一半，用户反馈“这个问题回答得好不好”作为质量信号。这看起来笨，但长期积累下来，你会发现它比任何理论推导都可靠。

4. 关键实现细节与代码级参考

4.1 embedding模型选型与分块参数配置

embedding模型的选择直接影响召回质量。中文场景下，我目前用下来效果最稳的是BAAI/bge-m3，它支持8000长度输入，生成1024维向量，混合检索下表现不错。如果你的算力比较紧张，用bge-small-zh-v1.5也够用，但语义细粒度会差一点。注意一定不要直接用通用的OpenAI text-embedding来处理中文知识库，成本高且分块长度受限。

分块参数，我最常用的配置参考如下：固定长度500字符、重叠80字符，这个配置在“内容完整度”和“检索颗粒度”之间比较平衡。如果你们的文档是长条款型，分段可以放大到800字符，重叠加到120；如果是短问答型，250字符更合适。没有万能参数，蓝图里应该把这两个参数暴露出来，方便针对数据集做网格搜索。

关于分块是否要带上标题前缀，我强烈建议要。把文档的标题层级路径拼到每个块的开头，比如合同/甲方义务/3.1 付款条件，这样向量检索时上下文信息更充足。LlamaIndex和Dify都有类似的字段设计，这也是我从它们那边学来的。

4.2 向量库+全文索引的融合检索实现

同时用向量库和全文索引，最简单的方式是用Elasticsearch的knn+match查询，或者用Milvus的混合检索接口。但我更推荐在代码层面做“双路召回”，因为这样能自控合并和调参逻辑。下面是一个最小实现骨架：

def hybrid_search(query, top_k=30): # 向量召回 query_vector = embed(query) vector_ids, vector_scores = vector_store.search(query_vector, top_k) # 关键词召回 bm25_hits = es_client.search( index="knowledge", query={"match": {"content": query}}, size=top_k ) # 合并候选集 merged = merge_rrf(vector_ids, bm25_ids) return merged

注意向量库里存的ID要和ES里的文档ID保持一致，这样合并才方便。你还需要存一份chunk_id -> chunk_content的内存映射，方便后续取原文。

如果你不想维护两个存储，也可以只用Milvus或Qdrant，它们现在自带稀疏向量功能，本质上你只用一个数据库就能实现混合检索。我建议自研初期用方案二，减少运维复杂度，但数据规模大了以后，ES的全文检索成熟度还是更高。

4.3 重排序模型的接入与阈值设置

重排序这里，我用FlagEmbedding库配合bge-reranker-base，成本不高，效果提升却很显著。接入流程很简单：加载模型，对每一条(question, doc) pair打分，按得分倒序截断。

实际使用中，我一般在重排序后设置一个相对阈值，比如取最高得分乘以0.6作为最低门槛。低于这个门槛的片段直接丢弃。这个阈值不是拍脑袋定的，而是我跑了200条评测数据，看了“错误召回片段”的得分分布，发现它们基本都低于最高分的55%。不同数据分布阈值需要自己标定，所以蓝图里要把“阈值可配置”作为设计目标。

问一句，重排序模型要不要自己部署？可以用CPU推理，因为检索量不大，业务QPS通常几十几百，跑一个base大小的重排序模型在4核CPU上也能扛得住；如果你并发要求高，换GPU推理更稳。用模型做精排，不求快，求准。

4.4 组件化工程：把蓝图落成代码结构

最后还是要回到代码。蓝图再好，代码里如果没有对应的模块边界，就只是PPT。我推荐一个最小目录结构：

app/ parser/ # 文件解析器 splitter/ # 分段器 indexer/ # 索引写入 retriever/ # 检索器 reranker/ # 重排序 generator/ # 生成器 eval/ # 评测脚本

每个模块都留一个抽象基类和至少一个默认实现。比如retriever下面可以有VectorRetriever、BM25Retriever、HybridRetriever。生成器里要有PromptTemplateLoader和ResponseValidator。

接口定义时要注意一点：每个模块的输入输出尽量用自定义的数据类，而不是裸的dict。裸dict虽然写起来快，但一旦字段名被改，所有下游全部静默出错。我吃过这个亏，很喜欢在网上看到的“类型即文档”的说法，自定义数据类本身就是在写文档。

5. 自研RAG过程中的常见问题与避坑笔记

5.1 召回不准时别急着换模型，先看切分

我踩过的最深的坑是：召回结果老是不准，我怀疑是embedding模型不行，准备全换。但后来把召回结果打印出来才看到，命中的片段只截断在一个句子里，问的是“方案对比”，命中的片段只剩下“方案对比表”这几个字，上下文全丢在上一段了。这就是典型的切分粒度太细，破坏了原文的论述结构。

切分调整优先于模型替换。先看看你的召回片段是不是“半句话”，如果片段内容明显没头没尾，就调大块长度或者减少重叠窗口之间的缝隙。如果片段精度够但相关性差，再考虑换embedding。顺序搞反会浪费大量时间。

5.2 上下文窗口限制下如何取舍知识块

即使模型支持128K，也不可能把30个召回片段全塞进去，因为塞多了反而会干扰答案聚焦。我的取舍逻辑是：在重排序后的Top10里，用“多样性”来进一步筛选。先保留得分最高的1个，然后依次检查下一个片段，如果与已选片段的语义相似度超过0.85，就跳过它，直到凑满5个，最后按文档顺序排好。

这个“按文档顺序”是很多人忽略的细节。从不同文档召回来的片段，强行拼在一起，LLM可能以为是连续的长文，导致逻辑混乱。理想做法是把同一文档的多个片段合并，并插入元信息“该片段来自某文档第几节”。你们的业务如果经常涉及跨文档回答，上下文里一定要拍清楚来源，不然模型很容易把两个不同合同的内容混在一起。

5.3 多路召回结果合并如何避免排序“打架”

当你同时用向量和BM25时，最难受的是两路分数不等价。向量得分是余弦相似度（0~1之间），BM25得分通常是个位数到几十，如果直接相加，BM25会被向量秒杀。很多人会用归一化，但归一化如果按每路独立进行，也会带来问题：单路得分普遍偏高时，容易把低质量的召回顶上。

我建议别直接比绝对分数，用RRF或者“排名加成”。排名是相对位置，抗尺度干扰能力强。RRF虽然简单，却是我经过多轮对比后仍然选择保留的方案。如果你用ES的multimatch，它会内部做归一化，也比较省事，但你就失去了对每路权重的控制。这个自由度对后续调优很重要，别一开始就为了省事把它丢掉。

5.4 开源协议与商用合规给我的提醒

这件事必须放在优先级最高的位置。你逆向工程开源项目的设计思想，不等于你可以直接抄代码然后闭源商用，版权边界必须自己把关。Apache 2.0协议比较友好，MIT更宽松，但GPL系项目的代码复制进自研项目时就要非常谨慎。每个开源项目的源码仓库里都会有LICENSE文件，动手之前一定先看一遍。

我做了一个简单动作：为每个模块顶部注释里写清设计参考来源，同时申请范围内只借鉴API设计和架构分层，不直接引用受传染性许可证约束的代码。如果你们公司有法务团队，尽早让法务参与评估；没有的话，就尽量只读不抄，把“启发”留在文档里。

5.5 一个小技巧：把检索链路做成可视化测试台

这个技巧是我后来才补上的，但作用非常大。我把所有检索中间结果同步到一个简单的FastAPI调试页面上，页面展示了“输入问题–分段数量–向量Top5–BM25Top5–重排序Top3–最终上下文”，每次调完参数直接刷新页面看效果，直观得可怕。这个方法比看日志快很多，也让团队成员更容易参与讨论和提意见。

调试页面不需要很精致，接口返回JSON即可，前端用简单的HTML表格渲染。不过是个很小的投入，却能解决“检索链路黑盒”的问题。只要你的自研蓝图把每一层的结果数据都暴露出来了，这一步几乎是免费的。

我个人在实际操作中的体会是，开源RAG项目从来不是让你白嫖代码的，而是给你看别人怎么想问题的。六款产品逆向下来，最大的收获不是某个具体算法，而是终于知道一个RAG系统应该从哪里切一刀——切分是在为检索定边界，检索是在为生成收数据，而评估是为整个系统兜底。如果你准备自研RAG，我的建议是别急着从第一行代码写起，先拿我这份蓝图对照一下，找到你自己的“第0层”，然后把每个模块做成能独立替换的最小单元。这么做下来，你会发现RAG没有想象中那么玄。