Few-shot プロンプティングとは？例と使いどき

Few-shot プロンプティングとは、本当の入力を渡す前に、入力と望む答えを組にしたタスクの実例をいくつかモデルに見せることです。モデルはそのパターンを読み取り、続きを書きます。例は、言葉にしにくいことを固定するいちばん早い方法です。2つのカテゴリの境目がどこにあるか、出力の正確な形、チームの書き方などです。

Few-shot プロンプティングの仕組み

Brown らの2020年の論文「Language Models are Few-Shot Learners」は、GPT-3 がプロンプトに置かれた数個の実演から、再学習なしで新しいタスクを身につけられることを示しました。これを in-context learning（文脈内学習）と呼びます。モデル自体は何も変わらず、例が影響するのはそのプロンプトへの返答だけです。次回も、例はまたそこに置かれていなければなりません。

呼び名は例の数で決まります。Zero-shot プロンプトは例なし、One-shot プロンプトは1つ、Few-shot プロンプトは複数で、ふつうは2つから数個です。

Zero-shot と Few-shot を並べて比べる

下の2つのタブは、同じ指示で同じことを頼んでいます。違いは、2つ目のタブが本当のチケットの前にラベル付きの例を4つ加えていることだけです。

サポートチケットを bug、billing、account、feature_request のいずれかに分類してください。チケット：パスワードをリセットしたのに、新しいパスワードが使えません。何度やっても「認証情報が無効です」と出ます。

Try it

Example replyReplies vary between models and runs.

カテゴリ：bug

ユーザーはパスワードをリセットしましたが、ログイン時に新しいパスワードが拒否されています。これはパスワードリセットの処理に問題があることを示しているので、認証システムのバグである可能性が最も高いです。

例によって2つのことが変わりました。1つ目は形式です。Zero-shot の返答は太字の見出しと説明を付けましたが、Few-shot の返答は例に合わせて1語だけを返し、これならスクリプトがそのまま読めます。2つ目は判断です。「bug」はこのチケットの妥当な読み方で、多くの人がそれを選ぶでしょう。しかしこのチームはログインの問題を account に分類していて、3つ目の例が説明の言葉を1つも使わずにそれを伝えています。そのルールに触れた指示はどこにもなく、例がそれを運んだのです。

例はいくつ使うか

2〜5個から始めてください。たいていの形式指定や分類のタスクにはそれで十分で、プロンプトも短く保てます。

例が1つだと形式は伝わりますが、モデルはそれをまねしすぎる傾向があります。唯一の例が値上げについての30語の要約なら、次の要約も30語になり、妙にお金の話に偏るかもしれません。
違う例が2つか3つあれば、モデルは共通するもの（パターン）と変わるもの（細部）を見分けられます。
分類では、すべてのラベルについて少なくとも1つの例を入れ、そのうえで例なしで間違えた境界線上のケースを足します。
数個を超えると、たいてい効果は小さくなり、リクエストは毎回長くなって、トークンと時間を消費します。正しくさせるのに何十個も例が必要なら、そのタスクにはもっと明確な指示か、まったく別のアプローチが必要かもしれません。

良い例の選び方

モデルは、教えるつもりだったことだけでなく、例に共通するすべてのことから学びます。

難しいケースを入れる。 簡単な例から学べることはわずかです。最も役立つ例は、上のログインのチケットのように境界線上にあります。
表面をばらけさせる。 短い入力と長い入力、違う話題、違う言い回しを混ぜてください。例の中の肯定的なレビューがすべて短いと、モデルは長さを判断の手がかりにしてしまうかもしれません。
ラベルの偏りをなくし、順番を混ぜる。 モデルは、例の中で最もよく出てくるラベルと、最後に出てくるラベルに寄りがちです。
すべての例を確認する。 例の中の間違いは、その間違いをしなさいという指示になります。
本物の入力を使う。 実際のデータから取った例は、作り話の例よりもモデルが目にする入力にはるかによく合います。

形式は完全にそろえる

すべての例で、同じラベル、区切り、大文字小文字を使い、本当の入力も例の入力とまったく同じ見た目にしてください。チケットのプロンプトでは、各例が「チケット：」のあとに「ラベル：」という形で、プロンプトは空の「ラベル：」の行で終わっています。そのため、次に書くのが自然なことは1つしか残りません。

長い例は、<example> タグのような明確な目印で1つずつ囲み、どこで1つが終わって次が始まるのかがモデルにわかるようにします。区切り文字と XML タグを参照してください。API では、例を会話の前のほうのターンとして渡すこともできます。例の入力を持つユーザーメッセージと、答えを持つアシスタントメッセージを、例ごとに繰り返します。

Few-shot プロンプトは、再利用できるプロンプトテンプレートに向いています。指示と例は固定で、入力だけが変わります。下のブロックは、コミットメッセージをチームの書き方に書き直します。入力欄に自分のメッセージを入れ、例のパートをオフにして、書き方のどれだけを例が運んでいるかを確かめてください。

社内ルールに沿ったコミットメッセージ

Fill inメッセージ

Parts

コミットメッセージを私たちのチームの書き方に書き直してください。書き直したメッセージだけを返してください。

変更前：レポート画面にcsvエクスポートのやつを追加した変更後：feat(reports): CSV エクスポートを追加変更前：セキュリティ警告が出たので lodash 上げた変更後：chore(deps): セキュリティ勧告に対応するため lodash を更新変更前：カートが空のときにクラッシュするのを直しました！！変更後：fix(cart): カートが空のときのクラッシュを防止変更前：readme の誤字変更後：docs(readme): 誤字を修正

変更前：検索ボックスで大文字小文字を区別しないようにした変更後：

Try it

Example replyReplies vary between models and runs.

feat(search): 検索ボックスで大文字と小文字を区別しないように変更

ルールはどこにも書かれていません。小文字の type、括弧に入ったスコープ、「〜を追加」「〜を修正」のような言い切りの形、末尾に句点を付けないこと。例がこの4つすべてを示し、返答はそれに従っています。例をオフにしてもモデルはメッセージを改善しますが、書き方は推測するしかなく、その推測があなたのものと一致する保証はありません。

Few-shot の例は、答えだけでなく推論を示すこともできます。手順を見せる実例は、Chain-of-Thought プロンプティングが最初に紹介されたときの方法です。答える前に内部で推論するモデルでは、例は入力、答え、形式にとどめてください。台本どおりの推論ステップは、モデルをもっと良い道筋からそらすことがあり、提供元によってはそうしたモデルではまず Zero-shot を試すようすすめています。

よくある質問

Few-shot プロンプティングとは何ですか？

Few-shot プロンプティングとは、本当の入力の前に、入力と正しい出力を組にしたタスクの例をいくつかプロンプトに含めることです。モデルは例が作ったパターンを続けます。独自のカテゴリ、特殊な形式、社内の文体のように、説明するより見せるほうが早いものに最も役立ちます。

Few-shot プロンプトには例をいくつ入れればいいですか？

たいていのタスクでは2〜5個から始めるのがよいでしょう。分類なら、ラベルごとに少なくとも1つの例と、例なしでモデルが間違えた境界線上のケースを入れます。数個を超えると、例を1つ足すごとの効果はたいてい小さくなり、リクエストは毎回長くなります。

One-shot プロンプティングとは何ですか？

One-shot プロンプティングは、モデルにちょうど1つの例を与える方法です。形式を示すにはそれで十分ですが、モデルはその1つの例を、長さ、言い回し、話題まで含めてまねしすぎる傾向があります。2つ目の違う例があれば、どの特徴がパターンでどれが偶然なのかがモデルに伝わります。

モデルは私の例から学習するのですか？

今回のリクエストの中だけです。例はコンテキストの中にあることで返答を形づくりますが、モデルの重みは変わらず、次の会話では何も覚えていません。これを in-context learning（文脈内学習）と呼び、Few-shot プロンプトが使うたびに例を持ち歩かなければならないのはこのためです。

悪い例で出力が悪くなることはありますか？

あります。モデルは例に共通するものを何でもまねます。間違いや、意図していない長さやトーンもです。例の大半が同じラベルなら、モデルはそのラベルに寄りがちにもなります。例が正しく、多様で、偏りがないかを確認してください。