ソートリーダー

RAGかファインチューニングか？実際の顧客プロジェクトから学んだ選び方

公開日 2026年11月12日

著者

Yaman Kavishwar, 創業者&CEO、VectovateAI

企業のAIについて話すと、ほぼ毎回、最初の1時間以内に同じ選択を迫られます。顧客企業は、デモでは印象的な大規模言語モデルを持っていますが、自社の製品や方針、文章の書き方をモデルは把握していません。その場にいる誰かがこう尋ねます。自社データでモデルをファインチューニングすべきか、それともモデルを中心に検索拡張生成（RAG）を構築すべきか、と。

率直に言えば、この問いの立て方はたいてい間違っています。RAGとファインチューニングは、それぞれ異なる問題を解決するものです。両者を競合する選択肢として扱うチームは、間違った問題を解決するために、何カ月もの時間と多額のGPU予算を費やしがちです。ここでは、実際に私たちがどう判断しているか、そして何がうまくいき、何がうまくいかなかったかを紹介します。

モデルに何が不足しているかを見極める

ビジネス上のタスクでモデルの回答が不十分な場合、原因は次の2つのどちらかです。

知識が不足している。最新の価格表や、2025年の仕入先との契約書にある条項、先月発売された製品のトラブルシューティング手順を把握していません。これは事実に関する問題です。

振る舞いが期待に合わない。必要な知識は持っていても、求めるとおりに応答しません。指定した出力形式を無視したり、適切でないトーンで書いたり、社内コードを誤って解釈したり、チケットを自社の40種類のカテゴリーに分類するような、範囲が狭く繰り返し行うタスクに対応できなかったりします。これはスキルに関する問題です。

前者の問題に適しているのがRAG、後者に適しているのがファインチューニングです。私が目にする混乱の多くは、事実を教えるためにファインチューニングを使おうとすることから生じています。

知識を追加する手段としてファインチューニングが適さない理由

モデルを文書で学習させれば、その内容を「知る」ようになると考えたくなるかもしれません。しかし実際には、文書に書かれた事実よりも、その文体のほうをはるかに確実に学習します。Microsoftの研究者たちは、知識を多く必要とする質問について2つの手法を直接比較し、学習時にモデルが触れていた事実でも、まったく新しい事実でも、RAGは教師なしファインチューニングを一貫して上回ることを明らかにしました。

実務上の問題もあります。事実は変わります。方針やカタログが変わるたびに、モデルを再学習するまで、ファインチューニング済みのモデルは古い情報のままです。また、追跡可能性も失われます。ファインチューニング済みモデルが数値を示しても、その根拠となった文書を特定できません。保険や医療など規制の対象となる分野の顧客では、たいていそれだけで議論は終わります。

RAGは、Lewisらが2020年の論文で初めて説明した手法で、知識をモデルの外部に保持します。質問を受けた時点で関連する文章を検索し、コンテキストとしてモデルに渡します。知識を更新するには、再学習ではなくインデックスを更新します。さらに、すべての回答に情報源を示すことができます。

ある物流企業の顧客事例が好例です。その企業の顧客は、荷物の現在地や不足している書類について、すぐに回答を得たいと考えていました。そうした情報は数分ごとに変わります。モデルをどれほど学習させても最新の状態を保つことはできないため、私たちが構築したアシスタントは、記憶に頼るのではなく、質問を受けた時点で最新の追跡データとIoTデータを参照して回答します。機能する設計は、検索を使う方法だけでした。

ファインチューニングが力を発揮する場面

ファインチューニングは時代遅れではありません。ただ、一般に思われているより用途が限られています。私たちが採用するのは、次の3つの状況です。

厳密で反復的な出力形式。請求書から固定のJSONスキーマに沿って項目を抽出するなど、1日に何千回も同じ構造の出力を生成する必要がある場合、大規模モデルにプロンプトを与えるより、小規模モデルをファインチューニングするほうが信頼性に優れ、費用も大幅に抑えられることがよくあります。
専門分野の用語。基盤モデルが正しく解釈できない略語や略記が使われる分野もあります。物流のステータスコード、臨床現場の略語、社内製品コードなどがよくある例です。比較的小規模なファインチューニングで、こうした問題を解決できます。
大規模運用時のコストと応答時間。タスクの内容が明確になれば、大規模な汎用モデルをファインチューニング済みの小規模モデルに置き換えられます。LoRAなどの手法を使えば、モデル全体ではなく少数の追加パラメーターを学習するだけで済むため、手頃なコストで実現できます。

これらはどれも、事実に関するものではない点に注目してください。すでによく理解しているタスクについて、モデルにどう振る舞うべきかを教えるためのものです。

RAGの失敗の大半は検索の失敗

チームから「RAGを試したが、うまくいかなかった」と言われても、問題がモデルにあることはほとんどありません。問題は検索の段階にあります。モデルの性能は、与えられた文章の質に左右されます。

地味ですが効果的な改善策は、次のとおりです。

文字数ではなく意味に基づいてチャンクを分割する。契約書を500文字ごとに分割すると、条項が途中で切れてしまいます。節や見出しに沿って分割すれば、文脈を保てます。
各チャンクにコンテキストを追加する。「上限は30日」とだけ書かれたチャンクは、どの方針に属するのかが分からなければ役に立ちません。Anthropicの報告によると、インデックス化の前に各チャンクへ短い文書コンテキストを追加する手法は、同社がコンテキスト付与型検索と呼ぶもので、検索失敗を49%減らし、リランキングと組み合わせた場合には67%減らしました。
キーワード検索とベクトル検索を組み合わせる。ベクトル検索は意味の把握に優れていますが、部品番号などの正確な用語には弱い傾向があります。ハイブリッド検索なら、両方に対応できます。
検索精度を個別に検証する。正解となる参照元の箇所が分かっている実際の質問を集め、最終回答を評価する前に、該当箇所が検索結果の上位に表示されるかを測定します。

両方を使うべき場合

本番環境では、最も優れたシステムは多くの場合、RAGとファインチューニングを組み合わせています。RAGが事実を補い、軽くファインチューニングしたモデルが形式、トーン、専門分野の用語を担います。研究も同じ方向に進んでいます。カリフォルニア大学バークレー校のRAFTアプローチでは、取得した文書をより有効に活用し、無関係な文書を無視できるよう、モデルを特化してファインチューニングします。

ただし、順序が重要です。私たちはほぼ例外なく、まずRAGを構築し、どこに課題があるかを測定してから、ファインチューニングに価値があるかどうかを判断します。最初にファインチューニングを行うと、本当の課題が何か分かる前に、トレーニングの費用を支払うことになります。

簡単な判断チェックリスト

タスクは、四半期に1回を超えて変わる事実に依存していますか？その場合はRAGを使いましょう。
ユーザーや監査担当者が、回答の出典を確認する必要がありますか？その場合はRAGを使いましょう。
問題は事実ではなく、回答の形式、トーン、語彙にありますか？ファインチューニングを検討しましょう。
コストや速度が重要となる、大量処理向けの限定的なタスクですか？より小型のモデルのファインチューニングを検討しましょう。
検索品質を単独で測定しましたか？まだなら、ほかのことに取りかかる前に測定しましょう。

要点

RAGとファインチューニングは競合するものではありません。一方はモデルに適切な情報を与え、もう一方はモデルの振る舞いを形作ります。まず実際にどのような問題があるのかを明確にし、モデルのせいにする前に検索を改善しましょう。そして、ファインチューニングは、システムが機能するようになってから取り組む価値のある最適化と捉えてください。機能させるための近道ではありません。