AIエンジニアリング
RAGかファインチューニングか：モデルにドメインを学ばせる方法の選び方
検索はリクエスト時にモデルへ事実を与え、ファインチューニングはモデルの振る舞いを変えます。両者は別々の問題を解くものであり、競合する手法として扱うと誤ったアーキテクチャに行き着きます。
· 4分で読めます · Starone エンジニアリング
この問いは通常、モデルに事業の知識を教える二つの方法からの選択として語られます。その捉え方では、役に立つ区別が隠れてしまいます。検索拡張生成（RAG）は知識を供給します。リクエスト時に関連するテキストを取得し、コンテキストウィンドウに配置します。ファインチューニングは振る舞いを調整します。モデルの重みを変更し、特定の形式で書く、特定のポリシーに従う、限定されたタスクをより確実にこなす、といったことを可能にします。
私たちの原則は、事実にあたるものはすべて検索で扱い、ファインチューニングはプロンプトと検索では必要な振る舞いを実現できないという根拠がある場合に限る、というものです。本稿では、その理由と、この原則が当てはまらない場面を説明します。
それぞれの手法が実際に変えるもの
検索の場合、モデルは変わりません。クエリはインデックスに対する検索に変換され、最適なパッセージが選ばれ、モデルはそれを使って回答します。知識は、更新、フィルタリング、監査が可能なデータストアに置かれます。
ファインチューニングの場合、ベースモデルを入力と出力のペアの例でさらに学習させます。LoRAのような低ランクアダプターを用い、少数の追加の重みだけを学習させることも多くあります。知識と振る舞いはパラメータの中に圧縮されます。学習後は、個別に参照することも、引用することも、削除することもできません。
知識には検索を標準とする理由
事業上の知識は変化し、読み手ごとに見せる範囲が異なり、ときには削除しなければなりません。この三つの性質は、検索システムが得意とし、チューニング済みモデルが苦手とする領域にそのまま対応します。
- 鮮度：新しいポリシーはインデックスに登録された時点で利用でき、学習の実行は不要です。
- アクセス制御：クエリ実行時に呼び出し元の権限で結果を絞り込めるため、同じ質問をした二人のユーザーが異なるソースを参照します。
- 出典の明示：回答は使用したパッセージを引用でき、読み手は内容を検証でき、エンジニアはデバッグできます。
- 削除：インデックスから文書を削除すれば以降の回答から消えますが、学習済みの重みから事実を取り除くことは実務上の未解決問題です。
検索がうまくいかない場面
検索は難しさを検索処理の側に移すものであり、この種のシステムが失敗するのはたいていそこです。正しいパッセージが取得されなければ、モデルは一般的な学習内容から回答するか、自信をもって空白を埋めてしまいます。固定長のチャンク分割は表を分断し、条項とその意味を与える見出しを切り離します。密な埋め込みだけでは、製品コードや条項番号のような厳密な識別子を取りこぼします。そのため私たちは、ベクトル検索とBM25などのキーワード検索を組み合わせ、統合した候補をリランキングします。
検索はリクエストのたびにトークンとレイテンシのコストも発生させます。また、特定の条件を含むすべての契約の要約のように、コーパス全体を見渡す必要のある質問は苦手です。こうした質問に必要なのは集計パイプラインや構造化クエリであり、top-kを大きくすることではありません。
ファインチューニングがコストに見合う場面
ファインチューニングが適切な手段となるのは、問題がモデルの知識ではなく応答の仕方にある場合です。典型例は、プロンプトでは大量処理時に維持できない厳密な出力構造、臨床文書や法務文書の文体といったドメイン固有の語調、数千件のラベル付きデータがある分類や抽出のタスク、そして小さなモデルを低コストで、あるいはプライベートなインフラで動かすという要件です。最後のケースでは、大きなモデルの出力で小さなモデルをチューニングすることで、大きなモデルでは満たせないレイテンシとコストの予算内に、限定されたタスクを収められる場合があります。
プロンプトが何ページもの指示と例に膨らみ、呼び出しのたびにその分のコストを払っている場合にも、検討する価値があります。安定した振る舞いを重みに移せば、プロンプトは短くなります。
チューニング済みモデルの運用コスト
ファインチューニングしたモデルは、独自のライフサイクルを持つビルド成果物です。整備された学習データセット、学習に使わない評価セット、どのデータからどのバージョンが作られたかの記録、そしてベースモデルが提供終了となり後継モデルでチューニングをやり直す日に備えた計画が必要です。学習データに個人情報や機密情報が含まれていれば、それは中身を調べにくい成果物の中に埋め込まれることになります。
品質面のリスクもあります。狭い範囲のチューニングは汎用的な能力を低下させることがあり、これは破滅的忘却と呼ばれる現象です。また、事実でチューニングしたモデルは、事実が変わった後も古い内容を確信をもって述べます。私たちがファインチューニングを知識の格納先として使わない主な理由はここにあります。
実務に耐える判断の順序
私たちは、コストと可逆性の順に選択肢を検討し、評価目標を満たした最初の手段で止めます。
- 少数の例を添えた明確なプロンプトを書き、評価セットで計測します。
- コーパスが小さく安定しているなら、コンテキストウィンドウに直接入れ、プロンプトキャッシュを使います。検索基盤は不要かもしれません。
- 知識が大規模である、変化する、権限管理を伴う場合に検索を追加します。
- 残る失敗が形式、語調、タスクの習熟に関するもので、質の高い例が十分にある場合にファインチューニングします。
- 必要に応じて両者を組み合わせます。取得したコンテキストをうまく使えるようチューニングしたモデルに、事実は引き続きインデックスから供給します。
逆の選択が正しい場合
タスクが閉じていて知識が静的であれば、ファインチューニングから始めるのは妥当です。サポートチケットを固定の分類体系に振り分ける、既知の種類の文書からフィールドを抽出する、問い合わせるインデックスのないデバイス上でオフライン動作させる、といった場合です。こうしたタスクにとって、検索は不要な可動部品を増やすだけです。
いずれにしても、判断は計測に基づいて行うべきです。検索の失敗と生成の失敗を切り分けられる評価セットがあれば、実際に観測されたエラーにどちらの手法が効くのかが分かり、検索の改善で解決できたはずの問題に高価な学習を投じることを防げます。