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

处理结构化文档时，常因剥离版面层级，或因孤立内容块，现有RAG系统会失效，这致使表格归属混乱，还让跨章节推理困难，这种困境催生出新思路，即将文档层级树与知识图谱深度融合，为复杂文档问答提供了可验证的工程化方案。

文本优先与版面优先的双重困境

将所有内容转化为纯文本流的文本优先方法，是依赖OCR和BM25等检索技术的，这类方法在处理技术手册或研究报告之际，会致使章节与表格的从属关系丢失，比如说一个有着多个实验数据的表格，系统没办法判定它是属于方法部分亦或是结果部分，这就造成了信息定位错误，GraphRAG尽管构建了知识图谱，然而社区检测所形成的聚类依旧欠缺与文档结构的对齐。

遵循版面优先的办法留存了文档的视觉架构，把内容划分成段落、表格、图表等单独的块。这种办法能够精准地辨认每个元素的位置，然而块与块之间的语义联系被切断了。当问题要求跨越多个章节对数据进行比较时，系统仅仅能够孤立地查找各个块，没办法构建跨区域的推理线索，多跳问答的准确率于是大幅度降低了。

构建文档原生索引BookIndex

BookIndex的关键所在是打造一棵从版面块产生的层级树，系统起先借助语言模型审核疑似标题的文本块，判定其是不是真实标题并明确在文档层级里的级别，此过程把PDF或者Word文档的视觉结构转变为可编程的树状骨架，每一个节点对应一个章节、子章节或者独立的内容块，树结构给后续的实体映射以及检索供给了空间定位基础。

树构建完毕之后，系统针对每个节点开展实体与关系的提取工作。表格以及公式运用专门的处理逻辑：表格的行标题以及列标题被提取成实体，并借由ContainedIn关系链接回到表格节点；公式之中的变量定义同样被捕获且关联到所在的段落。这般精细化的提取保证不同模态的内容于语义层获得统一的表达。

实体消解与图-树映射

要把局部子图归结为全局知识图谱，得借助实体消解来合并。传统办法会对全部实体展开成对比较，其计算复杂度呈现二次增长态势。BookRAG运用梯度检测的办法，采用增量查找策略，会在每提取一个新实体时，从向量数据库召回候选集，并用重排序模型进行评分，当相似度分数出现急剧下降时，就能识别出高置信度候选。这种方式把“LLM”以及“Large Language Model”等变体归纳到同一个节点，并且还避开了穷举配对所需的高昂开销。

GT - Link于树和图之间构建双向桥梁联系，在知识图谱里，从任意一个实体出发，能够追溯至其源头的树节点，不妨举例来说，像是某一技术术语可定位到其最初出现的章节或者所在的表格；与之相反，树当中的每个章节同样能够列举出其中所涵盖的全部实体。这般双向关联致使系统在进行检索时，既能够借助语义关系，又能够留存文档原本的结构上下文。

信息觅食驱动的Agent检索器

BookRAG引入了受信息觅食理论启发的Agent，它会依据问题类型动态规划检索路径，单跳查询能直接定位至树节点或者实体，多跳查询当需要跨章节推理时，Agent会生成Decompose算子把问题拆分成子问题，分别进行检索后综合得出答案，全局聚合查询会扫描整篇文档的特定节点类型，每个查询在索引当中走不同的路径，避免了一刀切的检索方式所带来的效率损失。

实验验证聚焦于两个维度，一个是问答准确性，另一个是检索覆盖率。在MMLongBench数据集中，当面对统计特定页面范围内图片数量的任务时，Agent能够顺着树结构去定位页面区间并且筛选图片节点。对于比较两个系统的复杂问题，Decompose算子会把问题拆解为各自的技术特点检索，然后借助推理算子合成对比答案。

单文档局限与跨文档扩展

Extract

此刻实体消解方式仅支持单文档里的合并，这于实际部署当中是一个关键局限，企业级场景里知识分布于数百乃至数千个文档内，同一概念于不同文档里或许有不同表述，跨文档的实体统一变成必须要解决的问题，一种方向乃是把BookIndex从检索索引提升为文档自身原有知识层，让树-图结构成为文档生命周期的一部分。

演化为可学习的策略层的是未来Agent的值算子规划方向。积累充足交互日志此后，自行调优算子调用顺序以及简化时机的是系统。在确保推理质量情形下，维持运行效率对于走向生产环境起着关键作用的是系统。在此发挥作用的可能是强化学习框架路径，于探索以及利用之前找到平衡的是Agent。

Select_by_Entity

对于长篇技术文档里存在的要跨章节进行比较分析的情况，你认为当下的 RAG 系统最为急需突破的，是实体消解的精确程度，还是结构感知的检索本领呢？欢迎在评论区讲述你的实践经历。

Graph_Reasoning

Text_Reasoning

相关标签： # BookRAG # 层级文档 # 树-图融合 # RAG框架 # 信息觅食理论