BookRAG 简明教程

在现实世界的企业环境中，知识很少存在于整洁的常见问题解答（FAQ）中。更多时候，它被埋藏在密集的技术手册、API 参考、标准作业程序（SOP）和研究论文中——这些长文档看起来和行为更像是书籍。它们带有章节和子章节、嵌入的表格和公式，以及清晰但复杂的分层布局。

但现有的 RAG 系统——包括基于文本的图方法和布局分割方法——往往由于断开的结构语义和静态工作流而失效。

这篇文章可能提供一个有用的视角。

1、为什么RAG 系统很难处理"类似书籍"的文档

人们有两种主流范式来处理这类文档。

1）以文本为主的方法

这种方法将所有内容扁平化为纯文本，主要依赖 OCR。然后它应用检索技术，如 BM25、经典的基于块的 RAG，或基于图的方法如 GraphRAG 或 RAPTOR。

• GraphRAG（GraphRAG 真的优于 RAG 吗？）从文本构建知识图，并应用社区检测来形成带摘要的分层集群。
• RAPTOR（高级 RAG 12：增强全局理解）递归地聚类和摘要块以形成树状结构。

2）以布局为主的方法

这种方法保留原始文档布局。它将内容分割成结构块（段落、表格、图表、公式），并使用多模态检索或基于 LLM 的处理管道（如 DocETL）来处理相关块。

两者都很聪明。两者都很有用。但在处理类似书籍的文档时，它们遇到了两个基本问题：

问题 1：结构和语义断开

以文本为主的路径剥离了文档的结构上下文。它失去了章节、子章节和内容（如表格）之间的关系。你无法分辨哪个表格属于哪个章节。

以布局为主的路径保留了各个块，但难以对它们之间的关系进行建模——尤其是在跨章节的情况下。这使得多跳推理变得困难且往往不可靠。

问题 2：僵化的、一刀切的工作流

现实世界的问题范围从简单的定义查找到跨越多个章节的复杂比较。但大多数 RAG 管道依赖于固定的查询处理工作流。这导致了两个问题：

• 对简单问题效率低下。
• 对复杂问题表现不佳。

简而言之

大多数现有的文档级 RAG 系统要么忽略了文档的分层结构，要么缺乏灵活的、查询感知的检索工作流。因此，它们往往错过正确的证据或检索效率低下；在一些布局感知的管道（如 DocETL）中，与 BookRAG 相比，这也可能导致更高的 token 成本和延迟。

2、BookRAG：树 + 图 + 链接 + 智能体

为了解决这些局限性，BookRAG被引入，它是专门为具有强分层结构的文档构建的 RAG 框架。

核心思想是构建一个文档原生索引，BookIndex，它将布局块的分层树与通过图树映射链接的细粒度实体知识图集成，然后使用受信息觅食理论启发的基于智能体的检索器来分类查询并通过遵循信息气味动态导航此索引。

在高层次上，BookRAG 建立在三个关键组件之上。

2.1 构建 BookIndex

BookIndex 将结构和语义集成在一个统一的索引中。

从 PDF 到树：布局解析 + 章节过滤

首先，它将文档解析为分层的树，表示目录和相关的内容块。

具体来说，它从布局解析开始（在他们的实验中使用 MinerU 实现），将 PDF 分解为单独的内容块。

每个块都带有元数据，如"这是一个标题"、"这是正文文本"、"这是一个表格"——以及字体大小、位置和其他布局细节。语言模型审查看起来像标题的块，并决定它们实际上是否是标题，如果是，它们在文档层次结构中属于哪个级别。

完成后，系统根据标题级别按顺序连接所有块，构建一棵树。这棵树构成了 BookIndex 的结构骨架，进而支撑后续的检索、推理和问答。

从树到图：多模态实体 + GT-Link

然后，它从树中提取知识图，捕获细粒度实体及其关系。

特别地，一旦树被构建，系统对每个节点运行实体和关系提取。文本块由语言模型处理，而包含图像的块通过多模态模型。对表格和公式添加了特殊处理；特别是对于表格，行和列标题被提取为实体，并通过"ContainedIn"关系链接到表格节点。这些局部子图使用新颖的基于梯度的实体解析方法合并到全局知识图中，该方法分析重排序器相似性得分并识别急剧下降以检测和统一共指实体。它捕获存在哪些实体以及它们如何连接。

最后，它通过GT-Link链接两者，将实体映射回它们来自的特定树节点。结果是一个结构化的三元组：B = (T, G, M)——树、图和映射。

特别地，GT-Link 在图和树之间创建了一座双向桥梁。从图中的任何实体，都可以追溯到它来自的确切树节点（例如，章节、表格、段落）。同样，树中的每个章节都可以展示它包含的实体。这紧密耦合了结构和含义——因此系统不仅知道某物是什么，还知道它在文档中的位置。

2.2 通过梯度实现更智能的实体解析

为了确保对知识图进行高质量推理，BookRAG 使用了基于梯度的实体解析方法。

不是对每对实体执行二次数的成对比较，BookRAG 将实体解析重新表述为每个新实体的增量查找。在单文档（干净 ER）设置中，每当提取新实体时，系统会询问它是否只是已见实体的另一个别名。

为了回答这个问题，它从向量数据库中拉取候选者列表，使用评分模型对它们进行排名，然后检查相似性得分是否急剧下降。

• 当检测到明显的得分下降时，系统隔离高置信度候选集：如果只包含一个实体，则直接合并；否则，它调用 LLM 在这些别名中选择规范实体并将新实体合并到其中。
• 如果没有，则将其视为单独的条目。

这种基于梯度的方法避免了比较每一对可能组合的繁重成本，同时保持图的整洁和紧凑——将"LLM"和"Large Language Model"等变体分组在一个单一、统一的节点下。

2.3 使用智能体进行自适应检索

借鉴信息觅食理论（IFT），BookRAG 引入了一个智能体，它根据问题类型定制检索策略：

• 单跳：直接查找。
• 多跳：需要跨章节推理的查询。
• 全局聚合：需要扫描整个文档的问题。

智能体生成一个由模块化操作符组成的动态计划——一些用于跟随"信息气味"导航到相关补丁，一些用于过滤块，另一些用于推理或综合最终答案。

每个查询根据其解决问题的需要，通过索引遵循自定义路径。这种设计使 BookRAG 即使在长而复杂的文档上也能平衡精度和效率。

3、案例研究

• 单跳——缩小搜索空间：在 Qasper 数据集的一个示例中，用户问了一个直接的事实问题。BookRAG 首先使用 Extract 操作符识别相关实体，然后应用 Select_by_Entity 过滤树。这将从 134 个节点缩小到仅 24 个节点的推理范围。之后，它运行 Graph_Reasoning 和 Text_Reasoning 分配重要性得分，并使用 Skyline_Ranker 选择最终的 8 个高置信度节点，用于生成答案。
• 全局聚合——精确过滤和计数：在来自 MMLongBench 数据集的全局风格查询中，问题需要计算特定页面范围内的图像数量。BookRAG 使用 Filter_Range 选择第 1 到 10 页，并使用 Filter_Modal 隔离图像块。这些过滤器产生精确的节点子集，然后通过 Map 和 Reduce 传递以执行特定的**聚合操作（例如，COUNT）**以生成最终答案。
• 多跳——分解和征服：对于比较两个系统的复杂查询，智能体使用 Decompose 操作符将其分解为子问题，分别检索每个子问题的答案，然后综合它们。

4、评估

实验不仅是为了展示 BookRAG 可以准确回答问题。

它们还突出了另外两个重要优势：检索覆盖率（它找到所有相关信息的程度）和效率（运行成本多少，响应速度多快）。

对于那些对完整评估感兴趣的人，请参阅参考文献。

5、结束语

对于长文档的复杂问答——如结构化手册、技术报告或研究论文——BookRAG 提供了一个强有力的、经过基准验证的设计方向。

它构建了一个文档原生索引 BookIndex，它集成了分层树、知识图和将实体映射回其结构位置的图树链接。在此基础上，它引入了一个智能体，它知道如何遵循信息的"气味"。

但在现实世界的部署中，我有一个担忧。实体解析目前仅限于单个文档内的合并。在企业规模下，知识通常跨越数百或数千个文档，跨文档实体统一变得必不可少。

在我看来，一个有希望的方向是将BookIndex不仅视为检索索引，而且视为文档本身的原生知识层。除了问答之外，它还可以支持一致性检查、结构化摘要，甚至交叉引用修复。在那种观点下，树图结构成为文档生命周期的一部分，而不仅仅是更好 RAG 的后端黑客。

展望未来，值得考虑的是智能体的操作符规划是否可以演变为可学习策略层。通过足够的交互日志或强化学习，系统可能会学会自我调整——决定运行哪些操作符、何时简化以及如何保持效率而不牺牲太多表达性。这就是在生产环境中保持实用性所需的控制。

原文链接: BookRAG: A Document = One Tree + One Graph + One Agent

汇智网翻译整理，转载请标明出处