few-shot 数量多少合适？边际效应

用 DeepSeek 做客服消息分类，先给了两个示例，准确度肉眼可见地上了一个台阶；贪心起见又堆到十二个，结果几乎没再变好，提示却长了一大截。示例数量的回报曲线不是直线，这条边际效应值得讲透。

示例为什么越多越不划算

每加一个示例，提示就长一截，模型要分摊的注意力也多一份。前面几个示例负责定调——告诉模型任务长什么样、边界在哪里，贡献最大；后面的示例只是在重复相似模式，信息增量越来越小，占用的空间和注意力却是实打实的。

边际递减是怎么发生的

可以把它想成学做菜：看两三遍示范，手法就学会了；看到第十遍，能学到的已经差不多。模型同理，当新示例与已有示例模式高度重合，它几乎不再修正自己的理解，只白白增加上下文负担，还挤占了放任务描述和当次内容的位置。

不同任务的数量参考段

• 格式模仿类：一到两个精修示例通常够用。
• 分类判断类：每个类别一个代表示例，类别多时优先覆盖易混对。
• 风格转换类：两三个，且风格要一致，混风格的示例比没有示例更糟。

三类任务的示例数量与要点不同，对照着定档。

该删示例的几种信号

• 提示长到模型开始漏掉任务描述。
• 加示例后输出反而更僵，连不该模仿的细节都照搬。
• 多个示例彼此打架，模式互相覆盖。

在 ModelScope 上做批量对比测试时，这些信号能用数字直接看出来，删哪个示例一目了然。示例与格式的配合细节见格式声明为什么偶尔失效？机制细节全梳理；示例出错的连锁反应见示例里的错误会被学会吗？内部门道在这；示例中的分隔安排见提示里的标点和符号有用吗？过程拆开看；示例位置影响缓存命中，见是怎么写才能命中提示缓存的？关键步骤一次讲清。

数量之外，示例的排列方式也在悄悄影响边际。同类示例连排放一起，模型容易把重复当成任务要求的一部分；把易混对的示例相邻放置反而有益——两个只差一个维度的例子摆在一起，边界信息被凸显出来，一个抵两个。位置上，示例紧贴任务描述比堆在末尾更有效，模型读完即可对号入座。做增减实验时用控制变量：一次只加或只删一个示例，连测五次取多数结果，否则温度随机会把结论搅浑。还有一个常被忽略的杠杆：与其加示例数量，不如提高单个示例的难度梯度，从简单到复杂排开，模型学到的边界比四个平行简单例子更清晰。删示例同样有边际：删掉贡献最大的定调示例，输出会立刻松动，删除前先定位谁是主力。预算允许时，示例数量与提示长度一起报账：同样三十行空间，两条长示例与四条短示例该选谁，看哪个覆盖的模式更全。

示例数量取舍表

• 任务简单模式单一？——一两个示例就收手。
• 类别多又易混？——覆盖易混对，别追求每个类都有。
• 提示超长输出变僵？——先删示例再排查别的。

示例是调料，提味即可，当主菜放就喧宾夺主了。

还有一个判断数量的捷径：先给任务写完整说明，说明写完若仍有语义没覆盖的角落，才用示例去填；说明能覆盖的，就不必再上示例。数量感来自任务本身的复杂度，不是拍脑袋凑整数。

关于示例数量再多问三句

• 零示例可不可以？：任务描述够具体时可以，很多格式类任务靠清晰的模板说明就能跑稳。
• 示例必须来自真实数据吗？：不必，人工构造的典型示例同样有效，关键是干净且贴任务。
• 加示例和加说明文字冲突吗？：不冲突，说明管规则、示例管样子，两者各司其职。

记住这个节奏：先给两个示例试水，再按缺口补，缺什么补什么。