LASSIC Media らしくメディア
LLMファインチューニングとRAGの使い分け・外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- 生成AIを社内データで強化する代表的な手法として、モデル自体を追加学習するファインチューニングと、外部知識を検索して回答に反映するRAGの2つがあります。
- 両者は学習対象・更新性・必要データ量・コストの構造が異なり、目的に応じた使い分けが判断のポイントになります。
- 外注を検討する際は、データの更新頻度と応答の一貫性のどちらを重視するかを整理しておくと、委託先との要件定義がスムーズになります。
目次
LLMのファインチューニングとRAGとは、社内データを生かす2つの手法
LLM(Large Language Model。大規模言語モデル)のファインチューニングとRAGとは、社内データを使って生成AIの回答品質を高める代表的な2つの手法を指します*1*5。前者はモデル自体に追加学習を施す方法で、後者はモデルを学習し直さずに外部知識を検索して回答に反映させる方法です*5。
ファインチューニングは、事前学習済みのモデルに新しい学習データを追加で与え、パラメータそのものを更新する手法です*1。応答の口調や形式を安定させたい場合や、特定タスクへの適応度を高めたい場合に選ばれます。
一方のRAGは、モデルの重みを変えずに、検索した外部知識をプロンプトに加えて回答させる手法です*5。AWSは、モデルの再学習を必要としない費用対効果の高いアプローチだと説明しています*5。どちらを選ぶかは、更新頻度の高いデータをどれだけ扱うかによって変わってきます。
OpenAIとAzureが示すファインチューニングの3つの手法
フルファインチューニング——モデルの全パラメータを更新する方法
フルファインチューニングとは、事前学習済みモデルが持つパラメータ全体を、追加の学習データで更新する手法です。Amazon Bedrockでは、正解ラベル付きのデータを与えてタスクへの適応度を高める方式を教師ありファインチューニング(Supervised Fine-tuning。SFT)と呼んでいます*4。学習後はモデルのパラメータそのものが変化するため、追加学習した内容を更新するには再学習が必要になります*4。
LoRA・PEFT——一部のパラメータだけを効率よく学習する方式
LoRA(Low-Rank Adaptation。低ランク適応)は、事前学習済みモデルの重みを凍結したまま、少量の追加パラメータだけを学習する手法です*3。Hugging Faceが提供するPEFT(Parameter-Efficient Fine-Tuning。パラメータ効率の良いファインチューニング)ライブラリは、この仕組みを用いて計算コストとストレージコストを抑えつつ、フルファインチューニングに匹敵する性能を目指すものです*7。
学習後のLoRAの追加パラメータは元のモデルに統合できるため、推論時の遅延が増えない点も特徴です*3。少量のパラメータを保存すればよいので、複数の用途向けに軽量なアダプタを作り分けやすくなります*3。
SFT・命令チューニング・DPO・RFT——学習データの与え方による分類
ファインチューニングは、学習データの与え方によっても分類できます。OpenAIは、正しい応答例を与えるSFT(命令チューニングとも呼ばれ、指示文と模範回答のペアで学習する方式)、望ましい回答と望ましくない回答を対比させて与えるDPO(Direct Preference Optimization)、評価結果をもとに学習させるRFT(Reinforcement Fine-Tuning)の方式を提供しています*1。Azure OpenAIも、モデルごとにSFT・DPO・RFTのいずれか、または複数の方式に対応しています*2。
必要なデータ量については、Azure OpenAIが具体的な目安を示しています。学習データは最低10件から実行できますが、推奨は100件以上とされ、数百〜数千件規模まで用意するとより効果が見込めるとしています*2。まずは50件程度の質の高いデータから始める進め方が推奨され、データセットの件数を2倍にするとモデルの品質は線形的に向上する傾向も示されています*2。
AWSとHugging Faceが解説するRAGの仕組みと更新性
RAGとは、外部知識を検索してから回答を生成する仕組み
RAG(Retrieval-Augmented Generation。検索拡張生成)とは、モデルが回答を生成する前に、学習データの外にある信頼できる知識源を参照し、その内容を回答に反映させる手法です*5。AWSは、社内の知識ベースや専門分野に対応させる際、モデルの再学習を必要としない費用対効果の高いアプローチだと位置づけています*5。
データ更新の仕組み——非同期処理で最新情報に対応
RAGは、ライブのニュースサイトや社内文書のような更新頻度の高い情報源にも接続できる点が特徴です*5。データが古くなる問題には、文書を非同期で更新し、埋め込み表現(文章の意味を数値化したベクトル情報)を更新し直す方法で対応します*5。この処理は自動化されたリアルタイム処理でも、定期的なバッチ処理でも実行できるとされています*5。
Amazon Bedrock Knowledge Basesのような実装機能では、Amazon S3やSharePoint、Confluenceなど複数のデータソースを取り込み、埋め込み生成・インデックス作成・検索までを一括で管理できます*6。検索結果の並び替えを行うリランキングモデルを組み合わせ、回答に使う情報の精度を高める仕組みも用意されています*6。
コスト・データ量・更新性・精度で比較する使い分けの判断軸
ここまでの内容を、学習対象・更新性・データ量・コストという観点で整理すると、次の表のようになります。
| 項目 | ファインチューニング | RAG |
|---|---|---|
| 学習対象 | モデル自体のパラメータを追加学習します*1。 | モデルは学習し直さず、外部知識を検索して回答に反映します*5。 |
| データ更新の反映 | 新しい情報を反映するには再学習が必要になります*4。 | 文書を追加・更新すれば、非同期の埋め込み処理で反映できます*5。 |
| 必要データ量の目安 | 最低10件から実行できますが、推奨は100件以上です。 数百〜数千件規模まで用意すると効果が見込めます*2。 |
検索対象となる文書や資料が用意できれば着手できます*6。 |
| コストの発生要素 | 学習データの前処理と、学習時のトークン処理量・エポック数に応じた費用がかかります。 モデルの保存費用も発生します*4。 |
検索基盤(ベクトルストアなど)の構築・運用費用と、埋め込みの再計算費用がかかります*6。 |
| 精度が効きやすい領域 | 応答の口調・形式や、特定タスクへの適応の一貫性を安定させやすくなります*1*2。 | 最新情報や社内固有の事実情報を、回答に反映しやすくなります*5。 |
表からわかるとおり、両者は得意な領域が異なります。更新頻度の高い情報を扱うならRAGが向いており、応答の形式や専門タスクへの適応度を安定させたいならファインチューニングが選択肢になります*1*5。
ファインチューニングとRAGを組み合わせるハイブリッド構成
両者は二択ではなく、組み合わせて使う設計も選択肢になります。Amazon Bedrockが提供する蒸留(Distillation。知識を大きなモデルから小さなモデルへ移す手法)は、精度の高い大規模モデル(教師モデル)の応答を使って、より小さく高速なモデル(生徒モデル)を学習させる仕組みです*4。この仕組みを応用すれば、RAGで参照した最新情報への応答パターンを軽量なモデルに学習させ、運用コストを抑える構成も検討できます。
実務では、応答の型や専門用語の使い方をファインチューニングで安定させ、日々更新される社内規程や最新の製品情報はRAGで参照させるという役割分担が取られることもあります。どちらの比重を重くするかは、更新頻度の高いデータがどれだけあるか、応答の一貫性がどれだけ求められるかで変わってきます。
内製で担う場合の必要スキルと工数、外注先選定の視点
ファインチューニングは、学習データの質がそのまま応答品質に反映される手法です。誤ったデータや古い情報を学習させると、その誤りごと回答に定着してしまい、修正には再学習をやり直す手間がかかります*4。RAGでも参照する文書の管理が不十分だと、古い社内規程や誤った情報を検索して回答に反映してしまうおそれがあります*5。
内製で対応する場合、ファインチューニングには学習データセットの設計・前処理、学習結果の評価、モデルの保存・運用までを扱う知識が求められます*1*2。RAGには検索対象文書の整備、埋め込みモデルの選定、ベクトルストア(検索用にベクトル化したデータを保管する基盤)の構築・運用、権限管理までを扱う知識が必要です*5*6。いずれも一度構築すれば終わりではなく、継続的な運用体制が前提になります。
専門パートナーに委託する場合は、要件定義の段階でどちらの手法が適しているかを一緒に判断できるかどうかが分かれ目になります。データ量や更新頻度、求める応答の一貫性を踏まえた設計提案ができるかを、契約前に確認しておくとよいでしょう。
まとめ：ファインチューニングとRAGを選ぶ3つの判断軸
本稿ではLLMのファインチューニングとRAGについて、仕組みと使い分けの視点を整理しました。要点は3つに集約できます。第一に、ファインチューニングはモデル自体を追加学習する手法で、応答の形式や専門タスクへの適応を安定させやすい一方、更新には再学習が必要です*1*4。第二に、RAGはモデルを学習し直さずに外部知識を検索して反映する手法で、最新情報への対応や導入のしやすさに強みがあります*5。第三に、両者は組み合わせて使うこともできるため、更新頻度と応答の一貫性のどちらを重視するかで設計を検討することが実務的です。
よくある質問
ファインチューニングとRAG、どちらから検討すればよいですか。
参照させたい情報の更新頻度が高い場合は、RAGから検討するとよいでしょう*5。応答の口調や形式を安定させたい場合、あるいは特定タスクへの適応を高めたい場合は、ファインチューニングが選択肢になります*1。多くの用途では、どちらか一方に決め切らず、組み合わせを検討する余地もあります。
ファインチューニングは少量のデータでも始められますか。
Azure OpenAIの例では、最低10件の学習データから実行できますが、推奨は100件以上です*2。まずは50件程度の質の高いデータから始め、効果を見ながら件数を増やす進め方が推奨されています*2。
RAGは導入後どれくらいで最新情報に対応できますか。
RAGは文書の更新を非同期の埋め込み処理で反映する仕組みのため、リアルタイム処理を組めば短時間での反映も可能です*5。定期的なバッチ処理を選ぶ場合は、その処理間隔が反映までの時間に直結します*5。
ファインチューニングとRAGは併用できますか。
併用は可能です。Amazon Bedrockが提供する蒸留のような手法を使えば、RAGで得た応答パターンを軽量なモデルに学習させる構成も検討できます*4。どちらを主体にするかは、更新頻度と応答の一貫性への要求度から判断するとよいでしょう。
外注する場合、最初に何を確認すればよいですか。
参照させたい社内データの範囲と更新頻度、求める応答の一貫性を整理したうえで、委託先がその内容を踏まえた設計提案をできるかを確認します。データの取り扱い体制や運用後の保守範囲についても、契約前にすり合わせておくことが大切です。
著者：テレリモ総研編集部 鈴木 亮佑
ITアウトソーシング・システム開発のご相談はLASSICへ
元請(元請（プライムベンダー）)として、貴社の課題に合わせた体制構築・開発支援をご提案します。まずはお気軽にご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：OpenAI「Model optimization」（https://developers.openai.com/api/docs/guides/model-optimization）
- *2 出典：Microsoft「Customize a model with fine-tuning」（Microsoft Foundry / Azure OpenAI ドキュメント）（https://learn.microsoft.com/en-us/azure/ai-services/openai/how-to/fine-tuning）
- *3 出典：Hugging Face「LoRA」（PEFT Conceptual Guides）（https://huggingface.co/docs/peft/main/en/conceptual_guides/lora）
- *4 出典：AWS「Customize your model to improve its performance for your use case」（Amazon Bedrock User Guide）（https://docs.aws.amazon.com/bedrock/latest/userguide/custom-models.html）
- *5 出典：AWS「What is Retrieval-Augmented Generation (RAG)?」（https://aws.amazon.com/what-is/retrieval-augmented-generation/）
- *6 出典：AWS「Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases」（Amazon Bedrock User Guide）（https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html）
- *7 出典：Hugging Face「PEFT」（https://huggingface.co/docs/peft/en/index）
