选向量库：四个能定下来一切的问题

为什么跑分表会误导

你能找到的几乎所有对比，都是在公开数据集上、不带元数据过滤地测召回率和每秒查询数。而你的应用有特定的语料，多数查询带选择性过滤，延迟预算里还包括网络和重排。在这些条件下，跑分表上的排名经常反转。

这不是反对测量，而是主张测量你真正会跑的那个东西。

问题一：语料有多大，量过了吗？

数的是片段数而不是文档数，乘以维度和精度，得到大致的内存占用。如果结果能舒服地装进你已经在跑的机器内存，那单节点方案会比任何分布式方案更简单、更便宜。很多团队在真正需要之前好几年就上了分布式存储，代价付在运维面上，而不是钱上。

问题二：多数查询带过滤吗？

这正是区分各家存储的问题。如果每次查询都要按租户、权限或时效做约束，你就需要在索引内部过滤、而不是在搜索之后过滤，并且要用你真实的过滤选择性来测。一个在无过滤搜索上看起来很快的存储，当百分之九十九的候选被排除时可能彻底崩掉。

问题三：谁来运维它？

对值班这件事诚实一点。如果没有人愿意运维分布式系统，那么托管服务、或者你已在运维的数据库的一个扩展，就是正确答案——不管吞吐对比里谁赢。最便宜的存储，是你的团队不会为它半夜起床的那个。

问题四：退出成本是多少？

投入之前先搞清楚你怎么离开。向量能导出、能在别处重建吗？查询语言是可移植的，还是 SDK 已经掌控了你的代码？一个进入便宜、离开昂贵的存储是一项负债，而它恰好在最糟的时刻显现——当你有流量却没有议价能力的时候。

怎么跑这个测试

取两百条真实查询，带上它们真实的权限过滤。把你的真实语料导入两个候选存储。从你的应用侧测端到端延迟、在你实际使用的 k 下的召回率，以及新增一百万向量所需的运维步骤。一个下午做这件事，胜过任何公开的表格。