はじめに
大規模言語モデル(LLM)のロングコンテキスト処理能力を評価するためのベンチマークデータセット「Loong」に関して勉強会で紹介LTを行ったので、Qiitaで記事にします。
- 紹介したarXivはこちら
- 実際に行ったLTはこちら
- 同勉強会の他の記事はこちら
以下で紹介する画像は勉強会で実際に紹介したスライドおよび元arXivから引用しています。
サマリ
背景
昨今LLMの能力は飛躍的に伸びています。
LLMのコンテキストウィンドウが伸びたことで、モデルがロングコンテキストを理解し、より複雑なタスクに対応することが可能となりました。
また余談ですが、arXivがリリースされた2024年6月当時はちょうどGemini-1.5 Proが実際に使えるようになったりとロングコンテキストLLMはより注目されていました。
一方で、従来のロングコンテキスト用のベンチマークデータセットには、以下の表で示すように課題が残っていると筆者らは主張しています。
具体的には、複数文書か、長さに多様性があるか、汚染を回避できているか、現実的か、根拠が分散しているか、多言語対応しているかの観点で改善の余地があると筆者らは主張しています。
そこで上記全ての課題を解決したベンチマークデータセットであるLoongを提案しました。
Loong
Loongは複数文章の参照が必要なタスクがあり、これにより複雑な幅広いタスクを設計できます。
複数文章が必要なタスクとは具体的にSpotlight Locating、Clustering、Comparison、Chain of Reasoingであり、詳細は以下の通りです。
また複数文章かどうかの課題以外は以下のように解決できていると筆者らは主張しています。
Loongの評価
モデル
オープンソースモデルとクローズドモデルの計7つを用いて評価されています。画像の()内はコンテキストウィンドウです。
評価指標
GPT-4を用いたLLM-as-a-Judgeを用いており、100点満点でスコア化しています。
スコアは平均スコア(GPT-4のスコアの平均)と完璧率(満点回答の割合)で評価しています。
評価結果
それぞれのタスクは以下のとおりです。
またコンテキストが長くなればなるほど、タスクの性能が下がっていることも確認できました。
さらに実際のコンテキストウィンドウサイズ以内で性能劣化が起きていることから、実際の能力の境界が、実際のウィンドウサイズよりも大幅に低い可能性が示唆されました。
またコンテキスト長が長ければ、コンテキストの長さに関する性能劣化が起きにくいことも示唆されてました。
最後にRAGを実施した場合のLoongの評価も実施しています。
下図のbaselineがコンテキストをそのまま入力した場合であり、それ以外がRAGのエンベディングモデルとtop-kです。
LoongデータセットにおけるRAGの導入はモデルの総合的な性能を向上させることがなく、むしろ評価が低下することが確認されました。これは、Loongデータセットの証拠が複数の文書に均等に分散しており、モデルにはロングコンテキストを総合的に理解する能力が求められるためです。
RAGの効果は、モデルが処理できるコンテキストウィンドウ内においては限定的ですが、ウルトラロングコンテキストセットに対してはtop-k設定を高くすることで一定の効果が得られました。
おわりに
紹介したarXivでは既存のロングコンテキストに対応したベンチマークで評価できない実践的な観点を評価可能なデータセットであるLoongを提案しています。
幅広いタスクで大規模言語モデル(LLM)のロングコンテキストを扱う能力やRAGの性能を調査し、既存の手法の限界と改善の方向性を示唆しています。
本arXivの後続としては以下などが良いかもしれません。
- Needle Bench
紹介したarXivの約1ヶ月後に出た。考え方もかなり似ている。
- NIAH
ロングコンテキストLLMを理解するには欠かせないNIAHの引用元。
- RAG vs ロングコンテキスト
- RAGとロングコンテキストのハイブリッド: Self-Route