5.2 示例的选择与设计策略

少样本学习的效果很大程度上取决于示例的质量。精心设计的示例可以使模型快速理解任务，而不当的示例可能导致误解或偏差。本节将介绍示例选择和设计的关键策略。

5.2.1 优质示例的特征

1. 代表性

示例应该代表任务中常见的典型情况。

任务：客户咨询分类

✓ 代表性示例：
- 物流查询（高频）
- 产品咨询（高频）
- 退换货（中频）

✗ 非代表性示例：
- 投诉 CEO（极罕见）
- 请求定制产品（特殊情况）

2. 多样性

示例应该覆盖任务的不同类型或情况。

任务：情感分析

✓ 多样化示例集：
- 明确正面："非常满意，五星好评！"
- 明确负面："太差了，再也不买了。"
- 中性/混合："还行吧，没什么特别的。"
- 隐含情感："等了一周才到。"（隐含负面）

✗ 同质化示例：
- "很好"
- "挺好的"
- "非常好"
（都是正面，缺乏多样性）

3. 清晰性

示例本身应该是正确、清晰、无歧义的。

✓ 清晰的示例：
输入：今天上海的天气怎么样？
输出：{"intent": "weather_query", "location": "上海", "time": "今天"}

✗ 不清晰的示例：
输入：天气
输出：查询天气
（输入太模糊，输出格式不明确）

4. 一致性

所有示例应该遵循相同的格式和风格。

✓ 一致的格式：
示例 1：输入 → 输出 A 格式
示例 2：输入 → 输出 A 格式
示例 3：输入 → 输出 A 格式

✗ 不一致的格式：
示例 1：输入 → JSON 格式
示例 2：输入 → 纯文本
示例 3：输入 → Markdown 列表

5.2.2 示例数量的选择

理想数量

研究和实践表明，3-5 个示例通常是较好的选择：

1 个示例：可能不够，无法展示多样性
2-3 个示例：适合简单任务
4-6 个示例：适合复杂任务，覆盖更多情况
7+个示例：收益递减，需权衡 Token 成本

影响因素

任务复杂度：

• 简单任务（如格式转换）：2-3 个示例

• 中等任务（如分类、提取）：3-5 个示例

• 复杂任务（如多步骤推理）：5-6 个示例

类别数量：

• 如果是分类任务，每个类别至少包含一个示例

边界情况：

• 需要额外示例来展示边界情况的处理

5.2.3 示例的组织结构

标准结构

[系统/任务描述]

示例 1：
输入：[输入内容 1]
输出：[输出内容 1]

示例 2：
输入：[输入内容 2]
输出：[输出内容 2]

...

请处理：
输入：[待处理内容]
输出：

带分隔符的结构

任务：[任务描述]

===示例===

【用户】[示例输入 1]
【助手】[示例输出 1]

【用户】[示例输入 2]
【助手】[示例输出 2]

===待处理===

【用户】[待处理内容]

表格结构

对于映射类任务，表格格式清晰简洁：

请按以下映射规则转换：

| 输入 | 输出 |
|------|------|
| 红色 | red |
| 蓝色 | blue |
| 绿色 | green |

请转换：黄色

5.2.4 示例选择策略

策略 1：覆盖边界情况

特别为可能出错的边界情况提供示例：

任务：判断年龄是否成年（>=18 岁）

常规示例：
- 25 岁 → 成年
- 10 岁 → 未成年

边界示例（重要）：
- 18 岁 → 成年（边界值）
- 17 岁 → 未成年（边界值）
- 无年龄信息 → 无法判断（异常情况）

策略 2：平衡类别分布

分类任务中，尽量平衡各类别的示例数量：

三分类任务：情感正面/负面/中性

推荐：
- 正面示例：2 个
- 负面示例：2 个
- 中性示例：2 个

避免：
- 正面示例：5 个
- 负面示例：1 个
- 中性示例：0 个
（严重不平衡可能导致模型偏向多示例的类别）

策略 3：从简单到复杂

按复杂度顺序排列示例：

示例 1（简单）：
输入："很好"
输出：正面

示例 2（中等）：
输入："产品不错，就是配送慢了点"
输出：混合

示例 3（复杂）：
输入："说实话，之前看差评我还有点犹豫，但实际收到后觉得还行"
输出：正面

策略 4：包含负面示例

展示“不应该”怎么做可以帮助模型理解边界：

正确示例：
输入：帮我查一下北京到上海的航班
输出：{"intent": "flight_query", "from": "北京", "to": "上海"}

反例（展示不识别的情况）：
输入：今天真是开心
输出：{"intent": "chitchat", "from": null, "to": null}
（不是航班查询，无法提取地点信息）

5.2.5 示例设计的注意事项

避免过于简化

示例应该足够真实，接近实际输入的复杂度：

❌ 过于简化：
输入：好
输出：正面

✓ 真实场景：
输入：买了两周了，总体来说还可以，续航比预期要好
输出：正面

避免示例中的偏见

确保示例不会引导模型产生不当的偏见：

❌ 有偏见的示例集：
- 所有正面评价都是女性用户
- 所有负面评价都是男性用户

✓ 中立的示例集：
- 正面/负面评价与用户特征无关

避免泄露测试答案

如果在评估场景使用，确保示例与测试数据无关

5.2.6 动态示例选择

在实际应用中，可以根据待处理输入动态选择最相关的示例：

流程：
1. 接收用户输入
2. 从示例库中检索与输入最相似的 N 个示例
3. 将这些示例组装进提示词
4. 发送给模型处理

优势：
- 示例与当前任务高度相关
- 可以维护大型示例库，按需选取
- 提高处理效果

思考

1. 在您的领域中，为了防止模型犯某种特定错误，您会如何设计一个 负面示例 (Negative Example)？

2. 回顾您最近设计的一个提示词，检查其中的示例是否具备足够的代表性和多样性？如果不够，您计划如何改进？