企业官网建设流程全解析

1. 从六款开源RAG产品里，我逆向出了一套自研蓝图

做RAG（检索增强生成）自研这件事，我前前后后折腾了快一年。最开始的想法很简单：开源方案这么多，随便挑一个改改就能用。结果真上手才发现，每个开源项目都像一间装修风格完全不同的房子——有的水电走得漂亮但家具拉胯，有的外观唬人但承重墙是假的。你没法直接把客厅搬到另一个户型里，得先看懂它的结构逻辑，再决定哪些能复用、哪些必须重做。

这篇文章要聊的，就是我带着团队把六款主流开源RAG产品逐一拆解之后，逆向出来的一套可复用的自研蓝图。所谓“六款”，覆盖了从轻量级原型框架到企业级全链路平台的不同形态，有偏检索的、有偏编排的、有偏评测的。我不打算罗列每个产品的功能对比表，那种内容网上太多了。我更想讲的是：每一款产品在架构上做的关键取舍，以及这些取舍背后暴露出的、自研时一定会踩的坑。

适合谁看？如果你正在评估“到底该基于开源改还是完全自研”，或者已经决定自研但不知道从哪一层开始动手，那这篇内容应该能帮你省下至少两三个月的试错时间。如果你只是想知道RAG的基本原理，那可能去读几篇入门综述更合适——这里聊的全是工程落地层面的东西。

先说一个核心判断：开源RAG产品最大的价值不是代码本身，而是它们用不同方式回答了同一个问题——检索、编排、生成这三段到底该怎么切、怎么连、怎么控。把这六个答案放在一起看，自研的蓝图自然就浮出来了。

2. 六款产品的架构拆解与关键取舍

2.1 为什么选这六款而不是别的

市面上开源RAG项目少说几十个，我选这六款的标准有三条。第一，架构差异要足够大，不能全是同一套LangChain套壳，否则拆完学不到新东西。第二，至少有一层做得特别深，比如有的检索层支持十几种召回策略，有的编排层能做到节点级容错，这种深度才值得逆向。第三，社区活跃度要能支撑长期参考，不然拆完没多久项目就停更了，经验也过期了。

具体来说，这六款分别代表了六种典型形态：轻量级链式框架、模块化检索平台、可视化编排引擎、企业级全链路系统、评测驱动型框架、以及面向特定场景的垂直优化方案。我不会点名具体项目，但后面讲到每一层设计时，你会看到它们各自的身影。

提示：选开源项目做逆向参考时，不要只看Star数。Star高只能说明营销做得好或者入场早，真正要看的是Issue区里维护者的回复质量、最近半年的Commit频率、以及文档里有没有讲清楚“为什么不这么做”。

2.2 检索层：从单路召回走向混合路由

六款产品在检索层的差异是最明显的。最轻量的那款只支持向量检索，连BM25都没集成，好处是代码极简、上手快，坏处是一旦遇到需要精确匹配的场景（比如查订单号、产品型号）就抓瞎。而做得最重的那款，检索层里塞了向量、关键词、图检索、甚至SQL查询四种通道，还带了一个路由决策模块来决定每次查询走哪条路。

我逆向下来的结论是：检索层的核心不是“支持多少种召回方式”，而是“怎么决定用哪种”。那款轻量框架之所以只做向量检索，是因为它的目标场景是语义问答，查询和文档之间没有精确匹配的需求。而那款重检索平台之所以要做路由，是因为它的用户查询类型太杂了——有人问概念，有人查数据，有人找关系。

自研时我的建议是：先做向量+关键词的双路召回，但不要急着上路由。路由决策本身需要大量标注数据来训练，冷启动阶段用简单的规则（比如查询里包含数字或引号就走关键词优先）就够了。等积累了几千条真实查询日志，再考虑用分类模型做路由。

2.3 编排层：链式、图式与事件驱动的分野

编排层是六款产品分化最严重的地方。三款用的是链式编排——把检索、重排、生成串成一条流水线，简单直接，但一旦中间某步失败，整条链就断了。两款用的是图式编排——节点和边可以动态组合，支持条件分支和循环，灵活但调试成本高。还有一款用的是事件驱动——每个环节发布事件，下游订阅处理，解耦最彻底，但追踪一次请求的完整路径特别费劲。

我实际用下来的感受是：链式编排适合POC阶段，图式编排适合业务逻辑复杂的场景，事件驱动适合多团队协作的大系统。但这里有个隐藏的坑——图式编排的“灵活”是有代价的。你可以在图上画出任意复杂的流程，但每多一个分支，测试用例就翻一倍。我们曾经在一个图式编排的RAG系统里加了七个条件分支，结果回归测试跑了四十分钟，后来不得不把一部分逻辑下沉到检索层去。

2.4 生成层：Prompt模板、上下文压缩与引用溯源

生成层看起来最简单，不就是把检索结果塞进Prompt然后调模型吗？但六款产品在这一层的设计差异，恰恰暴露了自研时最容易忽略的问题。

最基础的那款直接把Top-K文档拼接后塞进Prompt，没有任何压缩。结果就是Token消耗巨大，而且模型经常被无关内容带偏。做得好的那款在生成前加了一个上下文压缩模块——先用一个小模型对检索结果做摘要和去重，再送给大模型生成。还有一个细节是引用溯源：生成的内容里每个事实性陈述都要能追溯到具体的文档片段，这需要在Prompt里设计特殊的标记格式，并在后处理阶段做解析。

我踩过的一个坑是：早期自研时为了省事，把引用标记直接写在Prompt里让模型自己输出。结果模型经常编造引用编号，或者把不相关的片段标成来源。后来改成先生成内容、再用规则匹配回原文的方式，准确率才上来。这个经验后面会展开讲。

3. 自研蓝图的核心模块设计

3.1 整体架构：三层解耦加一个控制面

逆向完六款产品后，我画出的自研蓝图是这样的：检索层、编排层、生成层三层解耦，上面加一个控制面负责配置、监控和评测。三层之间通过标准化的数据契约通信——检索层输出的是带分数的文档片段列表，编排层输出的是执行计划和中间状态，生成层输出的是带引用的最终答案。

为什么这么切？因为六款产品里，凡是把检索和生成耦合在一起的，后期想换模型或换检索策略都特别痛苦。而三层解耦之后，你可以单独替换任何一层——比如把向量库从一款换成另一款，或者把生成模型从一个小模型换成大模型，只要数据契约不变，上层逻辑完全不用动。

控制面是我从企业级那款产品里学来的。它不参与实际的请求处理，但负责几件关键事：配置管理（Prompt模板、检索参数、路由规则）、指标监控（延迟、召回率、生成质量）、离线评测（用标注数据集跑回归测试）。没有控制面的RAG系统，调参全靠手动改代码，上线后出了问题也不知道是哪一层的问题。

3.2 检索层设计：双路召回加可插拔重排

检索层的具体设计我建议这样：向量召回和关键词召回并行执行，各自返回Top-N结果，然后合并去重，再经过一个可插拔的重排模块。重排模块初期可以用简单的分数融合（比如加权求和），后期再换成Cross-Encoder模型。

这里有个参数需要仔细调：两路召回的Top-N怎么定。我的经验是，向量召回取Top-20，关键词召回取Top-10，合并后大概有25-30个候选，再送给重排模块取Top-5送给生成层。为什么向量多取一些？因为向量召回的语义匹配能力强，但精度不如关键词，多取一些能提高召回率。关键词召回精度高但召回率低，取少一些就够了。

重排模块的可插拔设计很关键。我们一开始用的是简单的加权融合，后来换成了一个小型Cross-Encoder，效果提升明显但延迟增加了三倍。所以重排模块必须支持降级策略——当延迟超过阈值时，自动切回加权融合。这个降级逻辑在六款产品里只有两款做了，但自研时一定要加上。

3.3 编排层设计：有限状态机加条件路由

编排层我最终选的是有限状态机加条件路由的方案，而不是完整的图式编排。原因很简单：图式编排的灵活性在RAG场景里大部分用不上，但它的复杂度是实打实的。有限状态机足够表达“检索→重排→生成→引用校验→输出”这条主流程，以及“检索失败→降级到关键词→再失败→返回兜底答案”这样的异常分支。

条件路由用在两个地方：一是查询分类，判断用户查询是事实型、分析型还是闲聊型，不同类型走不同的检索策略；二是生成后校验，如果引用溯源失败或者答案置信度低，就触发一次重新生成或人工审核。

状态机的每个状态都要有超时和重试配置。我们曾经遇到过一个case：检索层因为向量库连接池耗尽卡住了，整个请求挂了三十秒才返回超时。后来在每个状态上加了独立的超时控制，检索层最多等三秒，超时就降级到关键词检索。

3.4 生成层设计：模板管理加引用后处理

生成层的核心是Prompt模板管理和引用后处理。模板管理不是简单地把模板存在数据库里，而是要支持版本控制、A/B测试和变量校验。我们吃过亏：有一次改了一个模板变量名，忘了同步更新代码里的填充逻辑，结果线上所有请求的Prompt里都少了一段关键指令，生成质量直接崩了。

引用后处理的逻辑是这样的：生成层输出纯文本答案，同时输出一个“引用占位符”列表，每个占位符对应一个检索片段的ID。后处理模块拿到答案后，用正则匹配占位符，替换成实际的引用标记（比如上标数字），并生成引用列表。如果某个占位符在检索结果里找不到对应ID，就标记为“引用异常”，触发告警。

这套逻辑比让模型直接输出引用编号可靠得多。实测下来，引用准确率从60%左右提升到了95%以上。

4. 实操落地：从零搭建一个最小可行RAG系统

4.1 环境准备与依赖选型

假设你现在要从零搭一个最小可行的RAG系统，我建议的技术栈是这样的：向量库用轻量级的本地方案（比如基于FAISS或Annoy的封装），关键词检索用Whoosh或Elasticsearch的轻量模式，编排层用Python的状态机库（比如transitions），生成层直接调API。不要一上来就上Kubernetes和微服务，那是日活过万之后才需要考虑的事。

依赖安装这块，我列一个最小清单：

pip install fastapi uvicorn pip install sentence-transformers pip install faiss-cpu pip install whoosh pip install transitions pip install openai

这里解释几个选型理由。sentence-transformers做向量化，本地跑不用调API，延迟低且免费。faiss-cpu做向量检索，虽然GPU版更快，但CPU版在数据量小于百万级时完全够用。whoosh是纯Python的关键词检索库，不需要额外部署服务。transitions实现状态机，代码量比手写if-else少一半。

注意：不要用LangChain或LlamaIndex来搭这个最小系统。它们封装太厚，出了问题你根本不知道是哪一层的事。先用裸库把流程跑通，理解每一层的输入输出，之后再考虑用框架提效。

4.2 数据准备与索引构建

数据准备分三步：采集、清洗、分块。采集就是从你的数据源（文档、网页、数据库）把原始内容拉下来。清洗是去掉HTML标签、页眉页脚、重复段落。分块是最关键的一步——块太大，检索精度下降；块太小，上下文不完整。

我的经验值是：中文文档每块300-500字，英文文档每块150-250词。这个范围是多次实验后得出的——小于300字，很多段落被切碎，语义不完整；大于500字，向量表示会被稀释，检索时匹配度下降。分块时还要注意重叠窗口，一般设置10%-20%的重叠，防止关键信息正好落在切分点上。

索引构建的代码大概长这样：

from sentence_transformers import SentenceTransformer import faiss import numpy as np model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2') chunks = [...] # 分块后的文本列表 embeddings = model.encode(chunks, normalize_embeddings=True) dimension = embeddings.shape[1] index = faiss.IndexFlatIP(dimension) index.add(embeddings.astype('float32')) faiss.write_index(index, 'vector.index')

这里用的是内积索引（IndexFlatIP），因为向量已经归一化了，内积等价于余弦相似度。数据量超过十万条时，可以换成IVF索引来加速，但会损失一点精度。

4.3 检索与重排的代码实现

检索部分要同时跑向量和关键词两路：

def vector_search(query, top_k=20): query_vec = model.encode([query], normalize_embeddings=True) scores, indices = index.search(query_vec.astype('float32'), top_k) return [(chunks[i], scores[0][j]) for j, i in enumerate(indices[0])] def keyword_search(query, top_k=10): from whoosh.qparser import QueryParser with ix.searcher() as searcher: parser = QueryParser("content", ix.schema) q = parser.parse(query) results = searcher.search(q, limit=top_k) return [(r["content"], r.score) for r in results]

合并去重后，重排模块用简单的加权融合：

def rerank(vector_results, keyword_results, alpha=0.7): merged = {} for doc, score in vector_results: merged[doc] = alpha * score for doc, score in keyword_results: if doc in merged: merged[doc] += (1 - alpha) * score else: merged[doc] = (1 - alpha) * score return sorted(merged.items(), key=lambda x: x[1], reverse=True)[:5]

alpha参数需要根据你的数据调。语义问答为主的场景，alpha设0.7-0.8；精确匹配为主的场景，alpha设0.4-0.5。我们一开始设的0.7，后来发现用户查询里有很多产品型号，把alpha降到0.5之后召回率明显提升。

4.4 生成与引用后处理的完整流程

生成层的Prompt模板我建议这样设计：

你是一个基于检索结果回答问题的助手。请严格根据以下参考资料回答问题。 如果参考资料中没有相关信息，请直接说“根据现有资料无法回答”。 参考资料： {context} 问题：{question} 回答要求： 1. 每个事实性陈述后面用[1][2]这样的标记标注来源 2. 不要编造参考资料中没有的信息 3. 回答控制在200字以内

生成之后，后处理模块做两件事：引用校验和格式清理。引用校验是检查每个[数字]标记是否在检索结果范围内，格式清理是去掉多余的换行和空格。

import re def postprocess(answer, num_sources): citations = re.findall(r'\[(\d+)\]', answer) valid = [c for c in citations if 1 <= int(c) <= num_sources] if len(valid) < len(citations): # 有无效引用，触发告警 pass answer = re.sub(r'\n{3,}', '\n\n', answer) return answer.strip()

这套流程跑通之后，一个最小可行的RAG系统就搭好了。实测下来，在千级文档规模下，单次查询延迟在800毫秒左右，召回率（Top-5中包含正确答案的比例）在85%上下。

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

5.1 检索层高频问题速查

这里重点说向量模型不匹配领域这个问题。我们早期用的是一个通用多语言模型，在技术文档检索上表现还行，但换到医疗问答场景后召回率直接掉到50%以下。后来换了一个在医疗语料上微调过的模型，召回率回到80%以上。向量模型的选择比向量库的选择重要十倍，这是我最深刻的教训之一。

5.2 编排层异常处理经验

编排层最常见的异常是状态卡死和循环触发。状态卡死通常是因为某个外部调用没有设超时，比如向量库查询卡住了，整个状态机就停在那里。循环触发是因为条件路由的规则写错了，比如“检索失败→降级→再失败→再降级”形成了死循环。

我的处理方式是：每个状态强制设置最大执行时间和最大重试次数。在transitions库里的配置大概是这样：

from transitions import Machine machine = Machine( states=['idle', 'retrieving', 'reranking', 'generating', 'done', 'failed'], initial='idle' ) machine.add_transition('start', 'idle', 'retrieving', after='do_retrieve') machine.add_transition('retrieve_ok', 'retrieving', 'reranking', after='do_rerank') machine.add_transition('retrieve_fail', 'retrieving', 'failed', after='do_fallback')

然后在每个do_xxx函数里加超时装饰器。这样即使某个环节卡住，最多等三秒就会自动跳到失败状态，返回兜底答案。

5.3 生成层质量问题的排查思路

生成层的问题通常表现为：答案不准确、引用错误、格式混乱。排查顺序应该是：先看检索结果对不对，再看Prompt有没有问题，最后才怀疑模型。

我遇到过好几次“答案不准确”，最后发现是检索层返回的片段里包含了过时信息。模型忠实地根据过时信息回答了问题，但用户期望的是最新数据。这种情况不是生成层的问题，而是检索层缺少时间过滤。后来我们在检索时加了一个时间范围参数，默认只检索最近两年的文档。

引用错误的问题前面提过了，核心是不要让模型直接输出引用编号。让模型输出占位符，后处理阶段再替换，准确率会高很多。

5.4 性能优化的三个关键点

第一个关键点是向量化缓存。同样的查询如果重复出现，没必要每次都跑一遍向量化。我们加了一个LRU缓存，命中率大概在15%左右，但延迟降低了20%。

第二个关键点是批量检索。如果一次请求需要查多个子问题，不要串行查，用批量接口一次查完。FAISS支持批量查询，速度比循环单查快三到五倍。

第三个关键点是生成层的流式输出。用户不需要等完整答案生成完才看到内容，流式输出能把首字延迟从两秒降到三百毫秒。虽然总生成时间没变，但用户体验提升明显。

6. 从开源逆向到自研落地的几点体会

拆完六款产品再自己动手搭，最大的体会是：开源RAG产品的价值不在于代码能直接抄，而在于它们用不同方式回答了“检索、编排、生成怎么切”这个问题。你不需要认同任何一款产品的全部设计，但你需要理解它为什么这么设计，以及这种设计在什么场景下会出问题。

另一个体会是：自研RAG的难点不在算法，在工程。向量检索、关键词检索、Prompt工程，这些都有成熟方案。真正花时间的是异常处理、降级策略、监控告警、评测体系这些“脏活累活”。六款产品里做得最好的那款，代码量其实不大，但它的异常处理逻辑占了将近一半。

最后分享一个实用技巧：在自研早期就建立离线评测集。不用多，一两百条标注数据就够。每次改完检索参数或Prompt模板，跑一遍评测集，看召回率和准确率的变化。没有评测集的RAG自研，就像没有仪表盘的开车——你感觉在前进，但不知道方向对不对。我们是在踩了两个月坑之后才补上评测集的，补上之后调参效率至少提升了一倍。