RAG 这个方向我从 2023 年下半年开始密集接触，前前后后拆过不下十套开源方案，也帮团队从零搭过两套自研系统。说实话，最开始我也是“拿来主义”，觉得 LangChain 一套、向量库一接、文档一灌就完事了。但真到了业务场景里，召回率上不去、多轮对话断片、知识更新滞后这些问题一个接一个冒出来，逼着我回头去啃那些成熟开源项目的源码。这篇文章就是那段时间逆向拆解六款主流开源 RAG 产品之后，沉淀下来的一套可复用自研蓝图。不管你是刚接触 RAG 想搞明白它到底怎么运转的，还是已经踩过坑准备自研一套更贴合业务的系统，下面这些内容应该都能帮你少走一些弯路。

1. 为什么要从开源 RAG 反推自研架构

1.1 直接套用开源方案的三个隐性成本

很多人一开始的想法跟我一样：开源 RAG 项目那么多，Dify、RAGFlow、FastGPT、Quivr、AnythingLLM、LangChain 官方模板，随便挑一个部署起来就能用，何必自己造轮子？这个想法在 Demo 阶段完全没问题，但一旦进入生产环境，三个隐性成本就会暴露出来。

第一个是定制化改造成本。开源项目的代码结构是为通用场景设计的，它的抽象层次往往比你实际需要的多两到三层。比如你想改一个检索后的重排序逻辑，可能要穿过 service 层、pipeline 层、component 层才能找到那个真正干活的函数。改完之后升级版本，合并冲突又是一场噩梦。

第二个是性能调优的盲区。开源方案为了兼容各种场景，默认参数往往偏保守。比如 chunk size 默认 512、top_k 默认 4、相似度阈值默认 0.7，这些值在通用场景下勉强能用，但在你的垂直领域里可能完全不是最优解。你不知道它内部到底做了什么取舍，就很难有针对性地调。

第三个是数据主权与合规成本。这个不用展开说，但凡涉及企业内部知识库，数据不出域是底线。开源方案虽然可以私有化部署，但它依赖的某些云服务接口、遥测上报、模型调用链路，你需要逐一审计和切断，这个工作量不比自研小。

1.2 逆向工程不是抄，是提炼设计决策

我特别想强调一点：逆向工程开源 RAG 产品，目的绝对不是把它的代码抄一遍。抄代码是最没技术含量的做法，而且你抄不到它背后的设计决策。

真正有价值的是提炼它在关键节点上做了什么选择，以及为什么做这个选择。比如：

• 它在文档解析阶段为什么选择按标题层级切分而不是按固定长度切分？
• 它在检索阶段为什么用混合检索而不是纯向量检索？
• 它在生成阶段为什么要把检索结果重新排序后再拼进 Prompt？
• 它的多轮对话记忆是怎么管理的，是存全量历史还是做摘要压缩？

这些决策背后的逻辑，才是自研 RAG 架构的真正骨架。你理解了这些，就能根据自己的业务特点做取舍，而不是盲目照搬。

1.3 六款产品的选型逻辑与拆解维度

我选的六款产品覆盖了不同的架构风格和技术栈：

拆解维度我定了四个：文档处理链路、检索策略、生成控制、工程架构。下面逐个展开。

2. 文档处理链路：从原始文件到可检索片段

2.1 文档解析的深水区：格式适配与内容提取

文档解析这一步，看起来简单，实际上是最容易埋雷的地方。我拆完六款产品后发现，它们在解析阶段的差异直接决定了后续检索效果的上限。

PDF 解析是重灾区。很多开源方案直接用 PyPDF2 或者 pdfplumber 提取文本，但这两者对扫描件、复杂排版、表格的处理都很弱。RAGFlow 在这方面做得比较深，它用了 OCR 兜底加版面分析，能识别出标题、正文、表格、图片说明等不同区域。我实测过一份 50 页的技术白皮书，用普通提取方式得到的文本里，表格数据全乱了，标题和正文混在一起；用 RAGFlow 的解析方式，结构保留得相当完整。

Word 和 Markdown 相对好处理，但要注意样式信息的保留。比如 Markdown 里的##标题层级，如果解析时丢掉了，后续就没法按层级做智能分块。FastGPT 在这一块的处理是：先把 Markdown 转成带层级标记的中间格式，再按层级切分。

HTML 解析要特别注意去噪。网页里的导航栏、广告、页脚这些噪音如果不清理，会严重干扰检索。Quivr 的做法是用 Readability 算法先提取正文区域，再做后续处理。

实操心得：文档解析阶段不要追求一步到位，建议先做格式归一化，把所有输入统一转成 Markdown 或带结构标记的纯文本，再做后续分块。这样链路清晰，排查问题也方便。

2.2 分块策略的取舍：固定长度 vs 语义分块

分块策略是 RAG 系统里最容易被低估的环节。我见过太多人直接用 LangChain 的RecursiveCharacterTextSplitter，设个 chunk_size=512、overlap=50 就完事了。这种做法在通用场景下能跑，但在垂直领域里往往效果很差。

固定长度分块的优点是实现简单、块大小均匀、检索时计算量可控。缺点是它会在语义边界处切断文本。比如一个完整的操作步骤被切成了两半，前半段在块 A，后半段在块 B，检索时只召回了块 A，生成答案就缺了关键信息。

语义分块的做法是先识别文本的语义边界（段落、标题、列表项），再在边界处切分。RAGFlow 和 Dify 都采用了类似策略。具体实现上，它们会计算相邻句子的 embedding 相似度，当相似度低于某个阈值时认为出现了语义断点。

我自己的做法是混合策略：先按标题层级做粗分，如果某个章节内容过长（超过 1000 token），再在章节内部按段落细分。这样既保留了结构信息，又控制了块的大小。

def hybrid_chunk(text, max_chunk_size=1000): # 第一层：按标题切分 sections = split_by_heading(text) chunks = [] for section in sections: if count_tokens(section) <= max_chunk_size: chunks.append(section) else: # 第二层：按段落切分 paragraphs = split_by_paragraph(section) current_chunk = "" for para in paragraphs: if count_tokens(current_chunk + para) > max_chunk_size: chunks.append(current_chunk) current_chunk = para else: current_chunk += "\n" + para if current_chunk: chunks.append(current_chunk) return chunks

2.3 元数据注入：让每个块都携带上下文

这一步是我拆解六款产品时发现的最大差异点。大部分开源方案只存了 chunk 的文本内容和向量，但 RAGFlow 和 Dify 会额外注入丰富的元数据。

元数据包括：来源文件名、所属章节标题、块在文档中的位置、创建时间、文档类型等。这些信息在检索后可以用来做过滤和重排序，也能在生成时拼进 Prompt 帮助模型理解上下文。

举个例子，用户问“第三章提到的部署步骤是什么”，如果你的块元数据里有章节信息，就可以在检索时加一个过滤条件，只召回第三章的内容。如果没有元数据，就只能靠向量相似度硬匹配，效果差很多。

注意事项：元数据字段不要太多，否则会增加存储和检索开销。我一般保留 5-8 个关键字段就够了，重点是来源、章节、位置、时间这四个。

3. 检索策略：从单路召回走向混合重排

3.1 向量检索的瓶颈与补充手段

向量检索是 RAG 的核心，但它有三个明显的瓶颈：

第一，对精确匹配不敏感。用户问“错误码 E5021 怎么解决”，向量检索可能召回一堆关于错误处理的通用文档，但就是找不到那个精确提到 E5021 的块。因为 embedding 模型把 E5021 编码成了一个语义向量，它和“错误码”“异常”这些词的向量很接近，但和具体的数字编码关系不大。

第二，对长尾查询效果差。如果用户的问题在训练数据里很少出现，embedding 模型可能无法准确编码它的语义。

第三，无法处理否定和条件。“不要用 Docker 部署”和“用 Docker 部署”在向量空间里可能非常接近，但语义完全相反。

解决这些瓶颈的常见手段是混合检索：向量检索加关键词检索（BM25 或全文索引），两路召回后做融合。FastGPT 和 Dify 都支持这种模式。

3.2 混合检索的工程实现与权重调优

混合检索的实现方式有两种：并行召回后融合和串行召回后过滤。

并行召回是同时跑向量检索和关键词检索，各自返回 top_k 结果，然后用 RRF（Reciprocal Rank Fusion）或加权分数融合。RRF 的公式很简单：

score = sum(1 / (k + rank_i))

其中 k 是平滑参数，一般取 60，rank_i 是文档在第 i 路召回中的排名。这个方法的优点是无需调权重，对两路召回的结果一视同仁。

加权分数融合则需要归一化两路的分数，然后按权重相加。权重的设定取决于你的场景：如果用户查询偏口语化，向量检索权重要高；如果查询包含大量专有名词和代码，关键词检索权重要高。

我自己的经验是：先用 RRF 跑一版基线，再根据 bad case 分析调整权重。不要一上来就调权重，那样很容易过拟合。

3.3 重排序模型的选择与部署考量

重排序是检索链路的最后一道关卡。它的作用是拿到粗排的 top_n 结果后，用更精细的模型重新打分，把最相关的块排到前面。

常见的重排序模型有：BGE-Reranker、Cohere Rerank、Cross-Encoder 类模型。我实测下来，BGE-Reranker 在中文场景下性价比最高，它比 Cross-Encoder 轻量，效果又比单纯的向量相似度好很多。

部署重排序模型时要注意延迟。如果每次检索都跑一遍重排序，响应时间会增加 200-500ms。我的做法是：只在检索结果置信度低的时候触发重排序。比如向量检索的 top1 和 top2 分数差距很小，说明模型不确定，这时候再上重排序。

def should_rerank(results, threshold=0.05): if len(results) < 2: return False score_diff = results[0].score - results[1].score return score_diff < threshold

4. 生成控制：让模型说人话、说对话

4.1 Prompt 模板的设计原则与常见陷阱

Prompt 设计是 RAG 系统里最“玄学”的部分，但它其实有章可循。我拆完六款产品后总结出三条原则：

原则一：明确角色和边界。开头就要告诉模型“你是一个基于给定资料回答问题的助手，如果资料中没有相关信息，直接说不知道”。这句话能大幅降低幻觉率。

原则二：结构化输入。把检索到的块用明确的分隔符包起来，并标注来源。比如：

【资料1】来源：xxx.pdf 第三章 内容：... 【资料2】来源：yyy.md 第二节 内容：...

原则三：控制输出格式。如果需要模型返回结构化数据，在 Prompt 里给出示例。如果需要它引用来源，明确要求它在答案后标注[资料1]。

常见的陷阱是 Prompt 太长导致模型“迷失在中间”。如果检索回来 10 个块，每个块 500 字，Prompt 就 5000 字了，模型对中间部分的注意力会下降。我的做法是限制召回块的数量，一般 3-5 个就够了，同时把最相关的块放在最前面和最后面。

4.2 上下文窗口管理：截断、压缩与摘要

上下文窗口是有限资源，怎么在有限窗口里塞进最有用的信息，是个工程问题。

截断策略最简单：按块的相关性排序，从高到低塞，塞满为止。缺点是可能丢掉后面的关键信息。

压缩策略是用一个小模型对每个块做摘要，只保留和问题相关的部分。这个做法能塞进更多块，但会增加一次模型调用。

摘要策略是在多轮对话场景下，把历史对话压缩成摘要，腾出窗口给检索结果。Dify 和 FastGPT 都支持这种模式。

我自己的选择是：单轮问答用截断，多轮对话用摘要。因为单轮场景下检索结果的相关性排序已经比较可靠了，截断的损失可控；多轮场景下历史对话的冗余度很高，摘要能省出大量空间。

4.3 引用溯源与幻觉抑制的实操手段

引用溯源是 RAG 相比纯生成模型的最大优势。用户不仅能看到答案，还能看到答案来自哪个文档的哪个部分。

实现引用溯源的关键是在生成时让模型标注来源。具体做法是在 Prompt 里要求模型在每句话后面加上[资料X]标记，然后在后处理阶段把这些标记替换成可点击的链接。

幻觉抑制除了 Prompt 层面的约束，还可以在工程层面做校验。比如：生成答案后，用另一个模型或规则检查答案中的关键实体是否出现在检索结果里。如果没出现，就标记为“可能幻觉”，触发人工审核或重新检索。

实操心得：引用溯源不要追求 100% 准确，能达到 80% 以上就已经很有价值了。关键是让用户知道这个答案有据可查，而不是凭空生成。

5. 工程架构：从单体到可扩展的 Pipeline

5.1 组件抽象与接口设计

自研 RAG 系统最容易犯的错误是把所有逻辑写在一个大函数里。我见过一个项目，rag_pipeline()函数有 800 多行，改一个参数要通读全文。这种代码没法维护，也没法扩展。

正确的做法是按职责拆分组件，每个组件定义清晰的输入输出接口。我参考 Dify 和 LangChain 的设计，把系统拆成这几个核心组件：

• Loader：负责从各种来源加载原始文档
• Parser：负责把原始文档解析成结构化文本
• Chunker：负责把结构化文本切分成块
• Embedder：负责把块编码成向量
• Indexer：负责把向量和元数据写入存储
• Retriever：负责根据查询召回相关块
• Reranker：负责对召回结果重新排序
• Generator：负责根据查询和召回结果生成答案

每个组件都是可替换的。比如你想从 OpenAI 的 embedding 换成 BGE，只需要实现一个新的 Embedder 类，其他组件不用动。

5.2 异步处理与性能优化

RAG 系统的性能瓶颈通常在两个地方：文档入库时的 embedding 计算和查询时的检索加生成。

入库阶段，如果文档量大，embedding 计算会很慢。我的做法是用异步任务队列，把文档解析、分块、embedding 拆成独立的异步任务，并行处理。同时用批量 embedding 接口，一次请求编码多个块，比逐个编码快 5-10 倍。

查询阶段，检索和生成可以并行。检索的同时，可以先把用户查询做预处理（比如改写、扩展），等检索结果回来后再一起送给生成模型。

import asyncio async def query_pipeline(query): # 并行执行查询预处理和向量编码 preprocess_task = asyncio.create_task(preprocess_query(query)) embed_task = asyncio.create_task(embed_query(query)) processed_query, query_vector = await asyncio.gather( preprocess_task, embed_task ) # 检索 results = await retrieve(processed_query, query_vector) # 生成 answer = await generate(processed_query, results) return answer

5.3 可观测性与持续迭代机制

RAG 系统上线不是终点，而是起点。你需要一套可观测性机制来持续监控效果、发现问题、迭代优化。

我一般会记录这几个指标：检索命中率（召回结果中真正相关的比例）、答案采纳率（用户对答案的满意程度）、平均响应时间、幻觉率（人工抽检发现的事实错误比例）。

这些指标的数据来源包括：用户反馈（点赞/点踩）、人工抽检、自动评估（用另一个模型判断答案是否基于检索结果）。

基于这些数据，你可以做针对性的优化。比如检索命中率低，就调分块策略或换 embedding 模型；幻觉率高，就加强 Prompt 约束或增加校验环节。

6. 常见问题与排查技巧实录

6.1 检索效果差的排查路径

检索效果差是最常见的问题，排查路径我一般按这个顺序走：

第一步，检查分块质量。随机抽几个块看看，是不是有语义不完整的情况。如果块被切得七零八落，先调分块策略。

第二步，检查 embedding 模型。用几个典型查询测试一下，看看召回的块是不是真的相关。如果 embedding 模型对中文支持不好，考虑换 BGE 或 M3E。

第三步，检查检索参数。top_k 是不是太小了？相似度阈值是不是太高了？先放宽参数看看召回效果，再逐步收紧。

第四步，检查查询本身。用户的查询是不是太短、太模糊？考虑加一个查询改写环节，把用户的口语化查询改写成更适合检索的形式。

6.2 生成质量不稳定的应对策略

生成质量不稳定通常表现为：有时候回答很好，有时候答非所问。原因可能有几个：

检索结果波动。同一个问题，两次检索召回的块不一样，导致生成结果不一致。解决办法是固定随机种子，或者用更稳定的检索策略。

Prompt 敏感。模型对 Prompt 的措辞很敏感，换一个说法结果就差很多。解决办法是固定 Prompt 模板，不要频繁改动。

模型本身的不确定性。大模型生成有随机性，temperature 设太高会导致输出不稳定。建议 RAG 场景下 temperature 设 0.1-0.3。

6.3 知识更新滞后的处理方案

知识更新滞后是 RAG 系统的固有挑战。文档更新了，但向量库里的旧数据还在，检索时可能召回旧内容。

处理方案有三种：

全量重建。定期把所有文档重新解析、分块、embedding，全量替换向量库。优点是简单彻底，缺点是耗时长、成本高。

增量更新。只处理有变化的文档，删除旧块、插入新块。优点是快，缺点是需要维护文档和块的映射关系。

版本管理。每个块带一个版本号，检索时只召回最新版本。优点是灵活，缺点是存储开销大。

我自己的选择是增量更新加定期全量重建。日常用增量更新保证时效性，每周做一次全量重建保证一致性。

最后分享一个小技巧：在检索结果里加一个“相关性分数”字段，生成时让模型参考这个分数。如果所有块的相关性都很低，模型可以选择说“没有找到相关信息”，而不是硬编一个答案。这个简单的改动能显著降低幻觉率。

这套蓝图我在两个项目里落地过，从零到上线大概用了三周时间，其中一周在调检索效果，一周在搭工程架构，一周在测试和优化。实际跑下来，检索命中率能到 85% 左右，答案采纳率 70% 上下，对于企业内部知识库场景已经够用了。后续还可以在查询改写、多路召回融合、生成结果校验这几个方向继续深挖，空间还很大。