← 返回 PaperDaily 大模型与智能体

Meta最新研究:不用重算!KVEraser让LLM“精准忘记”一段上下文,速度飙升4倍

让LLM“精准抹除”一段已处理的上下文,代价居然这么小!Meta与佐治亚理工的这个工作,用学习型KV编辑替代暴力重算,搞定Agent、RAG场景下的“事后诸葛亮”式内容删除,一次编辑,速度效率直接拉满。

Meta最新研究:不用重算!KVEraser让LLM“精准忘记”一段上下文,速度飙升4倍
🐉 龙哥读论文知识星球来了!
公众号每日8篇拆解不够看?星球无上限更AI领域论文、资讯、招聘、招博、开源代码,一站式干货,每日2分钟刷完即赚! 👇扫码加入「龙哥读论文」知识星球,前沿干货、实用资源一站式拿捏~ xingqiu_header

龙哥推荐理由:
让LLM“精准抹除”一段已处理的上下文,代价居然这么小!Meta与佐治亚理工的这个工作,用学习型KV编辑替代暴力重算,搞定Agent、RAG场景下的“事后诸葛亮”式内容删除,一次编辑,速度效率直接拉满。


原论文信息如下:
论文标题:
KVEraser: Learning to Steer KV Cache for Efficient Localized Context Erasing
发表日期:
2026年6月16日
发表单位:
Georgia Institute of Technology与Meta
原文链接:
https://arxiv.org/pdf/2606.17034v1.pdf
开源代码链接:
未开源

KV缓存擦除难题:删掉一句话,却要重算整本书?

用过ChatGPT或者Claude的伙伴应该都有体会:模型在处理超长上下文时,速度并没有明显变慢,这背后全靠一个叫KV缓存(Key-Value Cache)的神器。它把前面所有token的键值存下来,后面生成新token时直接复用,省掉了重复计算的苦力。
但麻烦来了——要是发现之前处理的一段内容是错的、过时的、甚至有害的,想把它删掉,该怎么办?比如RAG(检索增强生成)系统先读了一篇过时的维基百科,然后才发现内容不对;再比如Agent调用了错误的工具,结果返回了垃圾结果;或者用户突然改主意说“刚才说的那个偏好不算了”。这些场景里,问题段落是在模型已经完整处理完上下文之后才被发现的,而KV缓存里早就留下了它的“毒痕”。
最直接的办法是:保留删除区间前面的缓存,然后对删除区间后面的所有token重新做一遍预填充(prefill)。听着简单,代价却大到吓人——计算量取决于后缀长度,而不是删除区间的长度。想象一下,你只是删了对话中的一句话,但后面还有32K的token(比如整本书),那就得把后面32K全部重算!这在实际部署中基本不可接受。
图1:KVEraser应用场景示意图
图1:KVEraser应用场景示意图。用户撤回偏好、工具调用错误、检索文档过时等,都要求在KV缓存中删除一段已处理的内容。
还有更偷懒的想法:保持缓存不变,只在后面加一句指令“请忽略刚才那段内容”。可惜实验证明,大模型根本做不到。因为后缀的KV状态已经被污染了,后面再多的“忘掉它”也抵不过存储的证据。这就像脏水已经泼到了衣服上,再喊“水消失”也没用。
那么,能不能直接在KV空间里做局部编辑,既不用重算整个后缀,又能让后续解码行为就像那段内容从未存在过一样?这就是今天要介绍的这篇来自Georgia Tech 与 Meta 的论文——KVEraser 所解决的问题。

KVEraser妙招:用“学习型转向块”代替“暴力重算”

KVEraser的核心思路非常巧妙:不重建整个后缀,而是只替换删除区间对应的KV状态,用一个学习得到的“转向块”来补偿后缀中残留的污染。具体来说,给定原始上下文 x = p ⊕ e ⊕ s,其中 p 是前缀,e 是要删除的区间,s 是后缀。保留前缀的KV缓存不变,后缀的KV缓存也原封不动地复用,仅对 e 区间的位置生成新的KV向量作为替代。
这个“转向块”由一个可训练的eraser模块 Eφ 生成。它实际上是原生成模型backbone的一份可训练拷贝(去掉语言模型头)。输入是前缀的KV缓存和删除区间 e 的原始文本,输出对应位置的新key和value。训练目标是让从这个替代缓存出发的解码行为,尽可能接近从干净编辑后的上下文X = p ⊕ s出发的解码行为。
为什么这个局部编辑能起作用?考虑注意力机制:后缀中的token原本是在包含 e 的前缀下计算的,它们与 e 的交互已经编码进了自身的KV状态。直接重用这些后缀,污染自然存在。但eraser生成的新 e 区间KV块,作为一个可调节的缓冲界面,可以在自注意力层中调整整体注意力分布,从而有效抑制 e 对后续token的影响。论文给出了一个直观的公式(具体可看原论文 Section 4.1):
期望效果:新 e 区间的贡献 ≈ 精确编辑下后缀的贡献 − 被污染下后缀的实际贡献。也就是说,转向块学习去“填补”两个后缀注意力之间的差异。
这种设计的计算复杂度优势很明显。精确重算需要重跑整个后缀 s,注意力成本为 O(|s|(|p|+|s|))。而KVEraser只构建删除区间 e(通常很短)的转向块,成本为 O(|e|(|p|+|e|))。当 |e| ≪ |s| 时,提速非常可观。而且缓存长度不变,位置编码(RoPE,Rotary Position Embedding)无需调整,复用起来非常自然。

两阶段训练:从广撒网预训练到精准任务微调

训练KVEraser的最大挑战是缺乏大规模的上下文擦除标注数据。论文巧妙设计了一个两阶段训练策略
第一阶段:连续预训练——基于跨度邻居检索。利用海量Wikipedia文本,随机插入一段100 token的文本作为要删除的区间 e,然后要求模型根据一个锚点字符串检索其相邻文本。如果锚点紧挨着 e,那么检索目标就跨越了删除区间,模型必须学会忽略 e 才能正确完成检索。如果锚点在保留上下文中,则要求模型不受干扰地访问未删除信息。这样迫使eraser学会“压制删除区间影响”和“保持其他信息可用”之间的平衡。最终构造了80K个预训练样本。
第二阶段:任务特定微调。在两个下游任务上微调:一个是控制性的多值针锋相对(NIAH)基准,插入两个具有相同key但不同value的魔法数字,要求擦除较早的那个;另一个是长文档问答中的误导性事实擦除,从Natural Questions、TriviaQA、HotpotQA中构造样本,插入误导性文本块使得模型出错,然后训练eraser擦除该块。整个微调数据集约7.5K样本,覆盖1K~32K上下文长度。

实验效果惊人:与最优方法几乎无差别,速度快4倍

在NIAH基准上,KVEraser在所有上下文长度(1K~32K)上都达到了近乎完美的精确匹配(exact match),与精确重算(full recompute)几乎一样好。而其他近似基线要么一开始准确率就很差,要么随着上下文增长迅速退化。
图3:NIAH擦除结果
图3:擦除针锋相对中的魔术数字。KVEraser在各种上下文长度下均达到近乎完美的精确匹配,与全重算持平,同时避免了全重算陡峭的延迟增长。
更惊人的是延迟:从1K到32K上下文,KVEraser的延迟仅增加24%,而全重算增加了17.6倍!其他近似基线(缓存删除并移位、仅指令遗忘、局部后缀修复)要么延迟更高,要么准确率更低,完全不在一个维度上。
在更真实的长文档问答(QA)任务中(使用训练时未见过的数据集:2WikiMultiHopQA、MuSiQue、IIRC),KVEraser同样表现最佳,在所有近似方法中取得了最高的精确匹配,同时延迟与最优基线相当或更低。全重算虽然准确率最高,但延迟是KVEraser的3~4倍,实现了当前最佳的“质量-效率”平衡。
图4:QA中擦除误导性事实的结果
图4:擦除QA中的误导性事实。KVEraser在近似方法中达到最高精确匹配,处于质量-效率帕累托前沿。全重算虽然准确率最好,但延迟是KVEraser的3~4倍。
失败案例分析也很有意思:仅指令遗忘基线随着上下文变长越来越倾向于输出“两个值都输出”,说明污染持续存在;而缓存删除+移位则常输出完全不相关的值。KVEraser仅出现了个位数的失败,例如在1K时输出了一个无关值,在32K时重复了保留的值。
插图
这种效果,龙哥只想说一句:666!

深入分析:关键信息源的消融实验验证设计合理性

论文还对eraser的输入信息源做了详细的消融实验。默认设置下,eraser接收前缀缓存KV1:m-1和删除区间 e 的文本。变体包括:去掉前缀缓存(No prefix)、加入查询(Query conditioned)、以及额外使用15%的后缀缓存(Suffix KV 15%)。结果如下表:
表1:KVEraser变体的精确匹配
表1:KVEraser变体的精确匹配。加粗表示最佳,下划线表示次佳。
可以看到,默认KVEraser(只用prefix KV和erase span)在三个数据集上平均达到0.879,已经非常高了。加上查询信息后,平均为0.871,反而略有下降;去掉前缀缓存后降到0.859;额外使用15%后缀缓存(Suffix KV 15%)情况下的变体平均为0.876,略低于默认。这说明前缀缓存和删除区间本身已经提供了足够的信息来生成有效的转向块,加入更多信息不仅增加延迟,还可能引入噪声。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答:

KVEraser的eraser模块和原始生成模型是什么关系?Eraser模块是原始生成模型backbone的拷贝(去掉语言模型头),初始权重从生成模型复制。训练期间,生成模型参数冻结,只更新eraser的参数。推理时,eraser根据前缀缓存和删除区间输出转向KV块,然后生成模型从替代缓存开始正常解码。

如果删除的不只是一段,而是多段不连续的区间怎么办?论文提到,本文只研究单段连续删除,多段删除可以迭代地逐段处理,但完整研究留作未来工作。实际应用中可能需要考虑顺序或并行的多段编辑。

KVEraser能否推广到其他模型架构,比如没有RoPE的模型?论文中使用的是基于RoPE的Qwen3-8B,但eraser模块的设计与具体位置编码无关,它直接替换KV状态,不需要调整位置索引。理论上可以应用于其他因果注意力模型,但需要重新训练eraser。

如果你还有哪些想要了解的,欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数:★★★★☆ 将KV缓存编辑思想引入上下文擦除领域,解决了重算后缀的痛苦。提供了完整的两阶段训练方案,实用性很强。

实验合理度:★★★★☆ 在合成NIAH和真实QA数据集上进行了充分对比,基线包括精确重算、仅指令遗忘、缓存删除等,消融实验也比较全面。但仅用一个模型(Qwen3-8B)略有局限。

学术研究价值:★★★★☆ 为LLM安全部署、Agent可靠性、RAG清理等场景提供了新思路,可能引发更多关于KV空间操作的研究。

稳定性:★★★☆☆ 在实验场景下表现稳定,但跨领域泛化能力尚待验证,且训练数据依赖特定构造方法,可能遇到out-of-distribution失败案例。

适应性以及泛化能力:★★★★☆ 在两种任务、多种上下文长度上均有效,泛化到未见过的QA数据集效果不错。但暂时只验证了单段连续删除,对多段删除、反向约束(如“只保留”而非“删除”)尚未测试。

硬件需求及成本:★★★★☆ 推理时需要额外运行一次eraser模块(类似于一次小前向),但远低于重跑后缀,模型大小与生成模型backbone相当,可接受。

复现难度:★★☆☆☆ 论文没有开源代码,训练数据构造依赖具体步骤(如Wikipedia插入、检索过滤),复现有一定门槛。但方法描述清晰,具备可复现性。

产品化成熟度:★★★☆☆ 方法原理清晰,效果优秀,但需要为每个生成模型单独训练eraser模块,且目前只支持单段连续删除,距离通用产品还有距离。可优先用于特定Agent、RAG系统的定制。

可能的问题:仅用Qwen3-8B一个模型验证,泛化性存疑;预训练中锚点检索任务与下游擦除任务的gap可能影响迁移效果;实际部署中删除区间检测(即识别需要删除的区间本身)是一个独立的复杂问题,本文未涉及。


主要参考文献

[1] Mufei Li, Shikun Liu, Dongqi Fu, Haoyu Wang, Yinglong Xia, Hong Li, Hong Yan, Pan Li. "KVEraser: Learning to Steer KV Cache for Efficient Localized Context Erasing". arXiv:2606.17034, 2026.
[2] Kwon et al. "Efficient Memory Management for Large Language Model Serving with PagedAttention". SOSP 2023.
[3] Gim et al. "Prompt Cache: Modular Attention Reuse for Low-Latency Inference". MLSys 2024.
[4] Hu et al. "EPIC: Enhanced Position-Independent Cache for Long-Context Reasoning". ICLR 2025.
[5] Qian et al. "In-Context Forgetting: Can LLMs Forget the Right Information?". 2026.

*本文仅代表个人理解及观点,不构成任何论文审核或者项目落地推荐意见,具体以相关组织评审结果为准。欢迎就论文内容交流探讨,理性发言哦~ 想了解更多原文细节的小伙伴,可以点击"阅读原文",查看更多原论文细节哦!       

end
🤖 KVEraser证明了,让大模型“精准忘记”一段陈旧的检索、错误的工具反馈或用户删除的历史偏好,原来可以如此优雅高效!这种“动局部、不动全局”的思维,正是AI工程化的精髓。想和龙哥一起,洞悉更多高效实用的模型推理黑科技吗?欢迎加入龙哥读论文粉丝群,扫描下方二维码或者添加龙哥助手微信号加群:kangjinlonghelper。一定要备注:研究方向+地点+学校/公司+昵称(如 LLM推理+北京+Meta+龙哥),根据格式备注,可更快被通过且邀请进群。期待与你交流更多Agent和长上下文推理的硬核技术!
wechat_helper dianzan
转发文章 微博 X LinkedIn Facebook
龙哥读论文 · PaperDaily

本文基于龙哥读论文 PaperDaily 数据库整理,结合论文原文与工程视角进行解读。