BookRAG:面向层级文档的树-图融合RAG框架

简介: BookRAG是专为书籍类层级文档设计的新型RAG框架,首创“树+图+链接+Agent”四元结构:构建融合版面层级树与知识图谱的BookIndex,通过GT-Link双向映射实现结构与语义统一;引入信息觅食启发的Agent,动态规划检索路径,支持单跳、多跳及全局聚合查询,在精度、覆盖率与效率上显著优于传统文本/版面优先方法。

现有的RAG系统,无论是基于文本的图方法还是基于版面分割的方法,在面对这类文档时往往失效。根源在于两点:结构与语义的脱节以及工作流程的僵化。

本文介绍的BookRAG或许能提供一个有用的视角。

两种传统方法及其局限

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

第一种是文本优先方法,将所有内容扁平化为纯文本,主要依赖OCR,再用BM25、经典分块RAG或GraphRAG、RAPTOR等图方法完成检索。其中GraphRAG从文本构建知识图谱,通过社区检测形成带摘要的层级聚类;RAPTOR则递归地对分块做聚类和摘要,形成树状结构。

第二种是版面优先方法,保留原始文档版面,将内容分割为段落、表格、图表、公式等结构化块,再用多模态检索或基于LLM的处理管道(如DocETL)处理相关分块。

Figure 1: Comparison of existing methods and BookRAG for complex document QA.

两种方法各有价值,但面对类书籍文档时都会遇到两个根本性的问题。

结构与语义的脱节

文本优先路径剥离了文档的结构上下文,章节、子章节与表格之间的归属关系随之丢失,所以无法判断某个表格属于哪个章节。版面优先路径保留了单独的内容块,却难以建模块与块之间的关联,尤其是跨章节的关联,多跳推理因而变得困难且不可靠。

僵化的一刀切工作流程

现实中的问题差异很大,从简单的定义查找到跨多个章节的比较分析都有。大多数RAG管道依赖固定的查询处理流程,简单问题处理起来效率低,复杂问题又应对不了。

所以多数现有的文档级RAG系统要么忽略文档的层级结构,要么缺乏查询感知的检索流程。结果是经常遗漏关键证据或检索效率偏低;在DocETL这类版面感知管道中Token开销和响应延迟也比BookRAG更高。

BookRAG:一棵树 + 一张图 + 一个链接 + 一个Agent


Figure 2: Comparison of representative methods and BookRAG.

BookRAG是一个专为层级结构文档设计的RAG框架。

核心思路是构建一个文档原生索引BookIndex:将版面块的层级树与细粒度实体的知识图谱通过图-树映射整合在一起,再用一个受信息觅食理论(Information Foraging Theory)启发的Agent检索器,对查询分类后沿"信息线索"动态导航索引。

整个框架由三个关键组件构成。

构建BookIndex

BookIndex在一个统一索引中同时容纳结构和语义。

Figure 3: The BookIndex Construction process. This phase includes Tree Construction, derived from Layout Parsing and Section Filtering, and Graph Construction, which involves KG Construction and Gradient-based Entity Resolution.

文档先被解析为一棵层级树,对应目录及其关联的内容块。版面解析阶段(实验中使用MinerU实现)将PDF拆分为独立的内容块,每个块附带元数据:类型标注(标题、正文、表格等)、字体大小、位置信息以及其他版面细节。语言模型随后审查那些疑似标题的块,确认它们是否确实是标题,并判定其在文档层级中的级别。

所有块按标题级别依次连接构成一棵树。这棵树是BookIndex的结构骨架,后续的检索、推理和问答都依托于此。

树构建完成后,系统对每个节点执行实体和关系提取。文本块交由语言模型处理,含图像的块经过多模态模型处理。表格和公式有专门的处理逻辑,以表格为例,行标题和列标题被提取为实体,通过"ContainedIn"关系链接回表格节点。各节点产生的局部子图用一种基于梯度的实体消解方法合并为全局知识图谱:分析重排序器的相似度分数,识别其中的急剧下降,以此检测并统一共指实体。

最后通过GT-Link将树和图关联起来,把实体映射回其来源的特定树节点,形成结构化三元组B = (T, G, M)——树、图、映射。GT-Link在两者之间建立了双向桥梁:从图中的任一实体可以追溯到对应的树节点(章节、表格、段落等),反过来,树中的每个章节也能列出它包含的实体。结构与语义就此紧密耦合,系统不仅知道某个概念是什么,还知道它在文档中的具体位置。

基于梯度的实体消解

为了保证知识图谱上的推理质量,BookRAG采用了一种基于梯度的实体消解方法。

传统做法对所有实体执行二次复杂度的成对比较,BookRAG将其改造为增量查找:每提取一个新实体,判断它是否是某个已有实体的别名。做法是从向量数据库中召回候选列表,用评分模型排序再检查相似度分数是否出现陡降。如果检测到明显的分数断层,系统隔离出高置信度候选集,只有一个候选时直接合并多个候选时调用LLM选出规范实体再合并。没有明显断层的话,该实体视为独立条目。

这一方法避开了穷举配对的高昂开销,同时保持图谱的紧凑:像"LLM"和"Large Language Model"这样的变体会被归入同一个节点。

基于Agent的自适应检索


Figure 4: The general workflow of agent-based retrieval in BookRAG, which contains agent-based planning, retrieval, and generation processes.

BookRAG引入了一个Agent,借鉴信息觅食理论(IFT),根据问题类型定制检索策略:单跳查询做直接查找,多跳查询需要跨章节推理,全局聚合查询则需扫描整篇文档。

Figure 5: The BookRAG Operator Library and an Execution Example from MMLongBench dataset: (a) a visual depiction of the four operator types (Formulator, Selector, Reasoner, and Synthesizer) and (b) an execution trace for a "Single-hop" query, demonstrating the agent-based planning and step-by-step operator execution.

Agent会生成由模块化算子组成的动态计划:有的算子沿"信息线索"导航到相关片段,有的负责过滤内容块,有的执行推理或合成最终答案。每个查询根据待解决的问题在索引中走不同的路径,使系统在处理长篇复杂文档时兼顾精度与效率。

案例分析


Figure 6: Case study of responses across different query types from MMLongBench and Qasper. CYAN TEXT highlights correct content generated by BookRAG. GRAY TEXT describes the internal process, and marks omitted irrelevant parts.

图6展示了BookRAG处理三种查询的完整过程。

单跳查询的关键在于缩小搜索空间。以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。

不过在实际部署中有一个值得关注的局限:实体消解目前仅支持单文档内的合并。企业级场景下知识往往分布在数百甚至数千个文档中,跨文档的实体统一是绕不开的问题。1·

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

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

论文:

https://avoid.overfit.cn/post/301d874592154a5bada4fd7c777e827e

By Florian June

目录
相关文章
|
1月前
|
JSON 搜索推荐 定位技术
无 Embedding、无向量数据库的 RAG 方法:PageIndex 技术解析
PageIndex是无向量、基于推理的RAG框架,通过构建文档层次化目录树,让大模型像人类专家一样逐层推理导航,精准定位答案,支持可追溯、高相关性检索,专长于财报、法律、政策等结构化长文档。
344 0
无 Embedding、无向量数据库的 RAG 方法:PageIndex 技术解析
|
2月前
|
存储 人工智能 NoSQL
理解 Agent 记忆:从无状态模型到持久化记忆架构
大语言模型本质无状态,对话历史无法自动留存。Agent需长期记忆支撑连续性任务,但简单堆砌上下文不可行。本文系统阐释Agent记忆的四层架构(工作/情景/语义/程序记忆),及其写入、检索与遗忘机制,并对比Mem0、Letta等主流方案,揭示记忆正成为AI Agent技术栈中独立、标准的关键基础设施。
791 7
理解 Agent 记忆:从无状态模型到持久化记忆架构
|
2月前
|
机器学习/深度学习 人工智能 算法
更大的上下文窗口为什么让RAG变得更重要而非更多余
大上下文窗口(如1M tokens)并未淘汰RAG,反而凸显其价值:LLM注意力易被噪声稀释,“迷失在中间”效应导致性能下降。实验证明,相关性筛选比单纯扩容更关键。RAG+大上下文协同——先精准检索重排序,再注入高密度片段——才是生产级AI的可靠范式。
307 0
|
存储 自然语言处理 API
LlamaIndex使用指南
LlamaIndex是一个方便的工具,它充当自定义数据和大型语言模型(llm)(如GPT-4)之间的桥梁,大型语言模型模型功能强大,能够理解类似人类的文本。LlamaIndex都可以轻松地将数据与这些智能机器进行对话。这种桥梁建设使你的数据更易于访问,为更智能的应用程序和工作流铺平了道路。
5872 0
|
3月前
|
存储 搜索推荐 开发者
RAG 文本分块:七种主流策略的原理与适用场景
分块是RAG系统的基石,直接影响检索质量与LLM推理效果。行业共识:“分块决定RAG质量的70%”。从固定大小、句子/段落级,到语义、递归、滑动窗口及层次化分块,策略需匹配文档类型与任务需求。劣质分块导致上下文断裂、噪声激增、幻觉频发——燃料不行,再强的引擎也徒劳。
408 2
RAG 文本分块:七种主流策略的原理与适用场景
|
3月前
|
自然语言处理 数据库 开发者
PageIndex: 一种基于 LLM 推理的 RAG 架构(干货科普)
本文介绍开源项目 PageIndex,提出“推理即检索”新架构。它摒弃传统向量切块,利用 LLM 基于树状索引进行结构化导航,在 FinanceBench 评测中准确率达 98.7%。该方案有效解决长文档检索碎片化问题,虽涉及成本权衡,但为高精度知识问答提供了新的选择。
3649 3
|
2月前
|
人工智能 安全 API
OpenClaw不“吃灰”指南:全平台部署+免费API配置+102个即用场景解析+避坑手册
2026年,AI工具的核心价值已从“对话响应”转向“落地执行”。但多数用户仍困在“聊得热闹,做得有限”的困境——AI能写方案、改文字,却无法从头到尾独立完成一件完整任务。而OpenClaw作为首个开源本地部署的AI Agent平台,彻底打破这一局限:它不是单纯的聊天机器人,而是能连接20+平台、自动执行任务的“数字员工”——早上自动整理行业新闻推送到飞书、自动分拣100封客户邮件、监控GitHub代码漏洞并告警,这些场景现在就能落地。
687 9
|
4月前
|
专有云
山海征程|2025年阿里云专有云年度盘点
专有云的山海征程——2025年阿里云专有云年度盘点
292 0
|
2月前
|
机器学习/深度学习 人工智能 自然语言处理
手撕 Transformer:从原理到代码,一步步造一个“小型大模型”
手撕 Transformer:从原理到代码,一步步造一个“小型大模型”
580 6
|
2月前
|
人工智能 API 开发工具
HagiCode 为什么选择 Hermes 作为综合 Agent 核心
HagiCode 为什么选择 Hermes 作为综合 Agent 核心 在构建 AI 辅助编码平台时,选择合适的 Agent 核心直接决定了系统能力的天花板。毕竟有些事情,勉强不来——选错了框架,怎么折腾都不得劲。本文分享 HagiC...
536 3