少样本饱和曲线：为什么添加更多示例最终会适得其反
一个团队在路线优化任务上测试 Gemini 3 Flash，零样本准确率达 93%。他们开始添加示例，性能一路攀升——但在添加到八个示例时，准确率骤降至 30%。这不是噪声，而是少样本饱和曲线的猛烈反噬。这是大多数工程师只有在部署了一个四个示例时看起来正常、十二个示例时却出现问题的提示之后才会发现的故障模式。
"更多示例严格意味着更好"的直觉是错的。跨 12 个 LLM 和数十种任务类型的数据显示了三种截然不同的失败模式：稳定平台期（收益趋于平缓）、峰值回归（收益先升后崩）和选择诱导崩溃（更换示例检索策略后收益蒸发）。理解自己处于哪种模式，会改变你构建提示的方式、何时放弃少样本方案，以及是否应该转向微调。
三种失败模式
并非所有的少样本性能下降都长一个样子。
峰值回归是最具 戏剧性的，也是最具诊断价值的。模型在 0 到 4 个示例之间持续改善，到达峰值后急剧下跌。上文的 Gemini 3 Flash 案例是一个极端例子——从峰值到 8-shot，性能下降了 63 个百分点。但这种模式在各模型中普遍存在：Qwen 3.5 在代码修复任务上，随着示例数量增加，准确率从 56% 骤降至 0%。这种情况发生在示例的分布开始让模型学到某些细微错误的时候。
稳定平台期是良性版本。收益趋于平缓，边际改善趋近于零，但性能不会崩塌。大多数工程师在不知情的情况下就处于这种状态——在第四个示例之后已经停止贡献的示例上浪费 token。代价是浪费而非灾难性。
选择诱导崩溃是最隐蔽的。固定示例表现良好；通过 TF-IDF 或语义相似度动态检索的示例，在同一任务、同一模型上导致 58% 的相对性能下降。示例的内容不会改变你的平均值，但选择策略决定了你是稳定地达到峰值性能，还是随机触发失败案例。生产环境中使用基于检索的示例选择的系统都面临这种风险。
为什么更多示例开始适得其反
一旦理解了模型实际上在用你的示例做什么，这些失败模式就变得合理了。
模型学习的是格式和分布，而不是映射关系。 这是 Min 等人（2022 年）令许多提示工程师至今未完全消化的不舒适发现：随机替换少样本示例中的正确标签，几乎不影响性能。模型并不是在学习"当输入看起来像 X 时，输出 Y"——它在学习输出格式、词 汇风格、有效响应的结构。这意味着超过某个点之后，你不是在教它新的输入输出映射，而是在引入噪声。
中间迷失效应吞噬你的信号。 Transformer 的注意力在上下文中并非均匀分布。模型对提示开头和结尾的注意力更好；中间部分会被软焦点处理。堆入足够多的示例之后，实际的任务指令就被埋在了模型以降低注意力处理的上下文中间。那些本该提供帮助的示例变成了干扰。关于长上下文提示的研究持续显示，当关键信息位于上下文窗口中间 60% 时，准确率下降超过 30%。
虚假相关性随示例数量累积。 每个示例都是模型可以从中推断隐式规则的数据点。只有两三个示例时，这些规则受到约束——没有足够的模式来过拟合。有十或二十个示例时，模型开始拾取你无意传达的结构。如果你精心挑选的示例恰好共享某种句子结构、词汇风格或领域频率偏差，模型就会把那种虚假关联和合法关联一起学进去。然后把虚假规则应用到表面上匹配模式的输入上，不管底层任务逻辑是否适用。
一个具体的例子：如果你在对客服工单进行分类，而你的示例恰好在投诉中都使用了"紧急"一词，但在问询中从未使用，模型就会开始把"紧急"视为投诉类的强预测因子——即使工单是在询问一个紧急的产品问题。添加更多意外强化这种偏差的示例，你挖的坑就更深了，而不是更浅。
注意力是二次方的，上下文并非免费。 从 2 个示例扩展到 20 个示例不仅仅增加了线性的 token 成本。Transformer 的自注意力随上下文长度呈二次方扩展，这意味着模型在指数增长的成对关系集合上分配其有限的注意力容量。这种计算压力不会以错误的形式表现出来；它表现为对任何单个信号注意力的弱 化，包括你的任务指令。
不同任务类型的饱和点
饱和不是普遍的——它因任务和模型而异，这就是为什么如果不做显式测试，这种失败模式很难发现。
翻译任务的可扩展性最好。对于低资源语言，一些模型在数百个示例内持续改善。这种规律足够一致，使得低资源翻译可以说是多样本提示最好的使用理由。任务格式严格，映射关系是确定性的，示例能添加真实的信号。
数学推理更早达到饱和。MATH 数据集的性能通常在大约 125 个示例时达到峰值，然后下降。GPQA（研究生级科学推理）也是如此——125-shot，然后在 250 时下降。抽象推理任务的饱和速度似乎比程序性任务更快：一旦模型学会了答案格式，更多示例并不能教它更好地推理。
分类和提取任务饱和最快。大多数行业基准测试显示，2-5 个示例的范围能获取 80% 的可实现收益。超过 8 个示例后，这些任务类型的改善就落入噪声区间。这是最常见的生产工作负载，这意味着大多数工程师在一个他们的示例已经停止帮助的区间中操作。
