标准回答
选 Embedding 模型要先看需求维度，再用自己的数据验证，而不是直接挑榜单第一名。
任务与领域匹配
先明确用途：语义检索、聚类、还是相似度匹配。通用模型在开放域表现好，但医疗、法律、代码等专业领域往往需要领域微调或专门模型，否则术语语义召不回。
语言
确认是中文、英文还是多语场景。中文要选在中文语料上训练充分的模型（如 bge-zh、gte-zh），多语场景选 multilingual 版本，避免用纯英文模型硬跑中文。
向量维度
维度越高通常表达力越强，但存储和检索成本同步上升。高维向量占内存大、检索慢，需在精度与成本之间权衡；部分模型支持可变维度（如 Matryoshka），可按需截断。
最大输入长度
确认模型支持的最大 token 数能否覆盖你的 chunk 大小。长文档场景要么选长上下文 Embedding，要么先合理切分，避免超长被截断丢信息。
非对称检索与指令支持
RAG 中 query 短、doc 长属于非对称检索，选择对 query/doc 区分编码（asymmetric）的模型效果更好。部分模型（如 e5、bge 指令版）支持加 instruction 前缀来适配不同任务，用对前缀能明显提升效果。
部署、成本与隐私
API 方案（如 OpenAI text-embedding）省运维、质量稳定，但有调用成本、延迟和数据出域风险；本地开源（bge/gte/e5）可私有化部署、保护隐私、长期成本低，但要自己承担推理资源和运维。对数据敏感的业务通常倾向本地部署。同时要考虑模型的更新节奏与可得性，避免选用即将停服或不再维护的模型。
评估方法
榜单（MTEB/C-MTEB）只用于初筛候选。真正的选择必须基于自己的数据：构造一批带标注的 query-相关文档对，测 Recall@k、MRR、NDCG 等检索指标，对比候选模型；最后还要把 Embedding 接入完整 RAG 链路做端到端 A/B，看最终回答质量，因为检索指标好不一定等于业务效果好。
常见误区
⚠️ 常见踩坑
只看 MTEB/C-MTEB 榜单分数就拍板选型——榜单数据分布、任务类型可能和你的业务差很远，且存在过拟合榜单的风险；必须用自己领域的标注数据复测，并跑端到端检索 A/B，否则线上召回效果可能远不如预期。
追问
追问 1：没有标注数据时怎么评估 Embedding 模型？
可以低成本构造伪标注：从已有文档反向生成对应的 query（用 LLM 给每段 chunk 造几个可能被问到的问题），把「该 chunk 是这些 query 的正确答案」当作标注，测各模型的 Recall@k 与 MRR。也可以人工抽样几十条真实问题、人工标注相关文档做小规模评测。再辅以线上指标（用户是否重问、是否点了「无帮助」）做持续验证。
追问 2：向量维度太高带来检索成本问题，怎么取舍？
追问 3：对称检索和非对称检索有什么区别，对选型有何影响？
对称检索指 query 和被检索文本是同质的（如句子找相似句子）；非对称检索指两端形态差异大，典型是短 query 检索长 doc（RAG、搜索）。非对称场景应选专为此训练、或对 query 与 doc 用不同前缀/编码方式的模型，否则短 query 与长 doc 的向量分布不匹配，召回会变差。选型前先判断自己属于哪类，再挑对应能力的模型。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习