Embedding 模型选型：维度、语言与检索质量的取舍

榜单选型为什么翻车

RAG（检索增强生成）系统的检索质量，很大程度取决于 embedding 模型——把文本映射成向量的模型，语义相近的文本在向量空间里距离也近。很多人的选型流程是打开公开评测榜单，挑总分最高的一个上生产，结果线上效果远不如预期。原因不复杂：榜单用通用语料测，你的数据不是通用语料。你的查询带着行业黑话，你的文档有自己的格式与术语习惯，通用分数迁移到你的场景必然打折；何况公开榜单还存在被训练数据「见过」的污染风险，榜首之间的零点几分差距未必有统计意义。选型没有捷径，但有一条可复制的路径。

第一分水岭：语言与领域

语言。 中文场景优先考虑中文词表与中文语料训练充分的模型。多语言模型并非处理不了中文，但分词方式、成语与专有名词处理上的差异，会体现为相似度判断的系统性偏差，量级上足以扰动检索排序。

领域。 法律、医疗、代码这类专业领域，通用模型对术语相似度的判断可能失灵：「违约金」与「定金」在通用语义空间里距离很近，在法律语义里却是天差地别的两个概念。领域越专，越要警惕通用模型失灵，也越值得考虑领域模型或微调。

维度不是越大越好

向量维度直接决定存储与计算成本：维度翻倍，索引内存与查询延迟大体同步上涨。这笔账不难算——10 万条文档、768 维、每个分量 4 字节，向量本体大致 0.3GB，换成 1536 维就翻倍，还没算索引结构本身的额外开销。高维理论表达力更强，但在小规模数据上反而可能把无关细节编进向量，泛化变差。近年流行的 Matryoshka（套娃）表示学习给出一条折中路：训练时让向量的前缀保持可用，一个高维模型可以截断出多档低维表示，先按低维上线控制成本，质量不够再升档，存储与质量之间就有了弹性。

评测怎么做才可信

用自己的真实查询-文档对构造评测集，几十到几百条即可，关键在「真实」二字。构造时除了正例，还要放入「容易混淆的负例」——同领域但答案不同的文档，只测「海里捞针」分不出模型高下。指标两个就够：recall@k（前 k 条检索结果命中相关文档的比例，衡量找没找到）与 MRR（平均倒数排名，衡量正确答案排得多靠前）。对比候选模型时，务必用同一评测集、同一套切块策略——切块一变，模型排序就可能翻转，embedding 与切块必须联调，这正是本站 RAG 评测一文强调的原则。

def recall_at_k(retrieved: list[str], relevant: set[str], k: int) -> float:
    hits = len(set(retrieved[:k]) & relevant)
    return hits / len(relevant)

工程参数对照

检索质量之外，还有几个工程参数决定模型能不能舒服地跑在生产里。选型时把这张表和评测结果放在一起看，避免「质量合格、工程不可用」的尴尬：

参数	影响	选型动作
维度	存储与延迟成本	结合文档量估算，别盲目上高维
最大输入长度	长文档切块适配	切块长度必须小于它
推理速度	建库与在线查询耗时	百万级文档重建索引时是硬约束
许可协议	商用边界	逐条核对商用条款

微调选项

如果评测发现通用模型在你的领域集体失灵，对比学习微调是下一步：用领域内的正负样本对（问题与对应、不对应的文档）继续训练，几十到几千对数据就能带来可观提升。训练数据还有一条低成本来源：线上真实的「用户点击了哪条结果」回流下来就是天然的样本，让模型随业务越用越准。微调的成本与收益怎么算，本站微调一文有系统讨论。

决策流程

收集 50 条真实用户问题，人工标注或用强模型辅助标注相关文档，构造评测集。
候选模型在相同切块策略下跑 recall@k 与 MRR，得出短名单。
前两名上生产灰度，用真实点击与引用数据验证评测结论。
把 embedding 放回系统里看：它与切块策略、重排序共同决定检索质量，联调优于单点优化。
评测集是活的资产：随业务演进定期补充新问题、淘汰过时样本，让它跟得上数据分布的变化。