宣布个好消息，大家期待已久的VDBBench 1.0更新啦。
尝鲜链接：
https://github.com/zilliztech/VectorDBBench/releases/tag/v1.0.0
对于这个功能的更新，我们准备了很久，也思考了很多。
因为对我们来说，VDBBench 从来不只是一个测试工具。它是对向量数据库要走向哪里的抽象，也是一种工程经验的沉淀。
一个好的 Benchmark，不仅能验证产品的性能，更能指出明确行业的关注重点，传达什么是真正值得优化的问题。
就像过去五十年，摩尔定律对晶体管密度的要求，在硬件层面为产业设定了“增长的节奏”；过去十多年，ImageNet 以任务驱动方式，让大家通过不断的方法创新带来一次次AI技术路径的优化；而大模型时代，Scaling Law 从训练数据、参数规模与能力之间找出了指数关系，间接影响了所有基础模型的训练策略。
而这些成功案例的底层共同点都指向了同一个方向，行业标准与会与行业整体的演化路径绑定。
相比之下，过去向量数据库 Benchmark 与真实场景的偏差，不仅影响了很多用户对产品的认知与评估，甚至已经很大程度影响到了向量数据库系统设计的有效性。
因此，在本次的VDBBench 1.0 更新中，我们不仅在技术上做了许多突破，也倾听了社区的声音，力求提供一个更符合生产需求的基准测试工具。
功能设计上，VDBBench 1.0 中，你会看到我们：
🚀 重新设计的 UI：全新的主页和数据分析页面，让您可以更加直观、便捷地可视化和对比不同的测试结果。
🏷️ 标签过滤测试：新增了基于标签的过滤性能测试case，用户可以根据特定条件（例如：颜色 == "红色"）模拟真实的查询场景，提升了测试的实用性。
🌊 流式读写测试：在数据持续插入的同时，测量搜索性能，模拟“边写边读”的稳定性，让我们更接近真实的生产环境。
🔬 新的 BioASP 数据集：新增了 1024 维的 BioASP 数据集（1M 和 10M 向量），专门用于高维数据的性能测试。
⚙️ 灵活的自定义数据集：现在你可以更灵活地配置反映自己业务需求的数据集，真正做到按需测试。
除了功能上的更新，我们还对 Milvus、ZillizCloud、ElasticCloud、QdrantCloud、Pinecone 和 OpenSearch（AWS）等主要平台的基准结果进行了重新测试和更新，确保一切数据都是最新、最真实的。
01 为什么传统Benchmark无法用于生产
说实话，POC（概念验证）在某种程度上就是一个“照妖镜”。它能让那些没有实质性价值的东西原形毕露。但有个诡异的现象，人人都在嘴巴上喊着“别刷榜”，但自己却又参与其中。
这就带来一个非常矛盾的现实：大多数的Benchmark其实对生产环境没有太大帮助，但它们却恰恰在帮一些产品掩饰自己的短板，让它们看起来更加“高大上”。
这种现象在向量数据库领域尤为突出。自从2023年向量数据库市场爆发后，很多自研的向量数据库为了刷榜，不惜在各种Benchmark中做文章，结果一刷就“爆”，一用就“废”，不仅浪费了时间，甚至影响了项目进度。最重要的是，这种现象一度让整个行业的口碑遭到损害。
比如，Elasticsearch 虽然对外宣传查询速度是“毫秒级”，但实际优化索引的过程就需要 20 多小时。在这种情况下，谁能忍受这种长时间的停摆呢？
再比如，传统的Benchmark通常会假设：数据已经完全导入，索引已经建立完毕，但现实中，数据是持续流入的。为了重建索引而让系统停机几个小时，几乎是无法想象的。
传统向量数据库Benchmark与生产有多脱节，案例不胜枚举，影响最大的主要集中在三处：
1.数据集维度过时
很多基准测试还在用 SIFT 或 GloVe，但是SIFT 只有 128 维，而 OpenAI、Cohere 的主流模型的embedding模型维度是 768~3072 维，这些数据集的维度远低于当前大模型生成的embedding维度。
2.测试方法存在瑕疵
尤其是在并发测试吞吐量时，设定的并发数量和并发机制不能测试出database最佳性能。
3.测试用例过于简单
现实中，用户查询往往是这样的：一边是数据持续写入，一边是需要复杂的元数据过滤。但市面上的Benchmark基本没有考虑到这一点，大多只跑最基础的查询前先写完数据、建完索引之类 Hello World 级别的测试。
这些Benchmark指标完全脱离实际，与生产环境的需求背道而驰。这也让一些不负责任的产品有了浑水摸鱼的机会，让那些想要真正为客户解决问题的公司，被迫加入恶性内卷，浪费了大量的时间和精力。
02 VDBBench 1.0 更新背后的思考
这次 VDBBench 1.0 的更新，是基于我们对向量数据库在真实生产环境中使用场景的深刻理解而做出的，希望每一项功能的更新都能帮助用户更精准地衡量和优化性能。
以下是我们做出这些更新的深层次原因：
🚀 重新设计的 UI
传统的 benchmark 工具通常过于注重数据对比结果输出，而忽视了数据的呈现与交互性。在实际使用中，如何高效地理解这些数据对比结果、从中提取有价值的信息，直接影响测试结果的使用价值。
因此，我们重新设计了 UI，强调可视化和交互性，用户能够更加直观地对比不同的测试结果，发现不同产品之间的差距，并迅速做出决策。
🏷️ 标签过滤测试
通常来说，带过滤条件的搜索是一个常见的实际应用场景，比如，在电商或推荐系统中，用户往往会根据不同的标签或特征筛选数据（如“颜色==红色”）。
与此同时，过滤搜索会增加整体系统复杂度，主要体现在两方面：
过滤复杂度（Filter Complexity）：涉及的标量字段越多、逻辑条件越复杂，可能导致召回不足、图索引变成孤岛等等情况。
过滤选择性（Filter Selectiveness）：这是我们在真实生产中反复验证的“隐藏性能杀手”。过滤条件变“挑剔”之后，可能导致recall的波动，QPS 甚至会波动几个数量级。
而传统的 benchmark 测试往往忽视了业务场景的复杂性，只能进行基础的查询操作，无法模拟这种复杂的实际查询需求。
因此，我们通过标签过滤功能，模拟现实中常见的复杂查询场景，帮助用户真实地测试系统在多样化、复杂条件下的表现。
VDBBench可以针对不同的过滤量（从 50% 到 99.9%）进行系统测试，全面评估数据库在这一关键生产场景下的处理能力，提供更具现实意义的性能画像。
经测试发现，Milvus 和 OpenSearch 在 Cohere 1M 测试中，不同过滤选择性条件下的 QPS 和召回率表现如下：
Milvus 在不同过滤条件下始终保持了极高的召回率，而 OpenSearch 的表现则不稳定，看似QPS表现较好，但是recall < 0.8在生产中常常是不可接受的(测试结果见文末链接)。
🌊 流式场景
真实的生产环境并非单一的“只读”或“只写”场景，更多的是“边写边读”的并行场景。
一些极端情况，可能还会出现在高并发、高负载情况下，系统在处理查询请求的同时，还要不停地写入新数据。例如，金融或社交网络应用中，数据的生成和查询几乎是同时进行的。
许多传统的 benchmark 测试忽视了这一点，只模拟了单一的查询或数据插入操作，导致测试结果无法反映出在同时处理数据读写时的系统性能瓶颈。
因此，我们设计了流式场景，模拟真实的读写并行情况，帮助开发者更好地理解系统在高并发环境下的稳定性，尤其是数据写入对查询性能的影响。
流式场景是一种更全面的压力测试。而设计这样的Benchmark本身也很有挑战，因为目标不是简单地描述某个数据库的表现，而是要提供一个公平、可比较的评估模型，让你能够放心地对不同数据库的表现进行横向比较。
我们在支持用户使用多种向量数据库进行 POC（概念验证）时积累了丰富经验，并据此构建了结构化的测试方法：VDBBench 允许你预先设定写入速率（以目标负载为依据），确保每个数据库承受的是完全一致的压力，从而使搜索性能具有可比性。
例如，在 Cohere 10M 数据集和设定 500 行/秒写入速率的测试中：
VDBBench 启动 5 个数据写入进程，每个进程以 100 行/秒的速度写入。
每写入完 10% 的数据，就进行一次搜索测试（包含串行与并发模式），并记录相关指标，包括延迟、QPS 和召回率。
这种可控的测试方法，清晰揭示了数据库在真实生产负载下性能的演变轨迹，帮助你判断系统在持续写入压力下是否可靠。
经测试，在 Cohere 10M 流式测试（500 行/秒写入速率）中，Pinecone 与 ElasticSearch 的 QPS 和召回率表现为：
Pinecone 在整个测试过程中维持了更高的 QPS 和召回率，尤其在数据插入完成（达到 100%）后，QPS 表现出显著提升(测试结果见文末链接)。
🔬 新的 BioASP 数据集
我们新增了 BioASP 数据集，专门用于高维数据的性能测试。
在面对现代大规模向量数据时，传统 benchmark 使用的数据集已经远远不能满足测试需求。比如，SIFT 和 GloVe 这类数据集通常用于较小规模的低维向量，但如今的模型，尤其是大模型（例如 OpenAI 和 Cohere 的嵌入模型），其向量维度通常远超这些传统数据集，且规模上也大得多。
BioASP 数据集（1024维，支持1M、10M向量）恰好能够覆盖这一高维度、海量数据的场景，更好地模拟现代向量数据库的实际负载。
通过这样的数据集，我们能够测试系统在大规模高维数据上的表现，包括存储、查询和检索的性能，确保测试结果能够真实反映现代大数据场景下的挑战。
⚙️ 灵活的自定义数据集
每个行业和业务场景的需求都是不同的，传统的 benchmark 由于数据集的固定性和单一性，往往无法满足个性化和业务化的测试需求。
为了让用户能够根据自己业务的实际情况进行定制化测试，我们推出了灵活的自定义数据集功能。用户现在可以自由配置数据集的维度、规模以及数据类型，使得 benchmark 测试更加贴合自己独特的业务场景，真正做到“按需测试”。
比如，对于金融行业来说，可能需要更多针对交易数据的测试；而对于社交平台，则可能更关注用户行为数据的性能表现。
灵活的自定义数据集功能使得 VDBBench 不再只是一个通用的性能测试工具，而是可以根据实际场景量身定制的精准测试框架。
03 VDBBench 如何还原真实生产场景？
当然，VDBBench 不只是以上几个新功能，从底层的设计来说，VDBBench 彻底放弃对已有Benchmark做简单迭代，选择直接从零构建，过程中唯一的指导原则就是：真实、真实、还是真实。
围绕向量数据库的使用场景，我们将真实可以分为三个维度：
真实的数据、真实的工作负载、真实的性能测试方式。
（1）真实的数据
我们对用于向量数据库Benchmark的数据集进行了全面升级。用最新的embedding模型生成的向量数据，彻底取代 SIFT 和 GloVe 这类古董数据集。
为了确保数据在RAG之类的场景中真实可用，我们精心挑选了覆盖真实企业和垂直行业场景的文本语料。这些数据包括从通用知识库到生物医学问答、大规模网页搜索等多种类型，全面覆盖当代 AI 应用的主流需求。
Datasets used in VDBBench
此外，VDBBench 还支持自定义数据集。你可以使用自己通过embedding模型生成的数据，针对特定工作负载进行测试。这使得Benchmark的测试结果能够直接反映真实生产环境。
说白了，外面再吹得天花乱坠的数据，都没有企业自己的真实数据能说明问题。
（2）真实的工作负载
在全新的 VDBBench 中，我们将性能评估的重点聚焦于真正影响生产环境中用户体验的指标设计，比如：
使用 P95/P99 延迟衡量真实用户体验
平均延迟或中位数延迟并不总能反映真实体验。对用户来说，更重要的是尾部延迟——也就是 P95（95 分位）或 P99（99 分位）延迟。在 VDBBench 中，我们专门测量这两个指标，从而揭示在真实场景中，95% 或 99% 的查询实际能达到的性能表现。
报告系统可持续承载的 QPS，而非短暂峰值
VDBBench 不重点关注昙花一现的性能峰值，因为这个指标注水空间太大，因此我们通过逐步增加并发负载，找出系统在稳定运行条件下可长期维持的最大查询吞吐量（max_qps）。这才是衡量数据库真实处理能力的关键指标。
公开 Recall，将性能指标锚定于准确性
在向量搜索中，速度很重要，但不是唯一的重点，如果没有准确率（recall）的配合，这种性能数据本身毫无意义。
VDBBench 在每一项测试中都附带对应的 Recall 值，让用户能够准确了解当前性能下的查询准确度。这样，才能实现系统间真正公平、具备生产参考价值的横向对比。
（3）真实的性能测试方式
VDBBench 的设计核心在于还原真实使用场景，而非理想化的实验室条件。其中一个关键思路是将串行测试与并发测试分开进行，以更全面地捕捉系统在不同负载下的表现。例如，对于延迟指标，我们会分别记录：
serial_latency_p99：衡量系统在极低负载下（即一次只处理一个请求）时的性能，代表理想延迟的最佳情况。
conc_latency_p99：衡量系统在高并发条件下（即同时接收多个请求）时的响应能力，更贴近真实生产环境中的用户体验。
我们将基准测试划分为两个主要阶段：
串行测试（Serial Test）
该阶段为单进程运行，共执行 1,000 次查询，用于建立理想情况下的性能和准确率基线，包括 serial_latency_p99 和 recall。
并发测试（Concurrency Test）
该阶段模拟生产环境中的实际负载压力，具体设计如下：
真实的客户端模拟：每个测试进程独立运行，拥有自己的连接和查询集合，避免测试进程间互相通信干扰结果。
同步启动：所有测试进程同时开始，确保测得的 QPS 真正反映设定并发下的系统吞吐能力。
通过这些严谨设计，VDBBench 提供的 max_qps 和 conc_latency_p99 指标具备高度可信度，可直接用于用户的生产能力规划与系统评估。
经测试发现，Milvus-16c64g-standalone 在 Cohere 1M 测试下不同并发等级的 QPS 和延迟表现如下：
当并发数低于 20 时，Milvus 处于负载不足的状态，增加并发有助于更好地利用系统资源，因此 QPS 提高。 但当并发超过 20 后，Milvus 达到饱和负载，继续增加并发不会带来更多 QPS，反而因为排队时间变长，延迟上升(测试结果见文末链接)。
总结：别再被“假数字”骗了
前面说了那么多，其实总结起来就是一句话，别迷信数据，更别迷信对生产效益不大的数据。
相比传统Benchmark，VDBBench 通过覆盖持续数据写入、元数据过滤和流式负载等关键场景，能够更贴近实际生产环境。
尝鲜链接：
https://github.com/zilliztech/VectorDBBench/releases/tag/v1.0.0
测试结果展示：https://zilliz.com/vdbbench-leaderboard?dataset=vectorSearch
但是，不要迷信任何纸面数据，再细致的Benchmark设计，也永远无法覆盖所有真实场景中千变万化的客户需求。
作者介绍
田敏
Senior Software Engineer at Zilliz
推荐阅读
实战｜TRAE+Milvus MCP，现在用自然语言就能搞定向量数据库部署了！
实战|CLIP+Milvus，多模态embedding 如何用于以文搜图
