AIプロジェクトが本格化するにつれ、ベクトル検索のデータ量が指数関数的に増加し、インフラコストが重くのしかかる課題に直面します。「もっとメモリを積めばいい」という力技もありますが、RAG（Retrieval-Augmented Generation）システムにおいて、数百万、数億というベクトルデータをすべて高価なRAM上に保持し続けることは、ビジネスの持続可能性を大きく脅かします。
そこで注目すべきなのが、Product Quantization（PQ：直積量子化）という技術です。これは単なるデータ圧縮アルゴリズムではなく、計算機科学の知恵を結集し、わずかな精度の犠牲と引き換えに、劇的なリソース削減を実現する極めて実践的なアプローチです。
本稿では、FaissやMilvusの公式ドキュメントだけでは見えてこない、PQの本質的なメカニズムと、開発現場ですぐに使えるパラメータ選定のロジックについて解説します。なぜメモリが減るのか、どこまで精度が落ちるのか、そしてその境界線をどう見極めるのか。経営者視点でのコスト削減と、エンジニア視点での品質保証を両立させるための知見を共有しましょう。
ベクトルデータのメモリ消費とコストの相関
まず、実務の現場で直面する課題を具体的な数字で見てみましょう。AIプロジェクトのプロトタイプ段階では、データ量は数万件程度であることが多く、メモリの問題は表面化しません。しかし、本番運用に入りデータがスケールし始めると、状況は一変します。
100万ベクトルを超えたあたりで直面するメモリの壁
一般的に使用されるOpenAIの埋め込みモデル（text-embedding-3-small や text-embedding-ada-002）は、1536次元のベクトルを出力します。これを標準的なfloat32（4バイト）形式で保存する場合、1つのベクトルにつき以下のメモリが必要です。
$ 1536 \times 4 \text{ bytes} = 6,144 \text{ bytes} \approx 6 \text{ KB} $
たった1件で6KBです。「大したことない」と思われるかもしれません。しかし、これが100万件（1M）になるとどうでしょう。
$ 6 \text{ KB} \times 1,000,000 = 6 \text{ GB} $
生データだけで6GBです。実際には、検索を高速化するためのインデックス構造（HNSWのグラフ構造やIVFのリスト構造など）がオーバーヘッドとして加わるため、安全マージンを含めると10GB〜12GB程度のRAMが必要になります。
これが1億件（100M）になれば、単純計算で600GB〜1TBクラスのメモリが必要です。これほどのメモリを搭載したインスタンス（例えばAWSのr6i.24xlargeなど）は時間単価が非常に高く、常時稼働させれば月額数千ドルから数万ドルのインフラコストがのしかかります。ビジネスへの最短距離を描く上で、これは見過ごせない障壁です。
rawベクトルとIVFのみの場合のインフラコスト試算
実務の現場では、社内ドキュメント検索のために約5000万件のベクトルデータを扱うケースが見られます。当初、すべてのベクトルを非圧縮（Flat）または単純なIVF（Inverted File Index）で運用しようとするプロジェクトも少なくありません。
試算してみましょう。
- データ量: 5000万件 × 1536次元
- 必要メモリ: 約300GB（インデックス含む）
- インフラ: メモリ最適化インスタンス（例：384GB RAM搭載機）
- 冗長性: 本番環境では可用性のために最低2台、開発環境も含めればさらに倍。
結果として、データベース維持費だけで年間数千万円規模の予算が必要になる可能性があります。これは、多くのプロジェクトにおいてROI（投資対効果）が見合わない数字です。特にRAGのような、検索があくまで「LLMへの入力補助」であるユースケースにおいて、検索部分だけにこれほどのコストをかけるのは、経営的にも技術的にも合理的とは言えません。
なぜProduct Quantization (PQ) が現実的な解決策となり得るのか
ここで登場するのが「次元圧縮（Dimensionality Reduction）」と「量子化（Quantization）」です。
PCA（主成分分析）などで次元数そのものを減らす（例：1536次元→512次元）アプローチもありますが、これは情報の損失が大きく、特に意味的な微細なニュアンスが失われるリスクがあります。また、削減率もせいぜい1/2〜1/3程度にとどまります。
一方、Product Quantization (PQ) は、次元数を維持したまま、データの表現精度を落とすことでメモリを削減します。PQを適切に設定すれば、メモリ使用量を1/10から1/64、場合によってはそれ以上に圧縮することが可能です。
先ほどの5000万件の例で言えば、300GB必要だったメモリが、PQ適用後には10GB〜20GB程度に収まる可能性があります。これなら、汎用的な安価なインスタンスで十分に運用可能です。
「メモリ消費を減らす」ことは、単なる節約ではありません。システムを「スケール可能（Scalable）」な状態に保ち、ビジネスの成長を止めないための必須要件なのです。
直感で理解するPQのメカニズム：空間を「サブスペース」で分割統治する
では、PQは魔法のようにデータを消し去っているのでしょうか？ いいえ、PQのアプローチは非常に論理的です。それは「分割統治（Divide and Conquer）」と「近似（Approximation）」の組み合わせによるものです。
ここでは複雑な数式を使わずに、そのメカニズムを直感的に理解できるよう説明しましょう。
ベクトルを「切って」「まとめる」プロセスの図解
1536次元の長いベクトルを、1本の長いフランスパンだと想像してください。このパンには、様々な具材（数値情報）が詰まっています。
PQの第一ステップは、この長いパンを均等にスライスすることです。例えば、1536次元のベクトルを、$m$個のサブベクトル（部分ベクトル）に分割します。
もし $m=96$ に設定したとしましょう。すると、1つのサブベクトルの次元数は $1536 / 96 = 16$ 次元になります。
次に、それぞれのスライス（サブ空間）ごとに、データの傾向を分析します。膨大な数のデータがあっても、16次元という狭い空間の中では、似たようなパターン（クラスター）が存在します。PQは、各サブ空間ごとにk-means法などのクラスタリングを行い、代表的なパターン（セントロイド）を256個（$2^8$）選び出します。
コードブック（Codebook）がメモリを節約する仕組み
ここからが圧縮のハイライトです。
元のベクトルデータ（生の値）を保存する代わりに、「あなたの1番目のスライスは、パターンID 42に一番似ています。2番目のスライスは、パターンID 128に似ています...」というように、ID（コード）だけを保存するのです。
- 圧縮前: 1536個の
float32数値 = 6,144バイト - 圧縮後: 96個（$m$）のID。各IDは256通り（8bit = 1byte）なので、96 × 1バイト = 96バイト
なんと、6,144バイトが96バイトになりました。これが約98.4%の削減、つまり圧縮率約64倍の世界です。
このIDと実際の値（セントロイド）の対応表をコードブック（Codebook）と呼びます。検索時には、このコードブックを参照して、IDから近似的なベクトル値を復元（または直接距離計算）します。
距離計算が高速化される副次的メリット
PQの恩恵はメモリ削減だけではありません。検索速度も向上します。
通常の検索では、クエリベクトルとデータベース内の全ベクトルとの間で、1536回の浮動小数点演算（積和演算）を行う必要があります。しかしPQでは、ADC（Asymmetric Distance Computation：非対称距離計算）というテクニックを使います。
クエリが来た瞬間、事前にクエリとコードブック内の全セントロイドとの距離を計算し、ルックアップテーブルを作成します。データベース内の各ベクトルとの距離計算は、このテーブルから値を拾ってきて足し合わせるだけの処理（Table Lookup + Addition）になります。
CPUにとって、浮動小数点の掛け算よりも、メモリ参照と足し算の方が遥かに高速です。これにより、PQはメモリを節約しつつ、計算速度もブーストするという効果が期待できます。
【実証データ】圧縮率96%の世界で検索精度（Recall）はどう変化するか
「うまい話には裏がある」。技術の本質を見抜くエンジニアなら誰しもそう警戒するはずです。PQの代償、それは精度（Recall: 再現率）の低下です。
元の値を「似ている代表点」に置き換えているため、そこには必ず量子化誤差が生じます。この誤差が検索結果にどの程度影響するのか、具体的なデータを見てみましょう。
ここでの指標は Recall@N です。「正解データ（生ベクトルで全探索した時の上位N件）のうち、PQ検索の結果にどれだけ正解が含まれているか」を示す割合です。
m（分割数）とnbits（ビット数）が精度に与える影響のマトリクス
一般的に使用されるベンチマークデータ（SIFT1Mなど）や、OpenAIの埋め込みモデルを用いたデータセットでの傾向を統合すると、以下のような相関が見えてきます。
ここで、$d=128$（次元数）、$nbits=8$（256セントロイド）と仮定します。
| 分割数 ($m$) | サブベクトル次元数 ($d^*$) | メモリ圧縮率 | Recall@10 (概算) | 評価 |
|---|---|---|---|---|
| m = 4 | 32次元 | 高圧縮 (32x) | 40% - 60% | 危険。実用に耐えない |
| m = 8 | 16次元 | 中圧縮 (16x) | 60% - 80% | 用途によるが不安 |
| m = 16 | 8次元 | 低圧縮 (8x) | 85% - 95% | バランス良し |
| m = 32 | 4次元 | 微圧縮 (4x) | 95% - 99% | 高精度だがメモリ食う |
※ これはあくまで傾向値であり、データの分布によって変動します。
Recall@10が急激に低下する「危険ライン」の特定
データを見てわかる通り、圧縮率を高めようとして $m$ を小さくしすぎると（サブベクトルの次元数を大きくしすぎると）、Recallは低下します。
一般的な傾向として、サブベクトルの次元数（$d/m$）が24〜32を超えると、表現力が極端に落ちることが分かっています。1つのサブ空間で表現すべき情報量が多すぎて、256個のセントロイドでは近似しきれなくなるためです。
逆に、$m$ を増やせば精度は上がりますが、メモリ削減効果は薄れます。また、ルックアップテーブルの作成コストが増えるため、検索レイテンシも若干増加します。
データセット特性（画像のCLIP特徴量 vs テキストの埋め込み特徴量）による違い
重要なのは、データの種類によってPQへの耐性が異なるという点です。
- 画像データ（SIFT, CLIPなど）: 比較的、局所的な特徴がはっきりしており、PQによる圧縮でも精度が落ちにくい傾向があります。
- テキストデータ（BERT系モデル, OpenAIの埋め込みモデルなど）: 意味空間が非常に密で、各次元が複雑に絡み合っているため、画像に比べて量子化誤差の影響を受けやすい（Recallが落ちやすい）です。
特にRAG（検索拡張生成）で使われる最新のテキスト埋め込みモデル（OpenAIのtext-embeddingシリーズなど）の場合、意味的に似通ったドキュメントが高次元空間内で密集していることが多く、わずかな誤差で順位が入れ替わってしまいます。そのため、画像検索よりも保守的な（$m$ を大きめに取る）設定が求められます。
失敗しないパラメータ選定のベストプラクティス：黄金比の導出
PQ（Product Quantization）を導入する際、開発現場で最も頭を悩ませるのはパラメータの設定です。不適切な設定は、検索精度の致命的な低下や、期待したほどの速度向上を得られない結果を招きます。
ここでは、Faissなどのライブラリで設定すべき主要な2つのパラメータについて、理論と実践に基づいた「黄金比」とも言える設定指針を解説します。
- $m$ (Number of subquantizers): ベクトルをいくつに分割するか
- $nbits$ (Number of bits per subquantizer): 各サブ空間を何ビットで表現するか（通常は8）
「m = d/4」の法則：次元数に対する最適な分割数
PQの核心は「ベクトルを分割して量子化する」点にありますが、ここで重要となるのがサブベクトルの次元数です。テキストデータ（高次元の疎密な情報を含むベクトル）において、推奨されるサブベクトルの次元数は一般的に 4次元 〜 8次元 の範囲です。
これを数式化すると、元の次元数を $d$ とした時、最適な分割数 $m$ は以下の範囲に収束します。
$$ m \approx \frac{d}{4} \sim \frac{d}{8} $$
例えば、OpenAIの標準的な埋め込みモデル（1536次元）を使用する場合を考えてみましょう。
- 高精度重視 ($m=384$):
$1536 / 4 = 384$ 分割。サブベクトルは4次元となります。量子化による情報損失を最小限に抑えられるため精度は極めて高いですが、圧縮率はfloat32比で約4倍にとどまります。 - バランス重視 ($m=192$):
$1536 / 8 = 192$ 分割。サブベクトルは8次元となります。精度を維持しつつ、圧縮率を8倍まで高めることができ、コストパフォーマンスに優れた設定です。
もしメモリコストを極限まで削減したい場合でも、サブベクトルが16次元を超える設定（この例では $m < 96$）は、テキスト検索においては慎重になるべきです。Recall（再現率）が80%を下回るリスクが高まり、RAG（検索拡張生成）システムにおいては回答品質に直接的な悪影響を及ぼす可能性があります。
nbitsは基本的に「8」一択である理由
$nbits$ は、各サブ空間におけるセントロイド（代表点）の数を決定します（$2^{nbits}$）。
- $nbits=8 \to 256$ centroids
- $nbits=4 \to 16$ centroids
- $nbits=12 \to 4096$ centroids
実務的なシステム開発において、$nbits=8$ 以外を選択する合理的な理由はほとんどありません。
その最大の理由は、現代のコンピュータアーキテクチャにあります。メモリ管理の基本単位は1バイト（8ビット）です。$nbits=8$ に設定することで、量子化コードをパディングなしでメモリ上に整列させることができ、CPUのキャッシュ効率やSIMD（Single Instruction, Multiple Data）命令による並列処理効率が最大化されます。
4ビットにすればメモリ使用量はさらに半減しますが、表現力が極端に落ち、精度劣化が著しくなります。逆に12ビットや16ビットに設定すると、コードブックのサイズが指数関数的に肥大化し（$2^{12}=4096$個、$2^{16}=65536$個）、検索時のルックアップテーブル参照コストが跳ね上がります。これではPQの最大のメリットである「高速性」が失われてしまいます。
学習データ数は「256 × m」以上を用意せよ
PQを機能させるには、データの分布を学習してコードブック（Codebook）を作成するプロセスが不可欠です。この際、学習データ（Training Set）が不足していると、データ空間を適切に表現するクラスターを作れず、検索精度が出ません。
Faissの公式ドキュメントや実務での検証結果から、最低でも以下の学習データ数が必要とされています。
$$ \text{Training Data Size} \ge 256 \times m \times \alpha $$
ここで $256$ はクラスター数（$2^8$）、$m$ は分割数です。$\alpha$ は安全係数であり、最低でも30、安定した精度を求めるなら100以上が望ましい目安となります。
例えば、$m=192$ の設定であれば、最低でも約150万件（$256 \times 192 \times 30 \approx 1,474,560$）程度の学習用ベクトルがあることが理想です。
もし手元のデータが数千件〜数万件しかないプロトタイプフェーズでPQを導入しようとしても、学習がうまくいかず逆効果になることがあります。そのような場合は、無理にPQを適用せず生ベクトル（Flat Index）で運用するか、あるいは同じ埋め込みモデルで生成された公開データセットなど、類似した分布を持つ大規模データを用いて代用学習させるアプローチを検討してください。まずは動くものを作り、仮説を検証することが重要です。
精度低下を補う「リランキング（Re-ranking）」戦略との併用
ここまで読んで、「メモリは減らしたいが、精度低下はどうしても許容できない」と悩んでいる方もいるでしょう。システムアーキテクチャの工夫で解決する方法があります。
それが、「PQで候補を絞り、生ベクトルで順位を確定させる」リランキング戦略です。
PQで候補を絞り、生ベクトルで順位を確定させる2段階検索
すべてをメモリに乗せるか、すべてをディスクに置くか、という0か1かの話ではありません。ハイブリッドな構成が有効です。
- 第1段階 (Coarse Search): メモリ上の IVF+PQ インデックスを使って、高速に候補を絞り込みます。ここでは精度が多少粗くても構いません。例えば、最終的に必要なのがTop-10だとしても、ここではTop-100やTop-200を取得します。
- 第2段階 (Refine / Re-ranking): 取得したTop-200のIDに対応する「生のベクトルデータ」をディスク（SSD）や別のストレージから読み込みます。そして、クエリベクトルとの正確な距離を再計算し、正しい順位に並べ替えます。
この手法を使えば、検索速度はPQ並みに高速で、最終的な精度（Top-10のRecall）は生ベクトル検索とほぼ同等（99%以上）まで回復させることが期待できます。
ディスク上の生ベクトル読み込みとレイテンシのバランス
この戦略のボトルネックは、第2段階での「ディスクからのランダムリード」です。NVMe SSDなどの高速なストレージであれば、数百件程度のベクトル読み込みは数ミリ秒で完了します。
しかし、再計算対象（候補数）を増やしすぎると、IOレイテンシが増大します。逆に少なすぎると、第1段階での取りこぼし（Recall漏れ）をカバーできません。
IVF+PQ構成におけるnprobe設定の最適解
FaissのIVFインデックスにおける nprobe（検索時にいくつのバケツを探索するか）の設定も重要です。
- nprobeが小さい（例：1〜5）: 非常に高速だが、取りこぼしが多い。
- nprobeが大きい（例：32〜64）: 精度は上がるが、検索速度が落ちる。
リランキングを前提とする場合、nprobe を少し大きめに設定して広めに候補を拾い、PQの量子化誤差による順位の乱れをカバーするのが良いでしょう。
まとめ：エンジニアの価値は「トレードオフの制御」にある
Product Quantization（PQ）は、増え続けるデータと、有限なリソース（予算・メモリ）との間でバランスを取るための強力なツールです。
- コスト削減: メモリ使用量を90%以上削減し、インフラコストを劇的に下げる。
- メカニズム: ベクトルを分割し、コードブックで管理することで圧縮と高速化を実現。
- トレードオフ: 圧縮率と精度はトレードオフの関係。$m$ と $nbits$ の設定が重要。
- 最適解: テキストデータなら $m=d/8$、 $nbits=8$ が目安。さらにリランキングで精度を補完。
完璧なアルゴリズムなど存在しません。あるのは、要件に合わせた最適な妥協点の選択だけです。PQの特性を深く理解し、ビジネスインパクト（コスト）とユーザー体験（精度）のバランスを考慮してシステムを設計することが、真の価値を生み出します。
ベクトル検索の分野は日々進化を続けています。DiskANNやグラフベースのインデックスなど、新しい手法も次々と登場しています。常に最先端の技術スタックをアップデートし、実践的な検証を続けていきましょう。何か疑問点があれば、ぜひ議論を深めていきたいところです。
コメント