Few-shot 示例到底放几条？我的 3/5/7 法则

前年夏天做过一个电商评论情感分类的项目。客户要求不用微调，只能靠 prompt 解决。我最开始用零样本，就一句”判断下面这条评论是正面、负面还是中性”，跑了 500 条标注数据，准确率 68%。客户皱了皱眉，说能不能再高点。

我加了 3 条示例进去，升到 81%。再加到 5 条，到 89%。客户说够了够了，上线。

后来我自己出于好奇，又加到 10 条示例，心想应该能冲到 92%？结果掉回了 85%。

当时我特别费解。加示例不是应该让模型学得更好吗？为什么到一定程度后会倒退？

这个问题我花了大半年才摸清楚。这篇就说说我现在怎么定 few-shot 的数量。

先讲那个倒退曲线

这事其实有道理的。Few-shot 的本质是”上下文学习”（in-context learning），模型在推理时动态地从你给的例子里提炼模式。但提炼是有极限的——示例太多，会发生两件事：

第一，示例之间的细微不一致被放大。你自己写 10 条示例，总有几条风格或边界判断不完全一样。模型会把这些”不一致”也当成信号，结果反而变得犹豫。

第二，上下文长度增加，对任务本身的注意力被稀释。尤其在长文档场景下更明显。

所以 few-shot 不是”越多越好”。是有个甜蜜点，过了就掉头。

我现在用的 3/5/7 法则

这个法则不是啥标准答案，是我在实际项目里反复校准出来的经验值。不同任务类型，甜蜜点位置不一样：

3 条：分类任务 + 风格迁移

情感分类、意图识别、打标签、改写成某种特定文风——这类任务的特点是”模式相对简单，但边界需要锚定”。

3 条示例基本够了。一条典型正例、一条典型负例、一条边界模糊的。这样模型就明白了你的判定规则在哪。

再多加也没啥用。你加第四条、第五条多半是在重复前三条的模式，对模型来说是冗余信号。

5 条：结构化抽取

从长文本里抽字段、从邮件里提关键信息、从合同里找条款——这类任务需要模型学会”看哪里”和”怎么填”。

5 条示例里我通常这样配：2 条标准样例、2 条包含噪声或歧义的、1 条字段缺失或需要”填 null”的。覆盖主流情况 + 典型异常，再多就多余了。

7 条：复杂推理 / 多步决策

比如多跳问答、合规判断（需要组合多条规则）、代码评审这种需要”先看整体再判断细节”的任务。

7 条示例里，我会确保每条示例的”推理路径”都不一样——不是换输入，是换思考路径。让模型看到”哦原来这类问题可以这么想、也可以那么想”。

超过 7 条我基本就不加了。要么升级到带 <thinking> 的链式推理（这个在思考还是直接给答案那篇里细说），要么考虑微调或者上更强的模型。

示例顺序的讲究

这是个容易被忽略的点。同样 5 条示例，顺序不同效果能差 3-5 个百分点。

我摸出来的规律：最相关、最典型的那条放最后。Claude 的注意力对”刚刚看到的内容”是有偏向的（这事叫 recency bias），放最后的示例在生成时的权重明显更高。

所以我现在的排法大致是：

先放几条”覆盖各种情况”的杂样例
中间放”边界案例”
最后放一条和当前待处理输入最相似的

有时候如果我能动态检索，还会做个”相似度召回”，用检索到的最相似 case 作为最后一条示例。这套手法在 RAG 项目里特别好使。

示例写太好，反而拉低平均

这点我踩过大坑。

有次给一个客服改写项目写示例，我特别认真地把每条都润色得又专业又亲切。结果上线一测，发现模型在处理比较随意的用户投诉时，输出也变得很客套很书面——用户反馈说”像在跟机器人讲话”。

把示例里两条换成稍微”粗糙”一点的真实样本，口吻立刻松下来了，用户满意度反而上去了。

所以：示例的质量是”代表性”，不是”完美”。你的真实输入有多杂，示例就该有多杂。不要把示例全写成你梦里希望的那种理想形态，模型会照着做，然后在处理现实世界输入时别扭得要命。

输入输出对齐的格式

Few-shot 的格式写法我建议用 XML 标签成对包装，比 “Q:… A:…” 这种冒号式更稳定。为啥 Claude 特别吃 XML，这篇专门讲过。

典型写法：

<example>
  <input>用户评论：这破玩意儿用了三天就坏了</input>
  <output>负面</output>
</example>

<example>
  <input>用户评论：还行吧，没啥特别感觉</input>
  <output>中性</output>
</example>

<example>
  <input>用户评论：冲着品牌买的，用起来确实比便宜货强</input>
  <output>正面</output>
</example>

<task>
请判断下面这条评论的情感：
{用户输入}
</task>

格式统一、标签闭合、最后一条是最典型的。

0-shot vs Few-shot 怎么选

不是所有任务都需要 few-shot。我的判断标准：

能 0-shot 就 0-shot。Claude 的 zero-shot 能力本身就很强，简单任务加示例是浪费 token、拖慢响应。

什么时候需要 few-shot？

任务有”主观判断”的成分（比如风格分类）
期望输出有特定格式且不容易用自然语言描述清楚
边界情况多，光靠规则说不清楚
你试了 0-shot 结果准确率差 5 个百分点以上

先 0-shot 测一轮，拿到 baseline，再决定要不要加示例。有些人上来就怼 10 条例子，既浪费 token 也错过了真实性能评估。

我开头那个 68%→89% 到底怎么拆的

回到那个情感分类项目。我当时加示例的具体步骤，给大家看下：

第 1 条：一个明显负面但用词委婉的（让模型学会看”言外之意”）
第 2 条：一个表面夸实则讽刺的（中文里特别多这种）
第 3 条：一个情感混合的，判定为中性（教它怎么处理混合情感）
第 4 条：一个带脏话的负面（锚定”脏话≠一定是差评”的边界）
第 5 条：和当前测试集分布最接近的一条标准负面

每加一条都带来 2-5 个点的提升。到第 5 条时覆盖了主要 edge case，再往上加就开始触发前面说的”不一致被放大”现象。

一些零碎经验

示例里的输入尽量匿名化。别写真实用户名、真实公司名，容易让模型”记住”导致偏差。
输出格式在示例和最终任务里必须一致。你示例里是一个词，任务要求一段话，模型会精分。
示例本身也会走 prompt caching。如果你的示例长期固定，可以让它进缓存，省下不少钱。缓存机制我在这篇里拆过。
不同模型的甜蜜点不同。Haiku 对示例更敏感、可能 7 条都嫌少；Opus 自身推理强、3 条可能就够。Claude 家族那篇里有模型选型的讨论。

最后

Few-shot 这事说玄乎也玄乎——同样的示例换个顺序都能差好几个点。说朴素也朴素——你给模型看的就是它学到的，你示例写得糙，模型就糙。

3/5/7 不是铁律，是个起点。拿这个数字去试，根据你自己的评估集往上调或往下调 1-2 条。这个过程才是 prompt 工程的本体，不是套公式。