From Context to Skills: Can Language Models Learn from Context Skillfully? 精读

论文链接：arxiv.org/abs/2604.27660 代码仓库：github.com/S1s-Z/Ctx2Skill 发表时间：2026年4月（v3 更新于2026年6月）机构：清华大学（孙茂松、漆樊超等）、DeepLang AI、UIUC（Minjia Zhang）、复旦大学、中国香港中文大学 合著标注：这是典型的高校+企业联合研究，第一作者 Shuzheng Si（司书正）和 Haozhe Zhao 为共同一作，清华大学自然语言处理实验室（THUNLP）为核心团队，与 DeepLang AI 公司及 UIUC、复旦、港中文等高校深度合作。

一、论文背景

1.1 语言模型的两类知识：参数知识 vs 上下文知识

大语言模型（LLM）的知识来源可以分为两类：

参数知识（Parametric Knowledge）：模型在预训练阶段"背下来"的知识，固化在模型参数中。例如"GPT-4 知道勾股定理"——这不是因为它在推理时查了资料，而是因为训练语料中见过无数遍。
上下文知识（Contextual Knowledge）：模型在推理时从用户提供的文本中新学到的知识。例如你给模型一份全新的游戏规则文档，然后问它规则相关的问题——它需要当场学习这份规则，而不是回忆之前背过的东西。

当前最先进的 LLM 在参数知识任务上已经非常强大，能做竞赛级数学题、写复杂代码。但在实际应用中，很多任务恰恰需要模型从全新的、模型从未见过的复杂上下文中学习知识并推理。这种能力被称为 上下文学习（Context Learning）。

举个直观的例子：你给模型一份100页的生物医药实验报告，然后问它"如果按方案B操作，第3步的试剂浓度应该调成多少？"——答案不在模型的参数里，它必须从那份报告中推理出来。

1.2 上下文学习的核心困难

上下文学习为什么难？因为上下文中的知识有三大特点：

特点	说明
跨多种格式	上下文可能是教科书、实验数据集、法律条文、游戏规则——格式五花八门
规则隐式嵌入	关键规则和程序通常不是直接写出来的，而是需要深层理解才能提取
长度长、密度高	上下文可能动辄数万词，充满了技术密集的专业术语

先前研究（特别是 CL-bench 的评估）发现，当前最强的模型在这种任务上表现远不如预期。GPT-5.1 在 CL-bench 上的解决率只有 21.1%，这意味着将近80%的上下文学习任务它做不对。

1.3 技能增强：一个直觉上的好方案

一个直觉上的解决方案是推理时技能增强（Inference-time Skill Augmentation）：

把上下文中的规则和程序提取出来，变成一组自然语言技能（Skills），然后在推理时把这些技能插入到模型的前面（系统提示中），让模型在技能的引导下更好地利用上下文知识。

所谓 Skill（技能），就是一个简短的 Markdown 文件，里面写着结构化的程序性知识，比如：

## 技能：从实验数据中提取有效样本
- 检查每个样本的温度范围是否在 [0°C, 100°C]
- 如果温度超出范围，标记为异常并跳过
- 对有效样本按时间戳排序
- ...

有了这个技能，模型在处理类似任务时就不用从头推理了，而是按照技能中总结的流程来做，效率和准确性都会提高。

1.4 两个无法绕过的核心挑战

虽然"技能增强"的想法很直观，但真要做起来，有两个根本性的挑战：

挑战一：人工标注技能的成本不可接受

在编程、数学等可验证领域，你可以让人工写一套技能。但在上下文学习场景中，上下文可能涉及各种冷门领域——今天的上下文是量子物理论文，明天是古埃及法典，后天是某款桌游规则。每个领域都需要领域专家逐条提取技能，成本极高，且无法规模化。

挑战二：自动化技能构建缺乏外部反馈

在编程领域，你可以运行代码看结果对不对（有执行反馈）。在数学领域，你可以验证答案是否正确（有真值比较）。但在上下文学习中，没有这样的自动反馈信号——你怎么判断一个技能是否忠实地捕获了上下文中的知识？

这两个挑战让传统的技能构建方法在上下文学习场景中全部失效。

二、论文定位和关联工作

2.1 研究方向全景

这篇论文位于三个研究方向的交汇处：

  上下文学习（Context Learning）
          ↘
   LM 技能系统（Skill Systems） → ★ 本论文（Ctx2Skill）← 多智能体自博弈（Multi-Agent Self-Play）
          ↘                                        （GAN, 对抗训练, Self-Play RL）
   自进化框架（Self-Evolving Frameworks）

2.2 与现有工作的定位关系

（1）上下文学习基准

直接基础：CL-bench（腾讯混元 + 复旦大学，2026.02）

CL-bench 是本文的评估基准，包含 500 个复杂上下文、1,899 个任务、31,607 个评分标准。它首次系统性地定义了"上下文学习"的评估框架，分为四个类别：领域知识推理、规则系统应用、程序任务执行、实证发现与模拟。

CL-bench 揭示了一个重要事实：即使是 GPT-5.1 这样的顶级模型，在上下文学习任务上的解决率也只有 21.1%。这个数字说明了问题的严峻性，也为 Ctx2Skill 提供了明确的优化空间。

（2）LM 技能构建方法

这个方向的工作可以分为三类，Ctx2Skill 恰好在所有三类的"盲区"上切入：

类别	代表工作	方法	局限性
人工标注	SkillNet, SkillOrchestra, SkillsBench	领域专家手写技能	不可扩展，成本过高
自动化构建	AutoSkill, AutoRefine, CoEvoSkills, EvoSkill, SkillX	从交互轨迹中自动提取技能	依赖外部反馈（执行反馈、真值比较、任务奖励）
参数内化	SKILL0, SkillRL	通过 RL 或蒸馏将技能内化到模型参数	需要参数访问，不适用于闭源模型

Ctx2Skill 的独特定位：它同时不依赖人工标注、不依赖外部反馈、不依赖参数更新。通过多智能体自博弈产生的内部反馈信号（Judge 的二元判定）来驱动技能进化，完全绕过了上述三类方法的局限。

（3）多智能体自博弈

自博弈（Self-Play）的思想在强化学习领域由来已久：

GAN（2014）：生成器和判别器的对抗训练，开创了"自博弈"范式
AlphaGo Zero（2017）：通过自我对弈不断进化策略
SPIRAL（2025）：将自博弈应用于语言模型的零和博弈
Self-RedTeam（2025）：攻击者和防御者的在线自博弈

Ctx2Skill 借鉴了这个思想，但有一个关键区别：它博弈的不是模型参数，而是技能集。两个竞争方通过迭代更新各自的自然语言技能文档来共同进化，模型的参数始终保持冻结。

2.3 与同系列工作的关系

值得注意的是，本文作者团队与 CL-bench 团队有深度重合——CL-bench 的部分作者也参与了 Ctx2Skill。这意味着 Ctx2Skill 在设计时就深度理解了 CL-bench 的评估逻辑，这既是优势（方法与评估高度对齐），也需要注意潜在的过拟合风险（论文通过技能可迁移性实验部分缓解了这一担忧）。

三、问题定义

3.1 从直觉到形式化

原始问题是模糊的：“如何让模型从复杂上下文中学得更好？”

这个问题太宽泛了。什么叫"学得更好"？怎么衡量？在什么条件下？本文通过以下步骤将其逐步形式化：

第一步：明确任务场景

上下文学习任务包含三个要素：

一个上下文 $C$（可能非常长，且包含模型从未见过的知识）
一组任务 $\mathcal{T} = \{t_j\}$（基于上下文 $C$ 设计的问题）
一组评分标准 $\mathcal{R}_j$（判断答案是否正确）

第二步：定义"解决"

一个任务只有在所有评分标准都通过时才算"解决"（全有或全无）。形式化表示为：

$$y_j = \prod_k \mathbb{I}[r_{j,k}(a_j) = \text{pass}]$$

这一定义非常严格——即使 10 个评分标准通过了 9 个，只要 1 个不通过，整个任务就不算解决。

第三步：引入技能集

定义一个自然语言技能集 $\mathcal{S}$（一个 Markdown 文件），前置到模型的系统提示中：

$$a_j \sim \pi(\cdot | \mathcal{S}, C, t_j)$$

技能集的作用是：把上下文中最关键的规则和程序蒸馏成简洁、结构化的形式，让模型不必每次都从头阅读和理解整个上下文。

第四步：形式化核心问题

最终的问题被抽象为：

如何在不依赖人工标注和外部反馈的条件下，自动发现并优化一个技能集 $\mathcal{S}$，使得模型在上下文 $C$ 上的任务解决率最大化？

3.2 为什么这个抽象是本质的

这个抽象去掉了所有外部条件的干扰：

不依赖人工：技能必须由系统自动发现和进化
不依赖外部反馈：不能使用执行结果、真值标签等外部信号
不依赖参数更新：不能修改模型参数
不限定模型：技能应该能迁移到任何 LLM

在这四个约束下，系统只能依靠内部反馈信号来驱动进化。这就是为什么论文选择多智能体自博弈——通过 Challenger 和 Reasoner 的对抗产生天然的反馈信号。

四、问题解法

4.1 核心思想：用"出题"和"答题"的对抗来进化技能

Ctx2Skill 的核心思想可以用一个类比来理解：

想象一个学习小组，有一个"出题者"和一个"答题者"。出题者不断出更难的题来测试答题者对课本的理解，答题者不断总结答题技巧来应对。两者互相推动——出题者学会了出更刁钻的题，答题者学会了更深层的理解。一个中立的"裁判"来判断对错。

这就是 Ctx2Skill 的多智能体自博弈循环。但这里进化的不是"学生的大脑"（模型参数），而是"答题技巧笔记"（技能集）。

4.2 五个角色的分工

系统中有五个角色，全部由冻结的 LLM 扮演（即不修改模型参数，只修改提示词中的技能集）：

角色 ① Challenger（挑战者/出题者）

职责：阅读上下文 $C$，生成一批测试任务和评分标准
关键设计：评分标准要求正确答案必须推导上下文的规则，而不是简单复述表面内容
进化方式：有自己的技能集 $\mathcal{S}^C$，随迭代不断更新，学会出更有针对性的题目

类比：一个越来越会出题的老师，一开始出的是简单的选择题，后来能出综合大题。

角色 ② Reasoner（推理者/答题者）

职责：阅读上下文 $C$，在技能集 $\mathcal{S}^R$ 的指导下回答 Challenger 出的题目
进化方式：技能集 $\mathcal{S}^R$ 随迭代不断更新，总结出越来越多的上下文理解技巧

类比：一个越来越会答题的学生，笔记越记越完善。

角色 ③ Judge（裁判）

职责：对照评分标准，判断 Reasoner 的答案是否正确
关键设计：返回二元判定（通过/不通过），所有评分标准通过才算成功
不参与进化：Judge 保持中立，不更新技能集

类比：一个标准化考试的阅卷系统，按严格标准打分。

角色 ④ Proposer（提议者，每侧各一个）

职责：分析失败或成功案例，诊断技能集的不足之处，提出高级改进方案
Reasoner Proposer：分析失败案例 → 诊断"答题者缺少什么知识"
Challenger Proposer：分析已解决案例 → 识别"出题者的题目还不够刁钻"

类比：一个教学顾问，看完考试结果后分析"学生哪里薄弱"和"老师哪里出题还不够好"。

角色 ⑤ Generator（生成器，每侧各一个）

职责：将 Proposer 的高级诊断物化为具体的技能更新
操作类型：添加新技能条目、合并已有条目、保留不相关的条目

类比：一个教材编辑，把教学顾问的建议实际写入教材。

4.3 迭代流程

一次完整的迭代包含以下步骤：

┌─────────────────────────────────────────────────────────┐
│                   迭代 i                                  │
│                                                           │
│  ① Challenger 用 S^C_{i-1} 生成 M 个任务+评分标准         │
│                         ↓                                 │
│  ② Reasoner 用 S^R_{i-1} 尝试回答每个任务                  │
│                         ↓                                 │
│  ③ Judge 评估每个答案 → 分为失败案例和已解决案例             │
│                         ↓                                 │
│  ④ 失败案例 → Reasoner 侧的 Proposer+Generator → 更新 S^R │
│     已解决案例 → Challenger 侧的 Proposer+Generator → 更新 S^C │
│                         ↓                                 │
│  ⑤ 更新后的 S^R_i 和 S^C_i 进入下一次迭代                  │
└─────────────────────────────────────────────────────────┘

关键设计细节：

严格对抗：Challenger 的提示中不包含 Reasoner 的技能集，反之亦然。双方只看到对方的"输出"（任务/答案），看不到对方的"策略"（技能集）。
双向进化：不仅答题者在进化，出题者也在进化。这确保了持续的压力——如果只让答题者进化，出题者可能永远只出简单题，技能集就无法深入。
失败驱动：Reasoner 的技能更新由失败案例驱动——只有在做错的地方才会触发诊断和改进。Challenger 的技能更新由已解决案例驱动——只有在学生做对的地方才需要出更难的题。

4.4 Cross-Time Replay：防止对抗性坍塌

问题：对抗性坍塌

自博弈有一个经典问题：随着迭代进行，双方可能不是变得更强，而是走向极端：

Challenger 越来越极端：为了"难住" Reasoner，出的题目越来越偏离上下文的核心知识
Reasoner 过度专业化：技能集越来越针对这些极端题目，丧失了泛化能力

这就像 GAN 中的模式坍塌（Mode Collapse）——生成器只产生少数几种样本，判别器也无法提供有用的梯度。

问题为什么在循环内不可检测？

关键在于：每次迭代的 Judge 只评估新任务。如果 Challenger 在第 5 轮出的题目已经偏离了上下文的代表性知识，Judge 照样能判断 Reasoner 做得对不对——但这个"对不对"已经不反映真实的上下文理解能力了。

解决方案：Cross-Time Replay

Cross-Time Replay 的思想很简单但很有效：

维护两个探测集（无需人工标注，从迭代过程中自动收集）：
- 硬探测集 $\mathcal{Q}^h$：每轮迭代中评分标准通过率最低的失败任务（最难的题）
- 易探测集 $\mathcal{Q}^e$：每轮迭代中评分标准最少的已解决任务（最简单的题）
在每个迭代结束后，用当前的技能集 $\mathcal{S}^R_i$ 在两个探测集上测试，计算 Laplace 平滑解决率：
$$\rho^h(i) = \frac{\text{硬探测通过数} + 1}{|\mathcal{Q}^h| + 1}, \quad \rho^e(i) = \frac{\text{易探测通过数} + 1}{|\mathcal{Q}^e| + 1}$$
选择使 $\rho^h(i) \cdot \rho^e(i)$ 最大化的技能集作为最终输出

为什么用乘法而不是加法？

用加法：一个技能集可能牺牲所有简单探测（$\rho^e \approx 0$）来换取硬探测的微小提升，加法总分看起来还行
用乘法：只要任何一方接近 0，乘积就接近 0——这强制要求技能集在硬和易两方面都表现良好，防止了"偏科"

Laplace 平滑的作用：避免探测集很小时出现 0/0 的极端情况，给所有技能集一个合理的基准线。

4.5 推理时的使用方式

训练完成后，系统只保留最终选出的最优技能集 $\mathcal{S}^R_\star$。推理时：

$$a_j \sim \pi(\cdot | \mathcal{S}^R_\star, C, t_j)$$

技能集被前置到模型系统提示中。由于 $\mathcal{S}^R_\star$ 编码的是上下文 $C$ 的可重用知识（而非特定任务的答案），所以它可以泛化到同一上下文上的任何未见任务。

4.6 实验结果一览

骨干模型	无技能基线	Ctx2Skill	提升
GPT-4.1	11.1%	16.5%	+5.4
GPT-5.1	21.1%	25.8%	+4.7
GPT-5.2	18.2%	21.4%	+3.2

几个特别值得注意的发现：

GPT-4.1 + Ctx2Skill (16.5%) 超过了 Gemini 3 Pro (15.8%)——一个较弱的模型加上好的技能，能超过更强的模型
Cross-Time Replay 的必要性得到验证：固定使用最后一轮迭代的技能集，性能从 16.5% 降到 14.7%（GPT-4.1），说明后期迭代确实存在坍塌
技能可跨模型迁移：GPT-5.1 生成的技能用在 GPT-4.1 上，性能从 11.1% 提升到 16.1%，几乎等同于 GPT-4.1 自己生成的技能

五、必要知识反推

假设让一个完全没有相关知识的人来做这项研究，他需要掌握哪些信息？

5.1 发现问题阶段

必要知识	来源	如何融合
上下文学习的概念和评估	CL-bench 等基准测试的论文	理解当前模型在上下文学习上表现不佳，存在明确的优化空间
Skill 的概念和作用	SkillNet, SkillsBench 等技能系统文献	知道"把上下文知识蒸馏成技能"是一个可行的技术路线
现有技能构建方法的局限	AutoSkill, CoEvoSkills 等论文	理解为什么现有方法在上下文学习场景中不可用——缺乏外部反馈
LLM 的推理时增强	Prompt Engineering, Chain-of-Thought 等文献	理解不修改模型参数、只修改提示的增强范式

5.2 设计解法阶段

必要知识	来源	如何融合
自博弈思想	GAN、AlphaGo Zero、博弈论	借鉴"两个竞争方共同进化"的范式，用内部对抗产生反馈信号
对抗性坍塌问题	GAN 的模式坍塌、RL 的策略退化	预见到自博弈在迭代后期可能退化，需要提前设计防护机制
多智能体协作	Multi-Agent 系统、角色扮演	设计五个角色的分工——出题、答题、裁判、诊断、生成
技能集作为自然语言模块	Skill 系统、Prompt Engineering	把"技能"定义为可编辑的 Markdown 文件，而非模型参数
失败驱动的改进	课程学习、Hard Example Mining	用失败案例驱动 Reasoner 的技能更新，用成功案例驱动 Challenger 的进化
Laplace 平滑	统计学、贝叶斯方法	在小样本情况下避免极端评估，提供稳健的技能选择标准
Cross-Validation 思想	机器学习评估方法论	用探测集来"跨时间验证"不同迭代的技能集，选择泛化性最好的

5.3 知识融合的关键洞察

这项研究最核心的知识融合洞察是：

GAN 的对抗训练思想 + 技能系统的自然语言模块 + 无需外部反馈的约束 → 用"出题"对抗"答题"来产生内部反馈，进化的对象从模型参数变成了自然语言技能集。

这个融合不是简单的"把 A 套到 B 上"，而是需要深入理解三个领域的本质：

GAN 的本质不是"两个神经网络打架"，而是"通过对抗产生学习信号"——这个信号不一定要用来更新参数
Skill 的本质不是"一段提示词"，而是"编码可重用程序性知识的外部记忆"——这个记忆可以被迭代编辑
上下文学习的本质困难不是"模型不够聪明"，而是"上下文中的知识没有被有效蒸馏和结构化"——这正是技能要做的事

把这三个理解合在一起，Ctx2Skill 的设计就自然浮现了。

六、论文中可以提取的通用性灵感

灵感 1：进化的对象不一定是参数——“编辑文档"比"修改权重"更可控

Ctx2Skill 最大的启示是：进化的对象可以是自然语言文档，而不是模型参数。

这个思路可以推广到很多场景：

Prompt 优化：不是调模型，而是自动进化和选择最优的提示词
知识库管理：不是重新训练模型，而是自动维护和更新知识文档
工作流设计：不是写死流程，而是让流程在对抗中自我进化

好处是显而易见的：自然语言文档可读、可审计、可编辑、可迁移，远比模型权重透明。

灵感 2：对抗产生反馈——当没有外部信号时，创造内部博弈

“没有外部反馈怎么办？“这是一个极具普适性的问题。Ctx2Skill 的回答是：自己创造对手。

这个思路可以推广到：

教育：让一个 AI 扮演学生、另一个 AI 扮演出题者，通过互相对抗来发现知识盲点
安全测试：用红蓝对抗的方式自动发现系统漏洞
产品设计：让一个 AI 扮演挑剔用户、另一个扮演设计师，通过对抗迭代产品设计

核心原则是：当你缺少外部反馈时，构造一个博弈环境让反馈自然产生。

灵感 3：防坍塌机制是自博弈系统的"安全带”——不能只进化，还要会"刹车”

Cross-Time Replay 的设计揭示了一个重要原则：任何自博弈系统都需要防坍塌机制。

这不是 Ctx2Skill 独有的问题——GAN 有模式坍塌，RL 有策略退化，课程学习有难度失控。解决方案的共性是：维护一个"校准集”，定期检查进化方向是否偏离了初衷。

推广到其他场景：

持续学习：定期在旧任务上测试，防止灾难性遗忘
A/B 测试：不能只看最新版本，还要定期回测历史版本
组织进化：定期回顾核心使命，防止为了追求 KPI 而偏离本质

灵感 4：硬-易双探测的乘积评估——防止"偏科"的系统化方法

Ctx2Skill 用 $\rho^h \cdot \rho^e$（乘积）而不是 $\rho^h + \rho^e$（加法）来选择最优技能集。这个看似简单的数学选择，背后是一个深刻的原则：用乘法来同时约束多个维度的下限。

推广到其他场景：

多目标优化：当你需要同时满足多个指标时，乘积形式比加法形式更能防止"用一个指标的高分掩盖另一个指标的低分"
团队评估：评估一个团队时，不应该只看平均分，还要看最弱环节
风险管理：在风险评估中，多个风险因子的联合概率用乘法，而不是把风险分数简单相加

灵感 5：弱模型 + 好技能 > 强模型——知识蒸馏的另一种形态

实验中一个引人注目的发现：GPT-4.1 + Ctx2Skill (16.5%) > Gemini 3 Pro (15.8%)。

这意味着：一个较弱的模型，如果配备了精心构建的外部知识（技能），可以超越一个更强的裸模型。这本质上是一种推理时知识蒸馏——不是把知识蒸馏到模型参数里，而是蒸馏到外部文档中。

推广思路：

小模型部署：与其用大模型，不如给小模型配一套精心构建的领域知识库
成本优化：用大模型生成技能（一次性成本），然后用小模型+技能做推理（持续低成本）
知识传承：把专家知识蒸馏成文档，让非专家也能借助这些文档做出专家级的判断

灵感 6：不对称的技能迁移——“强者的知识可以教弱者，反之不然”

实验发现：GPT-5.1 生成的技能迁移到 GPT-4.1 效果很好（16.1%），但 GPT-4.1 生成的技能迁移到 GPT-5.1 效果较差（23.1% vs 25.8%）。

这个不对称性揭示了一个通用规律：更强能力的个体能发现和利用的知识，是更弱个体无法独立发现的。 但这些知识一旦被发现，较弱个体也能从中受益。

这就像：一个大厨能发明新菜谱，学徒做不到。但大厨写下的菜谱，学徒照着做也能做出好菜。

推广到：

知识管理：组织中应该让最有能力的人来做知识创造，而非知识搬运
AI 协作：在多模型协作中，应该让强模型负责知识发现，弱模型负责执行
教育资源分配：优秀教师的价值不在于直接教学生，而在于编写高质量的教材

灵感 7：失败驱动的改进比成功驱动的改进更高效

Ctx2Skill 让 Reasoner 的技能更新由失败案例驱动（分析做错的地方），让 Challenger 的技能更新由成功案例驱动（分析做对的地方说明题目还不够难）。

这个设计的普适启示是：改进的方向取决于你是"答题方"还是"出题方"——答题方应该聚焦失败，出题方应该聚焦成功。

推广到：

产品迭代：开发团队应该聚焦用户反馈中的负面案例（Bug、投诉），而市场团队应该聚焦正面案例（什么功能用户喜欢，说明竞品还没做好差异化）
个人成长：当你是一个领域的初学者时，聚焦自己犯的错误；当你已经是专家时，聚焦别人做对但你还没想到的方向

一、论文背景#

1.1 语言模型的两类知识：参数知识 vs 上下文知识#

1.2 上下文学习的核心困难#

1.3 技能增强：一个直觉上的好方案#

1.4 两个无法绕过的核心挑战#

二、论文定位和关联工作#

2.1 研究方向全景#

2.2 与现有工作的定位关系#

（1）上下文学习基准#

（2）LM 技能构建方法#

（3）多智能体自博弈#

2.3 与同系列工作的关系#

三、问题定义#

3.1 从直觉到形式化#

3.2 为什么这个抽象是本质的#

四、问题解法#

4.1 核心思想：用"出题"和"答题"的对抗来进化技能#

4.2 五个角色的分工#

角色 ① Challenger（挑战者/出题者）#

角色 ② Reasoner（推理者/答题者）#

角色 ③ Judge（裁判）#

角色 ④ Proposer（提议者，每侧各一个）#

角色 ⑤ Generator（生成器，每侧各一个）#

4.3 迭代流程#

4.4 Cross-Time Replay：防止对抗性坍塌#

问题：对抗性坍塌#

问题为什么在循环内不可检测？#

解决方案：Cross-Time Replay#

4.5 推理时的使用方式#

4.6 实验结果一览#

五、必要知识反推#

5.1 发现问题阶段#

5.2 设计解法阶段#

5.3 知识融合的关键洞察#

六、论文中可以提取的通用性灵感#

灵感 1：进化的对象不一定是参数——“编辑文档"比"修改权重"更可控#

灵感 2：对抗产生反馈——当没有外部信号时，创造内部博弈#

灵感 3：防坍塌机制是自博弈系统的"安全带”——不能只进化，还要会"刹车”#

灵感 4：硬-易双探测的乘积评估——防止"偏科"的系统化方法#

灵感 5：弱模型 + 好技能 > 强模型——知识蒸馏的另一种形态#

灵感 6：不对称的技能迁移——“强者的知识可以教弱者，反之不然”#

灵感 7：失败驱动的改进比成功驱动的改进更高效#