Learning When to Remember: Risk-Sensitive Contextual Bandits for Abstention-Aware Memory Retrieval in LLM-Based Coding Agents

📄 arXiv: 2604.27283v1 📥 PDF

作者: Mehmet Iscan

分类: cs.CL, cs.AI, cs.LG

发布日期: 2026-04-30

备注: 26 pages, 7 figures, 10 tables. Code and deterministic local artifacts are available at the repository listed in the paper

💡 一句话要点

提出RSCB-MC，解决LLM代码Agent中记忆检索的风险控制问题

🎯 匹配领域: 支柱二：RL算法与架构 (RL & Architecture) 支柱九：具身大模型 (Embodied Foundation Models)

关键词: LLM代码Agent 记忆检索 风险敏感 上下文Bandit 调试安全

📋 核心要点

  1. 现有基于LLM的代码Agent在记忆检索中面临风险控制问题，表面相似性可能导致不安全的记忆注入。
  2. RSCB-MC将记忆使用视为风险敏感的控制问题，通过上下文Bandit算法决定是否使用记忆以及如何使用。
  3. 实验表明，RSCB-MC在保证0%假阳性率的同时，显著提升了代码Agent的调试成功率和决策效率。

📝 摘要（中文）

基于大型语言模型（LLM）的代码Agent越来越多地依赖外部记忆来复用先前的调试经验、修复轨迹和仓库本地的操作知识。然而，只有当当前故障与之前的故障真正兼容时，检索到的记忆才有用；堆栈跟踪、终端错误、路径或配置症状的表面相似性可能导致不安全的记忆注入。本文将问题-记忆的使用重新定义为一个选择性的、风险敏感的控制问题，而不是一个纯粹的top-k检索问题。我们引入了RSCB-MC，一个风险敏感的上下文Bandit记忆控制器，它决定Agent是否应该不使用记忆、注入最佳解决方案、总结多个候选方案、执行高精度或高召回率检索、弃权或请求反馈。该系统通过模式-变体-事件模式存储可重用的问题知识，并将检索证据转换为一个固定的16特征上下文状态，捕捉相关性、不确定性、结构兼容性、反馈历史、假阳性风险、延迟和token成本。其奖励设计对假阳性记忆注入的惩罚比错过重用的惩罚更强，使非注入和弃权成为首要的安全措施。在确定性的smoke-scale artifacts中，RSCB-MC获得了最强的非oracle离线重放成功率，为62.5%，同时保持0.0%的假阳性率。在一个有界的200例热路径验证中，它达到了60.5%的代理成功率，假阳性率为0.0%，p95决策延迟为331.466微秒。结果表明，对于代码Agent记忆，关键问题不仅是哪个记忆最相似，而且是检索到的任何记忆是否足够安全以影响调试轨迹。

🔬 方法详解

问题定义：论文旨在解决基于LLM的代码Agent在利用外部记忆进行调试时，由于检索到的记忆与当前问题不完全匹配而导致的错误注入问题。现有方法通常采用top-k检索，但忽略了记忆注入的风险，可能导致Agent做出错误决策，降低调试效率。

核心思路：论文的核心思路是将记忆检索问题转化为一个风险敏感的上下文Bandit问题。Agent需要根据当前问题的上下文，权衡使用记忆带来的潜在收益和风险，并选择最优的行动策略，包括不使用记忆、注入最佳解决方案、总结多个候选方案、执行高精度或高召回率检索、弃权或请求反馈。这种方法强调了记忆使用的安全性，避免了盲目注入可能带来的负面影响。

技术框架：RSCB-MC系统包含以下主要模块：1) 知识存储模块，采用模式-变体-事件模式存储可重用的问题知识；2) 特征提取模块，将检索证据转换为一个固定的16特征上下文状态，捕捉相关性、不确定性、结构兼容性、反馈历史、假阳性风险、延迟和token成本；3) 上下文Bandit控制器，基于提取的特征，利用风险敏感的Bandit算法选择最优的行动策略；4) 奖励设计模块，对假阳性记忆注入进行更强的惩罚，使非注入和弃权成为首要的安全措施。

关键创新：论文最重要的技术创新点在于将记忆检索问题重新定义为一个风险敏感的上下文Bandit问题，并设计了相应的RSCB-MC系统。与现有方法相比，RSCB-MC不仅考虑了记忆的相关性，还考虑了记忆注入的风险，从而提高了Agent的调试安全性和效率。

关键设计：RSCB-MC的关键设计包括：1) 16特征上下文状态的设计，全面捕捉了记忆的相关性和风险；2) 风险敏感的奖励函数设计，对假阳性记忆注入进行更强的惩罚；3) 多种行动策略的选择，包括不使用记忆、注入最佳解决方案、总结多个候选方案、执行高精度或高召回率检索、弃权或请求反馈，从而提高了Agent的灵活性和适应性。

🖼️ 关键图片

fig_0
fig_1
fig_2

📊 实验亮点

RSCB-MC在确定性的smoke-scale artifacts中获得了62.5%的非oracle离线重放成功率，同时保持0.0%的假阳性率。在有界的200例热路径验证中，它达到了60.5%的代理成功率，假阳性率为0.0%，p95决策延迟为331.466微秒。这些结果表明，RSCB-MC在保证安全性的前提下，显著提升了代码Agent的调试性能。

🎯 应用场景

该研究成果可应用于各种基于LLM的代码Agent，例如自动化调试工具、代码修复系统和智能编程助手。通过提高记忆检索的安全性，可以显著提升这些Agent的性能和可靠性，降低开发和维护成本。此外，该方法还可以推广到其他需要安全决策的场景，例如医疗诊断和金融风控。

📄 摘要（原文）

Large language model (LLM)-based coding agents increasingly rely on external memory to reuse prior debugging experience, repair traces, and repository-local operational knowledge. However, retrieved memory is useful only when the current failure is genuinely compatible with a previous one; superficial similarity in stack traces, terminal errors, paths, or configuration symptoms can lead to unsafe memory injection. This paper reframes issue-memory use as a selective, risk-sensitive control problem rather than a pure top-k retrieval problem. We introduce RSCB-MC, a risk-sensitive contextual bandit memory controller that decides whether an agent should use no memory, inject the top resolution, summarize multiple candidates, perform high-precision or high-recall retrieval, abstain, or ask for feedback. The system stores reusable issue knowledge through a pattern-variant-episode schema and converts retrieval evidence into a fixed 16-feature contextual state capturing relevance, uncertainty, structural compatibility, feedback history, false-positive risk, latency, and token cost. Its reward design penalizes false-positive memory injection more strongly than missed reuse, making non-injection and abstention first-class safety actions. In deterministic smoke-scale artifacts, RSCB-MC obtains the strongest non-oracle offline replay success rate, 62.5%, while maintaining a 0.0% false-positive rate. In a bounded 200-case hot-path validation, it reaches 60.5% proxy success with 0.0% false positives and a 331.466 microseconds p95 decision latency. The results show that, for coding-agent memory, the key question is not only which memory is most similar, but whether any retrieved memory is safe enough to influence the debugging trajectory.