想象一下教孩子骑自行车。起初,你会使用辅助轮。它们提供稳定性与引导,确保孩子掌握平衡和踩踏板的机械原理。但最终,一旦孩子获得了动力和信心,辅助轮就变得不再必要——甚至可能阻碍速度和灵活性。你拆掉它们,孩子依然能骑得很好。
在大型语言模型 (LLMs) 的世界里, 上下文学习 (In-Context Learning, ICL) 的作用就很像那些辅助轮。通过为模型提供几个如何解决任务的例子 (示例) ,我们引导它产出预期的输出。这对于对齐 (Alignment) ——即让 LLM 遵循指令、乐于助人并保持安全性,而无需昂贵的微调——特别有用。
然而,标准的 ICL 有一个问题: 它让辅助轮永远装在车上。它强迫模型在生成每一个 Token 时都必须处理那些示例,这在计算上既昂贵又缓慢。
在这篇文章中,我们将深入探讨一篇引人入胜的论文,题为 “Take Off the Training Wheels! Progressive In-Context Learning for Effective Alignment” (拆掉辅助轮!用于有效对齐的渐进式上下文学习) 。研究人员提出了一种名为 PICA (Progressive In-Context Alignment,渐进式上下文对齐) 的方法,该方法允许 LLM 使用示例来启动,然后为了加速生成而丢弃它们——且不损失准确性。
问题所在: 对齐的成本
在介绍解决方案之前,我们要先明确背景。将 LLM 与人类偏好对齐通常是通过有监督微调 (SFT) 和基于人类反馈的强化学习 (RLHF) 等重训练方法来完成的。虽然有效,但这些方法需要海量的数据集和巨大的计算资源来更新模型的权重。
上下文学习 (ICL) 提供了一种“免训练”的替代方案。你只需用几个良好行为的例子提示模型 (例如,“用户: 请礼貌一点。模型: 当然!有什么我可以帮您的吗?”) ,模型就会针对当前会话进行自我对齐。
缺点是什么? 推理成本。 如果你的输入提示包含 1000 个 Token 的示例,模型必须不断地处理这 1000 个 Token。对于复杂的生成任务,这种开销是巨大的。
PICA背后的研究人员提出了一个关键问题: 在整个生成过程中,示例真的是必不可少的吗?
调查: 示例如何影响 Token
为了回答这个问题,作者进行了一系列实验,分析了 Llama-2 和 Mistral 模型生成的 Token 的概率分布。他们使用了 KL 散度 (KL-Divergence) , 这是一种衡量两个概率分布差异程度的统计指标。
他们比较了两种情况:
- 零样本 (Zero-shot) : 不提供示例。
- 少样本 (Few-shot) : 提供示例 (标准 ICL) 。
他们可视化了模型行为发生最大变化的地方。

如上图 1 所示,结果很有启发性。让我们分解这四个图表:
- 输入分析 (上排) :
- 看“Separator Token (分隔符 Token) ” (标记为绿色 ‘x’) 。在实验组 (比较零样本与少样本) 中,分隔符 Token 的 KL 散度非常大。
- 解读: 模型正在将“任务函数” (它应该做什么) 编码进分隔符 Token (即查询和回答之间的定界符) 的表示中。
- 输出分析 (下排) :
- 看左下角图表中的紫色圆圈。 前部响应 Token (Prior Response Tokens) (答案的前几个词) 的散度很高,但对于后部响应 Token (Posterior Response Tokens) (答案的其余部分) ,散度显著下降。
- 解读: 示例对于正确开启响应至关重要。然而,一旦前几个 Token 生成完毕,模型就进入了一种“心流状态”,此时示例变得多余。模型已经知道了轨迹。
这引出了论文的核心假设: Transformer 将任务函数嵌入到了分隔符 Token 中,且示例仅在生成前几个 Token 时是必须的。
解决方案: 渐进式上下文对齐 (PICA)
基于这些发现,作者开发了 PICA。该方法旨在通过将生成过程分为两个不同阶段来“拆掉辅助轮”。

如图 2 所示,PICA 分两个阶段运行: 少样本阶段和零样本阶段 。
阶段 1: 少样本阶段 (获得动力)
在第一阶段,模型的行为就像一个标准的上下文学习器。它利用示例 (\(D\)) 、查询 (\(Q\)) 和分隔符 (\(S\)) 来生成答案的前几个 Token。
此阶段的数学公式是标准的 ICL:

在这里,模型生成前部 Token (\(Y_{1:i-1}^{few}\)) 。关键在于,在这个过程中,作者提取了 ICL 向量 。
还记得任务信息存储在分隔符 Token 中的观察结果吗?PICA 从 Transformer 的前 \(L\) 层捕获分隔符 Token 的隐藏状态。这个“ICL 向量”包含了在示例中发现的任务指令的浓缩精华。
阶段 2: 零样本阶段 (拆掉轮子)
一旦生成了少量 Token (例如 10 个 Token) ,PICA 就会换挡。
- 丢弃示例: 庞大的示例 (\(D\)) 从输入上下文中被移除。
- 注入上下文: 阶段 1 中生成的先行 Token 被追加到输入中。
- 注入引导: 提取的 ICL 向量用于干预模型的前向传播。
现在,模型在没有示例计算负担的情况下生成剩余的响应:

为了确保模型不会忘记任务指令 (这些指令原本在被丢弃的示例中) ,PICA 执行了一次干预 。 它用之前提取的 ICL 向量替换零样本传递中分隔符 Token 的隐藏状态:

这意味着我们要通过外科手术般的方式将指令的“记忆”植入模型的处理流中,使其能够像示例仍然存在一样继续运行,但却拥有零样本模型的速度。
实验结果
PICA 真的有效吗?研究人员在 Alpaca-eval 和 Just-eval 等基准测试中,将其与普通 ICL、零样本以及全训练模型 (SFT 和 RLHF) 进行了对比测试。
有效性与效率
结果总结在下表中,令人印象深刻。

数据中的关键结论:
- PICA vs. 普通 ICL: PICA 对抗 GPT-4 的胜率始终更高。例如,在 Llama2-13b 模型上,PICA 对抗 GPT-4 取得了 40.15% 的胜率 , 而普通 ICL 为 37.61%。
- 与 SFT/RLHF 的比较: PICA 与经过昂贵微调的模型相当,甚至有时更好。在 Llama2-7b 上,PICA 显著优于 RLHF 版本 (对抗 GPT-4 的胜率为 21.57% 对 17.49%) 。
- 加速比: 看一下“Speedup (加速比) ”列。PICA 相比普通 ICL 提供了大约 5.45倍的加速 。 这对于部署 LLM 来说是一个游戏规则改变者,因为它使推理速度几乎达到了零样本模型的水平。
消融研究: 为什么这些组件很重要
作者并没有止步于主要结果;他们解剖了 PICA 以理解为什么它有效。
1. 层选择 (Layer Selection)
他们研究了哪些层对于提取 ICL 向量最重要。

图 3 显示,随着包含的层数增加,性能会提高直到某一点 (大约第 10-15 层) ,然后趋于平稳。这支持了 Transformer 在较早层中“构建”任务函数的理论。包含更深的层会引入噪声,因为那些层专注于预测特定的下一个 Token,而不是编码一般任务。
2. 多少个 Token 才“够”?
“辅助轮”需要保留多久?

如图 4 所示,性能增益在前几个 Token 急剧上升。当模型生成了 10 个前部 Token 时,PICA 超过了普通 ICL 的性能 (由 1.0 线表示) 。这证实了在响应的最开始之后,示例就是多余的了。
3. 鲁棒性 (Robustness)
众所周知,标准 ICL 很脆弱——如果你选了“坏”的例子,模型表现就会很差。PICA 似乎要稳健得多。

图 5 展示了 PICA (紫色柱) 不仅平均胜率更高,而且方差比普通 ICL (蓝色柱) 更低。因为 PICA 依赖于任务的隐式表示 (向量) 和已生成的前部 Token,一旦生成开始,它对输入示例的具体特质就不那么敏感了。
人类评估
为了确保这些指标不仅仅是自动化测试的假象,研究人员进行了人类评估。

人类评估 (表 2) 反映了自动化基准测试的结果。对于 Mistral-7b,PICA 在 35.4% 的情况下击败了 SFT 模型,并在 40.5% 的情况下打平。这有力地证明了免训练方法可以与微调相抗衡。
局限性与未来工作
虽然 PICA 前景广阔,但它并不完美。作者指出了在枚举任务 (例如,“列出 10 位著名的音乐家”) 中的特定弱点。

在图 7 中,我们看到对于基于列表的回答,KL 散度在每个新项目开始时再次飙升。这表明对于需要独立、连续项目的任务,“辅助轮”可能需要为每个新的要点暂时重新装上。当前版本的 PICA 不能很好地处理这种“重新初始化”,导致长列表的质量较低。
结论
这篇“拆掉辅助轮!”的论文提出了一个令人信服的论点,让我们重新思考如何使用上下文学习。它挑战了在整个生成过程中都需要完整上下文的假设。
通过识别出 (1) 任务函数存储在分隔符 Token 中,以及 (2) 示例仅对初始 Token 至关重要,研究人员构建了 PICA 。 这种方法提供了一个“两全其美”的解决方案: 少样本学习的高质量与零样本推理的速度和效率。
对于 NLP 领域的学生和研究人员来说,PICA 强调了查看 Transformer “引擎盖下”的重要性。这不仅仅关于模型输出了什么,还关于它如何以及在哪里内部表示信息。随着我们迈向更高效的 AI,智能地管理上下文——而不是盲目地处理它——的方法将变得至关重要。
](https://deep-paper.org/en/paper/2503.09958/images/cover.png)