RAGかファインチューニングか、知識更新で選ぶと失敗が減る

更新される知識を回答へ反映したいならRAG、文体や出力形式などモデルの振る舞いを変えたいならファインチューニング、という切り分けが基本です。最新の社内規程、製品情報、手順書を参照し、回答の根拠も示す用途ではRAGを先に検討します。

一方、同種の入力を決まった形式へ変換する、分類基準をそろえる、特定の文体を安定して出すといった用途では、良質な学習例があればファインチューニングが候補になります。更新頻度、根拠提示、利用可能なデータ、許容遅延、保守作業を同じ表で比べれば、解決したい問題と方式がずれる失敗を減らせます。

違いは回答時の検索か、事前の追加訓練か

RAGは、質問に関連する外部文書を検索し、取得した内容をコンテキストとしてLLMへ渡す構成です。モデルの重みを変えず、回答時に参照する情報を更新できるため、承認済み文書の差し替えや検索インデックスの更新を次の回答へ反映できます。

ファインチューニングは、事前学習済みモデルを特定のタスクやデータセットで追加訓練し、重みを適応させる方法です。IBMによる仕組みの比較 でも、RAGは外部データを検索して質問と組み合わせる手法、ファインチューニングは焦点を絞ったデータでモデルを再訓練する手法として区別されています。

したがって、RAGが主に制御するのは「どの情報を使って答えるか」、ファインチューニングが主に調整するのは「どのように答えるか」です。ファインチューニングしたモデルを、頻繁に変わる事実を正確に保管し、必要な出典とともに取り出すデータベースの代わりにするべきではありません。

目的から逆引きする判断表

技術名から選ぶのではなく、改善対象を一文で定義します。「最新の就業規則を該当箇所とともに案内する」と「問い合わせを指定されたJSON形式へ分類する」では、必要な仕組みが異なります。

• 知識の更新が多い：RAGを優先します。価格表、規程、在庫、手順書などを変更のたびに再学習するのではなく、参照対象と検索インデックスを更新します。
• 回答の根拠が必要：RAGが適します。取得文書の識別子、版、該当箇所を生成処理と表示画面まで引き継ぐ設計が必要であり、RAGを採用しただけで正しい引用が自動的に保証されるわけではありません。
• 文体や定型形式を固定したい：まずプロンプトや構造化出力で要件を満たせるか確認し、不足が残り、一貫した入出力例を用意できる場合にファインチューニングを検討します。
• 分類、抽出、変換の基準を定着させたい：正解基準が安定し、未使用データで反復評価できるならファインチューニングが有力です。
• 社内文書への質問応答を作りたい：RAGから始めるのが妥当です。AWSの比較ガイダンス は、頻繁に変わる文書にはファインチューニングが適しにくく、カスタム文書を参照する質問応答ではRAGを起点にできること、両方式を併用できることを示しています。

採用条件はデータと監査性で決まる

RAGに必要なのは、検索可能で、版とアクセス権を管理できる文書です。古い版、重複文書、表題だけが似た資料が混在すると、生成以前に検索結果が崩れます。文書の所有者、公開範囲、施行日、失効日をメタデータとして持たせ、利用者の権限を検索段階にも適用する必要があります。

ファインチューニングには、目的に対応した一貫性のある学習例が必要です。入力と望ましい出力の組が曖昧だったり、担当者ごとにラベル基準が違ったりすれば、その揺れまでモデルへ取り込まれます。学習用、検証用、最終評価用を分け、訓練に使っていない例で基盤モデルとの差を測ります。

Microsoft Foundryの解説 は、ファインチューニングの用途としてタスク性能、スタイルとトーン、書式や構造化出力への追従を挙げ、明確な入出力データを使う教師ありファインチューニングと、基準値から反復評価する工程を説明しています。学習ジョブが完了したことではなく、未使用の評価例で要件を満たしたことを採用条件にします。

監査では、RAGは回答時に取得した文書と版を記録しやすい反面、検索漏れや誤検索を防ぐ評価が欠かせません。ファインチューニングでは、個々の回答を特定の学習例へ結び付けて出典として示すことが難しいため、根拠提示が必須の業務を単独で担わせるのは不向きです。

費用と遅延は構成ごとに分けて見る

RAGの費用は、文書収集、重複除去、分割、埋め込み作成、検索基盤、ストレージ、アクセス制御の構築に左右されます。稼働後も変更検知、再インデックス、検索品質の監視が必要です。回答時に検索とコンテキスト追加が入るため、LLMだけを呼ぶ構成より処理段階が増え、取得文書が長ければ入力トークンも増えます。

ファインチューニングでは、学習例の設計、クリーニング、ラベル付け、訓練、評価、配備、版管理が主な費用になります。推論時に検索しない構成なら検索待ち時間はありませんが、利用するサービスやモデルによって訓練、配備、推論の課金方式は異なります。知識や要件が変われば、データ改訂と再評価、場合によっては再訓練も必要です。

比較表では、初期構築費と継続費を分けます。継続費には、RAGなら検索、ストレージ、埋め込み更新、入力トークン、監視を、ファインチューニングならデータ保守、再訓練、配備、推論、再評価を含めます。担当者の作業時間まで含めなければ、安く見える方式へ運用負担を移すだけになりかねません。

併用するなら知識と振る舞いの役割を分ける

RAGとファインチューニングは排他的ではありません。たとえば、更新される製品仕様をRAGで取得しながら、回答を所定の項目順と文体で返すよう調整したモデルを使う構成が考えられます。RAGが参照情報を供給し、調整済みモデルが出力の傾向を担う分業です。

ただし、最初から併用すると、失敗の原因が検索、プロンプト、モデルのどこにあるかを切り分けにくくなります。まず基盤モデルとプロンプトを基準にし、知識不足が主因ならRAGを追加します。その後も形式違反やタスク性能の不足が残り、十分な学習例がある場合にファインチューニングを重ねれば、追加投資の効果を測りやすくなります。

併用後も評価指標は分けます。検索には正しい文書と該当箇所を取得できたか、生成には取得内容と矛盾せず要求形式を守ったか、システム全体には応答時間、拒否すべき質問への対応、権限外情報の露出がないかを設定します。

小規模検証は同じ質問セットで比べる

導入判断には、実際の業務を代表する質問と失敗しやすい質問を集めた固定評価セットを使います。正解が文書にある質問だけでなく、情報が存在しない質問、新旧文書が競合する質問、権限外の内容を求める質問も含めます。形式を評価する場合は、内容の正しさとは別に、必須項目、禁止表現、機械処理の可否を判定します。

1. 改善したい対象を、知識の正確さ、根拠提示、形式遵守、分類性能などに分解し、合格条件を決めます。
2. 基盤モデルとプロンプトだけの結果を測り、品質、応答時間、費用の比較基準を残します。
3. 知識の不足には小規模なRAG、振る舞いの不足には一貫した学習例を使うファインチューニング候補を個別に試します。
4. 回答品質だけでなく、更新作業、障害時の復旧、権限管理、監視に必要な人手も記録します。
5. 単独方式が要件を満たさない場合だけ併用し、同じ評価セットで改善幅と追加負担を測り直します。

選択を決めるのは技術の新しさではなく、変更される対象です。答えに使う事実が変わり続けるならRAGを中心にし、望ましい出力の型が安定していて、それを示す質の高い例があるならファインチューニングを検討します。両方が必要でも、問題を一つずつ検証してから組み合わせる方が、品質、費用、運用責任を説明しやすくなります。