为什么用小评测集选
选 embedding 模型不必等大工程：准备 100 到 300 条真实问题并标注对应片段，固定切分与索引参数，只替换模型，比较 Recall@k 与 MRR，同时记录单条延迟与费用。这样得到的结论比看公开榜单可靠，因为考的是你自己的语料与问法分布——榜单靠前的模型在你的领域里未必更好。
基本信息
| 评测集规模 | 100 到 300 条真实问题起步，覆盖高频与长尾 |
|---|---|
| 核心指标 | Recall@k 看是否召回，MRR 看排位 |
| 控制变量 | 切片、索引参数、top-k 全部固定，只换模型 |
| 同时记录 | 单条延迟、显存占用、自建或调用成本 |
典型使用场景
- 首次选型：在通用小模型与领域大模型之间做取舍
- 升级评估：新版模型对自家语料的召回是涨还是跌
- 维度权衡：把向量从 1024 维降到 512 维，量化评估精度损失
- 国产化或私有化：自建模型与云端接口之间比较延迟与效果
- 回归门禁：把评测脚本接进发布流程，换模型前必须跑一遍
Recall@k 对比
Recall@k 对比
def recall_at_k(queries, k=5):
hit = 0
for q, gold_ids in queries: # gold_ids 为标注的正确片段
ids = [h["doc_id"] for h in search(embed(q), top_k=k)]
hit += any(g in ids for g in gold_ids) # 命中任一即算召回
return hit / len(queries)
for name in ["bge-base-zh-v1.5", "bge-large-zh-v1.5"]:
print(name, recall_at_k(queries)) # 切换模型时其余参数保持不变
指标读法
| 指标 | 含义 | 指标偏低时的常见原因 |
|---|---|---|
| Recall@5 | 前 5 条是否含正确片段 | 切分把答案切碎，或模型语义能力不足 |
| Recall@20 | 候选池的覆盖能力 | top-k 太小，或过滤条件过严 |
| MRR | 正确片段平均排在第几位 | 区分度不足，排名被相似噪声挤占 |
| P95 延迟 | 体验与容量规划依据 | 模型过大，或批量推理未开启 |
评测集 100 到 300 条真实问题即可起步，务必覆盖高频问题与长尾问法（缩写、型号、错别字），并随产品迭代补充。
对比实验要一次只改一个变量：同时换模型又改切分参数，效果变化无法归因到具体改动。
评测集要留出与调参集分离的验证部分：用同一批问题反复调参再报分数，指标会系统性偏乐观，上线后表现回落。