OpenSearch 向量搜尋基準的 5 種跑法
5 種 OpenSearch 向量搜尋基準跑法，從免訓練索引、只測寫入，到 Serverless、force merge 與搜尋壓測。
OpenSearch 向量搜尋要怎麼做基準測試，才不必每次都重建索引？
這篇整理 OpenSearch 向量搜尋的 5 種基準流程，幫你分清索引、訓練、合併和搜尋該測哪一段。
| 項目 | 測什麼 | 關鍵限制 |
|---|---|---|
| No-train | 索引與搜尋 | 適用不需要訓練的方法 |
| No-train index only | 只測寫入 | 不包含搜尋 |
| Amazon OpenSearch Serverless | Serverless 向量集合 | 不做 refresh 與 warmup |
| Force merge | 段合併成本 | 大資料集可能很貴 |
| Search | 既有索引的查詢表現 | 包含 warmup |
1. No-train test：免訓練的標準起點
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
這一項適合不需要訓練階段的向量方法。你可以直接定義 engine、space type 和其他方法參數，再看索引與查詢在負載下的表現。
如果你的目標是比較不同配置，而不是先花時間訓練模型，這就是最省事的入口。它也支援 HDF5 和 BIG-ANN 格式，方便重複使用同一批資料。
- 適合直接建立索引的方法
- 可比較 engine 與 space type
- 支援 HDF5、BIG-ANN 資料集
2. No-train index only：只看寫入速度
這個變體把搜尋拿掉，專心看 ingestion。若你的問題是「這個向量索引到底建得多快」，它比完整流程更容易讀出答案。
它特別適合 bulk load 調校、shard 大小測試，或不同 client 數量的實驗。相關參數像 target_index_bulk_size、target_index_bulk_index_clients、target_index_dimension，都能直接控制寫入路徑。
target_index_bulk_size: 1000
target_index_bulk_index_clients: 4
target_index_dimension: 7683. Amazon OpenSearch Serverless：對準受限環境
這個版本是給 Amazon OpenSearch Serverless 的向量搜尋集合用的。概念上仍是 no-train，但流程要跟 Serverless 的能力範圍對齊。
最重要的差異是它不包含 refresh 和 warmup，因為這些操作不支援用在向量搜尋集合上。若你要驗證的是 Serverless 部署，這種測法才不會把平台做不到的步驟算進去。
- 只用於 Serverless 向量集合
- 不做 refresh
- 不做 warmup
4. Force merge：看段合併代價
force merge 的重點是把向量索引壓到目標 segment 數，觀察合併成本。對大資料集來說，這一步可能很重，所以不適合硬塞進每一次基準流程。
如果你想知道段數縮減後，對後續搜尋或儲存佈局有什麼影響，這一項就很有用。文件把 target_index_max_num_segments 和 target_index_force_merge_timeout 都列得很清楚，方便你控制目標與等待時間。
- 先壓 segment，再看後續效果
- 適合維運或容量評估
- 大資料集成本可能很高
5. Search：直接量查詢表現
search 程序是拿已建立好的向量索引來測查詢。這樣可以避開重建索引的時間，特別適合資料量大、載入成本高的情境。
它還會包含 warmup，讓結果更接近穩態查詢表現。文件示例顯示 prod-queries 的 median latency 為 3.43393 ms，mean throughput 為 213.85 ops/s，已經能看出它能量化到什麼程度。
query_k: 10
search_clients: 8
target_throughput: 10
time_period: 900哪種適合你
如果你的方法不需要訓練，而且想先做一個通用比較，選 no-train。若你只想知道寫入有多快，就用 no-train index only；若你在驗證 Serverless 部署，則選 Amazon OpenSearch Serverless。
要看段合併成本就跑 force merge；如果索引已經存在，重點是查詢延遲或吞吐，search 最省時間，也最接近真實使用情境。