A
Member
换向量库之前只看官方跑分很容易踩坑，自己的数据、自己的查询分布才是标准。我现在的做法是先写一套小评测脚本，召回率和延迟一起测，再决定换不换。
第一步，准备评测集：从真实业务日志里抽 200~500 条查询，每条人工标出 3~5 条相关文档。合成查询分布和真实分布差太多，评测结果没有参考价值。
第二步，固定评测指标：召回率看 Recall@5 和 Recall@10，延迟看 P50 和 P99，不要只看平均延迟。平均延迟好看、P99 很差的库，上线后长尾请求会先出问题。
第三步，控制变量：同一批向量、同一查询集、同一硬件，依次测候选库。索引参数也要对齐，比如量化方式、nprobe 这类参数不对齐，比较结果没有意义。
第四步，测增量写入。很多库空库查询很快，数据量上来、增量写入频繁后，查询延迟和召回会同步下滑，这个场景要在评测里复现。
最后，评测脚本要进版本管理，换库、换 embedding 模型时直接重跑同一套脚本，结果才能横向对比。你在选向量库时，最看重召回还是延迟？欢迎分享你的评测做法。
第一步，准备评测集：从真实业务日志里抽 200~500 条查询，每条人工标出 3~5 条相关文档。合成查询分布和真实分布差太多，评测结果没有参考价值。
第二步，固定评测指标：召回率看 Recall@5 和 Recall@10，延迟看 P50 和 P99，不要只看平均延迟。平均延迟好看、P99 很差的库，上线后长尾请求会先出问题。
第三步，控制变量：同一批向量、同一查询集、同一硬件，依次测候选库。索引参数也要对齐，比如量化方式、nprobe 这类参数不对齐，比较结果没有意义。
第四步，测增量写入。很多库空库查询很快，数据量上来、增量写入频繁后，查询延迟和召回会同步下滑，这个场景要在评测里复现。
最后，评测脚本要进版本管理，换库、换 embedding 模型时直接重跑同一套脚本，结果才能横向对比。你在选向量库时，最看重召回还是延迟？欢迎分享你的评测做法。