PersonalAI 2.0：基于动态规划机制增强知识图谱遍历与检索的个性化 LLM 智能体框架 PersonalAI 2.0: Enhancing knowledge graph traversal/retrieval with planning mechanism for Personalized LLM Agents
在 GraphRAG 框架中引入 13 阶段动态规划流水线，用迭代式搜索计划增强实现多跳问答的 SOTA。
前置知识
GraphRAG（图检索增强生成）
GraphRAG 是在传统 RAG（向量检索+生成）基础上，将外部知识组织为图结构（节点=实体，边=关系）进行检索增强生成的方法。它通过图遍历而非扁平向量检索来定位相关子图，从而支持多跳推理与结构化事实查询。典型代表有 HippoRAG、LightRAG、RAPTOR 等。
本文 PAI-2 是 GraphRAG 范式的延伸，必须先理解 KG 节点-边的存储模型、嵌入向量辅助相似度匹配、PageRank/BeamSearch 等图遍历机制，才能看懂其流水线设计与对比基线选择。
多跳问答（Multi-hop QA）
指需要组合多个文档/三元组中的信息才能回答的复杂问答任务，例如「Payment On Demand 和 My Cousin From Warsaw 两部电影的导演是否来自同一国家」需要先分别查导演，再查国别，最后比较。多跳问答对传统 RAG 是难点，因为单次检索往往只能拿到其中一个事实片段。
本文核心动机正是解决多跳推理：HotpotQA、2WikiMultihopQA、MuSiQue 三个多跳基准的实验结果直接体现 PAI-2 的动态规划与图遍历增益。
知识图谱遍历算法（BeamSearch / WaterCircles / NaiveRetriever）
BeamSearch 从起始顶点沿多条路径并行扩展，使用 top-k 累积分数最高的路径；WaterCircles 以多顶点为圆心做有限跳数扩散，并按三元组类型分层排序；NaiveRetriever 则仅做扁平化的密集向量近邻检索，不展开邻域。三者的 trade-off 在召回范围与计算成本之间。
本文证明用图遍历算法（BS+NR、BS+WC）相比 NaiveRetriever 平均提升 6% LLM-as-a-Judge，是 PAI-2 的关键工程组件。
LLM-as-a-Judge 评估
用一个强 LLM（如 Qwen2.5 7B）按结构化提示对生成答案与标准答案进行 0/1 二分类判定的自动评估方法，常以 Krippendorff α 与人工标注的 Pearson r 验证可靠性。本文 Krippendorff α=0.93、r=0.88，证明其作为 judge 可靠。
本文主要指标 LLM-as-a-Judge 准确率直接依赖此范式；没有该评估方法，对多跳问答的细粒度答案正确性就难以量化。
提示工程（Prompt Engineering）
通过精心设计的 system/user 模板让 LLM 完成结构化子任务（去噪、分解、命名实体识别、计划生成、答案聚合等）的技术。本文中 13 个阶段基本都对应一张精心构造的提示表（Table 7–23），分别规定输入输出格式与约束。
PAI-2 的每一步都是 LLM 推理 + 提示工程的组合，提示质量直接决定计划增强、clue-query 生成与最终聚合的可靠性。
研究动机
现有 GraphRAG 系统在开放域多跳问答场景下普遍存在三类瓶颈：第一，依赖静态本体与节点级扁平检索，难以处理需要动态调整检索策略的多跳推理路径；第二，混合方法（LightRAG、RAPTOR、HippoRAG 2）虽然引入了图结构但缺少可迭代、可反思的搜索计划生成与修正机制，检索精度受限；第三，LLM 与 KG 的耦合方式粗糙——要么通过人工标注路径（RoG）牺牲可扩展性，要么靠多角色辩论（DoG）大幅增加计算开销。论文 Table 3 显示 HippoRAG 2 在 MuSiQue、DiaASQ 等难基准上的 LLM-as-a-Judge 仅 0.29 与 0.28，LightRAG 在 MuSiQue 上仅 0.01，RAPTOR 在 DiaASQ 上也只有 0.15，说明现有方法在多跳复杂问题上仍有显著的事实正确性损失与幻觉问题。
本文的目标是本文提出 PersonalAI 2.0 (PAI-2)，目标是在 7-14B 规模 LLM 上实现：(1) 13 阶段、端到端可执行的查询处理流水线，把搜索计划生成、实体链接、clue-query 构造、图遍历、相关三元组过滤、答案生成、计划增强等环节系统化组合；(2) 在六个公开基准（Natural Questions、TriviaQA、HotpotQA、2WikiMultihopQA、MuSiQue、DiaASQ）上 LLM-as-a-Judge 平均相对提升 4%；(3) 在 MINE-1 知识图谱构建基准上取得 89% 的事实保留率，超越 gpt4.1-mini 驱动的 Wikontic 86%。
与已有工作不同的是，本文的独特切入角度是把"搜索计划"提升为一等公民：区别于传统 GraphRAG 在固定本体内做节点级检索，PAI-2 由 LLM 显式生成自然语言搜索步骤序列，每一步抽取命名实体、链接到图节点后，再生成多条 clue-query 引导并行图遍历，并基于中间结果动态增强后续计划（plan enhancement）。这种「LLM 规划 + 图遍历 + 计划反思」三件套的紧耦合，区别于 HippoRAG 2 的 Personalized PageRank 单轮检索、LightRAG 的双层扁平检索、DoG 的多智能体辩论，是一种以中等规模 LLM 即可达成的轻量级动态检索框架。
核心方法
PAI-2 整体思路是「把 LLM 当作检索控制中枢，把 KG 当作可遍历的结构化外部记忆」。对每个用户问题，先在 Stage 1 进行去噪→增强→分解，将复杂问题切分为可独立回答的子问题；对每个子问题，在 Stage 2 让 LLM 生成自然语言搜索计划 $P=[s_1, s_2, \dots, s_M]$；进入循环后，对当前步骤 $s_j$ 抽取命名实体 $E_j$（Stage 3）、用密集+稀疏嵌入匹配到对象顶点（Stage 4），做线性组合并生成多条 clue-queries $CQ_j$（Stage 5），随后并行图遍历（Stage 6）、按嵌入相似度过滤（Stage 7）、生成单 clue 答案并汇总为 $s_{a_j}$（Stage 8-9），若不足则触发 SearchPlanEnhance 改写剩余计划（Stage 10），最后聚合所有子答案为最终输出（Stage 13）。所有 clue-queries 与子问题之间可并行执行。
PAI-2 与既有 GraphRAG 的本质区别在于三点：(1) 引入可迭代的搜索计划生成与增强机制，使 LLM 能根据中间检索结果动态修正后续检索路径，弥补传统 RAG「一次检索定胜负」的不足；(2) 提出「clue-query」概念——把抽象搜索步骤 $s_j$ 与具体对象顶点 $V$ 联合改写为可执行的多条自然语言子查询，并让图遍历从每条 clue-query 的起点顶点并行扩散，有效应对同一对象在图中以不同实体、不同子图重复出现带来的碎片化问题；(3) 把计划增强、图遍历算法选择（BS+NR/BS+WC）、顶点类型限制（排除 episodic）作为可调超参，形成一个层次化的检索策略空间，而非单一黑箱模型。
方法步骤详情
完整 13 阶段流水线操作如下。Stage 1 预处理：$q_d=\text{Denoise}(q)$ 经 Table 7 语法检查+Table 8 去噪；$q_e=\text{Enhance}(q)$ 经 Table 9-11 修正语法、替换术语、扩展语义；$\{q_1,\dots,q_N\}=\text{Decompose}(q_e)$ 由 Table 12 判定+Table 13 拆分；多阶段可并行执行。
技术新颖性
技术新颖性体现在三个层面。第一，把「计划生成+计划增强」引入 GraphRAG，使 PAI-2 的搜索策略成为可被 LLM 反思、修改的动态对象；论文用 18% LLM-as-a-Judge 平均提升（启用 vs 禁用 plan enhancement）量化这一贡献。第二，提出 clue-query 机制，把抽象查询与具体顶点进行语义绑定并并行多路遍历，有效缓解同一知识在 KG 中碎片化、图谱不连通导致的召回不全。第三，在 7-14B 小模型场景下做整体架构适配：通过 few-shot 在 HotpotQA 上选出 Qwen2.5 7B 作为统一 backbone，避免对超大模型的依赖；同时禁用 query preprocessing（作者认为其对准确率增益不够、prompt 需额外调优）以控制复杂度。整体上，这是首个把「动态规划+图遍历+计划反思」三机制紧耦合、且在 7B 级别 LLM 上跑出 6 个基准 SOTA 的 GraphRAG 框架。
实验结果
主要发现可总结为六点。**(1) 主基准（Table 3）**：Qwen2.5 7B 下 PAI-2 在 6 个基准上 LLM-as-a-Judge 均值 0.57，显著高于 LightRAG（0.16）、RAPTOR（0.42），与 HippoRAG 2（0.57）持平，在 TriviaQA/2WikiMultihopQA/MuSiQue 上分别领先 3/2/4 个百分点。**(2) 计划增强**：关闭 plan enhancement 后最佳 LLM-as-a-Judge 从 0.57 跌至 0.39（−18%），在 2WikiMultihopQA（0.58→0.28）与 DiaASQ（0.34→0.26）上损失最大。**(3) 图遍历 vs 扁平（Table 4）**：NaiveRetriever 配置下 PAI-2 均值 0.51，加入 BS+WC/BS+NR 后达 0.55（+6%），排除 episodic 顶点可缓解「Lost in the Middle」问题。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Natural Questions（开放域短答 QA） | LLM-as-a-Judge 准确率 | 0.69（PAI-2 最佳，BS+NR/all） | 0.80（HippoRAG 2） | -11%（绝对差距，作者归因于 NQ 小写命名实体识别困难与泛化问句容易触发 No Answer） |
| TriviaQA（开放域事实型 QA） | LLM-as-a-Judge 准确率 | 0.80（PAI-2 最佳，BS+NR/all） | 0.77（HippoRAG 2）、0.73（RAPTOR）、0.37（LightRAG） | +3% vs HippoRAG 2、+7% vs RAPTOR、+43% vs LightRAG |
| HotpotQA（多跳桥接 QA） | LLM-as-a-Judge 准确率 | 0.67（PAI-2 最佳，BS+WC/all） | 0.73（HippoRAG 2）、0.46（RAPTOR） | -6% vs HippoRAG 2，但 +21% vs RAPTOR；含 BS+NR 时 0.67 持平组合最佳 |
| 2WikiMultihopQA（多跳 QA） | LLM-as-a-Judge 准确率 | 0.58（PAI-2 最佳，BS+WC/E） | 0.56（HippoRAG 2）、0.27（RAPTOR）、0.11（LightRAG） | +2% vs HippoRAG 2、+31% vs RAPTOR、+47% vs LightRAG |
| MuSiQue（高难度多跳 QA） | LLM-as-a-Judge 准确率 | 0.33（PAI-2 最佳，BS+NR/all） | 0.29（HippoRAG 2）、0.22（RAPTOR）、0.01（LightRAG） | +4% vs HippoRAG 2、+11% vs RAPTOR、+32% vs LightRAG（六基准中最难） |
| DiaASQ（中文对话多跳 QA） | LLM-as-a-Judge 准确率 | 0.34（PAI-2 最佳，BS+WC/E） | 0.28（HippoRAG 2）、0.15（RAPTOR）、0.07（LightRAG） | +6% vs HippoRAG 2、+19% vs RAPTOR、+27% vs LightRAG |
| MINE-1 知识图谱事实保留率 | Information-Retention (%) | 89%（PAI-2 + Qwen2.5 7B） | 86%（Wikontic + gpt4.1-mini）、84%（Wikontic + gpt4o）、44%（GraphRAG + gpt4o）、39%（KGGen + Qwen2.5 14B） | SOTA，跨 LLM 范围最大领先 50 个百分点（vs GraphRAG），是 7-14B 量级最佳 |
局限与改进
作者在 §VIII 明确列出四点限制：(1) 隐式时间表示——把时间戳转成纯文本再喂给 LLM 容易触发「Lost in the Middle」效应，造成关键时间信息丢失；(2) 简化本体结构——缺乏丰富的索引/过滤字段，导致 QA 时检索效率与精度受限；(3) 实体定义模糊——对象顶点缺少规范化定义，对一词多义查询（如专有名词歧义）需要大范围遍历，容易召回不完整或误报；(4) 缺乏语义去重——当前去重仅用字符串精确匹配，同义三元组会冗余存储，增加存储开销并拖慢检索，特别是在剪枝过时边时容易出错。除作者承认的不足外，本文的独立观察还包括：MuSiQue 上的 LLM-as-a-Judge 仅 0.33 表明对真正高难度多跳问题提升仍有限；PAI-2 单问题平均延迟 1.51 分钟（Table 6）相对 PAI-1 的 1.0 分钟增加 50%，主要因多次迭代 LLM 推理与图遍历；Memory 构造耗时平均 46.25 小时/数据集、消耗 7.5M tokens，对中小团队成本仍然较高。
独立分析的弱点
独立分析三个弱点。**(1) 推理成本与延迟未充分解决**：Table 6 显示 PAI-2 在 DiaASQ 上单问题延迟 3.70 分钟，是 PAI-1 的 2.4 倍，因为 13 阶段流水线串行依赖多个 LLM 调用；改进方向包括对 Stage 2-10 中相似语义的提示做结果缓存（Table 27 已部分使用 Redis+MongoDB 缓存）、把多个 clue-query 调度改为单次 batch 推理、或对 7B 模型蒸馏/量化以换取 2-3 倍速度。**(2) 计划增强机制的稳定性**：在 2WikiMultihopQA 上 plan enhancement 关闭时 LLM-as-a-Judge 跌到 0.28，说明 SearchPlanEnhance 对某些子任务可能改写出比原计划更差的步骤；改进方向是加入计划版本回退（当增强后置信度下降时保留旧计划）或对增强提示加 self-consistency 多次采样投票。
未来方向
作者在 §IX 给出三条具体计划。**(1) Thesis Vertex Labeling**——为每个 thesis 顶点引入双标签：Episode 维度（FACT/OPINION/PREDICTION）刻画断言性质，Temporal 维度（STATIC/DYNAMIC/ATEMPORAL）刻画时效性，从而在遍历时按断言类型过滤。**(2) Time Interval Specification**——为 thesis 顶点显式记录 $t_{created}$、$t_{valid}$、$t_{expired}$、$t_{invalid}$、$t_{invalidated\_by}$，支持过期断言被新断言自动覆盖，实现知识生命周期管理。**(3) Fixed Predicate Fields**——为简单三元组谓词建立经审核、定期更新的术语表（glossary），并给对象顶点补充实体类型与简短描述，提升谓词语义稳定性。可延伸方向还包括与外部工具结合（网页检索、计算器）处理数值型多跳问题、记忆图抽象为多租户结构以支持千万级实体、部署为标准 RAG 后端并提供 OpenAI 兼容 API。
复现评估
复现评估整体偏中等。**(1) 开源情况**：论文未公开 GitHub 链接，但所有 prompt（Table 7-23）、检索超参（Appendix E：BeamSearch max_depth=5、WaterCircles hyper_num=15、NaiveRetriever max_k=50）、预处理脚本（Appendix D：NQ 2000 QA、TriviaQA 500 QA 等）均在附录中详尽给出，结合 Neo4j+Qdrant+OpenSearch+Redis+MongoDB 的全 Docker 部署（§IV.C）足以让工程团队复现。**(2) 算力门槛**：所有实验在单卡 NVIDIA TITAN RTX 24GB + Ollama 推理 7-14B LLM 完成，硬件消费级；但 6 数据集 × 15 配置 × 100 QA = 9000 次推理加 46.25 小时/数据集的图构建，总耗时仍达数天。**(3) 主要风险**：Qwen2.5 7B 作为 judge 与人工 r=0.88 而非 0.99，对小幅度差异需谨慎解读；不同 backbone 下结论可能波动。
论文图表
