【ITニュース解説】RAG vs. Fine-Tuning: How to Choose the Right Technique for Enterprise LLM Systems

大規模言語モデル（LLM）を企業で活用する際、RAG（Retrieval-Augmented Generation）とファインチューニングという二つの主要な手法がよく議論される。これらは「社内の文書をモデルに与えるべきか、それとも社内データでモデルを訓練すべきか」という問いに対する競合する答えとして捉えられがちだが、実際にはそれぞれ異なる役割と得意分野を持っている。本解説では、システムエンジニアを目指す初心者にも理解できるように、この二つの手法を知識の鮮度、モデルの振る舞い、データセキュリティ、コスト、そして評価といった多角的な観点から比較し、最適な手法を選択するためのフレームワークを説明する。

まず、解決したい問題を明確にすることが最も重要だ。問題は大きく「知識」「振る舞い」「ルール」の三つに分類できる。「この顧客の返品期間は何か？」という質問のように、常に最新の情報を必要とする場合は「知識」の問題であり、RAGが適している。これは、企業の契約条件やポリシーが頻繁に更新されるため、モデル自体にその知識を直接覚えさせることは現実的ではないからだ。一方、「受信メールを6つの業務カテゴリに分類し、常に有効なJSON形式で出力せよ」というような、一貫した形式や特定の振る舞いを求める場合は、「振る舞い」の問題であり、ファインチューニングの候補となる。さらに、「5,000トルコリラ以上の返金には二次承認が必要」といった、厳密な条件に基づく判断は「ルール」の問題であり、LLMではなく、SQLデータベースやワークフローシステム、ルールサービスといった決定論的なコードで処理すべき領域である。正確な計算や厳格な権限管理、あるいは取り消し不可能なアクションは、モデルに任せるべきではないという原則がある。

RAG（Retrieval-Augmented Generation）は、ユーザーの質問に対して、承認された情報源の中から関連性の高い「証拠」を検索し、その証拠をモデルの入力コンテキストとして与えることで回答を生成する仕組みだ。これにより、モデルは質問に答える時点で利用可能な知識を動的に変更できる。RAGのシステムは、情報源の取得、テキストやメタデータの準備、候補の検索、証拠の再ランキング、引用付き回答の生成、そしてシステム挙動の記録といった一連の生産パスを持つ。ベクトルデータベースはRAGパスの一要素に過ぎず、RAG全体を意味するものではない。RAGの質は単にPDFを分割するだけでは高まらない。文書の改訂履歴、有効開始日、製品範囲、言語、アクセス制御、見出しの階層、元のリンクといった豊富なメタデータを保持することが極めて重要だ。検索には、単語の一致を見る語彙検索と意味の類似性を見るセマンティック検索を組み合わせ、さらにリランカーを使って最も関連性の高い証拠を絞り込むことが推奨される。モデルは提供された証拠に基づいて回答するか、証拠が不十分であることを明示的に報告するべきであり、もっともらしい回答を勝手に生成することは避けるべきだ。アクセス制御はRAGの中核であり、「個人情報を漏らさないように」とプロンプトに加えるだけでは不十分で、ユーザーがアクセス権限を持たない情報を検索結果から最初から除外する仕組みが必須となる。もし検索が十分な証拠を返せない場合、システムは回答を生成せず「証拠不十分」の状態に入るべきである。

RAGの品質を評価するためには、少なくとも二つの側面から測定が必要となる。一つは「検索が正しい証拠を返したか」、もう一つは「その証拠のみを使って、モデルが正しく十分な回答を提供したか」という点だ。たとえば、間違った文書が流暢に要約されたり、正しい文書が誤った主張を裏付けるために使われたりする可能性があるため、これらは異なる原因と修正方法を必要とする。具体的な測定指標としては、「Recall@k」があり、これは正しい情報源が検索結果の上位k件に含まれるかを評価する（例：重要な条項が上位5件にあるか）。「引用の正確性」は、モデルが提示した回答が実際に引用した情報源によって裏付けられているかを人間がレビューして確認する。「根拠に基づく正確性」は、回答が提供された証拠とビジネスルールに忠実であるかを期待される回答と比較して評価する。「棄却」は、適切な証拠がない場合にモデルが回答を停止できるかを測るもので、誤った情報を生成するよりも「分からない」と伝える方がビジネス上は好ましい場合が多い。「遅延とコスト」は、応答時間や処理費用が許容範囲内であるかを監視し、特にピーク時のパフォーマンス（p95遅延）と1クエリあたりのコストを考慮する。評価セットには、簡単なFAQだけでなく、名前の衝突、古い改訂、複数文書にわたる回答、権限の境界、OCRエラー、空の検索結果、矛盾する情報源といった、より複雑で挑戦的なシナリオを含めることが重要だ。

ファインチューニングは、既存の基盤モデルを特定のタスクに合わせて、選定された入力と出力の例を使って微調整するプロセスだ。これは、分類ラベル、構造化された出力形式、特定の専門用語、簡潔な応答スタイル、あるいは望ましいツール選択といった、モデルの特定の「振る舞い」を改善するのに適している。訓練データセットとジョブをプロバイダーに提供して実行する形式が一般的で、例えばOpenAI APIではJSONL形式の訓練データを指定する。ファインチューニングは、訓練データに含まれる事実を信頼できる文書ストアに変えるものではないという点に注意が必要だ。ポリシーや価格が変更された場合、ファインチューニングされたモデルのどこに影響が出るかを特定し、更新するのは非常に困難である。ファインチューニングによってモデルに「記憶された」ように見える情報は、引用可能性や最新性、アクセス制御の保証がない。そのため、知識ベースの質問には、ファインチューニングされたモデルと並行してRAGが必要となる場合がある。訓練データは、理想的な作業結果と許可された出力契約を正確に反映しているべきだ。検証セットはプロンプトやハイパーパラメータの選択をサポートし、テストセットは最終的なモデル比較まで触らずに保持し、訓練データや検証データと同じ顧客、テンプレート、文書家族の情報が混入しないように厳密に分割する必要がある。モデル、データセット、プロンプト、評価の各バージョンは、同じリリース記録として管理されるべきである。

ファインチューニングはデプロイの決定ではなく、あくまで実験として捉えるべきだ。まず、「生成されるJSONのスキーマが常に有効であること」や「特定のタスクにおける分類精度が専門家の判断でX%以上に達すること」といった、客観的に測定可能な目標を設定する。次に、強力なシステムプロンプトを適用したベースモデル、RAGを組み合わせたベースモデル、そしてファインチューニングを適用したモデルの三つを、同じ、しかし未知のテストセットを使ってブラインド評価で比較する。複雑なアプローチだからといって、必ずしもより良い結果をもたらすとは限らないからだ。失敗例を詳細に分類し、それが知識不足、検索の誤り、スキーマの失敗、ツールの選択ミス、コンテキストの不足、安全性の問題、あるいは評価基準の曖昧さによるものかを特定することが重要だ。あらゆる失敗例を訓練データに追加しようとすると、データセットの品質を損なう可能性がある。訓練データには、理想的な振る舞いを示す例のみを含めるべきであり、個人情報、アクセスキー、古くなった矛盾するルール、未検証のモデル出力などは決して含めてはならない。

コストと遅延の観点も重要だ。RAGのコストには、情報源の準備とインデックス作成だけでなく、クエリ時の埋め込み生成、検索、再ランキング、コンテキストトークン、および回答生成の費用が含まれる。文書が変更された場合、影響を受ける断片のみを再処理できるため、効率的な更新が可能だ。一方、ファインチューニングには、データセットの準備、訓練ジョブの実行、評価、そしてカスタムモデルの推論コストがかかる。しかし、これらは純粋な技術費用に過ぎない。より広範な「物質的なコスト」には、誤った回答の修正作業、運用上の遅延、そして間違った情報がもたらすビジネスへの影響も含まれるため、モデルの請求書だけを考慮すべきではない。

セキュリティ、アクセス制御、データライフサイクル管理もシステムの設計において不可欠な要素だ。RAGシステムが文書をコンテキストに追加する前には、テナント、役割、レコードレベル、契約範囲、有効開始日といった様々なフィルターが適用される。情報源の断片、生成された回答、そしてユーザーのIDは、データ最小化の原則に基づいて可観測性のため記録される場合がある。文書が削除されたり、ユーザーのアクセス許可が取り消されたりした場合には、速やかにインデックスやキャッシュからもその情報を削除する仕組みが必要だ。ファインチューニングデータは、プロバイダーのデータ保持、利用、削除に関する規約を確認する必要があるという点で、もう一つのガバナンス上の課題を提起する。単にファイルを「ファインチューニングデータ」と呼ぶだけではガバナンスの問題は解決しない。どのデータクラスがシステム境界を越えて移動してもよいか、どのくらいの期間保持されるか、そしてモデルの改訂版がどのように廃止されるかを明確に定義する必要がある。

多くの場合、RAGとファインチューニングを組み合わせたハイブリッドなアーキテクチャが最も効果的な解決策となる。成熟したシステムでは、ファインチューニングされたモデルや慎重にプロンプトが設定されたモデルが、クエリの構造化や応答形式の安定化を担当する。RAGは最新で承認された証拠を提供し、ルールサービスは権限、計算、および副次的効果を検証する。そして、不確実なケースや高リスクなケースは人間がレビューする体制を整える。これにより、各コンポーネントがその能力を最大限に発揮できる責任を割り当て、一つのモデルにすべての知識や振る舞いを教え込もうとするよりも、全体として堅牢で信頼性の高いシステムを構築できるのだ。

実践的な意思決定プロセスとしては、まず「正しい情報源は何か」「必要なフィールドは何か」「副次的効果は何か」「期限はいつか」といった成功の契約を明確に定義することから始める。次に、強力なプロンプト、スキーマ検証、ルールチェック、そして測定可能なテストセットを用いて、シンプルなベースラインを確立する。知識が頻繁に変わる問題には、バージョン管理された情報源とRAGを優先し、検索の品質を別途評価する。モデルの振る舞いに一貫性のない問題が繰り返される場合は、固定されたテストセットでファインチューニングの仮説を検証する実験を行う。高リスクな決定は、必ず決定論的な検証や人間の承認なしに実行しない。本番環境では、システムのバージョン、コスト、誤検出率、情報源の証拠、ロールバックの可否などを継続的に監視し、運用を最適化していく必要がある。

最後に、いくつかのよくある疑問に答える。RAGとファインチューニングのどちらがより正確かという問いに対しては、RAGは最新で引用可能な知識のためにまず使用し、ファインチューニングは繰り返される振る舞いや形式、分類のために評価すべきだ。厳密なビジネスルールには決定論的なコードが依然として最適な層となる。ファインチューニングが会社文書をモデルに教えるのに適しているかというと、頻繁に変わるポリシー、価格、契約、顧客記録には通常、第一の選択肢ではない。これらはバージョン管理、引用、削除、アクセス制御を必要とし、RAGがより直接的にサポートするからだ。RAGが幻覚（ハルシネーション）をなくすかというと、そうではない。検索が間違っていたり不完全だったりすることもあるし、モデルが証拠を超えて生成することもあるため、情報源フィルター、再ランキング、引用チェック、証拠がない場合の棄却、そして評価を組み合わせて対処する必要がある。ベクトルデータベースだけでRAGが十分かというと、そうではない。情報源の品質、チャンク化、メタデータ、アクセスフィルター、ハイブリッド検索、再ランキング、バージョン管理、そして評価は、データベースの選択と同じくらい、あるいはそれ以上に重要である。RAGとファインチューニングは組み合わせられるかというと、はい、可能である。ファインチューニングや強力なプロンプトは振る舞いや応答形式を改善し、RAGは現在の証拠を提供する。ただし、権限、計算、永続的な副次的効果は依然として決定論的な検証が必要だ。最初の本番リリースで何を測定すべきかという質問には、ビジネス成果の正確性、正しい情報源の検索、引用のサポート、スキーマの有効性、証拠がない場合の棄却、p95の遅延、クエリあたりのコスト、そして人間のレビュー率を測定すべきである。