面试题 · 模型微调
搜索「RAG 架构」匹配到追问内容，相关段落已展开。查看匹配内容 ↓
在向量检索任务中，常用的文本嵌入模型有哪些？请对比不同模型的特点和适用场景。
| 模型 | 特点 | 适用场景 |
|---|---|---|
| BGE (智源) | 中文SOTA，多尺寸（large/base/small），支持指令微调 |
按学习路线查看教程、项目和面试题。
| 通用RAG、需要高性价比的场景 |
| GTE (阿里) | 长文本支持好（8K），中文效果优秀 | 长文档检索、法律文书 |
| M3E (开源社区) | 轻量、易部署，适合资源受限环境 | 边缘部署、快速验证 |
| BCEmbedding (网易) | 双语对齐好，跨语言检索强 | 中英混合场景 |
必考虑因素：
进阶优化：
通用场景选BGE-large，长文本选GTE，成本敏感选M3E，中英混合做微调——没有最好，只有最适合业务约束的。
场景切入
假设你在做一个电商客服的智能问答，用户问“这个订单什么时候发货”，你需要从商品库和订单库里检索相关信息。你会选哪个文本嵌入模型来做向量化？为什么？
层层追问
做RAG的时候你一般用什么模型把文本变成向量？……中文场景和英文场景有区别吗？……那如果文档特别长，比如法律文书，你还会用同一个模型吗？
直球架构
聊一下文本嵌入模型选型。从BGE、GTE、M3E、OpenAI这些里挑，怎么选？要考虑语言支持、上下文长度、向量维度、推理成本这些，你具体怎么权衡？
这道题其实是在问，当你要做向量检索时，怎么在模型能力、成本、业务场景之间做取舍。说白了，没有万能模型，只有最适配你约束的方案。
先说分类。市面上模型可以划成开源和闭源两拨。开源里中文好的有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掉到阈值以下，就触发增量微调。但微调不是万能药，它需要标注数据，成本不低。
所以我的判断是：没有银弹。我更倾向走混合路线，开源模型做主体，关键词检索做补充，再根据业务反馈迭代微调。面试官如果感兴趣，我可以展开聊聊微调时怎么构造对比学习样本，或者怎么评估向量质量。