RAGとファインチューニングの違いとは？目的・コスト・更新方法で選ぶ

RAG（Retrieval-Augmented Generation：検索拡張生成）とファインチューニングは、どちらもLLM（大規模言語モデル）を用途へ適応させる方法です。ただし、変更する場所も、更新のタイミングも異なります。

結論から言えば、更新・削除・引用したい情報を外部に置くならRAG、出力形式や分類基準などの振る舞いを学ばせるならファインチューニングが第一候補です。両方の要件があるなら併用できます。少数の例や短い資料で解決するなら、prompt（モデルへ渡す指示）やlong context（長い入力文脈）だけで十分な場合もあります。

この記事では、RAGとファインチューニングの違いを、鮮度、引用、削除、データ、コスト、遅延、運用、評価の8軸で比較します。「どちらが高精度か」を一律に決めるのではなく、自分の用途で試す順序まで落とし込みます。

結論：変えたい場所と更新責任で選ぶ

最初の判断では、次の表を使えます。

この表は絶対則ではありません。RAGにも回答生成のprompt設計が必要で、ファインチューニングで事実を学習させる研究もあります。「知識か振る舞いか」は候補を絞る最初の問いです。最終的には、誰が、何を、いつ更新し、誤りをどこで検出するかまで決めます。

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

両者の違いは、LLMへ独自情報を届ける経路にあります。

RAGは推論時に外部情報を検索する

RAGでは、文書、database、検索indexなどからquery（検索要求）に関係する情報を取得し、その内容をcontextとしてLLMへ渡します。元になったRAG論文は、モデルのparameterに保持されたparametric memoryと、外部から検索するnon-parametric memoryを組み合わせました。

現在よく作られるRAG applicationでは、文書を検索単位へ分けてindexへ登録し、質問時に候補を取得してpromptへ組み込みます。LLMのbase parameterを更新しない構成でも実現できます。詳しい流れは、RAGとは？LLMに外部知識を使わせる仕組みで解説しています。

ファインチューニングは学習でparameterを更新する

ファインチューニングでは、事前学習済みモデルへ追加のtraining dataを与え、目的に合う出力へ近づくようparameterを更新します。すべてのparameterを更新するFull fine-tuningだけでなく、一部だけを効率よく学習するPEFT（Parameter-Efficient Fine-Tuning：更新parameterを抑える追加学習）もあります。

LoRA論文が提案したLoRAは、base weightを固定し、低rankの更新行列を学習するPEFTの一種です。LoRAとファインチューニングは目的の異なる二択ではありません。LoRAは、ファインチューニングをどう効率化するかという更新方法です。SFT（Supervised Fine-Tuning：入力と期待出力の組で行う追加学習）やLoRAの詳細は、Fine-tuningとは？LLMを用途に合わせて調整する方法を参照してください。

8つの軸で比較する

RAGとファインチューニングを同じ粒度で並べると、tradeoff（ある利点を得ると別の負担が増える関係）が見えます。

鮮度だけでなく削除と引用も見る

「最新情報ならRAG」と言われる理由は、検索時に外部sourceを参照できるからです。しかし、元文書を更新しただけで回答が自動的に正しくなるわけではありません。parse、chunk、embedding、index、cacheまで更新が伝わり、正しい文書が検索され、LLMが根拠に沿って答える必要があります。

それでも、文書単位の更新、削除、閲覧権限、引用を要件にするなら、外部sourceを管理できるRAGの方が責任範囲を設計しやすくなります。ファインチューニングしたparameterから、特定の一文だけを確実に消し、回答の出典URLを復元する用途は難しくなります。

dataの形が違う

RAGで必要なのは、検索可能な文書だけではありません。source ID、見出し、更新日時、owner、閲覧権限などのmetadataがなければ、正しい引用や削除、認可を実装しにくくなります。また、質問に対して必要な文書がtop-kへ入るかを測る検索評価dataも必要です。

ファインチューニングでは、学ばせたいbehaviorが伝わる入力と期待出力を用意します。件数だけを増やしても、矛盾、誤答、format揺れ、data leakageがあれば、その癖まで学ぶ可能性があります。学習に使わないholdout set（性能確認用に分離したデータ）と、既存能力が落ちていないかを見るregression testが欠かせません。

用途別にどちらを選ぶか

社内規程・マニュアル検索はRAGから始める

就業規則、製品manual、障害対応手順のように、改訂、廃止、閲覧権限、根拠表示がある文書はRAGと相性がよい領域です。回答と同時に文書名や該当節を表示し、答えが見つからない場合は無理に生成せず、問い合わせ先へ誘導できます。

ただし、RAGを入れれば正確になるとは限りません。答えを含む文書がindexにない、別部署の文書が混ざる、古い版が上位に出る、取得した根拠をモデルが無視する、といった失敗を分けて観測します。

JSON・分類・定型応答はファインチューニングを検討する

問い合わせを決められたlabelへ分類する、長い入力から一定schemaのJSONを出す、tool callの引数を組み立てるなど、正解となる入出力関係を多数用意できるtaskではファインチューニングが候補です。毎回長いfew-shot exampleをpromptへ入れなくても、期待するpatternへ寄せられる可能性があります。

ただし、promptとschema validationで十分な場合もあります。学習前にbaselineを測り、誤りが繰り返し発生し、質のよい教師dataを作れると確認してから進めます。

少量・短文・低頻度なら、どちらも使わない

参照資料が数ページで、質問のたびに全文をcontextへ入れられるなら、検索基盤を構築する必要はないかもしれません。出力形式も数件のexampleで安定するなら、ファインチューニングよりprompt改善の方が変更しやすいでしょう。

RAGとファインチューニングは、必ず導入する機能ではありません。単純なbaselineを持つことで、追加した仕組みが本当に改善したかを比較できます。

コストは構築・更新・推論・評価に分ける

「RAGは安い」「ファインチューニングは高い」という比較だけでは、運用費を見誤ります。モデル、traffic、文書量、更新頻度、内製範囲によって負担の場所が変わるためです。

query-time latency（質問から応答までの遅延）は、RAGでは検索やrerank、長いcontextにより増え得ます。ファインチューニングはqueryごとの検索を必須にしませんが、選ぶmodel sizeやserving構成で遅延は変わります。固定の料金表ではなく、想定trafficと同じtest setで、応答品質、p95 latency（遅い側を含む95パーセンタイルの遅延）、1件当たり費用、更新作業時間を比較します。

精度は共通指標と方式別の診断を分ける

RAGとファインチューニングを比較するとき、最終回答の正解率だけでは改善箇所が分かりません。共通のend-to-end test（利用者へ届く最終結果の評価）と、方式ごとのdiagnostic test（原因を切り分ける評価）を両方持ちます。

共通して見るのは、task成功率、事実性、安全性、遅延、費用です。その上でRAGでは、必要文書が取得できたか、回答が根拠に従ったか、引用が正しいか、権限外文書が混ざらないかを分けます。ファインチューニングでは、未見入力へ一般化するか、formatを守るか、元の能力が落ちていないか、dataの偏りを再現していないかを確認します。

Fine-Tuning or Retrieval?は、対象としたknowledge-intensive taskとunsupervised fine-tuningの条件で、RAGが一貫して上回ったと報告しました。ただし、これはすべてのSFT、すべてのモデル、すべてのtaskでRAGが優れるという意味ではありません。比較研究を採用判断の一般則にせず、自分のdataとfailure caseで再評価します。

RAGとファインチューニングは併用できる

最新の社内文書をRAGで取得し、ファインチューニングしたmodelに「根拠を優先する」「指定schemaで答える」「不足時は回答を控える」といったbehaviorを学ばせる構成が考えられます。

RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agricultureは、対象とした農業data・model・評価条件で、fine-tuningによる改善にRAGの改善が累積したと報告しています。また、RAFTは、domain-specific RAGで関連文書を使い、distractor（回答に不要な取得文書）を無視する能力をpost-trainingで適応させる方法を提示しました。

ここから言えるのは「併用すれば必ず最高精度になる」ことではありません。併用すると、検索data、学習data、model、indexのversion組み合わせが増えます。RAGだけ、ファインチューニングだけのbaselineより改善し、その差が追加運用費に見合う場合に採用します。

最小PoCは失敗原因から機能を足す

PoC（Proof of Concept：小さな実証）では、最初からRAGとファインチューニングを両方作らない方が比較しやすくなります。

1. 評価setを先に作る：代表質問だけでなく、答えがない質問、古い情報、権限外文書、format edge caseを含めます。
2. prompt baselineを測る：system instruction、few-shot、structured outputでどこまで解決するか確認します。
3. 知識不足ならlong contextかRAGを試す：少量文書なら全文投入、文書量・更新・権限・引用が必要ならRAGへ進みます。
4. behaviorの反復誤りならファインチューニングを試す：教師dataを作り、holdoutとregressionで比較します。
5. 両方のfailureが残る場合だけ併用する：RAGの取得結果を使う学習例も含め、組み合わせごとに評価します。
6. 運用指標を加える：品質だけでなく、p95 latency、1件当たり費用、更新時間、誤引用、権限違反を監視します。

比較時には、同じ質問、同じ正解基準、同じ時点のsourceを使います。RAGだけ新しい文書を参照し、ファインチューニングだけ古い学習dataで評価すれば、方式ではなくdata条件の差を測ることになります。

よくある質問

社内データを覚えさせるなら、どちらがよいですか？

「覚えさせる」の意味を分けます。更新・削除・引用・権限管理が必要な社内文書ならRAGが第一候補です。分類基準や出力formatを入力例から学ばせたいならファインチューニングを検討します。両方必要なら併用します。

RAGはファインチューニングより安いですか？

一律には決まりません。RAGにはindexとquery-time処理、ファインチューニングには教師data、学習、評価、再配備の費用があります。想定traffic、更新頻度、文書量を置き、工程別に見積もります。

ファインチューニングで最新情報へ対応できますか？

新しいdataで再学習すれば反映を試みられますが、更新のたびに学習・評価・配備が必要です。頻繁な更新、引用、削除が要件なら、外部sourceを更新できるRAGの方が管理しやすいことが多くなります。

RAGとファインチューニングを両方使えばよいですか？

両方の要件と、単独構成では解消できないfailureがある場合に検討します。併用はversionと評価の組み合わせを増やすため、baselineとの差が運用負担に見合うことを確認します。

まとめ

RAGとファインチューニングの違いは、単なる「外付け検索」と「追加学習」ではありません。RAGは外部sourceとquery-time contextを管理し、ファインチューニングはtraining dataを通してmodel parameterやadapterを更新します。

選択では、変えたい対象に加えて、鮮度、引用、削除、権限、データ準備、遅延、保守、評価を並べます。更新可能な知識にはRAG、安定させたいbehaviorにはファインチューニングを初期仮説とし、少量ならprompt、両方必要なら併用を検討してください。

最終判断は方式名ではなく、同じ評価setで確認したfailureと運用指標から行います。

参考資料

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• LoRA: Low-Rank Adaptation of Large Language Models
• Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs
• RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture
• RAFT: Adapting Language Model to Domain Specific RAG
• Comparing Retrieval Augmented Generation and fine-tuning – AWS Prescriptive Guidance