Bob's Garden

Embedding 模型选型参考 · 公开 Benchmark 与合成 Query

8分钟阅读

Embedding 模型选型参考 · 公开 Benchmark 与合成 Query

面试亮点专题 · 客观数据支撑选型决策 + 测试数据质量意识

一、公开 Benchmark 概览

MTEB（Massive Text Embedding Benchmark）

  • 维护方：Hugging Face（2022 年发布，持续更新）
  • 覆盖范围：58 个数据集，跨 8 类任务（检索、聚类、分类、重排序、语义相似度等）
  • 语言：英文为主，部分多语言
  • 排行榜：huggingface.co/spaces/mteb/leaderboard
  • 用途：英文通用 Embedding 模型的事实标准基准

C-MTEB（Chinese MTEB）

  • 维护方：FlagAI / BAAI（BGE 系列团队）
  • 覆盖范围：35 个中文数据集，6 类任务
  • 排行榜：huggingface.co/spaces/mteb/leaderboard（同页面，切换语言筛选）
  • 用途：中文 RAG 项目选型最直接的参考

BEIR（Benchmarking IR）

  • 维护方：学术界（2021 年论文）
  • 覆盖范围：18 个异构检索数据集（生物医学、金融、新闻、问答等）
  • 核心价值：专测零样本泛化能力——在完全没见过的领域能不能检索准确
  • 用途：评估模型在新领域的迁移能力

二、当前模型排名参考（2025 年）

中文检索（C-MTEB Retrieval 子集）

排名模型维度特点
1Qwen3-Embedding-8B（通义）40962025 年最新，C-MTEB 全面领先
2BGE-M3（BAAI）1024开源基线首选，支持多语言，同时支持 Dense/Sparse/ColBERT
3text-embedding-3-large（OpenAI）3072英文强，中文表现受限
4ZhipuAI embedding-32048无完整 C-MTEB 公开数据，官方数据选择性披露

关键结论

  • BGE-M3 是中文 RAG 的开源基准：有完整 C-MTEB 数据，可复现，社区广泛验证
  • Qwen3-Embedding-8B 是 2025 年新标杆：但需要本地部署或 API，推理成本更高
  • ZhipuAI 缺乏公开基准数据：v4 实验中”最佳”结论不可信——7 条 Query 统计意义不足，且 ZhipuAI 本身没有第三方基准验证

三、为什么 v4 实验结果不能直接用于选型

v4 结论：ZhipuAI embedding-3 MRR=1.000（最佳）

问题：
1. 样本量太小：7 条 Query，1 条区分度差异 = 14% 的统计噪音
2. 领域单一：测试文档是 RAG 教程，特定领域的好坏不代表通用能力
3. ZhipuAI 缺乏公开验证：无法与 C-MTEB 排名交叉对照
4. 合成 Query 陷阱（见下节）：如果测试 Query 是 LLM 生成的，指标会虚高

正确做法：

  • 先看 C-MTEB 公开排名，缩小候选范围（去掉无公开数据的模型）
  • 用自己的业务数据（50~100 条人工标注 Query）做最终验证
  • 两个来源吻合 = 选型可信

四、合成 Query（Synthetic Query）

定义

用 LLM 从文档 chunk 自动生成测试问题，替代人工标注 Query。

chunk: "推荐分块大小在200到500个字符之间，并设置约10%到20%的重叠区域"
          ↓ LLM 生成
query: "RAG 系统中推荐的分块大小范围和 overlap 比例是多少？"

优点

  • 零人力成本：批量生成，1 分钟生成 100 条
  • 覆盖全面：每个 chunk 都有对应 Query，不漏测
  • 适合早期：快速验证系统是否能工作（smoke test）

核心缺陷：指标虚高

原因：LLM 生成 Query 时直接看到了 chunk 原文
      → Query 和 chunk 的词汇高度重叠
      → Embedding 相似度天然偏高
      → Recall@3 和 MRR 虚高，可能 10%~30%

现实用户的 Query 不会这样：
  用户会换说法、省略关键词、加入噪音词（如"RAG"主题词干扰）
  → 真实难度更高

正确使用方式

用途适合用合成 Query？原因
验证系统可以跑通✅ 适合只需粗略验证
不同分块策略横向对比✅ 适合相对对比，绝对值无意义
建立优化基线❌ 不适合基线虚高，后续优化无意义
模型选型最终决策❌ 不适合需要人工标注反映真实用户行为
向业务方汇报效果❌ 不适合数字不可信

经验法则：合成 Query 用于”发现问题”，人工 Query 用于”量化改进”。

五、v3.5 黄金数据集的设计原则回顾

v3.5 选择人工标注而非合成 Query，理由：

  1. 真实用户措辞：Q001 里的”RAG”主题词干扰是真实的，合成 Query 不会产生这种干扰
  2. 基线可信：后续 v4~v7 的指标提升才有意义
  3. 发现真实 badcase：Q001 MRR=0.5 是真实弱点，合成 Query 会掩盖它
如果用合成 Query 建基线：
  Q001 合成版 = "RAG 系统推荐的分块大小和 overlap 比例是多少？"
  → 词汇完全匹配 answer_chunk
  → 向量检索也能正确命中（无主题词干扰）
  → MRR=1.0，看不出问题
  → v5 混合检索的 RRF 平局陷阱永远不会被发现

六、面试表达

“在选型 Embedding 模型时，我不会直接相信供应商的宣传数据。我会先看 C-MTEB 公开排行榜——这是中文检索的事实标准基准，有可复现的第三方数据。ZhipuAI 等部分模型缺乏完整的公开基准数据，我会把这类模型排在较低优先级。

最终选型需要在自己的业务数据上验证，50~100 条人工标注 Query 就够——注意不能用合成 Query，因为 LLM 生成的 Query 和原文词汇高度重叠，指标会虚高 10%~30%，掩盖真实弱点。

我在 v4 实验里就踩过这个坑：7 条 Query 太少，ZhipuAI ‘最佳’ 这个结论统计意义不足，不能据此做选型决策。“

七、关联知识点

  • v3.5 黄金数据集 → 人工标注 Query 的设计原则
  • v4 Embedding 选型 → 实验局限性分析
  • 05_混合检索RRF平局陷阱专题分析.md → Q001 是如何被人工 Query 发现的
  • RAG 评估方案汇总 → 04_rag评估方案汇总.md

关系图谱