Cooperative Memory Paging with Keyword Bookmarks for Long-Horizon LLM Conversations
论文阅读：Cooperative Memory Paging with Keyword Bookmarks for Long-Horizon LLM Conversations
论文标题：Cooperative Memory Paging with Keyword Bookmarks for Long-Horizon LLM Conversations
作者：Ziyang Liu
发表位置：arXiv preprint，arXiv:2604.12376v1，当前 arXiv 页面显示 v2 已撤回
原文链接：https://arxiv.org/abs/2604.12376
v1 HTML：https://arxiv.org/html/2604.12376v1
主题：长对话记忆、上下文管理、LLM 工具调用、分页机制、关键词书签
核心问题：当长对话超过上下文窗口后，旧内容被移出上下文，模型如何在需要时准确找回这些被移出的细节？
1. 问题背景：长对话中的“上下文内存管理”
大语言模型在多轮对话中面临一个基本限制：上下文窗口是有限的，而对话历史会不断增长。一旦对话长度超过上下文窗口，系统就必须把部分旧内容从当前上下文中移出。问题不只是“移出哪些内容”，还包括更关键的一点：当模型后来需要这些被移出的信息时，它如何知道应该找回什么？
论文将这个问题类比为操作系统中的虚拟内存和分页机制。在操作系统中，物理内存有限，旧页面可以被换出到磁盘，等程序需要时再按需调回。类似地，长对话系统也可以把旧对话段落从上下文中移出，并在需要时重新载入。
但 LLM 的难点在于：模型并不总能意识到自己缺少信息。已有方法大致有几类：
| 方法类型 | 基本思路 | 论文指出的问题 |
|---|---|---|
| 截断 | 只保留最近若干轮对话 | 旧细节直接丢失 |
| 检索式记忆 | 根据当前问题检索相关历史 | 模型或检索器需要知道该查什么 |
| 摘要压缩 | 把旧内容压缩成摘要 | 细节不可逆丢失 |
| 显式记忆工具 | 让模型主动调用搜索或记忆工具 | 模型需要自我判断“我缺信息” |
这篇论文提出的方向是 cooperative paging，即“协作式分页”：系统不指望模型从输出不确定性中自动发现缺失信息，而是在上下文中给模型留下一个很短的“关键词书签”，提醒模型哪些旧内容可以被找回。
2. 为什么被动检测“记忆缺失”失败？
论文首先讨论了一种自然想法：能不能通过模型生成时的不确定性来判断它是否缺少被移出的信息？
直觉上，如果模型缺少关键上下文，它生成答案时应该更“不确定”，例如 token-level NLL 会升高。这就像操作系统中发生 page fault 一样：系统可以通过异常信号发现需要调页。
2.1 实验设计
作者构造了 5 个多轮对话，其中包含一些关键植入信息，例如：
- 花生过敏；
- 50 美元预算；
- Rust 编程语言偏好；
- 2–4 点的会议时间冲突。
每个对话在两种条件下生成回答：
- Full context：完整上下文中保留所有关键信息；
- Gist context：关键细节被替换成简短摘要。
然后比较两种条件下模型生成答案时的 NLL 差异。
2.2 实验结果
| Case | Full | Gist | ΔNLL |
|---|---|---|---|
| Peanut allergy | 0.314 | 0.249 | -0.065 |
| Budget $50 | 0.323 | 0.205 | -0.117 |
| Rust preference | 0.087 | 0.114 | +0.026 |
| Meeting 2–4pm | 0.067 | 0.272 | +0.205 |
| Control | 0.192 | 0.217 | +0.025 |
结果显示，NLL 并不能稳定地指示“模型缺少信息”。在花生过敏和预算两个案例中，gist 条件下模型反而更自信，NLL 更低。
论文给出的解释是：模型缺少信息时不一定会“挣扎”，它可能直接生成一个更通用、更流畅、但错误的答案。例如模型不知道用户花生过敏时，可能更直接地推荐餐厅，而不是谨慎地回避相关风险。因此，低 NLL 并不代表答案可靠。
这一部分的结论是：不能只依赖模型输出中的不确定性来检测记忆缺失。系统应该明确告诉模型：哪些旧内容被压缩了、可以通过工具找回。
3. 相关工作：LLM 记忆、压缩与操作系统类比
论文将相关工作分为几类。
3.1 操作系统启发的 LLM 记忆
MemGPT 将 LLM 记忆组织成多层结构，包括主上下文、召回存储和归档存储，并通过函数调用进行检索。Pichay 则实现了面向 agentic coding 场景的透明分页代理，通过工具调用匹配来检测 page fault。
本文与这些工作的区别在于：
| 系统 | 上下文中的提示物 | 触发方式 | 内容范围 | 是否可逆 |
|---|---|---|---|---|
| MemGPT | 无 | 模型主动查询 | 消息/记忆 | 是 |
| Pichay | Handle | 工具匹配 | 工具输出 | 是 |
| 本文方法 | Keyword bookmark | 模型 + 关键词索引 | 对话内容 | 是 |
本文关注的是普通长对话内容，而不是工具输出；同时，它不是让模型从零构造查询，而是给模型一个短关键词索引。
3.2 上下文压缩与截断
一些方法通过滑动窗口、压缩矩阵、token 剪枝或摘要压缩来降低上下文成本。这类方法的问题是：压缩往往不可逆。一旦细节被压掉，后续就无法恢复。
本文的方法则强调可逆性：旧内容被移出上下文后，完整内容仍保存在外部存储中；上下文中只保留一个关键词书签，模型需要时可以调用 recall() 找回原文。
3.3 检索式和事件式记忆
另一类方法关注如何组织和检索长期记忆，例如基于 episodic memory、图结构记忆或动态抽取的记忆系统。本文则聚焦一个互补问题：不是“存什么”或“怎么检索”，而是“怎样让模型知道什么时候应该检索”。
4. 方法：Cooperative Paging with Keyword Bookmarks
论文提出的核心机制很简单：
- 将长对话分成若干 page；
- 当上下文预算不足时，选择一些 page 移出上下文；
- 被移出的 page 不直接丢弃，而是替换为短关键词书签；
- 模型看到书签后，如果需要具体细节，就调用
recall()工具取回完整 page。
4.1 分页与书签
在基础机制中，论文将对话 turn 分组为 page。当上下文预算被超过时，旧 page 被压缩为类似下面的书签：
[p3:allergy,peanut,budget]
关键词通过启发式方法自动提取，包括大写多字符 token、数字、日期等，并经过停用词过滤。每个书签大约消耗 8–24 个 token，而原始 page 往往需要 200–500 个 token。
4.2 recall 工具
模型获得一个简单工具：
recall(page_ids=[3,5])
调用后，系统从外部 key-value store 中取回对应 page 的完整内容，并注入上下文。
系统提示词的核心要求是：如果需要书签中的具体细节，先调用 recall()，不要猜测没有的信息。
4.3 方法直觉
与让模型自由构造搜索查询不同，关键词书签相当于一张轻量目录。模型不需要猜“我可能缺了什么”，而是可以看到历史中有哪些被压缩主题，再决定是否调回。
这种设计把模型的认知负担从开放式搜索变成了索引查找。
5. 初步受控实验与 LoCoMo 评估
5.1 受控实验
作者构造了 10 个合成长对话，每个对话 20–35 轮，并植入 7 类关键信息，包括 allergy、budget、deadline、medical、preference、schedule 和 contact details。
模型需要回答 22 个 QA probe，用来测试它是否会正确调用 recall()。
| Info Type | Recall Acc. | Probe 数 |
|---|---|---|
| Budget | 100% | 3 |
| Deadline | 86% | 7 |
| Allergy | 100% | 2 |
| Medical | 100% | 6 |
| Preference | 75% | 4 |
| Overall | 90.9% | 22 |
在这个小规模受控实验中，模型达到 90.9% 的 recall accuracy，page selection accuracy 为 95.2%，并且没有观察到 false positive。
5.2 LoCoMo Benchmark
论文进一步在 LoCoMo 上评估。LoCoMo 包含 10 个真实多 session 对话，每个对话超过 300 轮，QA 类型包括 single-hop、temporal reasoning、multi-hop、open-domain 和 unanswerable。
比较方法包括：
- Truncation：只保留最近 20 轮；
- BM25 Retrieval：用 BM25 检索 top-3 旧 session；
- Word-overlap Retrieval：用词重叠检索 top-3；
- Search-tool Baseline：给模型自由形式的 memory_search 工具；
- Full Context：尽量保留完整上下文，但受窗口限制截断到 60 轮；
- Bookmark+Recall：本文方法。
在 GPT-4o-mini 上，结果如下：
| Method | Score (1–5) | 95% CI |
|---|---|---|
| Truncation (20 turns) | 1.64 | [1.43, 1.86] |
| BM25 Retrieval (top-3) | 1.86 | [1.61, 2.10] |
| Word-Overlap Retrieval (top-3) | 1.88 | [1.63, 2.12] |
| Search-Tool Baseline | 1.90 | [1.61, 2.19] |
| Full Context (trunc. 60) | 2.02 | [1.75, 2.29] |
| Bookmark+Recall | 2.18 | [1.89, 2.48] |
Bookmark+Recall 得分最高，为 2.18/5。虽然绝对分数并不高，但它超过了所有检索和记忆基线。论文特别指出，与 Search-tool Baseline 相比，二者都有工具，但 Bookmark+Recall 多了结构化索引，因此模型更容易知道该召回哪部分历史。
5.3 跨模型验证
论文还在多个模型上测试了 LoCoMo 结果：
| Method | GPT | DeepSeek | Haiku | GLM |
|---|---|---|---|---|
| Full Context | 2.02 | 2.58 | 1.05 | 1.84 |
| Truncation | 1.64 | 2.56 | – | – |
| BM25 Retrieval | 1.86 | 2.69 | 1.05 | 1.72 |
| Word-Overlap | 1.88 | 2.69 | – | – |
| Search-tool | 1.90 | 2.16 | – | – |
| Bookmark+Recall | 2.18 | 2.74 | 1.47 | 2.23 |
Bookmark+Recall 在四个模型上均排名第一。论文进一步使用四个独立 LLM judge 对最强的三类方法进行评分，Bookmark+Recall 仍然在所有 judge 下排名第一。
| Judge Model | Full Ctx | BM25 | Bookmark |
|---|---|---|---|
| GPT-4o-mini | 1.83 | 1.79 | 2.11 |
| DeepSeek-v3.2 | 2.11 | 1.98 | 2.23 |
| Claude Haiku | 1.50 | 1.39 | 1.87 |
| GLM-5 | 1.54 | 1.54 | 1.84 |
| Cross-judge avg. | 1.75 | 1.68 | 2.01 |
6. 分页设计空间：边界策略与淘汰策略
第 4 节说明 cooperative paging 有效，但它留下两个系统设计问题：
- page boundary 应该怎么切？
- 当上下文满了，应该淘汰哪个 page？
论文构建了 turn-by-turn paging simulator，用来研究这两个维度。
6.1 实验设置
作者在两个数据集上做实验：
| 数据 | 描述 |
|---|---|
| Synthetic long conversations | 20 个合成长对话，每个 120–200 turns，包含 6–8 个植入事实 |
| LoCoMo | 10 个真实多 session 对话，被拼接成连续流，在末尾设置 probe |
边界策略包括：
| Boundary | 含义 |
|---|---|
| fixed_5 | 每 5 turns 切一页 |
| fixed_10 | 每 10 turns 切一页 |
| fixed_20 | 每 20 turns 切一页 |
| topic_shift | 当前 turn 与前 5 turns 的 Jaccard overlap 低于阈值时切页 |
| exchange_5 | 每 5 个 user-assistant exchange 切一页 |
淘汰策略包括：
| Policy | 含义 |
|---|---|
| FIFO | 淘汰最旧页面 |
| LRU | 淘汰最近最少使用页面 |
| LFU | 淘汰累计访问次数最少页面 |
| Bélády oracle | 知道未来访问，淘汰未来最晚再用的页面，作为上界 |
6.2 结果一：page granularity 比“智能边界”更重要
| Boundary | Synthetic | LoCoMo | Avg Pages |
|---|---|---|---|
| topic_shift | 56.7% | 45.9% | 30 |
| fixed_5 | 61.3% | 53.3% | 24 |
| fixed_10 | 77.0% | 50.9% | 12 |
| exchange_5 | 77.3% | 59.2% | 12 |
| fixed_20 | 96.7% | 63.9% | 6 |
结果很反直觉：看似更“智能”的 topic_shift 最差，而简单粗粒度的 fixed_20 最好。
论文的解释是：瓶颈不在于 page 是否语义连贯，而在于模型要在多少个 bookmark 之间搜索。topic_shift 会产生太多小 page，平均约 30 页；fixed_20 只有约 6 页。书签数量越多，模型越难选中正确页面。
因此，在这个任务中，粗粒度分页优于过度细碎的语义切分。
6.3 结果二：淘汰策略依赖对话拓扑
| Policy | Synthetic | LoCoMo |
|---|---|---|
| FIFO | 73.4% | 41.7% |
| LRU | 68.6% | 52.8% |
| LFU | 65.6% | 58.1% |
| Bélády oracle | 87.7% | 66.0% |
| Bélády – best online gap | +14.3 pp | +7.9 pp |
在合成数据上，FIFO 是最佳在线策略；在 LoCoMo 上，FIFO 反而最差，LFU 表现更好。
论文解释为两类对话拓扑不同：
- 合成对话更像 forward-moving conversation，话题一路向前，旧内容不太会被重新访问，因此 FIFO 合理；
- LoCoMo 是真实多 session 对话，人会反复回到朋友、工作、计划、过去事件等主题，因此频繁出现的旧页面仍然有价值，LFU/LRU 更适合。
这一结果说明：不存在单一最优的在线淘汰策略。实际系统可能需要根据对话是否“回访旧主题”来切换策略，或使用 recency + frequency 的混合策略。
6.4 结果三：瓶颈从“是否召回”转移到“召回哪页”
在需要的 page 已被淘汰的 1,828 个 probes 中，模型有 96.3% 的情况会正确触发 recall()。这说明模型已经基本知道“何时需要召回”。
但在触发 recall 后，只有 56.6% 选中了正确 page。也就是说，问题已经从“模型会不会召回”变成了“模型能不能根据 bookmark 区分正确页面”。
不同事实类型的差异也很明显：
| Fact type | Accuracy | Probe 数 |
|---|---|---|
| allergy | 93.9% | 478 |
| number | 88.5% | 200 |
| deadline | 83.4% | 380 |
| contact | 82.4% | 398 |
| budget | 74.3% | 420 |
| preference | 73.6% | 360 |
| schedule | 54.2% | 380 |
| medical | 51.8% | 560 |
带有鲜明表面特征的信息，例如 allergy、number，容易被 bookmark 区分；而 medical、schedule 这类共享泛化词的事实更容易混淆。
7. 什么样的 Bookmark 有效？
第 6 节专门研究 bookmark 的形式和关键词质量。
7.1 格式消融：越丰富不一定越好
论文测试了四种 bookmark 格式：
| Format | Example | Acc. | Tok. | |
|---|---|---|---|---|
| ID only | [p1] |
9.1% | 4 | |
| Minimal | [p1:kw1,kw2] |
63.6% | 24 | |
| Medium | `[p1:kw | "text..."]` | 54.5% | 91 |
| Structured | [p1:t=..;e=..] |
59.1% | 78 |
最短的关键词格式 [pN:keywords] 在准确率和 token 成本之间取得最好平衡。更长的格式反而表现更差。
论文提出一个解释：过长 bookmark 会让模型误以为自己已经拥有足够信息，从而减少 recall 调用。短 bookmark 则明确告诉模型“这里只是索引，不是完整信息”，促使它在需要细节时调用 recall。
论文将这种现象称为 information-gap hypothesis。不过作者也说明，这一解释是 post-hoc 和 correlational 的，还需要更严格的控制实验来验证因果关系。
7.2 关键词 specificity 是关键
关键词是否具体，对结果影响很大。
| Keyword Type | Example | Acc. |
|---|---|---|
| Generic | “personal preferences” | 65.2% |
| Domain-specific | “dietary pref., vegetarian” | 90.9% |
| Improvement | – | +25.7 pp |
抽象标签“personal preferences”很难让模型判断何时该召回；而“dietary preference, vegetarian”或“programming language, Rust only”这类具体关键词更能提示后续任务中的相关性。
因此，bookmark 生成不应只提取抽象主题词，而应提取 consequence-relevant keywords，也就是能够提示“这条信息在什么场景下会影响答案”的关键词。
8. 缓解 Bookmark Bottleneck：更好的关键词生成策略
第 7 节继续研究能否通过改进 bookmark generation 来缓解 page selection 错误。
论文比较了六种策略：
| Strategy | 含义 |
|---|---|
| random | 随机选择非停用词 token |
| heuristic | 使用表面规则提取大写 token、数字、金额、日期等 |
| tfidf | 选择当前对话 page 中 TFIDF 最高的词 |
| llm-contextual | 每个 page 调一次 LLM，并提供其他 page 的一行摘要 |
| llm-batch | 一次性让 LLM 为所有 page 生成关键词，并要求跨页不重叠 |
| hybrid | 先用 heuristic，再让 LLM 为每页增加一个跨页区分性关键词 |
实验固定在 fixed_10 + LRU 设置下，分别在 synthetic 和 LoCoMo 上评估。
| Strategy | Synthetic E2E | Synthetic Prec. | LoCoMo E2E | LoCoMo Prec. |
|---|---|---|---|---|
| random | 50.9 | 32.5 | 38.8 | 18.5 |
| heuristic | 72.3 | 64.3 | 52.6 | 37.7 |
| tfidf | 62.3 | 45.1 | 47.5 | 29.1 |
| llm-contextual | 66.0 | 56.6 | 38.8 | 26.3 |
| llm-batch | 68.6 | 61.5 | 61.3 | 44.4 |
| hybrid | 76.7 | 68.8 | 45.0 | 28.3 |
| vs. heuristic | +4.4 | +4.5 | +8.7 | +6.7 |
结果显示：
-
更复杂不一定更好。tfidf 和 llm-contextual 都低于 heuristic；
-
两种策略有效，但适用数据不同：
- hybrid 在 synthetic 上最好；
- llm-batch 在 LoCoMo 上最好。
8.1 为什么不同数据需要不同策略？
论文解释为：合成数据中存在很多明显表面锚点，例如过敏原、金额、联系人、日期等，heuristic 本身已经能抓住这些信息，LLM 只需要额外增加一个区分性关键词，因此 hybrid 有效。
LoCoMo 真实对话则缺少这种明显锚点。启发式提取可能退化为泛化聊天词，例如人名、语气词等，因此只在 heuristic 上补一个词并不足够。此时需要 llm-batch 重新从跨页角度生成不重叠关键词。
论文提出一个实践规则：
- 如果 heuristic 提取出的关键词本身信息量高，用 hybrid；
- 如果 heuristic 关键词信息量低，用 llm-batch；
- 可以用 heuristic token 的平均 TFIDF mass 作为近似判断指标。
8.2 仍未完全解决的问题
在 LoCoMo 上，最佳策略把 E2E accuracy 从 52.6% 提高到 61.3%，recall precision 从 37.7% 提高到 44.4%。这是明显进步，但距离完美 page selection 仍有较大差距。
论文认为，仅靠 bookmark 内容本身可能无法完全解决瓶颈，后续方向包括：
- query-time reranking：模型触发 recall 后，系统根据 query-bookmark embedding similarity 对候选 page 重新排序；
- multi-stage recall：先选粗粒度主题，再缩小候选 page，最后再由模型确认具体 page。
9. 讨论：这篇论文的主要结论
论文最后总结了几个设计原则。
9.1 Cooperative paging 有效的原因
LLM 与传统程序不同，它会遵循系统提示并使用工具。因此，只要上下文中留下合适提示，模型可以主动参与记忆管理。
关键词书签的作用不是承载全部信息，而是提供“可恢复信息目录”。模型看到如 food allergy, peanut 这样的短提示，就能判断在餐厅推荐任务中需要调用 recall。
9.2 Bookmark 质量比机制复杂度更重要
实验显示，更长、更丰富的 bookmark 反而可能降低召回准确率。关键不是在 bookmark 中塞更多细节，而是选择更具体、更有区分度、更能提示后果的关键词。
“短”并不意味着“信息越少越好”。论文强调的是：bookmark 应该短而具体，像高区分度索引，而不是长摘要。
9.3 Page granularity 比语义边界更重要
topic_shift 的失败说明，在这个机制下，过度细分会产生太多 bookmark，增加模型选择成本。粗粒度 fixed_20 虽然语义上不一定最干净，但减少了索引数量，因此效果更好。
9.4 剩余瓶颈是 bookmark discrimination
模型已经基本知道何时需要 recall，但还不能稳定地知道该 recall 哪一页。尤其当多个 bookmark 共享泛化词，例如 “budget”、“medical”、“schedule” 时，模型容易选错。
因此，未来改进方向应集中在更好的关键词区分、候选重排和多阶段召回上。
10. 局限性
论文也指出了若干局限：
- LoCoMo 的答案质量主要由 LLM judge 评分，虽然使用了多 judge 验证，但没有人工评估；
- 实验主要使用 GPT-4o-mini，DeepSeek-v3.2 作为辅助模型，跨模型验证仍可扩大；
- 分页设计实验只使用 20 个模板化长对话和 10 个真实 LoCoMo 对话，更大规模真实长对话还需要验证；
- topic_shift 使用的是简单 word-overlap，强语义检测器可能改善结果，但作者认为 bookmark inventory size 仍是核心成本；
- 关键词提取目前仍偏启发式，学习式关键词生成是重要未来方向；
- 方法依赖模型愿意调用 recall，如果模型忽略 bookmark 并直接回答，被移出的信息仍不可访问。
11. 总结
这篇论文提出了一种用于长对话记忆管理的 cooperative paging 机制：当旧对话内容被移出上下文时，不是简单截断或不可逆压缩，而是用短关键词 bookmark 替代，并允许模型通过 recall() 工具按需恢复完整内容。
论文的核心贡献包括：
- 用 minimal keyword bookmark + recall tool 构建可逆的长对话分页机制；
- 在 LoCoMo 上显示 Bookmark+Recall 相比截断、BM25、word-overlap、search-tool baseline 和 truncated full context 取得更高评分；
- 系统研究 page boundary 和 eviction policy，发现 coarse fixed-size pages 优于过度细分的 topic_shift；
- 指出当前主要瓶颈已经从“是否触发 recall”转向“能否选中正确 page”；
- 通过格式和关键词实验说明，短而具体的 bookmark 比长摘要式 bookmark 更适合该机制。
整体来看，这篇论文的重点不是设计一个更复杂的外部记忆系统，而是说明：在长对话场景中，一个低成本、可见、可恢复的关键词索引，能够显著改善模型对被移出历史的访问能力。有效的 bookmark 应该像索引，而不是摘要；应该短，但必须具体且有区分度。
参考
- Ziyang Liu. Cooperative Memory Paging with Keyword Bookmarks for Long-Horizon LLM Conversations. arXiv:2604.12376v1. https://arxiv.org/abs/2604.12376
浙公网安备 33010602011771号