HyperMem: Hypergraph Memory for Long-Term Conversations

论文阅读：HyperMem——用超图组织长期对话记忆

论文标题：HyperMem: Hypergraph Memory for Long-Term Conversations
作者：Juwei Yue, Chuanrui Hu, Jiawei Sheng, Zuyi Zhou, Wenyuan Zhang, Tingwen Liu, Li Guo, Yafeng Deng
发表位置：ACL 2026 Main Conference，Volume 1: Long Papers
arXiv 编号：2604.08256
原文链接：https://arxiv.org/abs/2604.08256
ACL Anthology：https://aclanthology.org/2026.acl-long.1627/
主题：LLM Agent Memory、Long-term Conversation、Hypergraph、Hierarchical Retrieval
核心问题：传统 RAG 和 Graph-based Memory 主要通过成对关系组织记忆，如何显式表示跨时间、跨 Episode 的多元素高阶关联，并据此进行完整而高效的长期记忆检索？

1. 问题：长期记忆为什么还需要新的结构？

长期对话 Agent 面临的一个基本问题是：随着对话持续数周甚至数月，完整历史不可能一直保留在模型上下文窗口中，因此需要把历史信息保存为外部 Memory，并在之后按需取回。

传统方案大致可以分为两类。

第一类是普通 RAG。它将历史对话切成若干 Chunk，然后根据当前 Query 与 Chunk 的相似度取回若干片段。

第二类是 Graph-based RAG / Graph Memory。它进一步抽取实体和关系，通过图结构保存：

Alice -- signed_up --> Marathon
Bob   -- works_on  --> Project

这比完全独立的 Chunk 更结构化，但论文认为，两种方法仍然存在一个共同问题：

它们主要围绕 pairwise relation（成对关系）进行组织，而真实长期对话中的很多记忆实际上是多个元素共同形成的 high-order association（高阶关联）。

论文用一个持续数月的对话作为例子：

3 月：
Alice 报名参加马拉松。

3 月：
Bob 的项目快到 deadline，需要加班。

5 月：
Alice 已经可以跑 15km。

5 月：
Bob 项目上线，两人一起跑步庆祝，
Alice 又提到跑步可以缓解压力。

这里并不是只有一条简单的二元关系。

例如 Alice 的「马拉松训练」这一主题同时涉及：

  • 报名马拉松；
  • 后续训练；
  • 跑步能力提升；
  • 与之后跑步活动相关的事实。

这些 Episode 在时间上可能相隔数月，但在语义上属于同一个持续发展的主题。

如果只把历史保存成独立 Chunk，很容易只取回来其中一个片段。

即使构建普通图，论文认为多个 Episode 之间的这种「共同属于同一段长期叙事」的关系仍然没有被显式作为一个整体建模。

HyperMem 因此引入了 Hypergraph（超图）。

image

【Figure 1。该图对比 Chunk-based RAG、Graph-based RAG 与 HyperMem 的记忆结构，重点观察 HyperMem 如何利用一个 Hyperedge 将多个属于同一 Topic 的 Episode 作为整体关联起来。】

2. 为什么是 Hypergraph？

普通 Graph 中，一条 Edge 通常连接两个节点：

A ----- B

如果三个节点互相关联，通常需要拆成若干二元 Edge：

A ----- B
|       |
+-------C

Hypergraph 则允许一条 Hyperedge（超边） 同时连接多个节点：

Hyperedge E = {A, B, C, D}

因此，在 HyperMem 中：

一条超边可以直接表示「这一组 Memory 共同属于某个语义单元」。

论文关注的并不是单纯把 Graph 换成 Hypergraph，而是利用这种结构建立一个三层长期记忆：

Topic
  ↓
Episode
  ↓
Fact

其中：

层级 含义 主要作用
Topic 长时间跨度上的共同主题 将时间上分散但语义上连续的 Episode 聚合起来
Episode 时间上连续的一段事件或子对话 保存事件级语境和时间信息
Fact Episode 中抽取出的原子事实 作为最终精确检索目标

这里最关键的是：

Topic 并不是简单的对话标签，而是跨时间组织 Episode 的语义锚点。

例如：

Topic: Alice's marathon training

Episode 1:
Alice signs up for marathon

Episode 2:
Alice can now run 15km

Episode 3:
Project launches; they run together

这些 Episode 可以出现在不同日期。

HyperMem 使用 Episode Hyperedge 将属于同一个 Topic 的多个 Episode 组织成一个整体。

另一方面，一个 Episode 内部又可能包含多个 Fact，因此使用另一层 Fact Hyperedge 将它们组织起来。

于是形成：

Topic
  |
  | Episode Hyperedge
  |
  +---- Episode A
  +---- Episode B
  +---- Episode C
             |
             | Fact Hyperedge
             |
             +---- Fact 1
             +---- Fact 2
             +---- Fact 3

论文的重点就在于：

把长期对话中的「主题连续性」「事件上下文」和「原子事实」分别保存在不同粒度上，同时利用 Hyperedge 显式保存多个 Memory 元素之间的整体关联。

3. HyperMem 整体框架

HyperMem 可以分成两个阶段：

Memory Construction / Indexing
        ↓
Memory Retrieval

Memory Construction 又包含：

Raw Conversation
      ↓
Episode Detection
      ↓
Topic Aggregation
      ↓
Fact Extraction
      ↓
Hypergraph Memory
      ↓
Lexical + Semantic Index

用户提出 Query 后，则沿相反方向进行 coarse-to-fine retrieval（粗到细检索）：

Query
  ↓
Topic Retrieval
  ↓
Episode Retrieval
  ↓
Fact Retrieval
  ↓
Response Generation

image

【Figure 2。该图是 HyperMem 的核心框架图，上半部分展示 Episode Detection、Topic Aggregation、Fact Extraction 和 Hypergraph Memory 构建过程，下半部分展示从 Topic → Episode → Fact 的三级检索过程。】

下面按照论文的顺序分别介绍这些组件。

4. Hypergraph Memory Structure

HyperMem 将 Memory 表示成由三类节点组成的 Hypergraph：

V_T = Topic Nodes
V_E = Episode Nodes
V_F = Fact Nodes

以及两类 Hyperedge：

E_E = Episode Hyperedges
E_F = Fact Hyperedges

整体结构可以写成：

H = (
    V_T union V_E union V_F,
    E_E union E_F
)

其中：

  • E_E 负责组织属于同一个 Topic 的 Episode；
  • E_F 负责组织属于同一个 Episode 的 Fact。

Hyperedge 中的节点还拥有一个 [0, 1] 范围的 importance weight（重要性权重），表示某个 Episode 或 Fact 对对应主题或事件的重要程度。

因此 HyperMem 不只是保存「谁和谁相连」，还保存：

这一组节点为什么被组织到一起
+
每个节点在该关联中的重要程度

5. Hypergraph Memory Construction

Hypergraph 的构建分成三个阶段：

  1. Episode Detection
  2. Topic Aggregation
  3. Fact Extraction

而且这些步骤并不是简单规则系统，其中多个关键判断由 LLM 完成。

5.1 Episode Detection：先把连续对话切成事件

长期对话通常不会一直围绕一个主题进行。

例如：

聊马拉松
→ 聊工作
→ 几周后继续聊马拉松
→ 聊项目

如果直接把大量消息作为一个整体 Memory 保存，会使多个事件互相混杂。

因此 HyperMem 首先定义 Episode（情节 / 事件片段）。

Episode 是：

时间上相对连续，并且语义上构成一个完整事件的一组对话。

流式边界检测

系统维护一个历史 Buffer。

每当新的对话到达时：

new dialogue
     ↓
append to buffer
     ↓
LLM boundary detector

LLM 会根据三个主要信号判断当前事件是否已经结束：

  1. 当前 Buffer 是否已经形成语义完整的事件；
  2. 连续对话之间是否存在明显的时间间隔；
  3. 是否出现主题切换或事件结束的语言信号。

模型输出两个核心信号：

should_end
should_wait

如果：

should_end = True

系统就把当前 Buffer 固化为一个 Episode，然后清空 Buffer，继续处理之后的对话。

一个 Episode 保存三部分信息：

Episode = {
    dialogue,
    title,
    episode_summary
}

其中：

  • dialogue：原始对话；
  • title：简洁主题；
  • episode_summary：该事件的简短叙事摘要。

因此 Episode 同时保留：

原始证据 + 事件级语义摘要。

这也是之后 Temporal Reasoning 能够利用的一个重要层级。

6. Topic Aggregation：把跨时间 Episode 再聚合起来

只划分 Episode 仍然没有解决长期记忆问题。

原因是同一件事情可能持续数月：

3 月：报名马拉松
        ↓
4 月：训练
        ↓
5 月：能够跑 15km
        ↓
6 月：完成比赛

它们在时间上被切成多个 Episode，但实际上属于同一个持续发展的 Narrative。

因此 HyperMem 在 Episode 之上进一步建立 Topic Node。

6.1 Streaming Topic Aggregation

当新的 Episode E_cur 到来后，系统首先利用之后会介绍的 lexical + semantic retrieval，从历史 Episode 中找到相似候选：

E_cur
  ↓
retrieve similar historical Episodes
  ↓
C_E

然后由 LLM 判断当前 Episode 和已有 Episode / Topic 之间的关系。

论文将结果分成三种情况。

Case 1：Topic Initialization

如果没有找到相关历史 Episode：

C_E = empty

说明这是一个新的长期主题。

系统创建新的 Topic：

Topic = {
    title,
    summary
}

Case 2：Topic Creation

系统虽然找到一些语义相似 Episode，但 LLM 判断当前 Episode 实际上不属于它们现有的 Topic。

此时仍然创建新的 Topic。

这是为了避免：

语义看起来相似
≠
属于同一个持续事件

论文在 Prompt 中明确要求 Topic Matching 不只是判断宽泛主题是否相似，还会考虑：

  • 是否属于同一个具体事件或主题；
  • 是否存在 Narrative Continuity（叙事连续性）；
  • 核心人物 / 项目 / 关系是否一致；
  • 即使时间跨度数周甚至数月，是否仍属于同一事件的发展过程。

Case 3：Topic Update

如果新 Episode 与已有 Topic 匹配：

E_cur → existing Topic

则把 Episode 加入已有 Topic，并重新生成 Topic 的 metadata。

也就是说 Topic 不是建立之后永久不变，而是随着新的对话不断更新。

6.2 Episode Hyperedge

确定 Topic 后，系统构建 Episode Hyperedge，将该 Topic 下的一组 Episode 联合组织起来。

例如：

Topic:
Alice's marathon training

Hyperedge:
{
    Alice signs up for marathon,
    Alice can run 15km,
    Alice continues training,
    ...
}

同时 LLM 为每个 Episode 分配一个 [0,1] 的权重：

w_episode

表示这个 Episode 对该 Topic 的贡献程度。

因此 Topic 最终成为一个跨越时间的 semantic anchor（语义锚点）。

这使得后续系统不必从所有历史对话中独立搜索每一个 Episode，而可以先定位：

这个问题属于哪个长期主题？

然后再进入该主题内部检索。

7. Fact Extraction：从事件级记忆进一步提取原子事实

Episode 虽然比原始长对话简洁，但仍然包含大量 Narrative Context。

例如一个 Episode 可能是：

Bob 的项目正式上线。
Alice 提议一起跑步庆祝。
Bob 表示跑步确实能缓解工作压力。

用户真正的问题可能只是：

Bob 下班后通过什么方式缓解压力？

系统并不需要把整个 Episode 都作为最终证据。

因此 HyperMem 又提取一层 Fact Node。

例如：

Fact:
Running helps Bob relieve stress.

7.1 Fact 并不只有一句事实

HyperMem 的 Fact Node 包含：

Fact = {
    content,
    potential,
    keywords
}

三个字段各自承担不同作用。

content

真正的事实：

Bob uses running to relieve stress.

potential

这个 Fact 可能回答哪些类型的问题。

例如可以理解成：

What does Bob do to relieve stress?
How does Bob relax after work?

论文将这一字段称为对潜在 Query 的 anticipation（预判）。

也就是说作者不是单纯让 Embedding 模型之后再猜：

Query 和 Fact 是否相关？

而是在构造 Memory 时就让 LLM 预测：

这个事实未来可能回答什么问题？

从而让 Query 与 Memory 的表示更加容易对齐。

keywords

保存代表性关键词，用于之后的 lexical retrieval：

Bob
running
stress
work

7.2 利用 Topic 上下文抽取 Fact

一个值得注意的细节是，Fact 并不是完全孤立地从单个 Episode 中抽取。

论文的 Fact Extraction 会给 LLM：

Topic
+
Episodes in this Topic

让模型在完整 Topic 上下文下提取 Fact。

这样做主要是为了减少：

  • 重复事实；
  • 无意义的细节；
  • 缺乏上下文的事实。

同时，每个 Fact 都保留到原始 Episode 的 provenance（来源关系），保证之后仍然可以找到对应事件语境。

最后，对一个 Episode 中涉及的多个 Fact，再构造 Fact Hyperedge：

Episode
   ↓
Fact Hyperedge
   ├── Fact 1
   ├── Fact 2
   └── Fact 3

每个 Fact 同样拥有 [0,1] 的重要性权重。

至此，一个原始长期对话已经被重组为：

Topic
  ↓
Episodes
  ↓
Facts

而不是一组相互独立的文本 Chunk。

8. Hypergraph Memory Retrieval

Memory 建好后，HyperMem 并不是直接在所有 Fact 上进行一次 Vector Search。

论文设计的是：

Topic → Episode → Fact 的 coarse-to-fine retrieval。

在执行在线检索之前，系统首先建立索引。

8.1 Hybrid Lexical-Semantic Index

论文同时使用两类检索信号。

Sparse lexical retrieval

采用：

BM25

利用关键词进行精确匹配。

Dense semantic retrieval

采用：

Qwen3-Embedding-4B

将节点编码成 Dense Embedding，通过语义相似度进行检索。

而且 Topic、Episode、Fact 三种节点都会分别建立这两种索引。

因此系统同时利用：

Lexical signal
+
Semantic signal

作者认为这样能够兼顾：

  • 精确关键词；
  • 更抽象的语义意图。

9. Hypergraph Embedding Propagation

这里还有 HyperMem 中比较重要的一个设计。

如果两个 Episode 属于同一个 Hyperedge：

Episode A ─┐
Episode B ─┼─ Topic Hyperedge
Episode C ─┘

它们不仅在图结构上相关，其 Embedding 也应该反映这种共同的主题上下文。

因此论文设计了一个轻量级的 Hypergraph Embedding Propagation（超图嵌入传播）。

基本过程分两步。

首先，根据 Hyperedge 内节点的原始 Embedding 和重要性权重，计算 Hyperedge Embedding：

hyperedge_embedding
    =
weighted aggregation(
    node embeddings in this hyperedge
)

节点权重首先经过类似 softmax 的归一化，因此更重要的 Episode / Fact 对 Hyperedge 表示贡献更大。

然后再把与节点相连的 Hyperedge 信息传播回节点：

new_node_embedding
    =
original_node_embedding
    +
lambda * aggregate(incident_hyperedge_embeddings)

其中 lambda 控制结构信息传播的强度。

论文实验中使用的传播权重为：

lambda = 0.5

这样，即使两个 Memory：

  • 在文本表面表达上不同；
  • 在时间上相隔很远；

只要它们属于同一个 Hyperedge，就能够通过结构传播获得更接近的语义表示。

论文特别强调，这个设计受到 Hypergraph Neural Network 的启发，但并不需要进行大规模模型训练或 Fine-tuning，而只是一个轻量的 Embedding 更新过程。

10. Online Retrieval：Topic → Episode → Fact

建立索引之后，用户提出 Query：

q

系统执行三级检索。

10.1 Stage 1：Topic Retrieval

首先在所有 Topic 中检索。

对 Query 分别进行：

BM25 Retrieval
+
Dense Vector Retrieval

然后使用 RRF（Reciprocal Rank Fusion，倒数排名融合） 合并两个 Ranking。

基本思想可以写成：

RRF_score(document)
    =
sum(
    1 / (k + rank_from_each_retriever)
)

随后，再利用：

Qwen3-Reranker-4B

对候选结果进行更精细的 Query-Document Relevance Ranking。

最后保留：

Top-k Topics

论文实验配置为：

Top-10 Topics

第一层的作用相当于先回答：

当前 Query 大概率在问长期历史中的哪些主题？

大量无关 Memory 会在这一阶段被提前过滤。

10.2 Stage 2：Episode Retrieval

对于选中的 Topic，通过对应 Episode Hyperedge 展开：

Topic
 ↓
Candidate Episodes

然后再次执行：

BM25
+
Dense Retrieval
+
RRF
+
Reranker

保留相关 Episode。

实验中：

Top-10 Episodes

这一层的作用是：

在已经确定的主题内部，找出与当前问题真正相关的具体时间段和事件。

10.3 Stage 3：Fact Retrieval

之后从保留下来的 Episode 通过 Fact Hyperedge 展开到 Fact：

Episode
 ↓
Candidate Facts

继续执行同样的：

RRF
+
Reranker

最后选择：

Top-30 Facts

作为最终细粒度 Memory。

因此整个检索路径是：

All Memories
     ↓
Top-10 Topics
     ↓
Relevant Episodes
     ↓
Top-10 Episodes
     ↓
Relevant Facts
     ↓
Top-30 Facts

相比直接在全部 Fact 中搜索，Topic 和 Episode 实际上承担了逐层缩小 Search Space 的作用。

11. 最终 Response Context 怎么构造？

HyperMem 最终并不会重新把所有原始对话放回 Context。

系统主要使用：

Retrieved Fact.content

作为回答证据。

除此之外，还可以加入对应 Episode 的：

Episode.summary

作为 Narrative Context。

最终 Context 因此可以理解成：

Relevant Episode Summaries
+
Relevant Atomic Facts

论文认为这种方式可以在减少 Token 消耗的同时，又避免只使用孤立 Fact 导致上下文不足。

这一点也在后续 Ablation 中表现得非常明显：

Episode Context 对整体性能实际上非常重要。

12. 一个完整例子

论文 Figure 2 给出了一个 Query：

What did Bob do to relieve stress after work?

HyperMem 首先检索 Topic：

Bob's work and project

然后进入这个 Topic，对 Episode 进行检索：

Project launches;
they run together.

再从 Episode 中定位 Fact：

Running helps relieve stress.

最终组合出的 Memory Context 类似：

Relevant Episode:
Project launches; they run together.

Relevant Fact:
Running helps relieve stress.

Agent 最终回答：

Running.

这个例子体现了整个 HyperMem 的基本思想：

Query
 ↓
先确定长期主题
 ↓
找到对应事件
 ↓
定位具体事实
 ↓
回答

而不是：

Query
 ↓
直接与所有历史文本做一次相似度匹配

13. 实验设置

论文主要在 LoCoMo 长期对话记忆 Benchmark 上进行实验。

LoCoMo 包含持续数月的 Multi-session Conversation，并将问题划分为四类：

类型 含义
Single-hop 直接从某个事实中找到答案
Multi-hop 需要组合多个历史对话中的证据
Temporal 需要根据时间关系进行推理
Open Domain 需要更宽泛的语境甚至外部知识

13.1 Baseline

作者将 Baseline 分成两大类。

RAG 系统

包括：

  • GraphRAG
  • LightRAG
  • HippoRAG 2
  • HyperGraphRAG

其中 HyperGraphRAG 同样使用 Hypergraph，因此是一个值得注意的 Baseline。

论文对两者的区分是：

HyperGraphRAG 等已有 Hypergraph RAG 工作主要面向 静态知识库 / 固定 Corpus；

而 HyperMem 研究的是：

不断随对话增长和更新的 Agent Memory

并专门设计：

Episode Detection
+
Streaming Topic Aggregation
+
Fact Extraction
+
Hierarchical Retrieval

来处理长期对话 Memory。

Memory System

还比较了：

  • OpenAI Memory
  • LangMem
  • Zep
  • A-Mem
  • Mem0
  • MemGraph
  • MIRIX
  • Memobase
  • MemU
  • MemOS

因此实验同时覆盖了传统 RAG / Graph RAG 和专门的 Agent Memory System。

13.2 模型配置

HyperMem 的主要组件配置为：

组件 模型 / 设置
Semantic Embedding Qwen3-Embedding-4B
Reranker Qwen3-Reranker-4B
Answer Generation GPT-4.1-mini
Generation Prompt Chain-of-Thought
LLM Judge GPT-4o-mini
Initial Candidates 100
Topic Top-k 10
Episode Top-k 10
Fact Top-k 30
Hypergraph propagation weight 0.5
Evaluation 3 次独立运行取平均

需要注意，这篇论文的主要指标是：

GPT-4o-mini 给出的 LLM-as-a-judge Accuracy。

并不是传统的 Exact Match。

论文 Table 1 还说明：

  • RAG Baseline 主要使用各自官方实现进行复现；
  • Memory System 的部分结果来自已有论文或系统报告。

14. 主要实验结果

论文 Table 1 的结果如下。

Method Single-hop Multi-hop Temporal Open Domain Overall
GraphRAG 79.55 54.96 50.16 58.33 67.60
LightRAG 86.68 84.04 60.75 71.88 79.87
HippoRAG 2 86.44 75.89 78.50 66.67 81.62
HyperGraphRAG 90.61 80.85 85.36 70.83 86.49
OpenAI Memory 63.79 42.92 21.71 62.29 52.90
LangMem 62.23 47.92 23.43 71.12 58.10
Zep 61.70 41.35 49.31 76.60 65.99
A-Mem 39.79 18.85 49.91 54.05 48.38
Mem0 67.13 51.15 55.51 72.93 66.88
MemGraph 65.71 47.19 58.13 75.71 68.44
MIRIX 85.11 83.70 88.39 65.62 85.38
Memobase 73.12 64.65 81.20 53.12 72.01
MemU 66.34 63.12 27.10 50.01 56.55
MemOS 81.09 67.49 75.18 55.90 75.80
HyperMem 96.08 93.62 89.72 70.83 92.73

HyperMem 的 Overall Accuracy 达到：

92.73%

论文将其与两个主要对手进行比较。

最强 RAG 方法 HyperGraphRAG：

86.49%

HyperMem 高：

+6.24 percentage points

Memory System 中表现最高的 MIRIX：

85.38%

HyperMem 高：

+7.35 percentage points

15. 不同问题类型上发生了什么？

15.1 Single-hop

HyperMem：

96.08%

HyperGraphRAG：

90.61%

作者认为 Fact Layer 能够提供非常明确的 Atomic Information，因此对于直接事实检索尤其有效。

15.2 Multi-hop

HyperMem：

93.62%

这一类别尤其符合 Hypergraph 的设计目标。

Multi-hop 问题往往需要：

Episode A
+
Episode B
+
Episode C

共同回答一个问题。

如果这些 Episode 相隔数个月，单独 Chunk Retrieval 很容易漏掉其中部分证据。

HyperMem 则通过 Topic Hyperedge 将它们组织到一起，因此更容易完成完整的 Evidence Aggregation。

15.3 Temporal

HyperMem：

89.72%

Temporal Question 需要知道：

什么时候发生了什么
+
事件之后如何变化

作者认为 Episode Layer 保留了事件级 Context 与 Temporal Anchor，而 Topic Layer 又能够把不同时间点的相关 Episode 组织起来，因此更适合追踪事件演变。

15.4 Open Domain

HyperMem：

70.83%

这一项并没有明显领先，甚至低于一些 Memory Baseline。

论文解释，Open Domain Question 往往需要：

conversation history
+
external world knowledge

而 HyperMem 主要管理对话内部的 Memory，并没有引入外部知识源。

因此 Open Domain 仍然是其主要困难之一。

16. Ablation Study：真正重要的是哪一层？

论文进行了一系列 Ablation。

缩写含义为：

FC = Fact Context
EC = Episode Context
TR = Topic Retrieval
ER = Episode Retrieval

Overall 结果如下：

Configuration Overall Drop
HyperMem 92.66 -
w/o FC 91.75 -0.91
w/o EC 88.90 -3.76
w/o TR 91.94 -0.72
w/o TR & FC 91.75 -0.91
w/o TR & EC 88.83 -3.83
w/o TR & ER 90.19 -2.47

这里最明显的结果是：

Episode Context 是整个系统中影响最大的组件之一。

删除 Episode Context 后：

92.66
→
88.90

下降：

3.76 points

在 Temporal Question 上下降更加明显：

-5.61 points

这说明 HyperMem 并不能简单理解成：

最终有 Fact 就够了。

Fact 虽然精确，但是过于原子化。

Episode Summary 提供的事件级 Narrative Context 对：

  • 时间关系；
  • 多条事实之间的联系；
  • 事件状态；

仍然非常重要。

16.1 把层次结构完全压平会怎样？

如果绕过：

Topic Retrieval
+
Episode Retrieval

直接进行 Fact-only Retrieval，也就是：

w/o TR & ER

Overall 会降到：

90.19%

Multi-hop 更是下降：

-5.68 points

论文据此认为，三级结构并不只是为了存储时看起来更整齐。

真正有用的是：

Topic
  ↓
Episode
  ↓
Fact

这个 Retrieval Path 本身。

它维持了不同粒度 Memory 之间的语义连续性。

17. Hyperparameter Analysis

论文还分析了各层 Top-k 对结果的影响。

Topic Top-k

Topic 是最敏感的参数。

从：

Top-1

增加到：

Top-10

Accuracy 从：

76.88%

提高到：

92.66%

提升：

+15.78 points

说明如果最开始 Topic Recall 不够，相关 Narrative 会直接在第一层被剪掉，后面的 Episode 和 Fact 再精确也无法恢复。

Episode Top-k

Episode Top-k 相对不敏感：

k = 10 : 92.73%
k = 20 : 92.47%

说明当正确 Topic 已经找到之后，系统对 Episode 候选数量具有一定鲁棒性。

Fact Top-k

Fact Retrieval 在：

k = 30

附近表现最好。

继续增加 Fact 数量反而略微下降。

论文认为这意味着过度检索 Fact 会向最终 Context 引入噪声。

因此：

更多 Memory
≠
更好回答

关键仍然是获取足够但相关的证据。

18. Episode Context 能不能用更多 Fact 替代？

论文在不同参数配置下比较：

Fact Only

与：

Episode + Fact

结果显示，Episode + Fact 基本持续高出：

3% ~ 4%

这进一步说明：

Episode 提供的 Narrative Context 并不能通过单纯检索更多 Fact 来补偿。

换句话说，三层 Memory 并不是简单的信息冗余，而是承担不同粒度的职责：

Topic
负责长时间跨度的主题组织

Episode
负责事件与时间上下文

Fact
负责精确回答

19. Token Efficiency

HyperMem 还分析了 Accuracy 和 Token Usage 之间的关系。

论文以 Mem0 的 Token 使用量作为：

1.0x

基准。

部分结果为：

Method / Configuration Relative Token Usage Accuracy
Mem0 1.0x 66.88
HippoRAG 2 2.2x 81.62
HyperGraphRAG 26.3x 86.49
GraphRAG 35.3x 67.60
HyperMem Fact Only 2.5x 89.48
HyperMem Episode + Fact 7.5x 92.73

完整的 Episode + Fact 配置使用：

7.5x

Token，达到：

92.73%

而 Fact Only 在：

2.5x

Token 下已经能达到：

89.48%

相比之下 HyperGraphRAG 使用：

26.3x

Token，Accuracy 为：

86.49%

论文据此认为 coarse-to-fine Retrieval 可以提前排除大量无关信息，从而避免将大量 Graph / Chunk 内容直接输入生成模型。

20. Appendix 中的几个 Case Study

论文还通过 LoCoMo 中的实际问题说明不同层级分别在做什么。

Multi-hop：跨 10 个月统计比赛结果

问题要求回答某个人一共赢过多少次 Tournament。

相关证据分布在：

7 个 Session
+
10 个月时间跨度

GraphRAG 只找到部分证据，因此回答「至少两次」。

HyperMem 则利用 Topic Hyperedge 将所有与 Tournament 相关的 Episode 聚合起来，最终找到：

7 tournaments

这里主要体现的是：

Topic
+
Hyperedge

解决跨时间 Evidence Aggregation 的作用。

Temporal：某个时间点之前拥有多少宠物？

另一个问题询问：

截至 2023 年 9 月，Andrew 有多少宠物？

这类问题不能简单统计所有出现过的 Pet Fact，而需要重建：

截至指定时间点的状态

论文案例中：

  • GraphRAG 混淆了人物；
  • HyperGraphRAG 将不同时间的信息一起计算，得到 4 只；
  • HyperMem 得到当时只有一只名为 Toby 的狗。

作者将这一能力主要归因于 Episode Layer 对 Temporal Anchor 和事件演变过程的保留。

21. HyperMem 的方法可以怎样概括？

按照论文自己的设计逻辑，HyperMem 实际上解决了三个连续的问题。

第一层：原始 Conversation 太长

解决方式：

Conversation
→
Episode

把连续历史分割成语义完整的事件。

第二层：同一件事可能跨很多 Episode

解决方式：

Episodes
→
Topic Hyperedge

将时间上分散但语义上连续的事件重新组织起来。

第三层：Episode 对直接问答仍然太粗

解决方式：

Episode
→
Facts

抽取直接可回答 Query 的原子证据。

最终得到：

Long Conversation

      ↓ Episode Detection

Episode    Episode    Episode
   \          |          /
    \         |         /
       Topic Hyperedge

              ↓

       Fact Extraction

              ↓

Fact    Fact    Fact    Fact

              ↓

Topic → Episode → Fact Retrieval

因此 HyperMem 的核心并不只是「使用 Hypergraph」。

更完整地说，是：

使用 Hypergraph 将 Topic、Episode 和 Fact 三种不同粒度的 Memory 组织成高阶关联结构，再利用这一结构进行从 Topic 到 Episode 再到 Fact 的分层检索。

22. 论文指出的局限性

论文明确给出了两个主要限制。

22.1 当前只考虑 Single-user Memory

HyperMem 当前默认：

一个用户
+
一个 Memory Space

如果扩展到：

Multi-user

或者：

Multi-agent

会出现新的问题：

  • Memory Isolation；
  • Access Control；
  • 不同用户之间的权限；
  • 不同 Agent 可以访问哪些 Memory。

当前 Hypergraph 结构并没有解决这些问题。

22.2 Open Domain Question 仍然困难

HyperMem 管理的是：

Conversation History

但有些问题需要 Conversation 中根本不存在的外部知识。

例如：

User Memory
+
World Knowledge

才能完成回答。

因此仅优化内部长期 Memory 无法解决这部分问题。

论文将：

External Knowledge Base Integration

作为之后可能扩展的方向。

23. 总结

HyperMem 关注长期对话 Memory 中一个很具体的问题：

多个相关事件可能分布在数周甚至数月的不同对话中，仅依赖独立 Chunk 或 Pairwise Relation 容易产生 Fragmented Retrieval。

为此，论文提出三层 Memory：

Topic
Episode
Fact

首先使用 LLM 对流式 Conversation 进行 Episode Detection：

Conversation
→
Episode

然后通过 Topic Aggregation 将时间上分散、但属于同一持续事件的 Episode 聚合起来：

Episode A
Episode B
Episode C
   ↓
Topic Hyperedge

再从 Topic 下的 Episode 中抽取带有：

content
potential
keywords

的 Atomic Fact。

在索引阶段，HyperMem 同时结合：

BM25
+
Dense Embedding
+
Hypergraph Embedding Propagation

在查询阶段，则采用：

Topic Retrieval
      ↓
Episode Retrieval
      ↓
Fact Retrieval

的 coarse-to-fine 策略，并通过 RRF 与 Reranker 对候选进行排序。

在 LoCoMo 上，论文报告：

Overall LLM-as-a-judge Accuracy
= 92.73%

相比：

HyperGraphRAG : 86.49%
MIRIX         : 85.38%

均取得更高结果。

Ablation 进一步表明，HyperMem 中并不是 Fact 越精细就越可以抛弃上层结构：

Topic    → 长期主题与跨时间关联
Episode  → 事件、时间与 Narrative Context
Fact     → 精确回答证据

三种粒度承担不同职责。

尤其是移除 Episode Context 会造成最大的整体性能下降之一，而完全跳过 Topic 和 Episode、直接进行 Fact Retrieval，也会明显损害 Multi-hop Reasoning。

因此，这篇论文最终建立的是一种：

以 Hypergraph 为组织结构、以 Topic / Episode / Fact 为三种记忆粒度、以 coarse-to-fine retrieval 为读取机制的长期对话 Memory Architecture。

参考

  1. Yue, Juwei, et al. HyperMem: Hypergraph Memory for Long-Term Conversations. ACL 2026.
    https://aclanthology.org/2026.acl-long.1627/

  2. arXiv:2604.08256
    https://arxiv.org/abs/2604.08256

  3. Maharana et al. Evaluating Very Long-Term Conversational Memory of LLM Agents. LoCoMo benchmark.

  4. Edge et al. From Local to Global: A Graph RAG Approach to Query-Focused Summarization.

  5. Gutiérrez et al. From RAG to Memory: Non-Parametric Continual Learning for Large Language Models. HippoRAG 2.

  6. Luo et al. HyperGraphRAG.

  7. Chhikara et al. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory.

posted @ 2026-09-15 10:39  YourF4u1t  阅读(18)  评论(0)    收藏  举报