HFresh: Memory-Efficient Vector Search(AIﾒﾓ)

HFreshは、メモリ使用量を抑えつつ大規模なデータセットを扱うために設計された、Weaviateのディスクベースのベクトルインデックスです。すべてのグラフとベクトルをメモリ上に保持する従来のHNSWとは異なり、データを小さな領域（Posting）に分割してディスクに保存し、効率的な2段階アプローチで検索を行います。
https://weaviate.io/blog/hfresh

HFreshの2段階検索プロセス

第1段階：インメモリのCentroid（重心）検索
クエリが入力されると、まずメモリ上にあるコンパクトな「Centroidインデックス」を検索し、関連性の高いベクトル空間の領域（Posting）を特定します。このルーティング層にはHNSWが採用されており、ベクトルはRQ8（Rotational Quantization）によって圧縮され、メモリ使用量を約4分の1に削減しています。

第2段階：ディスク上のPostingスキャンと候補抽出
特定された領域（Posting）のみをディスクから読み込みます。Posting内のベクトルはRQ1（各次元を1ビットで表現）で強力に圧縮されており、通常の32ビット浮動小数点数と比べて最大32倍もサイズが小さいため、ディスクI/Oを抑えつつ高速なスキャンが可能です。

フル精度での再スコアリング
RQ1のスコアは最終的な順位付けには使用されません。スキャンで抽出された上位候補に対して、圧縮されていない元のベクトルデータを取得し、正確な距離計算（再スコアリング）を行って最終的な検索結果を決定します。

インデックスの継続的な最適化（バックグラウンド処理）

データの追加や削除が蓄積しても、長時間を要するインデックスの全体再構築（リビルド）は行いません。代わりに、以下の小規模な操作をバックグラウンドで継続的に実行し、インデックスの品質とバランスを維持します。

Split（分割）: 大きくなりすぎたPostingを2つのバランスの取れたグループに分割し、新しいCentroidを作成します。

Merge（結合）: データ削除などで小さくなりすぎたPostingを、近接する別のPostingと統合します。

Reassign（再割り当て）: 分割や結合に伴い、ベクトルをより適切なCentroid（Posting）に移動させて精度を補正します。

この仕組みにより、検索の応答速度を一定に保ちながら、数十億規模のベクトルデータに対してメモリ効率が高く、常に最新化された状態（Fresh）での検索を実現しています。
ーーー
HFreshの第一段階（インメモリのCentroid検索）は、入力されたクエリをベクトル空間内の適切な領域（Posting）へ正確に導くためのルーティング処理を行います。

HNSWを用いたナビゲーション: メモリ上に保持されたCentroid（重心）インデックスを検索し、該当する領域を特定します。このルーティング層にはWeaviateで広く実績のあるHNSWが採用されており、グラフ構造を用いて有望なPostingの方向へクエリを素早く誘導します。

RQ8圧縮による精度とメモリ効率の両立: 第一段階でのルーティングミス（誤った領域への誘導）は、後段の検索で真の類似ベクトルを見落とす原因となるため、致命的なコストになります。そのため、極端な圧縮は避けRQ8（8ビットのRotational Quantization）を使用することで、高いルーティング精度を維持しながらCentroidのメモリ使用量を約4分の1に削減しています。

フィルター要件の事前評価: メタデータによる絞り込み条件（例：特定のブランドや価格帯など）がある場合、ACORNという仕組みを活用してHNSWグラフを探索します。オブジェクトレベルの許可リストとPostingのメタデータを照らし合わせ、条件に一致するベクトルが「少なくとも1つ以上含まれているPosting」のみを的確に選択し、無駄なディスクI/Oを回避します。

動的変更への追従: データの追加や削除によってディスク上のPostingがバックグラウンドで分割（Split）や結合（Merge）された際、このCentroid層も連動して更新され、常に最新のルーティング情報を維持します。

数十億のベクトルデータ全体をスキャンするのではなく、この第一段階で「次にディスクから読み込むべき少数の候補領域」だけを、少ないメモリ消費で正確に絞り込みます。
ーーー
HFreshの第1段階におけるHNSWグラフについて、ノードの正体とメタデータの役割は以下の通りです。

グラフのノードは「Centroid（重心）のベクトル」
HNSWグラフの各ノードは、データを分割した領域（Posting）の代表点であるCentroid（重心）です。このCentroid自体はベクトルですが、ユーザーが登録した個々のデータベクトルそのものではなく、Posting内のベクトル群の中心を示す「代表ベクトル」です。メモリを節約するため、このCentroidベクトルはRQ8という形式で圧縮されてグラフ内に保持されています。

メタデータは「ベクトルではなく、IDの管理情報」
メタデータはベクトル空間の座標データではなく、「どのベクトルID（ドキュメントID）が、どのPostingに格納されているか」を記録したマッピング情報です。
メタデータは主にフィルター検索（例：「特定のブランド」のみを検索するなど）で以下の手順で利用されます。

まず、フィルター条件を満たすドキュメントIDの「許可リスト（ビットマップ）」が作成されます。

次に、このメタデータを参照して対象を照らし合わせることで、特定のPostingが「許可リスト内のIDを1つでも含んでいるか（検索する価値がある領域か）」を瞬時に判定します。

つまり、ノードは検索クエリを正しい領域へ誘導するための「ベクトル（重心）」であり、メタデータは条件に合わない領域を効率よくスキップするための「IDの辞書」として機能しています。