← 返回 2026-04-24

PersonalAI: 个性化大语言模型代理中知识图谱存储与检索方法的系统对比研究 PersonalAI: A Systematic Comparison of Knowledge Graph Storage and Retrieval Approaches for Personalized LLM agents

Mikhail Menschikov, Dmitry Evseev, Victoria Dochkina, Ruslan Kostoev, Ilia Perepechkin, Petr Anokhin, Nikita Semenov, Evgeny Burnaev 📅 2026-04-12 👍 3 2026-07-13 08:36
GraphRAG LLM代理 个性化AI 知识图谱 长期记忆 问答系统

基于AriGraph架构提出混合知识图谱外部记忆框架,系统对比6种检索算法在3个QA基准上的表现。

前置知识

检索增强生成 (RAG)

RAG 通过将外部知识库的检索结果附加到 LLM 的 prompt 中来增强生成的事实准确性,通常使用稠密向量相似度检索原始文本片段,但其缺点是无结构、缺乏跨记忆的语义关系。

本文明确指出传统 RAG 是 unstructured,无法捕捉记忆之间的语义与时间关系,这是 PersonalAI 想克服的核心痛点。

知识图谱 (Knowledge Graph)

知识图谱是节点 (实体) 与边 (关系) 组成的有向结构,常表示为 $\mathcal{G} = (\mathcal{V}, \mathcal{E})$;PersonalAI 进一步扩展为支持超边的混合图,允许一条边连接多个顶点以表达一句话对应多个事实。

PersonalAI 的核心数据结构就是带超边的知识图谱,需要理解超边能连接多个节点,这是抓住论文 mixed graph design 的关键。

A* 图搜索算法

A* 通过评估函数 $f(n) = g(n) + h(n)$ 在图中寻找最短路径,其中 $g(n)$ 是起点到当前节点的实际代价,$h(n)$ 是当前到目标的启发式估计;在本文中三种启发式 (IP、WSP、AWSP) 对应不同的语义考量。

A* 是本文提出的 6 种检索算法之一,其 $h$-metric 的选择会显著影响跨数据集的检索精度。

Beam Search 与 BFS 遍历

BeamSearch 在每一步保留 top-N 候选路径以避免指数爆炸,BFS 按层次展开所有邻接节点;两者的组合是 WaterCircles (同源路径相交时合并) 和本文混合检索算法 (Mixed Algorithm) 的基础。

BeamSearch 是本文 7B/8B 模型最高效的检索策略,理解 Beam 与 BFS 的取舍才能看清论文里的算法差异。

LLM-as-a-Judge 评估

用一个大语言模型 (本文用 Qwen2.5 7B,seed=42, temperature=0) 作为评判器,根据问题、标准答案和模型答案给出 0/1 标签,因 BERTScore 等指标无法捕捉细微语义差别而采用此方法。

全部主表 (Table 2) 的准确率都基于 LLM-as-a-Judge,理解其判断逻辑才能正确解读本文的对比实验。

研究动机

现有 RAG 流水线以稠密向量相似度从原始文本片段中检索证据,本质上是 unstructured、不支持跨记忆语义关系,在用户长期、复杂的交互中难以扩展。论文通过对 HotpotQA、TriviaQA、DiaASQ 三个基准的实验发现,纯 RAG 流水线对 7B/8B 小模型在 HotpotQA 上 EM 仅 0.37 (Llama3.1 8B),而 GraphRAG 类方法在 HotpotQA 上 EM 也只到 45.9% (GCR),性能与可解释性都难以满足个性化场景需要。

本文的目标是本文提出一个灵活的、以知识图谱为外部记忆的 LLM agent 框架 PersonalAI,在 AriGraph 基础上引入对象顶点 (object)、论据顶点 (thesis) 与情节顶点 (episodic) 三类节点以及标准边 + 两类超边,目标是不微调 retriever/reader 的前提下让任何现成 LLM 都能直接获得稳定、可解释、可时间感知的长期记忆与问答能力,并系统给出 6 种检索算法在多模型、多基准下的最佳配置。

与已有工作不同的是,此前关于知识图谱 + LLM 的工作 (GraphReader、HippoRAG、KGP 等) 都各自选择一种检索方式,缺乏在统一框架内对 A*、BeamSearch、WaterCircles 等多种图遍历策略的系统对照;更关键的是,真实个性化场景需要处理时间戳与自相矛盾的事实,而 DiaASQ 等基准本身不包含这些结构。PersonalAI 通过对 DiaASQ 进行时间标注扩展,直接在 308 个 QA 配置 (5 LLM × 3 数据集 × 多限制) 上比较 6 种算法,正好填补这一系统空白。

核心方法

PersonalAI 沿 AriGraph 的思路,将 LLM 当作结构化抽取器,从弱结构化自然语言段落 $\mathcal{D}_i$ 自动构建一个语义+情节混合知识图谱 $\mathcal{G} = (\mathcal{V}_o, \mathcal{E}_o, \mathcal{V}_t, \mathcal{E}_t, \mathcal{V}_e, \mathcal{E}_e)$;问答阶段再用同一 LLM 抽取问题中的实体、映射到图节点并通过可插拔的图遍历算法收集与问题语义最相关的三元组子集,最后由 Conditional Answer Generator 生成自然语言答案。直觉上,这是用图代替段落作为记忆单元,从而让检索既能利用结构 (路径、节点类型) 又能利用语义 (embedding) 信息。

与 GraphRAG 标准做法只保留 (subject, relation, object) 三元组不同,PersonalAI 把同一段原文对应的多个论据顶点用超边 $\mathcal{E}_t$ 显式捆绑,并把整段原文建模为一个情节顶点 $\mathcal{V}_e$,再通过 $\mathcal{E}_e$ 把情节顶点链接到所有从中抽取出的语义顶点。这构成了一个可同时支持按实体跳跃 (object edge) 与按句子或段落整体回溯 (thesis/episodic hyper-edge) 的混合图,使后续检索既可像 GraphRAG 走三元组路径,也可像 BeamSearch 走 fragment 级别路径。

方法步骤详情

整个框架分两条流水线。 Memorize pipeline: (1) 用 Appendix A 的 prompt 让 LLM 从段落抽取论据与对象三元组; (2) 通过 BFS 匹配新旧顶点,再用 Appendix B 的 prompt 让 LLM 判断并去除已过时的事实; (3) 把结果写回 Neo4j (图) + Milvus (向量) + Redis/MongoDB (缓存),处理速度约 1.35 fragments/分钟,每片段 550-650 字符。 QA pipeline: 实体抽取 → 实体-顶点匹配 → 以匹配顶点为种子,通过 A* / WC / BS / 混合算法遍历混合图,得到候选三元组并按 embedding 相似度取 Top-N → Conditional Answer Generator 综合生成答复;遍历时通过 E/T/O 三类限制剥离不需要的顶点类型 (7B 模型排除 episodic 顶点可减少噪声)。每个算法的超参见 Appendix E,例如 BS max_depth=5、max_paths=10、final_sorting_mode=mixed。

技术新颖性

技术上,PersonalAI 的新颖性在三方面。第一,记忆表示的混合图 (hyper-edge enabled) 显式区分论据、对象与情节三种语义层级,而 AriGraph 原架构只支持 episodic + semantic 两层,论文通过 6 类表 (vertices/edges) 与 Figure 1 的图例展示了三色三类顶点的丰富结构。第二,在检索侧将 A* 启发式细化为 Inner Product、Weighted Shortest Path (BFS)、Averaged WSP 三种,并把 BeamSearch 灵感从 token 生成搬到 graph traversal,允许一条问题同时展开多条语义路径,这是较新颖的算法组合。第三,在实验设计上引入 LLM-as-a-Judge 在 308 个 (模型 × 数据集 × 算法 × 限制) 配置上做穷举式对照 (Table 2-6),这种规模下结论可直接指导实践的算法选择。

Example of a graph fragment, constructed from natural language text using our method, with object (green), thesis (yellow) and episodic (blue) vertices
Figure 1: Example of a graph fragment, constructed from natural language text using our method, with object (green), thesis (yellow) and episodic (blue) vertices
High level architecture of proposed Memorize pipeline for LLM-based triples extraction from unstructured texts on natural language and memory construction
Figure 2: High level architecture of proposed Memorize pipeline for LLM-based triples extraction from unstructured texts on natural language and memory construction
High level architecture of proposed QA pipeline for generating answers to the questions based on constructed memory graph
Figure 3: High level architecture of proposed QA pipeline for generating answers to the questions based on constructed memory graph

实验结果

实验在 TriviaQA、HotpotQA、DiaASQ 三个基准上比较 5 个 LLM × 6 种算法 × 3 类限制的 308 个 QA 配置,使用 LLM-as-a-Judge 作为主指标 (EM 作为补充)。核心发现: (1) 在 7B/8B 范围内,Qwen2.5 7B 平均得分最高 0.27,BeamSearch 配合 episodic 限制是最佳组合,例如 Qwen2.5 + BS/E 在 DiaASQ 拿到 0.22; (2) 在 DiaASQ 上 GPT-4o-mini 配合 BS+WC/E 表现最好 (0.50),DeepSeek V3 配合 BS+WC/O 拿到 0.47,差距不大,说明混合检索在大模型上更稳; (3) 在 HotpotQA 上 GPT-4o-mini + BS+WC/all 达到全表最高 0.77,而 Llama3.1 8B 也能拿到 0.47 (BS/O),显示多跳推理在更强模型上受益明显; (4) 在 TriviaQA 上 DeepSeek V3 + BS+WC/all 获得 0.87 全表最高,说明开放域事实问答适合混合算法+无限制组合; (5) 限制分析 (Table 3) 显示 7B/8B 模型 74% 的低质量配置禁用了 thesis 顶点,而 73% 的高质量配置反而禁用 episodic 顶点,大模型则相反 — 73% 高质量配置禁用 thesis 顶点,表明小模型需要 thesis 提供核心信号,大模型反而被长 episodic 噪声影响; (6) 稳定性分析 (Table 4) 显示 8B 模型 + A*+WC 在不同限制下性能波动仅 4%,而 BeamSearch 在亚优参数下波动可达 24%; (7) 延迟 (Table 6): WC 平均 0.30 分钟、 A* 3.24 分钟、 BS 6.59 分钟;切换至 Qdrant 后内存占用从 80-90 GB 降到 4-6 GB,可降至 1/6 检索时间。在 HotpotQA 上 PersonalAI 用 GPT-4o-mini + BS+WC/all 拿到 EM 60.0,比 GraphRAG 基线最高 (GCR 45.9) 高 14.1 个百分点,但比 fine-tuned RAG (如 Atlas 79.8) 仍低 17.8 个百分点;在 DiaASQ 上复现 HippoRAG 得到 0.53 LLM-as-Judge,本文最优配置 (DeepSeek V3 + BS+WC/O) 拿到 0.47,与 HippoRAG 大体可比。

Characteristics of prepared datasets for QA pipeline evaluation
Table 1: Characteristics of prepared datasets for QA pipeline evaluation
Best QA configurations ranked by the LLM-as-a-Judge metric across all experiments
Table 2: Best QA configurations ranked by the LLM-as-a-Judge metric across all experiments
Impact of various constraints imposed during memory graph traversal on the quality of the QA pipeline
Table 3: Impact of various constraints imposed during memory graph traversal on the quality of the QA pipeline
Stability of proposed retrieval algorithms when various restrictions are imposed
Table 4: Stability of proposed retrieval algorithms when various restrictions are imposed
The influence of selected retrieval algorithms and imposed search restrictions on the percentage of generated "NoAnswer" stubs
Table 5: The influence of selected retrieval algorithms and imposed search restrictions on the percentage of generated "NoAnswer" stubs
QA pipeline latency (in minutes) as a function of the LLM and retrieval algorithm, with the caching mechanism enabled
Table 6: QA pipeline latency (in minutes) as a function of the LLM and retrieval algorithm, with the caching mechanism enabled
Extended characteristics of datasets, used to evaluate proposed Memorize and QA pipelines
Table 13: Extended characteristics of datasets, used to evaluate proposed Memorize and QA pipelines
Characteristics of constructed memory graphs for QA experiments
Table 15: Characteristics of constructed memory graphs for QA experiments
Time and speed of memory graphs construction based on a given dataset and LLM
Table 18: Time and speed of memory graphs construction based on a given dataset and LLM
Best QA configurations ranked by the Exact Match metric across all experiments
Table 19: Best QA configurations ranked by the Exact Match metric across all experiments
Comparison of existing RAG and GraphRAG methods with our proposed method on the Exact Match metric
Table 20: Comparison of existing RAG and GraphRAG methods with our proposed method on the Exact Match metric
查看结构化数据
任务指标本文基线提升
TriviaQA (开放域事实问答) LLM-as-a-Judge accuracy / Exact Match 0.87 (LLM-as-Judge, DeepSeek V3 + BS+WC/all) / 0.62 (EM, 同配置) Atlas 79.8 / RePLUG 77.3 / GNN-RAG 等 GraphRAG 36.1-45.9 (EM) 在 DeepSeek V3 配置上 EM 62.0 显著高于 GraphRAG (最好 45.9) 14.1 个百分点,但与 fine-tuned RAG (Atlas 79.8) 差 17.8 个百分点
HotpotQA (多跳推理) LLM-as-a-Judge accuracy / Exact Match 0.77 (LLM-as-Judge, GPT-4o-mini + BS+WC/all) / 60.0 (EM, 同配置) GCR 45.9 / RoG 43.0 / ToG2.0 40.9 (EM); HippoRAG 60.2 (EM) 比 GraphRAG 最好基线 GCR 高约 14 个百分点;与 HippoRAG 基本持平,体现了我们的综合检索 + 多种超边的优势
DiaASQ (对话式情感四元组分析,加入时间标注与自相矛盾陈述) LLM-as-a-Judge accuracy 0.50 (GPT-4o-mini + BS+WC/E) / 0.47 (DeepSeek V3 + BS+WC/O) HippoRAG 复现 0.53; 未 fine-tuned RAG 在对话任务上公开数字极少 与 HippoRAG 可比,验证了 thesis/episodic 超边对时间依赖与对话结构的捕捉能力

局限与改进

作者明确指出几个限制:首先,memory construction 阶段平均速度仅 1.35 fragments/分钟,完整构建 HotpotQA 需 27-72 小时,TriviaQA 更要 80-90 小时,这意味着 LLM API 成本与时间是真实瓶颈;其次,DeepSeek V3 在响应解析上错误率高达 31.21%,导致一些上下文存储不全,需要更强的输出约束或 fine-tuned parser;第三,当前图遍历只能用启发式 (IP/WSP/AWSP) 等语义近似度量,无法覆盖多模态或符号逻辑推理。PersonalAI 不微调 reader/retriever 这一选择也带来与 fine-tuned RAG 的固定差距:在 TriviaQA 上 Atlas/RAG-Sequence 等专门微调的 reader 比本框架高 17.8 个百分点,虽然它们一旦换数据集性能会大幅下降,仍然是当前评估时不能回避的现实短板。

独立分析的弱点

独立来看,本文存在几个可改进的弱点。第一,308 个配置虽多但每配置仅评估 100 个 QA-pair (TriviaQA 仅 500 对),统计性可能不足,应考虑 bootstrap 或至少 3 seeds 报平均。第二,Memory graph 占用 80-90 GB (Milvus) 是真实工程瓶颈,论文虽提 Qdrant 可降至 4-6 GB,但所有数字仍是 Milvus 测得,真实部署需重跑全套。第三,对 E/T/O 三类限制的讨论止步于宏观分布 (Table 3),缺每个数据集-算法细粒度消融。第四,NoAnswer 机制 (Table 5) 显示 8B + BS+AS 限制 episodic 时 NoAnswer 高达 73%,提示答案可能并非真无答案而是检索失败,却无 fallback 策略。改进方向是把规则化 fallback (强制要求 LLM 用 embedding 找最相似句子) + 更细粒度消融表 + 多 seed 重复。

未来方向

作者提出的未来方向有三:加入 memory time 参数支持基于时间邻近度的三元组过滤;优化 Milvus/Qdrant/Weaviate 等向量存储与近似最近邻搜索;按 triple 类型分桶到多个小型专门化 vector store。我基于本文成果可延伸的方向:把 retrieval 阶段也用 RL 学习,自动选择 A*/BS/混合的混合权重;用 LLM-as-a-Judge 反向蒸馏成奖励,微调一个小而强的 retriever;以及引入 erasure-coded sharding (论文已提到文献 [20]) 把混合记忆图跨节点分片,适配生产级多用户记忆;对隐私敏感场景,可结合 PIR with result verification (文献 [21]) 提供端到端可审计的远程记忆访问。

复现评估

复现方面,论文给出了非常完整的细节:Neo4j + Milvus + Redis + MongoDB 全部跑在单台机器的 Docker 容器中,所有 LLMs 由本地 Ollama (Qwen2.5 7B、DeepSeek R1 7B、Llama3.1 8B) 或 API (GPT-4o-mini、DeepSeek V3) 提供,单张 NVIDIA TITAN RTX 24GB GPU,Embedding 使用 multilingual-e5-small,Appendix A-F 公开所有 LLM 提示词与超参 (BS max_depth=5、max_paths=10;WC hyper_num=15、episodic_num=15)。但作者没放出代码仓库,Memorize pipeline 处理 HotpotQA 完整语料需 27-72 小时,TriviaQA 80-90 小时,GPU 显存超 24GB 才能稳跑 DeepSeek V3 抽取,实际复现的时间和算力门槛都比较高。判断难度:中高 — 工程链路清晰但缺一键脚本。