-
一张图谱
-
一个智能体
在真实企业场景中，知识很少以整洁的问答对（FAQ）形式存在。它们更多隐藏在厚重的技术手册、API 文档、标准作业流程（SOP）和科研论文里——这些长文档在形态与逻辑上更接近**书籍。**它们包含章节与子小节、内嵌表格与公式，以及清晰但复杂的层级布局。
但现有的检索增强生成（RAG）系统——包括基于文本的图谱方法和基于版面分割的方案——往往因为结构与语义割裂、工作流静态僵化而效果不佳。
本文或许能提供一个有价值的视角。
为什么大多数 RAG 难以处理“类书籍”长文档
两种传统思路（及其局限）
当前处理这类文档主要有两大主流范式。
1. 文本优先思路
这种方法将所有内容扁平化为纯文本，主要依赖光学字符识别（OCR），再使用 BM25、传统分块 RAG，或 GraphRAG、RAPTOR 这类基于图谱的检索技术。
-
GraphRAG 从文本中构建知识图谱，并通过社区发现形成带摘要的层级聚类。
-
RAPTOR 对文本分块进行递归聚类与摘要，形成类树结构。
2. 版面优先思路
这种思路保留原始文档版式，将内容分割为结构化块（段落、表格、图片、公式），再通过多模态检索或基于大模型的处理流水线（如 DocETL）处理相关块。
图1：现有方法与 BookRAG 在复杂文档问答上的对比。[来源]
两种思路都很巧妙、也很实用，但在处理类书籍文档时，会遇到两个根本性问题。
问题一：结构与语义割裂
文本优先路线会剥离文档的结构上下文，丢失章节、子小节与表格等内容之间的关联——系统无法知道某张表格属于哪一节。
版面优先路线保留了独立块，但难以建模块之间、尤其是跨章节之间的关系，导致多跳推理困难且不稳定。
问题二：僵化、一刀切的工作流
真实问题从简单的定义查询，到跨多章节的复杂对比不等。但大多数 RAG 流水线使用固定的查询处理流程，导致：
-
简单问题效率低下
-
复杂问题能力不足
小结
现有大多数文档级 RAG 要么忽略层级结构，要么缺乏灵活、感知查询意图的检索工作流。结果就是：经常漏检关键证据，或检索效率低下；在 DocETL 这类版面感知流水线中，相比 BookRAG 还会带来更高的 Token 开销与延迟。
BookR：一棵树
-
一张图谱
-
一条链接
-
一个智能体
图2：代表性方法与 BookRAG 对比。[来源]
为解决上述局限，研究者提出 BookRAG——一个专为强层级结构文档设计的 RAG 框架。
核心思路是：构建原生文档索引 BookIndex，将基于版面块的层级树与细粒度实体知识图谱通过图谱–树映射关联；再使用受信息觅食理论启发的智能体检索器，对查询分类并沿信息线索动态导航索引。
整体上，BookRAG 由三大关键模块构成。
1. 构建 BookIndex
BookIndex 将结构与语义融合在统一索引中。
图3：BookIndex 构建流程。该阶段包括：从版面解析与章节过滤得到的树构建，以及包含知识图谱构建与基于梯度的实体对齐的图谱构建。[来源]
从 PDF 到树：版面解析 + 章节过滤
首先将文档解析为层级**树结构，**表示目录与对应内容块。
具体来说： 先通过版面解析（实验中使用 MinerU）将 PDF 拆分为独立内容块。 每个块附带元信息：标题、正文、表格，以及字号、位置等版式细节。再用大模型判断哪些块是真正的标题，并确定其在层级中的级别。
之后，系统按标题层级将所有块按序连接，构建出一棵树。这棵树成为 BookIndex 的**结构骨架，**支撑后续检索、推理与问答。
从树到图谱：多模态实体 + GT-Link
接着从树中抽取**知识图谱，**捕获细粒度实体及其关系。
具体流程： 树构建完成后，在每个节点上执行实体与关系抽取。文本块由大模型处理，含图片块由多模态模型处理。表格与公式做专项处理：对表格，将行、列标题抽取为实体，并通过 ContainedIn 关系链接到表格节点。 这些局部子图通过一种基于梯度的新型实体对齐方法合并为全局知识图谱：系统分析重排模型的相似度分数，识别明显的分数骤降点，检测并统一共指实体。
最终通过 GT-Link（图谱–树链接） 将两者关联，把实体映射回其来源的树节点。最终形成结构化三元组：B = (T, G, M)——树（Tree）、图谱（Graph）、映射（Mapping）。
特别地，GT-Link 在图谱与树之间建立双向桥梁： 从图谱中任意实体，可回溯到其来源的精确树节点（章节、表格、段落）； 从树中任意章节，可展示其包含的实体。 这种设计让结构与语义紧密耦合——系统不仅知道“是什么”，还知道“在文档的哪里”。
2. 基于梯度的更精准实体对齐
为保证知识图谱上的高质量推理，BookRAG 使用基于梯度的实体对齐方法。
不同于对所有实体做平方级别的两两比较，BookRAG 将实体对齐重构为：对每个新实体做增量查找。 在单文档（干净实体对齐）场景下，每当抽取新实体，系统判断它是否只是已有实体的别名。
做法是： 从向量库召回候选列表 → 用打分模型排序 → 检查相似度分数是否出现明显骤降。
-
若出现明显骤降：系统隔离高置信候选集
-
只有一个实体 → 直接合并
-
多个实体 → 调用大模型选择标准实体并合并
-
若无明显骤降 → 作为独立实体
这种基于梯度的方法避免了全量两两比对的高昂开销，同时保持图谱简洁紧凑——将“LLM”与“大语言模型”这类变体统一到单个节点。
3. 基于智能体的自适应检索
图4：BookRAG 中基于智能体的检索通用流程，包含基于智能体的规划、检索与生成。[来源]
依托**信息觅食理论（IFT），**BookRAG 引入智能体，根据问题类型动态调整检索策略：
-
单跳：
直接事实查询
-
多跳：
需要跨章节推理
-
全局聚合：
需要遍历整篇文档
图5：BookRAG 算子库与来自 MMLongBench 数据集的执行示例： (a) 四类算子（公式器、选择器、推理器、合成器）可视化； (b) 单跳查询的执行轨迹，展示智能体规划与分步算子执行。[来源]
智能体生成由模块化算子组成的动态计划： 有的用于追踪信息线索、定位相关片段； 有的用于过滤块； 有的用于推理或合成最终答案。
每个查询都根据需求走定制化路径。这种设计让 BookRAG 在超长复杂文档上也能平衡精度与效率。
案例分析
图6：来自 MMLongBench 与 Qasper 的三类查询（单跳、多跳、全局聚合）案例。 青色：BookRAG 生成的正确内容； 灰色：内部过程与省略的无关部分。[来源]
图6 完整展示 BookRAG 如何处理三类查询：
- 单跳：缩小搜索空间用户提出直白事实问题。BookRAG 先用
Extract算子识别相关实体，再用Select_by_Entity过滤树结构，将推理范围从 134 个节点缩小到 24 个。随后执行Graph_Reasoning与Text_Reasoning打分，用Skyline_Ranker选出最终 8 个高置信节点生成答案。 - 全局聚合：精准过滤与统计问题需要统计指定页码内的图片数量。BookRAG 用
Filter_Range选定第 1–10 页，用Filter_Modal筛选图片块，得到精确节点子集，再通过Map与Reduce执行聚合操作（如计数）得到答案。 - 多跳：分解与攻克对需要对比两个系统的复杂查询，智能体用
Decompose算子拆分为子问题，分别检索答案后再合成。
实验评估
实验不仅证明 BookRAG 能准确回答问题，还突出另外两大优势：
-
检索覆盖度
（能否找到所有相关信息）
-
效率
（运行成本与响应速度）
完整评估细节可查阅参考文献。
思考
对于长文档（结构化手册、技术报告、科研论文）的复杂问答，BookRAG 提供了经过基准验证的可靠设计方向。
它构建原生文档索引 BookIndex，融合层级树、知识图谱与 GT-Link（将实体映射回结构位置）；并在此之上加入能追踪“信息线索”的智能体。
但在真实落地中，我有一点担忧：当前实体对齐仅限于单文档内合并。在企业级场景中，知识往往跨成百上千份文档，跨文档实体统一是刚需。
**在我看来，一个很有前景的方向是： 把 BookIndex 不仅当作检索索引，更视为文档本身的原生知识层。**除问答外，它还可支持一致性校验、结构化摘要、交叉引用修复等。 在这种视角下，树–图谱结构成为文档生命周期的一部分，而不只是后端 RAG 优化技巧。
更进一步，可以思考：智能体的算子规划能否进化为**可学习的策略层？**借助足够多的交互日志或强化学习，系统可自我调优——决定使用哪些算子、何时简化、如何在保持表达能力的同时维持效率。这正是工业落地所需要的可控性。
参考文献：BookRAG: A Hierarchical Structure-aware Index-based Approach for Retrieval-Augmented Generation on Complex Documents
-------------------------------------------------------------
