この記事には広告(アフィリエイトリンク)が含まれます。Amazonのアソシエイトとして、PROBEFOLIOは適格販売により収入を得ています。

「短く、分かりやすくまとめて」と頼んだのに、思っていた形と違う。説明を足すほど依頼文が長くなり、かえって伝わりにくくなることがあります。そんなときに試したいのが、「この形でお願いします」と見本を添える方法です。

初めて伝票を書く人には、口で説明するより記入済みの一枚を見せた方が伝わることがありますよね。AIにも同じように、入力と、それに対して欲しい答えを数組見せます。これがFew-shot promptingと呼ばれる頼み方です。

大切なのは見本の数を増やすことより、迷いそうな違いを見せることです。この記事では、問い合わせを「納期・請求・その他」に分ける小さな仕事で、例の作り方と答え合わせを紹介します。プログラムを書かず、普段のチャットに添えるところから試せます。

この記事の目次
01

説明に「こう答えてほしい」という見本を足す

Fewは少数、shotはこの文脈では例を指します。Few-shot promptingは、AIへの依頼に少数の例を含める方法です。例を添えない場合はZero-shot、一つだけならOne-shotと呼ぶことがあります。呼び名より、どんな違いを例で伝えるかが大切です。

これは、モデルの内部を追加学習で更新するファインチューニングとは別です。今回渡した例を、その返答の材料として使います。次の会話でも使いたいなら、テンプレートやプロジェクトの指示などに保存し、実際に読み込まれる形にしておきます。

02

問い合わせを「納期・請求・その他」へ分ける例

架空の問い合わせを三つに分類します。「納期」は到着時期、「請求」は料金や請求書、それ以外は「その他」です。ただし、到着前の返金など複数の話が混ざる場合は、勝手に一つへ決めず「要確認」にします。

「分類して」と書くだけでなく、「いつ届きますか→納期」「請求書の宛名を変えたい→請求」という見本を置くと、ラベルの表記を示せます。さらに、複数の話がある見本を足すことで、迷う場面の扱いも伝えられます。以下は架空データによる記入例です。

「分類して」だけでなく、見本を添える

  1. 見本1:入力 → 欲しい分類

    「商品はいつ届きますか」→ 納期

  2. 見本2:入力 → 欲しい分類

    「請求書をもう一度送ってください」→ 請求

  3. 今回分類してほしい文

    「箱が壊れて届きました」→ 答え合わせでは「その他」になるか確認する。

分類ルールを伝える架空の例。最後の分類は期待する答えで、実測の出力ではありません。

「届く」という似た言葉があっても、到着日を尋ねている文と破損を伝えている文では用件が違います。見本は、単語を拾うだけでなく何で分類してほしいかを示すために使います。

見本に入れた文だけを再入力して成功しても、別の問い合わせを分類できるとは限りません。練習に使っていない文を残し、納期と請求の両方を含む場合など、迷う例でも答えを確かめてください。

03

この入力で確かめたい完成形

「領収書を再発行できますか」に対する確認用の答えは「請求|支払い書類の再発行です」です。これはモデルを動かした実測回答ではなく、編集部が作った採点用の正解例です。理由の言葉まで完全一致する必要はありませんが、指定ラベルが守られ、根拠にない事情を付け足していないかを見ます。

同じ見本をそのまま再入力して正しく分類できても、新しい問い合わせに対応できる証拠にはなりません。「明日までに届かないなら請求を止めたい」のように、表現を変えた境界例も確認します。見本を増やすときは、分類したい現実の迷いに合わせて選びます。

04

見本は、典型・境界・例外をそろえる

似た例を十個並べるより、どの場面で判断が分かれるかを示す方が役立つことがあります。たとえば納期の例が全部「いつ届く」なら、「発送予定」「到着見込み」という言い換えが出たときも分類できるかを確かめます。

個人情報や実在の取引先情報を、そのまま共通テンプレートへ残さないようにします。住所や注文番号を架空の値へ置き換えても分類に必要な意味を保てるなら、その形で用意してください。

見本に入れたい違い
種類架空の入力期待する扱い
典型到着予定を知りたい納期
言い換え領収書を再発行したい請求
境界遅延したので返金してほしい要確認
対象外店舗の営業時間を知りたいその他
情報不足例の件をお願い要確認として追加情報を求める
05

例を増やす前に、分類ルールが矛盾していないか

「すべて三分類にする」と「分からないものは要確認にする」が混ざっていると、例を増やしても指示がぶつかります。出力のラベル一覧と見本で使っているラベルをそろえましょう。判断保留を認めるかも、先に決めます。

確認には、見本と別の入力を少なくとも数件用意します。正しく分類できた数だけでなく、誤って自動処理へ回した件数を記録します。請求の変更を実行するような業務なら、「要確認」が増えることより、間違った処理が通ることの方が問題です。

改善は一度に一つずつ行います。見本の追加、ルールの変更、モデルの変更を同時にすると、何が効いたか分かりません。入力と結果を残し、変更前の例でも再確認してください。

もっと多くの分類や文章生成へ応用するなら、Few-shotを含むプロンプト設計の本も比較できます。見本を足せば必ず良くなるという本の紹介ではありません。例の選び方と評価を、アプリ開発の中で学びたい方への候補です。

06

うまくいった見本を、毎回の仕事へ戻す

完成したテンプレートには、目的、ラベル、見本、判断保留の条件、確認日を残します。別の担当者へ渡すときは、「この例の外では判断を確認する」という使い方も一緒に伝えます。例を増やし続けて読みにくくなったら、重複を減らして代表例へ整理しましょう。

定型業務の依頼文はChatGPTの仕事用テンプレートへ。毎回同じ方針を使うならシステムプロンプトの考え方で、固定の指示と今回の入力を分けられます。

QUICK ANSWERS

よくある疑問を、ここで。

使い始める前に、気になるところから。

例は何個必要ですか?

固定の正解はありません。まず典型例と迷う例を少数用意し、別の入力で確認します。同じ例を増やすより、判断の境界をカバーすることを優先します。

この記事の内容をもとにした、編集部からの提案です。
Few-shotは追加学習ですか?

この方法では、例をその場の入力として渡します。モデルの重みを更新する追加学習とは別です。

この記事の内容をもとにした、編集部からの提案です。
JSONの形を必ず守らせられますか?

例だけでは保証できません。アプリで扱う場合は、構造化出力や形式の検査も使い、壊れた出力をそのまま処理しない設計が必要です。

この記事の内容をもとにした、編集部からの提案です。

この記事を共有する

X(旧Twitter)(新しいタブで開きます)LINE(新しいタブで開きます)はてなブックマーク(新しいタブで開きます)

商品情報の提供:Supported by Rakuten Developers

SOURCES & EDITORIAL NOTE

出典と、この記事について

公式資料や、記事で参照した発表・報道をまとめています。仕様や料金は、利用する前に最新の案内をご確認ください。

確認した内容と条件は本文に記載しています。結果や使い勝手は、資料や環境によって異なります。編集方針を読む