100万チャンクには、一般的なfloat32ベクトルだけでおよそ1.5~6.1GBが必要です。グラフインデックス、メタデータ、テキスト、レプリカ、作業領域は含まれていません。
計算の起点はドキュメント数ではなく次元数です。100万個の768次元float32ベクトルには、4バイトの値が7億6,800万個含まれるため、10進表記で約3.07GBになります。実際に運用できるストアは、ベクトルの識別、効率的な検索、メタデータのフィルタリング、チャンクテキストの保持、さらにサーバー上での検索とメンテナンス処理中のインデックス保守に耐える必要があるため、これより大きくなります。
生のベクトルバイト数が再現可能な下限になる
チャンク数に埋め込みの次元数と、各座標のバイト数を掛けます。100万個のfloat32ベクトルでは、384次元なら1.536GB、768次元なら3.072GB、1,536次元なら6.144GBです。2進ギガバイトで表示すると、数値は約7%小さくなります。
スケーリングの概要でも、同じ生のベクトルストレージの関係が示されています。データベース構造を考慮する前の座標データ量は、次元数に値のビット幅を掛けて決まります。
float16ならベクトル要素の容量を半分にでき、int8や積量子化ならさらに削減できます。ただし、圧縮によって再現率に影響が出る可能性があり、データベース側の対応も必要です。これらの数値には、元のドキュメントや生成されたチャンクテキストは含まれていません。
インデックスとメタデータは座標データに匹敵する容量になる
フラット検索はインデックス構造の追加が比較的少ない一方で、多数のベクトルをスキャンします。HNSWは近傍リンクと複数のグラフ階層を保持し、検索処理を減らします。ベクトルごとのID、削除レコード用のトゥームストーン、フィルター、アライメント、データベースページによって、さらにオーバーヘッドが加わります。
HNSW接続の解説では、グラフ接続によって近似検索が高速化する一方、追加のメモリとストレージを消費する理由が説明されています。設定した近傍数によって、このコストは直接変わります。
メタデータによる差はさらに大きくなります。簡潔なドキュメントIDと言語コードなら数十バイト程度ですが、繰り返し使用されるパス、権限、チャンクテキスト全体を含めると、数百バイトから数千バイトが追加されることがあります。合計を比較する前に、テキストを一度だけ保存するのか、ベクトルデータベース内に保存するのかを統一してください。
単一のストレージ見積もりでは不十分な理由
768次元float32のチャンクが100万個ある場合、実用上の計画範囲は、相当量のテキストやレプリカを除いて、ベクトルと近似インデックスだけで5~12GBになることがよくあります。これは予算策定の範囲であり、特定のフォーマットを保証するものではありません。
ベクトルアーキテクチャの比較では、一部のHNSW構成において、HNSWストレージのオーバーヘッドが生の座標データを大幅に上回ると見積もられています。実際の倍率は、エンジンのデフォルト設定とグラフパラメーターによって決まります。
チャンクごとに複数の埋め込みを使用する場合、ハイブリッドキーワードインデックス、レプリケーション、スナップショット、またはデータを一時的に重複させる再構築を行う場合、この範囲では不十分です。一方、圧縮されたディスクバック型ストアでは過大評価になることもあります。「100万チャンク」という情報だけでは不十分で、次元数、データ型、インデックス、メタデータ、コピー数を明示する必要があります。
10%のインデックスサンプルから外挿する
最終的な埋め込みデータ型、メタデータスキーマ、インデックスパラメーターを使用して、代表的なチャンク10万個を挿入します。コンパクション後に、生のベクトル列、インデックス、メタデータ、テキスト、先行書き込みログ、スナップショットの容量をそれぞれ測定します。スケーラブルな構成要素を10倍に外挿し、再構築用とバックアップ用の余裕を加えます。
圧縮とファイルシステムの割り当てが物理容量に影響するため、テストは想定するストレージ作業領域のストレージ階層上で実施してください。空のデータベースファイルから外挿するのは避けます。
測定した定常時の合計容量に、少なくとも一時的なインデックスコピー1つ分と20%の空き容量を加えて予算化します。レプリケーションを有効にしている場合は、レプリケーション対象の構成要素だけを乗算します。次元数、メタデータ、HNSWの近傍設定を変更するたびに、サンプル測定を繰り返してください。
テック&AIハブ
もっと読む

ローカルRAGの検索品質を測定し、再現率・適合率・引用カバレッジを解釈する方法
ローカルRAGのテストセットを構築し、主要な検索指標を算出し、それらのトレードオフを解釈し、回答の主張が引用された根拠によって裏付けられているかを監査する。

サンプリングレートが同じ場合、センサー数の増加に伴ってスマートホームの機能計算がより重要になるのはなぜですか?
デバイス数の増加に伴うセンサーごとおよびセンサー間の計算処理を追跡し、非線形な融合コストを特定して、自動化処理に遅延が生じる前に特徴量パイプラインのベンチマークを実施します。

同じクエリ量でも、ドキュメントライブラリが拡大するとRAG評価コストが重要になるのはなぜか?
ユーザークエリを増やさずにコーパスの拡大がRAG評価の工数を増加させる理由と、層別テストによってコストをリスクに応じて抑えられる仕組みを理解する。

