はじめに
みなさんこんにちは。株式会社インプルの岩崎です。
本日は、RAGとLong Contextのお話。後者は、初めて取り扱う内容です。似てるようで全然違う二つの用語について、それぞれ理解を深めて特徴を探っていきましょう。
RAG vs Long Context
さて、今回紹介するのは、RAG（検索拡張生成）とLong Context（長文コンテキスト）という技術。
RAGとLong Contextは、どちらもAIが「知らない情報」や「膨大な資料」を扱うための技術ですが、アプローチの仕方が根本的に異なります。
RAGとは
RAGは、LLMがもともと持っている能力に加えて外部の知識を組み込み、その組み込まれた知識を使って回答を生成する方法です。データベースは一度構築して仕舞えば、繰り返しそこから扱うことができます。なので、アップデートすれば常に最新情報に素早くアクセスすることもできます。
一方で、知識の断片などを扱うため、検索漏れなどの情報の抜け漏れが発生し、結果が左右されやいデメリットがあります。
RAGについてまとめた記事も作成していますので、よければこちらもご覧ください。
Long Contextとは
一方、Long Contextは、モデルの入力上限を増やし、超速読で外部知識を全て読み込むことで、抜け漏れなく回答を生成するものです。そのため、RAGよりは回答精度が上がるという意見もあります。
そのため、入力トークン数が増えるのでLLMの利用料金が増えたり処理時間が長くなるデメリットもあります。また、あまりにも膨大な情報を扱うと、情報が多すぎて迷子になってしまうこともあります。
（これは記事がないので、割愛です・・・。）
どっちが良いか？
さて、このように似た技術があると、どっちが良いのか気になってしまうものです。
比較した論文
この「結局、RAGとLong Contextはどっちが強いのか？どう使い分けるべきか？」を真っ向から比較した、より実践的な内容の論文で有名なものに、RAG or Long-Context LLMs? A Direct Comparison （ https://arxiv.org/abs/2407.16833 ）という論文があります。
膨大なデータ（長文）を処理する際、単純に全部読み込ませる「Long Context (LC)」と、必要なところだけ持ってくる「RAG」のどちらが精度とコストで勝るのかを、様々なモデル（GPT-4oやGemini 1.5 Proなど）で検証した研究です。
今回は、次の3つのポイントについて紹介します。
精度面
まず最初に精度面です。それぞれの読み込ませ方で、精度の高いシーンは、下記のような場合でした。
RAGが勝つ場合 : 答えが特定の「1箇所」に書かれている場合（情報の検索）。
Long Contextが勝つ場合 : 複数の資料にまたがる情報を要約したり、全体を俯瞰して比較したりする必要がある場合。
しかし、当時の最新の強力なモデル（GPT-4oなど）では、単純な情報抽出でも Long Contextの方がRAGより精度が高い 傾向があることがわかりました。冒頭に紹介したように、RAGは「検索の失敗」という弱点があるため、その部分で大きくマイナスな面が出てしまったようです。
現在では、それからモデルも一段と進化し、性能も向上したので、また違う結果になるかもしれませんが、全体を満遍なく網羅できるLong Contextの方が、いいのかもしれません。。。
コスト面
続いてコスト面です。これは冒頭でも若干触れたので、なんとなく結果はわかりますね。。。
そう、結果は圧倒的にRAGの方が有利でした。
Long Contextは全部読み込ませるため、入力するたびに大量のトークン料金がかかります。一方、RAGは必要な分だけを読み込ませるため、計算資源や料金を大幅に節約できます。
解決策
そうして、この論文では最終的に、どっちを使うのかではなく、「AIにどっちを使うか選ばせる」という手法、Self-Route を提案しています。簡単な質問は低コストなRAGで、複雑な質問はLong Contextで、と自動で振り分けるのが一番賢いという結論です。
この結論からもわかるように、どちらかが圧倒的にいいかと言われると、そうではなく、用途に応じて正しく使い分けることが大事だということがわかります。
これらの技術を使用したツール
GoogleのNotebookLMは、メイン技術に Long Context を使用しています。膨大なコンテキストウィンドウを活かして、アップロードした資料を全て一度に読み込んでいるため、資料を跨いだようやくや、複雑な関連性の抽出が得意です。
一方、Open web UIのような、チャット形式のものは RAG の技術が多く使われています。（チャットはレスポンス良くないとですからね・・・。）数万、数百万という膨大なドキュメントから、質問に関係ある数件だけを瞬時に見つけ出します。
どう使い分けるべきか？
これまでの内容をもとに、結局どのように使い分けるといいのでしょうか？
Long Context を使うべきケース
Long Contextを使うシーンは、「木を見るより、森を見る」タスク になります。
- 物語や論文の要約: 1冊の本の起承転結を把握し、矛盾がないか確認する。
- コード全体のレビュー: 複数のファイルにまたがるプログラムのバグを見つける。
- 比較分析: 「資料Aと資料Bの主張の違いを書き出して」といった比較。
- データ量: 数MB（数冊の本程度）まで。
RAG を使うべきケース
RAGを使うケースは、「森の中から、特定の木を探す」タスク になります。
- 膨大なナレッジベース: 数千～数万件のPDFやWikiから回答を探す。
- 最新情報の参照: 毎日更新されるニュースや社内情報を反映させたい（Long Contextだと毎回全読み込みが必要でコストが跳ね上がる）。
- コスト重視: 1回の質問でかかるトークン代を安く抑えたい。
- データ量: 数GB〜テラバイト級。
おわりに
さて、今回は、LLMにドキュメントを参照させる時、どのような方法でドキュメントを参照させればいいか、RAG と Long Context の2つの方法を紹介しました。
LLMにドキュメントを参照させてアウトプットを出すツール開発においては、参考になる内容だったのではないでしょうか。ご覧いただき、ありがとうございました。