少样本提示与示例

零样本、单样本、少样本。

零样本（zero-shot）只有指令——"对情感进行分类"。单样本（one-shot）加一个示范。少样本（few-shot）加若干个。模型不会被这些示例重新训练；它的权重毫无改变。它对这些示例的条件作用，与对任何其他令牌的条件作用一样——它们把下一批令牌的概率分布推向与所示范模式相匹配的输出。这就是上下文学习（in-context learning）：在推理时进行模式推断，而非训练。

Few-shot classification prompt:

Review: "Arrived broken and support ignored me."   Sentiment: negative
Review: "Works fine, nothing special."             Sentiment: neutral
Review: "Best purchase this year, flawless."       Sentiment: positive
Review: "Cheap feel but it does the job."          Sentiment:  <- model continues here

模型已经三次见过答案的确切形状。它几乎一定会输出 negative / neutral / positive 之一然后停下，因为这是该模式的要求。把这种可靠性与零样本提示对比：那时模型可能回"这整体看起来有点偏正面"。示例同时钉住了格式和标签空间。

何时示例胜过指令。

• 输出格式繁琐。某种特定 JSON 形状、某种特定引用风格、某种固定表格布局——演示一次远比用文字规定容易。
• 任务属于"一看就知道"。语气匹配、对边缘案例分类、套用某种隐性内部风格。决策边界存在于示例中，而非任何你能写出的规则里。
• 边缘情况行为必须钉死。放一个棘手输入及你想要的确切处理方式的示例，模型会从中泛化。
• 你想让标签空间被遵守。三个带标签的示例教会"只存在这些标签"，比"只用这些标签"这句话更可靠。

反之，如果一行指令在你的评测集上已经奏效，就别加示例。它们在每次调用都耗令牌，而不必要的示例会把模型行为收窄得超出你的本意。

挑选与排序示例。

覆盖优先于数量

三个精心挑选、横跨决策空间的示例，胜过十个近乎重复的。如果你有 A/B/C 三类，三类都展示。如果有一对臭名昭著易混的，放进那个能消歧的示例。这些示例是一个微型教学集——就按教学集来设计。

匹配真实分布

如果 90% 的生产输入又短又乱，而你的示例全是又长又干净，那模型被教的就是错误分布。从看起来像你实际会收到的输入里抽取示例。

顺序效应是真实的

模型对示例顺序敏感，最后一个示例有明显的拉动力（近因效应）。两个实际后果：别把某一类全放前面、另一类全放最后，否则会把预测偏向最后那一类；以及在 A/B 测试提示词时重新打乱顺序，以确保你测的是提示词，而不是某个排序伪影。

悄无声息的毒：一个错误示例。

少样本最大的风险不是示例太少——而是一个标错的示例。模型把你的示范当作真值。一个答案错误的示例会教出错误的模式，而且是隐形地：提示词看起来没问题，bug 只表现为某子集输入上的质量下降。

来自上下文学习研究的一个相关微妙之处：示例的格式与标签空间承载了大部分收益，有时甚至超过完全正确的内容。这不为草率标签开脱——错标签仍然有害——但它解释了为什么连展示对了形状的粗糙示例也很有帮助，以及为什么你的示例结构与其内容同样值得用心。

少样本在何处不再划算。

少样本很强大，但既非免费也非无限：

• 令牌成本每次调用都付。一个 12 示例块前置到每个请求，是真实的经常性花费和延迟。如果它是静态的，提示词缓存能收回大部分成本；如果它随请求变化，则不能。
• 收益递减。从 0→2 个示例常是一大跳；8→16 很少是。测量你的曲线在哪里变平，并在那里停。
• 它不增加知识。示例教的是模式，不是事实。如果任务需要模型缺乏的信息，那是检索问题（见 RAG 篇），不是少样本问题。试图用示例教一个知识库是范畴错误。
• 动态少样本是扩展之道。与其用固定块，不如从一个带标签的池中检索与当前输入最相似的少数示例。这让提示词保持精简、示例最大化相关——而且这字面上就是把检索施加于示范，将少样本与嵌入和向量搜索构件联系起来。