考察点
面试官想确认你不是只会调 OpenAI API 的默认 embedding，而是真的做过选型对比：知道去哪里看榜单、榜单之外还要验证什么、维度大小对工程成本意味着什么。报得出几个主流模型的名字、维度和特点，说明真的调研过。追问常往微调、量化降维、领域适配方向走。
参考答案
选型看哪几个维度
选型先框定约束：语言（纯中文、中英混合还是多语言）、领域（通用还是法律、医疗、代码）、部署方式（调 API 还是自建）、成本与延迟预算。然后看榜单：英文看 MTEB，中文看 C-MTEB，重点看 Retrieval 子任务的 nDCG@10，而不是总分。但榜单只能用来圈定候选集，最终必须用你自己的业务 query-文档对实测——榜单数据和你的领域分布差得远，榜单第一在你数据上不一定是第一。
主流模型盘点
闭源 API 侧，OpenAI 的 text-embedding-3-large 输出 3072 维，支持在请求时指定降维（比如砍到 1024），精度损失可控；text-embedding-3-small 是 1536 维，便宜量大。开源侧中文场景用得最多的是 BGE 系列：bge-m3 输出 1024 维，支持最长 8192 token 的输入，多语言，而且一个模型同时产出稠密向量、稀疏权重（类 BM25 的词项权重）和多向量（ColBERT 风格）三种表征，做混合检索很方便；bge-large-zh-v1.5 也是 1024 维，纯中文场景性价比不错。其他还有 Jina embeddings、GTE、M3E 等。另外 bge 系列有个使用细节：query 侧要加 instruction 前缀（中文版是「为这个句子生成表示以用于检索相关文章：」），文档侧不加，非对称检索效果才好。
维度对工程意味着什么
维度直接决定存储和计算成本。1024 维 float32 一条向量占 4KB，100 万条就是约 4GB，HNSW 索引通常要求向量常驻内存，这个量级要按内存规划机器。3072 维的 text-embedding-3-large 同规模就是 12GB。降成本的手段：一是降维，bge-m3 和 text-embedding-3 都支持截断维度（Matryoshka 套娃式训练，截断后仍保序），1024 砍到 256 维检索质量损失通常很小；二是量化，float32 转 int8 内存省 75%，很多向量库原生支持。所以「维度多少」这个问题，面试官想听的答案是：先看模型能力，再按数据规模算存储账，必要时用降维和量化压成本，而不是背一个数字。
实测怎么测
构造一批真实的 query，每个 query 人工标出相关文档，算 Recall@10 或 nDCG@10，候选模型横向对比。注意向量入库前要做 normalize，归一化后内积等于余弦相似度，检索用内积就行，很多库默认距离度量在这里容易配错，配错了召回质量会莫名变差。
微调什么时候上
通用模型在垂直领域（专业术语多、行话多）效果差时，用领域内的 query-文档对做对比学习微调，关键是构造难负例——字面上像但语义不相关的负样本，比随机负样本对提升大得多。微调前先用 query 侧 instruction、混合检索这些低成本手段榨干通用模型，微调是最后手段。
可能的追问
- 维度越高越好吗？答：边际收益递减，1024 维往上收益很小但存储线性涨。Matryoshka 训练允许截断降维，实际选型是精度、内存、延迟三方权衡。
- 为什么不直接用 LLM 取 hidden state 当向量？答：生成式 LLM 的表征是为下一个 token 预测优化的，且双向对比弱，检索效果通常不如专门用对比学习训的双塔模型，成本还高一个量级。
- 微调数据从哪来？答：点击日志里的 query-点击文档对是天然正例；没有日志就让 LLM 基于文档生成问题再人工筛。负例用同 batch 内其他样本加难负例挖掘。