アーカイブ / RAG
WebANNS：ブラウザー内のベクトル検索で計算・読み込み・メモリー使用量を調整
WebANNS
WebANNSの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
Figure 4 . Overview of WebANNS .
概要
- WebANNSは、WebAssemblyによる計算、候補の段階的な読み込み、キャッシュ量の調整を組み合わせたブラウザー内の近似近傍検索エンジン。
- 著者らは五つのデータセット、三種類のブラウザー、三台の端末で評価し、Mememo比で99パーセンタイル応答時間が最大743.8倍改善、メモリー使用量が最大39％減少したと報告した。
- 社内文書への適用では、実際の文書と端末を使い、応答時間、メモリー使用量、検索候補の妥当性を測る必要がある。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、WebANNSの仕組み
- 01文書と意味ベクトル
- 02HNSW索引を保存
- 03質問ベクトルで探索
- 04候補を段階読込
- 05近い文書を返す
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
WebANNSは、ブラウザー内で質問に近いデータを探す検索エンジンである。近似近傍探索とは、質問と文書などを表す数値列を比べ、全件を厳密に調べる負担を抑えて近い候補を見つける方法を指す。
検索した文書を生成AIの回答材料に使うRAGでも、この処理が必要になる。ブラウザーでは計算速度、端末上の保存領域へのアクセス、使えるメモリーが検索時間を左右する。検索の遅れは、利用者が結果を得るまでの待ち時間につながる。
手法
WebANNSは文書とその意味ベクトルからHNSW索引を作り、文書などとともにIndexedDBへ保存する。HNSWは近いデータを階層的につないで探索範囲を絞る索引、IndexedDBはブラウザー内の保存領域である。例えば手順書を登録した後、質問をベクトルに変え、索引をたどって近い文書を探す。
距離計算と候補の並べ替えには、ブラウザーで実行できる形式のWebAssemblyを使う。JavaScriptがそのメモリーとIndexedDBの間に入り、不足した候補を取得する。候補は必要になった段階でまとめて読み込み、各階層の探索を終えてから次へ進む。初期化時には、応答時間が設定した基準を超えるまでキャッシュ量を段階的に減らす。
新規性
著者らが提案するのは、ブラウザー内の近似近傍探索で、計算、保存領域からの読み込み、メモリー使用量を一つの設計で扱う方法である。計算にWebAssemblyを使い、JavaScriptをデータの受け渡しとキャッシュの仲介役にする。
探索に必要と分かった候補を段階的にまとめて読み込み、次の階層へ進む前に探索結果を確定させる。初期化時には応答時間を見ながらキャッシュ量を減らす。
従来手法との違い
比較対象のMememoも、近いデータを階層的につなぐHNSW索引と、ブラウザー内の保存領域IndexedDBを使う。ただし、著者らの測定では先読みしたデータの一部が使われず、キャッシュ量も事前に固定されている。
Wiki-50kを使ったMememoの測定では、メモリーに置けるデータの比率が98％未満になると、99パーセンタイル応答時間は10秒を超えた。WebANNSは計算方法、候補の読み込み時点、キャッシュ量の決め方を変更する。この数値は当該測定条件での結果である。
実験結果
著者らは、4MBから7.5GBまでの五つのデータセット、三種類のブラウザー、三台の端末で試作を評価した。Mememoとの比較で、99パーセンタイル応答時間、すなわち遅い側の問い合わせ時間を示す値が最大743.8倍改善し、メモリー使用量は最大39％減少したと報告する。
ブラウザー内の問い合わせ時間を10秒から10ミリ秒台に短縮したとも述べる。ただし、確認できた本文の範囲では、これらの最大値とデータセット、端末、メモリー条件を対応づける結果表はない。最大改善値を通常の利用条件での速度とみなすことはできない。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：従業員が閲覧できる社内手順書をブラウザー内で検索する。入力は手順書本文、その意味ベクトル、質問文とし、出力は質問に近い文書の候補一覧とする。意味ベクトルは文章の内容を数値列に表したもので、質問にも対応する数値列を用意する。
元文書とベクトルから索引を作り、質問時に候補を表示する。検索エンジン自体の追加学習データやセンサー入力は論文中で指定されていない。適用には文書の更新方法と閲覧権限の扱いを別途設計し、候補が業務上適切か確かめる必要がある。
応用先の候補からNauhに相談できます。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：閲覧対象をそろえた少量の社内文書を集め、各文書と質問の意味ベクトルを対応する方法で用意する。検索エンジン自体の追加学習データやセンサーは指定せず、担当者が質問ごとに妥当な文書を評価用ラベルとして付ける。索引の作成・更新から候補表示までを確かめる。
同じ文書、質問、端末、ブラウザーでMememoを比較対象にする。99パーセンタイル応答時間、メモリー使用量、ラベルに照らした候補の妥当性を記録し、利用可能なメモリー量も変えて測る。業務で許容できる待ち時間と候補品質を先に定めて判断する。
限界と課題
著者らが明示する技術上の制約は、WebAssemblyがIndexedDBへ直接アクセスできず、使用できるメモリーにも限りがあることだ。また、HNSWでは候補との距離を計算して次の探索先を決めるため、必要な候補の読み込みを遅らせすぎると探索経路が誤り得る。WebANNSは仲介層と段階的な読み込みで対処する。
編集上の検証事項は、対象文書の量や利用端末で応答時間とメモリー使用量が両立するか、検索候補が妥当かという点である。閲覧権限の適用と文書更新時の索引管理についても、この用途での動作を確認する必要がある。
出典
元のタイトル・要旨を確認する（英語）
WebANNS: Fast and Efficient Approximate Nearest Neighbor Search in Web Browsers
Approximate nearest neighbor search (ANNS) has become vital to modern AI infrastructure, particularly in retrieval-augmented generation (RAG) applications. Numerous in-browser ANNS engines have emerged to seamlessly integrate with popular LLM-based web applications, while addressing privacy protection and challenges of heterogeneous device deployments. However, web browsers present unique challenges for ANNS, including computational limitations, external storage access issues, and memory utilization constraints, which state-of-the-art (SOTA) solutions fail to address comprehensively. We propose WebANNS, a novel ANNS engine specifically designed for web browsers. WebANNS leverages WebAssembly to overcome computational bottlenecks, designs a lazy loading strategy to optimize data retrieval from external storage, and applies a heuristic approach to reduce memory usage. Experiments show that WebANNS is fast and memory efficient, achieving up to $743.8\times$ improvement in 99th percentile query latency over the SOTA engine, while reducing memory usage by up to 39\%. Note that WebANNS decreases query time from 10 seconds to the 10-millisecond range in browsers, making in-browser ANNS practical with user-acceptable latency.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01