长上下文焦虑正在变得奇怪:上下文窗口已经从 128K 卷到 1M,但 LLM 在 buried evidence 上的抽取准确率反而没跟着涨。UIUC 团队 Yanjun Zhao 等人在 7 月 2 日放出的 arXiv:2607.02509 把这件事量化得相当难看——在一个 128K 的输入里,前 0.1% 的 token 占据了 50%~80% 的累积问题相关信号,也就是说,128 个 token 实际上承担了"读完整份长文档"的活。 论文给出的解法 RECONTEXT,是一个训练免费、完全不改 backbone 的 inference harness。它在 prompt 构造阶段,直接调用模型自己的 attention 分数圈出"与问题最相关"的 evidence span,把这些 span 显式地 verbatim 重排到问题附近,最后才让模型生成。原始 128K 一字未删,forward-pass 成本与标准推理基本持平。 在 8 个 128K 长文档 benchmark、Qwen3-4B / Qwen3-8B / Llama3.1-8B 三个 backbone 上,RECONTEXT 拿到 best average rank,平均准确率从 0.24 拉到 0.30,相对增益 24.6%。配套的理论分析也写得有意思:把上下文比作联想记忆的存储、问题当检索线索、attention 当 cue-trace 关联、replay 当 trace reactivation,顺带证明递归 replay 对隐层表示的单调改进。 值得关注的两个落地边界:一是必须能拿到 attention weights,黑盒 API 直接出局,只能自托管 Qwen / Llama3 实例;二是它和 DAC、summary 类压缩天然不兼容,二者同时跑会出现"双 replay / 选证据标准冲突",论文里没给解,上生产前必须把上游压缩关掉。ReContext 是少见的"几乎不花成本就能白拿"的推理优化,但能不能真正跑进 RAG、长 code agent、合规审查流水线,取决于工程上你愿不愿意给它留一道 attention hook。