フューショットプロンプティングとは
フューショットプロンプティングとは、言語モデルにプロンプト内で少数の例を示し、タスクや応答のパターンを伝える方法です。例は、今回のリクエストに与えるコンテキストであり、それ自体がモデルの学習を更新するわけではありません。分類の境界、抽出のルール、望ましい文章の形式などを示せます。
執筆：Ai Flowi · 公開日
例の価値は、何を明確にするかにあります。本当の難しさが似た2つのラベルの区別にあるなら、簡単なケースを繰り返してもあまり役に立ちません。有用なフューショットのプロンプトは、境界付近のケースを示し、評価には別の質問を残します。そうすることで、見かけ上の成功が、既に含まれていた答えの繰り返しにすぎない状況を避けられます。
Few-shotで例なし、1例、複数例の違いは何ですか？
例なしのプロンプトは、実例を示さずに指示します。例えば「各依頼をaccess、fault、unclearに分類してください」と伝えます。1つの実例では、入力とその正解ラベルを示します。複数の実例では、確認を求めるのが正しいケースも含めて、それぞれのラベルをどう適用するかを示せます。
これらはプロンプト設計の選択肢であり、方法の普遍的な優劣を示すものではありません。単純なタスクなら、明確な定義だけで十分な場合があります。表現に解釈の余地が残り、境界を実例で示すことで解消できる場合には、例が役立ちます。ただし、入力テキストが増え、意図しない近道を学ばせてしまうこともあります。
制約の設計と出力評価を含む広い分野については、プロンプトエンジニアリングを参照してください。このページでは、プロンプトのコンポーネント設定を繰り返すのではなく、実例の選び方を中心に扱います。
架空の依頼分類の例
社内ヘルプデスクが、例示用の3つのラベルを使うとします。accessは、権限やアカウントを必要としていることを意味します。faultは、以前は使えていたものが動作しなくなったことを意味します。unclearは、どちらのラベルを選ぶにも根拠が足りないことを意味します。これらは例のための定義であり、実際の顧客業務の定義ではありません。
構成例であり、記録されたテストではありません。以下の実例は、モデル接続を設定せずにプロンプトの内容を示しています。
Instruction: classify the request using its stated facts.
Labels: access, fault, unclear.
Request: Please give me access to the design folder.
Label: access
Request: My existing folder access worked yesterday but fails now.
Label: fault
Request: I need help with the design folder.
Label: unclear
New request: [supply a separate request here]上記の正解ラベルは、この記事で作成した実例であり、観測されたモデルの結果ではありません。「アクセス権をください」と「既存のアクセスが失敗する」の対比が、有用な境界を示します。すべての例にフォルダーという名詞が出てくるので、その名詞自体がカテゴリを決めるべきではありません。
出力の契約は、ラベルと、依頼に結び付いた短い理由という控えめなものにします。後でJSONオブジェクトが必要になった場合は、必要な構造を別途指定してください。整った形式の例を示しても、以降のすべての出力が有効で、意味的にも正しいとは保証できません。
例と反例を意図的に選ぶ
簡単にラベルを付けられる例だけでなく、難しい入力に似た例を含めます。「ページにアクセス拒否と表示される」という依頼は、以前アクセスできていたかによって、権限不足にも不具合にも該当し得ます。unclearの実例を使い、不確実であることも許容される結果だと示してください。
反例は、推測してはいけないことを示せます。「来週アクセスできるようにしたい」という依頼は、既にアカウントが壊れていることを示しません。正解となる判断を一貫して説明してください。そうしないと、モデルは矛盾する実例を受け取り、評価者にも適用できる安定したルールがなくなります。
明確なラベルを付けずに、正しい答えと誤った答えを並べないでください。モデルが、従うべき実例と、問題として指摘されている動作を区別できるようにします。例全体で、入力と出力の配置を統一してください。
例示から除外した架空の評価用質問セットを保持する
プロンプトに一度も含めない依頼を確保します。架空の評価用依頼として「フォルダーは開けますが、ダウンロードボタンが動かなくなりました」が考えられます。定めたルールでは、この記事で設定する正解はfaultです。別の例として「このフォルダーについて誰に相談すればよいですか？」なら、正解はunclearです。
ダッシュボードなど、別の対象についての依頼も含めます。実例によってフォルダー固有の近道を学んでしまった場合、対象を変えた表現でそれを発見しやすくなります。含めた例の言い換えも役立ちますが、異なる境界を試すケースより確認としては弱くなります。
指示だけのプロンプトと、例を含むプロンプトを、同じ評価用セットとモデル設定で比較します。ラベルの誤り、根拠のない理由、形式が不正な出力は別々に記録してください。ここではモデルを実行していないため、精度の数値は報告していません。正解はテスト仕様であり、合格したテストではありません。
フューショットの内容をAI Flowi Workflowに対応させる
実例のブロックをリクエストに配置する方法は、Prompt Templateのドキュメントで扱います。
選択した生成モデルの接続は、Language Modelのページで扱います。
実例のラベルに定義済みの応答構造が必要な場合は、構造化出力のガイドを参照してください。
この分類器で提案するフィールドはlabelとreasonです。アプリケーションで定義したラベルはaccess、fault、unclearであり、カタログの選択肢ではありません。理由を受け入れるのは、明記された権限の必要性、以前は動作していたものの停止、根拠の不足のいずれかを示す場合だけです。依頼に書かれていないのに、ユーザーが以前アクセスできていたとする理由は拒否します。
依頼に複数のカテゴリが含まれることもあります。例えば「ダッシュボードのアクセス権をください。プリンターも動かなくなりました」です。実例を選ぶ前に、タスクが依頼全体を分類するのか、個々の問題を分類するのかを決めてください。単一ラベルの設計では、この混在した依頼に対する明確な曖昧性のルールが必要です。問題ごとに分類する設計では、実例で分割の方法を示す必要があります。そうしないと、モデルは実例を正確に模倣しても、分類する単位を取り違える場合があります。
例は、その判断に合わせてください。混在した依頼を評価セットだけに追加すると、境界の不足を発見できます。しかし、その答えをプロンプトにコピーしてから再度評価すると、不足が見えなくなります。実例を修正した後は、別の混在した依頼を残し、ルールを教えた表現以外にも適用できるかを確認してください。
カタログに記載されていますが、Ai Flowiによる本番環境でのテストは行われていません
実例に基づく分類を設定する前に、カタログを確認してください。モデルへのリクエストには、ご自身のプロバイダーアカウントとAPIキーが必要です。実例のテキストも、別途課金されるプロバイダーの使用量に含まれます。
よくある間違いと、例を省いてよい場合
例によって、最も目立つラベルに応答が偏ったり、非公開の依頼が誤って開示されたりする場合があります。境界を設計する際は架空の素材を使い、実例を共有する前には利用許可を確認してください。公開テンプレートに、機密の認証情報や個人を特定できるサポート記録を含めてはいけません。
長い実例は、現在の入力やソースの証拠とも限られた入力領域を取り合います。コンテキストエンジニアリングでは、その選択のトレードオフを説明します。短い決定的なルールで正確に判断できるなら、モデルに例を模倣させるより、そのルールの適用が適している場合があります。
Agentが関係するのは、ツールが必要な場合であり、プロンプトに例が含まれるという理由からではありません。全体の出発点となる設計には、文書化されたユースケースを使い、その証拠を確認してください。フューショットプロンプティングは、アクションを許可したり、ラベルを認証したり、周囲のワークフローが正常に実行されたことを証明したりするものではありません。