RAGとFine-Tuning：使い分け

特定のドメインでLLMを適切に機能させたい場合、主な戦略は2つあります。Retrieval-Augmented Generation (RAG)は推論時に関連する知識を動的に注入します。一方、fine-tuningはモデルの重みを更新し、知識、文体、形式に関する設定を組み込みます。正しく選択できるかどうかが、信頼できるシステムを構築できるか、あるいは誤った方法に何か月も高額なGPU計算を費やすかの分かれ目になることがあります。

ファインチューニングでは、入力と出力のペアを使って学習し、モデルの重みを更新します。特定のJSON形式で常に応答するよう教える、ブランドの文体を採用させる、ドメイン固有の推論パターンに従わせる、モデルが最適化されていなかった種類のタスクを実行させるなど、動作の変更に優れています。ファインチューニングによって事実知識が確実に更新されるわけではありません。モデルは学習例に過適合し、基礎となる事実を新しいクエリに一般化できないことがあります。

RAGはモデルの重みを変更しません。その代わり、関連する文書をコンテキストウィンドウに配置することで、推論時にモデルが利用できる情報を変えます。RAGは、非公開文書に関する質問への回答、頻繁に更新されるデータに基づく最新の回答、検証可能な情報源に基づく応答といった知識関連の処理に優れています。一方、モデル固有の文体、形式の好み、推論方法を簡単に変えることはできません。

情報が時間とともに変化する用途では、RAGが明らかに優れています。文書が更新されたときにベクトルストアを再インデックスする作業は数分で完了し、GPUリソースも必要ありません。新しいデータでモデルをファインチューニングするには再学習が必要で、費用も時間もかかります。その場合でも、モデルが新しい事実を確実に想起できるとは限りません。商品カタログ、法規制、医療ガイドライン、社内ポリシーには、ファインチューニングよりもRAGのほうが適しています。

プロンプトエンジニアリングだけでは、非常に具体的な文体、トーン、構造化形式で常に応答することを確実に強制できない場合、ファインチューニングが適しています。たとえば、ブランド独自の語彙を必ず使うカスタマーサービスボット、社内のスタイルガイドに合ったコードを必ず生成するコードジェネレーター、何千もの例外的なケースでも固定された分類体系を確実に出力する分類モデルなどです。

ファインチューニングには、学習用の計算資源、データセットの準備、評価にかかる初期コストの高さがあります。ただし、より小さなモデルを使えるようになれば、クエリごとのコストを下げられます。RAGは、ベクトルデータベースのインデックス作成が安価なため初期コストが低い一方、埋め込みAPIの呼び出しと、コンテキストを注入した少し長いプロンプトによるクエリごとのオーバーヘッドが発生します。1日あたり1,000万クエリ未満のほとんどのアプリケーションでは、RAGのクエリごとのオーバーヘッドは、ファインチューニングの開発コストと比べて無視できる程度です。

ファインチューニング済みモデルは、必要なプロンプトが短くて済むため、推論が高速になる場合があります。知識がコンテキストではなく重みに組み込まれているためです。RAGでは、埋め込みAPIの呼び出しとベクトル検索クエリという2つの往復通信が追加されます。オーバーヘッドは通常50～200ミリ秒です。リアルタイム音声アシスタントのようなレイテンシーに敏感なアプリケーションでは、このオーバーヘッドが重要になります。多くのチャットやQ&Aアプリケーションでは、追加されるレイテンシーはユーザーがほとんど感じない程度です。

RAGは明確な監査証跡を提供します。回答ごとに、どの文書が取得されたかを正確に把握でき、ユーザーに提示することもできます。ファインチューニング済みモデルは不透明な重みから回答するため、特定の出力がどの学習例によって生成されたかを示す記録はありません。金融、医療、法律など、回答に説明可能性と検証可能性が求められる規制業界では、RAGの透明性はファインチューニングに対する大きな利点です。

RAGとファインチューニングは相互に排他的ではありません。一般的な本番環境のパターンは、まず一貫した出力形式とドメイン語彙のためにモデルをファインチューニングし、その後RAGを追加して最新の事実知識を提供する方法です。ファインチューニング済みモデルが文体と構成を安定して処理し、RAGが知識を担当します。この組み合わせは、重要性の高いエンタープライズアプリケーションで、どちらか一方だけを使うより優れた性能を発揮します。

次の手順で判断してください。問題は文体または形式の一貫性に関するものですか？ → ファインチューニングを検討します。情報は非公開または頻繁に更新されるものですか？ → RAGを使います。情報源の引用が必要ですか？ → RAGを使います。データセットがファインチューニングには少なすぎる（例が500件未満）ものですか？ → few-shot promptingを使ったRAGを利用します。モデルに現在拒否しているタスクを処理させる必要がありますか？ → RLHFまたはDPOを使ってファインチューニングします。迷った場合はRAGから始めてください。構築が速く、更新しやすく、透明性も高いためです。

次のシナリオを使って感覚を身につけてください。社内HRチャットボット（ポリシーが四半期ごとに変わり、情報源の引用が必要）→ RAG。独自フレームワーク向けのコード補完（コードスタイルとフレームワークのパターンを統一）→ ファインチューニング。法律文書のQ&A（非公開文書で、正確な引用が必要）→ RAG。カスタマーサポートボット（特定のトーンが必要で、製品FAQが毎週更新される）→ トーンにはファインチューニング、知識にはRAG。医学文献の要約ツール（最新の研究を扱い、出典の明示が重要）→ RAG。

このレッスンで扱ったAI Engineeringの概念の理解度を確認しましょう。

このレッスンでは、ファインチューニングはモデルの動作と文体を変える一方で事実知識を確実には変えないこと、RAGは推論時に知識を動的に提供するとともに完全な透明性と情報源の引用を実現すること、そして選択のための意思決定フレームワークを学びました。帰属情報が必要な、頻繁に更新される非公開知識にはRAG、一貫した文体と形式にはファインチューニング、重要性の高いエンタープライズアプリケーションには両方を使います。次は、完全なRAGパイプラインをゼロから構築します。