ACToR：RAG 从”塞满上下文”到”决策点触发”

代码补全的 RAG 有一个根本性浪费：它在任务开始前把所有相关上下文都塞进去，不管模型实际需不需要、在哪里需要。

ACToR（Adaptive Critical Token-Aware Retrieval）做了件反直觉的事：不再预先加载，而是让模型在生成过程中自己喊”停，我这里需要上下文”。

Kefeng Duan 等人，arXiv:2609.01601。

Critical Tokens：错误的聚集点

论文的核心洞察是：自回归生成过程中，错误不是均匀分布的。

一小部分 token（占生成位置的 5–11%）集中了大多数功能性失败。这些位置的 token 一旦生成错误，后续代码会沿着错误语义路径走下去，最终导致功能失效。这些位置就是”critical tokens”。

三个特征可以识别它们：

  • Token Mismatch：模型的 top-1 预测偏离 ground truth
  • Uncertainty：概率分布的熵高——模型自己也不确定该填什么
  • 后续注意力影响：来自未来 token 的高注意力权重，说明当前位置是后续代码的依赖节点

这不是靠人工规则定的——一个轻量 3 层 MLP 分类器，用 LLM 最后一层的隐藏状态训练，自动识别。

推理时触发：不是预填充，是按需

关键机制：

生成过程中，分类器逐 token 监控。如果当前 token 被判定为 critical（p(critical) > p_threshold），模型暂停，执行一次定向检索——用”原始 prompt + 已生成序列 + 当前 critical token”构造查询——然后用检索回来的上下文重新解码当前 token。

这改变了 RAG 的时序：不是”开始前塞满”，而是”中途需要时触发”。

position-aware 加权：检索出来的上下文也不是等权的。论文设计了一个双端高斯权重 profile，强调序列头部和尾部的 token——这两个位置通常包含最关键的仓库级信息（import、类签名、初始化）。

数据：只触发关键位置，精度反而更高

RepoExec +8.4%，CoderEval +15.4%。相对提升。

关键在于：critical tokens 只占 5–11% 的生成位置，但主导了大多数失败。这意味着大多数 RAG 检索其实是浪费的——你给了模型大量它不需要的上下文，反而可能稀释真正有用的信号。ACToR 把检索次数压缩到必要的少数位置，精度反而上升。

反直觉失效案例

有意思的是：critical tokens 里的错误高度集中在 keywords（关键字），而模型的注意力却不成比例地指向结构操作符和分隔符。

这说明模型在”看”代码结构，但失败在”写”代码关键字。attention map 告诉你模型关注了什么，但不能预测错误会在哪里发生。这对基于注意力做代码生成质量判断的现有方法是个挑战。

实践意义

对长仓库、低上下文窗口部署是直接可落的推理期改造。不需要重训模型，不需要改变架构，只需要在生成逻辑里加一个 critical token 检测 + 触发检索的模块。

这对 Cursor、Cline 这类 IDE 插件尤其有价值——它们的上下文窗口压力大，但代码生成质量要求高。按决策点补上下文，比预填整个文件要聪明得多。

参考

  • ACToR：arXiv:2609.01601，GitHub: github.com/DeepSoftwareAnalytics/ACToR