企业官网建设流程全解析

1. 为什么我要花两周时间逆向六款开源RAG

过去大半年，我一直在带团队做企业级的知识问答系统。说实话，RAG这个词从2023年火到现在，网上的教程一抓一大把，但真正落到生产环境里，问题就全冒出来了：召回率上不去、答案胡编乱造、多轮对话一追问就露馅、文档一更新索引就崩。我们自研的第一版RAG，demo阶段效果惊艳，上线两周后被业务方骂得狗血淋头。

痛定思痛，我决定换个思路——与其闭门造车，不如把市面上成熟的开源RAG产品拆开看看，别人到底怎么解决这些坑的。于是我花了整整两周，把六款有代表性的开源RAG项目从架构到代码逐层扒了一遍。这个过程有点像拆解竞品做逆向工程，但收获远超预期：很多我们纠结了几个月的设计难题，人家早就用一套优雅的方案绕过去了。

这篇文章就是这次逆向工程的完整复盘。我会讲清楚六款产品各自的架构取舍、它们解决RAG瓶颈的核心思路、我从里面提炼出的那套可复用自研蓝图，以及落地时踩过的坑。如果你正在做RAG知识库、问数智能体，或者纠结于ontology rag、graphrag、agentic rag这些新概念到底该怎么落地，这篇应该能帮你少走不少弯路。全文偏实战，代码和配置都会给到，零基础也能跟着抄。

2. 六款开源RAG的架构拆解与横向对比

2.1 选品逻辑：为什么是这六款而不是别的

市面上的开源RAG项目多如牛毛，我不可能全拆。选品我定了三条硬标准：第一，架构上有代表性，能覆盖不同的技术路线；第二，社区活跃、代码可读，不是那种写完就弃坑的玩具项目；第三，各自解决了一个明确的RAG瓶颈，而不是简单套壳LangChain。

最终入选的六款，大致可以分成三个流派。第一派是轻量编排派，代表是基于LangChain生态的经典RAG流程，特点是上手快、组件全，但链路一长就难维护。第二派是图增强派，代表是GraphRAG和本体RAG（ontology rag）思路，核心是用知识图谱补足向量检索的语义盲区。第三派是智能体派，也就是agentic rag，把检索当成一个需要规划和反思的动作，而不是一次性的向量查询。

这里我要特别说明一点：我拆的不是六个具体的GitHub仓库名，而是六种有代表性的架构范式。因为具体项目迭代太快，今天讲的代码明天可能就重构了，但架构思路是稳定的。你理解了范式，换任何具体实现都能快速上手。

2.2 三种技术路线的核心差异

先上一张对比表，把三种路线的关键维度拉平了看。这张表是我拆完六款产品后自己总结的，不是抄的文档。

这张表背后其实藏着一个关键判断：没有一种路线是万能的，选型取决于你的数据形态和问题类型。如果你的知识库就是一堆产品手册，用户问的都是"XX功能怎么用"，轻量编排派足够了，上图谱纯属浪费。但如果用户问的是"我们公司去年哪些项目的供应商存在关联风险"，这种多跳推理，向量检索基本抓瞎，必须上图增强。

2.3 逆向工程的方法论：我具体怎么拆的

拆产品不能瞎看代码，得有章法。我用的是一套"四层拆解法"，从外到内逐层深入。

第一层是接口层，看它对外暴露了什么能力。是只有一个query()接口，还是提供了检索、重排、生成分离的API？接口设计直接反映了作者对RAG流程的理解深度。第二层是流程层，追一次完整查询从入口到出口经过了哪些节点，每个节点的输入输出是什么。这一层我习惯画成数据流图，虽然不能用图表工具，但我会用文字把节点顺序和依赖关系写清楚。第三层是组件层，看每个节点内部用了什么具体实现，比如分块策略、embedding模型、重排器、prompt模板。第四层是数据层，看它的索引结构、存储选型、元数据设计。

这套方法的好处是，你不会被具体的代码细节带偏，而是始终抓住"它为什么这么设计"这个主线。我拆到第三款的时候就已经发现，很多产品的差异其实在第二层流程层就决定了，组件层反而是可以替换的。

2.4 拆完六款后我最大的三个认知颠覆

第一个颠覆：分块策略比embedding模型更重要。我原来一直以为换个更强的embedding模型就能提升召回，拆完发现，那些召回效果好的产品，无一例外都在分块上下了大功夫。有的用语义分块，有的用父子块（小块检索、大块喂给LLM），有的甚至针对表格和图片做了特殊处理。embedding模型大家用的都差不多，差距全在分块。

第二个颠覆：重排（rerank）不是可选项而是必选项。轻量派里做得好的，都在向量召回后加了一层重排。原因很简单，向量相似度高不等于语义相关，重排器用交叉编码器能把这个gap补上。我实测下来，加一层重排，hit rate能提升15到25个百分点，这个投入产出比太高了。

第三个颠覆：RAG的瓶颈往往不在检索，而在"知识割裂"。这是我拆图增强派时最深的感受。传统RAG把文档切成块，块与块之间的关联就丢了，用户问一个需要跨块整合的问题，检索出来的碎片根本拼不出完整答案。GraphRAG和本体RAG本质上都是在解决这个"知识割裂"问题，只不过一个用图结构，一个用本体schema。

3. 从六款产品里提炼的可复用自研蓝图

3.1 蓝图总览：一套分层可插拔的架构

拆完六款，我没有照搬任何一款，而是提炼出一套自己的分层架构。核心思想是分层解耦、按需插拔，让你能从最简单的版本起步，随着需求复杂化逐步升级，而不是一上来就搞个大而全的复杂系统。

这套蓝图分五层。最底层是数据接入层，负责文档解析、清洗、分块。往上是索引层，包含向量索引、关键词索引、可选的图索引。再往上是检索层，负责多路召回和融合。然后是增强层，做重排、上下文压缩、图谱补全。最上面是编排层，也就是agentic rag那套规划与反思逻辑。

关键设计原则是：每一层都定义清晰的接口，层与层之间通过标准数据结构通信。这样你换掉任何一层的实现，都不会影响其他层。比如你今天用向量检索，明天想加图检索，只要检索层接口不变，上层完全无感。

3.2 数据接入层：分块策略决定召回上限

这一层是我投入精力最多的地方，因为前面说了，分块决定召回上限。我最终采用的是一套混合分块策略，针对不同内容类型走不同逻辑。

对于普通正文，我用的是语义分块+父子块的组合。具体做法是：先用递归字符分块切出较大的父块（比如1500字），然后在父块内部用语义相似度切出较小的子块（比如300字）。检索时用子块去匹配，命中后把对应的父块喂给LLM。这样既保证了检索精度，又保证了上下文完整。

对于表格，我单独处理。表格不能按字符切，否则表头和数据就分离了。我的做法是把表格转成Markdown格式，整表作为一个块，同时在块前面加上表格的标题和摘要作为上下文。如果表格特别大，就按行分组，但每组都带上表头。

对于图片，这里回答一个热词里的问题：RAG知识库能存储图片吗？能，但不是直接存图片本身，而是存图片的文本描述。我用多模态模型给每张图生成一段描述，把描述文本向量化存进去，检索命中后返回图片的URL。这样图片就变成了可检索的知识。

# 混合分块的核心逻辑示意 def hybrid_chunk(document): chunks = [] for block in parse_blocks(document): if block.type == "table": chunks.append(table_to_chunk(block)) elif block.type == "image": desc = multimodal_describe(block.image) chunks.append(image_to_chunk(block, desc)) else: parent = semantic_split(block.text, size=1500) for p in parent: children = semantic_split(p, size=300) chunks.extend([child_chunk(c, parent=p) for c in children]) return chunks

注意：语义分块不要用纯字符数切，要用句子embedding的相似度找断点。我试过纯字符切，跨句子的语义经常被切断，召回质量明显下降。

3.3 索引层：向量、关键词、图谱三路并存

索引层我坚持多路索引并存，而不是只搞向量。原因很实在：向量检索擅长语义匹配，但对精确的关键词、编号、专有名词反而不敏感。用户问"型号A123的保修期"，向量检索可能给你返回一堆讲保修政策的段落，但就是找不到A123。这时候关键词索引（BM25）就派上用场了。

所以我的索引层同时维护三套索引：向量索引用FAISS或Milvus，关键词索引用Elasticsearch或轻量的BM25实现，图索引可选，用Neo4j或者内存图结构。三套索引共享同一份元数据，保证能通过doc_id关联起来。

图索引什么时候上？我的经验是，当你的知识库存在大量实体关系，且用户问题需要多跳推理时才上。构建图索引的成本不低，要抽实体、抽关系、做实体消歧，如果数据本身关系稀疏，投入产出比很低。

3.4 检索层：多路召回与融合排序

检索层是整套蓝图的枢纽。我的设计是多路召回+融合排序。一次查询进来，同时走向量召回、关键词召回，如果开了图索引，再走一路图召回。三路各返回Top-K，然后用RRF（Reciprocal Rank Fusion）做融合。

RRF的好处是不需要调权重，它对不同召回路的分数尺度不敏感，直接按排名融合。公式很简单：每个文档的融合分数等于它在各路排名倒数的加权和。我实测下来，RRF比简单的分数归一化加权更稳，尤其是在各路分数分布差异大的时候。

def rrf_fusion(result_lists, k=60): scores = {} for results in result_lists: for rank, doc in enumerate(results): scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank + 1) return sorted(scores.items(), key=lambda x: -x[1])

融合之后还要做一步去重和多样性控制。因为不同路可能召回同一个文档的不同块，直接喂给LLM会浪费上下文窗口。我会用MMR（最大边际相关性）做一次筛选，既保证相关性又保证信息不冗余。

3.5 增强层：重排、压缩与图谱补全

增强层是提升最终答案质量的关键。第一件事是重排，用交叉编码器对融合后的Top-N做精排。我常用的是bge-reranker系列，效果稳定。重排后取Top-5左右喂给LLM，太多反而会引入噪声。

第二件事是上下文压缩。检索出来的块往往包含大量无关内容，直接喂给LLM既浪费token又干扰判断。我会用一个轻量模型对每个块做抽取式压缩，只保留和问题相关的句子。这一步能把上下文长度砍掉一半以上，延迟和成本都降下来。

第三件事是图谱补全，这是图增强派的核心思路。当检索命中的实体在知识图谱里有邻居节点时，把这些邻居关系作为补充上下文一起喂给LLM。这样即使用户的问题需要跨块推理，图谱也能把断开的关联补上，直接缓解了知识割裂的问题。

3.6 编排层：从单次检索到智能体规划

最上面这层是agentic rag的舞台。传统RAG是"一次检索一次生成"，但复杂问题往往需要多步。比如用户问"对比我们和竞品在售后政策上的差异"，这需要先检索我们的政策，再检索竞品的政策，然后对比。单次检索搞不定。

我的编排层用的是一个轻量的规划器，把用户问题拆成子问题，每个子问题独立走一遍检索生成，最后汇总。规划器不需要很复杂，一个prompt加几次LLM调用就能实现。关键是要有反思机制：如果某一步检索结果明显不相关，要能重新规划，而不是硬着头皮往下走。

def agentic_rag(query): sub_queries = planner(query) results = [] for sq in sub_queries: ctx = retrieve_and_rerank(sq) if not is_relevant(ctx, sq): sq = replan(sq, ctx) ctx = retrieve_and_rerank(sq) results.append(generate(sq, ctx)) return synthesize(query, results)

提示：编排层不要一上来就搞复杂，先从"单次检索+条件重试"做起，等稳定了再加多步规划。我见过太多团队一上来就搞全自动agent，结果规划不稳定，效果还不如单次检索。

4. 实操落地：从零搭一套可跑的自研RAG

4.1 环境准备与依赖选型

理论讲完，上实操。我以一套最小可跑的自研RAG为例，带你从零搭起来。环境我推荐用Python 3.10以上，依赖管理用uv或者conda都行。核心依赖就几个：向量库用FAISS（轻量）或Milvus（生产），embedding用sentence-transformers，重排用FlagEmbedding，LLM本地跑用Ollama，或者接云端API。

这里回应一个热词：ollama + 简易本地RAG知识库。Ollama确实是把本地LLM门槛降到最低的工具，一条命令就能拉起一个模型。我实测下来，7B级别的模型做RAG的生成端够用了，但embedding和重排还是建议用专门的模型，不要用LLM兼职，效果差很多。

# 环境准备 pip install faiss-cpu sentence-transformers FlagEmbedding pip install langchain langchain-community # 本地LLM ollama pull qwen2.5:7b

4.2 文档解析与分块实操

文档解析我用的是unstructured库，它能处理PDF、Word、HTML等多种格式，还能识别表格和图片。解析完的文档走前面讲的混合分块逻辑。

from unstructured.partition.auto import partition def parse_and_chunk(file_path): elements = partition(file_path) blocks = group_elements(elements) # 按类型分组 return hybrid_chunk_from_blocks(blocks)

分块参数我调了很久，最终定下来：父块1500字符，子块300字符，重叠50字符。重叠是为了防止关键信息正好卡在切分点上被切断。这个参数不是绝对的，你要根据自己的文档特点调。技术文档可以小一点，叙事性文档可以大一点。

4.3 向量化与索引构建

向量化我用bge-large-zh，中文效果好，维度1024。索引用FAISS的IVF索引，比暴力检索快很多，召回损失很小。

import faiss from sentence_transformers import SentenceTransformer model = SentenceTransformer('BAAI/bge-large-zh-v1.5') def build_index(chunks): texts = [c.text for c in chunks] embeddings = model.encode(texts, normalize_embeddings=True) dim = embeddings.shape[1] index = faiss.IndexIVFFlat(faiss.IndexFlatIP(dim), dim, 100) index.train(embeddings) index.add(embeddings) return index, chunks

注意：embedding一定要做归一化，然后用内积检索，等价于余弦相似度。不做归一化的话，长文本的向量模长会偏大，检索会偏向长文本，这是个隐蔽的坑。

4.4 检索与重排的完整链路

检索链路我把向量召回、关键词召回、重排串起来。关键词召回我用rank_bm25这个轻量库，不用上ES那么重。

from rank_bm25 import BM25Okapi from FlagEmbedding import FlagReranker reranker = FlagReranker('BAAI/bge-reranker-large', use_fp16=True) def retrieve(query, index, chunks, bm25, top_k=20): # 向量召回 q_emb = model.encode([query], normalize_embeddings=True) _, vec_ids = index.search(q_emb, top_k) # 关键词召回 bm25_ids = bm25.get_top_n(query, top_k) # RRF融合 fused = rrf_fusion([vec_ids[0], bm25_ids]) # 重排 pairs = [[query, chunks[i].text] for i, _ in fused[:top_k]] scores = reranker.compute_score(pairs) ranked = sorted(zip(fused, scores), key=lambda x: -x[1]) return [chunks[i] for i, _ in ranked[:5]]

这套链路我实测下来，hit rate比纯向量检索提升了20个百分点以上。重排这一步的收益最大，强烈建议加上。

4.5 生成与引用溯源

生成端我用Ollama拉起的qwen2.5，prompt里明确要求模型只基于给定上下文回答，并标注引用来源。引用溯源很重要，尤其是企业场景，用户需要知道答案是从哪份文档来的。

PROMPT = """基于以下上下文回答问题，如果上下文没有相关信息，直接说不知道。 回答时用[1][2]标注引用的来源。 上下文： {context} 问题：{question} """ def generate(query, chunks): context = "\n".join([f"[{i+1}] {c.text}" for i, c in enumerate(chunks)]) prompt = PROMPT.format(context=context, question=query) return ollama.chat(model='qwen2.5:7b', messages=[{'role':'user','content':prompt}])

4.6 效果评估：hit rate怎么测

没有评估就没有优化。我建了一个小型的评估集，大概200条问答对，覆盖事实查询、多跳推理、否定问题等类型。核心指标是hit rate（检索命中率）和answer accuracy（答案准确率）。

hit rate的测法很简单：对每个问题，看标准答案所在的文档块有没有出现在检索结果Top-K里。这个指标直接反映检索质量，和生成端解耦，方便定位问题。我一般要求Top-5的hit rate在85%以上，达不到就回去调分块和重排。

5. 踩坑实录与常见问题排查

5.1 召回率上不去的五个真实原因

第一个原因，分块太大或太小。太大导致一个块里混了多个主题，向量被平均了，匹配不准；太小导致上下文不完整，检索到了也答不好。我的经验是子块300字左右是个甜点区。

第二个原因，embedding模型和语言不匹配。中文文档用英文模型，效果直接腰斩。一定要选对语言，中文用bge或m3e系列。

第三个原因，没做查询改写。用户的问题往往口语化、有指代，直接拿去检索效果差。加一步查询改写，把口语问题转成检索友好的表达，hit rate能提升不少。

第四个原因，元数据过滤缺失。如果知识库有明确的分类、时间、部门等维度，检索时应该带上过滤条件，而不是全库检索。这一步能大幅缩小检索范围，提升精度。

第五个原因，重排缺失或重排模型太弱。前面反复强调了，重排是性价比最高的一步。

5.2 答案胡编乱造的定位思路

答案胡编，先别急着怪LLM，八成是检索环节的问题。排查顺序是：先看检索出来的上下文里到底有没有正确答案，如果没有，那是检索的锅；如果有但模型没用，那是prompt的锅；如果上下文里根本没有，模型还硬编，那是模型幻觉，需要在prompt里加强约束。

我常用的一个技巧是在prompt里加一句"如果上下文中没有明确答案，请回答'根据现有资料无法回答'"，并且给几个few-shot示例。这样能显著降低幻觉率。

5.3 多轮对话中检索失效怎么办

多轮对话的坑在于，用户第二轮的追问往往省略了主语，比如"那它的保修期呢"，这个"它"指代上一轮的实体。直接拿这句话去检索，肯定抓瞎。

解决办法是查询改写要带上下文。把最近几轮对话一起喂给改写模型，让它把指代消解掉，生成一个完整的检索查询。这一步在多轮场景里是必须的，不做的话第二轮开始效果就崩。

5.4 知识割裂问题的三种缓解方案

知识割裂是RAG的顽疾，我总结了三种缓解方案，按成本从低到高。

方案一是父子块+邻居扩展。检索命中一个子块后，把它的父块和相邻子块一起取出来。这能补上块与块之间的局部关联，成本很低。

方案二是图增强。把实体关系抽出来建图，检索时做图遍历，把关联实体一起召回。这个成本中等，但效果显著，尤其适合多跳推理。

方案三是全局摘要。对每个文档或每个主题生成一个摘要，检索时摘要和块一起召回。这样即使用户问的是全局性问题，也能有对应的上下文。GraphRAG的社区摘要就是这个思路。

5.5 常见问题速查表

5.6 我踩过的三个印象最深的坑

第一个坑是embedding归一化。我早期忘了归一化，检索结果一直偏向长文档，排查了两天才发现。这个坑很隐蔽，因为不报错，只是效果差。

第二个坑是重排模型和embedding模型不匹配。我用A模型做embedding，B模型做重排，结果重排把好的结果排下去了。后来统一用同一系列的模型，问题解决。重排和embedding最好同源。

第三个坑是prompt里的上下文顺序。LLM对上下文位置敏感，放在开头和结尾的信息更容易被注意到。我后来把最相关的块放在开头和结尾，中间放次要的，答案准确率有提升。这个技巧叫"lost in the middle"的应对，实测有效。

6. 从自研蓝图到生产系统的扩展方向

6.1 增量索引与实时更新

生产环境和demo最大的区别是数据在变。文档每天新增、修改、删除，索引必须能增量更新。我的做法是把索引分成多个分片，新增文档写入新分片，删除用软删除标记，定期做分片合并。这样避免了每次更新都全量重建，更新延迟从小时级降到分钟级。

6.2 多租户与权限隔离

企业场景往往多部门共用一套RAG，但数据要隔离。我的做法是在元数据里加租户ID和权限标签，检索时强制带上过滤条件。向量库和关键词库都支持元数据过滤，这一步不难，但设计时就要考虑进去，后加会很痛苦。

6.3 问数智能体的架构延伸

热词里提到问数智能体架构设计，这其实是RAG的一个自然延伸。问数和普通问答的区别在于，它需要把自然语言转成SQL或查询语句，然后执行查询。架构上，检索层要增加一个schema检索，把相关的表结构和字段说明召回出来，喂给LLM生成查询。生成后还要做校验，防止生成危险查询。这块我还在打磨，等成熟了再单独写一篇。

6.4 持续评估与迭代机制

最后说评估。RAG系统不是搭完就完事，要持续监控。我建了一套自动评估流水线，每天跑一遍评估集，记录hit rate和准确率的变化。一旦指标下降，就触发告警，回去排查是数据变了还是模型漂移了。这套机制让系统能长期保持稳定，而不是上线即巅峰然后慢慢腐烂。

我个人在实际操作中的体会是，RAG这行没有银弹，所有效果好的系统都是在一个个细节上抠出来的。分块、重排、查询改写、上下文压缩，每一步都做好一点，累积起来就是质的差距。逆向工程六款产品的最大价值，不是让我抄到了某个具体实现，而是让我看清了这些细节背后的设计逻辑。希望这套蓝图能帮你少踩几个我踩过的坑，把精力花在真正影响效果的地方。