S4 Embed
ベクトル検索のFinOpsゲートウェイ
既存のベクトルDBを安く保ちつつ、リコールを目標値に維持するFinOpsレイヤー。埋め込みを量子化(binary + int8)し、二段検索(1bit Hammingの粗選別 + 厳密リスコア)をOpenSearch / pgvector / Qdrant / Milvusの前段で実行。RAM上のANNグラフを最大32倍削減します。自分のVPC内のAmazon Linux 2023 AMIとして稼働し、利用量(埋め込み・インデックス・検索)に応じた従量課金。
S4 Embed は「低コストでリコール目標を満たすベクトル検索構成」を見つけて運用するためのFinOps層です。30k件ベンチでbinary Hamming + floatリスコアはrecall@10が0.976〜1.000(ストアとover-fetch次第)に到達 — 動作点は自分で選べます。FinOpsツール群が本体: s4embed prove(リコール/コスト/レイテンシのフロンティア試算)、compare(各ストアのライブ計測)、tune(予算を満たす配備設定の生成)、ゲートウェイのshadowモード(本番と二重書き・影比較してから切替)、drift(ドリフト監視)。ストア非依存で OpenSearch / pgvector / Qdrant / Milvus に対応します。
課題
ベクトル検索の ANN グラフはインメモリで保持されるため、コーパスが大きくなるほどベクトルデータベースの RAM コストが膨らみ、運用費の予測が難しくなります。かといってリコール(再現率)を犠牲にするわけにもいかず、コストとリコールのどちらを取るかという板挟みになりがちです。さらに OpenSearch・pgvector・Qdrant・Milvus のどのストアでどの設定が最もコスト効率が良いのかを、本番に切り替える前に確かめる手段が乏しいのも課題です。
仕組み
- 1
量子化でベクトルを圧縮
埋め込みをバイナリ(インメモリの ANN グラフを最大 32 倍小さく)と int8 残差(オンディスクのベクトルを約 4 倍小さく)に量子化し、ベクトルデータベースが保持すべき RAM を削減します。
- 2
二段階検索でリコールを保持
1 ビット Hamming による粗い候補抽出で短いショートリストを作り、続いて厳密なリスコアで並べ直します。over-fetch とリスコアの動作点を調整することで、目標リコールを満たしながら RAM を抑えます。
- 3
切替前にデータで検証
s4embed prove / compare / tune がお客様のベクトルでリコール・コスト・レイテンシのフロンティアを測定し、デプロイ可能な設定を出力します。ゲートウェイの shadow モードが本番トラフィックを圧縮パスに複製・比較し、切り替え前に挙動を確認できます。
特長
埋め込みのbinary量子化でRAM上のANNグラフを最大32倍削減。30k件ベンチでrecall@10は0.976〜1.000(ストア/over-fetch次第) — 目標リコールに合わせて動作点を選択。
ストア非依存(OpenSearch / pgvector / Qdrant / Milvus)。shadowモードで本番経路を影比較し、切替前に検証。
FinOps CLI: prove / compare / tune / drift で、コスト・リコール・レイテンシを測って配備設定を出力。
含まれるもの
- Amazon Linux 2023 ベースの AMI(x86_64)— お客様自身の VPC 内で、ロードバランサーの背後で動作するベクトル検索 FinOps ゲートウェイ
- バイナリ+int8 量子化と二段階検索(1 ビット Hamming の粗い段+厳密リスコア)のパイプライン。インメモリ ANN グラフを最大 32 倍削減
- ストア非依存のパイプライン — OpenSearch・pgvector・Qdrant・Milvus に対応し、ロックインなし
- FinOps CLI — s4embed prove(リコール/コスト/レイテンシのフロンティア推定)、compare(各ストアのライブ ANN リコール計測)、tune(リコール+レイテンシ+RAM 予算を満たす設定の出力)、drift(埋め込みドリフトとリコールを監視し再チューニングを提案)
- ゲートウェイの shadow モード — 本番リードを二重書き込み・並行比較し、切り替え前に圧縮パスが既存の結果を再現するか確認
- OpenSearch と pgvector のパスを自動構築する CloudFormation クイックスタート(Qdrant・Milvus は既存エンドポイントを指定して接続)
- 運用機能 — API キー認証(設定時)、リクエストサイズと同時実行数の上限、課金やストアの異常で fail-closed する readiness プローブ、Prometheus メトリクス、使用量課金(埋め込みテキスト・インデックス文書・検索クエリ単位)
こんな用途に
コーパス拡大でベクトルデータベースの RAM コストが膨らむ、大規模な検索・RAG ワークロード
リコール目標を保ったまま、ベクトル検索のコストを下げたいチーム
OpenSearch・pgvector・Qdrant・Milvus のどのストア/設定が最もコスト効率が良いかを、本番切替前に計測したいケース
データとベクトルデータベースを自社アカウント内に保持したまま、使用量課金でベクトル検索を運用したいケース
よくある質問
圧縮するとリコールは落ちませんか?
動作点はお客様が選べます。30k 件のベクトルベンチマークでは、バイナリ Hamming+float リスコアが recall@10 で 0.976〜1.000 を記録し(OpenSearch 0.995、pgvector 0.996、Qdrant 1.000、Milvus 0.976)、いずれも 32 倍の RAM 削減のもとでの値です。over-fetch を上げるほどリコールが上がるため、目標リコールに合わせて動作点をチューニングします。リコールは over-fetch とともにスケールし、最適点はワークロードごとに異なります。
RAM はどれくらい削減できますか?
バイナリ量子化により、インメモリの ANN グラフを最大 32 倍小さくできます。加えて int8 残差でオンディスクのベクトルが約 4 倍小さくなります。削減幅はコーパスやストア、選択する動作点によって変わるため、s4embed prove / tune で実データから見積もるのが確実です。
どのベクトルストアに対応していますか?
パイプラインはストア非依存で、OpenSearch・pgvector・Qdrant・Milvus に対応します。OpenSearch と pgvector のパスは付属の CloudFormation クイックスタートで構築でき、Qdrant と Milvus は既存のエンドポイントを指定するだけで利用できます。s4embed compare を使えば、各ストアのライブ ANN リコールを比較できます。
本番に切り替える前に検証できますか?
できます。s4embed prove と tune がお客様のベクトルで設定を見積もり、compare が各ストアのライブ ANN リコールを計測します。ゲートウェイの shadow モードは本番リードを二重書き込み・並行比較し、圧縮パスが既存の結果を再現することを切り替え前に確認できます。さらに s4embed drift が埋め込みのドリフトとリコールを監視し、必要に応じて再チューニングを提案します。
データはどこに置かれ、どのように課金されますか?
S4 Embed は標準の Amazon Linux 2023 AMI として、お客様自身のロードバランサーの背後、お客様自身の VPC 内で動作します。データもベクトルデータベースもアカウント外に出ることはなく、ロックインもありません。課金は使用量ベースで、埋め込みテキスト・インデックス文書・検索クエリの単位で AWS Marketplace Metering Service を通じて毎時報告され、AWS の請求に計上されます。
料金モデル
利用量に応じた従量課金(埋め込みテキスト数・インデックス文書数・検索数) + 自分のVPC内のEC2(Amazon Linux 2023 AMI)。