
RAGかファインチューニングか、知識と振る舞いを分けると迷わない

社内AIに改訂される規程や製品情報を参照させるならRAG、決まった形式での回答や専門タスクの処理を安定させるならファインチューニングを軸にする。Microsoft Foundryの設計ガイドも、頻繁に変わる私的な情報を使う場合と、モデルの振る舞いやタスク性能を変える場合を分けている。知識の参照と出力の制御がともに必要なら、両方を組み合わせる。
この区別は方式の優劣を決めるものではなく、どこに原因があるかを見分けるためのものだ。正しい規程を取得できない問題は検索対象や検索方法に、根拠を渡しても所定の項目を返せない問題は指示や出力制御にある。併用を選ぶ前に、どちらの問題を解く必要があるかを分けると、追加する仕組みの役割が明確になる。
知識の更新と出力の定着は、仕組みが異なる
RAGは質問に関係する文書を検索し、見つかった内容を質問とともにモデルへ渡して回答を作る。AWSの設計ガイドは、複数の社内文書を対象とする質問応答では、モデルを再学習せずに外部の知識を参照できる点を示している。文書を改訂した後は検索対象を更新できるため、回答時に参照させる情報を入れ替えられる。
ファインチューニングでは、入力と望ましい出力の例を用いてモデルを調整する。問い合わせの分類、項目の抽出、一定の文体や順序に沿った回答など、繰り返す処理の改善が主な候補になる。専門知識を調整に使うこともできるが、変更の多い規程をそれだけで扱うと、改訂内容を反映するたびに学習データやモデルを更新する負担が生じる。
出典が必要な業務では、この違いがとくに大きい。RAGなら取得した文書の名前、版、参照箇所を回答と結び付ける設計ができるが、文書を渡しただけで引用が正しくなるわけではない。検索で古い版や権限外の文書を拾えば、整った文章でも根拠としては使えない。ファインチューニング済みモデルの回答だけから、どの社内文書のどの箇所を参照したかを特定することも難しい。
方式を分ける六つの質問
社内AIの用途を決める際は、求める回答そのものに加え、情報の更新、出典、費用と待ち時間を確認する。同じ業務が複数の条件に当てはまる場合でも、知識を取得する機能と出力を整える機能を別々に考えられる。
- 情報は頻繁に変わるか。規程や製品仕様の改訂を早く反映したいならRAGが中心になる。変化の少ない分類基準や表現の決まりを身に付けさせたいなら、調整の効果を検討できる。
- 回答に原文の根拠が必要か。利用者が条項や文書の版を確かめる業務では、検索結果と回答を結び付けられるRAGが適している。回答に出典を表示するだけでなく、その箇所が実際に主張を支えているかも重要になる。
- 失敗は事実の誤りか、形式の乱れか。必要な記述が取得されないなら文書の整備と検索を見直す。正しい記述を渡しても項目の抜けや順序の乱れが続くなら、指示文や出力検証で対応できるかを見たうえで調整を考える。
- 初期に何を用意できるか。RAGには検索可能な文書、改訂を反映する経路、アクセス権の設計が要る。ファインチューニングには良質な入出力例に加え、学習から分離した評価用データが要る。
- 質問ごとのトークン量を許容できるか。RAGは取得した文章を入力に加えるため、長い資料を多数渡せば入力が増える。調整で短い指示や回答にできても、学習と調整済みモデルの運用費用は別にかかる。
- 待ち時間の上限はどこか。RAGでは検索と文書を加えた後の生成を合わせて測る必要がある。回答生成が短くなっても検索処理が増える場合があり、モデル側だけの遅延では利用者の待ち時間を判断できない。
条件付きの例なら、改訂される人事規程の条項を示す用途はRAGが出発点になる。一方、問い合わせを所定の分類へ振り分ける用途は、参照文書の検索より出力の一貫性が中心になる。規程を参照しつつ定型の回答を作る業務では、両方の要件が同時に生じる。
精度の数字は、評価した課題と指標で変わる
米ワシントン州の農業文書を用いた比較研究では、GPT-4の評価指針への適合スコアは、基本構成が75%、RAG付きが80%、調整済みが81%、調整とRAGの併用が86%だった。これは農業分野の質問への回答を、望ましい内容を記した指針に沿って採点した値であり、「完全に正しい回答の割合」とは別の指標である。同じ研究の検索実験では、対象を573文書から3888文書に広げると、関連箇所を上位の検索結果に含めた割合は81.5%から75.0%に下がった。
前半の数字は、調整と検索が同じ課題で補い合う可能性を示す。後半は、資料を増やすだけでは必要な箇所を拾いやすくならないことを示す。社内規程や日本語の問い合わせで同じ順位や改善幅になるとは限らないため、事実の正しさと検索の成否を一つのスコアにまとめると原因を見失う。
たとえば、旧版の条項を答えた場合は文書の更新や版の選択を確認する。正しい版が検索結果にないなら検索の問題であり、正しい箇所を渡しても回答に反映されないなら生成側の問題になる。根拠は合っているのに指定された項目が欠ける場合は、出力形式の問題として分けられる。どの失敗が多いかによって、検索を直すべきか、指示やモデルの調整に進むべきかが変わる。
遅延とトークン量は同じ方向には動かない
AWSのAmazon Novaの比較実験では、MicroとLiteの回答生成の遅延が基本モデル比でファインチューニングにより約50%、RAGにより約30%減った。一方、入出力を合わせた平均トークン量は調整済みモデルで60%超減り、RAGでは参照内容を渡すため2倍超になった。実験はAWSに関する10問を評価に使い、調整には同分野の質問と回答の組を用いている。
RAGでトークンが増えても、この実験では回答生成の遅延は短くなった。ただし、その遅延は検索を含む一連の待ち時間と同じではない。調整済みモデルが短い回答を返すよう学習したことも結果に影響しており、トークン量や遅延の差を別の社内業務の予測値として使うことはできない。
費用も一回のモデル呼び出しだけでは比べられない。RAGでは文書の取り込み、検索基盤、改訂と権限の管理に費用がかかる。ファインチューニングでは学習用データの作成、調整、評価、調整済みモデルの提供方法が費用を左右する。質問が増えるほど毎回の検索処理や入力トークンの差も効くため、初期費用と継続費用を分けて見る必要がある。
併用するのは、検索だけでも調整だけでも要件が残るとき
改訂される規程の内容と条項を答える用途では、最新版を検索できることが先決になる。所定の項目だけを返す分類や抽出の用途では、指示文と出力の検証で要求を満たせる場合がある。それでも同じ種類の形式違反や処理ミスが続くなら、良質な例を使ったファインチューニングが候補になる。
規程を根拠にしながら社内様式の回答も作るなら、RAGで最新版と参照箇所を渡し、調整済みモデルで回答の並びや表現を安定させる構成を検討できる。検索が外した情報を調整で補えるとは限らず、形式が整っていても引用箇所にない内容を加える可能性は残る。併用の価値は、両方の要件で改善が出るかどうかで決まる。
選択に必要なのは、同じ質問群で事実の正確さ、引用箇所の妥当性、形式の遵守、トークン量、検索を含む待ち時間を比べることだ。知識の更新だけで要件を満たせるなら検索の仕組みを中心にし、出力の乱れが残る場合に調整を加える。これなら、併用に伴う費用と運用の複雑さを、改善した要件に結び付けて判断できる。
関連記事:
関連記事
ニュースレターを購読
Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。




