RAG 向量模型怎么选?

这道题我觉得本质上是在问一个成本和效果的平衡问题。选文本向量模型不是选个最好的，而是要在精度、速度、存储、场景之间做取舍。

先说语义质量。我一般会先看MTEB榜单，它覆盖了检索、[[重排]]、聚类这些任务，能给个全局印象。但说实话，榜单排名高不代表在你的业务上就灵。真正有用的方法是拿自己的业务数据测一遍。比如做客服退款场景，用户说“我买的东西坏了”，和“商品有瑕疵”语义很接近但字面完全不同，模型能不能把这两个query映射到相近的向量空间？我会用业务上真实的query-doc对去算Recall@K和MRR，看bad case。如果发现很多同义词匹配不上，那这个模型就不合适。

再一个，上下文长度。很多模型只支持512 token，如果文档很长，比如企业SOP，就需要截断或者分层切。我倾向用能支持8k的模型，或者干脆用[[Parent Document]]策略，把长文档拆成小块分别embed，检索时先找到小块再关联回整篇。

说完质量，说工程性能。这里有个直接的权衡：向量维度。768维和1024维，精度可能就差零点几个点，但存储和计算成本能差百分之二三十。我一般会优先选768维，除非业务对精度极其敏感，比如风控合同检索。推理速度也很关键，尤其是实时索引构建的场景。小模型比如MiniLM，22MB，QPS能跑很高，适合边缘部署；大模型比如GTE-large，335MB，精度高但慢。我的原则是：能用小模型解决的问题，绝不上大模型。

多语言支持要看场景。如果是纯中文业务，用m3e或者BGE的中文版就够了，没必要上支持100种语言的模型，那会牺牲单语言精度。但如果业务涉及跨境订单或者多语种客服，那就得选BGE-m3这种多语言模型，还得注意跨语言的检索能力，比如用户用中文查，英文文档能不能召回。

最后说落地。真正上线时，我很少只用向量检索。更常见的做法是[[Hybrid Search]]，把向量和[[BM25]]结合起来。因为向量模型对字面匹配、专有名词比如订单号、错误码这些，效果很差，但BM25很擅长。所以我会同时建向量索引和倒排索引，检索时把两路结果融合，再用Rerank模型排序。这个方案能覆盖更多case，但代价是多维护一套索引和增加延迟。

还有一个点值得注意：模型微调。很多开源模型比如BGE、E5都支持微调，但微调需要高质量的query-doc对，而且容易过拟合。我一般只在领域差距特别大，比如医疗、法律，才考虑微调，否则用通用模型加好的检索策略就够了。

所以总结一下，我的选型思路是：先拿MTEB初筛，再用业务数据精测，然后根据场景选维度和模型大小，最后用混合检索兜底。不追求单个模型最强，而是追求系统整体最稳。