一篇讲透：RAG / GraphRAG / LLM-Wiki / PageIndex 在企业知识系统的融合应用

点击上方蓝字加入我们

知识工程是企业 Agent 系统构建的重要基石之一。

大型企业内部的知识以各种形态分散在不同的部门与系统里。它们可以用来协助构建业务本体；但更多时候，我们要让知识能够被 Agent 检索和查阅，以构建必要的上下文，进而提供问答、探索、创作等任务能力。

从经典的向量 RAG，到后来的 GraphRAG，再到 PageIndex、LLM-Wiki，知识的组织与检索模式不断革新。但面对复杂多变、难以预测的任务，很多时候不应该多选一，而是将它们融合应用。

读完本文，相信你对此应该有更清晰与深入的认识。

企业构建知识底座，是为了让上层应用（在当前语境下，更多指 AI 智能体应用）更加高效、精准地查询到必要的相关知识。

不过，在大量非结构化文档为主的知识世界里，同时做到这三点并不容易。

比如，把所有知识都通读一遍，虽然读取的信息范围更广，但效率太低；用向量做语义检索，速度很快，但召回的精度和上下文完整性又会受到文档切分等影响。

这也是为什么会有多种知识组织与检索模式：本质是为了解决不同要求的知识问题。

快速理解四种模式

我们用图书馆做例子，对这四种模式建立一个快速认识。

• 向量 RAG：片段检索。把每本书的段落做成资料卡，可按语义查找。比如问“公司报销制度”，先找出意思接近的资料卡，再找到对应的原文段落。

• GraphRAG：图增强检索。为每本书的章节、人物、机构和事件等建立“关系网”。比如查“谁影响了谁”，可以先找到对象，再沿着关系网追查。

• PageIndex：文档树导航。拿到一本厚手册，为它建立分章节的目录和摘要。查找内容时，先看目录选章节，再逐层翻到正文读取内容。

• LLM-Wiki：知识编纂。像图书管理员读过相关书籍后，编写一部持续修订的专题百科。后来的人先看百科目录，再找到专题阅读，必要时才回到原书。

需要注意，这四种能力的层次不完全相同：有的侧重检索结构，有的侧重知识组织 — 这也决定了它们并非水火不容。

这是两种最为熟知的 RAG 模式，我们做一个简单回顾。

经典 RAG：按意思查资料卡

经典 RAG 把原文片段（Chunk）作为检索单元。与精确匹配不同，向量索引按语义相似程度查找内容。可以把向量粗略理解为文本在“语义地图”上的坐标：意思相近的内容，更有机会被一起发现（但不保证事实/内容相同）。其准备与应用过程一般为：

• 索引阶段：解析文档、按章节或语义切块，计算向量，连同来源等元数据写入向量库

• 检索阶段：把用户问题也转成向量，通过向量库检索到相近片段，再交给模型回答

实际应用中，向量检索可以与关键词搜索 / 过滤配合使用。

比如查“iPhone18 的保修条款”：向量帮助理解“保修条款”的问法，关键词帮助匹配具体型号 iPhone18。两路候选进行合并、重排等，得到更加精准的召回。这可以借助多路融合检索、元数据过滤、或混合检索数据库等技术实现。

【适用性与特点】

经典 RAG 适合客服、产品资料、内部制度等大规模文档中的局部事实性问答。生态成熟，容易建立基线，检索性能较高。

最大的问题是“相似不代表完整”：找到主条款的 Chunk，可能漏掉例外；找到某个项目，可能漏掉它依赖的系统；Chunk 过小容易丢上下文，而过大又容易带入噪声。

这是一些早期 RAG 系统在快速上线后很快无人问津的原因之一：

原理与实现简单，但能解决的问题有限。上线很快，优化很慢。

GraphRAG：沿着关系追查线索

“供应商甲停供，会影响到哪些大客户？”，这个问题不会有直接的答案，可能需要沿“供应商—零件—产品—订单—客户”查找线索，且分散在多份材料甚至数据库中。

这需要借助 Graph 这种结构。Graph 把实体（比如一个供应商）作为节点，把关系（比如供应商与零件的供应关系）作为边，大量节点和边就构成了一张更大的 Graph。

GraphRAG 就是利用知识图谱增强检索的一类方法。微软的 GraphRAG 是代表性实现：

• 构建阶段：从文本抽取实体与关系，聚合成图，再识别联系紧密的社区（关系密切的节点组成的“小团体”），并生成社区摘要。

• 检索阶段：先通过向量找到相关实体，再结合邻居、关系与原文补充上下文；而总结性问题则可汇总社区报告，再输入模型。

工程上，GraphRAG 的难点在于准确的抽取实体与关系、消歧、原文映射、Graph 数据的存储、更新和查询等，特别是一些垂直行业，要建立起完备的 Graph 并不容易。

【适用性与特点】

GraphRAG 适合跨文档关系的多跳问题与主题归纳。比如，可以追查“供应商停供会影响哪些客户”；也可以回答“这批材料主要讨论什么内容”等总结性问题。

相比单一的向量 RAG，它能沿着关系补充上下文，但准备过程更复杂（通常借助 LLM），成本也更高，当然也可能出错。你应该只在知识具有明显的关系特征、而任务确实需要关系探索时才考虑 GraphRAG。

最后，GraphRAG 的使用也可能需要向量。比如，先用向量找到与问题相关的 N 个实体，再沿 Graph 的关系补充线索。

向量检索帮助找到相关内容，Graph 则帮助补齐关系。它们在回答事实性问题时可能很有用，比如从一份数百页的软件帮助文档中查询“单点登录支持哪些认证协议？”，通常比较容易定位答案。但你如果问：

“为什么配置了单点登录，部分用户仍无法登录？这与权限设置或版本有关系吗？”

处理这类问题时，RAG 甚至 GraphRAG 方案都可能遇到一个难点：上下文读不全。

一份复杂软件的帮助文档中，单点登录配置、权限设置、版本限制、常见问题分散在不同章节，彼此相隔几十页。如果只召回与问题相似的段落，就容易漏掉前置条件、配置依赖和注意事项中的重要信息。

PageIndex 为这类需要长文档跨章节查证的问题，提供了另一条路径。

核心方法：建立原文档的导航树

PageIndex 的核心思想是解析文档，利用目录、标题版式或正文识别文档的章节层级，将节点与页码或正文范围关联，并按配置生成节点摘要，形成一棵原文档的“导航树”。

这里的节点就是一个索引节点，它告诉模型：这一节讲什么、上下层是什么，以及去哪里读。它不依赖向量，但仍按章节层级组织索引，并保留原文定位信息。

而到了查询阶段，模型从查看这棵“导航树”开始：

• 首先根据问题选择相关章节与页码范围

• 调用读取工具取得对应页的原文内容

• 如果模型认为上下文不足，可能要求继续补充其他章节
  

在上面的例子中，可能要先读单点登录配置，再补上权限设置、版本限制和常见问题中的相关内容。当然是否读全，很大部分取决于导航树的质量和模型的选择。

技术实现：借助 PageIndex SDK

借助开源 PageIndex，可以快速上手。以下为本地调用的示例：

from pageindex import PageIndexClient

client = PageIndexClient(
    index="gpt-6-luna",  # 建树模型
    chat="gpt-6-sol",    # 查询模型
)

doc_id = client.submit_document(
    "report.pdf"
)["doc_id"]

answer = client.chat(
    "2023 年的营业利润率是多少？",
    doc_id=doc_id,
)

PageIndex SDK 提供索引创建、结构读取、检索与问答等接口，目前主要处理文本型 PDF 或 Markdown 文件（OCR、视觉解析等能力需另行集成）。

适用性与特点

从原理看，PageIndex 更适合年报、合同、手册等章节清晰、需要跨章节核对的长文档。如果有很多长文档，通常需要先发现候选文档。

PageIndex 的优势是先了解全文脉络，然后取证，大大减少可能的上下文遗漏。

缺点是适用场景相对受限，所以在大型项目中可能更适合作为“副手”。其代价是查询的延迟及额外成本，毕竟结构解析、摘要生成、检索时判断都需要借助 LLM，本身也存在不准确的可能。

LLM-Wiki 是 Andrej Karpathy 在今年提出的一种模式。它的核心思想是：

LLM 不再在查询时从原始文档中检索信息，而是先将知识编译成一个持久的、相互关联的 Wiki，并保持其更新  — 就像一部持续修订的专题百科，按主题把原始知识文档整理成概念页（Page），保留关键结论，并在 Page 之间建立交叉链接。

核心方法：LLM 的编译与持续更新

初次构建时，先把原始目录（比如 raw）中的文档编纂成可复用的知识页。 LLM 读取 raw 中的文档，识别实体、概念和关键事实、规划 Wiki 的页面结构、再按主题整合材料、生成概念页 / 实体页 / 专题总结等，最后建立交叉链接、来源回链和索引页。

同一主题可以汇总多个来源，一份原文也可能贡献给多个页面。

初次构建后，后续再围绕变化持续维护。 当新材料进入，或知识源发生变化，借助 LLM 识别受影响的 Wiki 页，进行补充、修订或删除，并标注尚未解决的问题，最好还能定期检查过期内容、断链和知识缺口等。

 使用时，Agent 沿着索引页与内部链接，根据任务找到自己需要读取的内容：

1. 先看索引页：比如  index.md，了解知识库有哪些主题，判断从哪里开始。
2. 进入相关概念页：沿目录链接打开页面，阅读已经整理好的知识。
3. 按需延伸阅读：沿交叉链接查阅相关概念，补齐必要知识。
4. 用于当前任务：依据这些知识回答问题、分析方案、撰写文档或编写代码。
   
   

OKF：将 LLM-Wiki 标准化的知识格式

这里还有一个概念：OKF（开放知识格式）。它是 Google 发布的开放知识格式规范，可用于表达和交换 LLM-Wiki 等方式整理出的知识。在这个规范中，一个 Wiki 页面通常表示为带 YAML 元数据的 Markdown。比如：

基于 OKF 规范的 LLM-Wiki 一般长这样：

适用性与特点

LLM-Wiki 适合沉淀领域术语、指标口径、操作规程、编程上下文等：既能直接浏览，也能为 Agent 组织任务所需的上下文。

它的难点在于规模化与长期维护，这源自它有一个独立的“中间层” Wiki。

当你的 Wiki 拥有成千上万的页面后，一旦知识源发生变化，需要定位受影响的页面，处理更新、冲突和错误等，这需要付出较大的时间与 Token 成本。

所以，在企业应用中，不宜急着把所有资料编成 Wiki。优先沉淀反复使用、相对稳定的核心知识；而海量工单、会议纪要这类知识，可以在发现复用价值后再整理。

当然，更合适的方法是与其他模式进行协作与融合应用。

在探讨几种模式的融合之前，我们做一个简单的总结：

注意，这只是一般的工程分析，并非排名。每种模式都有代价：向量需要嵌入，图需要抽取关系，树导航要建树，Wiki 则需要整理和持续维护。所以在真实应用中，往往需要组合使用它们：按任务路由或串联使用不同模式与工具。

下面来探讨一些可能的融合应用模式。

融合一：向量找到入口，用 Graph 做关系扩展

先用关键词与语义向量检索，找到相关实体或片段；再借助图沿有来源的关系扩展，返回相关上下文，必要时用重排模型筛选。

也可以将片段与 Graph 检索并行召回，再合并重排（也可以结合关键词检索）：

融合二：向量定位文档，用 PageIndex 做增强阅读

先通过 RAG 管道或 GraphRAG 检索定位候选文档，再根据需要补充上下文。较短的文档可以直接读全文；复杂的长文档则调用 PageIndex，定位相关章节并补充。

这里需要结合向量块的元数据、Graph 节点属性等信息，确认读取的文档及其树索引的身份与版本一致，避免搜索与读取的不一致。

融合三：Wiki 存核心知识，PageIndex 读长文，RAG 连接长尾

这是一种分工合作的方式：不同任务/子任务可以路由到不同的知识服务管道。

• 企业中核心、稳定、经常被引用的知识，整理成 Wiki／OKF ，比如业务规则、管理制度、指标解释、参考手册和 SOP（标准操作流程）

• 复杂的长文档可以建立 PageIndex，便于在长文中阅读、定位、补充上下文

• 其他大量非结构化、快速变化、偶尔被查询的信息，仍可由 RAG 管道提供快速服务，必要时结合图增强检索

使用时，Agent 可以借助 LLM 路由器选择工具；或者动态的把大任务拆成子任务，分别从不同的服务管道查询、整理、再补充、合成结果等。

以 AI 编程上下文的应用为例

假设为一个行业应用构建 AI 编程知识库：已有整理过的 Wiki、向量 RAG 管道，以及借助语法树构建的代码图谱（一种不借助 LLM 构建的代码 Graph ）。那么，在一次新需求的设计开发过程中，可能同时发生以下动作：

1. 从 Wiki 的索引入口进入，读取相关的业务术语、规则、流程；理解系统架构等
2. 为核对一个指标口径或 API 变更，通过向量 RAG 快速检索到相关的知识与事实
3. 借助代码图谱发现模块与代码间的关联性，用来分析本次开发的影响范围
4. 通过 PageIndex 在一个上百页的接口文档中定位到使用方法、开发注意点等

最终，你可以生成带有出处、引用甚至页码的待确认设计草稿。必要时你也可以将经过核验、可复用的设计决策与解释再回写 Wiki，实现知识积累。

当然，并非每个任务都需要走遍所有通道。

你可以在 AGENTS.md 设定路由与组合规则，让 Agent 按需选择；也可以定义 Skill 或借助  LangGraph 等框架编排，来固化标准的检索过程。

融合四：Wiki 可以成为其他模式的输入

查询管道不一定都从原始文档构建。整理后的 LLM-Wiki／OKF 本身就是有结构、且质量更高的 Markdown 文档集，恰好就是 RAG/GraphRAG 的理想输入。所以，你可以在此基础上建立起向量 RAG 的查询加速层，并验证分块和召回效果；只在必要时才回到最原始的文档查询。

此外，相互链接的 Wiki 页面本身就构成一个文档的 Graph；你可以在此基础上进一步做实体与关系抽取，以支持更深入的关系探索。

关于以上的几种融合应用模式，最后需要说明的是：

融合扩展了可覆盖的检索需求，但也带来了知识更新与治理的复杂性：当原始内容或访问权限变化时，相关片段、Graph、Wiki 页和文档树都需要相应更新或失效，这非常考验工程能力。

以上我们梳理了面向 Agent 系统的企业知识底座的构建模式。根据知识特点、任务需要和工程条件，企业可以从最紧急的任务入手，建立起基线，再在业务发展中补齐更复杂的能力。

实际构建时，可以借助一些开源项目来降低工程复杂度：

• Microsoft GraphRAG：实体关系抽取、社区识别、局部检索与全局归纳
• LightRAG：融合图与向量检索，支持增量维护
• PageIndex：文档树导航，提供索引、检索与问答 SDK
• OpenWiki（LangChain）：编纂、维护 Wiki，支持 OKF 输出
• RAGFlow：很强大的文档解析能力；提供 RAG、Wiki、PageIndex 等模式
• WeKnora：来自腾讯的知识工程基座，支持 RAG、Graph、Wiki 等知识模式

后续我们将分享基于这些开源项目的实践，欢迎继续关注。

END

喜欢就关注哦

动动小手点个赞

点在看最好看