ベクトル量子化でホーム検索インデックスを縮小する方法

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

ベクトル量子化は、高精度な埋め込み値を元のベクトルを近似するコンパクトなコードに置き換えることで、ホーム検索インデックスのサイズを縮小します。

プライベート検索サーバーでは、メモ、OCRテキスト、マニュアル、写真のメタデータ、文字起こし、アプリケーションの記録から、数十万から数百万のチャンクをインデックス化することがあります。すべての埋め込みを完全精度の浮動小数点値として保存すると、ベクトルのワーキングセットが元のテキスト自体より大きくなる場合があります。量子化では、検索に使用する表現を変更し、各ベクトルが占有するバイト数を減らします。その代わりに、制御された近似誤差を受け入れ、メモリとストレージへの負荷を軽減します。

完全精度の埋め込みでは、各次元に数バイトが必要

埋め込みは、数値座標の配列です。1,024次元のベクトルを32ビット浮動小数点値で保存すると、グラフリンク、ID、ペイロード、アロケーターのオーバーヘッド、レプリカを考慮する前の生の値だけで4,096バイト必要になります。

圧縮されたベクトル表現は、インデックス内のベクトル部分に必要なバイト数を減らし、メモリに制約のあるホームサーバーでも、より大きな検索可能なワーキングセットを常駐させられるようにします。

この生のサイズを100万チャンク分にすると、非圧縮のベクトル値だけで数ギガバイト近くになります。複数のコレクション、レプリカ、常駐する検索インデックスによって、ホームサーバー上のフットプリントはさらに増加します。量子化が対象とするのは、この数値表現です。元のPDF、ペイロードメタデータ、転置インデックス、ベクトル周辺のすべてのグラフエッジが自動的に圧縮されるわけではありません。

量子化は詳細な座標を、より少数の表現可能な状態にマッピングする

基本的な考え方は、無数に存在し得る浮動小数点値を、より少数の表現可能な状態に置き換えることです。正確なマッピングは、システムがスカラー量子化、バイナリ量子化、積量子化、回転量子化など、どの量子化方式を使用するかによって異なります。

さまざまなベクトル量子化モードは、それぞれ異なる方法で表現サイズを削減するため、スカラー、バイナリ、積量子化の各方式に共通する普遍的な精度や性能のトレードオフはありません。

スカラー方式では、各座標の精度を下げることができます。バイナリ方式では、方向に関する情報をより粗く符号化します。別途説明する積量子化では、ベクトルを部分空間に分割し、コードブックの識別子を保存します。

共通する結果は同じです。検索エンジンは、候補を比較するたびに元の完全精度の配列を扱う代わりに、コンパクトな近似表現をホットなワーキングセットに保持できます。

ベクトルの小型化は、常駐メモリと距離計算時のデータ転送量を削減する

検索では、候補ベクトルを繰り返し読み込み、クエリと比較します。表現が小さくなると、より多くの候補をCPUキャッシュやアクセラレーターのメモリに収められ、メモリ階層を通過するデータ量も減少します。

コンパクトな近似ベクトルは、候補を広く検索する際のストレージ使用量とメモリ転送量を削減します。ただし、その距離は元の完全精度の埋め込みに含まれる関係を近似したものです。

ホームサーバーでは、メリットは見出しにある圧縮率よりも、アクティブなインデックスをメモリに常駐させられることにある場合が多いです。メモリ不足を回避することで、ディスクフォールトの繰り返しや、ローカルLLM、データベース、その他のコンテナとのリソース競合を防げます。

レイテンシーが改善するかどうかは、検索エンジン、CPU命令、インデックス構造、追加のデコード処理や再スコアリング処理の有無によって異なります。

近似ベクトルは近傍の順位を変える可能性がある

量子化は通常、非可逆です。複数の異なる完全精度ベクトルが、近い、あるいは同一のコンパクト表現にマッピングされることがあるため、近似距離によって元の順位が常に正確に維持されるとは限りません。

非可逆の圧縮領域検索は、より小さい、または高速な類似検索用ワーキングセットを得る代わりに、数値表現の厳密性を犠牲にします。そのため、圧縮後には再現率を測定する必要があります。

完全精度では別のチャンクよりわずかに近かった関連チャンクが、圧縮後には順位を入れ替えることがあります。その影響は、データ分布、埋め込みモデル、量子化器、コードサイズ、クエリの難しさによって異なります。だからこそ、再現率のテストが不可欠です。幅広い意味検索では安全に見える圧縮設定でも、非常によく似た製品マニュアルや、バージョン違いで内容が近接した文章では、異なる結果になる可能性があります。

オーバーサンプリングと再スコアリングで、コンパクトな初回検索の精度を補える

一般的な設計の1つでは、圧縮されたインデックスから最終的なtop-kより多くの候補を検索し、その後、元のベクトルを使って候補を絞り込んだ集合の正確な、またはより高精度な距離を再計算します。

オーバーサンプリングと再スコアリングでは、圧縮表現を使って広範囲の検索を行い、最終順位付けの前に、候補を絞り込んだ集合についてより高精度な距離を再計算できます。

このハイブリッド方式では、コストの高い完全ベクトルを広範な候補スキャンから除外しつつ、境界付近の結果をRAGに渡す前に修正できます。

その代わり、元のベクトルを保持すると追加のディスク容量やメモリが必要になり、再スコアリングによってクエリごとの処理量も増加します。ホームサーバーでは、圧縮後のバイト数だけでなく、全体のフットプリントを測定する必要があります。

量子化が解決するのはベクトルサイズであり、検索インデックスのすべてのボトルネックではない

HNSWインデックスにはグラフ接続も保存されます。また、メタデータフィルター、テキストインデックス、ドキュメントペイロード、キャッシュ、クエリバッファも、それぞれ独自のリソースを消費します。

意味検索インフラには、埋め込み、インデックス作成、フィルタリング、検索の各段階が含まれるため、ベクトルの縮小が影響するのは、ホーム検索パイプライン全体の1つのリソース層だけです。

HNSWインデックスにはベクトルと接続グラフの両方が含まれます。そのため、ベクトル圧縮によってインデックス全体のフットプリントが、生の埋め込みバイト数と同じ比率で削減されるわけではありません。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.