RAG・ファインチューニング・ロングコンテキスト — 自分の問題には何を使うべきか：論文が実際に測ったもの、そして誰も測っていないもの

はじめに — 答えから言うと
3つは同じ問題を解いていない
ファインチューニングで知識を注入できるか — 2つの論文が正反対に見える理由
- 農業論文の数字をそのまま信じる前に
- そして新しい知識を無理に注入すると起きること
ロングコンテキストはどこで崩れるか — 位置、長さ、語彙
RAGはロングコンテキストより安いのか — Self-Routeが実際に測ったもの
ところがベンチマーク自体が汚染されている — 本稿で最も重要な部分
2026年に変わったこと — キャッシングはロングコンテキストをタダにしない
それで何を見るべきか — あなたが実際に測れるもの
いつ使ってはいけないか
誰も答えていないこと
おわりに
参考資料

はじめに — 答えから言うと

「うちの文書でチャットボットを作りたいのですが、RAGを使うべきですか、ファインチューニングをすべきですか、それとも100万トークンのコンテキストに全部入れてしまえばいいですか?」おそらくLLMアーキテクチャで最も頻繁に出る質問でしょう。そして検索して出てくる答えの大半は、出典が一つもない意思決定ツリーです。「最新情報が必要ならRAG、スタイルが必要ならファインチューニング」 — 間違いではないのですが、これでは何も決められません。なぜそうなのか、どの程度そうなのか、どこで崩れるのかが書かれていないからです。

そこで本稿は測定されたものだけで答えます。結論を先に書くとこうなります。

3つはそもそも競合関係にありません。 ファインチューニングが新しい事実をモデルに注入することに失敗するというのは、複数の論文で繰り返し測定された結果です。したがって「知識」が問題なら、選択肢は実質的に2つです。
残る選択(RAG vs ロングコンテキスト)は、あなたが自分で測れる一つの属性でほぼ決まります — あなたのコーパスでrecall@k曲線がどこで飽和するか。これはベンチマークではなく、半日もあれば測れる数字です。
そして正直であるべき部分 — この3つを単一の共通ベンチマークで比較した研究は、私が確認した範囲では存在しません。論文ごとに異なるモデル・異なるデータセット・異なる指標を使っています。だからA論文の数字とB論文の数字を並べて比較してはいけません。

以下がその根拠です。それぞれの数字が何を測り、何を測っていないかまで併せて書きます。

3つは同じ問題を解いていない

まず軸を整理する必要があります。3つの方式はよく並べて語られますが、実際には互いに異なるものを変えています。

ファインチューニングは重みを変えます。モデルがどのように答えるかを変える道具です。
RAGはプロンプトに何を入れるかを変えます。検索で選んだ断片だけを入れます。
ロングコンテキストもプロンプトに何を入れるかを変えます。ただし選ばずに全部入れます。

つまりRAGとロングコンテキストは同じ軸(プロンプトに何を入れるか)の両極端であり、ファインチューニングは別の軸です。Gekhmanら(arXiv:2405.05904)の結論の一文が、この構図を最も凝縮して表現しています — 大規模言語モデルは事実知識の大部分を事前学習で獲得し、ファインチューニングはその知識をより効率的に使うよう教える、という見方を裏付けると論文は書いています。

この一文が正しいなら、「社内文書をファインチューニングで学習させる」という計画は、出発点から道具の選択を誤っていることになります。ところが実務では正反対のケーススタディも出回っています。まずその矛盾から解かなければなりません。

ファインチューニングで知識を注入できるか — 2つの論文が正反対に見える理由

否定側。 Ovadiaらの "Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs"(arXiv:2312.05934)は、知識注入を正面から測ります。結論は明快です — 教師なしファインチューニングも一定の改善を与えるが、RAGは一貫してそれを上回る。学習時に見た既存知識でも、完全に新しい知識でもそうである。そしてモデルは、教師なしファインチューニングで新しい事実情報を学ぶことに困難を抱える。

肯定側。 Microsoftの "RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture"(arXiv:2401.08406)は逆に見えます。アブストラクトの表現そのまま — ファインチューニングで正確度が6 p.p.以上上がり、これはRAGと累積して、さらに5 p.p.上がった。

2つの結果は矛盾しているのでしょうか? いいえ。測っている介入がそもそも別物なのです。

Ovadiaらの言うファインチューニングは教師なしファインチューニング、すなわち継続事前学習(continual pre-training)です。論文は、この方式を研究全体を通して使うと明記しています。生のテキストをそのまま与えて次のトークンを予測させる方式です。より重要なのは、論文が教師ありファインチューニング(インストラクションチューニング)をそもそも候補から除外した際に書いた理由です — インストラクションチューニングが必ずしもモデルに新しい知識を教えるわけではなく、したがってインストラクションチューニングだけでは知識注入問題の解法になり得ない。

一方、農業論文のパイプラインはQ&Aペアでファインチューニングします。文書から質問・回答ペアを生成し、それで学習させます。完全に別の介入です。

整理するとこうです。「ファインチューニング」という一つの単語が少なくとも2つの異なる作業を指しており、2つの論文はそれぞれ別の側を測りました。ブログ記事たちがこの2つを混ぜて引用することで、「ファインチューニングは効くこともあれば効かないこともある」という、結論のない結論が作られています。

農業論文の数字をそのまま信じる前に

肯定側の根拠を引用するなら、その根拠の限界も一緒に見るのが公平です。論文のTable 18はこうです。

モデル                 ファインチューニング   正確度      +RAG
Llama-2-chat 13B                             76% ±2%    75% ±2%
Vicuna                                       72% ±2%    79% ±2%
GPT-4                                        75% ±3%    80% ±4%
Llama2 13B                      O            68% ±3%    77% ±2%
GPT-4                           O            81% ±5%    86% ±2%

算数は正確に合っています。GPT-4基準で75% → 81%がアブストラクトの「6 p.p.以上」、81% → 86%が「RAGでさらに5 p.p.」です。ただし、3つの点を指摘しなければなりません。

誤差範囲が重なっています。 75% ±3%の区間は72~78で、81% ±5%の区間は76~86です。76~78の区間で重なります。そして論文は、この ± の値が標準偏差なのか信頼区間なのかを定義しておらず、有意性検定も提示していません。6 p.p.を「確実な改善」と読むのは根拠を超えています。
ドメインファインチューニングがむしろ負けたケースが表の中にあります。 農業データでファインチューニングしたLlama2 13Bは68%で、汎用のインストラクションチューニングモデルであるLlama-2-chat 13Bの76%より低いのです。(ただし出発チェックポイントが異なります — 前者はベースモデルを、後者はchatモデルを使います。それでも「ドメインデータでチューニングすればドメイン課題で勝つ」という直観が自動的には成立しない、という点は明らかです。)
学習ラベルがLLM生成物であり、採点者もLLMです。 ファインチューニング用の回答はLlama2-13B-chatにRAGを付けて生成し、評価はGPT-4が行いました。つまりこの実験はかなりの部分、「RAGパイプラインの出力をモデルに蒸留(distill)した」ものに近いのです。

そして新しい知識を無理に注入すると起きること

Gekhmanら(arXiv:2405.05904)は、ここからさらに一歩進みます。ファインチューニング例のうち新しい知識を導入する比率を統制しながら観察した結果、新しい知識を含む例は、モデルがすでに知っていることと一致する例よりも目に見えて遅く学習されます。ところが最終的に学習されてしまうと、それらの例はモデルの幻覚(ハルシネーション)傾向を線形に増加させます。

論文の表現をそのまま移すと — 新しい事実知識をファインチューニングで導入することには危険がある、ということを結果は示している。「学習は遅く、学習し終えると幻覚が増える」という組み合わせは、実務では最悪です。学習損失は下がっているのにプロダクション品質は悪化する、という形で現れるからです。

実務への含意：頻繁に変わる事実をファインチューニングで注入しないでください。ファインチューニングは、形式・口調・ドメイン用語・出力構造のような振る舞いを変えることに使ってください。LoRAでそれをやるときにハイパーパラメータがどう絡み合うかは、LoRA rankと学習率の回で別途扱います。

ロングコンテキストはどこで崩れるか — 位置、長さ、語彙

では全部入れればいいのでは? コンテキストウィンドウは100万トークンあるのだから。ここには、互いに異なる3つの測定された失敗モードがあります。

位置。 Liuらの "Lost in the Middle"(arXiv:2307.03172)は、関連情報の位置を変えながら性能を測りました。結果はよく知られたU字カーブです — 関連情報が入力の最初か最後にあるとき性能が最も高く、長いコンテキストの中間にあるとき大きく落ちます。論文は、これが明示的にロングコンテキストを謳うモデルでも現れると釘を刺しています。

長さ。 Databricksの "Long Context RAG Performance of Large Language Models"(arXiv:2411.03538)は、20のオープンソース・商用モデルに対して、コンテキスト長を2,000から128,000トークンまで(可能な場合は200万まで)変えながらRAGワークフローを回しました。3つのドメインデータセットを使います。核心の結果はアブストラクトにあります — 文書をより多く検索すれば性能は上がり得るが、64kトークンを超える長さで一貫した正確度を維持できるモデルは、最新のSOTAの中でもごく少数にすぎない。

本文はさらに具体的です。分析した大多数のモデルで、RAG性能が上がる区間は16k~32kトークンまででした。Qwen 2 70Bは64kまで一貫した正確度を維持し、Llama 3.1 405Bは32k以降性能が落ち始め、GPT-4-0125-previewは64k以降落ちます。

さらに興味深いのは、失敗の仕方がモデルごとに違うことです。Claude 3 Sonnetは著作権の懸念を理由に回答をしばしば拒否し、Gemini 1.5 Proは過度に敏感な安全フィルタのために長いコンテキストで課題に失敗し、Mixtral-8x7Bは繰り返しや無作為な内容を吐き、DBRXは16k以上で指示に従わず内容を要約してしまうことが頻発しました。つまり「ロングコンテキストで悪くなる」という言葉すら、単一の現象ではありません — 拒否、安全フィルタ、繰り返し、指示無視が、それぞれ別のモデルで現れます。

語彙。 NoLiMa(arXiv:2502.05167)は最も不都合な結果です。既存のneedle-in-a-haystackテストは、針と干し草の山のあいだに文字どおりの語彙一致があり、モデルがそれを利用して課題を簡単にできてしまう — というのがこの論文の指摘です。そこで質問と針の語彙的重複を最小化するよう設計したところ、128K以上をサポートすると主張する13のモデルを評価した結果、短いコンテキストでは良好だったモデルたちの性能が、長さが伸びるにつれて大きく落ちました。32Kで11のモデルが自身の短い長さのベースライン比50%を下回り、最上位だったGPT-4oでさえ、ほぼ完璧な99.3%のベースラインから69.7%へ下がりました。

ここで重要な含意があります。needle-in-a-haystackを通過したことは、ロングコンテキストが機能する証拠ではありません。 あのテストは、語彙一致という近道を許していました。実際の質問は、たいてい文書と同じ単語を使いません。

正直な限界：上の3つの研究が評価したモデルはすべて2023~2024年世代です(NoLiMaは2025年改訂)。2026年のフロンティアモデルで同じ曲線が出るかを、同じ方法論で再測定した公開研究を、私は確認できていません。

RAGはロングコンテキストより安いのか — Self-Routeが実際に測ったもの

コストの側で最も多く引用されるのが、GoogleのSelf-Route論文(Liら、arXiv:2407.16833)です。実際の表を見ましょう。Contriever検索器基準、9つのデータセットの平均です。

Gemini-1.5-Pro       LC 49.70 | RAG 37.33 | Self-Route 46.41 | トークン 38.39%
GPT-4O               LC 48.67 | RAG 32.60 | Self-Route 48.89 | トークン 61.40%
GPT-3.5-Turbo        LC 32.07 | RAG 30.33 | Self-Route 35.32 | トークン 38.85%

読み方はこうです。リソースが十分ならLCはRAGに一貫して勝ちます — 49.70対37.33は小さな差ではありません。しかしSelf-Route(簡単な質問はRAGへ、RAGが「答えられない」と判断したものだけLCへ)は、LCのトークンの38~61%だけを使いながらLCに肉薄します。

なぜこれが成り立つのかが、この論文の本当の発見です — 63%のクエリでモデルの予測が完全に同一であり、70%のクエリでスコア差が10未満でした。そして論文は一つ付け加えています — 同一の予測が必ずしも正解というわけではなく、RAGとLCは同じ正解だけでなく同じ間違いもする傾向がある、と。つまり大半の質問で、2つの方式はそもそも区別がつきません。高い方を使う理由がないのです。

コストの数値は注意して引用すべきです。 論文本文は、Gemini-1.5-Proでコストが65%、GPT-4Oで39%削減されたと書いています。GPT-4Oは算数がぴったり合います — トークンの61.40%を使うので38.6%の削減、四捨五入して39%です。ところがGemini-1.5-Proはトークンの38.39%を使うので削減は約61.6%のはずで、Dragon検索器を使ったTable 2でもトークン比率は37.87%(約62.1%の削減)です。論文の言う65%は、論文自身の表から約3 p.p.外れています。 大きな問題ではありませんが、「65%」をそのまま書き写す前に知ってはおくべきです。

そして決定的な限界：この論文が使ったモデルはgpt-3.5-turbo-0125、gpt-4o-2024-05-13、Gemini-1.5-Proです。2024年のモデルです。データセットはLongBench(平均コンテキスト約7k単語)と∞Bench(平均約100kトークン)で、ここで言う「ロングコンテキスト」は100万トークンではなく7k~100kです。

2026年には後続研究があります。"Route Before Retrieve"(arXiv:2605.10235、2026年5月)は、Self-RouteがまずRAGを試して失敗したらLCに切り替える受動的なフォールバックである点を指摘し、検索の前にメタデータ(文書タイプ、長さ、冒頭のスニペット)でルーティングを先に決める方式を提案します。方向性そのものが、「質問ごとに違う道具」というSelf-Routeの洞察を保ちながら、そのコストをさらに下げる側へ進んでいるというシグナルです。

ところがベンチマーク自体が汚染されている — 本稿で最も重要な部分

ここまでの数字をすべて揺るがす発見が一つあります。

"Long Context vs. RAG for LLMs: An Evaluation and Revisits"(arXiv:2501.01880)は、既存研究を再検討しながら、それらの中核的な洞察との不一致を指摘します。そして、非常に単純なのに誰もやっていなかったことをやります — 外部コンテキストなしでも答えられる質問をふるい落とすのです。 現代のLLMはパラメータにエンコードされた知識だけで多くの質問に答えられるので、長い文書でどちらがより役立つかを判断するには、モデルがコンテキストなしでは正解できない質問だけを残すべきだ、という論理です。フィルタリングにはGPT-4oを使い、厳格なexact-match採点を適用します。

結果はこうです。

データセット       全質問数    残った質問   維持率
Coursera                172          54     32%
NQ                    1,109         373     34%
NovelQA               2,283         869     38%
2WikiMHQA             2,300       1,036     45%
HotpotQA              2,200       1,113     51%
MultiFieldQA            150         121     81%
NarrativeQA           2,211       1,880     85%
QASPER                2,718       2,674     98%
QuALTY                2,725       2,725    100%
TOEFL-QA                962         962    100%
MultiDoc2Dial           158         158    100%
─────────────────────────────────────────────────
合計                 19,188      13,628     71%

Natural Questionsでは維持率が34%です。 言い換えれば、NQの質問の約3分の2は、GPT-4oがコンテキストを一つも与えられずに正解します。Courseraは32%、NovelQAは38%です。

これがなぜ致命的かというと — これらのベンチマークの上で「RAG対ロングコンテキスト」のスコアを測ると、そのスコアのかなりの部分は検索ではなくモデルの事前学習知識を測っていることになるからです。そして、先に引用したDatabricksの研究が使った3つのデータセットのうちの一つが、まさにNQです。

ここから出てくる実務的な結論が、本稿で最も重要です。あなたの社内文書は、モデルの事前学習データにはありません。 だから、公開ベンチマークで出たRAG対LCの比率を、あなたのコーパスにそのまま持ち込んではいけません。ベンチマークではモデルが答えのかなりの部分をすでに知っていて、あなたのコーパスでは何一つ知りません。条件が違うのです。

付け加えると、この論文の結論自体も、先行研究と微妙に異なります — QAベンチマーク、特にウィキペディアベースの質問ではLCがおおむねRAGを上回り、要約ベースの検索はLCに近く、チャンクベースの検索は後れを取る。ただし対話ベースのクエリと一般的なクエリではRAGが有利である。「RAGが勝つ/負ける」が、データセットの種類によってひっくり返るということです。

2026年に変わったこと — キャッシングはロングコンテキストをタダにしない

Self-Routeのコストモデルは単純です。論文自身が書いたとおり、LLM APIの価格は通常入力トークン数に基づくので、トークンを少なく使えばその分安い、というものです。2024年には正しいモデルでした。

その間に、プロンプトキャッシングが一般化しました。安定したプレフィックス(接頭部)をキャッシュに載せておけば、再利用時にはずっと安くなります。Anthropicが文書化している自社の構造を例にとると、キャッシュ読み取りは基本入力価格の約0.1倍で、キャッシュ書き込みは5分TTLで1.25倍、1時間TTLで2倍です。キャッシュ可能な最小プレフィックス長もモデルごとに異なります(例: Opus 4.8は4,096トークン、Sonnet 4.6は2,048トークン)。ここで自然な反論が出てきます — コーパスが安定していてクエリが繰り返されるなら、丸ごとキャッシュに載せておけば、Self-Routeのコスト論理は崩れるのではないか?

部分的にしかそうなりません。 2026年3月の "Beyond the Context Window"(arXiv:2603.04814)が、これを実際に測りました。プロンプトキャッシングを含むコストモデルを立て、事実ベースのメモリシステム(Mem0)とロングコンテキスト推論を比較した研究です。核心の一文はこれです — ロングコンテキスト推論はキャッシングを適用してもコンテキスト長に比例して大きくなるターンあたりコストを支払うのに対し、メモリシステムのターンあたり読み取りコストは、一回きりの書き込み段階のあとはほぼ固定される。

測定値はこうです(LongMemEval、500の対話、平均コンテキスト101,601トークン)。

                          コスト
メモリ書き込み(1回)       $0.0435 / 対話        (計 $21.76、500対話)
メモリ読み取り            $0.0013 / クエリ      (計 $0.65、500質問)
LC GPT-5-mini             $0.0293 / リクエスト  (計 $14.79、504リクエスト)
LC 初回ターン(モデル値)   $0.0265
─────────────────────────────────────────────────────────────
損益分岐: 約10ターン (100kコンテキスト)。N=20でメモリが26%安い。
コンテキストが長くなるほど、分岐点は13ターン -> 9ターンへ下がる。

算数は合っています($21.76を500で割ると$0.0435、$14.79を504で割ると$0.0293)。だから、ターン数が少なければロングコンテキストが安く、多ければ検索が安いのです。キャッシングはこの曲線の傾きを下げるだけで、向きを反転させることはできません。

ところが、この論文を引用するときに必ず一緒に言わなければならないことがあります。精度ではロングコンテキストが大きく勝ちました。

データセット      メモリシステム   LC GPT-5-mini   LC GPT-OSS-120B
LoCoMo                  57.68           92.85            81.69
PersonaMem v2           62.48           69.75            60.50
LongMemEval             49.00           82.40            48.20

LoCoMoで57.68対92.85、LongMemEvalで49.00対82.40です。安い側が、精度で大きく負けました。論文はその理由も書いています — 全履歴を渡せばすべてのディテールが保存されるが、メモリパイプラインは約101,600トークンの対話をユーザーあたり平均2,909トークンの原子的事実へ圧縮するので、圧縮過程での情報損失は避けられない、というのです。

適用範囲の限定：この研究が測ったのは持続型対話エージェントのメモリシステムであって、文書コーパスのRAGではありません。コスト構造に関する洞察(「検索はターンあたり固定、ロングコンテキストはキャッシングしても長さに比例」)は一般化できますが、精度の数字は対話メモリベンチマークのものです。そのまま持ち込んではいけません。

キャッシングの効果自体は、別途測定されています。"Don't Break the Cache"(arXiv:2601.06007)は、3つのプロバイダにわたる500以上のエージェントセッションでキャッシングを測定し、コスト削減が41%から80%の範囲、TTFT改善が13%から31%の範囲だと報告します。ただしこの論文も、エージェント型のツール呼び出しワークロード(DeepResearch Bench)を測ったものであり、全コンテキストをキャッシュする戦略ではTTFT改善がないか、わずかな退行が見られたと書いています。そしてこの論文自身が明かすとおり、著者らの知る限り、マルチターンのエージェント課題でこのコスト削減を定量化した先行研究はありませんでした。

それで何を見るべきか — あなたが実際に測れるもの

ここからが決定ルールです。核心は、ベンチマークを読むのではなく、あなたのコーパスを測れということです。そして最初に測るべき数字は、一つだけです。

ステップ1：recall@k曲線を描く(これがほぼすべてを決めます)

Databricks論文が付録に入れておいた表が、事実上この方法論のテンプレートです。text-embedding-3-largeで、各データセットのrecall@kをコンテキスト長別に測ったものです。

コンテキスト長       2k     4k     8k    16k    32k    64k    96k   128k
Databricks DocsQA  0.547  0.856  0.906  0.957  0.978  0.986  0.993  0.993
FinanceBench       0.097  0.287  0.493  0.603  0.764  0.856  0.916  0.916
NQ                 0.845  0.992  1.000  1.000  1.000  1.000  1.000  1.000

論文の解釈そのまま — 各データセットの検索recallが飽和するコンテキスト長は異なります。NQは8kで早く飽和し、DocsQAとFinanceBenchはそれぞれ96kと128kで飽和します。

この曲線があなたの答えです。

小さいkで飽和するなら(NQのように) — 答えが局所的です。検索が8k以内で、すでにすべての根拠を持ってきています。ロングコンテキストは何も追加せず、妨害文書(distractor)だけを増やします。RAGを使ってください。 ここでコンテキストを増やすのは純粋な損です。
96k~128kまで上がり続けるなら(FinanceBenchのように) — 根拠が広く散らばっています。ここが、ロングコンテキストが値打ちを発揮しうる唯一の領域です。ただし条件があります(ステップ2)。
最後まで良くならないなら — FinanceBenchは128kでも0.916です。100%に到達しません。検索がボトルネックか(チャンキング・埋め込みの問題)、そもそも検索で解く問題ではないかです。後者ならハイブリッド検索とリランキングを先に試し、それでもだめなら、質問が「検索」ではなく「総合」を要求しているのかもしれません — そのときがGraph RAGを検討する地点です。

そして、Databricks論文が付けた警告を必ず一緒に読むべきです — 検索の正確度は単調に増加するが、それはRAGの正確度が単調に増加するという意味ではない。コンテキストを増やせばrecallは上がり、生成は悪化します。だから最適点は両端ではなく中間のどこかにあります。これは、曲線を描いてはじめて見つかります。

測り方は難しくありません。正解文書がわかっている質問を50~100個作り、kを変えながら、正解文書が上位kに入る比率を数えるだけです。これはLLM呼び出しが不要な純粋な検索指標なので、安くて速いのです。

ステップ2：モデルがその長さで持ちこたえるか確認する

ステップ1で「96kまで上がる」と出たからといって、96kを入れればいいわけではありません。Databricksの測定では、大多数のモデルは16k~32kですでに性能が折れていました。そしてNoLiMaが示したとおり、質問と文書の語彙が重ならなければ、32Kで大部分のモデルが崩れます。あなたの質問は、文書と同じ単語を使っていますか? 普通は使っていません。

ステップ3：更新頻度を見る

コーパスが頻繁に変わるなら、ファインチューニングは候補から外れます(変わるたびに再学習)。ロングコンテキストもキャッシングの利得が消えます(プレフィックスが変わればキャッシュは無効化され、デフォルトのTTLは分単位です)。頻繁に変わるコーパスでは、RAGがデフォルトです。

ステップ4：知識か行動か

「うちの口調で答えさせたい」/「このJSONスキーマだけで」/「このドメインの略語を理解させたい」→ ファインチューニング。「この文書に何と書いてあるか」→ 検索。この2つを混ぜないでください。OvadiaとGekhmanの結果が言っているのは、正確にこれです。

ステップ5：ターン数で予算を計算する

同じコンテキストに質問を何回投げますか? "Beyond the Context Window" の構造を借りれば — ターンが少なければロングコンテキストが安く、多ければ検索が安い。100kコンテキストでの分岐点は約10ターンでした。文書1つにつき質問1つならロングコンテキストが有利になり得ますし、同じコーパスに数千のクエリが来るなら検索が圧倒的です。

いつ使ってはいけないか

最も引用に値する部分は、たいていここです。

ファインチューニングを事実の注入に使わないでください。 学習は遅く、学習し終えると幻覚が増えます(Gekhmanら)。社内wikiをファインチューニングするプロジェクトは、ほぼ常に道具の選択ミスです。
コンテキストウィンドウが100万だからという理由でロングコンテキストを使わないでください。 ウィンドウサイズは容量であって能力ではありません。NoLiMa基準では、32Kで13のうち11のモデルが自身のベースラインの半分を下回りました。
needle-in-a-haystackの通過を根拠にしないでください。 あのテストは、語彙一致という近道を許しています。
recallが小さいkで飽和しているのに、コンテキストを増やさないでください。 妨害文書だけが増え、lost-in-the-middleに入ります。
公開ベンチマークのRAG対LC比率を、あなたのコーパスに持ち込まないでください。 NQの質問の約3分の2は、コンテキストなしでも解けます。あなたの文書はそうではありません。
そして、本稿の数字もあなたのコーパスの答えではありません。 すべて他人のコーパス、他人のモデルから出たものです。

誰も答えていないこと

正直に書くべき部分です。以下は、私が確認した範囲で、公開された研究が答えていない質問です。

3つの方式を単一の共通ベンチマークで比較した研究がありません。 RAG対LC(Self-Route、2501.01880)とRAG対ファインチューニング(Ovadia、農業論文)はそれぞれ存在しますが、互いに異なるモデル・データセット・指標を使っています。だから「RAGはLCより12点低く、ファインチューニングは6 p.p.上げるから、RAG+ファインチューニングは…」のような計算は成立しません。本稿でもやっていません。
2026年のフロンティアモデルで、RAG対LCをキャッシングまで反映して再測定した研究がありません。 Self-Routeは2024年のモデルと、トークンベースのコストモデルを使います。キャッシング認識のコストモデルは2603.04814が立てましたが、対象は対話メモリであって文書RAGではありません。
キャッシングのエージェントワークロードへの効果すら、ごく最近になって測定されたばかりです。 2601.06007は、自分たちの知る限り、マルチターンのエージェント課題でこのコスト削減を定量化した先行研究はないと明記しています。
ファインチューニング方式別の知識注入効果を統制比較した研究が不足しています。 教師なし継続事前学習(Ovadia)と教師ありQ&Aチューニング(農業)が、同じデータ・同じ評価で比較されたことはありません。だから「教師ありQ&Aチューニングなら知識注入ができるのか」は、依然として開いたままです — 農業論文の証拠は誤差範囲が重なり、ラベルはLLM生成物です。

こうした空白があるという事実そのものが、実務的に重要です。誰かが「研究によればRAGはファインチューニングよりX%良い」と断言したら、そのXは、どのファインチューニングをどのデータで測ったものなのかを尋ねてみてください。

おわりに

この質問へのよくある答えが役に立たないのは、間違っているからではなく決定不能だからです。「最新情報ならRAG」は正しいのですが、自分の問題がそれに該当するのかを知るすべがありません。

測定されたものだけを残すと、絵はこう整理されます。ファインチューニングは知識注入の道具ではありません — これは複数の論文で繰り返し確認されており、逆に見えるケーススタディは別の介入を測ったものです。ロングコンテキストは位置・長さ・語彙の3軸でそれぞれ崩れ、大多数のモデルの実質的な限界は、広告されたウィンドウサイズより一桁小さいのです。RAGとロングコンテキストは、大半のクエリでそもそも同じ答えを出します — Self-Route基準で63%が完全に同一でした。そして、これらすべての数字が乗っていたベンチマークは、3分の1から3分の2がコンテキストなしでも解ける質問でできていました。

だから実務の答えは、ベンチマークをさらに読むことではなく、曲線を一本、自分で描くことです。あなたのコーパス、あなたの質問50個、kを変えながらrecall。小さいkで飽和すればRAG、最後まで上がるならロングコンテキストを検討しつつモデルがその長さで持ちこたえるかを確認、最後まで上がらないなら、検索ではなく問題定義を見直してください。

道具ではなく、質問が先です。そしてその質問の性質は、他人の論文ではなく、あなたのデータにだけ書かれています。