今回の論文
今回取り上げるのは、Tianjun Zhang、Shishir G. Patil、Naman Jain らによる論文「RAFT: Adapting Language Model to Domain Specific RAG」です。2024 年 3 月に arXiv で公開された論文で、研究分野は RAG、ドメイン適応、LLM の事後学習です。URL は https://doi.org/10.48550/arXiv.2403.10131 です。
この論文を選んだ理由は、RAG の精度改善を「検索器を良くする」だけでなく、「LLM を RAG 向けに学習させる」という観点で整理しているからです。社内文書検索、プロダクト FAQ、業界特化アシスタントのように、ある程度ドメインが決まった用途ではかなり応用しやすい考え方です。
どんな技術か
RAFT は、Retrieval Augmented Fine-Tuning の略で、RAG で渡される文書を前提に LLM を学習させる手法です。
普通の RAG では、検索で取ってきた文書をプロンプトに追加して、その場でモデルに読ませて答えさせます。しかし、事前学習済み LLM は「検索結果の中から必要な文だけ拾い、関係ない文は無視し、根拠付きで答える」ようには必ずしも訓練されていません。そこで RAFT は、学習時から質問と複数文書をセットで与え、正しい文書とノイズ文書が混ざった状況で答える練習をさせます。
ひとことで言えば、RAFT は「RAG を使う本番環境に近い形で LLM を事前に鍛える技術」です。検索付きで使うなら、検索付きの入力を見ながら学習させたほうが強い、という発想です。
課題
RAFT が解決しようとしているのは、ドメイン特化 RAG において、LLM が検索文書をうまく扱えない問題です。
何が難しいのかというと、RAG の失敗は検索器だけでなく、生成側のモデルにも起きるからです。たとえ正解を含む文書が検索されていても、モデルが関係ない断片に引っ張られたり、複数文書の関係を読み違えたり、もともと持っていた知識で埋めてしまったりします。
既存の方法には限界があります。通常の RAG は「学習なしで文書を足すだけ」なので、モデルは本番でいきなり open-book 試験を受けるような状態になります。一方、通常の supervised fine-tuning は質問と回答だけで学習することが多く、文書を読んで答える訓練になっていません。そのため、ドメイン知識への馴染みは出ても、「検索文書から必要情報を拾う力」は十分に伸びないことがあります。
なぜこの課題を解く必要があるのかというと、実際の AI システムでは検索ノイズが避けられないからです。社内規程検索、医療文献 QA、API ドキュメント支援、法務文書参照のような用途では、検索結果に無関係な文や似ているが違う文が混ざります。このとき、モデルが正解文書と distractor を見分けられないと、検索品質がそこそこでも最終回答が崩れます。
つまり RAFT の問題設定は、「検索された文書を渡せば解ける」はずのタスクで、LLM にその読み方をどう学習させるか、という点にあります。
用語解説
- RAG
- 検索で取り出した外部文書をプロンプトに追加して回答させる仕組みです。RAFT はこの推論方式そのものではなく、RAG を前提にした学習レシピを提案しています。
- ドメイン適応
- 汎用 LLM を、医療、社内文書、API 仕様書など特定領域に合わせて強くすることです。RAFT は「そのドメインの文書を参照して答える」能力に焦点を当てた適応手法です。
- distractor document
- 検索結果に混ざる無関係、または答えに役立たない文書です。RAFT ではこのノイズを学習時から混ぜることで、本番の検索ゆらぎに強いモデルを作ろうとします。
- oracle document
- 質問に答えるための正しい根拠を含む文書です。RAFT は oracle document だけでなく distractor も同時に与えることで、「どれを読むべきか」を学ばせます。
- Chain-of-Thought
- 最終回答に至る途中の説明や推論の流れです。RAFT では、単に答えだけを出すより、根拠引用を含む reasoning を作らせたほうが性能が上がることを示しています。
技術の仕組み
RAFT の核は、学習データの作り方にあります。RAG を後付けで足すのではなく、「質問」「複数文書」「根拠付き回答」を 1 セットにして fine-tuning します。
基本アイデア
論文では、既存手法を open-book 試験の比喩で説明しています。普通の RAG は、勉強せずに本番でだけ参考書を開く状態です。通常の fine-tuning は、参考書を見ずに練習問題だけ解く状態に近いです。RAFT はその中間ではなく、「参考書を見ながら、ノイズも混ざった本番に近い形で練習する」設計です。
この発想により、モデルは 2 つの能力を同時に学べます。1 つはドメインの表現や答え方に慣れること、もう 1 つは複数文書の中から答えに必要な根拠を抜き出すことです。
学習データの構成
RAFT の各学習サンプルには、質問、文書集合、回答が含まれます。文書集合には、答えの根拠になる oracle document と、答えに不要な distractor document が混在します。これが重要です。常に正解文書だけを見せるのではなく、検索結果らしいノイズを入れることで、本番の RAG に近づけています。
さらに、論文では一部の学習サンプルでは oracle document をあえて含めず、distractor だけを与える設定も使っています。これによって、モデルが毎回文脈だけに依存するのではなく、必要に応じてドメイン知識も内部化するよう促します。論文では、学習データの 100% に oracle を入れるより、一定割合で外したほうが下流性能が良いケースがあると報告しています。
回答の作り方
RAFT は、答えだけを supervision に使うのではなく、根拠引用を含む Chain-of-Thought 風の回答を学習対象にします。論文では、回答内で根拠文を明示的に引用し、その引用をもとに結論へつなぐ形を使っています。
これはかなり実務的です。RAG では「答えが合っているか」だけでなく、「なぜその文書を採用したか」が重要になることがあります。特に監査、医療、社内ナレッジのような用途では、根拠付きで答える癖を学習させる価値があります。
推論時の流れ
推論時は特別な構造を追加しません。普通の RAG と同じく、質問に対して検索器が top-k 文書を返し、その文書をコンテキストに含めてモデルへ渡します。違うのは、モデルがすでに「複数文書の中から relevant な根拠を見つけ、不要文書を無視する」練習を済ませている点です。
つまり RAFT は、推論アルゴリズムを変える技術ではなく、RAG に最適化された fine-tuning の設計だと言えます。retriever 非依存で使えるのも特徴です。
重要な工夫
RAFT の工夫は大きく 3 つあります。
1. 正解文書とノイズ文書を混ぜて学習する
これによって、モデルは「文書があるから何でも信じる」のではなく、「どの文書が答えに効くか」を読むようになります。RAG の失敗要因を、検索器だけでなく reader 側にも置いているのがポイントです。
2. 根拠引用付きの reasoning を学習する
答えの丸暗記より、どの記述が根拠かを明示させたほうが、文脈理解が安定しやすいという考えです。論文のアブレーションでも、この CoT 付き学習が性能改善に寄与しています。
3. 一部サンプルでは oracle を抜く
これは直感に反する工夫ですが、常に正解文書がある前提で学習すると、モデルが文脈依存に寄りすぎる可能性があります。oracle なしサンプルを混ぜることで、内部知識と文脈読解の両方を使うバランスを取っています。
実験と結果
論文では、RAFT が本当に domain-specific RAG を強化するのか、また CoT や oracle 混合率が効くのかを検証しています。
何を検証したのか
主な検証は 3 つです。1 つ目は、通常の LLaMA2-7B、RAG 付き LLaMA2-7B、通常の domain-specific fine-tuning、domain-specific fine-tuning + RAG と比べて RAFT が強いかどうかです。2 つ目は、CoT 付き回答を学習に入れることが有効かどうかです。3 つ目は、学習時に oracle document をどの割合で含めるのが良いかです。
データセットと評価対象
評価では、PubMed QA、HotpotQA、そして Gorilla の APIBench 系データセットである HuggingFace Hub、Torch Hub、TensorFlow Hub が使われています。つまり、医療文献 QA、複数文書読解、API ドキュメント理解という、かなり性質の違うドメインで見ています。
この選び方が良い点は、単なる一般 QA ではなく、RAG の実務に近い「文書を読んで答える」ケースを含んでいることです。特に API ドキュメント系の評価は、開発支援用途を考えるうえで参考になります。
ベースライン比較
論文の表では、RAFT は多くの設定で一貫して強い結果を出しています。たとえば HotpotQA では、LLaMA2-7B + RAG が 0.03、通常の domain-specific fine-tuning が 6.38、domain-specific fine-tuning + RAG が 4.41 に対して、RAFT は 35.28 でした。HuggingFace データセットでも、domain-specific fine-tuning の 61.06 に対して RAFT は 74.00 まで伸びています。
PubMed QA では差が比較的小さく、domain-specific fine-tuning + RAG の 71.6 に対して RAFT は 73.30 でした。論文でも、PubMed QA は yes/no 型であるため、他タスクほど大差が出にくいと説明されています。逆に言えば、複数文書の選別や文脈読解が重要なタスクほど RAFT の強みが出やすいと読めます。
CoT の有無でどう変わったか
アブレーションでは、CoT なしの RAFT と比べて、CoT ありの RAFT が明確に改善しています。HotpotQA では 25.62 から 35.28、HuggingFace では 59.07 から 74.00 へ伸びています。単に答えだけを学習するより、根拠と reasoning を含めたほうが、文書読解の訓練として効いていることがわかります。
これは実務でも重要です。RAG の fine-tuning データを作るとき、短い QA ペアだけで済ませるより、どこを根拠にしたかまで含めたデータを作る価値が高いと示唆しています。
oracle 文書を常に入れるべきか
論文の面白い点は、学習時に常に oracle document を含めるのが最適とは限らないと示したことです。データセットによって最適な割合は異なりますが、oracle を 100% 入れるより、一部の学習サンプルでは外したほうが downstream の RAG 精度が上がるケースがありました。
結果から言えるのは、RAG 向け学習では「正解文書を読ませる量を増やせばよい」とは限らず、文脈依存と内部知識利用のバランス設計が重要だということです。
何に使える？
RAFT は、検索付き LLM を特定ドメインで本気で使いたいときに向いています。特に、文書集合がある程度固定され、質問の型も繰り返される環境で価値が出やすいです。
社内ナレッジ検索
就業規則、業務マニュアル、FAQ、過去議事録などを参照して答える社内アシスタントで有効です。社内文書は似た表現が多く、検索ノイズも入りやすいため、「文書が出てきても読み間違える」問題が起きます。RAFT を使うと、検索結果の中から relevant な根拠を拾う reader 能力を鍛えやすいです。
API ドキュメントや開発支援
論文でも Gorilla 系データセットで効果が出ています。SDK の使い方、関数シグネチャ、設定パラメータの参照が必要な開発支援では、事前知識だけでなく「今見えているドキュメントを正しく読む」ことが重要です。社内フレームワークや独自 API の Copilot 的支援にも向いています。
医療・法務・規制文書の QA
これらの領域では、モデルの一般知識より、与えられた文書の正確な読解が重要です。特に PubMed QA のような設定で有効性が確認されているため、医療文献探索支援や規程ベース回答への応用可能性があります。ただし実運用では、評価と監査設計を別途入れる必要があります。
顧客サポートや BtoB SaaS のヘルプセンター
製品マニュアル、料金仕様、設定手順、制約事項などを検索しながら答えるサポート bot にも合います。検索文書が複数返る前提なら、retriever の改善だけでなく、generator を RAFT 的に鍛えると回答品質を安定させやすいです。
開発や事業へのヒント
この論文から得られる大きなヒントは、RAG の品質は retriever だけで決まらないということです。プロダクトとして見ると、reader である LLM 側の訓練不足がボトルネックになりえます。
まず「検索精度不足」と決めつけない
RAG の誤答が出たとき、すぐに embedding や reranker の改善へ進みがちです。しかし、正解文書が top-k に入っているのに間違うなら、問題は LLM 側の文脈読解です。自分で AI アプリを作るなら、失敗例を「検索 miss」と「読解 miss」に分けて見るだけでも改善方針が変わります。
小規模プロダクトでも取り入れやすい
大規模学習をしなくても、よくある質問セットと関連文書があるなら、RAFT 的なデータを少量作って SFT する価値があります。特に社内ツールや縦型 SaaS では、対象ドメインが狭いので少量データでも効きやすい可能性があります。これは論文の直接検証範囲を超える推測ですが、ドメインが狭いほど有利という方向性は自然です。
根拠付き学習データは資産になる
RAFT の考え方を採ると、単なる QA ログより、「どの文書のどこを根拠に答えたか」が入ったデータの価値が上がります。これはモデル改善だけでなく、監査、評価、FAQ 整備にもつながります。プロダクト運営上も、回答理由をデータ化する意味が大きいです。
今後注目すべき方向性
今後は、RAFT を reranker 学習、query rewriting、retrieval planning、citation verification などと組み合わせる流れが強くなりそうです。特に agent 型 RAG では、検索の前後で複数ステップの判断が入るため、「読む能力」を明示的に学習させる重要性はさらに上がるはずです。ここは将来方向の考察です。
限界
RAFT にも限界があります。まず、学習データ作成のコストが高いです。質問、正解文書、distractor、根拠付き reasoning をそろえる必要があり、普通の instruction tuning よりデータ設計が重くなります。
また、効果はドメインの性質に依存します。PubMed QA のように yes/no 型で、文書選別より回答形式が支配的なタスクでは、改善幅がそこまで大きくありません。逆に、複数文書の読解やノイズ耐性が重要なタスクほど向いています。
実装面では、retriever が極端に弱い場合、RAFT だけでは限界があります。推論時に正解文書がそもそも入ってこなければ、reader を鍛えても救えません。つまり、RAFT は retriever を不要にする技術ではなく、retriever と generator の間を埋める技術です。
さらに、論文は主に in-domain RAG を対象にしています。頻繁に文書集合が変わるケースや、未知ドメインへ横断的に使うケースでどこまで効くかは追加検証が必要です。
よくある質問
Q. RAFT は普通の RAG と何が違うのですか？
A. 普通の RAG は推論時に文書を追加するだけですが、RAFT は学習時から「質問 + 複数文書 + 根拠付き回答」で LLM を鍛えます。つまり、検索文書の読み方そのものを学習させる点が違います。
Q. RAFT は retriever を改善する手法ですか？
A. いいえ、中心は generator 側の fine-tuning です。retriever 非依存で使えますが、推論時に正解文書が top-k に入ってくることは前提になります。retriever の改善を置き換えるものではありません。
Q. どんなタスクで特に効きやすいですか？
A. 複数文書の中から必要な根拠を選ぶ必要があるタスクで効きやすいです。たとえば社内文書 QA、API ドキュメント支援、マニュアル検索、複数ページを横断する質問応答などです。
Q. 学習データは必ず CoT 付きにすべきですか？
A. 論文では CoT 付きのほうが複数データセットで良い結果でした。そのため、根拠引用や reasoning を含めたほうが有望です。ただし、実務では長すぎる CoT がコストや回答速度に影響するため、どこまで出力させるかは設計次第です。
Q. 小規模なチームでも試せますか？
A. 試せます。大規模な研究実装をそのまま再現しなくても、少数の高品質 QA と関連文書から RAFT 風データを作り、LoRA などで軽量に調整するアプローチは現実的です。これは論文の直接結果ではなく、実装への応用案です。
今日の学び
この論文は、ドメイン特化 RAG で LLM が検索文書をうまく読めず、ノイズ文書に引っ張られる課題を扱いました。これに対して RAFT は、正解文書と distractor を混ぜた文脈、さらに根拠付き reasoning を使って fine-tuning することで解こうとしました。
ここから得られるヒントは、RAG の改善は検索器だけでは足りず、LLM に「文書を読んで答える練習」をさせる価値が高いということです。特定ドメインの検索付き AI を作るなら、推論設計だけでなく学習データ設計そのものが競争力になります。