企业官网建设流程全解析

1. 引言：为什么需要 Wiki RAG

检索增强生成（Retrieval-Augmented Generation, RAG）已经成为大模型落地的主流范式：先从外部知识库检索相关片段，再交给大模型生成答案。它的基本假设是——把足够多的相关文本塞进上下文窗口，模型就能“读懂”并给出正确答案。这个假设在简单事实问答上基本成立，但在真实的企业知识库、技术文档、百科类语料上，传统 RAG 的短板会迅速暴露出来。

• 知识碎片化：向量检索返回的是一堆互不相关的文本块，模型需要自己“拼图”，容易拼错。一个 chunk 里可能同时出现三个不同主题的句子，也可能一个完整论点被切分到两个 chunk 里。
• 缺乏上下文：单个 chunk 往往脱离原文语境，导致答非所问。比如“该方案在 2023 年停止维护”这句话，脱离了所属章节，模型根本不知道“该方案”指的是什么。
• 多跳问题无力：像"某公司的创始人后来创办了哪家公司"这类需要串联多个实体的问题，传统 RAG 很难处理。单次向量检索只能召回与问题字面最相似的片段，无法沿着"公司 → 创始人 → 新公司"的链条逐跳推进。
• 知识更新滞后：文档更新后，向量库需要重新切分、重新嵌入，成本高。而且一旦切分策略变化，整个索引都要重建，历史 chunk 的语义边界也随之改变。
• 结构信息丢失：原始文档里的标题层级、目录、交叉引用、脚注，在切分成 chunk 之后几乎全部丢失，而这些恰恰是人类阅读时理解文档的重要线索。

Wiki RAG 正是在这样的背景下被提出的一种改进思路：用结构化的 Wiki 知识组织方式，替代或补充扁平的向量检索，让检索结果自带层级、关联和上下文。它借鉴了维基百科这类超文本知识库的组织经验——页面有标题、正文有章节、实体之间有链接，检索时先"找到正确的页面"，再"在页面内找到正确的段落"，最后"沿着链接看看还有没有相关信息"。## 2. 什么是 Wiki RAG

Wiki RAG 并不是某一个具体的开源库，而是一类以 Wiki 式知识组织为核心的 RAG 架构。它的核心思想是：把知识库组织成类似维基百科的结构——页面（Page）、章节（Section）、段落（Paragraph）、实体链接（Entity Link），检索时先定位到相关页面/章节，再在局部范围内做细粒度检索。

理解 Wiki RAG 需要抓住三个关键词：

• 层级（Hierarchy）：知识不是平铺的，而是"文档 → 页面 → 章节 → 段落"的树状结构。检索时自上而下逐层收敛，搜索空间从百万级 chunk 缩小到几十个段落。
• 链接（Link）：页面之间通过实体建立有向或无向的关联，形成一张知识图。这让检索可以"跳转"，而不只是"匹配"。
• 可寻址（Addressable）：每个知识单元都有稳定的标识（页面 ID、章节路径），答案可以精确引用到"某某页面的第几节"，天然具备可解释性。

从学术脉络上看，Wiki RAG 并不是凭空出现的概念，它站在几条研究线的交汇处：一是结构化检索增强（把文档结构引入检索），二是图增强 RAG（GraphRAG 系列工作），三是多跳问答（HotpotQA 等基准推动的迭代检索研究）。后文第 3 节会专门梳理这些论文与 Wiki RAG 的关系。

一个典型的 Wiki RAG 流程如下：

与传统 RAG 相比，Wiki RAG 的关键差异在于多了一层"知识结构"：

3. Wiki RAG 的核心组成

3.1 知识结构化层

Wiki RAG 的第一步是把原始文档“Wiki 化”：为每个文档建立页面，页面下划分章节，章节下保留段落，并为关键实体建立双向链接。这一步通常借助大模型自动完成——让模型抽取实体、生成摘要、建立关联。

具体来说，结构化处理一般包含四个子步骤：

1. 页面切分：按文档的自然边界（标题、目录、分页）切出页面，而不是按固定字符数硬切。
2. 章节树构建：解析 Markdown/HTML 的标题层级，还原出“一级标题 → 二级标题 → 三级标题”的树，每个节点记录自己的路径（如产品手册/安装指南/Linux 环境）。
3. 实体抽取与链接：用大模型或 NER 模型从段落中抽取实体（人名、产品名、术语），并在页面之间建立链接。链接可以是显式的（原文中的超链接、引用），也可以是隐式的（模型判断两个页面讨论同一实体）。
4. 摘要生成：为每个页面和章节生成一句话摘要，作为粗检索的索引内容，同时也能在上下文组装时提供“导航信息”。

这一步的质量直接决定了整个系统的上限。实践中常见的坑是：标题层级不规范导致章节树错乱、实体抽取过度导致链接爆炸、摘要过于笼统导致粗检索失效。

3.2 层级索引

索引不再是单一的向量库，而是多级索引：

• 页面级索引：页面标题 + 摘要的向量，用于快速定位相关页面。
• 章节级索引：章节标题 + 关键句的向量，用于缩小范围。
• 段落级索引：原始段落的向量，用于精确召回。
• 图索引：实体之间的链接关系，用于多跳扩展。

3.3 检索与路由

查询到来后，系统先判断问题类型：是单点事实查询，还是需要跨页面推理的多跳问题。前者走“页面 → 段落”的直线路径，后者则沿实体链接做图遍历。

3.4 上下文组装与生成

最终交给大模型的不是零散 chunk，而是结构化的上下文块：包含页面标题、章节路径、相关段落以及关联页面摘要。这让模型更容易理解信息之间的从属与关联关系。

4. Wiki RAG 的优点

• 上下文更完整：检索结果自带层级路径，模型能理解“这段话属于哪个主题的哪个部分”，减少断章取义。
• 多跳推理更强：借助实体链接，可以自然地串联多个页面，处理复杂关联问题。
• 检索精度更高：先粗后细的两阶段检索，避免在大规模向量库中“大海捞针”。
• 可解释性更好：答案可以追溯到具体页面和章节，便于人工核查。
• 增量更新友好：文档更新时只需重建对应页面，不必全量重嵌入。
• 知识复用性高：Wiki 结构本身可被多个下游任务复用，如问答、摘要、推荐。

5. Wiki RAG 的缺点

• 构建成本高：需要额外的结构化处理（实体抽取、链接建立、层级划分），前期投入远大于传统 RAG。
• 结构质量依赖模型：自动生成的 Wiki 结构可能有错误链接或错误摘要，错误会沿检索链路放大。
• 实现复杂度高：多级索引、图遍历、路由判断都需要工程实现，调试难度大。
• 对简单问题可能"过度设计"：对于单点事实查询，Wiki RAG 的额外开销未必划算。
• 维护成本高：知识结构需要持续维护，链接失效、页面过时都会影响效果。
• 冷启动困难：知识库规模较小时，Wiki 结构的优势难以体现。## 6. 与传统 RAG 的对比

6.1 检索粒度对比

传统 RAG 的检索粒度是固定 chunk，切分策略（按字符、按语义）决定了召回质量，但 chunk 之间彼此孤立。Wiki RAG 的检索粒度是动态的：先定位页面，再在页面内检索，粒度随问题自适应。

6.2 上下文质量对比

传统 RAG 返回的是“片段集合”，模型需要自行推断片段间关系；Wiki RAG 返回的是“带结构的上下文”，片段之间的从属、并列、引用关系是显式的。这在需要综合多段信息的问答中差异明显。

6.3 多跳能力对比

这是两者差距最大的地方。传统 RAG 处理多跳问题通常依赖“迭代检索”（多次查询），但每次查询都是独立的，容易丢失中间实体。Wiki RAG 通过实体链接天然支持图遍历，多跳路径清晰可控。

6.4 成本与收益对比

结论：如果业务以简单事实问答为主、知识库更新频繁、团队资源有限，传统 RAG 是更务实的选择；如果业务涉及复杂关联推理、对可解释性要求高、知识相对稳定，Wiki RAG 的投入更值得。

7. 实践建议与选型思路

1. 先跑通传统 RAG 基线：不要一上来就上 Wiki RAG，先用传统方案验证业务价值。
2. 按问题类型分层：对简单查询走传统路径，对复杂查询走 Wiki 路径，做混合路由。
3. 结构自动化但可人工校正：用大模型生成 Wiki 结构，同时保留人工审核入口。
4. 控制结构粒度：页面不宜过细，章节不宜过碎，否则检索开销会急剧上升。
5. 建立评估体系：分别评估单跳、多跳、跨页面问题的准确率，用数据驱动选型。## 8. 总结

Wiki RAG 本质上是用知识结构换检索质量：它通过页面、章节、实体链接等 Wiki 式组织，弥补了传统 RAG 在上下文完整性和多跳推理上的短板，代价是更高的构建与维护成本。

它不是传统 RAG 的替代品，而是在特定场景下的增强方案。理解两者的边界，根据业务的问题复杂度、知识稳定性和团队资源做取舍，才是落地的关键。