LLMFew-shotPrompt Engineering评测工程化
Few-shot 示例怎么选：覆盖率与干扰项平衡（从经验到可评测策略）
Few-shot 不等于“多放几个例子”。示例选得好，模型输出稳定且可控；选得差，会引入风格污染、规则漂移、甚至让模型学到错误模式。本文给出一个可复用的示例选择框架：先定义任务子空间，再做覆盖与难例，再控制干扰项与顺序偏置，最后用离线评测与在线指标验证收益。
2026年3月4日
Synthly 团队
预计阅读 15 分钟
📷 Photo by Alessia Lorenzi via Pexels
先给结论：Few-shot 的目标是“降低方差”，不是“让模型模仿文案”
如果你把 Few-shot 当作“给模型抄作业”，你会得到：
- 输出更像示例，但不一定更对
- 输入稍微变化就崩
- 规则越堆越乱
更正确的目标是：
用少量示例把任务空间的关键边界讲清，让模型在新输入上更稳定。
一、先定义任务子空间：你到底要覆盖什么？
示例选择的第一步不是找例子，而是把任务拆成子空间（bucket）。
举例：如果任务是“把用户需求转成结构化 JSON”，子空间可能包括：
- 信息完整 vs 信息缺失（需要追问）
- 单一实体 vs 多实体
- 约束冲突（用户要求互相矛盾）
- 风险动作（写操作/敏感字段）
你至少要覆盖 3-5 个最常见 bucket。
没有子空间，就没有覆盖率。
二、覆盖与难例：示例要“代表性”，也要“边界性”
1）代表性示例：覆盖主流分布
来自真实流量的 top 场景，输出要符合你定义的“输出合同”。
2）边界示例：覆盖最容易翻车的地方
边界示例往往更值钱：
- 缺字段 → 追问
- 冲突约束 → 拒绝或澄清
- 工具失败 → 降级
这些示例能显著降低线上事故概率。
三、控制干扰项：示例里最危险的不是错误答案，而是“错误习惯”
你需要刻意清除或固定以下干扰项：
- 语气与冗余解释（会污染风格）
- 不一致字段（会造成字段漂移）
- 隐含假设（会让模型编造）
- 特定格式细节（会让模型死记模板）
一个简单原则：
示例只展示你想让模型学到的“结构与决策”，其他都尽量最小化。
四、顺序与权重：别忽视近因效应
工程上常见现象：
- 最后一个示例会被模型过度参考
- 某个示例的特殊情况被当成通用规则
建议：
- 把最关键的“规则示例”放在靠后位置
- 把最容易被误泛化的特殊例子放在靠前并显式标注“仅适用于…”
- 必要时用小标题标出 bucket（让模型知道这是分类）
五、让 Few-shot 可评测：用数据而不是感觉
1）离线评测集：覆盖 bucket + 难例
准备一个评测集：
- 每个 bucket 20-50 条
- 真实输入为主
- 标注“通过/失败原因”
2）对照实验：一次只改一个变量
例如：
- 增加一个边界示例
- 调整示例顺序
- 删除一段解释性文案
然后观察：
- 通过率
- 输出方差（格式漂移次数）
- 追问正确率
- token 成本
3）线上指标：别只看“感觉更像人”
建议至少跟踪：
- 任务完成率
- 返工率/用户纠正次数
- p95 延迟
- token 成本
六、一个可复用的示例选择流程（你可以照着做）
- 定义输出合同（字段、枚举、失败与追问）
- 把任务分 bucket（3-5 个）
- 从真实流量挑代表性示例（覆盖分布）
- 补齐边界示例（覆盖翻车点）
- 清理干扰项（字段一致、文案最小）
- 固定顺序并做对照评测（验证顺序偏置）
- 灰度上线并持续回写样本（形成闭环）
如果你想看“提示词系统化”的整体框架，可结合：
常见问题
Few-shot 与 RAG 谁更重要？
它们解决的问题不同：Few-shot 更像“行为约束与输出模板”，RAG 更像“事实补全”。工程上常见组合是：
- Few-shot 固定输出合同与决策结构
- RAG 提供可引用的事实证据
能不能用自动方法选示例？
可以。常见方法是：
- 先用语义相似召回候选示例
- 再做多样性约束（避免全是同一类）
- 最后用离线评测筛选
但无论是否自动化，评测闭环是关键。