面试题 · 模型微调
在RAG系统中，选择文本向量编码模型时需要考虑哪些技术指标和性能因素？
1. 语义质量指标
2. 工程性能指标
3. 系统兼容性
4. 实际验证方法
学习内容与项目面试，在同一条路上。
选型建议：先MTEB初筛，再用业务数据精评，最后做成本-精度trade-off决策。
场景切入
假设你在做一个电商客服RAG，用户问‘退货运费谁出’，系统要检索相关规则。你会怎么选文本编码模型？比如考虑领域术语和长描述怎么处理？
层层追问
RAG里文本编码模型怎么选？……除了精度，工程上还要看哪些指标？……如果业务有大量长文档，向量维度和存储成本怎么权衡？
直球架构
请列出在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初筛，再用业务数据精测，然后根据场景选维度和模型大小，最后用混合检索兜底。不追求单个模型最强，而是追求系统整体最稳。