非対称量子化: ストレージを97%削減し、ほぼロスレスな検索を実現

すべての投稿 非対称量子化: 97%のストレージ削減による、ほぼロスレスなLate Interaction検索 リサーチ エンジニアリング ASJDRH Aamir Shakir, Joel Dierkes, Rui Huang・2026年6月29日・8分読書 コピー Wholembed v3のようなLate Interactionモデルは、ドキュメント全体を単一のベクトルに圧縮するのではなく、細粒度の情報を保持するため、検索精度が大幅に向上します。しかし、これはストレージの経済性にも影響を与えます。単一のドキュメントでも、ドキュメントの複雑さに応じて数百または数千のベクトルが生成されることがあります。各ベクトルは保存され、後で検索に使用される必要があります。 Mixedbread Searchは、数十億ドキュメント規模のマルチモーダルLate Interaction用検索エンジンであるSilo上で動作します。Siloはオブジェクトストレージに25億ドキュメント以上のベクトルを保存し、クエリの必要に応じて高速な階層にロードします。その規模では、ドキュメントあたりの追加バイトは数十億回繰り返され、保存ドキュメントあたりのコスト、シャードのコールドスタート時間、クエリが読み取るバイト数に直接影響します。システム全体を安価に保ちつつ、Late Interactionの価値を高める品質を維持するというトレードオフを回避する必要があります。この記事では、非対称量子化について説明します。これは、本番環境でLate Interactionを実行可能にする最適化の1つです。クエリベクトルは高精度に保ち、ドキュメントベクトルはバイナリ符号として保存します。内部ベンチマークスイートでは、生のドキュメントベクトルストレージをドキュメントあたり平均32倍（393 KiBから12.28 KiB）削減し、検索品質はfp32の90.26 NDCG@10に対して89.65を維持しました。マルチベクトルドキュメントあたりのストレージは、fp32の393 KiBから、int8クエリとバイナリドキュメントの組み合わせで12.28 KiBに低下し、32倍、97%の削減となります。 fp32は32個のセルとして描かれ、各セルは単一のint8-by-binaryセルと同じサイズです。 非対称量子化は、Siloにおけるドキュメントあたりのベクトルストレージを約97%節約します。 before fp32 × fp32 393 KiB after int8 × binary 12.28 KiB TL;DR: ドキュメントは長期間保存され、クエリは一度実行されます。そのため、ドキュメントベクトルは1ビットの符号として保存し、クエリはint8で保持します。これにより、ドキュメントあたりのストレージが32倍に縮小され、内部ベンチマークではNDCG@10の品質低下はわずか0.61ポイント（90.26から89.65）です。 量子化: マルチベクトルストレージを実用的にする 量子化とは、高精度の浮動小数点ベクトルを、int8や1ビット符号などの低精度値で表現することです。目標は、ペイロードサイズを削減しながらランキング品質を維持することです。これは特にSiloにとって重要です。オブジェクトストレージは、耐久性があり低コストな永続性を提供します。これを実際のワークロードに適したものにするには、高速にサービスを提供するためのコンパクトなインデックスが必要です。そしてドキュメント側では、ペイロードサイズがコストを支配します。 ナイーブなLate Interactionは、より多くのベクトルを保存するため高価です。3072次元のfp32の標準的な単一ベクトル埋め込みは、ドキュメントあたり12 KiBを消費します。786ベクトルの128次元のマルチベクトル表現は、より多くの情報を含みますが、非圧縮では約33倍大きくなります。 表現 | 次元数 | ドキュメントあたりのストレージ | 3072-d fp32単一ベクトルに対する相対値 ---|---|---|--- 単一ベクトル、fp32 | 3072 | 12,288 B / 12 KiB | 1.0x 単一ベクトル、int8 | 3072 | 3,072 B / 3 KiB | 0.25x マルチベクトル、fp32 | 786 × 128 | 402,432 B / 393 KiB | 32.75x マルチベクトル、int8 | 786 × 128 | 100,608 B / 98.25 KiB | 8.19x マルチベクトル、バイナリ | 786 × 128 | 12,576 B / 12.28 KiB | 1.02x ここでのストレージ数は、生のベクトルペイロードのみを指します。本番環境のインデックスには、ドキュメントID、メタデータ、レイアウトオーバーヘッドも含まれます。 バイナリドキュメントベクトルを使用すると、786トークンのマルチベクトルドキュメントは、3072次元のfp32単一ベクトルよりも約2%大きくなるだけです。これは、単一ベクトルストレージと同等のコストでLate Interactionの品質を得られることを意味します。これにより、トレードオフを変更できます。Late Interactionは、ストレージを正当化できるケースに限定されるものではなく、デフォルトで実用的に実行できるようになります。 これはLate Interactionの新しい方向性ではありません。ColBERTv2は、積極的な圧縮が品質を維持しながらLate Interactionモデルのフットプリントを削減できることを示しました。PLAIDは、最適化された検索とプルーニングを使用して、Late Interaction検索を実用的なレイテンシまでエンジニアリングできることを示しました。本番システムでは、両方の教訓が重要です。モデルは正確である必要があり、表現はハードウェアを通過させるのに十分安価である必要があります。 なぜ非対称量子化か ドキュメントベクトルの圧縮は、コーパス全体でストレージ、IO、キャッシュスペース、コールドスタート時間を節約します。クエリベクトルの圧縮は、クエリが小さく、短命で、インデックスに保存されないため、ほとんど何も節約しません。これも、両方をバイナリ化しない理由です。完全にバイナリな検索は最もコンパクトなオプションですが、クエリを単一ビットに落とすと、ランキングが依存するマグニチュード情報を失い、ドキュメントのみをバイナリ化するよりもはるかに多くの品質を犠牲にします（後述）。そのため、クエリはint8で保持し、ドキュメントベクトルのみをバイナリ符号として保存します。クエリはランキングを維持するのに十分な精度を保ち、ドキュメント側はサービングに重要なストレージ削減を実現します。 スコアリングトリック バイナリドキュメントベクトルは小さいため、保存コストが低くなります。int8 x int8スコアリングの場合、最新のARM CPUはNEONドット積命令を通じて直接サポートを提供します。当社のAArch64カーネルは、SDOTを使用して16個のint8乗算をint32レーンに蓄積し、その後vaddvq_s32で結果を水平に削減します。int8 x binaryスコアリングの場合、有用な恒等式はより単純です。各ドキュメント次元が符号ビット（b_iが{-1, +1}）として保存されている場合、次のようになります。 q⋅b = ∑i qibi = 2∑i : bi=+1qi − ∑iqi したがって、スコアリングは次元ごとに完全な乗算を必要としません。正のドキュメントビットによって選択されたクエリ値の合計と、クエリ全体の合計が必要です。ドキュメントベクトル（float）は符号ビットに還元され、バイトにパックされます。バイナリドキュメントに対するint8クエリのスコアリングは、次元ごとの乗算を必要としません。これは、選択されたクエリ値の合計の2倍からクエリ全体の合計を引いたものです。 バイナリドキュメントは、スコアリングをセレクト＆サムに変換します。 doc floats | 0.94 | -0.31 | 0.55 | 0.38 | -0.72 | 0.12 | -0.08 | 0.61 sign bits | + | - | + | + | - | + | - | + packed | 1 | 0 | 1 | 1 | 0 | 1 | 0 | 1 score = 2 · (q0 + q2 + q3 + q5 + q7) − Σ qᵢ 正のドキュメントビットによって選択されたクエリ値の合計と、1つの合計値のみ — 次元ごとの乗算なし。 カーネルでは、ドキュメントの符号はビットにパックされます。128次元パスの場合、クエリの合計と8つのクエリビットプレーンを事前計算します。各ドキュメントトークンは16個のパックされたバイトとしてロードされ、NEON整数演算でシフトおよびマスクされて8つの0/1マスクになり、その後クエリプレーンに対してSDOTでスコアリングされます。最終スコアは上記の恒等式を使用します：2 * selected_query_sum - query_sum。 バイナリxバイナリは、ハミング距離を使用できるため計算上さらに安価ですが、品質低下が大きすぎるため、メインの検索パスには使用しません。 検索品質 内部検索ベンチマークスイート全体でいくつかの精度ペアリングを評価しました。スコアはNDCG@10のスイート全体での平均値で、0〜100にスケーリングされています。NDCG@10（Normalized Discounted Cumulative Gain at rank 10）は、上位10件の結果が理想的なランキングに対してどれだけうまく並べ替えられているかを測定し、関連ドキュメントがより高い順位に表示されるほど報酬を与え、100が完璧なランキングです。 フルプレシジョンベースラインの平均は90.26です。バイナリドキュメントに対するint8クエリの平均は89.65で、0.61ポイントの低下ですが、ドキュメントベクトルストレージは32倍削減されます。パフォーマンスの低下が最小限である理由の一部は、Wholembed v3がSiloのトレードオフを念頭に置いてトレーニングされているため、量子化に対して堅牢であることです。 実行時間について、ARMマシンで33 × 128のクエリを、各786 × 128のドキュメント1000件のリストに対して実行した際のスコアリングカーネルをベンチマークしました。表は、2回のウォームアップ後の9回の測定実行の中央値レイテンシと、fp32ベースラインに対するスピードアップを示しています。 クエリ形式 | ドキュメント形式