企业官网建设流程全解析

做自研RAG项目，最怕的不是写代码，而是把弯路完整地走一遍。文档解析、分块、向量化、检索、重排、提示词装配，任何一环拍脑袋，最后都要在问答效果上还债。我自己带团队做RAG落地时，踩过一轮坑之后才意识到：与其闭门造车，不如把市面上成熟的开源RAG产品当成免费教材，一件件逆向拆解，再拼出适合自己业务的自研底座。

这篇内容想做的事情很简单：从六款有代表性的开源RAG产品里，逐层抽出值得复用的设计，最终汇成一套可直接参考的自研RAG蓝图。不管你是刚接手RAG相关需求、团队里正在选型，还是自研到一半发现效果不对，这篇都能给你一个相对完整的参照系。

1. 先回答一个核心问题：为什么自研RAG要先逆向开源产品

1.1 自研RAG最常见的三种弯路

先说我在实际项目里看到的三类典型失败路径。

第一类是"重检索、轻前处理"。团队一上来就调Embedding模型、换向量库、优化召回策略，但文档根本没处理好。拿到的PDF是扫描件，OCR没做；表格被当成普通文字切碎；章节标题和正文混在一个chunk里。结果检索阶段无论怎么调，召回的内容都是碎片，LLM生成答案时自然只能瞎编。这类项目通常会在上线后一到两周被业务方用几个"常识问题"问倒。

第二类是"重实现、轻评估"。代码写得很嗨，召回接口、重排服务、知识库管理后台全都有，但没有一套评估集。上线之后怎么判断效果变好还是变差？全靠感觉。RAG这个系统链路长，任何一环微调都可能让另一半更差，没有指标几乎是盲人摸象。

第三类是"重功能、轻成本"。把各家开源产品的功能全部"缝合"到自己系统里，实体抽取、意图识别、多轮改写、图谱构建全都上。功能列表很漂亮，但每个模块都在增加延迟和算力成本，最后用户问一个问题要等十几秒，而且复杂模块之间的互相干扰很难排查。

这三种弯路的共同根源，是缺少一个从全局视角出发的、"别人已经验证过"的参考架构。而开源RAG产品恰好提供了这个参考。

1.2 逆向工程在软件领域为什么可行

逆向工程之所以在RAG领域尤其有效，是因为RAG本身并不是一个"全新算法"，而是多个成熟技术的工程化组合。它涉及解析、存储、检索、排序、生成、评估等多个环节。每个环节单独看都不神秘，但组合起来却有大量工程细节。

这些细节，论文里通常不会写，官方文档也往往一带而过——比如分块时保留文档原始层级，比如查询改写要维护一个独立于知识库的提示词体系，比如重排模型的得分不能直接和相似度阈值比较。但开源产品的代码里全是答案，它们是开发团队用真实业务数据和线上反馈一点点调出来的。

所以，从六款开源产品里"逆向"出公共骨架，本质上是在吸收一群资深工程师踩坑后的沉淀。这比从零开始自己摸索要高效得多。

2. 六款开源产品怎么选，它们的架构差异在哪里

2.1 选样标准：覆盖完整链路而不是只看名气

选这六款，不是因为它们最火，而是因为它们各自解决了RAG链路里一个"关键卡点"，并且互相之间有明显差异。我的筛选标准有三个：

• 完整覆盖RAG关键链路，不是只有其中一两环；
• 技术路线有差异，能从不同角度提供启发；
• 社区活跃、有大量真实部署案例，避免"纸面产品"。

我选了RAGFlow、Dify、FastGPT、QAnything、MaxKB、LightRAG/GraphRAG这两个图谱增强路线，其中LightRAG和GraphRAG归为一类来讲，因为它们解决的问题相同，思路也相近。加上它们刚好是六个维度。

2.2 五条不同的技术路线

这六类产品背后的路线差异，我用一张表来总结：

这五条路线的本质差别在于对"文档上下文"的组织方式不同。RAGFlow和MaxKB更重视"文档进来之后怎么处理"，Dify更重视"知识库和上层应用怎么衔接"，QAnything更重视"召回之后怎么精排"，图谱方案则走了一条完全不同的路——不再依赖向量相似度，而是用实体关系网络来做推理。

这提醒我们：自研时不要一开始就锁定某一种路线，而是先想清楚自己业务里的瓶颈在哪一环，再去对号入座。

3. 逐款拆解：每一款产品最值得偷师的模块

3.1 RAGFlow：文档解析的尽头是版面理解

RAGFlow给我最大的启发，是它把"文档解析"从预处理步骤提升到了核心能力的高度。大多数开源产品对PDF的处理还停留在按页抽文字、按字符切分，而RAGFlow在进入分块前，先做了一套完整的版面分析：识别标题层级、段落边界、表格区域、图片位置，还原文档的原始阅读顺序。

这套设计对自研的启发有两层：

第一，解析结果的粒度决定了后续检索质量的上限。如果文档解析时就把表格硬拆成一行行散文本，那后续分块和向量化做得再好，检索出来的也是断裂内容。RAGFlow的做法是：表格先以结构化单元（Markdown或HTML）保存，正文按语义段落保存，图片通过视觉模型生成描述文字，再统一进入切块流程。

第二，版面分析可以大幅提升"引用溯源"的准确性。当用户问"这个数据来自哪个章节"，RAGFlow能定位到原始版面区块，而不是只抛出一段拼接文本。自研RAG如果不想一上来就做完整的版面分析，可以先从"保留标题路径"开始——让切出来的每个chunk都带着章、节、小节的路径信息，这在召回展示时帮助很大。

3.2 Dify：知识库管理和检索编排的样板

Dify给我的感觉是"平台味"最重的一个。它不只是RAG引擎，更是一套围绕知识库的管理和编排层。它把知识库生命周期的各个环节都做成了可配置项：数据导入方式、分段规则、索引方式、检索设置、召回策略、重排模型。这里有两个点对自研特别有参考价值。

一是"检索设置"的精细化。同一套文档，不同场景对检索的容忍度完全不同。业务问答里用户直接要答案，召回精度优先；知识库内部检索管理员想尽可能多地找到相关内容，召回率优先。Dify把这些差异做成了知识库级别和检索参数配置：top_k大小、相似度阈值、Score阈值、召回策略等。自研时，把这些参数做成系统可配置项而不是写死在代码里，能省掉大量后续调优沟通成本。

二是分段（Chunking）规则的半自动化。Dify的系统默认分段并不复杂，但提供了很强的自定义空间，包括文本分段标识符、最大分段长度、重叠长度，还支持父子分块模式——父块负责上下文语义，子块负责精确匹配。这让知识库管理员可以根据文档类型去微调，而不需要动代码。

Dify的另一个可借鉴点是它的"知识库隔离"思路。多个知识库之间可以设置独立权限和独立检索范围，问答时可以指定检索某一个或某几个。这种设计在自研系统里很容易被忽略——往往一个库打天下，后续权限、合规问题全冒出来。

3.3 FastGPT：问题分类与知识库路由

FastGPT这个名字暗示了它的路线：快、直接、以问答为目标。它最打动我的功能是"问题分类器"和"知识库路由"。

RAG问答系统里有一种常见场景：用户的问题根本不需要走向量检索。比如用户问的是"你们支持哪些格式"，这个问题的答案可能在系统配置里；再比如用户问的是"你是谁"，这属于闲聊；还有一些流程类问题，需要走工作流而不是查知识库。FastGPT通过一个前置分类模块，把问题先做意图分流，再决定是否触发知识库检索，以及检索哪个知识库。

这个设计解决了一个被很多人忽略的问题：不是所有问题都适合向量检索。对于一个垂直业务的自研RAG来说，问题路由的价值比想象中大得多。它可以：

• 避免把闲聊问题送进检索链路，省掉无效计算；
• 把不同领域的问题路由到对应知识库，缩小检索范围，提升精度；
• 为"兜底回复"留出空间，当所有知识库的置信度都低时，走人工转接。

自研时不必做一个独立的模型来做路由。一个轻量分类提示词，让LLM判断问题类型并输出JSON结构，就足够覆盖大多数场景。关键是把这个环节放在检索之前，并让它可配置。

3.4 QAnything：把重排当一等公民

QAnything是网易有道开源的项目。它的核心思路是"两阶段检索"：第一阶段同时使用向量检索和BM25关键词检索，做多路召回；第二阶段用一个专门的Rerank模型，对召回结果统一打分排序。这个设计在RAG产品里不算稀奇，但QAnything把它做到了极致。

回看业界实践，许多自研RAG项目把重排当成可选项，甚至上线之初完全不加重排。这会带来一个明显问题：向量检索的Top-K结果和用户真正相关的尾部内容之间，经常存在错位。缩小chunk可以缓解，但会引入更多的噪音chunk；单纯加大Top-K又会让生成阶段返回太多无关内容，挤占上下文窗口。

QAnything把重排做成了标准服务，并配套了双向的Embedding和Rerank模型，其中最值得借鉴的是"召回+重排的指标分工"：召回阶段看召回率，尽量别漏；重排阶段看精度，把最相关的内容顶到前面。自研链路里，重排并不一定要自研模型，从HuggingFace上选一个合适的Rerank模型（比如BGE系列），封装成独立服务，就能获得极大的效果提升。

3.5 MaxKB：轻量嵌入与对话内检索

MaxKB走的是另一条路线：把RAG能力做得足够轻、足够易嵌入，让它可以作为模块被现有业务系统快速调用。它的默认架构不依赖庞大组件，支持一键部署，同时提供了函数调用能力和对话流程编排能力。

对自研团队的启发是"边界意识"。很多自研项目容易把系统越做越重——为了支持某个边缘功能，拆出一个独立服务，然后这个服务又需要额外运维。MaxKB的克制提醒我们：RAG核心链路之外的功能，能通过配置、函数、编排解决的问题，尽量不要做成核心模块。

MaxKB的"对话内检索"也很有意思。它不是一次性把知识库结果全塞进上下文，而是允许在多轮对话中动态追加检索。这对应了真实场景里用户逐步明确需求的过程——第一轮问"你们产品的定价"，第二轮追问"那企业版呢"。如果每次都是全量重检索，不仅成本高，而且容易丢失对话焦点。

3.6 GraphRAG与LightRAG：让RAG拥有全局视野

图谱方案针对的是普通向量RAG的一个硬伤：局部强、全局弱。当你问"这几类产品之间的关联是什么"或"如果A不成立，B和C会怎样"这类问题上，纯向量检索几乎无能为力，因为答案不藏在某一段文本里，而是要通过多段知识之间的连接关系推理出来。

GraphRAG的路线是用LLM从文档中抽取实体和关系，构建知识图谱，再做社区聚类和社区摘要，回答问题时先在实体网络上做局部搜索，再结合社区摘要做全局推理。LightRAG在此基础上做了简化，通过"局部+全局"双层检索，用更低的算力成本拿到类似的效果。

从自研角度看，图谱不是用来替代向量检索的，而是用来补位"关系密集型"问题。它适合的组织结构大致是：知识库内容之间有强关联、问题普遍涉及多实体比较、需要推理链。如果只是做简单的FAQ问答，图谱带来的额外成本和复杂性可能不值得。

更务实的做法是"向量为主、图谱为辅"的融合架构：先向量召回一批相关内容，再用图谱补充实体关系层面的信息，最后一起交给LLM生成。这样不会为了图谱而牺牲时效性和简洁性。

4. 六款产品背后的公共骨架：自研RAG的五层结构

拆完六款产品，我发现它们虽然形态各异，但骨架高度一致。这个公共骨架可以浓缩成五层结构，这也是自研RAG时值得照抄的部分。

4.1 文档接入层：解析、清洗、结构化、分块

文档接入层的目标是把原始文件变成干净的、语义完整的文本单元。它由四个步骤组成：

• 解析：根据文件类型选择不同解析器。PDF要处理扫描件识别与版面分析；Word/HTML要提取正文和结构；表格要按行列结构保存而不要拍平。
• 清洗：去掉页眉页脚、目录、重复文案、无意义空白、水印文本。页眉页脚如果不去掉，会变成每个chunk都带一段重复噪音，严重干扰向量相似度。
• 结构化：保留标题路径、章节层级、表格Markdown表示、图片描述。这步决定了后续引用溯源能力。
• 分块：在结构化基础上，按语义边界切块，设置合适的分块大小和重叠区间。父块保存上下文，子块承担精确匹配。

这层的质量，基本决定了整个系统的上限。RAGFlow、Dify、FastGPT都在这层投入了大量工程，但它们的实现思路可以各自借鉴。自研时，可以先用成熟解析器（比如Unstructured、PyMuPDF、Tika）搭建流水线，不要纠结于自研解析核心。

4.2 索引层：稠密向量+稀疏关键词的混合索引

索引层负责把chunk变成可检索的结构。公共骨架里，几乎所有产品都在用混合索引，而不是单纯的向量索引。

• 稠密向量索引：chunk文本经过Embedding模型转成向量，在向量数据库里按相似度检索。负责语义级召回。
• 稀疏关键词索引：用BM25这类算法按词频检索。负责精确关键词召回，尤其适用于人名、产品型号、特殊代码等向量模型覆盖不好的场景。

自研时落地方案很多：Elasticsearch既有BM25又有向量检索能力；Qdrant、Milvus可以搭配外置BM25服务；最简单的方案是先用SQLite+一个向量库+一个倒排索引把链路跑通。关键不是选哪个库，而是"两条召回路径必须都存在"，最终的召回结果要合并、去重、重排。

4.3 检索层：多路召回、查询改写与重排

检索层是六款产品差异最大的地方之一，但思路的一致性很高：不能让第一次向量检索的结果直接进入生成阶段。

标准做法可以总结为三步：

1. 查询改写：用户的原始问题往往口语化、有指代、缺少上下文。LightRAG和Dify都有类似的查询改写机制——先把问题扩充成多组检索词，同时保留原始问题。比如用户问"它的性能怎么样"，需要先想办法确认"它"指代哪个产品，再展开检索。
2. 多路召回：向量检索、BM25关键词检索、图谱检索并行或串联进行，每路召回Top-N，然后合并。
3. 重排：用交叉编码器模型对合并的候选重新打分。交叉编码器的精度高于向量相似度，但速度慢，只适合在候选集上做精排。

一个可以立刻用的查询改写提示词模板我放在下面，这也是我在项目里实际用过的：

你是检索词改写助手。根据用户问题和对话历史，生成最多三个独立的检索词。 要求：检索词面向知识库检索系统，必须具体、完整、包含关键实体名称。 输出格式：JSON数组，如["检索词1","检索词2","检索词3"]。 用户问题：{question} 对话历史：{history}

4.4 生成层：上下文窗口管理、提示词模板与引用溯源

生成层决定了检索出来的内容是否能被正确使用。这里有几个常见的坑：

• 把整个检索结果一股脑塞给LLM，不顾上下文窗口。正确做法是设置检索结果的最大字数占比，保留给LLM推理的空间。比如限制最终进入上下文的检索片段不超过1500字，超出部分宁可截断。
• 提示词模板太简单，只写"根据以下内容回答"。效果更好的模板会明确要求：优先使用检索内容，不编造；信息不足时明确回答不知道；引用的序号必须与检索片段对应。
• 忘记引用溯源。用户使用RAG产品时，最需要的东西是他能回去翻原文。在生成结果时带上引用序号，并最终映射到原文页和具体段落，这个能力是所有评测里用户满意度最高的一个。

4.5 评估优化层：离线指标与线上反馈闭环

最后一个公共模块是评估。Dify、FastGPT都有相对完整的调试和质检界面；QAnything也有评测报告模块。真正让我把它当成"必做项"的，是RAG系统在迭代中的特征：任何一次修改，效果都可能朝不同方向漂移，离线不能评估，就完全没法迭代。

做评估可以分两步起步：

第一步，做一套低成本人工评估集。选50-100条真实问题，标注标准答案、支持性引用文档、正确回答；把"忠实度、相关性、答案完整性"三个维度做成打分表。

第二步，接入RAGAS这类开源评估框架，让LLM充当裁判，对回答质量做自动化评估。RAGAS提供了Faithfulness、Answer Relevancy、Context Precision等指标，可以直接对测试集批量评估。

评估不是上线前一次性的动作，而是要固化在知识库更新和检索参数调优的全流程里。没有评估集，后面所有优化都像在黑夜里调音量。

5. 逆向成果落地：一套可复用的自研RAG蓝图

5.1 分层架构与数据流设计

我基于上面五层结构，整理出一个较完整的自研RAG分层架构。这里尽量保持简单，强调可落地性。

接入层（文件上传 → 解析 → 清洗 → 结构化 → 分块） ↓ 索引层（Embedding向量化 ↵ BM25倒排索引 → 写入向量库/索引库） ↓ 检索层（查询改写 → 多路召回 → 合并去重 → 重排） ↓ 生成层（上下文组装 → 提示词模板 → LLM生成 → 引用溯源） ↓ 应用层（问答接口 → 管理后台 → 反馈收集 → 评估闭环）

各层之间通过标准接口连接：接入层输出统一的"文档单元"对象，包含内容、标题路径、元数据和分块关系；检索层输出带评分和来源的候选片段；生成层只消费候选片段和提示词参数。这种数据流设计有两大好处：

• 每一层可以由不同组件实现，后续替换成本低。今天用PostgreSQL的pgvector，明天换Qdrant，不需要动其他层。
• 每一层可以独立验证。接入层可以单独测试某一个PDF的切块质量；检索层可以单独压测召回率；生成层可以单独评测回答忠实度。

5.2 组件选型对照：自研与替换的边界

组件选型是自研团队每天都会面临的问题。我按踩过的坑，给一份比较务实的选型对照表：

很多人会在选型上纠结很久。我的经验是：选型的核心不是"哪个最好"，而是"替换成本够不够低"。只要接口统一，先随便选一个跑通，再根据评测结果替换，才是最快路线。

5.3 最小可用版本的实现路线

如果从零开始做一个自研RAG的MVP版，我会按这个顺序推进：

1. 先用Python脚本接入开源解析库，实现"PDF/Word/HTML → 清洗 → 递归字符分块"的流水线。分块参数先用经验值：500字左右，重叠100字。
2. 用BGE-M3生成向量，写入pgvector（或Chroma）；同时用SQLite FTS5存一遍原文关键词索引。
3. 实现一个检索接口：改写查询 → 向量召回Top-20 → BM25召回Top-20 → 合并去重 → 用BGE-Reranker重排取Top-5。
4. 写一个生成接口：把Top-5片段按提示词模板发给LLM，输出时以[1]-[5]标注引用序号。
5. 用RAGAS框架搭建离线评测，导入50-100条业务问答，跑基准效果。
6. 再根据评测结果回头调分块策略、召回数量、提示词。

按这个顺序走，通常两周内就能跑出一个效果初步可用的RAG基础版。如果团队里有人之前完全没接触过RAG，这个MVP过程本身就是最好的学习路径。

6. 自研落地必须跨过的四个实操坑

6.1 分块大小该定多少：从"RAG知识库"谈起的参数调优

在看了大量开源项目的讨论和实际案例后，我可以说：根本不存在一个适用于所有场景的分块大小。常见建议从200到800字都有，关键是看你的文档类型和用户问题的特点。

• 如果文档是产品说明书：每段本身语义完整，直接按段落分块优于按固定字数硬切。chunk大小可以放宽到800字。
• 如果文档是合同或制度文件：条款之间有强引用关系，更适合父子分块。父块是整个条款段落，子块是条款内的句子。
• 如果用户问题偏短、偏实体化（比如"型号A和型号B的区别"）：chunk太大容易把答案淹没在其他信息里，需要更小的chunk配合重排。

一个可行的经验法则是：先用固定字数（400-500字）跑一遍基线，再用评测集观察失败case，然后针对失败类型调整策略，而不是一开始就追求最优参数。

6.2 图片和表格到底能不能存进RAG知识库

这个问题在"RAG知识库"相关讨论里的出现频率很高。我的回答是：可以，但不能用常规方式。

纯文本向量化对图片天然失效。正确做法是有两条路：

• 图片辅助路径：用OCR或视觉语言模型（比如Qwen-VL、MiniCPM-V）提取图片中的文字信息，生成详细的图注和描述文本，再把描述文本向量化。用户后续的问句中只要涉及图片内容，就能通过描述文本检索到。
• 表格结构化路径：表格不要转成纯文本行流，要保留成Markdown表格或HTML，按行列关系保存。检索时把表格对应的文字说明作为主检索单元，表格本身作为附件随候选片段一起返回。

自研时最好设计一个"多模态文档单元"：一个单元可以同时包含文字块和图片/表格对象。这样检索只作用于文字描述，生成时再按需携带图片或表格进上下文。

6.3 知识图谱不是银弹：kg与向量检索的适用范围边界

自打"kg知识库""ontology rag"这类热度起来之后，不少人也在问：我要不要给自研RAG直接上知识图谱方案？

我的判断标准是看问题的"密度"。如果业务里的典型问题都是"XX是什么""XX和YY谁更适合我""怎么做XX"这类局部查询，向量RAG足够了。但如果你经常遇到"为什么这个环节影响了那个环节""哪些因素共同决定了这个结果"这类跨实体推理问题，知识图谱才有必要引进来。

另外还需要考虑成本。GraphRAG构建图谱的算力开销比普通向量索引高很多倍，而且需要定期随文档更新重建。更合理的起步方式是在向量检索召回之后，叠加一个"关系补充"环节：对召回片段做一次轻量实体链接，顺便抽取相邻实体关系，补进上下文。先用小成本验证图谱对效果的增量，再做完整图谱模块。

6.4 macOS本机搭建RAG环境的可行性方案

很多人习惯用自己的Mac本机先搭RAG试验环境。这事完全可行，但要提前跳过几个坑。

最稳的本地方案是：Ollama跑Embedding和LLM模型，搭配Chroma或Qdrant作为向量库，再用FastGPT或MaxKB作为界面和管理层。具体到Mac上实践时，有几个经验可以分享：

• 内存是硬约束。7B量级的量化和13B量化模型在同一台机器上同时跑Embedding和生成，内存16GB会比较吃紧。建议Embedding用轻量模型（如BGE-Small），生成时才切换大模型，或者用远程API做生成。
• Python环境建议直接用虚拟环境管理工具，不要直接在系统Python上装依赖，别问我是怎么知道的。分块、向量化、评测这些依赖一旦冲突，排查起来特别费时间。
• macOS上跑PDF解析，注意扫描版PDF需要额外装OCR相关库。如果不装，解析出来全是空文本，检索结果会非常迷惑。

如果在Mac上先把这套MVP跑通了，后续迁移到服务器环境，基本就是换一个向量库连接字符串的事。

最后再聊一点个人的实际感受。逆向这六款开源产品时，我最大的体会是：自研RAG真正难的地方，不是某个算法环节有多高深，而是如何把解析、切块、索引、召回、精排、生成、评估这些"看起来都会"的模块，以正确的顺序和正确的边界组合在一起。开源产品把组合方式直接摆在了代码里，这是信息密度极高的参考素材。

如果你现在正准备自研RAG，我的建议很明确：不要从写第一个函数开始，先从拆第一份开源代码开始。选一款和你业务最接近的产品，把它的数据流画一遍，再对照这篇的五层结构和选型表，决定哪些环节自研、哪些环节用现成组件。先跑通MVP，再谈优化。这样走，至少不会把弯路完整地走一遍。