ベクトル検索、 本番では何を見るべきか ― 正しく評価し、Business Goal に合わせて最適化する

ベクトル検索、 本番では何を見るべきか ― 正しく評価し、Business Goal に合わせて最適化する Yulan Yan (顔 玉蘭) Zilliz Founding Solutions Architect Search Engineering Tech Talk 2026 Autumn

Who am I 研究から実装まで、検索と言語を一貫して見てきた立場から 顔 玉蘭 Yan, Yulan Zilliz Founding Solutions Architect, Zilliz Milvus の開発元 NLP 研究員 NICT ・ 多言語の情報抽出・質問応答 Data & AI プラットフォームの SA Databricks ・ RAG ・ Agent ・ Vector Search ベクトル DBに専念 Zilliz ・ 検索基盤そのものを支援 Milvus Zilliz Cloud 世界で最も広く採用されている オープンソースのベクトルDB Milvus のフルマネージド版（商用 SaaS） AWS ・ Google Cloud ・ Azure 10,000 の企業が利用 （Zilliz / Milvus） プラットフォームの「 1 機能としての検索」 → 「検索そのもの」を深く見る側へ 今日の共有：どの DB が速いか、ではなく「本番で何を見て、どう判断するか」 視点変化

基本の形 ベクトル検索の基本の形 書き込み Write path Vector DB / Index layer データ Embedding Insert 商品・文書 ベクトル化 vector + スカラー属性 (category, in_stock …) 直近の書き込み まだ索引化されていない Index build / Compaction （バックグラウンド） 1 ANN Index HNSW / IVF / AUTOINDEX … 検索 Read path 2 クエリ Embedding Search 「白い靴」 同じモデル TopK + filter + search params TopK 結果 書いたデータが いつ 検索に入るか ＝ Consistency Level （Milvus 既定: Bounded） ID + 距離 + 属性 → Rerank / LLM （今日は扱わない） 評価する：Recall・Latency（p95）・QPS 3 | © Copyright 2026 Zilliz 調整する：① Index 作成時 ／ ② 検索時 のパラメータ

評価軸 Milvus で見る評価軸は 3 つ Recall Latency（p95） QPS ＝ 検索品質 ＝ ユーザー体験 ＝ スループット 全件比較の Top-K と、 どれだけ一致したか 1 クエリの応答時間。 遅い側 5% まで見る 1 秒あたりに 捌けるクエリ数 目標の例 目標の例 目標の例 Recall@10 ≥ 0.95 p95 ≤ 200 ms ピーク 3,000 QPS 効く先 結果の正しさ 効く先 SLA 効く先 コスト（必要なリソース） ＋ Cost 同じ負荷を少ないリソースで捌けるほど安い。Business Goal は「3 軸 ＋ Cost」の目標値に落とせる 4 | © Copyright 2026 Zilliz

評価軸 3 つの軸はトレードオフ QPS 例 / illustrative ef=16 Recall 0.954 ef=10 1,290 QPS p95 120 ms ef=16 ef=128 Recall 0.9999 360 QPS p95 300 ms ef=32 ef=64 ef=128 Recall を約 +0.05 上げるために QPS 約 1/3.6・p95 約 2.5 倍 ef=384 パラメータで、同じ Index が曲線上を動く Recall@10 → 5 | © Copyright 2026 Zilliz 数値は説明用の例。傾向は小規模な計測（faiss HNSW）に基づく（A6）

評価軸 Business Goal で、Operating Point を選ぶ 例：EC 商品検索 / illustrative QPS / ノード Recall ≥ 0.95 Recall ≥ 0.95 p95 ≤ 200 ms Cost 重視 ○ ピーク Cost 3,000 QPS 最小に ① Recall と p95 で候補を絞る ② 残りから、必要ノード数（Cost）で選ぶ Recall 0.954・p95 120 ms 1,290 QPS → ノード 3 台 バランス ○ Recall 0.992・p95 160 ms 880 QPS → ノード 4 台 Recall 重視 ✕ SLA Recall 0.9999・p95 300 ms 360 QPS → p95 が目標超え 目標を決めると、選ぶ点が決まる 6 | © Copyright 2026 Zilliz Recall@10 → 数値は説明用の例。傾向は小規模な計測（faiss HNSW）に基づく（A6）

最適化 同じ Index でも、Workload が変わると結果が変わる 固定： 同じ HNSW Index・同じ ef=64。変えたのは検索条件だけ（EC なら TopK 増・在庫×カテゴリで絞る） Recall@k TopK 10・フィルタなし 0.999 QPS p95 560 190 ms 例 / illustrative 1% フィルタで Recall を戻すと… ef=64 → ef=1024 TopK 100 0.990 480 220 ms フィルタ 10% 通過 0.988 550 195 ms フィルタ 1% 通過 0.365 500 210 ms Recall 0.36 → 0.92 QPS 500 → 36 p95 210 ms → 2.9 s QPS 約 1/14・p95 約 14 倍 1.0 ※ 傾向は faiss HNSW + bitmap フィルタでの計測に基づく。フィルタの扱いは実装ごとに異なる（Milvus にも独自の戦略あり） 7 | © Copyright 2026 Zilliz 数値は説明用の例。傾向は小規模な計測（faiss HNSW）に基づく（A6）

最適化 ノブ①：Index 作成時 — 種類と構築パラメータ 1 index_params = client.prepare_index_params() index_type Index の種類：HNSW / IVF 系 / DiskANN … index_params.add_index( field_name="embedding", 2 metric_type="COSINE", params 構築パラメータ：メモリ・構築時間・Recall の上限 index_type="HNSW", 1 params={"M": 16, "efConstruction": 200}, 2 3 スカラー Index フィルタ列にも（index_type 省略で型から自動選択） ) index_params.add_index( field_name="category") client.create_index("products", index_params) 選ばずに任せる場合：AUTOINDEX 3 index_type="AUTOINDEX" Milvus の既定では HNSW（M=18, efConstruction=240） ＝ 便利な出発点。Workload に合うとは限らない Index の種類・構築パラメータが“曲線”を決め、 8 | © Copyright 2026 Zilliz 検索パラメータはその上を動く Milvus（pymilvus）の例。AUTOINDEX 既定値: Milvus v2.6 の autoIndex.params.build（設定で変更可）

最適化 Index の種類は、データと Workload で選ぶ 条件（Data × Workload × Goal） 候補 メモリ目安 トレードオフ メモリに収まる・TopK 小・高 Recall HNSW ≈ 640 MB 高 QPS・高 Recall ／ メモリ最大 メモリに収まらない・SSD あり DiskANN 主に SSD 大容量・安定した Latency ／ I/O が律速 メモリ予算が厳しい IVF-SQ8 / IVF-PQ TopK が大きい（データの 1% 以上） IVF 系 フィルタが厳しい（95% 以上を除外） FLAT（全件比較） ≈ 131 / 11 MB ≈ 515 MB* 512 MB 省メモリ ／ 量子化で Recall↓（refine で補う） 大きな TopK に向く ／ 小さい TopK は graph 系 残りが少なければ速く正確 ／ 多いと遅い 目安は出発点。 最後は自分の Workload で Recall × QPS / p95 を測って決める 例：スライド 7 の 1% フィルタ（99% を除外）は、目安では FLAT の領域 9 | © Copyright 2026 Zilliz 目安とメモリ（100 万 × 128 次元 float）は milvus.io — Index Explained より。* IVF-FLAT。2026-10-23 確認

最適化

ノブ②：検索時 — TopK・フィルタ・探索幅
res = client.search(
collection_name="products",
anns_field="embedding",
data=[query_vector],
limit=10,

1

limit

何件返すか（TopK）

filter='category == "shoe"',

2

filter

スカラー条件で絞り込む

partition_names=["jp"],

3

partition_names

4

ef

探索範囲を限定

search_params={
"metric_type": "COSINE",
"params": {"ef": 64},

探索幅（Zilliz Cloud: level）

},
)

検索ごとに変えられる。Index を作り直さずに、曲線上の点を動かせる
10

| © Copyright 2026 Zilliz

Milvus（pymilvus MilvusClient.search）の例。検索パラメータは Index 種類ごとに異なる（HNSW: ef / IVF: nprobe）

最適化 TopK と ef は、こう決める TopK 状況 決め方 トレードオフ 画面に表示する 表示件数そのもの（例：10） 最も軽い Rerank / LLM に渡す 次段が必要とする候補数（例：50〜100） TopK ↑ で QPS ↓・p95 ↑ ページング offset + limit（上限 16,384） 深いページほど重い Recall 目標がある 目標を満たす最小の ef（ef ≥ TopK） 上げすぎると QPS ↓・p95 ↑ だけ フィルタが厳しい ef を上げる、または FLAT・パーティション スライド 7 の 1% フィルタ ef 手順：TopK を決める → ef = TopK から上げる → Recall 目標を満たした最小の ef で止める → p95 / QPS を確認 例（スライド 6）：Recall ≥ 0.95 を満たす最小は ef=16。余裕を見て ef=32 でも p95 160 ms で目標内 11 | © Copyright 2026 Zilliz Zilliz Cloud level の目安: docs.zilliz.com（Tune Recall Rate）。TopK 上限は Milvus の既定値（設定で変更可）

マネージド 調整には、テストと経験が要る 自分でやる場合のループ 選択肢：Zilliz Cloud Milvus の開発元によるマネージドサービス Index を選ぶ 構築パラメータ HNSW / IVF / DiskANN … M, efConstruction / nlist AUTOINDEX データ分布を分析して、Index を自動で設定 level 1〜10 検索時の精度 ↔ 速度を 1 本のノブで 3 軸で計測 検索パラメータ Recall × p95 × QPS TopK, ef / nprobe データや Workload が変わるたびにやり直し。 enable_recall_calculation 推定 Recall を返す（正解の準備は不要） 要件に合わせて、インフラ構成も選べる（→ 次） 任せても、評価軸は同じ。どの点を選ぶかは Business Goal 次第 12 | © Copyright 2026 Zilliz 出典: docs.zilliz.com（AUTOINDEX Explained / Tune Recall Rate）2026-10-23 確認

マネージド インフラ設計：検索時にデータをどの層に置くか A. Performance 優先 B. バランス C. Cost 優先 Memory のみ（All in memory） Memory + Local disk Memory + Local disk + Object storage Memory Hot ベクトル + Index すべて 圧縮ベクトル・Index の一部 Hot：よく使うデータ Local disk（SSD） Warm 使わない グラフ・元のベクトル Warm：ディスクにキャッシュ Object storage Cold 使わない 使わない Cold：全データ、必要時に取得 Index 例 HNSW・IVF 系（in-memory） DiskANN 系（disk-based） 階層キャッシュ前提の Index 特徴 QPS・Latency 最良 / Cost 最高 容量と性能の中間 容量最大・Cost 最低 / 最も遅い 数値例 * 500–1,500 QPS・10 ms 200 万 / CU・$63〜 100–300 QPS・50–100 ms 800 万 / CU・$16〜 10–50 QPS・100–1,000 ms 4,000 万 / CU・$5〜 ※ 図は検索時にデータを読む層。永続化先とは別（例：Milvus はどの構成でも Object storage に永続化） 要件がインフラ（器）を決める。 器を決めた後も、その中の Index と検索パラメータは別に最適化が必要 13 | © Copyright 2026 Zilliz * 数値例：Zilliz Cloud の Performance-optimized / Capacity-optimized / Tiered-storage 公開値 768 次元、価格は 100 万ベクトル・月あたり。zilliz.com/pricing（2026-10-23 確認）

14 | © Copyright 2025 Zilliz

まとめ ベクトル検索、本番で見ること 1 評価軸は 3 つ Recall（品質）・p95（SLA）・QPS（コスト） 2 Business Goal で 3 軸 ＋ Cost の目標から、点を選ぶ 3 ノブは 2 か所 Index 作成時 ／ 検索時 正しく評価軸を持ち、その軸の上で 目的に合った Operating Point を選ぶ 15 | © Copyright 2026 Zilliz

APPENDIX 参考リンク Milvus — Single-Vector Search https://milvus.io/docs/single-vector-search.md Milvus — AUTOINDEX 既定値（v2.6 ソース） https://github.com/milvus-io/milvus/blob/v2.6.0/pkg/util/paramtable/autoindex_param_nocuda.go Tune Recall Rate（level / enable_recall_calculation） https://docs.zilliz.com/docs/tune-recall-rate Milvus — Index Explained（Index 選択の目安） https://milvus.io/docs/v2.5.x/index-explained.md Milvus — Consistency Level https://milvus.io/docs/consistency.md Zilliz Cloud Pricing https://zilliz.com/pricing Balancing Precision and Performance（level 測定例） https://zilliz.com/blog/balancing-precision-and-performance-how-zilliz-cloud-new-parameters-help-you-optimize-vector-search ANN-Benchmarks https://ann-benchmarks.com/index.html 16 | © Copyright 2026 Zilliz 2026-10-23 / 10-29 確認

• https://milvus.io/docs/single-vector-search.md
• https://github.com/milvus-io/milvus/blob/v2.6.0/pkg/util/paramtable/autoindex_param_nocuda.go
• https://docs.zilliz.com/docs/tune-recall-rate
• https://milvus.io/docs/v2.5.x/index-explained.md
• https://milvus.io/docs/consistency.md
• https://zilliz.com/pricing
• https://zilliz.com/blog/balancing-precision-and-performance-how-zilliz-cloud-new-parameters-help-you-optimize-vector-search
• https://ann-benchmarks.com/index.html

ありがとうございました