스크립트
00:00:00皆さん、こんにちは。本日はご参加いただきありがとうございます。「何の意味もない話」へようこそ。失礼、
00:00:21「検索（リトリーバル）」についての話です。私はAI21というAI研究所で働いているユヴァルと申します。本日は、
00:00:29多くの人があまり語りたがらないテーマである「チャンキング」についてお話ししたいと思います。
00:00:37チャンキングは決してオワコンではなく、まだ打つ手があるということを、最後には納得していただければ幸いです。
00:00:45XやLinkedInなどを見ていると、「RAGは死んだ」という投稿をよく目にするのではないでしょうか。
00:00:53最近ではMCPまでもが過去のもの扱いされ、RAGも再び「死んだ」と言われています。オーガニック検索や
00:01:00オーガニックリトリーバル万歳、と。しかし「RAGは何回死ねば気が済むんだ？」と思いませんか？
00:01:07LlamaIndexのCEOであるジェリーのように、「いや、RAGは死んでいない」と言う人でさえ、
00:01:14何かを否定しなければ気が済まないようです。そしてその対象が「チャンキング」なのです。「投資するな、
00:01:23そんなのやるな」と。なぜチャンキングがオワコンと言われるのか。それは誰もが
00:01:30エージェント型の検索を使うようになったからです。grepやls、findなどがありますよね。これらは素晴らしいですが、
00:01:36大量のデータと多種多様なクエリが存在する場合、これらだけでは不十分です。
00:01:46少々お待ちください。よし。多くの人がチャンキングについて語りたがらない最大の理由は、
00:01:51それが「楽しい作業ではない」からだと思います。RAGやファイルシステムには、
00:02:002つの段階があります。第1段階はいわば退屈な作業です。最初に行う作業であり、
00:02:07大量のデータを前処理し、チャンクサイズを決定しなければなりません。そして
00:02:13すべてをベクターDBに格納します。もう1つのパートは検索（リトリーバル）です。基本的には
00:02:20クエリごとに実行される処理です。こちらははるかに扱いやすく、
00:02:25最適化も簡単です。クエリ群を使ってtop-kパラメータを調整したり、
00:02:32ハイブリッド検索を試したりできます。検索チューニングの方がずっと楽しいですよね。
00:02:40ですから、もし何かを葬り去るべきだとしたら、それはおそらく
00:02:47検索チューニングのほうでしょう。エージェント型検索がそれを不要にしたと言えます。しかしエージェント型検索も、
00:02:55チューニングを不要にしたと認めたとしても、データが大量にある場合には十分ではありません。
00:03:02言うまでもなく、コストが非常に高くつきます。トークンの浪費問題は
00:03:09誰もが話題にしていることです。そして根本的な問題として、フォルダやディレクトリ内で
00:03:17データ自体が適切に整理されていなければ、どうしても非効率な
00:03:25結果になってしまいます。タイムリーな例で考えてみましょう。現在FIFAワールドカップが開催中だとします。
00:03:33歴代のFIFAワールドカップのデータセットがあると想像してください。各ディレクトリが、
00:03:40例えば98年大会、2002年大会…といった具合に分かれています。「どのチームが最多優勝したか？」という
00:03:50クエリを投げた場合、単一のフォルダを見るだけでは答えは出ません。すべてのフォルダを巡って勝者を確認し、
00:03:57それらを集約する必要があり、極めて非効率です。ちなみに答えはブラジルですね（現時点では）。
00:04:03つまり、検索は実際には死んでいません。このセッションで何かをオワコン扱いするつもりはありません。
00:04:13単に「裏方の配管作業」になってしまっただけです。RAGシステムを構築したことがある方なら、
00:04:21誰もがこの感覚に心当たりがあるはずです。初日や最初の1週間、あるいは徹底するなら最初の1ヶ月で、
00:04:29例えば512といった適当なチャンクサイズを決めます。そして10%や20%程度のオーバーラップを
00:04:36設定し、すべてをインデックス化したら、あとはすっかり忘れてしまうのです。固定長チャンキング戦略について
00:04:43よく語られますが、チャンクサイズが大きすぎると、
00:04:49全体の文脈が把握できる良さはあるものの、多くの細かいニュアンスが失われます。そして
00:04:54どのチャンクも意味のある埋め込み表現を得られなくなります。逆にチャンクを小さくしすぎると、
00:05:00全体像が見失われ、効率も悪くなってしまいます。つまり何が言えるかというと、
00:05:07チャンキングとは本質的に非可逆圧縮だということです。どうあがいても何かを失ってしまうのです。
00:05:15私は「唯一の正解となるチャンクサイズは存在しない」と主張します。データ構築経験のある方は、
00:05:23「いや、うちのコーパスやデータセットに対しては、システムを極限まで最適化して
00:05:29非常にうまく機能させている」と言うかもしれません。私たちも以前はそう考えていました。様々な種類のエージェントや
00:05:35システム、ワークフローを扱ってきた豊富な経験がありましたから。
00:05:40ベンチマークを考えれば、モデルを特定のベンチマークに過剰適合させるのは簡単です。
00:05:48しかしRAGではそうはいきません。データセットごとに最適化することは実質不可能なのです。
00:05:54チャンクの有効性がクエリ依存であることをこれからお示しします。なぜそんな確信を持って言えるのか？
00:06:00実際に実験を行い、検証したからです。その結果をご紹介しましょう。私たちは、
00:06:06データごとの最適なチャンクサイズを机上で議論するのではなく、実際に突き止めることにしました。
00:06:14データセットを用意し、それを複数回、この検証では6回複製しました。複製ごとに、
00:06:23各インスタンスのチャンクサイズを変えています。チャンクサイズ2,000のデータベース、
00:06:281,000のデータベースといった具合です。これを複数のデータセットで実施しました。
00:06:36会議の文字起こしデータである「QMSUM」、小説に対する質問応答である「NarrativeQA」、
00:06:41そして「サインフェルド」のデータセット（「何の意味もないトリビア」ですね。正確には
00:06:49ドラマ『となりのサインフェルド』の台本に関するトリビア問題で、社内で作成したお遊びのようなものです）。
00:06:56これも公開していますので、ご希望なら後でリンクを共有します。これらすべてで検証を行いました。
00:07:03まず各データセットにおいて、どのチャンクサイズがベストかを確認したかったのです。そして
00:07:10ここにお示ししているのがサインフェルドのデータセットからの例です。本質的に性質の異なる2つのクエリが、
00:07:16チャンクサイズによって全く異なる結果を示しています。最初の質問「ジェリーのお気に入りのシャツの名前は？」
00:07:24これを見ると、非常に絞り込まれたピンポイントな質問であることがわかります。
00:07:28答えはおそらく非常に局所的に存在します。こういったケースでは、小さめのチャンクサイズが
00:07:33最も優れた性能を発揮します。100トークンの固定サイズでは1位だったものが、
00:07:43サイズを変えると50位以下に沈んでしまいます。一方で「ジェリーが宿敵であり純粋な悪と呼ぶのは誰か？」という質問の場合、
00:07:50大ファンではない私ですら「ニューマン」だと知っていますが、実際の台本上では
00:07:56そう簡単には見つけられません。結果が劇的に変化するのが見て取れますよね。小さなチャンクサイズを
00:08:02使うと、答えを取得できなくなってしまいます。一連の実験を終えた後、
00:08:10私たちはある発想に至りました。「もし、各クエリに対して検索に最適なチャンクサイズを教えてくれる
00:08:19オラクル（神のお告げ）や魔法のランプの魔神がいたらどうなるだろう？」と。これがまさに
00:08:25「オラクル実験」です。達成可能なポテンシャルを知りたかったのです。これは現時点で
00:08:33実装できるシステムという意味ではなく、どれほどの改善の余地があるのかを見たかったのです。このグラフをご覧ください。
00:08:38まず青い線について、Y軸は再現率（Recall）で高いほど良く、
00:08:46X軸は取得チャンク数です。つまり「Recall@k 対 k」を表しています。青い線は互いに似通っていて
00:08:52見分けがつきにくいかもしれませんが、それぞれ特定の固定チャンクサイズの性能です。そしてオレンジの線が
00:09:01オラクルの結果です。各クエリに対して最適なチャンクサイズを選んだ結果です。そしてこれは
00:09:09複数のデータセットに共通して見られます。多くのデータセットで青い線同士が交差しており、
00:09:16どのデータセットでも単一のチャンクサイズが圧倒的に優れているわけではないことがわかります。そして
00:09:24さらに興味深いのは、非常に大きな伸びしろがある点です。オレンジの線と
00:09:30すべての青い線との間のギャップは極めて大きく、チャンキングの戦略を
00:09:38工夫するだけで20〜40%もの改善が見込めます。しかも極めてシンプルな戦略で、です。このギャップこそが、
00:09:47512や1000といった恣意的なチャンクサイズを何となく選ぶことで支払わされている代償なのです。
00:09:56ここでの課題は少々厄介です。各フェーズで必要な情報が手元にないという一種の「情報不足問題」だからです。
00:10:07どういうことか説明しましょう。チャンクサイズを制御できるインデックス作成フェーズでは、
00:10:12将来どんなクエリが来るかがわかりません。
00:10:18推測や予測を試みることはできても、どんなクエリが来るかはわからないため、
00:10:25クエリに合わせてチャンクサイズを調整することができません。一方、クエリが判明している検索フェーズでは、
00:10:31チャンクサイズを自由に変えられません。すでに固定されているからです。クエリごとに
00:10:37全プロセスを最初からやり直すわけにもいきません。そこで先行研究、特にAnthropic社の
00:10:47Contextual Retrieval（文脈付加型検索）などを調べました。これは各チャンクを情報補強したり、
00:10:54潜在空間の表現を改善しようとするアプローチです。しかし私たちが目指したのはそこではありません。それらは依然として
00:11:01「単一の固定チャンクサイズで運用する」という枠組みにとどまっていたからです。私たちは別のアプローチを取りました。
00:11:08「1つのサイズに絞る必要はあるのか？複数使えばいいのでは？」と考えたのです。私たちはこれを「マルチスケールインデックス」と呼んでいます。
00:11:16要するに先ほどお見せした実験と同じことを行います。データベースを用意し、複製して複数の
00:11:26チャンクサイズ（ウィンドウサイズ）でチャンキングします。ここまでがインデックス時の処理です。そして検索時には、
00:11:34そのすべてに対してクエリを実行します。つまりN個のウィンドウサイズとDBの複製があるなら、1クエリにつき
00:11:436回（N回）の検索呼び出しを行います。ではそれらをどう統合するのか？本番環境では当然ながら
00:11:52オラクルは使えません。オラクルは理論上の限界を測るためのものですから。実世界では
00:11:57事前に正解はわかりません。そこで何らかのマージアルゴリズムが必要になります。ここで
00:12:06問題となるのは何でしょうか？N個のランキング結果が得られるものの、
00:12:13それらはチャンクごとの順位付けであり、サイズの異なるチャンク同士は単純に比較できないという点です。
00:12:19そこで最近よく使われている手法を採用しました。現在の多くの
00:12:25RAGシステムの多くが採用している方法で、チャンク単体を取得するのではなく、
00:12:30チャンクが見つかったらドキュメント全体を取得します。コンテキスト長が伸びているため、
00:12:35より多くの文脈を提供したいわけです。この場合、チャンクではなく同一のドキュメントに対する
00:12:44n個のランキングが得られるため、比較可能になります。この場合の検索は、本質的に
00:12:50投票のようなものと考えられます。単なる1回のランキングや、それをリランクするのではなく、
00:12:56関連ドキュメントに対するn通りの順位付けがあり、それらを1つにまとめたいのです。
00:13:03そこで使ったのが、RRF（Reciprocal Rank Fusion）と呼ばれる手法です。
00:13:11極めてシンプルな計算式です。色々試しましたが、これが一番うまくいきました。
00:13:17ご覧の通り、これは特別な学習モデルなどではなく、
00:13:23一瞬で処理が終わる簡単なスクリプトにすぎません。システム全体の構成はこちらです。
00:13:32n通りのインデックスがあり、各DBへクエリを投げ、RRFを用いてそれらを統合します。
00:13:40結果はご想像通り良好です。そうでなければ、ここに立ってこんなに自信満々には話せませんよね。
00:13:48ご覧のように、複数のデータセットで検証しました。QMSum、
00:13:56NarrativeQA、Seinfeld、そしてFinanceBenchです。いずれにおいても最善の固定サイズと同等以上でした。
00:14:05グラフで見てみましょう。少し見づらいので順に説明します。各行は
00:14:12チャンクサイズを示し、50、100と並んでいます。一番下の行が私たちの手法で、
00:14:21全サイズから取得して結合したものです。各列はRecall@kを表し、Recall@1、2、3から
00:14:3110まであります。ここで読み取れる点は2つあります。まず、
00:14:39どのRecall値においても私たちの手法が勝っている点です。当たり前に思えるかもしれませんが、
00:14:46これらすべてを結合するのは決して自明ではありません。そしてもう1つ、品質自体も向上しています。
00:14:53ヒートマップを見ると、はるかに緑色が濃くなっていますね。これは
00:14:58大きくお見せしたかっただけです ここには4つのデータセットすべてがあり
00:15:06より良い結果が得られています 多くの項目で実に20%、30%、40%もの向上です
00:15:14ここでは紹介しなかったMTEBの結果もあります 後でリンクを載せるブログで確認できますが
00:15:22そちらでもデータセットに応じて 10%から40%程度の大幅な改善が見られます
00:15:30もちろんコストが全くかからないと 主張するつもりはありません 当然コストはあります
00:15:36タダ飯はありませんから 何事にも代償は伴います そう 追加のメモリコストです
00:15:43定数倍のO(1)で 2倍から5倍程度の追加メモリが必要になります
00:15:51データベースのコピーをすべて保持する必要があるからです しかしレイテンシの観点では
00:15:59検索処理をすべて並列で実行でき RRFの部分も時間があまりかからないため 影響はほぼありません
00:16:10これは非常に素晴らしい研究プロジェクトで 実に面白い結果が得られました
00:16:16改善の余地や 今後の課題もあります 具体的には
00:16:23どのチャンクサイズを何種類使うべきかを 解明したいと考えています 50、100、
00:16:32200などで進めたのは 正直かなり恣意的でした だからこそ計算方法や
00:16:40正確に必要なコピー数を割り出す必要があります またRRFの先を目指すことも課題です
00:16:46RRFを採用したのは試した手法の中で 最も良好だったからであり より優れた手法が存在しないとは言えません
00:16:52最後に1つお伝えしたいのは エージェントが検索を終わらせたわけではない ということです
00:16:59何も終わっていません 単なるインフラです 問題なのは
00:17:07それが2022年時点のインフラだという点です 非常にシンプルな手法を使えば RAGシステムや
00:17:17データの保存と検索に関わるあらゆるシステムで 過度な複雑さなしに20〜40%向上させられます
00:17:26詳細を知りたい方はブログをご覧ください サンプルコードや
00:17:34となりのサインフェルドのデータセットも載せています 以上です ユーヴァルでした ご清聴ありがとうございました
00:17:47また次回お会いしましょう
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기