「AIに資料を渡した」「AIに例を教えた」。日常会話では似ていますが、実装を選ぶときは区別が必要です。
独自教材を作る過程で、用語の正解だけでなく、入力・検索対象・モデルの重みのどこを変えたかを問う形に整理しました。この記事では、その見分け方を架空の社内問い合わせシステムで説明します。特定製品での実測報告ではありません。
三つの操作を分ける
| 手法 | ここで行う操作 | 混同しやすいこと |
|---|---|---|
| Few-Shotプロンプティング | 入力に少数のお手本を添える | 例の提示を、その場でのモデル重み更新だと思う |
| RAG | 外部情報を検索し、取得結果を生成に利用する | 取得できたことを、回答の正確さと同一視する |
| ファインチューニング | 追加の訓練でモデルのパラメータを調整する | 文書を入力に貼るだけの処理と混同する |
Brownらの論文は、Few-Shotの例をテキストで与え、タスク適用時の勾配更新やファインチューニングを行わない設定を扱います。[1]
LewisらのRAG論文は、パラメータに保持する知識と検索可能な外部メモリを組み合わせる構成を扱います。なお、原論文にはモデルの訓練も含まれます。RAGだから訓練を一切しない、という意味ではありません。 検索利用と重み更新を別の操作として考えるのがポイントです。[2]
架空例：社内問い合わせの返信を作る
社内規程を使って、問い合わせへの返信案を生成するとします。
1. 返信例を3件添えた
次の3つの返信例と同じ構成で、今回の問い合わせへの返信案を作ってください。
例1：……
例2：……
例3：……
今回の問い合わせ：……
例を入力の文脈に含めるので、Few-Shotプロンプティングです。追加訓練をしていないなら、この操作をファインチューニングとは呼びません。
ただし「入力の文脈に含める」ことから、サービス側で保存されない・後の学習に使われない、と推測してはいけません。データの保存や利用条件は別途確認する事項です。
2. 規程を検索し、関連箇所を添えた
問い合わせに関連する文書を取得し、その内容を回答生成へ利用するならRAGの構成です。参照文書を更新し、検索対象へ反映することで、生成モデルの重みをその都度更新せずに新しい情報を渡せます。
ここで、次の二つは別の失敗です。
- 検索で別会社の規程を拾った。
- 正しい会社の規程を拾ったが、生成した回答がその条件を取り違えた。
前者では取得資料の対象や検索範囲、後者では回答と根拠の対応を確認します。「引用リンクがある」だけでは、この二つの確認を終えたことにはなりません。
これは本記事の設計上の整理であり、特定のRAG製品で発生を測定した結果ではありません。
3. 訓練データを用意して追加訓練した
返信データを使い、モデルのパラメータを調整する訓練工程を行うならファインチューニングです。
「例をたくさん貼ったからファインチューニング」ではなく、訓練工程を行ったかを確認します。
二択にしない
三つの手法は併用できます。たとえば、追加訓練したモデルに、検索した規程と少数の返信例を渡す構成も考えられます。
設計の会話では、「AIに学習させました」で止めず、次のように操作を説明すると違いが伝わります。
今回は重みを更新していません。社内規程を検索して入力へ添え、返信例3件をお手本にしています。
この説明なら、規程を更新するとき、返信の書式を変えるとき、それぞれどこを見直すかを考えやすくなります。どの構成が優れるかは、対象データと評価条件を決めて比較する必要があります。
参照資料
-
Brown et al., Language Models are Few-Shot Learners（2020）。Abstractのタスク適用時に勾配更新・追加訓練を行わない設定を参照。
https://arxiv.org/abs/2005.14165 -
Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（2020、参照ページは2021年改訂版）。Abstractのparametric/non-parametric memoryの構成を参照。
https://arxiv.org/abs/2005.11401
関連教材
このような概念の切り分けを練習する非公式・独自60問教材を制作しました。この記事の理解に購入は必要ありません。
Zenn版とTips版の収録問題は同じです。制作：MORI・Human OS／構成・照合支援：ChatGPT。