LANTERN：分层归档与时序情景检索网络，用于长上下文LLM对话

# 用于长上下文LLM对话的分层存档与时间情景检索网络

###### 摘要

大型语言模型在将对话历史压缩以适配有限上下文窗口时，会丢弃关键细节。我们提出 Lantern（分层存档与时间情景检索网络），一种轻量级记忆层，它能主动存档每一轮对话，并在压缩后通过混合检索恢复相关细节——无需任何LLM调用，每轮额外延迟小于25毫秒。¹ 在94个真实多轮对话（1,894个人工验证的事实，人类一致性κ=0.81）上，Lantern-Rerank恢复了78.3%因压缩而丢失的可验证事实，显著优于对MemGPT基于LLM的提取和多查询搜索管道的忠实复现（72.4%；Wilcoxon检验 p<0.0001，95%置信区间 [+3.1, +8.6] 个百分点，d=0.43），且推理成本极低。即使没有重排序器，基础版Lantern在无需任何LLM调用的情况下也达到或超过了该基于LLM的基线（p=0.005）。当四个生产级LLM使用Lantern恢复的上下文回答事实性问题时，准确率平均提升8.4个百分点（每个模型单独的Wilcoxon检验 p<0.05），表明恢复的上下文在不同模型架构中均有用。我们发布了完整的评估框架——包括配对显著性检验、失败分析、事实类型分层和压缩鲁棒性分析——以支持可重复性和未来工作。

## 1 引言

现代大型语言模型（LLM）在有限的上下文窗口内运行。当多轮对话超出此容量时，系统会采用*压缩*：对较早的消息进行摘要或截断，为新内容腾出空间。虽然压缩保持了对话的流畅性，但它会破坏具体细节——端口号变成了“配置了数据库”，错误代码变成了“修复了一个bug”，架构决策变成了“讨论了设计”。

我们将这种信息丢失形式化为*上下文悬崖*。设 C_t 表示第 t 轮时的上下文，F(C_t) 表示可检索的事实集合。在压缩轮次 t* 时：

C_{t*+1} = summarize(C_1, ..., C_{t*-k}) ⊕ C_{t*-k+1} ⊕ ... ⊕ C_{t*}  (1)

其中 ⊕ 表示上下文拼接。上下文悬崖定义为 ΔF = F(C_{t*}) \ F(C_{t*+1})。在我们的实验中，|ΔF| / |F(C_{t*})| > 0.5：单次压缩事件后，超过一半的特定事实丢失。最近的实证工作证实，生产级LLM的最大有效上下文窗口（MECW）可能远小于宣传的窗口，准确性在标称限制之前就已显著下降 Paulsen (2025)。

图1 (https://arxiv.org/html/2606.05182#S1.F1) 展示了编码会话中上下文悬崖的具体示例。

**压缩前**
第1轮（用户）
在 config/db.yaml 中将数据库端口设置为 5433
第1轮（助手）
完成。更新了 config/db.yaml，端口设为 5433。
第3轮（用户）
用户存储使用 PostgreSQL 而非 MongoDB
第3轮（助手）
好的选择。正在设置 PostgreSQL 驱动...
第15轮（用户）
在 src/auth.ts 中创建认证中间件...
... 再25轮 ...

**压缩后**
LLM摘要：
“讨论了数据库设置，做出了架构决策，创建了认证中间件...”
✗ 端口 5433 ——丢失
✗ PostgreSQL 决策 ——丢失
✗ 文件路径 src/auth.ts ——丢失
✗ 工具调用和文件引用 ——丢失
最近的38-40轮（保留）
只有最后几条消息存活。

**Lantern 恢复**
✓ 数据库端口 = 5433 || config/db.yaml
✓ 选择 PostgreSQL 而非 MongoDB
✓ 认证中间件 || src/auth.ts
✓ 工具调用：write_file, run_cmd
压缩 混合检索

图1：上下文悬崖的实践。左：一个编码对话，包含具体的、可恢复的事实（高亮）。右上：压缩后，较早的轮次被模糊的摘要替换——具体事实被破坏。右下：Lantern通过混合检索从其存档存储中恢复丢失的细节。

这个问题影响每一次扩展的LLM交互。编码助手会丢失配置值和架构决策。支持代理会忘记会话早期提到的客户细节。研究助手会丢失早期分析中的引用和数值结果。

现有方法分别解决了部分问题，但各自存在不足。滑动窗口仅保留最近的上下文。RAG系统 Lewis et al. (2020) 从静态文档中检索，而非实时对话历史。摘要化本质上会丢失具体性。MemGPT Packer et al. (2023) 引入了显式的内存分页，但依赖LLM本身来决定存档什么，引入了延迟和成本。

我们提出 Lantern，一种压缩感知的内存系统，它将主动的提取式存档与通过倒数排名融合 (Reciprocal Rank Fusion) 的混合检索相结合 Cormack et al. (2009)，形成一个在存档和基础恢复过程中无需任何LLM调用的管道。关键洞察是，基于LLM的事实提取——对话记忆系统中的主导范式——并非必要：一个精心设计的提取式存档管道，融合多个检索信号，可以在成本低数个数量级的情况下匹配或超越基于LLM的方法。附录D (https://arxiv.org/html/2606.05182#A4) 评估了一个用于多会话管理的可选置信度衰减机制。

我们的贡献如下：(1) 我们证明 Lantern-Rerank 恢复了 78.3% 因压缩而丢失的事实，显著优于 MemGPT-Faithful (72.4%; p<0.0001, d=0.43, 95% CI [+3.1, +8.6] 个百分点)。即使没有重排序器，基础版 Lantern (76.3%) 也优于这个基于LLM的基线 (p=0.005)，且无需任何LLM调用——从而确立了无提取存档与混合检索是LLM驱动记忆的一种高成本效益替代方案。(2) 我们表明，恢复的上下文广泛有用：四个生产级LLM在使用Lantern恢复的上下文回答问题时，平均准确率提升8.4个百分点（每个模型单独的 p<0.05），并且我们描述了基础检索（质量评分4.42/5）与重排序（4.11/5）之间的覆盖-连贯性权衡。(3) 我们发布了一个严格的评估框架——包含 94 个真实对话中的 1,894 个人工验证事实——包括失败分析、事实类型分层、配对统计检验和压缩鲁棒性分析，为未来压缩感知记忆研究建立了一个基准。

## 2 相关工作

#### 上下文窗口扩展。
RoPE Su et al. (2021)、ALiBi Press et al. (2022) 和 Longformer Beltagy et al. (2020) 等架构支持更长的序列，但并未解决超出窗口时的信息丢失问题。Liu et al. (2024) 表明LLM在长上下文中未能充分利用中间位置的信息。环注意力 (Ring Attention) Liu et al. (2023) 是一种分布式注意力算法，它将序列分区到多个设备上，从系统层面实现接近无限的序列长度；然而，它并未解决早期轮次被稀释时发生的*语义*丢失。无限注意力 (Infini-attention) Munkhdalai et al. (2024) 将压缩记忆直接集成到注意力机制中，但需要模型重新训练，限制了其在API提供的LLM上的适用性。流式LLM (StreamingLLM) Xiao et al. (2024b) 维护注意力汇点以实现稳定的流式推理，而 SnapKV Li et al. (2024) 压缩键值缓存；两者都旨在提高效率而非信息保存。InfLLM Xiao et al. (2024a) 通过高效上下文记忆提供免训练上下文外推。这些发现共同表明，应用层记忆作为架构扩展的实用且互补的替代方案。

#### 检索增强生成。
RAG Lewis et al. (2020) 和 RETRO Borgeaud et al. (2022) 通过文档检索增强LLM。这些系统专为静态知识库设计，无法处理实时对话的时间演化特性。HippoRAG Gutiérrez et al. (2024) 借鉴神经生物学原理为LLM实现长期记忆，但目标是知识图谱构建而非对话事实恢复。

#### 记忆增强代理。
MemGPT Packer et al. (2023) 为LLM代理引入了操作系统风格的内存分页，将存档决策委托给LLM。Park et al. (2023) 为生成式代理实现了基于反射的记忆。Zhang et al. (2024) 调查了LLM代理中的记忆机制，指出了在上下文持久性系统评估方面的空白。Wang et al. (2024) 和 Modarressi et al. (2024) 探索了模型级别的读写记忆。Larimar Das et al. (2024) 通过外部记忆模块为LLM引入了情景记忆控制。CoALA框架 Sumers et al. (2024) 提出了具有结构化记忆组件的语言代理认知架构。

#### 对话记忆基准。
LongMemEval Wu et al. (2024) 对跨会话的长期交互式记忆进行基准测试。LoCoMo Maharana et al. (2024) 提供了一个用于评估长对话记忆的数据集。Lantern的评估框架通过专门关注压缩事件后的*会话内*事实恢复来补充这些工作。

Lantern 在三个维度上与先前工作不同。与截断和滑动窗口不同，它在*压缩之前*存档上下文。与标准RAG不同，它索引的是实时对话轮次而非静态文档。与 MemGPT Packer et al. (2023) 不同（后者将存档决策委托给LLM，带来延迟和成本），Lantern的存档和基础检索无需任何LLM调用；LLM仅在可选的重排序步骤和压缩本身被调用。

## 3 方法

Lantern作为应用程序和LLM之间的中间件运行。它观察每一轮对话，维护一个持久的SQLite存储，并在压缩事件后注入恢复的上下文。系统有两个核心阶段——*存档*和*恢复*——以及一个用于多会话管理的可选*强化*阶段（图2 (https://arxiv.org/html/2606.05182#S3.F2)）。

➊ 存档每一轮 · 零LLM调用
记忆存储 SQLite · WAL · FTS5
➋ 在压缩事件上恢复
➌ 强化 自我优化循环

对话轮次 LLM运行时
分块轮次 用户 · 助手 · 工具调用
摘要 提取式 · ≤1200字符
标签与分类 情景 / 语义 / 程序
嵌入 MiniLM-L6-v2 · 384维
SQLite WAL模式 FTS5索引 去重哈希 c0=0.5 σ0=0.5
写入

语义 余弦
全文 FTS5 关键词
Jaccard 重要性 R⋅F⋅D⋅c⋅σ
RRF融合 ∑ 1/(60+rank)
MMR多样性 λ=0.7
预算打包 B=6k字符
压缩 抽取 注入上下文
提升 c+0.15 衰减 c-0.02 修剪 c<0.15
恢复ID 更新 c, σ

图2：Lantern系统架构。存档（蓝色）：每一轮被分块、摘要、标记和嵌入——零LLM调用。记忆存储（青色）：带FTS5索引、去重和每个条目置信度c及EMA成功率σ的WAL模式SQLite。恢复（橙色）：压缩时，四个并行检索信号通过倒数排名融合合并，通过MMR（λ=0.7）多样化，并打包到6000字符预算内。强化（绿色）：检索到的条目被提升，未检索的衰减，过时的条目被修剪——形成一个自我优化循环。

### 3.1 主动存档

在每一轮，Lantern执行五个操作，无需LLM调用：

#### 1. 分块。
用户和助手消息被分组为轮次对，同时包含工具调用元数据和文件路径。

#### 2. 提取式摘要。
摘要被确定性生成：每条消息最多500字符，加上工具和文件引用，截断至1200字符。

#### 3. 嵌入。
使用句子转换器 (all-MiniLM-L6-v2, 384维) 对摘要进行编码 Reimers and Gurevych (2019)。

#### 4. 标签和类型提取。
通过模式匹配提取标签（例如文件路径、错误代码、函数名）。每轮对话被分类为记忆类型（情景、语义或程序），以支持下游过滤。

#### 5. 存储。
条目写入SQLite（WAL模式，FTS5全文索引），附带元数据：置信度分数（初始化为0.5）、访问次数、时间戳、标签和记忆类型。

每轮存档成本：零LLM API调用，<25毫秒延迟，约2KB存储。（压缩本身由宿主LLM运行时执行，不属于Lantern的存档管道。）

### 3.2 混合检索与恢复

当检测到压缩时，Lantern在字符预算B内恢复上下文。检索结合四个通过倒数排名融合（RRF）融合的排序列表 Cormack et al. (2009)：

#### 语义相似性。
查询嵌入与存储条目嵌入之间的余弦相似性。

#### 全文搜索。
SQLite FTS5对条目摘要和内容的排序。

#### 关键词重叠。
查询词与条目查找提示（标签、文件路径、工具名称）之间的Jaccard相似性重叠。

#### 重要性评分。
每个条目按以下方式评分：

I(e) = R(e) · F(e) · D(e) · c_e · σ_e (2)

其中 R(e) = exp(-0.693 · Δt / T_{1/2}) 是新近度（半衰期 T_{1/2}=7 天），F(e) = log2(a_e+1)+1 是频率，D(e) 是丰富度（工具调用和文件引用的奖励），c_e 是置信度，σ_e 是EMA成功率。

四个排序列表使用 RRF 常数 k=60 进行融合：

RRF(e) = Σ_{L∈L} 1 / (k + rank_L(e)) (3)

在将条目打包到预算之前，对融合排序应用最大边际相关性（MMR）Carbonell and Goldstein (1998) 以促进多样性。

#### 可选重排序