少样本提示如何选例、配比与排序

给提示词塞几条示例，模型到底学到了什么？原文借三篇论文给出一个提醒：在研究覆盖的分类和选择题任务里，少样本提示（few-shot prompting）的作用，很大一部分是告诉模型输入长什么样、答案有哪些、应该怎样输出，而不只是传递正确答案。

更容易被忽略的是，模型还会跟着示例的类别比例和排列顺序走。对用 AI 做工单分类、反馈分流的开发者来说，示例应该当作需要验证的配置，模型升级后也要重新检查。

示例首先教会模型怎样答题

Min 等人在 2022 年的研究中，测试了包括 GPT-3 在内的 12 个模型，任务覆盖分类和多项选择。研究者把示例里的正确标签换成随机标签后，性能下降大多只有 0–5 个百分点。

这不是说答案可以随便写，而是提示我们：示例还在传递三类信息。

第一是标签空间，也就是允许输出哪些答案。第二是输入分布，即真实请求通常长什么样。把示例换成与任务不相符的文本后，多个模型的表现下降了 3–16 个百分点。第三是格式：每次都按照相同方式，把输入和标签配在一起。去掉这种配对结构后，效果接近甚至差于完全不给示例。

对这些任务，示例首先是一份格式约定和合法答案清单。

该研究还发现，示例达到约 8 条或更多后，收益趋于平缓。原文据此建议，优先选接近生产输入、格式统一的示例，别靠重复堆数量。

但边界必须留着：同一论文中，部分数据集的差距更大；原文也提到，后续研究发现故意给错标签会损害效果。因此，「随机标签影响有限」不能推导成「正确标签不重要」。

类别比例和最后几条示例，会悄悄改变答案

Zhao 等人在 2021 年的研究中，发现了三种偏差：模型偏向示例中占多数的标签，偏向靠后的标签，也偏向预训练数据里更常见的答案词。

其中一个 4-shot 情感分类设置尤其反直觉：示例依次是「Positive、Positive、Positive、Negative」，模型最后却给出了接近 90% 的 Negative 预测。前三条占多数，也没挡住最后一条的影响。

同一研究中，只调整示例顺序，某个情感任务的准确率就从 54.3% 变到了 93.4%。增加示例数量，也没有稳定消除这种波动。

下面这组工单示例的问题，是类别覆盖和比例都不完整：

Ticket: "Card charged twice" -> billing
Ticket: "Refund not received" -> billing
Ticket: "Invoice has wrong GST" -> billing
Ticket: "App crashes on login" -> bug

要留意前三行连续出现的 billing：它容易成为默认选择，而 feature_request 和 other 根本没有露面。

原文给出的调整，同时展示了四个类别，并用统一标签包住每条示例：

<example>Ticket: "App crashes on login" -> bug</example>
<example>Ticket: "Card charged twice" -> billing</example>
<example>Ticket: "Please add dark mode" -> feature_request</example>
<example>Ticket: "What are your office hours?" -> other</example>

要留意第四行：other 为无法归入业务类别的输入提供了出口。每行的 <example> 则把示例边界标了出来，这是原文引用 Anthropic 文档建议的做法。

原文没有给出这两组工单提示的实测对照，所以它们说明的是改进思路，不能据此宣称准确率已经提升。

为什么换模型后，示例顺序也要重测

Lu 等人在 2022 年的研究中，遍历了同样四条示例的全部 24 种排列。有些排列的准确率接近当时最佳水平，有些却接近随机猜测。

更麻烦的是，好顺序不能直接跨模型复用。某种排列仅仅换了模型规模，准确率就从 88.7% 掉到 51.6%。

因此，提示词文本没有改，不代表行为就稳定。模型换了，示例顺序的效果也可能变。

原文建议从少量、多样、相关的示例起步。它引用的 Anthropic 指南推荐先用 3–5 条，再拿评估集测试两三种排列。如果准确率明显波动，至少能在上线前发现提示词对顺序过于敏感。

这里的评估集，就是一批预先确定正确答案的真实或近似真实输入。固定它，才能判断变化来自提示词，还是来自测试样本不同。

我的判断

我赞同作者把注意力从「多塞几条」转向格式、覆盖、比例和评估。这些因素容易检查，也比凭感觉挑示例更便于团队协作。

但标题里的「教格式，不教事实」需要收窄理解。原文主要证据来自分类和选择题，不能直接外推到复杂代码生成、业务规则推理或知识问答。示例中的事实、规则和正确实现，在这些任务里可能十分关键。

「每类一条、均衡交错」适合作为起点，也不是最终答案。类别很多时，覆盖全部标签会和少量示例的建议冲突；真实业务的类别比例，也未必适合直接复制进提示词。原文没有给出这些取舍的对照数据，需要按自己的错误成本验证。

此外，随机打乱可以用于检查顺序敏感性，却不能保证每个顺序都好。把验证过的顺序固定下来，保留模型和提示词版本，更方便定位回归。

能拿来做什么

• 给前端反馈分流或 Node 工单分类接入 AI 时，先写清允许输出的标签，并检查示例是否覆盖 other、none 或 not applicable 等出口，避免只展示最常见的业务类别。
• 从实际请求中选出少量不同类型的输入，保留真实措辞和杂乱表达，同时统一分隔符、字段名和输出格式；可以从 3–5 条开始验证。
• 固定一批带正确标签的评估输入，对同组示例测试两三种顺序，检查总体准确率以及各类别的误判，确认结果是否明显波动。
• 切换模型或模型规模时，把示例顺序一起纳入回归检查，不要直接沿用上一次手工挑出的最佳排列。