做了几年RAG项目，从早期拿开源框架拼demo，到后来给企业做私有化知识库，最大的体会是：RAG看起来简单，做到生产可用很难。检索精度、解析质量、响应延迟、可维护性，每一个环节都会在真实场景里给你找麻烦。去年我在启动自研RAG引擎之前，做了一件很笨但收获极大的事——把市面上六款代表性的开源RAG产品逐个拆了一遍，读源码、跑测试、看它们的架构演进思路。这篇内容就是那次逆向工程的完整记录，也是我最终沉淀出的一套可复用自研蓝图。
不管你处于哪个阶段，只要你在做知识库问答、智能客服、企业搜索这类需要对接私有知识的系统，这篇文章都值得读完。我会把六款产品逐一拆给你看，每款的启发点是什么，最后落到一张可以直接照着搭建的自研架构图上。
1. 为什么自研之前要先做逆向工程
先说动机。市面上RAG框架多如牛毛，LangChain、LlamaIndex、Haystack、Qdrant、RAGFlow、GraphRAG，功能各有侧重，有的偏编排、有的偏存储、有的偏应用。按理说直接用就好，为什么还要自研？
我遇到的典型困境是：项目做到中后期，需要深度的定制化。比如客户要求表格抽取后保持行列关系，要求图片OCR结果参与召回，要求权限体系精确到文档段落级别。开源框架在这些点上要么不支持，要么改动成本远超自建。但完全从零开始写，又容易踩别人已经填过的坑。逆向工程的价值就在这里：它不是抄代码，而是把每款产品的设计意图提炼出来，变成自己的选型和架构依据。
我给自己定了个拆解框架，每看一款产品都从四个维度入手：
- 解决什么核心问题：这款产品想解决RAG链路里的哪一段痛点？
- 架构上哪层做得深：数据接入、索引构建、检索召回、重排序、生成融合、评估迭代，哪一层设计得最扎实？
- 工程上的取舍：为了性能、扩展性或易用性，它放弃了什么？
- 哪些能搬来自用：哪些设计可以直接借鉴到自研架构里，不需要重新发明轮子。
带着这四个问题去看源码，你会发现自己看的不是代码，而是作者团队踩过的坑。下面进入正题，逐一拆解。
2. 六款开源RAG产品的拆解重点
2.1 LangChain：链路抽象，但不是全部答案
LangChain是很多人的RAG入门框架。拆它的源码最大的收获不是某个具体组件，而是它如何抽象RAG链路。LangChain把整个流程拆成Loader、Splitter、Embedding、VectorStore、Retriever、LLM、OutputParser几个环节，每个环节都是可替换的接口。这种设计让团队可以快速搭出原型，再逐步替换自己实现的模块。
但拆底层会发现，LangChain对RAG的封装深度是有限的。它的Retriever默认逻辑就是取top-k，对相关性打分、混合召回、结果重排这些进阶需求，几乎都留给开发者自己扩展。换句话说，LangChain提供了流水线的骨架，但它默认场景是“接一个开箱即用的向量检索”，检索质量的上限取决于你选的向量库和Embedding模型。
我的结论是：自研RAG时，LangChain的组件化思想值得借鉴，但不要指望它解决检索效果问题。它会放大你对向量库能力的依赖，而向量相似度本身并不等同于语义相关性。所以拆完LangChain后，我把重点放到了检索层的产品上，比如Qdrant。
2.2 LlamaIndex：索引层的极客派
如果说LangChain是通用编排，LlamaIndex则直接把重点放在索引上。拆LlamaIndex源码时，最值得看的是它的文档拆分策略和索引结构设计。大多数框架用固定chunk size切文档，上一刀和下一刀之间的语义被切断了。LlamaIndex支持树索引、关键词索引、知识图谱索引等多种结构，每一种索引对应不同的数据形态和查询模式。
它里面有个设计思路很打动我：文档不是“切完就完”，而是建立一个二级结构。每个chunk之上有摘要节点，检索时先匹配摘要层，再根据摘要命中的路径取回具体的叶子节点。这相当于给向量检索加了一层“目录”，能有效解决大文档切片后上下文割裂的问题。
这个思路在实际项目里非常实用。比如你有一本300页的技术手册，按500字符切片会有几百个块。问题来了：用户问一个概念，这个词可能出现在多页中，向量相似度最高的块并不一定包含完整答案。LlamaIndex的摘要树结构让检索先命中“那一章”，再在章节内部找具体片段，命中率能明显提升。自研时我在文档预处理模块里加入了类似的“章节摘要索引”，效果不错。
2.3 Haystack：生产级Pipeline和评估思维
Haystack是我特别欣赏的一款产品，它把一个成熟搜索系统的工程素养带进了RAG。拆它的源码，最大的收获在于两点：Pipeline的严格设计和评估闭环。
Haystack的Pipeline不是简单的前后调用，而是有输入输出约束的DAG，每个节点声明自己的输入要求，管道的组装在运行时就能发现问题。这个设计对生产环境的维护太重要了——你换一个Embedding模型，不会等到上线后才发现某个组件接不上。
更难得的是，Haystack内置了Pipeline评估能力。它提供了一套评测节点，你可以准备一批“问题-文档-标准答案”三元组，跑完Pipeline后直接计算检索命中率、答案准确率和延迟指标。拆完后我意识到，之前很多项目RAG效果调不好，不是模型不行，而是根本没有一个可量化的回归评估体系。改动一个参数，好不好全靠肉眼感觉。自研蓝图里，我把评估管线作为第一优先级加进去，没有评估体系的RAG项目就是盲人摸象。
2.4 Qdrant：向量存储与混合检索的工程范本
如果只允许我选一款深度拆解的源码，我选Qdrant。它是Rust实现的向量数据库，性能好且有更厚的设计细节。Qdrant的过滤器机制尤其值得研究：把向量相似度检索和结构化条件过滤放在同一查询里执行，比如“找语义相似的文档，同时满足source='合同' AND date>='2024-01-01'”。这意味着知识库的权限过滤、时间过滤、类型过滤都可以在检索阶段完成，而不是先向量召回再内存过滤。
Qdrant的混合检索（BM25 + 向量）也做得扎实。实际场景里，纯向量检索对专有名词、编号、型号这类精确匹配很弱。比如用户输入“CVE-2024-12345”，Embedding之后语义匹配几乎找不到精确对应项，但BM25可以按词项精确命中。混合检索本质上是在“懂语义”和“认字面”之间做平衡，Qdrant把这两路召回放在一套查询体系里并支持RRF（Reciprocal Rank Fusion）融合排序。
自研检索模块时，我参照Qdrant的设计，把向量检索和倒排索引做成两条并行的召回通道，再用RRF做结果融合。这里有个细节：RRF的k值对结果影响很大，实践下来k=60比较稳，能兼顾两类得分的量纲差异。另外，Qdrant对payload索引的取舍也值得学，它允许你只对过滤频繁的字段建索引，避免每个元数据字段都拖累写入性能。
2.5 RAGFlow：文档解析的深水区
RAGFlow是目前开源社区讨论度很高的RAG应用层项目，它的深度文档解析能力正好回应用户的一个常见疑问：“RAG知识库能存储图片吗？”答案是能，但存储只是第一步，关键是让图片信息参与检索。RAGFlow采用DeepDoc工具把PDF、Word、PPT中的文本、表格、图片识别后重新布局，OCR识别图片里的文字，表格被还原成结构化格式。这样问“去年三季度的销售数据是多少”，即使答案在报表图片里也能被召回。
拆RAGFlow源码给我的冲击在于：大部分自研RAG项目把80%精力放在模型和检索上，却把文档解析当成了一个“调用现成库”的步骤。这是一个巨大的误区。我实际测试过，用PyMuPDF直接抽文本，和经过版面分析后的抽取结果，在后续检索命中率上能差20个百分点。文档解析是整个RAG链路上最容易决定成败、最容易被低估的环节。
自研时我把文档解析独立成一个服务，按文档类型拆分处理：PDF走版面分析+OCR，表格走结构识别，扫描件走图像增强+OCR。每种文档的处理结果都以统一的Markdown结构输出，保留标题层级、表格关系、图片位置。这个“清洗层”在RAG架构里可能不性感，但它是决定知识库能不能真正好用的地基。
2.6 GraphRAG：把“关系”纳入知识底座
最后拆的是微软开源的GraphRAG和它的轻量化变体LightRAG。它们的核心创新是：在文档切块向量化的同时，额外构建一层知识图谱，把实体、关系和社区结构抽取出来。
传统RAG面对“某系统的某个模块改了版本后，对另一个依赖它的模块有什么影响”这类问题，往往答不准，因为答案不是落在单独某段文字里，而是分布在多篇文档的关联关系中。向量检索按相似度匹配，很难跨文档把这种“关系链路”串起来。GraphRAG先做实体识别和关系抽取，再用Leiden算法做社区检测，把相关知识聚成主题社区，查询时既可以走向量召回，也可以走图遍历，或者先把社区摘要生成好，再按社区检索。
这个思路启发了我对“RAG知识库和结构知识库区别”的理解。传统知识库（比如基于知识图谱的KG）强在精准关系和推理，弱在非结构化文本的覆盖；RAG知识库强在全文本检索，弱在对隐式关系的理解。GraphRAG的价值在于把两者的优势结合起来。但拆源码后我也客观评估了它的成本：实体抽取非常消耗Token和时间，普通配置下文档入库速度远低于纯向量方案。所以我的判断是，GraphRAG的图谱层适合用在小体量的精品知识域，比如企业核心产品文档、架构说明文档，不适合一上来就把所有文档无脑跑图抽取。
3. 从六款产品提炼出的自研RAG通用蓝图
六款产品拆完，我画出了一套自己的RAG参考架构。它不追求大而全，而是聚焦生产可用性，用模块化的方式组织。
整体分为五层：接入层、解析层、索引层、检索层、生成层，外加一条贯穿始终的评估链路。
| 层级 | 核心职责 | 从哪款产品获得启发 |
|---|---|---|
| 接入层 | 对接多数据源：本地文件、Web页面、数据库、API同步 | LangChain的数据源抽象 |
| 解析层 | 文本抽取、OCR、版面还原、表格识别、章节树构建 | RAGFlow的DeepDoc思路 |
| 索引层 | 切片、向量化、倒排索引、知识图谱索引、摘要索引 | LlamaIndex的索引多样性 |
| 检索层 | 向量召回、BM25召回、混合融合、过滤、重排序 | Qdrant的混合检索与payload过滤 |
| 生成层 | Prompt组装、上下文压缩、引用溯源、答案生成 | Haystack的Pipeline约束 |
| 评估层 | 回归数据集、指标计算、失败案例分析 | Haystack的评估器设计 |
接入层对应LangChain的可插拔数据源设计，解析层对应RAGFlow的深度解析思路，索引层混合了LlamaIndex的摘要树和GraphRAG的图谱抽取，检索层基本就是Qdrant的混合检索设计思路，生成层参考Haystack的组件约束和可测试性。
自研RAG的冰山在水面下。水面之上是“查文档、找内容、生成回答”的体验；水面下是接入、解析、索引、检索、重排、评估一整条链路。很多团队只盯着模型效果，忽略了工程链路的设计，结果demo很惊艳，上线即翻车。
4. 落地自研RAG的关键实施路径
4.1 分阶段建设路线
明确了蓝图之后，我建议分四个阶段落地，每阶段都有明确的交付物，避免一上来就铺大摊子。
第一阶段：单机可用的最小闭环。目标是用最小成本打通“文档上传→解析→切片→向量化→检索→生成”。技术栈上，解析用Unstructured或自研的版面分析脚本，向量库先用轻量的Chroma或LanceDB，模型用开源的BGE或GTE系列Embedding，LLM用qwen或glm的API。这一阶段别追求完美，先让链路跑起来，能在测试集上达到60分。
第二阶段：检索增强与质量优化。接入BM25混合召回、RRF融合、交叉编码器重排序，建立回归评估集，用评估指标指导优化。这个阶段的关键是积累一个领域评测集。我的建议是准备100到300条真实用户问题，每条标注对应的正确答案和出处文档，每轮改动后全量回归，用召回率、命中率、忠实度三个指标来判断改动方向。
第三阶段：多元化索引与元数据管理。在向量检索之外增加摘要索引、知识图谱索引，根据文档类型和查询类型路由不同的检索路径。同时完善权限体系，把用户、角色、部门的过滤条件下沉到检索层。
第四阶段：可观测性与持续迭代。记录每次查询的检索链、命中的文档、相似度得分、生成内容、用户反馈，建立可回溯的链路日志。这一步决定了系统能否持续变好。
4.2 技术选型与配置参考
自研不一定什么都要自己写，组件选型很关键。下面给出我实测过的一套组合，稳定性不错：
- 文档解析：PyMuPDF处理文本类PDF，PaddleOCR处理扫描件，Camelot处理表格类PDF
- 切片策略：优先按Markdown标题层级切块，正文再按语义边界二次切分，默认块大小300到500字符，重叠50字符
- 向量化：BGE-M3 Embedding模型，支持中英混合，表现均衡；新项目可以试试gte-large，检索精度略有提升
- 向量存储：Qdrant作为主存储，Rust实现性能好，部署不复杂，docker可以启动
- 混合检索：Qdrant内置的BM25 + 向量双路召回，RRF融合，k值设为60
- 重排序：bge-reranker-base，对top-50候选重排后取top-5
切片策略上我踩过最大的坑是“为了切而切”。第一种错误是切得过大，比如800字符一块，导致向量表达的主题不够聚焦，召回结果里大量噪声；另一种是切得过小，比如150字符，上下文信息丢失严重，回答经常前言不搭后语。更合理的做法是先用目录和标题做一级结构切分，再根据段落语义做二级细化；如果一篇文章没有明确标题结构，再用固定窗口兜底，同时记录相邻块之间的上下文关系，检索命中的时候把前后各一块带出来，让LLM拿到完整上下文。
另外一个很少有人注意的细节是Embedding模型的文本截断。BGE系列默认最长支持512个Token，超过部分直接截断，很多人因此丢失了关键信息。我的做法是先用模型的分词器切出前512个Token，同时把文本中间部分做滑动窗口，生成多段Embedding再取平均，虽然计算量略增，但长文检索效果改善明显。
4.3 从零搭建一个轻量RAG核心代码
最后贴一段我从蓝图中抽出的“最小核心实现”，它不依赖重框架，只有四个文件配合就能跑通基础链路。结构如下：
parser.py：文档解析与切片index.py：创建Embedding写入Qdrantretrieve.py：混合检索与RRF融合generator.py：组装Prompt并调用LLM
我先看parser.py的核心逻辑：
import re from typing import List, Dict def split_document(text: str, chunk_size: int = 400, overlap: int = 50) -> List[Dict[str, str]]: """ 做多级切片：优先按标题切，其次按段落切，最后按窗口兜底 返回列表，每个元素包含文本内容和元数据 """ sections = [] # 用常见标题格式做一级切分 pattern = re.compile(r'^(#{1,3})\s+(.*)$', re.MULTILINE) matches = list(pattern.finditer(text)) if matches: for i, match in enumerate(matches): start = match.end() end = matches[i + 1].start() if i + 1 < len(matches) else len(text) sections.append({ "title": match.group(2).strip(), "level": len(match.group(1)), "content": text[start:end].strip() }) else: sections.append({"title": "", "level": 0, "content": text.strip()}) chunks = [] for sec in sections: if len(sec["content"]) <= chunk_size: chunks.append({"text": sec["content"], "title": sec["title"]}) else: # 优先按段落边界切 paragraphs = [p.strip() for p in re.split(r'\n\s*\n', sec["content"]) if p.strip()] buffer = "" for para in paragraphs: if len(buffer) + len(para) <= chunk_size: buffer += para + "\n" else: if buffer: chunks.append({"text": buffer.strip(), "title": sec["title"]}) buffer = para + "\n" if buffer: chunks.append({"text": buffer.strip(), "title": sec["title"]}) return chunks再来看retrieve.py里混合检索融合的核心逻辑：
import math from typing import List def rrf_fusion(dense_results: List[dict], sparse_results: List[dict], k: int = 60) -> List[dict]: """ Reciprocal Rank Fusion 把向量召回和BM25召回的排序结果按倒数排名融合 """ score_map = {} for idx, doc in enumerate(dense_results + sparse_results): doc_id = doc["id"] rank = doc.get("_rank", idx + 1) # 召回结果是按得分降序排列的 score_map[doc_id] = score_map.get(doc_id, 0) + 1.0 / (k + rank) fused = sorted(score_map.items(), key=lambda x: x[1], reverse=True) return [{"id": doc_id, "rrf_score": score} for doc_id, score in fused]这只是整个链路的极小一部分，真正的细节在解析清洗、元数据管理、评估集构建这些代码之外的地方。但先让它跑起来，再逐步迭代，是自研RAG最务实的路径。
5. 真实项目中踩过的坑和排查思路
逆向工程拆完，不代表自研就一帆风顺。以下是我在实际落地过程中反复踩过的几个有代表性的坑，整理出来供你排查时参考。
坑一：向量召回效果差，先别急着换模型。排查顺序很重要：先看chunk，再看Embedding，最后看检索策略。有一次项目检索命中率上不去，团队第一反应是换更大的Embedding模型，试了一圈没多大变化。后来查了数据发现，原始PDF的页眉页脚被抽取进正文，每个chunk里都混着“某某公司内部资料”这类重复文本，向量全部被噪声带偏。最后只是加了预处理，把页眉页脚过滤掉，命中率直接提升了十个百分点。大多数检索质量问题出在数据和切片上，而不是模型上。
坑二：混合检索的RRF参数要按数据量调。我最初直接采用k默认值，检索结果偏向向量路。后来测试了一个代码库知识库，精确匹配需求多的场景下BM25召回更准，要调低k值以放大稀疏召回。给一个可操作的经验：如果召回结果总是语义泛泛而谈，把k从60下调到30甚至20；如果召回结果精确但不相关，把k往上调到80或100。这个参数本质上是两路召回的信任权重，没有统一最优值。
坑三：检索结果拼进提示词后，LLM反而变笨。这听起来反直觉，但很常见。原因是把大量包含无关信息的片段塞进上下文，干扰模型对真正答案的注意力。后来我加了一个上下文压缩步骤：重排序之后，把top-5结果交给一个小模型，让它从每段中提取与问题最相关的句子，拼成精简版上下文。LLM吃进去的上下文质量比数量重要得多，这个认知帮我解决了不少“检索准但回答差”的问题。
坑四：图片知识库的“能存”不等于“能用”。用户问“RAG知识库能存储图片吗”，技术上把图片转成向量存进去很容易，难点在于图片中的信息如何被检索和引用。如果只是把一张产品结构图直接存进去，用户问“这个零件的型号”，向量检索根本无法命中。参照RAGFlow的做法：先让文档解析服务把图片里的文字用OCR提取出来，再把图片的布局信息（比如图注、附近的正文）一起作为上下文存入索引，检索时才能既有图片引用又有文字依据。
坑五：没有评估体系的优化全是玄学。自研前期我犯过的最大错误是凭感觉调参。每次改动觉得“好像好了一点”，但没有数据支撑。后来搭建了一个最小评估集：精选真实用户问题，记录每个问题在改动前后的retrieval命中率、answer准确率、上下文噪声比例。有评估集之后，优化节奏变成了：改一个参数跑一次回归，数据说话。建议你在自研第一天就把评估集建起来，哪怕只有50条问题，也好过没有。50条精炼真实的问题，迭代两三轮调优，效果提升是肉眼可见的。
6. 写在最后的几点体会
这套蓝图从拆解到落地，前后花了我大概三个多月的时间。好几个项目交付之后都源于这里面的架构思路。回看整个过程，有几点教训和心得值得多说一句。
开源RAG产品的意义从来不是让你直接部署，而是让你在动手前看清全貌。每款产品背后都代表了一种取舍哲学：LangChain追求极致灵活但把复杂度留给你，LlamaIndex强调索引结构的重要性，Qdrant把工程细节打磨到极致，RAGFlow专注下沉到文档解析的深水区，GraphRAG试图突破语义检索的天花板。你不需要同时拥有它们的一切，但可以带着它们的问题清单审视自己的架构。
我个人认为好用的RAG架构，“清晰”比“花哨”重要。模块边界清楚，数据血缘可追踪，每个检索结果能解释来源，比堆砌多个Ranker和模型更耐维护。另外强烈建议在实际项目里保留一个手工构造的“坏样本库”——把用户反馈过答得不对的问题和标准答案收集起来，随着时间推移，它比任何评测集都更能指导你的优化方向。知识库系统是典型的需求会越用越深的产品，评估数据是它持续进步的养料。
