RAGとファインチューニングは何が違う？

RAGとファインチューニングは、モデルを業務へ合わせる方法ですが、変える対象が異なります。RAGは回答時に参照する情報を検索して追加し、ファインチューニングは用意した例を使ってモデルの応答傾向を調整します。最新の社内情報が足りないのか、安定した形式や振る舞いが必要なのかを先に切り分けてください。両方を組み合わせる場合もあります。

何を変える方法か

表は横にスクロールできます

観点	RAG	ファインチューニング
主に変えるもの	その回答でモデルへ渡す情報	学習を通じた応答傾向
更新対象	検索元の資料やindex	学習例、学習済みの調整モデル
向く課題の例	変わる規程や製品情報を参照する	一貫した分類・書式・応答パターンを学ぶ
根拠の追跡	取得した資料を記録すれば示しやすい	学習例をそのまま個別回答の出典として示す仕組みではない
主な失敗	必要な情報を検索できない、古い資料を取る	学習例が偏る、期待した振る舞いにならない
運用で見るもの	取込、権限、検索、更新反映	学習データ、評価、モデルの提供条件

RAGは「モデルへ知識を永久に覚えさせる」ことではありません。質問のたびに外部情報を取得して、その応答の材料へ加える構成です。ファインチューニングも、データを追加すれば常に望む事実を正確に記憶するという意味ではありません。両者を同じ「追加学習」と呼ぶと、更新方法や根拠の扱いを誤ります。

まず問題の種類を診断する

表は横にスクロールできます

困っていること	最初に調べること	次の候補
規程変更後も古い説明をする	変更資料が検索対象へ反映されているか	RAGの同期・検索を調整
回答に最新の製品条件が必要	正式な情報源と更新頻度	RAGまたは人が確認する参照フロー
毎回出力形式が崩れる	指示、schema、例、制約の十分さ	prompt / structured outputを先に評価
分類の境界がぶれる	誤分類例とラベル定義	評価を整えたうえでfine-tuningを検討
説明の口調が一貫しない	system instructionと修正指示	prompt例で改善し、必要性を再評価

ファインチューニングを選ぶ前に、まず現在のprompt、structured output、評価データで不足を特定します。APIや製品がfine-tuningを提供するか、対象モデル・地域・データ形式が条件を満たすかは変わるため、導入時点で公式仕様を確認してください。特定プロバイダーの提供状況を一般論として断定しません。

問い合わせ対応の設計例

社内サポートで「手当の申請条件を答える」ケースを考えます。申請条件は改定されるため、まずRAGで現行規程の該当箇所を取り出す設計が候補です。回答に規程名、版、該当見出しを添え、資料に見つからない場合は「確認できない」と返すようにします。古いPDFがindexに残っていれば、モデルの調整だけでは問題を直せません。

別の課題として、問い合わせを決められたJSON形式へ分類し、同じ分類基準で処理したいとします。まずラベル定義、入力例、境界例を整え、promptや出力schemaでどこまで安定するかを測ります。それでも一貫した振る舞いが不足する場合、利用できるモデルと現行条件を確かめてfine-tuningを候補にします。ただし事実の根拠は別途検索・参照させる必要があります。

両者を組み合わせるなら、調整したモデルへRAGで現行規程を渡すように役割を分けられます。モデルが文体や分類を安定させ、RAGがその回答に必要な資料を提供する設計です。組み合わせても正確性が自動で保証されるわけではなく、根拠との対応、誤分類、更新反映を別々に評価します。

判断の前に作る評価表

表は横にスクロールできます

テスト入力	RAGで見る点	Fine-tuningで見る点
現行資料に明記された通常質問	正しい文書・版・条件が取得されるか	必要なら出力形式が守られるか
例外条件を含む質問	適用範囲と例外が一緒に検索されるか	例外ラベルの扱いが安定するか
資料にない質問	根拠不足として止まれるか	学習例に引きずられて断定しないか
表現を変えた同じ依頼	関連資料が変わらず見つかるか	同じ基準で分類できるか
資料改定後の質問	新版が検索され旧版が外れるか	外部情報の更新を学習で代用していないか

評価セットには成功例だけでなく、似た語の別制度、矛盾する資料、期限切れ文書、情報が不足した入力を含めます。正解率一つにまとめず、検索の失敗、出力形式、根拠の有無、停止判断を分解して記録します。データを学習へ使う前には、機密情報、個人情報、利用権、保管期間などの条件も確認します。

選択を誤りやすいところ

最新情報が必要なのに、その内容をmodelへ固定的に覚えさせようとすると、更新のたびに再評価・再学習が必要になります。逆に、出力形式のばらつきだけを直したいのに、検索indexを増やしても原因へ届かないことがあります。まず失敗した入力と期待結果を並べ、「必要な情報を持っていない」のか「情報はあるが、応答の仕方が安定しない」のかを見ます。

RAGでは、検索結果が良いことと回答が正しいことは別の評価です。Fine-tuningでは、学習例に似た入力で成功しても未知の言い回しや例外で同じように動くとは限りません。改善後は、未使用の評価データも使って変化を確認し、以前できていたケースが壊れていないか回帰テストします。費用は学習や検索の料金だけでなく、データ整備、評価、運用担当の負荷を含めて見積もります。

AIものさしの判断

社内規程や更新されるFAQのように「何を根拠に答えるか」が課題なら、まずRAGの資料・権限・更新経路を整えます。「どのような形式や手順で答えるか」が課題なら、promptや出力制約を評価し、それでも必要性が残る場合にfine-tuningを検討します。両方の課題がある場合は、情報源と応答傾向を別々に評価してから組み合わせます。

導入前には、現行の公式ドキュメントで提供モデル、料金、入力データ条件を確かめ、同じテストセットで現行方式との比較を行います。必要な改善が測れない、または学習例の権利・品質・保護条件を確認できない場合は、fine-tuningを急がず評価とデータ管理を先に整えます。

方式を決めるための順番

1. 失敗例を集める：期待する答えと実際の答えを並べ、情報不足か振る舞いの不安定さかを分ける。

2. 参照情報を整える：更新される資料なら、正式な版、アクセス権、削除手順を決める。

3. promptと出力制約を試す：schema、指示、例で問題が解消するか同じ評価セットで測る。

4. 必要な層だけ追加する：知識検索と応答傾向の調整を別の役割として設計する。

5. 変更後に回帰評価する：成功例だけでなく、例外、不明、旧版、権限外を再確認する。

この順序は、どの製品でも同じ構成が最適だという主張ではありません。困りごとの原因が分からないまま複雑な仕組みを追加すると、改善した理由も失敗した場所も分かりにくくなるための診断手順です。費用比較ではAPI料金だけでなく、資料の整理、index更新、学習データの作成、評価、監視、人の確認を含めます。

データ準備では、学習へ使ってよい文章か、個人情報や秘密情報を含まないか、誤ったラベルを含んでいないかを確認します。RAG用資料も、検索対象へ置く権利と閲覧させる権限が必要です。利用規約やデータ保持条件はproviderや契約によって異なり、技術的に登録できることは利用許可を意味しません。導入前に公式条件と社内ルールを照合します。

評価結果が改善しても、その仕組みが将来の未知入力で同じ結果を保証するわけではありません。実運用へ出す場合は、対象範囲を限定し、誤答や検索漏れを報告できる方法を用意します。更新時にはデータ版、モデル、prompt、retrieval設定を識別できるようにし、問題が起きたときの切り戻し単位を決めてください。

料金や提供条件を比較する

RAGには、文書保管・index作成・検索・model入力の費用が関係し、fine-tuningにはデータ作成や学習実行、調整モデルの利用費用が関係する場合があります。ただし価格や提供条件はサービス、契約、利用量によって変わるため、ここで一律の費用比較はできません。導入時点の公式料金表と契約条件を確認し、評価・監視・人手確認も含む総運用費を見積もってください。

選択肢の比較では、「安い方式」を先に決めるのでなく、必要な精度、更新頻度、根拠説明、応答形式を満たす構成を絞ります。機密情報を含む場合は、入力データの取扱い、保存、学習利用、削除の条件を公式情報と契約で確認します。

運用上の役割を分ける

RAGでは、誰が参照資料を承認し、いつindexへ反映し、旧版をいつ外すかを決めます。Fine-tuningでは、誰が例を選び、正解ラベルを確認し、学習データの権利と個人情報を確認するかが必要です。いずれも「モデル担当者が用意する」で終わらず、情報の所有者と更新責任者を定めてください。

更新頻度が高い情報をfine-tuningで扱おうとする場合、変更のたびに評価が必要になる可能性があります。逆に、応答形式の一貫性をRAG資料だけで補おうとすると、検索内容と無関係な例を増やすことになります。責任範囲と更新周期を整理し、問題がどの層で起きたか追える状態にしてから選定します。