★ FEATURED ARTICLE 1. 为什么我要花两周时间逆向拆解六款开源RAG产品去年下半年我所在的团队接到一个内部知识库问答系统的需求。当时摆在面前的有两条路一是直接调用市面上成熟的商业RAG服务二是基于开源方案自研一套。商业方案看起来省事但数据要出内网而且按调用量计费的模式在长期使用下成本不可控。于是我们决定自研。自研RAG这件事听起来门槛不高——无非就是文档切块、向量化、检索、拼Prompt、调模型这几步。但真正动手之后才发现每一个环节都有大量的工程细节需要决策切块粒度怎么定向量模型选哪个检索用纯向量还是混合检索重排序要不要加多轮对话的上下文怎么管理这些问题如果没有参考答案光靠拍脑袋很容易做出一个能跑但不好用的系统。我的做法是先把市面上口碑不错的六款开源RAG产品拉下来逐一部署、使用、读源码从它们的架构设计中提炼共性再结合我们自己的业务场景做取舍。这个过程大概花了两周时间收获远超预期。这篇博文就是把这套逆向工程的思路和结论完整地分享出来适合正在考虑自研RAG的开发者、需要做技术选型的架构师以及想了解RAG工程化落地细节的读者。2. 六款开源RAG产品的整体架构对比2.1 我选择的六款产品及选择理由在挑选逆向对象时我定了几个标准第一必须是真正能跑起来的完整系统而不是只提供几个函数的工具库第二要覆盖不同的技术路线比如有的偏轻量、有的偏企业级第三社区活跃度要够说明这些设计经过了真实用户的检验。最终选定的六款产品按定位大致可以分为三类轻量级框架型这类产品的特点是代码量小、依赖少、上手快适合快速搭建原型。它们的RAG流程通常是线性的从文档加载到答案生成一条路走到底没有太多分支逻辑。平台级系统型这类产品提供了完整的Web界面、用户管理、知识库管理等功能RAG只是其中的一个模块。它们的架构更复杂但工程化程度更高值得借鉴的地方也更多。检索增强型这类产品在检索环节做了大量优化比如混合检索、多路召回、重排序等适合对检索质量要求高的场景。注意我这里刻意没有提具体产品名称一方面是为了避免广告嫌疑另一方面是因为这篇博文的核心价值在于提炼设计思路而不是推荐某个具体工具。你在选型时可以根据自己的需求去对应这些类别。2.2 架构共性与差异的提炼把这六款产品的架构图铺在一起看我发现了一个很有意思的现象所有产品的核心流程都是一致的区别只在于每个环节的实现深度和扩展方式。核心流程可以概括为五个阶段文档摄入加载原始文档解析成纯文本然后切分成块。向量化与索引把文本块通过Embedding模型转成向量存入向量数据库。检索根据用户问题从向量数据库中召回相关文本块。增强把召回结果和用户问题拼成一个完整的Prompt。生成调用大语言模型生成最终答案。差异主要体现在三个方面对比维度轻量级框架平台级系统检索增强型文档解析支持纯文本和Markdown为主支持PDF、Word、HTML等多种格式通常支持多种格式且解析质量较高切块策略固定长度切块支持按语义、按标题层级切块支持自定义切块规则部分支持重叠切块检索方式纯向量检索向量检索为主部分支持关键词检索混合检索重排序多路召回上下文管理无多轮对话支持支持多轮对话有会话历史管理支持多轮对话部分支持查询改写扩展性低修改需要改源码中提供插件机制高提供丰富的配置项和API这张表是我在逆向过程中逐步整理出来的每一列都对应着我实际部署和测试后的观察。比如切块策略这一行轻量级框架通常就是一个RecursiveCharacterTextSplitter搞定而平台级系统会提供多种切块器的组合甚至允许用户自定义切块规则。2.3 从对比中得到的第一个关键结论对比完这六款产品之后我得到了第一个关键结论自研RAG的难点不在能不能跑通而在每个环节做到什么程度。如果只是做一个Demo用轻量级框架的思路半天就能跑通。但要做一个真正能在业务中使用的系统就必须在每个环节都做深入的工程优化。比如文档解析如果只支持纯文本那用户上传PDF就没法用如果切块粒度太粗检索出来的内容就会包含大量无关信息影响答案质量如果没有重排序检索结果的相关性就会差很多。这个结论直接影响了我们后续的自研方案设计不追求大而全但每个核心环节都要做到够用且好用。3. 核心模块的逆向分析与自研取舍3.1 文档解析与切块最容易被低估的环节在逆向之前我以为文档解析和切块是最简单的环节无非就是读文件、按固定长度切分。但实际拆解下来这个环节的复杂度远超我的预期。先说文档解析。六款产品中有三款只支持纯文本和Markdown另外三款支持PDF、Word、HTML等格式。支持多格式的产品在解析质量上也有明显差异。有的产品解析PDF时只能提取纯文本表格和图片全部丢失有的产品则能保留表格结构甚至能提取图片中的文字。我在测试中遇到过一个典型案例一份产品需求文档里面有一个关键的功能对比表格。用纯文本提取的方式表格内容变成了一堆乱序的文字检索时完全无法定位到正确的信息。而用支持表格结构提取的解析器表格被转成了Markdown格式检索效果好了很多。再说切块。六款产品中有四款用的是固定长度切块只是块大小和重叠长度不同。另外两款用了更复杂的策略按语义切块先用Embedding模型计算相邻句子的相似度在相似度骤降的地方切分。这种方式的优点是每个块内部的语义更完整缺点是计算成本高而且切块结果不稳定。按标题层级切块利用Markdown或HTML的标题结构把同一标题下的内容作为一个块。这种方式适合结构化的文档但对非结构化文档无能为力。我们最终的取舍是以固定长度切块为主辅以标题层级切块。具体来说如果文档有明确的标题结构就按标题切块如果没有就用固定长度切块块大小设为512个token重叠长度设为50个token。实操心得块大小和重叠长度这两个参数我试过很多组合。块太小比如256检索出来的内容太碎模型很难拼出完整答案块太大比如1024检索出来的内容包含太多无关信息反而干扰模型。512是我实测下来比较平衡的值。重叠长度设为块大小的10%左右能有效避免关键信息被切断。3.2 向量化与索引模型选型与索引策略向量化环节的核心决策是Embedding模型的选择。六款产品中有三款用的是OpenAI的Embedding接口两款用的是开源的BGE系列模型还有一款同时支持多种模型让用户自己选。我在测试中对比了不同模型在中文场景下的检索效果。结论是在中文场景下开源模型和商业接口的差距已经很小了。BGE系列模型在中文语义相似度任务上的表现和商业接口相比差距在可接受范围内但成本优势非常明显。索引策略方面六款产品都用了向量数据库但选择不同。有的用FAISS这种轻量级的本地索引有的用Milvus、Qdrant这种独立的向量数据库服务。我们的取舍是开发阶段用FAISS生产环境用Qdrant。FAISS的好处是零依赖、启动快适合快速迭代Qdrant的好处是支持分布式部署、有完善的过滤和标量索引功能适合生产环境。这里有一个容易被忽略的细节向量维度和距离度量方式的选择。不同的Embedding模型输出的向量维度不同常见的有768维、1024维、1536维。距离度量方式有余弦相似度、欧氏距离、内积等。这些参数在创建索引时就要确定后期修改需要重建整个索引。注意如果你用的是归一化后的向量余弦相似度和内积是等价的。大部分Embedding模型输出的向量都已经归一化所以直接用内积即可计算速度更快。3.3 检索策略从纯向量到混合检索的演进检索环节是六款产品差异最大的地方也是我花时间最多的部分。轻量级框架通常只做纯向量检索把用户问题向量化然后在向量数据库中找最相似的Top-K个块。这种方式实现简单但在实际使用中问题不少。比如用户问XX功能的参数是什么纯向量检索可能会召回一堆提到XX功能但没提参数的块因为向量相似度主要看语义整体对关键词的精确匹配不敏感。平台级系统通常会加入关键词检索形成混合检索。具体做法是同时做向量检索和BM25关键词检索然后把两路结果融合。融合算法有RRF和加权求和两种RRF更常用因为它不需要调权重。检索增强型产品还会加入重排序环节先用混合检索召回较多的候选块比如20个然后用一个重排序模型对候选块进行精排选出最相关的几个比如5个送给大模型。重排序模型通常比Embedding模型更大、更准但计算成本也更高所以只用在候选集上。我们最终的方案是混合检索重排序。具体流程是向量检索召回Top-20。BM25检索召回Top-20。用RRF融合两路结果得到Top-20。用重排序模型对Top-20精排选出Top-5。把Top-5拼入Prompt。这套流程比纯向量检索复杂不少但检索质量提升明显。我做过一个简单的对比测试同样的问题集纯向量检索的答案准确率大概在60%左右加入混合检索后提升到75%再加入重排序后提升到85%左右。3.4 上下文管理与多轮对话多轮对话是很多RAG系统的标配但实现方式差异很大。最简单的做法是把历史对话直接拼到当前问题前面一起做检索和生成。这种方式的问题是历史对话中的无关信息会干扰检索而且随着对话轮次增加Prompt会越来越长最终超出模型的上下文窗口。更成熟的做法是查询改写先用大模型把当前问题和历史对话结合改写成一个个独立的、不依赖上下文的查询然后再用这个查询去做检索。比如用户先问XX功能怎么用再问它的参数有哪些查询改写会把第二个问题改写成XX功能的参数有哪些这样检索时就不会丢失关键信息。六款产品中有三款支持查询改写但实现方式不同。有的用规则模板有的用大模型。我们最终选择了用大模型做查询改写因为效果更好而且成本可控——毕竟改写只是生成一个短查询token消耗不大。实操心得查询改写的Prompt设计很关键。我试过几种写法最终用的是根据以下对话历史将用户的最新问题改写成一个独立的、不依赖上下文的问题。如果最新问题本身已经独立则原样返回。这个Prompt简单直接效果稳定。4. 从逆向到自研一套可复用的蓝图4.1 整体架构设计基于前面的逆向分析我设计了一套自研RAG的架构。整体分为四层接入层负责接收用户请求管理会话状态做基础的参数校验和限流。检索层包含文档解析、切块、向量化、索引、检索、重排序等模块。生成层负责Prompt组装、大模型调用、答案后处理。存储层包括向量数据库、文档存储、会话存储。这四层之间通过明确的接口通信每一层都可以独立替换或升级。比如检索层你可以先用FAISS做向量索引后期换成Qdrant只要接口不变上层代码不用改。4.2 关键模块的实现要点文档解析模块我用了两个解析器一个处理纯文本和Markdown一个处理PDF。PDF解析器选的是能保留表格结构的方案虽然速度慢一点但检索质量提升明显。解析后的文本统一转成Markdown格式方便后续按标题切块。切块模块实现了两种切块器按标题切块和按固定长度切块。切块器根据文档是否有标题结构自动选择。固定长度切块时块大小512token重叠50token。向量化模块封装了一个统一的Embedding接口底层可以切换不同的模型。开发阶段用开源的BGE模型生产环境根据成本和质量要求选择。检索模块实现了向量检索、BM25检索、RRF融合、重排序四个子模块。每个子模块都可以独立开关方便做A/B测试。生成模块Prompt模板可配置支持不同的模型和参数。答案后处理包括引用标注、格式清理等。4.3 参数配置与调优经验这套系统跑起来之后我花了不少时间做参数调优。以下是我认为最关键的几个参数及其调优经验参数推荐值调优经验块大小512 token太小则信息碎片化太大则噪声多重叠长度50 token约为块大小的10%避免关键信息被切断向量检索Top-K20太小则召回不足太大则重排序压力大BM25检索Top-K20与向量检索保持一致方便融合重排序后Top-K5太多则Prompt过长太少则信息不足温度参数0.1RAG场景需要确定性答案温度不宜高这些参数不是一成不变的需要根据你的业务场景和数据特点做调整。比如如果你的文档都是短文本块大小可以适当减小如果你的问题都是事实型查询温度可以设为0。注意调参时一定要有评估集。我一开始凭感觉调调来调去也不知道有没有变好。后来建了一个包含100个问题和标准答案的评估集每次调参后跑一遍看准确率的变化效率高了很多。5. 实操过程中踩过的坑与排查技巧5.1 文档解析的常见问题问题一PDF解析后文字顺序错乱。这是PDF解析的经典问题尤其是多栏排版的PDF。解决方案是先用版面分析工具识别栏位再按栏位顺序提取文字。如果不想引入额外依赖可以尝试调整解析器的参数部分解析器支持按阅读顺序输出。问题二表格内容丢失。纯文本提取会丢失表格结构导致检索时无法定位。解决方案是使用支持表格提取的解析器把表格转成Markdown或HTML格式。如果解析器不支持可以考虑用专门的表格识别工具做后处理。问题三扫描版PDF无法提取文字。这种情况需要OCR。六款产品中只有一款内置了OCR功能其他都需要额外集成。我们的做法是先用OCR工具把扫描版PDF转成文本再走正常的解析流程。5.2 检索质量差的排查思路检索质量差是最常见的问题排查时可以从以下几个方向入手检查切块质量把检索到的块打印出来看看内容是否完整、是否包含关键信息。如果块太碎或太杂调整切块参数。检查Embedding模型用几个已知相似的句子测试Embedding模型的相似度输出看看是否符合预期。如果模型对中文支持不好考虑换模型。检查检索参数Top-K是否太小距离度量方式是否合适索引是否正常构建检查查询改写如果是多轮对话场景看看查询改写后的结果是否准确。改写错误会导致检索方向完全偏离。检查重排序如果加了重排序但效果反而变差可能是重排序模型和Embedding模型不匹配或者重排序的候选集太小。5.3 生成环节的典型问题问题一模型编造答案。这是RAG系统最头疼的问题。解决方案是在Prompt中明确要求只根据提供的上下文回答如果上下文中没有相关信息回答根据已有信息无法回答。同时可以降低温度参数减少模型的随机性。问题二答案不完整。可能是检索到的块不够全或者Prompt中上下文的排列顺序影响了模型的注意力。可以尝试把最相关的块放在Prompt的开头或结尾因为模型对这两个位置的注意力更强。问题三引用标注不准确。如果要求模型标注答案的来源模型可能会标错。解决方案是在Prompt中给出明确的引用格式并在后处理时做校验。5.4 性能优化的经验RAG系统的性能瓶颈通常在两个地方向量检索和模型调用。向量检索的优化手段包括使用更高效的索引类型如HNSW、减少向量维度、使用量化技术压缩向量。模型调用的优化手段包括使用流式输出减少首字延迟、缓存常见问题的答案、对Prompt做压缩减少token消耗。实操心得流式输出对用户体验的提升非常明显。用户不需要等整个答案生成完而是可以边生成边看。实现上也不复杂大部分模型接口都支持流式返回。6. 这套蓝图后续还能怎么扩展这套自研RAG系统上线后运行了几个月整体效果符合预期。但RAG这个领域发展很快后续还有很多可以扩展的方向。多模态RAG目前只支持文本后续可以加入图片和表格的理解能力。比如用户上传一张图表系统能理解图表内容并回答相关问题。Agent化把RAG作为一个工具接入Agent框架让模型自己决定什么时候检索、检索什么。这种方式适合复杂任务比如需要多步推理的场景。个性化检索根据用户的历史行为和偏好调整检索结果的排序。比如同样的问题不同角色的用户可能关注不同的答案。评估自动化目前评估集是人工构建的后续可以用大模型自动生成评估问题和标准答案降低评估成本。这些方向我都在陆续尝试有些已经出了原型有些还在调研阶段。RAG的工程化落地是一个持续迭代的过程没有一劳永逸的方案只有不断根据业务反馈做调整。我个人在实际操作中的体会是不要追求一步到位先把核心流程跑通再逐步优化每个环节。我见过不少团队一开始就想做一个大而全的系统结果做了半年还没上线。反而是那些先用轻量级方案快速上线、再根据用户反馈迭代的团队最终做出了真正好用的产品。
阅读完成 · 觉得有帮助？
