BookRAG评测：树-图融合RAG框架处理层级文档

先聊一个现实问题：在技术文档、研究报告和各类手册的阅读场景里，光靠关键词来检索信息，早就捉襟见肘了。特别是面对那些结构复杂、图文并茂的文档——比如一本技术白皮书或一份操作指南——常规RAG系统往往会遇到不小的麻烦。

眼下比较主流的处理方式，无非两条路：要么把文档整个拍平成纯文本，像揉面一样把所有内容搅在一起，然后用BM25或者GraphRAG、RAPTOR这类图方法来检索；要么就死抠版面，把文档拆成段落、表格、图片这些小块，再靠多模态或LLM管道来处理。

这两条路都有道理，但也都卡在同一个问题的两端：结构与语义如何兼得。

第一种方法把文档的层级关系丢掉了，表格属于哪个章节、一个概念出现在上下文的什么位置，通通不清楚。第二种方法倒是保住了每个块的“物理身份”，但块与块之间的关联——尤其是跨章节的关联——它建不起来。结果就是，你问一个绕了两层逻辑的问题，系统就开始含糊其辞。

此外，大多数RAG管道还有一个通病：毛巾拧干式的工作流程。简单的问题，比如“这个条款在第几页”，它要走一遍完整的检索-推理-生成流程；复杂的问题，需要跨三章五节去比对的，它又应对不了。效率和精度两头都顾不上。

所以，相比DocETL这类版面感知的管道，BookRAG在Token开销和响应延迟上确实更优。下面就把它的几个核心设计拆开来说。

传统方法的两大死xue

说到这儿，不妨先看看现有两种做法具体卡在哪里。

结构与语义的脱节。文本优先路径跑完一遍OCR，表格里的数字可能还记得，但表格属于哪个章节——这层关系没了。版面优先路径保留了每一块的标签，但块与块之间的归属链、跨章节的逻辑递进，它也很难建模。多跳推理于是变得困难，而且常常不可靠。

僵化的一刀切流程。现实中的问题差异太大了。读者可能只想查一个定义，也可能需要跨多个章节做比较分析。大多数RAG系统不管这个，上来就执行预设的处理流程——简单问题拖节奏，复杂问题又撑不住，两头都不讨好。

BookRAG试图回答的就是这个问题：能不能建一个索引，既能保留文档的骨架，又能理解其中实体的关系，同时还能根据问题类型灵活调整检索策略？

BookRAG：一棵树、一张图、一个链接、一个Agent

Figure 2: Comparison of representative methods and BookRAG.

BookRAG的核心是自建一个文档原生索引——BookIndex。它不走“先拍平再检索”的路径，也不走“先拆块再组装”的路径。它把三个东西整合在一起：版面块的层级树、细粒度实体的知识图谱、以及树与图之间的双向链接。再配合一个受信息觅食理论启发的Agent，来代替那套僵化的固定流程。

这个框架的关键组件，有三个。

构建BookIndex

Figure 3: The BookIndex Construction process.

一张图说明白：文档先被解析成层级树。版面解析阶段（实验里用的是MinerU）把PDF拆成独立的内容块，每个块附带元数据——类型（标题、正文、表格等）、字体大小、位置信息。语言模型来鉴定哪些块是标题，并确认它们的层级位置。所有块按标题级别串起来，构成一棵树。这棵树就是BookIndex的结构骨架。

树建好之后，系统对每个节点做实体和关系提取。文本块交给语言模型，含图像块走多模态通道。表格和公式有专门的处理逻辑：以表格为例，行标题和列标题被提取为实体，通过“ContainedIn”关系链接回表格节点。

各节点产生的局部子图，用一种基于梯度的实体消解方法合并成全局知识图谱。这个过程的核心是：分析重排序器的相似度分数，找到分数中的急剧下降点，从而检测并统一共指实体。比如“LLM”和“Large Language Model”会被合并到同一个节点。

最后通过GT-Link将树和图关联起来，把实体映射回其来源的特定树节点。树和图之间由此建起了双向桥梁：从图中的任一实体可以追溯到具体的章节、表格或段落，反过来，树中的每个章节也能列出它包含的实体。结构和语义就此紧密耦合。

基于梯度的实体消解

为了保持知识图谱上的推理质量，BookRAG没有采用传统的二次复杂度成对比较，而是改用增量查找。每提取一个新实体，就从向量数据库中召回候选列表，用评分模型排序，再检查相似度分数是否出现陡降。如果有明显的分数断层，系统隔离出高置信度候选集：只有一个候选时直接合并，多个候选时调用LLM选出规范实体再合并。没有明显断层的话，该实体视为独立条目。

这个方法避开了穷举配对的高昂开销，图谱的紧凑度也保持得很好。

基于Agent的自适应检索

Figure 4: The general workflow of agent-based retrieval in BookRAG.

Agent的引入，让检索不再是固定套路。它借鉴信息觅食理论，根据问题类型定制检索策略：单跳查询做直接查找，多跳查询需要跨章节推理，全局聚合查询则需扫描整篇文档。

Agent生成由模块化算子组成的动态计划——有的算子沿“信息线索”导航到相关片段，有的负责过滤内容块，有的执行推理或合成最终答案。每个查询走不同的路径，兼顾了精度与效率。

案例分析

Figure 6: Case study of responses across different query types from MMLongBench and Qasper.

图6展示了三种查询的执行过程。

单跳查询的关键是快速缩小搜索空间。以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），得出最终答案。

多跳查询的策略是分解再综合。面对一个比较两个系统的复杂问题，Agent用Decompose算子将其拆分为子问题，分别检索各子问题的答案后综合输出。

评估

实验验证的不仅是BookRAG的问答准确性，还有两个维度的表现：检索覆盖率——找到所有相关信息的能力；以及效率——运行成本和响应速度。完整评估数据可参阅原论文。

总结与展望

面对长文档的复杂问答场景——结构化手册、技术报告、研究论文——BookRAG给出了一套经过基准验证的设计方案。它的核心思路是构建文档原生索引BookIndex，把层级树、知识图谱和图-树链接整合在一起，再配合一个能沿信息“线索”导航的Agent。

不过有一个实际部署中需要注意的局限：实体消解目前只支持单文档内的合并。在企业级场景下，知识往往分布在数百甚至数千个文档中，跨文档的实体统一是绕不开的问题。

一个有前景的方向是把BookIndex从检索索引提升为文档自身的原生知识层。问答之外，它还能支撑一致性检查、结构化摘要乃至交叉引用修复——树-图结构由此成为文档生命周期的一部分，而不只是服务于RAG的后端工程。

再往前看，Agent的算子规划是否能演化为一个可学习的策略层？积累足够的交互日志或引入强化学习后，系统或许能自行调优——决定调用哪些算子、何时简化流程、如何在不损失太多表达能力的前提下维持运行效率。这种精细的控制能力，正是生产环境所需要的。

论文：
https://a void.overfit.cn/post/301d874592154a5bada4fd7c777e827e