少样本腐化：为什么昨天的示例会拖累今天的模型

我合作过的一个团队曾有一个 JSON 提取提示词，其中包含 11 个手工调优的 few-shot 示例。在之前的模型上，这些示例将精确匹配准确率提升了 6 个百分点。模型升级后，同样的 11 个示例反而让准确率下降了 2 个百分点。没有人更改过提示词。没有人更改过评估集。这些示例就是失效了——而且更糟的是，它们开始产生误导。

这种退化并不是新模型的 bug。它是提示词本身的一种“腐化”模式。每当团队在迁移模型版本时将提示词视为固定资产，这种现象就会出现。Few-shot 示例并不是提示词独立的一部分，它们是“模型-提示词对（model-prompt pair）”的一部分。在不重新评估另一方的情况下迁移其中一方，会产生任何绑定在单一模型版本上的评估套件都无法捕捉到的退化。

新模型并不存在的失败模式

Few-shot 示例通常是针对特定模型的特定弱点选择的。资深工程师注意到模型在 JSON 输出中总是带有尾随逗号。于是他们添加了一个展示正确格式的示例。他们注意到当字段名不明确时，模型会混淆 DD/MM 和 MM/DD 格式的日期。于是他们又添加了一个示例。到提示词发布时，这些示例就是团队在评估过程中捕捉到的失败模式的压缩历史。

当模型升级时，这些失败模式会发生转变。新一代模型具有不同的格式先验、不同的指令遵循行为以及不同的盲点。上个季度修复了真实 bug 的尾随逗号示例，现在正在纠正一个新模型根本不存在的失败模式——而且模型接触该示例并非没有代价。它消耗上下文 token，引入模型不需要的风格偏见，最糟糕的是，它可能会导致过度纠正：一个已经能正确处理 JSON 的模型可能会被引导做出古怪的格式选择，因为这些演示暗示任务的重点是“格式”而非实际语义。

这种情况有一个被记录的版本叫做 few-shot 崩溃（few-shot collapse）：随着你增加示例，性能会攀升到顶峰然后下降。在某些模型上，下降趋势非常剧烈——据测算，当示例数量超过最佳平衡点时，Gemma 7B 的准确率从 77.9% 骤降至 39.9%。其背后的机制已广为人知：较长的上下文会降低对实际任务的注意力，夹在长提示词中间的示例会被忽略，而与模型预训练先验相矛盾的演示会创建模型过度索引的模式。这些机制都不会在意你的示例在上个季度表现有多好。

OpenAI 一直在直接告诉人们这一点。针对较新的推理模型的官方指南指出，“清晰的指令和定义明确的约束通常比添加示例更有效”，并且当任务需要大量推理时，few-shot 提示词反而会降低性能。Decoder 社区将 OpenAI 的迁移建议总结为：将新模型视为“需要调优的新模型系列，而不是掉头就换（drop-in）的替代品”，并且“在开始迁移时使用全新的基准，而不是沿用旧提示词栈中的每一条指令”。Few-shot 示例是旧提示词栈中最沉重的部分，也是团队最不愿意删除的部分。

针对单个示例的效用审计

严酷的事实是，在模型升级后，“提示词整体是否退化？”并不是一个足够有用的问题。尽管整体评估结果可能持平或略微向好，但 few-shot 块中的单个示例可能正在默默地造成损害。你需要的是一种针对单个示例的贡献度度量，并将其作为每次模型迁移的一部分来运行。

这种机制描述起来很简单，但操作起来却枯燥乏味。对于提示词中的每个示例 $E_i$：

• 在保留 $E_i$ 的情况下运行评估集。记录得分。
• 在移除（消融） $E_i$ 的情况下运行评估集。记录得分。
• 两者的差值（delta）就是 $E_i$ 在该模型上的效用。

贡献度为正的示例保留。贡献度为零或负的示例被删除。在新模型上新产生帮助的示例——也许是之前处于边缘但在新模型上终于发挥作用的示例——则从候选池中晋升。

在实践中有三个细节至关重要。首先，评估集必须足够大，以确保单个示例的信号不是噪声。一个只有 50 个案例的评估集几乎无法为每个示例提供统计效力；你至少需要几百个案例，这样 1-2 个点的偏差才能真正与采样抖动区分开来。其次，你必须使用确定性设置（temperature 为 0，以及 API 暴露的固定种子）运行，或者运行多次试验并取平均值——否则同一个示例在不同次的审计中测量结果会不同。第三，示例之间可能会发生相互作用：移除一个示例可能会改变另一个示例的表现，因为模型是将它们作为序列读取的。第一轮逐一消融示例的审计会捕捉到主要影响，但在 few-shot 块确实在发挥重要作用的提示词上，进行第二轮成对消融示例是值得的。

加载中…