embeddinggemma-2-zh

google/embeddinggemma-2（2026-10-06 发布，740M 多模态嵌入模型）的中文能力实测与中文微调工作仓。

本仓库包含两样东西：

微调不是本仓库的卖点，结论才是。下面把涨的和跌的全部列出，不做选择性披露。 代码与完整原始结果：https://github.com/Weidows/embeddinggemma2-zh

为什么做这个

google/embeddinggemma-2 的官方评测覆盖 MTEB（多语言 v2）、MIEB、MAEB， 但发布后 48 小时内没有任何中文基准数字：声明 base_model=google/embeddinggemma-2 的 60 个衍生仓库里零中文；GitHub 搜 embeddinggemma + C-MTEB 与 + chinese 均为 0 仓库； 中文圈内容全部是转载/新闻。（核实时间：2026-10-08）

实测结果 — C-MTEB（MTEB(cmn, v1)，31 个中文任务）

只加载文本骨干（config_kwargs={"vision_config": None, "audio_config": None}，271.0M 参数）， bf16，截断 2048，batch 16。

用 bge-m3 一半的参数量，拿到它约 96% 的中文成绩；7 个单项反超 bge-m3。

按任务类型

明确的短板（对 bge-m3 落后约 0.10）

→ 收敛为两块：医疗领域（检索 + reranking） 与 中文 STS（AFQMC / ATEC / BQ）。

两点需要澄清（容易被误读）

• PAWSX 0.1497 不是它的短板：bge-m3 也只有 0.1566，这是对抗性改写任务本身难。
• 中文聚类并不弱：本模型 0.4925 高于 bge-m3 0.4615（ThuNews 两项各反超约 0.07）； 只是不及 Qwen3-Embedding-0.6B。

中文微调（LoRA r=32）— 结论：零和

针对上面 6 个短板做的定向微调。结果是净收益 +0.0037，实质为零，涨的和跌的几乎抵消。

方法

结果（31 任务，微调前 → 微调后）

涨的

跌的

为什么会零和（诊断）

1. 不是灾难性遗忘：不在靶单里、本来也不弱的 LCQMC 只动了 −0.0002。通用能力没有雪崩。
2. 是数据覆盖缺口：训练集只有「通用中文 STS 短句 + 医疗 QA」，没有 NLI 数据、没有通用检索的 (query, passage) 对。 结果就是练过的域涨、没练过的域跌 —— PairClassification（Ocnli/Cmnli）是纯副作用， 通用检索（Covid/MMarco/Du/Ecom/T2）是域偏移（医疗检索涨 +0.09/+0.04，通用检索跌 −0.03~−0.13）。
3. 长文属分布外：训练时 max_seq_length=192，而评测用 2048。

→ 想把这轮微调做成正收益，缺口的补法是明确的：补 Ocnli/Cmnli 的 train split（NLI 正负对， 这两个数据集本身就有 train split）和 通用中文 (query, passage) 对，并把训练长度提到 512。 本轮没有继续迭代 —— 把这个"零和"结论和完整回归数据如实公开，比发布一个只报喜的权重更有用。

⚠️ 可比性声明（重要）

用法

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Weidows/embeddinggemma-2-zh")   # 271M 文本骨干
model.max_seq_length = 2048   # 建议显式设置（见下）
emb = model.encode(["蚂蚁借呗怎么关闭", "花呗额度怎么提升"], normalize_embeddings=True)

⚠️ 建议显式设置 max_seq_length：该模型的 config 会让 sentence-transformers 解析出一个溢出的 默认值（约 1e30，等于完全不截断）。这与微调无关，原版 google/embeddinggemma-2 同样如此。

注意：本权重是纯文本骨干版（config.json 里 vision_config / audio_config 均为 null）， 不含原版 740M 的图像/音频塔，因此不支持多模态输入。

如果你想改从源码仓库 google/embeddinggemma-2 手动加载配置，而不是用本仓库的 config.json：

# 必须显式关掉编解码器：否则会实例化视觉塔（768 宽），
# 其 Gemma4ClippableLinear 会与 peft 冲突，也会白白加载 1.5GB 权重
SentenceTransformer("google/embeddinggemma-2",
                    config_kwargs={"vision_config": None, "audio_config": None})

实测中发现的集成缺陷（值得上游注意）

用 sentence-transformers 直接 encode() 时，若某条输入"整串就是一个媒体 URL"， 默认路径会把它当作媒体去解码：

网页抓取的中文语料里这类文档很常见（mteb/MMarcoRetrieval 语料第 98275 条就是裸 YouTube 链接）， 一次全量评测会因此崩在语料编码中途。把 sentence-transformers pin 到纯 text modality 可绕开， 且 embedding 数值不变（200 条中文文本上 np.allclose(atol=1e-4) == True）， 吞吐同时提升约 4 倍（92 → 376 docs/s）。

复现

git clone https://github.com/Weidows/embeddinggemma2-zh && cd embeddinggemma2-zh
uv sync
./src/phase2/eval_finetuned.sh          # 微调后权重跑 8 个靶任务（约 29 min）
./src/phase2/eval_finetuned.sh --full   # 全量 31 任务（约 174 min）

本机需要直连 + 本地代理，不能用 HF 镜像（镜像会让 hf download 报 Local entry not found. [SSL: UNEXPECTED_EOF_WHILE_READING]）。

引用 / 数据出处

• 本模型评测：mteb 2.24.0，benchmark MTEB(cmn, v1)，逐任务原始分数在同仓 results/， 本仓库 eval/ 下也放了一份（含微调前后的原始 JSON）
• bge-m3 与 Qwen3-Embedding-0.6B 的对照：前者本机同设置实跑，后者取自 mteb/results 公开条目

局限

• 截断 2048（模型支持 8192）：受显存约束（文本塔的 per_layer_projection_norm 会把 [batch, seq, 24 层, 512 维] 上采样到 fp32）。C-MTEB 语料 p99 ≈ 1.3k token，影响有限， 但医疗长文档任务可能被低估。
• 只评测了文本，图像/音频（MIEB / MAEB）未涉及。
• 对照模型均为 2048 截断，因此与它们在公开榜单（各自默认长度）上的成绩不可直接对比。
• 微调权重仅 1 epoch、无早停、无超参搜索，且如上所述训练长度 192 < 评测长度 2048； 它在靶任务上的提升是真实的，但通用检索上的退化同样是真实的。