论文

来自早期问题的计算能否帮助 LLMs 解决新问题?

来自早期问题的计算能否帮助 LLMs 解决新问题?

大型语言模型(LLMs)常在同一对话中解决彼此独立的问题。那么,先前问题的计算 能否帮助它们解决新问题?初步实验显示,保留历史既可能提高也可能降低后续轮次准确率,即使在同一领域内也是如此。为理解这些影响,作者采用 受控重放(controlled replay)来隔离每个“问题-历史”配对所对应的内部状态变化;在不同历史下,这些变化仍保持当前问题之间相似的关系。 为改进保留历史条件下的推理,作者提出 STAIR(Stale-Token Attention for Inter-query Reuse)。STAIR 将先前回答生成中的 keys 和 values 捕获到一个固定 bank 中,并学习在当前查询于 prompt 处理阶段读取该 bank 时重定向这些查询。基础模型保持冻结,仅训练 12,288 个参数。 在三个 Qwen 模型和四个基准上,STAIR 相比带历史的原始模型,将后续轮次平均准确率最高提升 11.67 个百分点。

论文精读

TL;DR 研究 LLM 多轮对话中历史计算对后续推理的影响,发现历史既有助益也有干扰;提出 STAIR 仅用 12K 参数重读历史 K/V,在三个 Qwen 模型上平均提升后续准确率最高 11.67 个百分点。

问题

问题背景

大语言模型(LLM)常在同一对话中处理多个独立问题,历史上下文是否有助于解决新问题?业界关注多轮交互中的状态复用与推理稳定性。

现有方法局限

当前主流做法或忽略历史计算、或将完整历史拼接到 prompt,但论文实验表明保留历史 会双向影响后轮准确率(可升可降)。直接拼接历史引入噪声,干扰当前 query 的注意力分布;而简单的 KV cache 复用仅加速生成,未能挖掘早期计算中的可用信号。此外,LoRA 等参数高效方法仍需训练较多参数,且没有针对历史状态重映射的机制。

为什么难/重要

难点在于如何隔离历史计算对当前问题的具体影响。不同历史条件下,内部状态变化保持某种相似关系(论文通过受控重放发现),但如何显式利用这种结构需要精心设计。模型冻结、仅训练极少量参数(12,288)意味着要找到一种通用的重定向策略,把陈旧的 KV 变成可复用信号,而非简单丢弃或忽略。这关系到多轮对话系统、Agent 连续任务求解的鲁棒性与效率。

行业类比

类似客服机器人连续回答多个用户提问时,如何复用前一问题的推理路径来加速当前响应,同时避免上下文污染。

核心洞察

  • 历史计算对后续问题的影响是双向的且依赖于问题-历史配对,这颠覆了将对话历史视为无关上下文或仅仅有益的观点。与以往多轮对话研究关注任务连贯性或上下文学习不同,本文通过受控重放隔离内部状态变化,发现同一历史对不同当前问题可能提升或降低准确率,即使在相同领域内。这提示工程实践需对历史缓存做动态筛选,而非简单保留全部历史。
  • STAIR 方法通过冻结基座模型仅训练 12,288 参数的查询侧重定向,在保持模型权重不变的情况下利用历史响应构建只读 KV bank,实现了平均最高 11.67 个百分点提升。相比 LoRA 等参数高效微调需要更新部分权重,STAIR 的轻量级适配更适合推理服务部署,且训练成本极低,为重用对话历史中的计算提供了新范式。

方法

输入与历史缓存

STAIR 面向多轮推理场景:输入包括当前问题 prompt 与之前轮次生成的完整对话历史。模型正常处理时,早期 response 的 token 会以 key/value 对形式保留在 KV cache 中;这些“陈旧”的 token 可能干扰当前查询,也可能包含可复用的中间计算。STAIR 的做法是在推理前固定采集一个只读的 历史 K/V bank:从早期 response 生成过程中捕获 keys 和 values,但不再更新其内容。

关键模块:查询侧重寻址

STAIR 的核心是 query-side re-addressing。当前问题在 prompt processing 阶段读取历史 bank 时,标准注意力会直接计算当前 query 与所有历史 key 的相似度。STAIR 学习一个轻量级重定向函数,对当前 query 向量施加可学习变换,使其能更准确地指向与当前问题相关的历史 token,而不是简单依赖原始点积。该过程只影响查询侧,历史 key/value 保持冻结。

输出与训练

重定向后的 query 与 bank 中的 key 计算注意力,聚合得到增强的上下文表示,进入后续层生成当前答案。训练仅更新 12,288 个参数(基础模型完全冻结),使用差分读出与推理任务的监督信号(如答案 token 的交叉熵),避免对历史 token 的表示造成干扰。

与同类方法的差异

与 LoRA 等需要更新权重矩阵且通常作用于所有层的方案不同,STAIR 只修改查询侧的重寻址参数,参数规模极小,且显式将历史计算视为可重用的只读存储,而非需要微调的模型状态。

实验

实验设计

  • 论文先通过 控制回放 隔离历史-问题配对产生的内部状态变化,发现不同历史下当前问题间关系具有相似性。
  • 提出 STAIR(Stale-Token Attention for Inter-query Reuse),将先前响应生成的 keys 和 values 存入固定 bank,并在 prompt 处理时学习重定向当前 queries。
  • 基座模型冻结,仅训练 12,288 个参数;在 三个 Qwen 模型(如 Qwen3-4B Instruct、Qwen3.5-4B、Qwen3.5-9B)和 四个基准 上评估。

关键发现

  • STAIR 相比 带历史未修改模型,平均 later-turn 精度最高提升 +11.67 个百分点。
  • 由于基座冻结且参数量极小,STAIR 能以极低训练成本复用历史计算,且无需改变原有预训练权重。
  • 实验还包括连续推理、共享 T1 历史、LoRA 对比等设置,但摘要未给出全部数值。

与基线的深度解读

  • 直接保留对话历史可能引入无关信息干扰,STAIR 通过 查询侧重定向 让当前 token 有选择地读取历史 K/V,避免全量注意力被陈旧 token 分散。
  • 相比 LoRA 等参数高效微调,STAIR 训练参数更少(仅 12,288 vs LoRA 通常数百万),且保持基座完全冻结,更适合部署时动态适配。
  • 这一结果说明 跨问题计算复用 是可行的,对多轮对话式推理系统有工程参考价值。

行业影响

落地场景

STAIR 适合任何在同一对话中连续处理多个独立问题的产品,如智能客服、在线教育答疑、代码助手、医疗咨询等。模型保留历史计算痕迹(作为 K/V bank),后续问题通过 query-side re-addressing 读取相关历史信息,提升跨问题推理准确率,无需重新生成或丢弃上下文。例如,教育答疑机器人可在一段对话中连续解答数学、物理题目,利用先前题目的中间状态辅助当前问题。

商业价值

核心价值在体验提升与降本。一方面,后续轮次准确率提升(论文报告最高 +11.67 pp)直接减少错误答案导致的用户重试、客服升级或流失;另一方面,基础模型冻结,仅训练 12,288 参数,意味着极低的微调成本和部署风险,无需维护多份全量模型。在长对话业务中,更准确的回答可降低 token 浪费(减少澄清和修正),间接降低推理成本。

与现有 stack 的接口

STAIR 可作为现有推理服务的一个轻量级插件:在模型 prefill 阶段,从历史响应中捕获 keys/values 存入固定大小的 bank,并通过一个小型可训练适配器(query-side re-addressing)对当前 query 的注意力进行重定向。集成时只需在注意力层后挂接 bank 与适配器,冻结所有原有权重。训练数据来自真实会话日志,仅需少量 GPU 即可完成 12K 参数优化。部署时增加少量显存与延迟,但可无缝嵌入 vLLM 等推理框架的自定义 attention 实现。

具体落地 use case

  • 在线教育答疑:学生连续提问多道数学题,模型保留先前解题过程的中间表示,STAIR 使后续题目可利用相似结构,减少重复推理错误,提升正确率。
  • 电商客服机器人:用户在同一会话中先后咨询商品参数、物流、退换政策等独立问题,模型通过历史计算痕迹跨问题泛化,更准确地理解当前意图,减少答非所问。

局限

  • **历史质量依赖与错误传播风险**:STAIR 从先前回复生成中捕获 K/V bank,并让当前 query 重定向注意力读取 stale tokens。当历史任务答案错误、推理链路不完整或与当前问题无关时,bank 中的无用或有害信息可能被放大;尤其在任务切换后,保留历史本身可能降低准确率。论文虽发现历史影响有正负,但方法未显式过滤或估计历史可靠性,实际部署中需要额外筛选机制,否则早期错误容易传播。
  • **实验覆盖范围有限**:只在 Qwen 系列(Qwen3-4B、Qwen3.5-4B、Qwen3.5-9B)和四个推理/数学类基准上验证,未涉及其他模型架构、代码生成、多语言或开放域对话任务。固定 bank 大小和只读历史注意力可能对非推理型任务或需要持续更新记忆的场景不够灵活,因此泛化到不同模型家族和任务类型仍有待验证。
  • **固定 bank 的容量与跨会话复用不足**:STAIR 使用固定大小的 bank 仅存储先前 response 的 K/V,无法自适应扩容或跨 session 持久化。对于多次任务切换的长会话,超过 bank 容量的早期计算会被覆盖,难以利用更早历史。训练使用 session replay 依赖成对问题历史,实际部署中构造 bank 和重定向 query 会增加 prefill 开销,可能影响吞吐,需要更高效的 memory 管理策略。
论文Jipei He2026-09-30原文

相关内容