面试题 · 模型微调
在构建文本向量编码系统时，你会考虑哪些因素来选择embedding模型？不同模型在效果和性能上有何差异？
1. 业务场景匹配
2. 关键性能指标
| 因素 | 权衡要点 |
|---|---|
| 维度 | 768/1024维效果好，但存储和检索成本高；384维适合大规模 |
| 上下文长度 | 512 vs 8192，长文档需截断或层次编码 |
| 多语言 |
按学习路线查看教程、项目和面试题。
| mBERT、LaBSE做多语言；单语言场景用专用模型效果更好 |
| 推理速度 | 小模型（MiniLM）vs 大模型（GTE-large）的精度-延迟 trade-off |
3. 主流模型对比
4. 领域适配
5. 效果评估
场景切入
假设你们要做个电商客服的语义检索系统，用户问“退货流程”得召回相关FAQ。你现在要选一个embedding模型，你会怎么考虑？比如BERT和Sentence-BERT你选哪个？
层层追问
你们做文本向量化的时候，embedding模型怎么选的？……那如果场景是中文、还要支持长文档呢，模型选型上有什么不同？……再比如业务对延迟要求很高，但精度也不能太差，你怎么权衡？
直球架构
请直接讲构建文本向量编码系统时，选embedding模型要考虑哪些维度？不同模型比如BGE、M3E、OpenAI embedding在效果和性能上具体怎么比？
这道题其实问的是，在真实业务里怎么平衡效果、成本和工程复杂度。我先给个框架：选型完全取决于场景，不同场景对向量质量的要求差别很大。
先说场景。如果是做语义检索，比如[[RAG]]里的召回，那肯定优先选专门优化过句子相似度的模型，像BGE、M3E这种，它们用对比学习训练出来的向量，余弦相似度能很好反映语义相关性。但如果你只是做文本分类或聚类，通用BERT就够用了，甚至可以用更轻量的模型，没必要上大模型。
具体说一下核心参数。维度是个典型trade-off：768维或者1024维效果确实好，但存储和检索成本会翻倍；如果向量规模上亿，384维反而更实用，配合[[Product Quantization]]能压到很低的存储。上下文长度也有坑：很多模型最长512 token，长文档要么截断，要么做层次编码，否则信息会丢。多语言方面，如果业务只涉及中文，用专门的中文模型比如BGE或者M3E，效果远好于mBERT这种通用多语言模型。
举个例子，在电商客服场景里，我们做退款政策的语义检索。用户说“商品坏了要退”，我们需要召回对应的政策条款。这个场景的难点在于：用户表达很口语化，而政策文本很正式。如果用通用BERT，向量可能把“坏了”和“损坏”映射到不同区域，但用M3E或者BGE这种对比学习过的模型，就能把这两个语义拉近。
这里有个坑：通用模型在垂直领域往往不够准。比如医疗、法律这种术语密集的场景，直接用开源的[[embedding]]模型，召回率会明显下降。所以落地的时候，我一般会先在业务数据上评估Recall@K，如果不够，就做领域微调，用领域语料做对比学习，加上In-batch negatives和InfoNCE损失。
性能评估也不能只看MTEB榜单，那个太通用。我会构建业务测试集，比如用真实用户query和人工标注的相关文档，算MRR和Recall@K。上线前还会做AB测试，看端到端效果有没有提升。
还有一个容易被忽略的点：embedding模型和[[Rerank]]模型怎么配合。很多人以为embedding效果好就万事大吉，其实embedding做初筛，[[Cross-Encoder]]做精排，两者结合才能达到生产级精度。这个配合的阈值怎么设、延迟怎么优化，是另一个值得深挖的问题。
所以我的选型逻辑是：先定场景，再卡资源，然后选一个基线模型快速试错，最后用业务指标验证。如果效果不够，优先考虑领域微调而不是换更大的模型。