- 公開日
Few-shotは、少数の入力と望ましい出力の例を示して、回答の仕方を伝える方法です。分類が一つのラベルへ偏るときは、例の数だけを増やす前に、分類基準と、例に含まれる語句やラベルの分布を確認します。典型例に加えて判断が分かれる境界例を選び、修正に使わなかった入力で確かめます。
例を変えた後に出力が変わっても、すぐに「偏りが解消した」とは言えません。分類の正解、例の数、並び順、入力の難しさを一緒に変えていれば、何が関係したか分からなくなります。改善したい誤りを特定し、変更条件と確認用の入力を分けることが必要です。
例から基準以外の特徴を拾うことがある
Calibrate Before Use: Improving Few-shot Performance of Language Modelsは、当時のGPT-3やGPT-2を使った課題で、プロンプトの形式、選ぶ例、例の順序によって正答率が変わることを報告しました。その原因として、プロンプトの末尾近くに置かれた答えや、事前学習データでよく現れる答えへ予測が偏る傾向を挙げています。ICML 2021の研究であり、現在の全モデルが同じ大きさで影響を受けるという意味ではありません。
同論文の主な改善方法は、出力の偏りを補正するcontextual calibrationです。この記事で扱う、業務基準に合う例を選び直す方法とは同一ではありません。境界例を足せば必ず正答率が上がるという実証として、この研究を引用することもできません。
実務上は、「問い合わせ文に特定の語があると、いつも同じ分類になる」「例に少ない分類を選ばない」といった症状を入口にします。ただし、その語が本来の分類条件なら、同じ分類になること自体は誤りではありません。資料不足、ラベル定義の曖昧さ、入力文の欠落も原因候補に含め、例示バイアスという名前だけで診断を終えないようにします。
架空の問い合わせを二分類と保留に分ける
社内ツールの窓口で、問い合わせを「手続案内」「利用障害」「要確認」へ振り分ける架空の例を使います。目的は担当窓口の候補を示すことで、アカウント変更や修復を自動実行することではありません。ここでの分類は、この窓口の運用上の仮定です。
「手続案内」は、通常の使い方や所定の復旧手順を尋ねる問い合わせです。「利用障害」は、通常の操作を行ったのにサービス側のエラーなどで利用できない状況が示されている問い合わせです。「要確認」は、どちらかを決める情報が足りない場合に使います。パスワード忘れに対する所定の再設定方法の案内は、この例では手続案内へ含めると決めます。
元の例示が、次の三件だけだったとします。
| 入力例 | 出力ラベル |
|---|---|
| ログインの手順を教えてください | 手続案内 |
| パスワードを忘れたので再設定方法を教えてください | 手続案内 |
| 登録したメールアドレスの変更手順を知りたいです | 手続案内 |
この例示には、利用障害と要確認がありません。AIが後の問い合わせも手続案内と分類したとして、その一件だけで原因を確定することはできませんが、境界を示していない例の構成は見直す対象になります。「ログイン」という語と手続案内の結び付きも、点検する候補です。
まずラベルの定義を依頼文へ明示します。次に、例のどの特徴が分類を決めるのかを説明できる組合せを選びます。例を単に三分類同数へ揃えるだけでは、同じ言い回しの繰返しになり、境界を伝えられないことがあります。
同じ語句で判断が変わる例を選ぶ
例の選び直しでは、次のような入力を含める案が考えられます。いずれも作例であり、実モデルで効果を測ったものではありません。
| 入力例 | 期待する分類 | 分類を決める情報 |
|---|---|---|
| ログイン手順を教えてください | 手続案内 | 通常の方法を尋ねている |
| 正しい手順でログインするとサービスのエラー画面になり、利用できません | 利用障害 | 手順ではなく発生中の不具合を報告している |
| ログインできません | 要確認 | パスワード忘れか不具合か等を判断する情報が不足 |
| パスワードを忘れてログインできません。再設定方法を教えてください | 手続案内 | この窓口では所定の再設定案内として扱う |
同じ「ログインできない」を含んでも、原因と依頼内容で分類が分かれます。最後の例は、利用できないという結果だけで利用障害へ振り分けないための境界例です。ただし、窓口の運用が異なれば正解も変わります。業務の定義と合わない例を、一般的に正しい分類として入れないようにします。
「要確認」の出力には、不足する情報を短く添える方針も決めます。たとえば、エラー表示の有無と直前の操作を尋ねる候補を示します。必要な情報がないのにラベルだけを強制すると、分類例を整えても推測が残ります。分類を保留することと、問い合わせ全体を処理できないことは同じではなく、担当者へ確認点を渡せます。
改善する依頼例は次のとおりです。
「以下の分類定義と例に従って問い合わせを分類してください。例中の単語だけで決めず、利用者が求めることと発生している状況を確認してください。定義へ当てはめる情報が足りない場合は要確認とし、分類を決めるために先に確認すべき情報を短く示してください。出力はラベルと短い根拠にしてください。」
この未実行の依頼例には、実際のラベル定義と例を付けます。「単語だけで決めない」と書いたから問題が解決したとはみなさず、分類を決めた記述が入力に存在するかを回答後に確認します。
比較で変えたものを分けて残す
元の三例から新しい四例へ変えると、例の数、ラベル分布、境界の有無が同時に変わります。この組合せが業務上使えるかを調べることはできますが、結果の差を「境界例一つの効果」とは言えません。何を確かめる比較かを先に決めます。
境界例の役割を狭く見るなら、同じ数の例を用意し、一部を典型例から境界例へ置き換える比較を設計できます。順序の影響を見るなら、例の内容と数を固定して順序だけを変えます。モデル、設定、分類定義、回答形式も固定し、変更した点を記録します。この記事では、その比較試験は実施していません。
例を分類ごとに同数へ揃えた場合でも、実際の問い合わせの分布まで同数だとは限りません。例は基準を伝えるための材料であり、業務でどの分類が何割届くかを代表する標本とは限らないためです。見本の件数と実運用の比率を混同せず、評価では実際に重視する誤りや稀なケースも見る必要があります。
未使用の問い合わせで確認する
例を選び直すために見た問い合わせは、調整用として分けます。同じ入力へ繰り返し合わせてから、その入力で正解した件数を「未知の問い合わせでの性能」と報告することはできません。確認用には、選定や依頼文の修正に使わなかった別の入力を用意します。
たとえば、「報告書の出力方法を知りたい」と「報告書の出力を押すとエラーで停止する」を対にすれば、ログイン以外でも方法の案内と発生中の不具合を区別できるかを見る設計になります。「エラーという表示の意味を調べたい。現在は利用できている」のような入力は、単語だけで分類していないかを点検する候補です。期待ラベルは実際の運用定義に照らして担当者が確定します。
これらをプロンプトの例へ採用したら、その時点で同じ入力は未使用の確認用ではなくなります。似た文章へ単語だけ置き換えても、難しさが十分に変わらない場合があります。表現の違いに加え、情報不足、複数の依頼が混じる文、分類定義では扱えない文など、判断条件の違いを確認します。
集計は全体の正解数だけでなく、分類別の取り違えと要確認の使い方を分けます。情報が足りないときの要確認は妥当でも、明確な利用障害まで毎回保留するなら、業務に必要な振分けができていません。逆に保留を減らすため、情報不足の文を無理に手続案内へ入れることも改善ではありません。
少数例で判断が揃わないときは、さらに例を足す前に定義を見直します。担当者同士でも分類が割れるなら、AIだけの偏りとして扱わず、窓口の受持ちや保留条件を整える必要があります。例の追加で入力が長くなり、定義変更時に直す箇所も増えるため、分類を変える違いを説明できる例を残し、別入力で効果を確かめます。
基本から確認する：この記事の前提になる考え方は、「プロンプトの書き方ガイド（依頼文の基本6項目と例文）」にまとめています。
