循环记忆的写入路由

一句话定义

循环记忆（Recurrent Memory） 是一类用小容量状态代替全量历史的结构：不保留全部 token 的键值，而是把历史压缩进固定数量的槽，每读一个 token 更新一次，查询时读全部槽。

容量固定意味着写入不可逆。一个 token 写进槽里，就挤掉了别的东西；跳过不写，事后就再也取不回来。写入路由（write routing）就是每次写入前的两个决定：这个 token 写不写，以及写几个槽。

它解决什么问题

全注意力的问题很直接：缓存随序列长度线性增长，端侧内存装不下。循环记忆把每步开销压成常数——不管前面读过几万字，状态就那么大。

代价藏在写入里。固定容量下的记忆有两种坏法：

写多了。干扰内容占满槽位，把有用信息挤掉，查询时读到的是噪声。
写少了。关键证据当时没写，后面问起来只能猜。

多数实现把「写不写」和「写几个槽」当成同一个决定：每个 token 都写，都写同样数量的槽。这一步合并省事，但也让两种坏法没法分开调。

关键做法

arXiv 上的 Write What Matters（2610.34180）提出把两件事拆开，方法叫 FWR（Factorized Write Routing）：先用一个门控决定每个 token 保留还是跳过，再决定写入的槽数是固定值还是按 token 自适应。查询阶段仍然读全部槽，读取侧不改。

作者在两个合成任务、十个随机种子上测出了密度反转：

密集场景（Feature Recall，大量特征都要记住）：每次写四个槽时，总是写优于学习出来的选择性写入，准确率 0.472 对 0.337。漏写的代价大于干扰的代价。
稀疏场景（Passkey，长上下文里埋一条事实）：选择性写入反过来占优，0.222 对 0.048，差了四倍多。此时干扰占多数，过滤比全收更值钱。

另一条结果不太符合直觉：在学习出门控之后，测试的自适应槽数规则在两个任务上都不如固定分配。也就是说，决定「写不写」的门控有效，决定「写几个」的自适应规则暂时没兑现。

作者还给了一个诊断用的 oracle——用部署时拿不到的事实标签来判断该不该写——在 Passkey 上到 0.372。这个上界说明两件事：过滤干扰还有空间，但即使有完美标签也只有这么多，固定容量的记忆本身是瓶颈。

常见误区

以为「记住更多」总是更好。 容量固定时，多写就是多挤。稀疏事实任务上全量写入的分数只有选择性写入的四分之一。
以为一个开关能通吃两个场景。 同一个门控在密集任务上掉分、在稀疏任务上提分，方向相反。上线前要先判断自己的数据是哪种密度。
把自适应当成升级。 参数更多的那条规则在这个评测里没赢过固定分配。结构复杂不等于效果好。
只看平均指标。 这类机制的价值体现在「长上下文末端的查询」上，如果评测只测短输入，写入策略根本没被考到。

用不上的时候

任务需要逐字回溯原文（合同条款、订单明细）。这时候该用检索或全注意力，压缩记忆必然丢字。
训练数据不足，门控学不出来。学不出门控时，它的表现会落到「总是写」或「总是不写」两个端点之一。
序列本来就不长。缓存没成为瓶颈时，引入写入策略只是多一层要调的东西。
需要可解释的记忆内容。槽里是被压缩后的向量，不像缓存那样能指认「第几个 token」。

参考

arXiv:2610.34180，Write What Matters: Disentangling Token Selection from Slot Allocation in Recurrent Memory（2026-10-25）。提出 FWR，把「是否写入」与「写入槽数」解耦；两个合成任务、十个种子，四槽写入下密集任务总是写 0.472 对 0.337、稀疏任务选择性写入 0.222 对 0.048；学习门控下自适应槽数在两个任务上均不如固定分配；带标签的 oracle 在 Passkey 上 0.372。