"RAG for long context LLMs" 日本語まとめ
kun432ロングコンテキストのLLMであればRAGはもう要らないのではないか？というテーマで、LagnChainの中の人の講演が紹介されていた。
ロングコンテクストLLMのためのRAG:ビデオ
長いコンテキストのLLMは本当にRAGを殺すのか？これは講演です これは @RLanceMartin が最近のミートアップで行った講演で、この質問に関連するいくつかの異なるプロジェクトのスレッドをまとめたものです。
Multi-needle in a haystack（干し草の山から複数の針を探す）テストは、複数の事実に対するロングコンテキストLLMの推論と検索の限界を示す。
しかし、RAGはいくつかの方法で進化するかもしれない。クエリ分析が重要であることに変わりはないが、完全な文書インデックス（例えば、RAPTOR、インデックスのマルチ表現）とロングコンテキストな埋め込みへのシフトが見られるかもしれない。
また、単純なプロンプト：レスポンスのパラダイムから、検索後の推論とフィードバックによって反復的にRAGの回答が構築される（Self-RAG、C-RAG）「フロー」パラダイムへのシフトが見られるかもしれない。
中身を少し追いかけてみる。
kun432動画
スライド
kun432かいつまんでポイントをまとめよっかなと思ったら、スレにまとめてくれていた。
それぞれ日本語訳をつけた
- ロングコンテキストLLMは、RAGシステムのように複数の事実を検索して推論することができますか？
@GregKamradtと私は、GPT4でmulti-needle-in-a-haystackを使って調べてみた。検索は保証されていない：針が多いほど悪くなる。
https://www.youtube.com/watch?v=UlmyyYQGhzc
- 素晴らしい論文（@adamlerer & @alex_peys）によると、これは訓練による最新性バイアスのせいかもしれない。コンテキスト拡張生成には向かない。
https://arxiv.org/pdf/2310.01427.pdf（引用訳）この現象の原因として考えられるのは、LLMが訓練されるタスクと、コンテキスト拡張生成タスクとのミスマッチである。ウェブページ、書籍、記事、コードなど、LLMの事前学習に一般的に使用されるドキュメントのうち、特定のトークンを予測するために最も有益なトークンは、一般的に最も新しいものである。事前学習中、これは最近のトークンに注目する学習バイアスを誘導する。さらに、私たちが調査しているオープンソースモデルで使用されている回転位置埋め込み（RoPE）スキームには、長い距離での注意力を低下させる帰納的なバイアスがあるため[27]、これらのモデルは、最近のトークンに優先的に注意を向けるように学習することがさらに容易になる。極端な最新性バイアスは、遠くのトークンに実は非常に関連性の高い情報が含まれている可能性があるような、コンテキスト拡張生成タスクには適切ではない。
- しかし、RAGは長いコンテキストのLLMのために再考されるべきである。ただコンテキストを詰め込むだけでは、セキュリティや認証の問題とともに、理想的なレイテンシやコストよりも高くなる可能性が高い。しかし、"ちょうどいいチャンク "を得るためにkNNを使ったドキュメント・チャンキングは、長いコンテキストではあまり意味をなさない。
4/「ドキュメント」という単位でのRAGはまともなようだ：チャンキングはなく、ドキュメントはすでに自己完結した単位であり、検索は質問を（チャンクではなく）正しいドキュメントにリンクさせるだけである。
ドキュメントの粒度は？一つの大きなコンテキストなのか、小さなファイルの束なのか。最適なパレートは、文書レベルでの包含であり、埋め込み類似度やキーワード検索のようなヒューリスティックな方法で優先順位をつけることだと思う。
- クエリ分析（質問の書き直し、ルーティング、テキストからDSLへの変換）は、引き続き関連性があると思われる。タスクは、質問を適切なドキュメント・適切なDB、といっしょ or どちらか、にリンクさせることにシフトするだけである。
https://python.langchain.com/docs/use_cases/query_analysis/
- インデックスの問題が大きく変わる。チャンキングはあまり重視されず、ドキュメント単位のインデックスが重視される。プロポジション・インデックス (@tomchen0 et al)は、検索しやすいようにドキュメントの要約をインデックスし、長いコンテキストのLLMのためにドキュメントの全文を返すという、いいトリックだ。
https://arxiv.org/pdf/2312.06648.pdf
https://blog.langchain.dev/semi-structured-multi-modal-rag/
- RAPTOR (@parthsarthi03 他) 多くのドキュメントから文脈を必要とする質問のための素晴らしいアプローチ。jerryjliu0氏からの良いアルファ: RAPTORを複数のドキュメントに適用する。これを試してみたが、うまくいった：
https://www.youtube.com/watch?v=jbGchdTL7d0確かに、ドキュメントレベルではraptorはもう必要ないかもしれない。リーフノードは任意の大きさにできるので、ドキュメント間でインデックスを作ることができる。
- しかしドキュメント単位のインデックス作成には、長いコンテキストのembeddingが必要だ。
@JonSaadFalcon、@realDanFu、@simran_s_aroraのクールな取り組みである Monarch Mixer (M2) で利用できる - 有望な方向性だと思う。
https://hazyresearch.stanford.edu/blog/2024-01-11-m2-bert-retrieval
- また、"単発 "のRAGから、答えをチェックし反復的に構築する "フロー "へとシフトする。セルフRAG (@AkariAsai et al）、C-RAG（Shi-Qi Yanら）が良い例だ。
https://arxiv.org/abs/2310.11511
https://arxiv.org/abs/2401.15884
https://blog.langchain.dev/agentic-rag-with-langgraph/
- RAG+ロングコンテクストLLMのための可能な部分。質問→ドキュメントのクエリ分析、ドキュメント単位のインデックス作成(プロポジション, RAPTOR)、ドキュメントに基づいたLLM生成、検索後の推論(例えば@GroqIncのようなレイテンシが下がるにつれてより実現可能なチェック/フロー)。
kun432こちらも参考に
kun432個人的なまとめ
- ロングコンテキストLLMがRAGを完全に置き換えるには色々とハードルはまだある
- コストとレイテンシー
- 検索できるかどうかが保証されない
- （おそらく）ロングコンテキストモデルでも完全ではない可能性が高い
- とはいえ、ロングコンテキストによりこれからのRAGは変化する可能性がある
- 既存のRAGは文書中のチャンクを正確に検索できるかがポイントになっている
- 精度・複雑性などの課題が多い
- ロングコンテキストがこれを解決する可能性は当然ある
- チャンクレベルからドキュメントレベルにretrievalの焦点は移るのではないか？
- 既存のRAGは文書中のチャンクを正確に検索できるかがポイントになっている