스크립트
00:00:00皆様、本日はお越しいただきありがとうございます。Hornet DevでCEOを務めておりますジョー・バーガムです。本日は
00:00:19「エージェンティック検索におけるBM25の圧倒的な有用性」についてお話しします。会場の中で
00:00:24BM25について聞いたことがある方はどれくらいいますか？初めてでしょうか、それとも… おお、かなりいますね。素晴らしいです。実は今ワールドカップも見ていまして。
00:00:32ノルウェー対コートジボワール戦の後半で、ノルウェーがリードしています。嬉しい限りです。
00:00:37さて、Hornetではエージェント向けの検索・情報リトリーバル基盤を開発しています。私自身、
00:00:46長年検索やリトリーバルの問題に取り組んできました。白髪が増えたことからもわかるように、
00:00:52この分野で20年以上働いています。本日のプレゼンでは、なぜこの
00:00:5930年ほど前の語彙的スコアリング関数が今大きく再評価されているのかをお話しします。まずは、
00:01:08私が言う「エージェンティック検索」や「エージェンティック・リトリーバル」が何を意味するのか、その定義からお話ししましょう。
00:01:14私の定義では、エージェンティック検索とは本質的に「エージェントのループ内で行われる検索」のことです。
00:01:22コードを書いたりディープリサーチを行ったりと、あるタスクの完遂を目指すエージェントがあり、
00:01:28そのタスクを成功させるために、エージェント内部で何らかの情報ニーズが発生します。
00:01:34優れたエージェンティック検索システムを構築するためには、基本的に3つの要素が必要です。
00:01:411つ目は、能力の高いモデル。ツールを活用し、適切なクエリを組み立てられるモデルです。
00:01:472つ目はモデルを包むハーネス（制御機構）であり、
00:01:55リトリーバルや検索機能をモデルにどう提示するかという部分です。やり方はいくつかあります。
00:02:01ツール呼び出しを使う方法もあれば、コードモードを使う方法もあります。先ほどIdoが実演したのも、
00:02:08リトリーバル基盤を提示するための、いわゆる「コードモード」でした。これがハーネスの部分です。
00:02:14そして3つ目は、場合によっては10億規模のドキュメント集合に対しても
00:02:23効率的に検索を実行できる「リトリーバルエンジン」です。BM25の定義ですが、BM25とは「Best Match 25」の略です。
00:02:33研究者たちが無数の実験を行い、その25番目の実験結果が
00:02:38最も優れていたことに由来しています。これが名前の背景です。本質的にはスコアリング関数です。
00:02:44クエリとドキュメントが存在し、クエリの単語群とドキュメントの単語群との相互作用から
00:02:50何らかのスコアを算出するイメージです。
00:02:55そしてこのスコアが、クエリに対するドキュメントの関連性を適切に表す指標になることを期待します。
00:03:01BM25を計算する一つの方法として、全ドキュメントを対象に1つずつスコアを算出して
00:03:08上位K件のドキュメントを特定するやり方があります。そして、こうしたTop-K取得をいかに高速化するかについて、
00:03:1430〜40年にわたり数々のアルゴリズムが研究されてきました。私たちもその分野に多くの投資を行っています。
00:03:22のちほど関連する事例もお見せしますが、BM25自体はあくまでスコアリング関数であり、Top-K検索を高速化する手法が存在します。
00:03:30BM25自体が変わったわけではありません。スコアリング関数は昔と同じですが、変化したのは「ユーザーがより強力になった」という点です。
00:03:38Edoも一般的知識について触れていましたね。現在のLLMは膨大な一般的知識を持っています。エンティティ、企業、日付など、多くのことを知っています。
00:03:50モデルのパラメータに組み込まれたそうした暗黙的知識を活用することで、モデルは本質的に検索が非常に得意になります。
00:04:01これこそが、今BM25の重要性を再び高めている根本的な変化なのです。
00:04:09かつてBM25は一種のベースライン指標でした。情報リトリーバルの研究では、必ずBM25のベースラインを用意し、
00:04:17そこに高度なニューラル手法などを構築して、BM25と比較する形を取っていました。
00:04:24また、従来の検索評価方法も興味深いです。かつては検索結果の10個の青いリンクを人が目で確認し、評価指標を計算していました。
00:04:34そうした評価の多くは廃れつつあります。なぜならエージェントは非常に強力で、人間よりも遥かに多くのクエリを打ち込めるからです。
00:04:45そのため、単発のクエリだけでシステムを評価することの妥当性は薄れています。
00:04:53こちらは私のお気に入りのベンチマークの一つです。ベンチマークの話をするのが好きでして。
00:04:59「BrowseComp Plus」は、昨年発表された論文にあるディープリサーチ用のベンチマークで、ちょうど830個の質問が用意されています。
00:05:13これらはなぞなぞのような問題です。パブクイズのようなものをイメージしてください。アメリカにもパブクイズはありますよね？
00:05:19はい、良かったです。かなり長文の、なぞなぞのような質問です。
00:05:23そしてこのベンチマークの仕様・プロトコルでは、モデルに対して
00:05:31「search」という非常にシンプルなツールを与えます。検索文字列を受け取ると、スニペットをモデルに返します。
00:05:40コーパスは約10万5,000件（10万件程度）のWebドキュメントで、かなり小規模です。
00:05:47エンドツーエンドの正解率についてですが、これらの質問には正解となる参照回答があり、モデルとループレ全体がその正確な回答を生成できたかを検証できます。
00:06:02では、なぜリトリーバルが必要なのでしょうか？ 私は歳なので、コンテキストウィンドウを80年代のフロッピーディスクに例えるのが好きなんです。
00:06:11当時はフロッピーディスクを使ってパソコンにゲームをインストールしていました。
00:06:15みなさんはお若いのでそうした懐かしさはわからないかもしれませんが、フロッピーディスク1枚には約1.4MBのデータが入りました。
00:06:26そして現在のモデルで精度劣化が始まり出す上限は、私の感覚ではおよそ35万トークンです。
00:06:34つまり、ちょうどフロッピーディスク1枚分のデータ量です。
00:06:38そのため、コンテキストウィンドウに実際に入れるべき情報を取得するには、リトリーバルが必要になります。
00:06:47BrowseComp Plusは、リトリーバルの品質がタスクのエンドツーエンド精度にどう影響するかを見事に示しています。
00:06:57ここでのエンドツーエンド精度とは、検索ツールを備えたモデルが質問に正解できるかどうかということです。
00:07:05あのなぞなぞのような質問に対してです。
00:07:07もし回答に必要な根拠ドキュメントを、あらかじめモデルのコンテキストウィンドウに
00:07:16人工的に直接詰め込んでおけば、精度は非常に高くなります。
00:07:21つまり、推論能力自体がボトルネックなのではありません。
00:07:23事前に根拠を与えられていれば、GPT-4レベルでも非常に高い正解率で質問に答えられます。
00:07:33しかし、ハーネスを介してモデルにリトリーバルツールを使わせると、精度は低下します。
00:07:39ハーネスの性能や、モデルのクエリ作成能力、
00:07:44そしてリトリーバー自体の検索品質に依存するようになるからです。
00:07:49私にとってこれは極めて重要です。仮に完全なモデル、つまり間違いを一切犯さないAGIのようなモデルが登場したとしても、
00:07:57ミスをしなくなるだけで、
00:08:00コンテキストウィンドウがフロッピーディスク1枚分程度であるという制限は残るからです。
00:08:04そのため、そのコンテキストウィンドウに何を投入すべきかを選択する必要があります。
00:08:07前述のスライドが示すように、リトリーバルの重要性は依然として変わりません。
00:08:13そしてこのBrowseComp Plusデータセットでは、そうしたなぞなぞ形式の質問が「検索の軌跡（トラジェクトリ）」へと変換されます。
00:08:20モデルがクエリを実行し、結果を受け取って読み込み、クエリを再構築し、
00:08:27コンテキストウィンドウが埋まるか、答えが見つかるまで検索を繰り返すからです。
00:08:36私たちはこれらの検索軌跡の調査に時間を費やしました。
00:08:44GPT-5がどのようにクエリを組み立てているかを観察するためです。
00:08:49そこから多くの興味深い側面が見えてきました。
00:08:52これについては最近のブログ記事でも解説しています。
00:08:55hornet.dev でご覧いただけます。
00:08:57私たちはこれを「AOLの検索クエリログ」と比較するのが好きです。
00:09:02AOLは昔のネット接続サービスで、検索インターフェースがありました。
00:09:08そして彼らは誤って、人々がWebで何を検索していたかを示す大規模なサンプルデータを公開してしまったのです。
00:09:17それらのクエリは非常に短いものでした。
00:09:19最近のクエリログも目にしたことがありますが、
00:09:22人間であるユーザーの傾向として、今でもわずか数単語で検索を行っています。
00:09:27一方、GPT-5ははるかに強力なユーザーです。
00:09:31一般知識を備えており、
00:09:32一瞬で非常に長いクエリを生成できます。
00:09:35有用な構文演算子を駆使することも可能です。
00:09:40Web検索から学習したsite指定演算子やフレーズ検索などです。
00:09:45これは全く新しいタイプのワークロードと言えます。
00:09:52BM25についてですが、BM25にはスコアリング関数の
00:09:57さまざまな側面を制御するハイパーパラメータが主に2つ存在します。
00:10:01先ほどベースラインを用意するという話をしました。
00:10:04通常、BM25がそのベースラインになります。
00:10:06BrowseComp PlusでもBM25をベースラインとして使用しています。
00:10:10しかし、そのベースライン設定がひどいものであることが判明しました。
00:10:14そのため、埋め込みモデルなどのより高度な手法と比較した際、
00:10:20元の論文を見ると、それらの手法がBM25よりも遥かに優れたリトリーバル・パラダイムであるように見えてしまいます。
00:10:26ですが最近の研究により、BrowseComp Plusの論文で使われていたパラメータが、
00:10:33このような長文ドキュメントを扱うには不適切だったことがわかりました。
00:10:37だからこそ「どのBM25のことを指しているのか？」という疑問が生じるのです。
00:10:40パラメータ設定によって、そのベンチマークの全体の精度に劇的な差が出るからです。
00:10:50では、なぜ進化させたユーザーにとってBM25が今これほど強力なのでしょうか？
00:10:56先ほど触れたように、ユーザーの全般的な知識量が増し、より速く入力し、
00:11:00より具体的な指示を出せる高度なユーザーとなったからです。
00:11:02そして完全一致（エグザクトマッチ）の重要性は今も変わりません。
00:11:06モデルは固有名詞、エンティティ、郵便番号、SKUなどの特定コードを把握しているからです。
00:11:12これらは全トークンを固定の語彙構造にエンコードする埋め込みモデルでは、
00:11:17表現するのがそれほど容易ではありません。
00:11:21また、比較的コストが安い点も挙げられます。埋め込み推論の実行コストを考慮すると特に顕著です。
00:11:27埋め込みモデルの中には80億パラメータ規模のものもあり、テキストのエンコード用に
00:11:32専用インフラを立ち上げる必要があるなど、負担が大きくなります。
00:11:36その点BM25は非常にシンプルで、既存のエコシステムのツール群も充実しています。
00:11:43そのため、すぐに導入して活用することができます。
00:11:45さらに、モデルが検索結果を検証し、特定のクエリ表現で
00:11:51なぜその結果が得られたのかを理解するのも非常に容易です。
00:11:54文字通りの単語やフレーズなどを一致させるため
00:11:58クエリの再定式化に役立ちます
00:12:03以上が3つのポイントです
00:12:06さて 次は「何が必要か」という旬なトピックです
00:12:11これはウォータールー大学のジミー・リンの研究グループによるごく最近の研究です
00:12:17情報検索やエージェント検索の研究で素晴らしい成果を上げています
00:12:23私が気に入っている最新の論文があります
00:12:26タイトルは『動的ワークスペース拡張によるコーパス直接インタラクションのスケーリング』です
00:12:32詳しく説明していきます
00:12:34エージェント向けのWeb検索インフラを構築したいと想像してください
00:12:39現在 多くの企業がそれを行っています
00:12:41私たちもそうしたユースケースを支えるインフラ構築を
00:12:47支援しています
00:12:48そこには数十億のドキュメントが存在する可能性があります
00:12:53これらは文脈ウィンドウに収まりません
00:12:55ですから当然 検索（リトリーバル）が必要です
00:12:57そしてBM25は優れたベースラインです
00:12:59それを使って情報を検索できます
00:13:03その結果は エージェント向けの検索結果ページ（SERP）のようなものだと考えてください
00:13:15レトリバーから取得したドキュメントをワークスペースに配置できるからです
00:13:20このワークスペースをファイルシステムとして整理すれば スキル周りと同じ仕組みを活用できます
00:13:29段階的開示が可能になり ドキュメントのタイトルや
00:13:35短いスニペットをモデルに見せることができます
00:13:39モデルは「もっと読む必要がある」と判断できます
00:13:43その際 得意なプリミティブツールをすべて活用できます
00:13:48皆さんもコーディングエージェントを使っていますよね
00:13:49文脈管理のために grep、ripgrep、sed、awk などを活用しているのを目にしているはずです
00:13:55ここでは両方のメリットが得られます
00:13:58サンドボックス、検索インフラ、VFS、bashなどを組み合わせることができます
00:14:05とてもワクワクしますよね
00:14:06現在起きている新しいパラダイムがすべて統合されているからです
00:14:11私はこの方向性に非常に期待しています
00:14:14また これは一種の「ハック」でもあります
00:14:16現在モデルが得意なことに最適化するためのハックです
00:14:19フロンティアLLM企業は、コーディング、bash、ツール利用に向けてモデルを最適化しているからです
00:14:27そのため エンドツーエンドのタスクをその軌道に乗せておけば
00:14:31新しいモデルが登場した際にも 当然性能が向上します
00:14:37AGIが実現すれば ブラウザを直接使えるようになるかもしれませんが どうなるでしょう
00:14:41現時点では これは検索インフラとエージェント型検索体験を構築する非常に強力な方法です
00:14:53評価に関してですが
00:14:55先ほどもお話ししました
00:14:57従来の情報検索では 1つのクエリと1つのランク一覧からnDCGを計算して比較していました
00:15:07新しいユーザーがエージェントの場合 それはもはや重要ではありません エージェントはクエリを再定式化し
00:15:12さらにクエリを実行し 拡張し あらゆる操作を行えるからです
00:15:17そのため 伝統的な情報検索の評価の多くは形骸化しています
00:15:23代わりに モデルが課されたタスクを実行できるかを確認してください 例えば
00:15:30質問応答の場合 正しい答えが得られているかを見ます
00:15:35Hornetでは プリミティブの1つとしてBM25に着目しており ビジョンを掲げています
00:15:42BM25を評価するための最高で最も効率的な方法を目指しています 強力で
00:15:51根幹となるプリミティブだからです この図は匿名化されたエンジンとHornetを比較しています
00:15:59同じハードウェアで 1億件のWebドキュメントを単一ノードで処理した比較です
00:16:07ご覧の通り Hornetは他のエンジンよりもはるかに効率的に実装されており
00:16:13同じコストでより高いスループットを実現できます Web検索などのインフラを構築している
00:16:19多くの企業にとって 大幅なコスト削減を意味します
00:16:24Y軸は何ですか？
00:16:26Y軸はQPSです すみません
00:16:32Y軸は…あ、失礼 Y軸はレイテンシです
00:16:40このセッションのまとめとして4つの主張があります。新しいユーザーはより強力で、タイピングも読むのも速く、クエリを再定式化でき、豊富な一般知識を持っています。そのためgrepやBM25のようなシンプルなツールがより強力になります。
00:17:03それが1点目です。2点目は「どのBM25を指しているのか」です。
00:17:07実装、パフォーマンス、パラメータに違いがあるので、検討が必要です。
00:17:14また、なぜエージェント検索に有効なのか？単純にモデルにとって説明可能だからです。モデルは結果を確認でき、grepと組み合わせて使用できます。完全一致があり、grepもほぼ完全一致を扱うからです。
00:17:27この2つの組み合わせは、非常に強力なエージェント検索パラダイムとなります。
00:17:39参考文献がたくさんあります。講演の動画やスライドも公開される予定です。
00:17:47不満があれば、Twitter（X）でメッセージを送ってください。
00:17:55質疑応答の時間はないと言われましたが、検索について喜んでお話しします。会場のあちこちにいますし、連絡を取るにはXのアカウントが一番です。
00:18:08以上となります。
00:18:25それではまた次回お会いしましょう。
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기