Few-shot promptingとは？例を見せてもモデルの重みは変わらない
LLMへ「分類して」とだけ頼むと、ラベル名や答えの書式が揺れることがある。Few-shot promptingは、解いてほしい入力の前に、同じ形式の入出力例を少数置く方法だ。モデルはその例を文脈として参照して続きの出力を作るが、通常の推論では重みを更新しない。
名前に「学習」が付くIn-context Learningとも呼ばれるため、Instruction Tuningと混同しやすい。前者は今回の入力に例を含める操作、後者は例を使ってモデルの重みを調整する工程だ。同じ例文を見せても、どちらを行っているかで、その効果が持続する範囲は違う。
例は「答え」だけでなく、入出力の形を示す
次は説明用の感情分類だ。ラベルを「好意的」「否定的」の2種類に決め、2例を置いてから新しい入力を続ける。
次の短文を「好意的」か「否定的」に分類する。答えはラベルのみ。
短文: 使いやすくて助かった。分類: 好意的
短文: 説明が分かりづらかった。分類: 否定的
短文: 操作が簡単で迷わなかった。分類:期待する出力は「好意的」だ。ここで例が伝えているのは、判断の方向だけではない。ラベルの候補、入力と出力の区切り、余計な説明を付けない書式も示している。この3文は説明用に作ったもので、特定のモデルの実行結果ではない。
GPT-3論文は、タスクの説明と複数の例を入力文脈へ入れ、追加の勾配更新や微調整をせずに評価した。例をゼロ個にするzero-shot、1個にするone-shot、複数にするfew-shotを区別している。指示文だけで十分な場合もあるため、例を増やすこと自体を目的にしない。
例の内容と形式を分けて考える
何が効いているのかを調べる研究では、単に「正しい答えを2件見せたから、モデルがその場で分類規則を覚えた」とは言い切れない。Minらの『Rethinking the Role of Demonstrations』は、実験した設定で、入力の分布、ラベルの候補、例全体の形式が性能に重要であることを示した。例とラベルの正しい対応だけが唯一の要因ではなかった。
ただし、この結果は「間違ったラベルを例に入れてよい」という実務上の推奨ではない。誤った見本は利用者に誤解を与えるうえ、モデルやタスクが変われば影響も変わる。公開するプロンプトでは、正しい例と一貫した書式を使い、例を入れない場合との比較で効果を確かめたい。
Context Windowにも費用を払う
Few-shotの例は毎回入力に含まれるので、そのぶんContext Windowを使う。長い例を大量に追加すると、肝心の質問や参照資料、回答のための余裕が減る。分類なら、代表的な成功例だけでなく、紛らわしい境界例を少数入れるほうが有用な場合がある。どの例が効くかは、例の数だけでなく、入力との近さや出力の一貫性で評価する。
また、プロンプト内の例はその入力に対する一時的な文脈であり、別の会話へ自動的に持ち越される学習結果ではない。継続的に同じ振る舞いが必要なら、アプリ側で必要な例を毎回渡すか、別途モデルの調整を検討する。Few-shot promptingとInstruction Tuningの境界は、重みを更新したかどうかにある。