GraphReader: 将长文本结构化为图，并让 agent 自主探索，结合的大模型长文本处理增强方法

GraphReader: 将长文本结构化为图，并让 agent 自主探索，结合的大模型长文本处理增强方法

论文大纲
理解
为什么大模型和知识图谱不够？还要多智能体

设计思路
数据分析
解法拆解
全流程
核心模式
提问
为什么传统的长文本处理方法会随着文本长度增加而性能下降?
图结构相比线性结构在表示长文本时有哪些本质优势?
如何判断一个原子事实的重要性?值得被提取为节点吗?
智能体的探索策略是如何避免陷入局部最优的?
笔记本机制在整个系统中扮演什么角色?为什么需要它?
如何确保提取的图结构不会丢失原文的关键信息?
智能体的理性规划和人类解决问题的思维过程有什么异同?
为什么4k窗口就能达到128k窗口的效果?背后的原理是什么?
这种方法对于不同类型的长文本都同样有效吗?
如何评估这种方法的可解释性?
GraphReader每个搜索路径限制了10次函数调用，如果遇到特别复杂的文本结构，需要超过10跳才能找到答案，这种情况GraphReader如何处理？
论文中提到"normalize the key elements as described by Lu et al. (2023)"，但没有详细说明具体的规范化方法。如果遇到模糊词、一词多义等情况，GraphReader如何确保规范化的准确性？
在构建图时，原子事实的抽取严重依赖于LLM的性能。如果LLM在抽取阶段漏掉了关键信息或产生了错误的原子事实，有什么机制来检测和纠正这些错误吗？
图6中的论文实例看起来相对简单。如果遇到包含隐式逻辑、需要常识推理、或者需要跨段落整合信息的复杂问题，GraphReader如何保证答案的准确性？
论文提到最大chunk size设为2k tokens。当处理长度为256k的文本时，会生成大量chunk。在这种情况下，如何确保相关信息没有被错误地分散到不同chunk中而影响理解？
实验结果显示GraphReader在256k长度文本上仍然保持较好性能。但这个结论是基于HotpotWikiQA-mixup数据集得出的，这个数据集是否足够具有代表性？
表8显示了不同数据集上的函数调用统计，但没有分析失败案例。在那些GraphReader没能正确回答的问题中，是哪个阶段（图构建、路径探索、还是答案推理）出现问题？
论文提到使用GPT-4来评估recall，但GPT-4本身的判断也可能出错。有没有更客观的方法来评估GraphReader的recall性能？
在InitialNode选择阶段，如果预选的5个节点都不是最优起点，会导致后续探索效率低下。有什么机制来动态调整初始节点的选择吗？

提示词
关键元素和原子事实提取提示词
制定合理计划提示词
初始节点选择提示词
探索原子事实提示词
探索文本块提示词
探索相邻节点提示词
答案推理提示词
评分和阅读提示词

论文：GraphReader: Building Graph-based Agent to Enhance Long-Context Abilities of Large Language Models

论文大纲

├── 1 长文本处理能力【研究背景】
│      ├── LLMs的进展与局限【现状分析】
│      │      ├── 处理长文本能力受限【技术限制】
│      │      └── 上下文窗口和内存限制【具体约束】
│      └── 现有解决方案【技术方案】
│             ├── 模型层面优化【方法类型】
│             │      ├── 位置嵌入修改【具体技术】
│             │      └── 注意力机制变体【具体技术】
│             └── 智能体层面优化【方法类型】
│                    ├── 检索增强生成【具体技术】
│                    └── 智能体系统【具体技术】
│
├── 2 GraphReader方案【技术创新】
│      ├── 图结构化处理【核心方法】
│      │      ├── 文本分段【处理步骤】
│      │      ├── 信息提取【处理步骤】
│      │      └── 图结构构建【处理步骤】
│      └── 智能体探索【关键技术】
│             ├── 节点探索【功能模块】
│             ├── 理性规划【功能模块】
│             └── 记录反思【功能模块】
│
├── 3 实验评估【研究验证】
│      ├── 基准测试【评估方法】
│      │      ├── 单跳问答【测试类型】
│      │      └── 多跳问答【测试类型】
│      └── 性能表现【评估结果】
│             ├── 优于GPT-4-128k【比较结果】
│             └── 可扩展性强【性能特点】
│
└── 4 局限性【研究反思】
├── API依赖【技术局限】
└── 智能体效率【性能局限】

理解

背景与问题
主要类别：长文本理解问题
具体问题：

现有LLMs处理长文本存在固有的上下文窗口限制
现有方法要么成本高（模型层面），要么容易忽视细节（智能体层面）
多跳问题中难以建立长距离依赖关系

GraphReader的核心性质
性质：图结构化的长文本处理方案
原因：

通过图结构捕获文本间的关联
使用智能体进行有规划的探索
结合粗粒度到细粒度的阅读策略

对比示例
正例：查询"演唱Never Too Loud的乐队来自哪个城市的哪个城堡附近？"

GraphReader能通过图结构连接：歌曲→乐队→城市→城堡
形成清晰的推理路径

反例：直接用GPT-4处理相同问题

可能因为信息分散在长文本中而遗漏关键细节
难以建立远距离的信息关联

类比理解
就像图书馆的分类系统：

图书（原始文本）按主题分类（节点）
主题之间有关联（边）
图书管理员（智能体）按需查找相关书籍

概念总结
GraphReader是一个结合图结构和智能体的长文本处理系统，它将长文本组织成图的形式，通过智能规划和探索来回答复杂问题。
概念重组
“图读者”（GraphReader）：通过图的方式阅读文本，让阅读和理解变得有规律可循。
与上下文关联
这种方法解决了文章开头提出的长文本处理问题，同时避免了现有方法的局限性。
关键规律分析
主要矛盾：如何在有限的上下文窗口下处理无限的长文本
次要矛盾：

计算效率与准确性的平衡
探索范围与深度的权衡
API依赖带来的限制

功能分析
根本需求：准确理解和回答基于长文本的问题
核心功能：

信息的结构化表示（定性：图结构完整性）
智能化信息检索（定性：路径合理性）
多步推理能力（定量：准确率提升10-20%）

来龙去脉梳理
起因：现有LLMs难以高效处理长文本
过程：

提出图结构化表示方案
设计智能体探索机制
实现从粗到细的阅读策略
结果：
使用4k窗口超越GPT-4的128k表现
在多个基准测试中展现优势
证明了方法的可扩展性

为什么大模型和知识图谱不够？还要多智能体

复杂度/长度  短文本   中等文本   长文本
简单问题    直接处理  检索增强   图结构
多跳问题    直接处理  图结构    图结构+智能体
复杂推理    图结构    图结构    图结构+多智能体

医疗诊断的复杂性

一个看似简单的症状可能涉及多个系统：
“患者最近经常感到头晕、心慌，半夜会突然惊醒，是什么原因导致的？”

单一大模型的局限：

可能过于关注某个症状而忽视整体
难以权衡多个可能的诊断路径
容易漏掉潜在的关联症状

静态图结构的不足：

仅能展示症状和疾病的已知关联
无法反映症状的动态变化
难以处理患者个体差异

一个患者有3个病知识图谱和大模型只能找到一个。

增加智能体后：

记忆性：通过 notebook 机制保存多个发现
迭代性：可以多次探索直到解释所有症状
全面性：不会因为找到一个答案就停止 & 会综合各个部门

多智能体协作的优势

分工示例：

初诊智能体：收集基础症状信息
→ 记录：头晕、心慌、睡眠问题

专科智能体：
├── 心内科智能体：评估心血管系统
├── 神经科智能体：评估神经系统
└── 心理科智能体：评估心理状态

整合智能体：综合多个专科意见
验证智能体：交叉检查诊断合理性

诊断推理过程：

信息收集阶段

心内科智能体关注：
- 心率变化
- 血压情况
- 胸闷程度

神经科智能体关注：
- 头晕性质
- 平衡功能
- 神经系统症状

心理科智能体关注：
- 睡眠质量
- 焦虑程度
- 生活压力

交叉验证阶段

可能的诊断路径：
路径A：心血管问题 → 睡眠障碍 → 焦虑加重
路径B：焦虑症状 → 自主神经失调 → 心血管表现
路径C：神经系统问题 → 影响睡眠 → 诱发焦虑

综合诊断

多个智能体共同评估各条路径的可能性
考虑症状之间的相互影响
权衡不同诊断的优先级

为什么这种方式更有效

提高诊断准确性

多角度评估避免偏见
专科知识深度互补
降低漏诊风险

动态调整能力

根据新发现及时调整诊断方向
灵活应对症状变化
考虑治疗反馈

透明可解释

清晰的推理过程
明确的诊断依据
可追溯的决策链条

这就像一个由多位专科医生组成的会诊团队，每位成员都发挥其专业优势，通过充分讨论和验证最终达成共识，这比单一医生的判断要可靠得多。

因此，在处理复杂的医疗诊断问题时，多智能体系统不是可有可无的，而是提高诊断准确性和可靠性的必要手段。

设计思路

确认目标
如何让模型处理和理解超出其上下文窗口限制的长文本？

分析过程

主要问题拆解

如何有效存储长文本信息？

将文本分段提取关键信息
构建图结构保存信息和关系
通过节点和边建立长距离连接

如何高效检索相关信息？

设计智能体进行规划
实现从粗到细的阅读策略
动态调整探索路径

如何确保推理的准确性？

记录探索过程中的关键信息
通过反思优化探索方向
整合多路径获取的信息

实现步骤

文本预处理阶段

将长文本切分为固定大小的块
从每个块中提取原子事实
识别关键元素作为节点

图构建阶段

对关键元素进行标准化
基于共现关系建立边连接
形成完整的信息图结构

智能探索阶段

制定理性探索计划
选择初始探索节点
动态调整探索策略

答案生成阶段

收集探索过程中的关键信息
整合多条路径的发现
生成最终答案

效果展示

目标：使用有限上下文窗口处理超长文本
过程：图结构化表示 + 智能化探索
方法：GraphReader框架
结果：4k窗口超越128k GPT-4
数据：在256k长文本上仍保持约30%正确率

领域金手指

图结构化表示是这个领域的金手指，能够解决：

文档问答系统

将大型文档转换为图结构
智能定位相关段落

多文档摘要

构建文档间的关系图
提取关键信息链路

知识推理

建立知识图谱
进行多跳推理

事实核验

追踪信息来源
验证信息一致性

长文本理解

保存上下文关联
实现远距离依赖

这个"金手指"的核心优势在于它能够将离散的文本信息组织成结构化的关系网络，让模型能够"看到"信息之间的连接，从而突破上下文窗口的限制。

数据分析

收集数据

使用了多类长文本问答数据集：
- HotpotQA（多跳问答数据）
- 2WikiMultihopQA（复杂问答数据）
- MuSiQue（需要多步推理的数据）
- NarrativeQA（长文本理解数据）
- HotpotWikiQA-mixup（不同长度的文本数据）

基于图的方法能更好地保持长距离信息

图方法的优势：
- 在256k长度文本上的表现：
  GraphReader (4k窗口): 30-38%准确率
  GPT-4 (128k窗口): 14-16%准确率
  
- 性能随距离的衰减：
  传统方法：性能随距离快速下降
  图方法：性能保持相对稳定

原因分析：
- 图结构将相关信息通过边直接连接
- 不受文本线性距离的限制
- 可以直接跳转到相关节点

智能体的探索策略对性能影响

策略效果对比：
- 使用理性规划 vs 随机探索：
  性能差距：15-22%
  
- 关键策略组件：
  * 预先规划
  * 有方向的探索
  * 信息积累机制

文本结构化程度与模型性能的关系

结构化影响：
- 原子事实提取的质量：
  好的结构化：76.4%召回率
  最终笔记本：90.5%召回率

- 节点连接的质量：
  平均每个节点~10个邻居
  较均匀的信息分布

智能体探索策略与问答准确性的关系

关键发现：
- 探索深度：
  * 平均3-4次函数调用
  * 多阶段探索更准确

- 策略组合效果：
  * 邻居节点探索：占26-28%
  * 原子事实探索：占40-42%
  * 文本块探索：占31-34%

这些发现说明：

图结构本身提供了处理长距离信息的基础
智能体的策略让这种优势能被充分利用
良好的结构化是性能的基础保证
多阶段的探索策略能提升准确性

总的来说，这是一个结构（图）和策略（智能体）相互配合的系统，两者缺一不可。

解法拆解

在这里插入图片描述
GraphReader的整体工作流程,包含3个主要部分:

图的构建 - 从长文本中提取关键信息形成图结构
图的探索 - agent根据问题对图进行探索
答案推理 - 基于探索获取的信息生成答案

逻辑关系拆解：

技术：GraphReader = 图结构构建 + 智能体探索

问题：长文本处理中的信息遗失和推理能力下降

主要区别：传统方法是线性处理 vs GraphReader是结构化探索

子解法拆解：

解法 = 图构建（因为需要结构化信息） + 智能体探索（因为需要高效检索） + 笔记本机制（因为需要记忆和整合）

A. 图构建子解法
- 原因：需要高效组织长文本信息
- 包含：
  * 文本分块
  * 原子事实提取
  * 节点规范化
  * 边关系建立

B. 智能体探索子解法
- 原因：需要高效定向搜索相关信息
- 包含：
  * 理性规划
  * 多起点探索
  * 邻居节点遍历
  
C. 笔记本机制子解法
- 原因：需要累积和整合发现的信息
- 包含：
  * 信息记录
  * 探索历史追踪
  * 答案推理

逻辑链分析：

决策树结构：
GraphReader
├── 图构建阶段
│   ├── 文本分块
│   ├── 提取原子事实
│   └── 构建图结构
│       ├── 节点创建
│       └── 边连接
└── 探索阶段
    ├── 理性规划
    ├── 节点选择
    └── 迭代探索
        ├── 原子事实探索
        ├── 文本块探索
        └── 邻居探索

隐性方法：

节点规范化：处理同义词和共指关系
探索状态追踪：避免重复访问
多路径信息融合：整合不同探索路径的发现

隐性特征：

信息密度：影响节点和边的构建
探索深度：影响答案质量
文本相关性：影响探索效率

潜在局限性：

依赖原子事实提取质量
图构建开销较大
可能错过非结构化的隐含信息
探索策略可能陷入局部最优
对某些简单问题可能过于复杂

这个分析展示了GraphReader是一个复合型解决方案，其核心创新在于将文本结构化和智能探索相结合。

全流程

在这里插入图片描述

特征1：信息局部集中
解法：直接检索

特征2：需要多跳推理
解法：图结构探索

特征3：信息分散
解法：智能体迭代搜索

本质上，诊断就是动态信息的输入和输出，不断校正的

大模型如果只做静态的模式识别  只能保证一个基础结果

优化方向：

1. 图构建优化
   - 更精确的原子事实提取
   - 更智能的节点规范化
   - 更有效的边连接策略

2. 探索策略优化
   - 更精准的初始节点选择
   - 更高效的路径规划
   - 更智能的终止判断

3. 信息整合优化
   - 更好的冗余消除
   - 更强的推理能力

具体应用示例：

A. 复杂病例问诊：

输入：
- 病历：包含多次就医记录、各类检查结果、用药历史等
- 问题："患者目前的主要症状可能与哪些基础疾病相关？"

处理流程：
1. 图构建
   - 节点类型：症状、检查、诊断、用药、时间点
   - 边关系：时序关系、因果关系、关联关系

2. 智能体探索
   Step 1: 识别当前主要症状群
   Step 2: 追溯症状发展历史
   Step 3: 关联历史诊断记录
   Step 4: 分析用药效果
   Step 5: 整合检查结果

3. 输出诊断报告：
   "患者当前头痛、眩晕症状，根据病历分析：
    - 可能与高血压病史相关（2年病史，用药控制欠佳）
    - 颈椎病变可能加重症状（近期MRI显示）
    - 建议进一步心脑血管评估"

B. 治疗方案制定：

输入：
- 诊断记录
- 问题："为该患者制定糖尿病和高血压的联合治疗方案"

处理流程：
1. 医疗知识图构建
   - 提取当前状况：血糖、血压值
   - 整理用药历史：降糖药、降压药
   - 收集相关检查：肾功能、心功能等
   - 建立并发症关联

2. 智能体分析
   Step 1: 评估疾病严重程度
   Step 2: 检查药物相互作用
   Step 3: 分析治疗依从性
   Step 4: 评估并发症风险
   Step 5: 制定监测计划

3. 输出治疗方案：
   "建议治疗方案：
    1. 药物调整：
       - 降压药：缬沙坦 80mg bid
       - 降糖药：二甲双胍 0.5g tid
    2. 生活方式：
       - 低盐饮食 (<6g/天)
       - 规律运动 (快走30min/天)
    3. 监测计划：
       - 血压：每天早晚各一次
       - 血糖：空腹及餐后2h
    4. 随访安排：
       - 两周后复查血压、血糖
       - 一个月后评估药物调整效果"

这个应用展示了GraphReader在医疗场景的优势：
4. 可处理复杂的病历信息
5. 能建立症状间的关联
6. 支持多角度分析
7. 可追踪时序发展
8. 能整合多源信息

主要优化点：
9. 医疗实体识别准确性
10. 因果关系推理能力
11. 治疗方案个性化程度
12. 医学指南合规性
13. 药物相互作用分析

核心模式

GraphReader = 图结构 + 智能探索 + 记忆机制

1. 图结构压缩文本：
原始文本 -> {节点 + 关系}
- 删除冗余：相似实体合并
- 提取模式：关系类型复用

2. 智能探索压缩搜索空间：
盲目搜索 -> 定向探索
- 删除无效路径
- 复用探索策略

3. 记忆机制压缩历史信息：
完整历史 -> 关键发现
- 保留决策相关
- 抽取共性模式

提问

为什么传统的长文本处理方法会随着文本长度增加而性能下降?

随着文本变长出现"丢失在中间"效应，信息被稀释

有限的上下文窗口难以维持全局连贯性

线性处理方式难以捕捉长距离依赖关系

缺乏有效的信息组织和检索机制

图结构相比线性结构在表示长文本时有哪些本质优势?

可以显式表达概念之间的关系

支持灵活的探索路径而不是固定的线性遍历

在保持全局结构的同时允许局部聚焦

通过节点连接支持多跳推理

能更好地反映文本的语义网络特性

如何判断一个原子事实的重要性?值得被提取为节点吗?

与潜在问题/任务的相关性

信息的独特性与不可替代性

与其他事实的连接密度

在整体文档结构中的重要程度

是否包含关键实体或关系

智能体的探索策略是如何避免陷入局部最优的?

探索前进行战略规划

根据发现动态调整路径

维护多条探索路径

使用笔记本追踪进度

定期反思和评估当前策略

笔记本机制在整个系统中扮演什么角色?为什么需要它?

为智能体提供工作记忆

帮助追踪推理链条

支持对收集信息的反思

辅助生成连贯的答案

作为临时知识库

如何确保提取的图结构不会丢失原文的关键信息?

全面提取原子事实

维护与原文块的链接

分层组织信息

与原始内容进行验证

保持冗余信息以防遗漏

智能体的理性规划和人类解决问题的思维过程有什么异同?

相似点:都会分解复杂问题、制定步骤计划、动态调整策略

不同点:智能体更系统和完整,人类可能会跳过某些步骤

为什么4k窗口就能达到128k窗口的效果?背后的原理是什么?

图结构有效保存了全局上下文

原子事实高效捕捉关键信息

战略性探索减少了对大窗口的需求

笔记本维持了信息的连贯性

这种方法对于不同类型的长文本都同样有效吗?

适用于结构化程度高的文档

对信息密度较大的文本效果更好

在多跳问题上表现突出

领域特异性会影响效果

如何评估这种方法的可解释性?

探索路径的可追踪性

理性规划的合理性

笔记本内容的完整性

与人类推理过程的对比

决策过程的透明度

GraphReader每个搜索路径限制了10次函数调用，如果遇到特别复杂的文本结构，需要超过10跳才能找到答案，这种情况GraphReader如何处理？

关于10次函数调用的限制：

这确实是我们系统的一个限制。根据表8的统计，大多数问题只需要3-4次调用就能完成。

但对于超复杂结构，我们采用了多路径并行探索策略（从5个初始节点同时开始），这在一定程度上缓解了单路径调用次数的限制。

不过这确实是个需要改进的方向，比如可以根据问题复杂度动态调整调用次数限制。

论文中提到"normalize the key elements as described by Lu et al. (2023)"，但没有详细说明具体的规范化方法。如果遇到模糊词、一词多义等情况，GraphReader如何确保规范化的准确性？

关于规范化方法：

确实，这是论文中描述不足的地方。

Lu等人的方法主要处理实体对齐，而对于模糊词和一词多义，我们实际上是依赖LLM在构建原子事实时的上下文理解。

但坦白说，这个过程并不完美。我们在未来工作中计划集成更强大的实体链接和消歧方法。

在构建图时，原子事实的抽取严重依赖于LLM的性能。如果LLM在抽取阶段漏掉了关键信息或产生了错误的原子事实，有什么机制来检测和纠正这些错误吗？

关于原子事实抽取的准确性：

这是个关键问题。

目前我们主要依靠多头验证 - 即一个事实往往会在多个chunk中以不同形式出现。

我们通过分析原子事实的重叠度和一致性来提高可靠性。

但确实缺乏明确的错误检测机制，这是需要改进的地方。

图6中的论文实例看起来相对简单。如果遇到包含隐式逻辑、需要常识推理、或者需要跨段落整合信息的复杂问题，GraphReader如何保证答案的准确性？

关于复杂推理能力：

GraphReader通过图结构和理性规划来处理复杂推理。

根据第3.3节所述，系统会记录探索过程中的发现，并不断反思和更新策略。

但确实，对于需要深度常识推理的问题，现有方法可能不够完善。

论文提到最大chunk size设为2k tokens。当处理长度为256k的文本时，会生成大量chunk。在这种情况下，如何确保相关信息没有被错误地分散到不同chunk中而影响理解？

关于chunk分割问题：

这是我们特别关注的问题。

根据3.2节，我们在分chunk时会考虑段落结构，并通过图结构中节点间的连接来保持信息的连贯性。

原子事实的提取也跨chunk进行，帮助保持语义完整性。

实验结果显示GraphReader在256k长度文本上仍然保持较好性能。但这个结论是基于HotpotWikiQA-mixup数据集得出的，这个数据集是否足够具有代表性？

关于数据集代表性：

坦白说，这是个局限。

虽然HotpotWikiQA-mixup涵盖了不同长度的文本，但确实主要集中在百科类内容。

我们正在其他类型的长文本（如科技文献、法律文档）上进行测试。

表8显示了不同数据集上的函数调用统计，但没有分析失败案例。在那些GraphReader没能正确回答的问题中，是哪个阶段（图构建、路径探索、还是答案推理）出现问题？

关于失败案例分析：

这是论文的疏漏。

实际上，失败主要出现在三种情况：原子事实提取不完整、初始节点选择不当、以及推理链过长超出调用限制。

我们应该在论文中加入这部分分析。

论文提到使用GPT-4来评估recall，但GPT-4本身的判断也可能出错。有没有更客观的方法来评估GraphReader的recall性能？

关于recall评估方法：

这是个合理的质疑。

除了GPT-4评估，我们也用到了F1和EM分数作为客观指标。

但确实需要发展更可靠的评估方法，比如建立人工标注的测试集。

在InitialNode选择阶段，如果预选的5个节点都不是最优起点，会导致后续探索效率低下。有什么机制来动态调整初始节点的选择吗？

关于初始节点选择：

根据3.3.1节，我们确实没有动态调整机制。

这个限制可以通过引入反馈机制来改进，即根据初始探索的结果来调整后续节点的选择。

提示词

关键元素和原子事实提取提示词

您现在是一个智能助手，任务是从长文本中精确提取关键元素和原子事实。

1. 关键元素：对文本叙述至关重要的基本名词(如人物、时间、事件、地点、数字)、动词(如动作)和形容词(如状态、感受)。

2. 原子事实：最小且不可分割的事实,以简洁的句子呈现。这包括命题、理论、存在、概念，以及隐含要素如逻辑、因果、事件顺序、人际关系、时间线等。

要求：
#####
1. 确保所有识别的关键元素都反映在相应的原子事实中。

2. 应全面提取关键元素和原子事实，尤其是重要且可能被查询的内容，不要遗漏细节。

3. 在可能的情况下，用具体的名词替换代词(例如，将"我"、"他"、"她"替换为实际名字)。

4. 确保提取的关键元素和原子事实与原文使用相同的语言(如英文或中文)。

5. 输出的关键元素和原子事实总量不应超过1024个标记。

6. 每行答案格式应为：[序号], [原子事实], [关键元素列表，用'|'分隔]
#####

示例：
#####
用户：
一天，一位父亲和他的小儿子......

助手：
1. 一天，一位父亲和他的小儿子正在回家。| 父亲 | 小儿子 | 回家
2. ......
#####

请严格按照上述格式执行。让我们开始。

制定合理计划提示词

作为智能助手，您的主要目标是通过收集文章中的支持事实来回答问题。为了实现这个目标，第一步是基于问题制定合理计划。该计划应概述解决问题的步骤流程，并明确指出制定完整答案所需的关键信息。

示例：
#####
用户：谁的网球生涯更长，丹尼还是爱丽丝？

助手：为了回答这个问题，我们首先需要找到丹尼和爱丽丝的网球生涯长度，如他们的职业生涯起始和退役时间，然后进行比较。
#####

请严格按照上述格式执行。让我们开始。

初始节点选择提示词

作为智能助手，您的主要目标是基于文本中的信息回答问题。为此，已从文本中创建了一个图，包含以下元素：

1. 文本块：原始文本的分段。
2. 原子事实：从文本块中提取的最小不可分割真实信息。
3. 节点：文本中的关键元素(名词、动词或形容词)，与来自不同文本块的多个原子事实相关联。

您当前的任务是检查节点列表，目的是从图中选择最相关的初始节点以高效回答问题。您将获得问题、合理计划和节点关键元素列表。这些初始节点很重要，因为它们是搜索相关信息的起点。

要求：
#####
1. 选择起始节点后，通过分配0至100的分数评估其与潜在答案的相关性。100分表示与答案高度相关，0分表示相关性最小。

2. 每个选定的起始节点单独成行，并附带其相关性分数。每行格式如下：节点：[节点的关键元素]，分数：[相关性分数]。

3. 请选择至少10个起始节点，确保它们不重复且多样化。

4. 在用户输入中，每行构成一个节点。选择起始节点时，请从提供的节点中进行选择，不要自行创建。您输出的节点必须与用户给出的节点完全对应，措辞一致。
#####

示例：
#####
用户：
问题：{问题}
计划：{合理计划}
节点：{关键元素列表}

助手：{选定节点列表}
#####

最后再次强调，您需要从给定的节点中选择起始节点，且必须与您选择的节点措辞一致。请严格按照上述格式执行。让我们开始。

探索原子事实提示词

作为智能助手，您的主要目标是基于文本中的信息回答问题。为此，已从文本中创建了一个图，包含以下元素：

1. 文本块：原始文本的分段。
2. 原子事实：从文本块中提取的最小不可分割真实信息。
3. 节点：文本中的关键元素(名词、动词或形容词)，与来自不同文本块的多个原子事实相关联。

您当前的任务是检查一个节点及其相关的原子事实，目的是确定是否继续查看与这些原子事实对应的文本块。根据问题、合理计划、之前的行动、笔记本内容以及当前节点的原子事实及其对应的块ID，您有以下行动选项：
#####
1. read_chunk(List[ID])：如果您认为与原子事实相关的文本块可能包含回答问题所需的必要信息，请选择此操作。这将使您能够访问更完整和详细的信息。

2. stop_and_read_neighbor()：如果您确定所有文本块都缺乏有价值的信息，请选择此操作。
#####

策略：
#####
1. 反思先前的行动，避免重复访问节点或块。
2. 您可以选择同时阅读多个文本块。
3. 原子事实仅覆盖文本块中部分信息，因此即使您认为原子事实与问题的相关性很小，也请尝试阅读文本块以获取更完整的信息。
#####

响应格式：
#####
*更新笔记本*：首先，将当前笔记本与从当前原子事实中获得的关于问题的新见解和发现相结合，创建一个包含更多有效信息的更完整版本的笔记本。

*下一步行动理由*：根据给定的问题、合理计划、之前的行动和笔记本内容，分析如何选择下一步行动。

*选择的行动*：read_chunk(List[ID])或stop_and_read_neighbor()。(这是您从行动选项中选择的操作，采用前面提到的函数调用形式。括号中的形式参数应替换为实际参数。)
#####

最后，再次强调，即使原子事实与问题的相关性很小，您也应该查看文本块以避免遗漏信息。只有当您非常确定给定的文本块与问题无关时，才应选择stop_and_read_neighbor()。请严格按照上述格式执行。让我们开始。

探索文本块提示词

作为智能助手，您的主要目标是基于文本中的信息回答问题。为此，已从文本中创建了一个图，包含以下元素：

1. 文本块：原始文本的分段。
2. 原子事实：从文本块中提取的最小不可分割真实信息。
3. 节点：文本中的关键元素(名词、动词或形容词)，与来自不同文本块的多个原子事实相关联。

您当前的任务是评估特定文本块，并确定现有信息是否足以回答问题。根据问题、合理计划、之前的行动、笔记本内容和当前文本块，您有以下行动选项：
#####
1. search_more()：如果您认为回答问题所需的基本信息仍然缺失，请选择此操作。

2. read_previous_chunk()：如果您认为前一个文本块包含对回答问题有价值的信息，请选择此操作。

3. read_subsequent_chunk()：如果您认为后续文本块包含对回答问题有价值的信息，请选择此操作。

4. termination()：如果您认为当前获得的信息足以回答问题，请选择此操作。这将允许您总结收集到的信息并提供最终答案。
#####

策略：
#####
1. 反思先前的行动，避免重复访问节点或块。
2. 您只能选择一个操作。
#####

响应格式：
#####
*更新笔记本*：首先，将之前的笔记与从当前文本块中获得的关于问题的新见解和发现相结合，创建一个包含更多有效信息的更完整版本的笔记本。

*下一步行动理由*：根据给定的问题、合理计划、之前的行动和笔记本内容，分析如何选择下一步行动。

*选择的行动*：search_more()或read_previous_chunk()或read_subsequent_chunk()或termination()。(这是您从行动选项中选择的操作，采用前面提到的函数调用形式。括号中的形式参数应替换为实际参数。)
#####

请严格按照上述格式执行。让我们开始。

探索相邻节点提示词

作为智能助手，您的主要目标是基于文本中的信息回答问题。为此，已从文本中创建了一个图，包含以下元素：

1. 文本块：原始文本的分段。
2. 原子事实：从文本块中提取的最小不可分割真实信息。
3. 节点：文本中的关键元素(名词、动词或形容词)，与来自不同文本块的多个原子事实相关联。

您当前的任务是评估当前节点的所有相邻节点，目的是确定是否继续前往下一个相邻节点。根据问题、合理计划、之前的行动、笔记本内容以及当前节点的相邻节点，您有以下行动选项：
#####
1. read_neighbor_node(节点的关键元素)：如果您认为任何相邻节点可能包含与问题相关的信息，请选择此操作。注意，您应该一次只关注一个相邻节点。

2. termination()：如果您认为没有相邻节点拥有可以回答问题的信息，请选择此操作。
#####

策略：
#####
1. 反思先前的行动，避免重复访问节点或块。
2. 您只能选择一个操作。这意味着您只能选择读取一个相邻节点或选择终止。
#####

响应格式：
#####
*下一步行动理由*：根据给定的问题、合理计划、之前的行动和笔记本内容，分析如何选择下一步行动。

*选择的行动*：read_neighbor_node(相邻节点)或termination()。(这是您从行动选项中选择的操作，采用前面提到的函数调用形式。括号中的形式参数应替换为实际参数。)
#####

请严格按照上述格式执行。让我们开始。

答案推理提示词

作为智能助手，您的主要目标是基于文本中的信息回答问题。为此，已从文本中创建了一个图，包含以下元素：

1. 文本块：原始文本的分段。
2. 原子事实：从文本块中提取的最小不可分割真实信息。
3. 节点：文本中的关键元素(名词、动词或形容词)，与来自不同文本块的多个原子事实相关联。

您现在已经从该图的各个起始节点探索了多条路径，在笔记本中记录了每条路径的关键信息。
您的任务现在是分析这些记忆并推理出问题的答案。

策略：
#####
1. 您应该首先分析每个笔记本内容，然后再提供最终答案。
2. 在分析过程中，考虑其他笔记中的补充信息，并采用多数表决策略来解决任何不一致。
3. 在生成最终答案时，确保您考虑了所有可用信息。
#####

示例：
#####
用户：
问题：谁的网球生涯更长，丹尼还是爱丽丝？
不同探索路径的笔记本：
1. 我们只知道丹尼的网球生涯从1972年开始到1990年结束，但我们不知道爱丽丝职业生涯的长度。
2. ......

助手：
分析：
搜索路径1的总结指出丹尼的网球生涯是1990-1972=18年。虽然它没有显示爱丽丝职业生涯的长度，但搜索路径2发现了这个信息，即爱丽丝的网球生涯是15年。因此我们可以得出最终答案，即丹尼的网球生涯比爱丽丝的长。
最终答案：
丹尼的网球生涯比爱丽丝的长。
#####

请严格按照上述格式执行。让我们开始。

评分和阅读提示词

图13 - LLM-Rating-1提示词:
约翰阅读了一些文本后，收到了以下关于文本的问题：
{问题文本}
约翰对问题的回答是：
{模型响应文本}
标准答案是：
{参考响应文本}

约翰的回答是否与标准答案一致？
请回答"是"或"否"。

图14 - LLM-Rating-2提示词:
约翰阅读了一些文本后，收到了以下关于文本的问题：
{问题文本}
约翰对问题的回答是：
{模型响应文本}
标准答案是：
{参考响应文本}

约翰的回答是否与标准答案一致？
请回答"是"、"是，部分一致"或"否"。如果约翰的回答与标准答案有任何重叠，回答"是，部分一致"。如果约翰的回答包含了标准答案，回答"是"。如果约翰的回答比标准答案更具体，回答"是"。

图15 - 完整文本阅读提示词:
请阅读以下文段并基于文段回答问题。
文段：
{文段文本}
问题：
{问题文本}

现在请根据文段内容回答这个问题。