完整题目
在向量检索任务中，常用的文本嵌入模型有哪些？请对比不同模型的特点和适用场景。
本文目录
答案要点
- 区分通用嵌入模型与专用嵌入模型的差异
- 掌握主流模型的核心特点（如M3E、BGE、GTE、OpenAI等）
- 理解模型选型需考虑的因素（语言支持、向量维度、上下文长度、推理成本）
- 了解领域适配和微调策略
- 能结合实际场景给出选型建议
主流文本嵌入模型分类
1. 开源中文模型（国内首选）
| 模型 | 特点 | 适用场景 |
|---|---|---|
| BGE (智源) | 中文SOTA，多尺寸（large/base/small），支持指令微调 | 通用RAG、需要高性价比的场景 |
| GTE (阿里) | 长文本支持好（8K），中文效果优秀 | 长文档检索、法律文书 |
| M3E (开源社区) | 轻量、易部署，适合资源受限环境 | 边缘部署、快速验证 |
| BCEmbedding (网易) | 双语对齐好，跨语言检索强 | 中英混合场景 |
2. 国际主流模型
- OpenAI text-embedding-3/ada-002：效果稳定，API便捷，成本高
- Cohere Embed：多语言支持好，长文本优化
- E5/MiniLM：英文场景轻量选择
3. 选型核心维度
必考虑因素：
- 语言覆盖：纯中文→BGE/GTE；中英混合→BCEmbedding或微调
- 上下文长度：短文本（512）vs 长文档（8K+）
- 向量维度：768/1024常见，维度越高存储成本越大
- 推理成本：边缘端选小模型（如bge-small），服务端可选大模型
进阶优化：
- 垂直领域建议用领域数据做对比学习微调
- 重排序（Rerank）阶段可用Cross-Encoder提升精度
一句话总结
通用场景选BGE-large，长文本选GTE，成本敏感选M3E，中英混合做微调——没有最好，只有最适合业务约束的。
换一种问法，检查是否真正理解
场景切入
假设你在做一个电商客服的智能问答，用户问“这个订单什么时候发货”，你需要从商品库和订单库里检索相关信息。你会选哪个文本嵌入模型来做向量化？为什么？
层层追问
做RAG的时候你一般用什么模型把文本变成向量？……中文场景和英文场景有区别吗？……那如果文档特别长，比如法律文书，你还会用同一个模型吗？
直球架构
聊一下文本嵌入模型选型。从BGE、GTE、M3E、OpenAI这些里挑，怎么选？要考虑语言支持、上下文长度、向量维度、推理成本这些，你具体怎么权衡？
练习口述回答 · 约4分钟
- 一句话定位：选型本质是平衡语言、成本、上下文
- 边界划分：开源 vs 闭源，通用 vs 领域微调
- 真实场景：电商退款政策检索，BGE+GTE+rerank
- 落地风险：模型更新、维度膨胀、数据漂移
- 工程师判断：倾向混合检索加微调
这道题其实是在问，当你要做向量检索时，怎么在模型能力、成本、业务场景之间做取舍。说白了，没有万能模型，只有最适配你约束的方案。
先说分类。市面上模型可以划成开源和闭源两拨。开源里中文好的有BGE、GTE、M3E，闭源就是OpenAI、Cohere这些。但真正落地时，很少只用一种。比如你的场景是电商客服要检索退款政策，文档有长有短，有纯中文也有中英混杂。我会把BGE-large作为主力，因为它中文语义理解强，性价比高，适合大部分问答。但遇到那种几千字的政策条款，BGE的默认上下文可能不够，我就换成GTE，它支持8K token，能完整编码长文档。这就引出一个关键：不要迷信单一模型，要根据文本长度和语言灵活组合。
再一个，很多人忽略边界。向量检索不是万能的。如果你的query里包含精确订单号或错误码，向量[[embedding]]会丢失精度，这时候需要跟关键词检索结合，比如[[Hybrid Search]]，用[[BM25]]兜底。我见过不少项目上线后召回率低，一查全是向量模型对短代码不敏感。所以前提是，你得先判断数据里有没有结构化片段。
举个例子，一个退货申请页面，用户输入“订单号12345为什么退款失败”，我期望召回两条政策：“退款失败可能原因”和“订单状态异常处理”。如果只用向量，可能只召回语义接近的第一条，漏了第二条。所以我会做两路召回：一路向量检索语义相似文档，一路关键词匹配订单号，然后用[[Rerank]]阶段把结果合并排序。这样命中率明显提升。
落地还有几个坑。第一，模型更新频繁，BGE从1.0到3.0向量分布会变，如果你已经存了几千万向量，重新索引成本极高。我会在选型时预留一个版本兼容层，比如存两份不同维度的向量，或者用[[Product Quantization]]压缩，但精度会有折损。第二，维度越高不一定越好。768维和1024维，检索效果可能只差1%，但存储和计算成本翻倍。我一般会先用小维度模型做快速验证，效果不达标再升维，而不是一上来就上最大号。
另外，很多团队忽略数据漂移。业务政策每季度更新，旧向量对新query可能不匹配。我倾向于定期用线上真实query回测，如果Recall@K掉到阈值以下，就触发增量微调。但微调不是万能药，它需要标注数据，成本不低。
所以我的判断是：没有银弹。我更倾向走混合路线，开源模型做主体，关键词检索做补充，再根据业务反馈迭代微调。面试官如果感兴趣，我可以展开聊聊微调时怎么构造对比学习样本，或者怎么评估向量质量。