跳到主要内容

把少样本示例用对

进阶
What you'll learn
  • 什么是少样本提示，以及为什么示例胜过描述
  • 如何读懂一条让模型来补完的清爽少样本提示
  • 如何挑选、格式化并排序示例（包括边缘情况）
  • 什么时候选用零样本，什么时候选用少样本
  • 为什么一个马虎的示例比没有示例更糟

少样本提示是指在让模型处理一个新例子之前，先给它看几个做好的任务范例。做得好的话，这是锁定某种格式、风格或边缘情况行为的最快方式——往往比用语言描述你想要什么更有效。

为什么示例胜过描述​

"简洁而友好"很含糊。展示两份简洁、友好的输出则毫不含糊。模型会对这些示例进行模式匹配，并延续这个模式。

一条清爽的少样本提示词​

注意它的形态：几组格式完全相同的 Message → Label 配对，然后是最后一条带着空 Label: 的消息，留给模型来填。

少样本分类提示词

Classify each support message as: billing, bug, or feature.

Message: "I was charged twice this month."
Label: billing

Message: "The app crashes when I upload a photo."
Label: bug

Message: "Can you add dark mode?"
Label: feature

Message: "My subscription renewed at the wrong price."
Label:

模型掌握了这个模式；它会把最后一行补完。

如何挑选与格式化示例​

Guided walkthrough1 of 5
  1. 把你在意的边缘情况包含进来。如果某个类别罕见或棘手，就把它包含进来。

上面提到的 token 成本是实打实的——参见 Token 与上下文。至于分隔符做法，XML 标签是干净、可靠的分隔方式。

零样本对比少样本​

先试试零样本（直接提问）——现代模型很强。当你需要某种特定的格式／风格，或任务含糊不清时，再加上示例。如果零样本已经做得很到位，就不必为示例买单。

Pro tip
  • 示例就是数据——保持它们干净。一个错误或马虎的示例会主动教出错误的东西。要像对待训练数据一样去精心筛选它们。
Key takeaways
  • 展示，而非描述：做好的范例胜过含糊的描述。
  • 覆盖多样性，尤其是边缘情况，并让每个示例都保持完全相同的格式。
  • 2 到 5 个示例通常就够了；更多可能过拟合并消耗 token。
  • 顺序很重要——最清晰的放最前面，不要把同一标签聚在一起。
  • 从零样本开始；只在需要特定格式／风格或任务含糊时才加上示例。

自我检测

0/5
  1. 为什么示例往往胜过像“简洁而友好”这样的文字描述？
  2. 对一条少样本提示来说，多少个示例“往往就够了”？
  3. 对于分类任务，应该如何排序示例？
  4. 什么时候应该优先选用零样本而不是少样本？
  5. 一个马虎或错误的示例有什么风险？

下一步​