NoteBank：回放几段文本，线性注意力长上下文召回率从1.7%飙到70%

线性注意力和状态空间模型处理长输入时成本很低，因为它们用固定大小的状态替代不断增长的 KV 缓存。代价是：状态会遗忘。KAUST 的一篇新论文《History Replays Itself》（arXiv:2610.15715）提出了 NoteBank——一个免训练的附加模块，它在旁边存几段原始文本片段，当问题到来时把它们重新喂给模型。

NoteBank 论文来源截图

NoteBank 是什么

NoteBank 是一个稀疏的情节记忆模块，可以直接挂到预训练的循环模型和混合语言模型上，比如 Gated DeltaNet（GDN）和 Mamba-2。它不改变骨干网络的权重或架构，也不需要外部嵌入模型、单独训练的检索器或独立的阅读器网络。模型自己决定存什么、自己找回、自己读取。

作者的切入点很清晰：循环状态被要求同时做两件事——承载当前计算，以及充当长期存储。随着上下文增长，状态被不断覆写，证据可能在人们意识到它重要之前就丢失了。NoteBank 把这两个职责拆开：循环状态继续做它该做的事，一个小型原文存档负责召回。

为什么这件事重要

带有线性注意力层的模型越来越多地出现在混合设计中，包括 Kimi Linear 和 Qwen3-Next 系列，因为它们能削减长上下文的显存和算力开销。它们的软肋在检索：在输入深处找到某个具体事实。

在六个 RULER 大海捞针任务、一百万 token 的设置下，论文报告 GDN 的平均准确率从 1.7% 提升到 70.3%。从 4K 到 1M token，检索性能没有明显退化。持久化存储约为同等宽度、深度和精度下完整多头注意力 KV 缓存的 1/2600（论文 Figure 1 中为 74.5 MiB 对 192 GiB）。额外算力最多为分析 FLOPs 的 0.025%。

线性注意力与 KV 缓存的取舍

标准 Transformer 的注意力机制在生成每个 token 时都要与之前所有 token 的 Key 和 Value 做点积，因此 KV 缓存随上下文长度线性增长。长上下文下，显存占用和每步计算量会一起膨胀。线性注意力（Linear Attention）用可结合的核函数或状态递推改写注意力计算，让历史信息压缩进一个固定大小的状态矩阵中，每步只需更新这个状态，计算复杂度从 O(n²) 降到 O(n)，显存则是常数级。状态空间模型（SSM）如 Mamba 系列也遵循同样的递推范式。代价是：固定状态无法无损保留所有历史细节，早期信息会被后续更新覆写。这就是 NoteBank 试图补救的核心矛盾——状态适合做快速计算，但不适合做长期精确存储。两者职责分离后，线性模型的长上下文检索短板才有机会被显著缓解。

工作流程：写入、寻址、回放

整个流程分三个阶段，全部建立在模型已经计算出的特征之上。

写入

上下文按 C 个 token 为一组分块处理，循环状态照常跨块传递。在每个块内，写入器根据每个 token 的 key 向量有多“独特”来打分：1 减去该 token 的 key 与块平均 key 之间的余弦相似度，再对层和头取平均。总独特性高的窗口被选中，扩展到句子边界并控制在 token 预算内，作为笔记存储。这一步发生在任何问题出现之前，所以选择只能依赖独特性这种通用信号。

独特度打分为什么可行

NoteBank 的写入策略建立在一个假设上：在长文档中，反复出现的短语和常见连接的 key 向量会趋于相似，而真正携带独特信息的 token（如专有名词、日期、编号、罕见术语）其 key 会偏离局部平均方向。用 1 减去余弦相似度作为独特性分数，本质上是在测量该 token 在语义方向上与周围内容的“偏离程度”。这种信号完全来自模型已经计算出的特征，不需要额外嵌入模型或监督标签。代价是它无法预知未来问题需要什么，所以只能优先存储“看起来与众不同”的片段。对于信息均匀铺开、答案依赖多个普通句子聚合的任务，这种按独特度选段的策略会漏掉关键证据，这也是论文承认的局限之一。

寻址

每条笔记在每个层-头通道上获得一个紧凑地址：笔记中最独特 token 处的原生查询向量。问题到来时，从保存状态的副本出发运行问题，得到它自己的查询向量。每个通道按最大余弦相似度为所有笔记打分，并投票给它认为最匹配的那条。得票最多的前 R 条笔记被检索出来，平局时优先选择更早的笔记。

每层-头通道独立投票

在多头注意力或线性注意力结构中，每个层和每个头学习到的查询空间可能关注不同方面的信息。NoteBank 没有把笔记地址压缩成单一向量，而是为每条笔记在每个层-头通道上都保存一个原生查询向量，相当于给同一条笔记记录多种“检索线索”。问题到来时，每个通道独立计算自己与所有笔记地址的余弦相似度，并投出一票给最匹配的笔记。最终按得票数排序取前 R 条。这种多通道投票机制的好处是鲁棒性：即使某些头对当前问题不敏感，其他头仍可能命中正确的笔记。代价是存储地址的开销随层数和头数线性增长。平局时优先选择更早的笔记，则是一种偏向时间顺序的稳定化处理，避免随机性影响检索结果。

回放

被检索到的笔记按原始文档顺序拼接，从未修改的骨干网络出发（从保存状态的副本开始）重新处理。然后处理问题并生成答案。实际上，模型在回答前重新阅读相关段落，让证据在状态中保持新鲜，而非已经褪色。

控制流的粗略示意：

# 写入（上下文编码期间）
for chunk in chunks(context, C):
    state = backbone.update(state, chunk)
    notes += select_notes(chunk, keys, top_w=W)      # 独特性打分
    addresses += make_addresses(notes, queries)

# 读取（问题到来时）
q_feats = backbone.query_features(question, state_copy)
top = vote_over_channels(q_feats, addresses, top_r=R)
replay = concat_in_document_order(top)
answer = backbone.generate(state_copy, replay + question)

论文可选地训练轻量 LoRA 适配器，帮助模型在下游任务中利用回放的证据。核心检索结果无需训练。适配器仅在回放和回答阶段启用，写入和寻址不变。

成本按预期增长：存档大小随上下文长度线性增长，速率由笔记预算决定；将问题与存档匹配是穷举式的，所以也是线性增长；回放预算恒定，最多为 R 倍笔记长度的额外 token。

实际影响与局限

实际意义在于：只要给廉价循环模型一个存放原文证据的地方，它就能表现得像是拥有大得多的记忆。这对长时间运行的智能体、长文档和聊天历史很有吸引力——在这些场景里维护完整 KV 缓存成本高昂。论文报告的不只是合成检索的提升：在 LongBench v1/v2 和 MemoryAgentBench 上也有改善，覆盖从三个 1.3B 研究模型一直到 Mamba-2-8B 和训练后的 Qwen3.5-9B。

有几个需要留意的点：

大海捞针测试是最好的情况。 RULER 类任务奖励找到一段独特的文本。如果问题需要的信息稀疏散布在文档各处，或者需要对多个段落做聚合，在问题出现前就写好的稀疏存档会更吃力。
存储和算力声明是分析性的。 论文的 FLOP 数字是层级别的分析估计，作者也说明它们不测量运行时。穷举匹配和回放会增加实际延迟，FLOP 计数无法捕捉。
这是预印本。 结果尚未经过同行评审或独立复现。
它更接近检索增强，而非新架构。 新颖之处在于用骨干网络自己的 key 和 query 做写入和寻址，用自己的前向传播做读取。这省去了额外组件，但“存片段再重读”的核心模式对构建过检索增强系统的人来说并不陌生。

对开发者来说，有用的启示是设计原则：也许不需要把循环状态做大或重新训练模型来修复长距离召回。在状态旁边保留一个小型原文存档并从中回放，就能以适度的成本恢复大量丢失的能力。

RULER 基准与大海捞针任务

RULER 是一套专门评估长上下文能力的合成基准，其中最经典的任务是“大海捞针”：在一段长达数十万 token 的无关文本中埋入一条特定事实，然后要求模型根据问题找回这条事实。这类任务考验的是精确检索能力，而不是推理或多跳聚合。NoteBank 在 RULER 上从 1.7% 提升到 70.3%，说明它的写入-寻址-回放机制确实能让线性模型具备基本的精确召回能力。但正如论文指出的，大海捞针是最佳场景：待检索信息是一段独特、集中、局部的文本，恰好与按独特度选段、按查询相似度投票的机制高度契合。如果答案需要跨多个分散段落聚合，或者问题涉及的信息在写入阶段并不显眼，稀疏存档的召回率会明显下降。因此 RULER 的高分应被理解为该方法的适用边界，而非通用长上下文能力的全面证明。

总结

NoteBank 把“记住一切”和“用当前上下文计算”分开。它在读取时写入独特片段，用模型自己的查询特征找到它们，并在回答前回放。在报告中的基准上，这让一个 1.3B 的 Gated DeltaNet 在百万 token 下从接近零提升到约 70% 的平均准确率，存储开销极小。可以把它看作一个值得在你自己的工作负载上测试的免训练技术——尤其是那些答案藏在某一段独特文本里的场景——而不是一个已经解决的长上下文问题。

参考来源