少样本:塞几个例子,以及一个被忽略的收益

实测:0 / 2 / 5 个例子

同一评测集、同一规则版提示词,只改示例数量(示例全部取自评测集之外,避免"泄题"),各跑 3 轮:

示例数     均分        抖动        平均token     提示词字数
0       17.3      0.47      2788        196
2       18.0      0.00      3547        273
5       18.0      0.00      4567        378

2 例 vs 0 例:分数 +0.7,token +27%
5 例 vs 0 例:分数 +0.7,token +64%

三个结论:

① 加 2 个例子:分数 +0.7,而且抖动从 0.47 变成 0。 看三轮原始分数:0 例是 [18, 17, 17],2 例是 [18, 18, 18]——每轮都一样。这个"稳定性收益"在很多场景里比涨分更重要:用户不会因为你平均分高而满意,会因为"同样的问题今天这样答明天那样答"而流失。

② 从 2 个加到 5 个:分数一分没涨,成本从 +27% 涨到 +64%。 又是一次"边际收益归零"(这门课第三次撞到了)。2-3 个通常就够,尤其当规则已经写清楚时。

③ 例子会挤占上下文、还可能带偏。 5 个例子如果都是同一类,模型会过度倾向那一类。所以例子要覆盖不同类别、包含边界,而不是随手挑五个最简单的。

什么时候该用少样本

进阶:动态挑例子

固定塞 2 个例子是"静态少样本"。更聪明的做法:根据用户这次的输入,动态挑最相似的 2 个例子塞进去。

思路很简单:把你的例子库做成向量索引(AP4 的 RAG 技术),每次检索最相近的 2-3 条当示例。适合类别特别多(比如 50 个工单类型)的场景——固定示例覆盖不过来,动态挑总能给到"最像的那几个"。

⚠️ 但要记住 ap1.4 的教训:动态示例每次不同 = 前缀变了 = 缓存失效。所以结构上要把"固定不变的规则"放最前面,动态示例放后面,至少保住前半段的缓存。

🔧 动手做:找到你的示例甜区(12 分钟)

1. 跑本节代码 fewshot.py,看你自己的 0/2/5 对比。
2. 重点看抖动(标准差)那一列:加了例子后,你的分数变稳了吗?
3. 换成你的场景:用你毕业方向的评测集重跑——如果你的任务偏"风格/语气"类,大概率会看到比这次更大的提分。
4. 做一次坏例子实验:故意把 5 个例子全换成同一类(比如全是"投诉"),重跑——观察模型是不是开始把什么都往那一类归。
5. 定下你的配置:几个例子、选哪几个、放在提示词的什么位置(记得缓存友好)。

✅ 做到这里你应该有:你任务上的示例数量决策 + 一次"坏例子"的直观教训。

为什么:少样本是性价比很高但容易过量的手段。有评测的人能找到甜区(2-3 个),没评测的人会一路加到十几个——分数没涨,每次调用都在多付钱。这一节真正教的不是"塞例子",是"用数据决定塞几个"。

我的任务是【描述】,类别/输出形态有【列出】。请帮我设计少样本示例:1) 该给几个(说明理由);2) 每个示例覆盖什么情况(要含边界,不要都是简单样本);3) 示例放在提示词的哪个位置最利于缓存(不变的在前);4) 提醒我哪些内容绝对不能当示例(避免泄题)。