长文档问答为什么反复失忆?Ctx2Skill 给了一个工程答案

Ctx2Skill 这篇论文最有意思的地方，不是又把上下文窗口吹大了一圈。

它问的是另一个更扎实的问题：如果模型不能改参数、没有人工标注、也没有外部反馈，它能不能从一份复杂文档里，自己提炼出下次还能用的“技能”？

这里的技能不是插件，也不是代码工具，而是一组自然语言操作规则。它可以被塞回后续推理提示里，让模型处理同一份文档的后续问题时，不再完全从零开始。

换句话说，Ctx2Skill 想解决的不是“读得更长”，而是“读完之后留下些什么”。

从临时阅读到可复用技能：真正的变化不是上下文变长，而是规则被沉淀并在后续问题中复用。

把几十页合同、合规手册、客服流程或实验规程扔进 LLM，看起来像是把知识交给了模型。

但多数时候，它只是临时阅读。

这和人读文档不一样。人读过一次，会形成索引、规则、例外、经验。模型拿到上下文，通常是在当前请求里重新定位、重新理解、重新组织答案。下一次同样的文档再进来，它仍然像第一次见。

CL-bench 正是把这种困难做成了评测。源文记录的口径是：500 个复杂上下文、1,899 个任务、31,607 条二元验证 rubrics，平均上下文长度 10.4K tokens，最长约 65K tokens。评分还很狠：所有 rubric 全部通过才算答对。

在这个口径下，未增强的 GPT-5.1 在 Table 1 里的整体准确率是 21.1%。也就是说，强模型看过长文档，也不等于真正掌握了文档里的操作规则。

普通 RAG 解决的是“把相关段落找出来”。

Prompt engineering 更像人工给模型写操作说明。

微调则需要标注数据和训练成本，而且新文档、新规程、新业务不断出现时，很难每次都重来。

Ctx2Skill 的路径更绕，也更有启发性：既然没有外部答案，就让模型自己生成测试、自己暴露盲点、自己更新技能文本。

论文把这个过程拆成五个冻结参数的角色：

最关键的路由是：Reasoner 答错，说明它的技能有盲区；Challenger 出的题太容易，说明它的出题技能不够强。失败样本推动 Reasoner，容易样本推动 Challenger。两边都不改模型参数，只改自然语言技能描述。

论文框架图展示了两层机制：上方是 Challenger-Reasoner-Judge 的自博弈循环，下方是 Cross-Time Replay 从历史技能候选中选择更稳的 Reasoner 技能。

这张图里容易被忽略的一点是：Challenger 的技能部署时并不会留下。

它像一个训练阶段的考官。真正被带到推理阶段的是 Reasoner 的技能。但没有一个持续变强的考官，Reasoner 很快就只会适应一小撮固定题型。

所以 Ctx2Skill 的方法论价值，不只是“让模型学会答题”。它更像是在问：一个系统能不能自动制造足够有效的失败案例，逼出更可复用的规则？

很多迭代系统都有一个暗示：多迭代几轮，总会更好。

Ctx2Skill 的实验恰好提醒我们，这个直觉不可靠。

源文记录的 GPT-4.1 backbone 口径下，Reasoner 技能从 Iter-1 到 Iter-5 的 overall accuracy 反而从 15.9% 降到 14.7%。后期 Challenger 越来越会出难题，Reasoner 也可能被逼得越来越窄，最终在一般问题上退化。

Cross-Time Replay 的作用，就是不迷信最后一版。

它把历史迭代产生的技能都留下来，再用困难探针集和容易探针集共同重评。论文使用乘积形式评分：困难题表现和容易题表现任何一边垮掉，整体分数都会被拉低。

这是一种很工程化的诚实：最新版本不天然等于最好版本。

对做 agent、评测、工具链的人来说，这个点值得单独记住。你不能只看“我又迭代了五轮”，还要问：有没有一个独立选择机制，能承认第三轮可能比第五轮更好？

主实验里，Ctx2Skill 在多个模型上都带来正向提升。源文最重要的三组数字是：

这说明方法有跨模型一致性，不是只吃某一个模型家族的红利。

但另一半也要说清楚：最强组合也只有 25.8%。即使考虑 CL-bench 的苛刻口径，复杂上下文理解距离“可靠自动化”仍然很远。

所以这组数字最稳的读法不是“Ctx2Skill 解决了长文档问答”，而是：在上下文理解密集任务里，方法论杠杆可以显著改变模型表现，但它还没有把问题变成可放心托管的生产能力。

这也是为什么我更愿意把 Ctx2Skill 看成一个离线预处理管道，而不是在线推理时随手一开的增强开关。

它适合那些文档会被反复问、反复审、反复迁移的场景：合规手册、内部操作规程、复杂客服政策、模型评测说明、发布回滚手册、数据标注规范。

如果一份文档只会被问三五个问题，先跑 25 次以上 agent 调用去造技能，成本大概率摊不回来。

如果把这篇论文迁移到真实工作里，不要从“我们要不要上 Ctx2Skill”开始。

先写一个更小的契约。

最小技能构建契约

这份契约的意义，是把“技能”从一段看似聪明的提示词，变成一个可审计的工程产物。

举个贴近 AI 团队的试点场景：你有一份模型评测规程，里面规定了样本入选、失败分类、回归判定、发布阻断、例外审批。团队每次改模型服务或评测脚本，都要有人重新解释这些规则。

用 Ctx2Skill 思路做试点，不是让 agent 直接替你发布，而是先让它从评测规程里生成技能，再拿历史评测单和新评测单做探针。通过后，它只能输出三类东西：适用规则、证据引用、是否需要人工介入。它不能改阈值，不能绕过审批，不能把不确定判断写成通过。

这样，技能库才有可能从“提示词收藏夹”变成组织知识资产。

论文最后还有几个反直觉结果，特别适合转成工程门槛。

Challenger 技能演进是最大单项贡献之一，说明“会出好题”比我们想象得更关键。早期技能往往优于后期技能，说明迭代会带来偏化风险。强模型生成的技能能较好迁移给弱模型，说明高质量技能本身有资产属性。Judge 的边缘案例校准仍是缺口，说明自博弈不等于自证明。

把这些结论压缩到上线判断里，就是四个问题：

上线前四问把论文里的边界翻译成工程门槛：复用量、验证证据、成本摊销和规则老化。

上线前四问

一个很小的一周试点就够了。不要先谈平台化，先拿一份模型评测规程做验收：

评测规程试点验收卡

不要一开始就把它放进生产链路。先证明它能留下正确的规则，再谈自动化。

Ctx2Skill 真正打动我的，不是它把分数提高了几个点。

而是它把一个长期被混在一起的问题拆开了：上下文窗口负责“看见”，技能机制负责“留下”。

只看见，不会自动变成组织知识。

能留下，也不代表可以直接上线。你还需要探针集、版本选择、Judge 校准、成本摊销、刷新机制和人工门槛。