Zenn
🤩

インコンテキストラーニング vs. RAG：長大なコンテキストがあれば検索は不要？

2025/04/01に公開
NLP
LLM
生成 AI
RAG
incontextlearning
tech

「大規模言語モデル（LLM）」の精度やコンテキスト長が急速に伸びてきている昨今、Retrieval-AugmentedGeneration－RAGが本当に必要なのか疑問に感じる方もいるのではないでしょうか？

たとえば、「Gemeni」という超大規模モデル（コンテキスト長200万トークンとも噂！）が出てきたら、ディープラーニング任せで一気に大量のドキュメントを食わせてしまえば済むのでは…？という声も。
この記事では、そんな疑問を念頭に、インコンテキストラーニング（ICL）とRAGの特徴を整理し、それぞれの強み・弱みを比較してみます。

1. インコンテキストラーニング（ICL）の魅力

1.1 プロンプトに情報を詰め込む

インコンテキストラーニング（ICL）は、LLM本体を再学習・ファインチューニングしなくても、「プロンプトに必要情報を直接書き込む」だけでタスク適応が可能な手法です。Zero-ShotやFew-Shot例示をするアレ、と言えばピンとくる人も多いはず。

  • メリット
    • 学習コストが小さい（基本的にプロンプトの工夫だけ）
    • モデルの内部はそのままなので、やりたいタスクが変わっても応用しやすい
    • 大量のテキストを一括で処理できれば、複数文書の総合推論が一度に行える

1.2 長大なコンテキストなら“全部突っ込める”？

もしコンテキストが超巨大（数十万～数百万トークン）なら、わざわざ検索をかけるまでもなく「関連資料を全部ぶち込む」作戦が可能になります。

  • 期待される強み

    • RAGみたいに外部エンジンで検索しなくても、一度に参照した文書同士をモデルが内部表現で“関連づける”可能性がある
    • ブラックボックス的にはスッキリしたフロー（「プロンプトに詰め込む→LLMに任せる」）で完結

  • 懸念点

    • 計算資源コスト: とにかく推論に時間・GPUメモリを食いがち
    • 大量の文書を無秩序に与えると、ノイズが増えてハルシネーションを誘発しやすい
    • 新規ドキュメントが常時追加される場合、コンテキストをいちいち再構築し続ける運用コストが発生

2. RAGの仕組みと強み

2.1 必要な文書だけ検索してLLMへ渡す

RAG（Retrieval-Augmented Generation）は、外部コーパスを検索して、その結果をLLMに連携する手法です。たとえばベクトル検索ライブラリ（FAISSやMilvusなど）を使ってクエリと類似した文書を素早く見つけ、トップN件をLLMのプロンプトに注入します。

  • メリット

    1. コーパスが大きくてもOK: 一度の推論で必要な文書だけ取り出して使うため、コンテキスト制限に悩みにくい。
    2. 実装・運用が柔軟: 検索エンジンのパラメータ調整や埋め込みモデルの更新が独立して行える。
    3. 文書のアップデートが容易: 新しい文書が増えてもインデックスを更新すれば参照可能。

  • RAGの限界

    • 検索精度に依存するため、本当に関連深い文書を取れていない場合、回答の品質が下がる。
    • 外部検索後、LLMが複数文書を正しく“論理統合”できるとは限らない。
    • 根拠を明示しやすい利点はあるが、パイプラインの段階が増えるほどシステムが複雑化。

3. 実際どっちが優位？　チェックポイント

3.1 コンテキスト長 vs. 検索効率

  • 長大コンテキストが圧倒的に余裕があるなら、すべての資料をプロンプトに入れて一気に処理できる“ICL特攻”が魅力的かもしれません。ただしコンテキストが膨大になるほど推論時間が伸び、コストが爆上がりする可能性大。
  • RAGで検索する場合、仮に数十万件の文書があっても、関連度の高い10～20件を拾ってLLMに与えれば済むため、計算資源を節約できます。

3.2 ノイズ対策

  • インコンテキストラーニングで文書を山積みにすると、不必要な情報や矛盾する情報も大量に含まれがち。LLMがノイズに引っ張られて誤った推論をしやすくなる恐れ。
  • RAGなら、外部検索エンジンであらかじめ文書の「スコア付け」を行い、ノイズを減らしたうえでLLMに投げられる。運用の自由度が高い。

3.3 リアルタイム更新・ドキュメント管理

  • インコンテキストで毎回「ドキュメントを全部詰め直す」運用だと、最新資料の組み込みや並行リクエストの負荷をどうコントロールするかが課題に。
  • RAGなら、バックエンドで文書DBを更新・インデックス作成を行えば、検索結果がそのまま最新化される。柔軟な拡張性が利点。

3.4 適材適所のハイブリッドもアリ

「RAGで抽出された文書をミニ要約して、それをICLの大規模コンテキストにまとめる」など、両手法を組み合わせるアプローチも登場しています。

  • 一度に扱うテキストが膨大な場合、多段階で情報を圧縮・検証するほうが現実的でしょう。

4. 具体的シナリオ例

  • 研究論文アシスタント
    • 大量論文を一度にICLコンテキストへ… は非現実的。RAGで必要なセクションを抜粋してまとめるほうが、最終プロンプトのサイズを抑えやすい。
  • ドキュメントQ&A
    • FAQレベルで件数が少ないならICLでもいける。数百件程度をまとめて入力できれば、検索する手間なしに応答可能。ただしFAQの量が増えるほどRAGの利点が目立つ。
  • 医療・法務
    • 最新のガイドラインや条文を常にアップデートする必要がある。RAGならデータベースを更新するだけで済むが、ICLは毎回長大コンテキストを再構築し続ける必要があるかもしれない。
    • 調査時に引用ソースを提示する場合、RAGのほうがリンクを返しやすい。

5. まとめ：ディープラーニング任せ vs. 検索併用

「コンテキスト長が超長ければ何でも解決？」

  • 一定のケースでは有効。ただしメモリ・計算コスト・ノイズ混入が深刻化するリスク。
  • 定常的にドキュメントが増え続ける場面では、まとめてコンテキストに詰め込む運用が大変。

「RAGは過渡的な技術？」

  • 検索で関連文書を厳選する設計は、これまでの情報検索（IR）技術とLLMを結びつける堅実な手法。
  • 大規模コンテキストモデルが普及しても、根拠提示や効率性の観点でRAGの強みは色あせにくい。

最終的には…

  • 運用条件（リアルタイム性、コーパス規模、根拠要提示など）を踏まえ、ICLとRAGのどちらが適しているか判断するのが得策。
  • ハイブリッドの“多段構成”がベストになるケースも多いはず。

今後の深掘り：RAGの実装パターンとICLの高度な使い方

本記事では、ICL vs. RAGの大づかみな比較に留まりましたが、次のステップとしては以下のような話題を深掘りしたいと考えています。

  1. RAGの実装パターン

    • ベクトル検索エンジン（Faiss, Milvus）の設定
    • LangChainなどのパイプライン構築手法
    • 外部Toolとの連携で多段推論を実現するアプローチ（Agentic RAG など）

  2. ICLをより高度に使いこなす

    • 大規模コンテキストを前提にした要約・フィルタリングの実装
    • Prompt設計パターン（段階的にプロンプトを更新する ReAct スタイルなど）
    • 大量ドキュメントを分割→LLM内部で統合するテクニック（Chain-of-ThoughtやTree-of-Thought）

  3. ハイブリッド設計事例

    • 一度RAGで文書抽出→その要約をICLの巨大コンテキストに詰め込む
    • 多回問い合わせ（Recurrent Prompting）とRAGの組み合わせ

これらのトピックを掘り下げることで、実際にPoCを作りたい人やシステムを運用したい人が具体的に動けるようにしていきます。興味ある方はぜひコメントやフォローでフィードバックをお寄せください。

参考リンク・文献

  • FAISS: https://github.com/facebookresearch/faiss
  • Milvus: https://github.com/milvus-io/milvus
  • Dense Passage Retrieval (Karpukhin et al., 2020)
  • Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., 2020)
  • Bubeck, S. et al. (2023). "Sparks of Artificial General Intelligence: Early experiments with GPT-4." arXiv.
  • Mann, W. C. & Thompson, S. A. (1988). “Rhetorical Structure Theory.” Text.

もし興味があれば、「RAG vs. In-Context Learning」を比較検証しているGitHubリポジトリや、ACM/ACLの論文もぜひチェックしてみてください。性能評価や応答品質がタスクごとに大きく変わっている実験結果などが見られます。

おわりに

「ICLか、RAGか？ あるいは両方使うか？」——結論はユースケース次第ですが、両者の特徴を知っておけば選択を誤りにくいでしょう。
将来、LLMのコンテキストがいくら拡張されようとも、情報の管理性・根拠提示などの面でRAGが持つ強みは依然として大きいはず。
一方、莫大なコンテキストを一度に扱えるなら、そのシンプルさと一体感は魅力的。

いずれにしろ、次の記事で具体的なPoC例やプロンプト戦略を取り上げていきますので、よければまた読みに来てください。実際に手を動かして、あれこれ試してみるのが一番の近道です！

この記事は複数の論文・実装例を参照しつつ執筆し、客観的情報に基づいています。技術の進展は早いので、ぜひ独自に検証実験も行いつつ、最新情報を追いかけてみてください。

Discussion