嵌入模型换一个,召回率可能差 15 个点,但很多团队是随手选的。这节给出我们的对比方法。
可复现前提: 同上一节的 150 条标注问答。评测脚本 bench/embedding,需要各模型的 API key。
对比结果
| 模型 | 维度 | recall@5 | 索引 120 万段成本 | 单次查询延迟 |
|---|---|---|---|---|
| A(通用多语) | 1536 | 0.81 | ¥420 | 38ms |
| B(中文优化) | 1024 | 0.88 | ¥310 | 31ms |
| C(开源自部署) | 768 | 0.79 | 电费 | 12ms |
| D(大维度) | 3072 | 0.89 | ¥1180 | 62ms |
三条结论
- 中文场景选中文优化的模型,比通用多语高 7 个点,还更便宜。
- 维度不是越大越好。D 比 B 只高 1 个点,成本高 3.8 倍。
- 开源自部署适合高频低要求场景。我们把它用在了"相似问题推荐"这种容错高的功能上,查询延迟只有三分之一。
一个必须提醒的坑
换嵌入模型必须重建全部索引。 不同模型的向量空间不通用,混用会得到完全无意义的结果。我们有一次灰度发布只换了一半服务的模型,线上召回直接崩了,排查了两小时才想明白。
量化能省多少
把 float32 量化到 int8,内存降 75%,recall@5 从 0.88 掉到 0.87。这个交易在我们的规模下非常划算。
# 量化前后对照,建议在你自己的数据上跑一遍再决定
python bench/embedding/quantize.py --model B --dtype int8