Few-shotプロンプティング：実践ガイド

言語モデルと取り組んでいると、指示が役に立たなくなり、例が効き始める瞬間があります。タスクを三通りに説明したのに、モデルはまだ書式をわずかに間違えたり、例外を取りこぼしたり、出力の体裁を不揃いにしたりする。直し方はたいてい、より良い説明の段落ではなく――良い答えがどう見えるかをモデルに示すことです。それがfew-shotプロンプティングであり、うまくやれば、手にできる最も信頼できる道具の一つです。

なぜ例は説明に勝るのか

指示はパターンを記述します。例はそれを実演します。この違いが重要なのは、実演が、記述では残ってしまう曖昧さを取り除くからです。「日付を月、日、年の順に整える」は、なお十数の選択を残します――カンマの有無、月の略記、ゼロ詰め。狙いどおりの出力をぴったり示す一つの例が、気にする細部を一つひとつ列挙せずとも、それらすべてを一度に決着させます。

これが効くのは、モデルが文脈の最も尤もらしい続きを生成するからです。その文脈に、入力とそれに対する正しい出力のきれいな例が二つか三つ含まれていれば、新しい入力に対する最も尤もらしい続きは、確立されたパターンに一致する出力になります。あなたはモデルに新しい技能を教えているというより、答えの形を自明にしているのです。例が明快で一貫しているほど、形は自明になります。

ゼロショット、ワンショット、そしてもっと必要なとき

まずは例ゼロから始めましょう。タスクが単純で、モデルが指示だけからすでにうまくこなすなら、例はただのトークンと遅延の無駄です。多くのタスクは本当にそれを必要としません。ゼロショットの出力が不揃いだったり、書式を間違えたり、ある種の入力で失敗したりするとき、例に手を伸ばしましょう。

良い例が一つあれば、しばしばそれだけで書式の問題が直ります――散文が伝えあぐねる構造を釘付けにするからです。タスクにモデルが見ておくべき多様性があるとき、二つ目、三つ目を加えましょう。異なる入力の種類、ある例外、「答えなし」のケース。ひと握りを越えると、たいてい収穫逓減にぶつかります。例が増えるほどコストがかさみ、パターンが明らかになった後はめったに足しになりません。正しい数は、収まる限りの最大のセットではなく、パターンを曖昧でなくする最小のセットです。

現実を代表する例を選ぶ

最大の誤りは、どれも簡単な例を選ぶことです。すべての例が、きれいで整った入力から自明な答えが出る様子を示していたら、あなたはモデルに簡単な道だけを教え、それ以外を何も教えていません。すると乱雑な実際の入力がやって来て、モデルには頼れる実演された振る舞いがありません。例は、もっときれいだったらと願う部分も含め、実際のデータのように見えるべきです。

重要なケースを意図して含めましょう。一部の入力が「分かりません」や空の結果を生むべきなら、まさにそうする例を示しましょう――さもないとモデルは、どの入力にも自信ある答えが出ると学んでしまいます。間違えやすいカテゴリがあるなら、一つ含めましょう。例はカリキュラムです。モデルがどのみち成功したであろう状況ではなく、放っておけばつまずく状況を覆うよう選びましょう。

例どうしの一貫性を保つ

例はパターンで教えるので、例どうしの矛盾は積極的に有害です。一つの例がリストをダッシュで整え、別の例が番号で整えれば、あなたはモデルにどちらも許容されると教え、モデルはそれらを混ぜます。一つの例が推論のステップを含み、別の例が答えに直行すれば、モデルはどちらを望まれているか分かりません。すべての例は、小さな細部に至るまで、書式、トーン、構造で一致すべきです。

この一貫性は、例と実際の入力の境界にまで及びます。例と、末尾に付け足す実際のタスクとで、同じラベル、同じ区切り、同じレイアウトを使いましょう。モデルは新しい入力を、確立された連なりの次の項目として、それまでと同一に整えられたものとして見るべきです。例と実際の入力の間の視覚的な切れ目はどれも、パターンが滑り落ちる隙です。

境界が明らかになるよう整える

few-shotプロンプトは、ある例がどこで終わり次が始まるのか、あるいは例がどこで止まり実際のタスクが始まるのかをモデルが見分けられないとき、失敗します。それらの境界を紛れもなくしましょう。各部にラベルを付け――入力には明確な印、出力には明確な印――その同じ構造をすべての例で繰り返しましょう。一貫した区切りは、テキストの壁を、モデルが延長できる読みやすい連なりに変えます。

この構造はまた、ある微妙な失敗からも守ります。入力の内容が指示へ滲み出すことです。例が明確に区切られていれば、たまたま命令のように見える内容も、ラベルの付いた枠の中にとどまり、データとして扱われます。すべてが地続きで流れていると、モデルは入力を指示と読み違えやすくなります。ここではわずかな書式の規律が、大きな信頼性をもたらし、しかもほとんどコストがかかりません。

一つのケースではなく、セットに対して反復する

すべてのプロンプティングと同じく、few-shotの作業は、実際の入力にわたって持ちこたえて初めて完成します。一つの印象的なケースが完璧に動くまで例をいじりたくなりますが、その一つのケースはデモであって、測定ではありません。多様な実際の入力のセットを集め、few-shotプロンプトをそのすべてに対して走らせ、例が防ぐはずだった失敗がないか結果を読みましょう。

一度に一つだけ変えましょう。例を一つ差し替える、取りこぼし続ける例外を加える、矛盾を一つ直す、それから再びセット全体を走らせて比べる。役立つと思っていた例が、実はモデルを間違ったパターンへ繋ぎ止めていて、取り除くと改善する、と気づくこともあります。すべてのテスト入力にわたって最もよく機能する例のセットを保ち、例のセットを、一度書くものではなく、保守するものとして扱いましょう。

まとめ

few-shotプロンプティングが効くのは、実演が記述より明快だからです。指示だけでは出力が不揃いになるとき使い、パターンを曖昧でなくする最少の例を使いましょう。実際のデータのように見える例を――例外や「答えなし」のケースも含めて――選び、例どうしの一貫性を保ち、モデルがきれいな連なりとして読むよう境界を整えましょう。それから、一つのデモではなく、実際の入力のセットに対して証明しましょう。よく選ばれた一貫した例がひと握りあれば、書式と例外こそが重要なタスクにおいて、何段落もの指示を上回ります。