Embedding 模型中转：RAG 项目最容易踩的四个坑

先说 Embedding 的特殊性

Embedding 和「对话」有一个本质区别：它的输出不是给人看的，是存起来做数学运算的。

这带来一个后果：embedding 的问题不会在调用时报错，只会在检索质量下降时体现。 而检索质量下降又很容易被归因为「检索策略不好」，很难回溯到 embedding 层。

所以下面四个坑，都属于「上线后才暴露」的类型。

坑一：向量空间不可混用 ★最严重

两家供应商的 embedding 向量不可比，即使模型同名（都叫 text-embedding-3-small）、维度相同。

原因：向量空间由具体实现决定。不同供应商即使用的是同一个开源模型，也可能因为：

• 权重版本不同（v1.5 与 m1.5 的向量空间不同）；
• 分词器版本不同；
• 量化方式不同（fp16 / int8 会产生不同的向量）；
• 归一化处理不同。

症状：混合使用两家的向量入库后，检索结果可能完全随机 —— 相似的文档不再相似，查询命中的是无关内容。

最隐蔽的一点：它不报错，也不一定表现为「召回率下降」，有时反而表现为「召回了一堆看起来也相关的文档」—— 因为随机向量在某些情况下也能撞上一些语义相近的结果，看起来像「效果一般」而不是「坏了」。

预防：一个索引（collection）只用一个供应商的 embedding。如果要换，必须全量重建索引。

坑二：维度变更导致索引失效

不同模型的输出维度不同（常见的 768 / 1024 / 1536 / 3072）。多数向量库的 collection 在创建时就固定了维度。

症状：换模型后写入失败（报维度不匹配），或者更糟 —— 有些客户端库会自动截断/补齐，导致向量被静默损坏。

预防：

1. 在 collection 的元数据里记录降维与模型名，不要只记在代码里；
2. 换模型时新建 collection 而不是原地覆盖，旧索引保留到新索引验证完成为止；
3. 注意有些模型支持维度参数（如 dimensions: 512），但这属于「同一模型的不同投影」，与「换模型」不是一回事 —— 调整维度同样需要重建。

坑三：批量接口的返回顺序

Embedding 的批量接口通常接受一个字符串数组。不要假设返回顺序与输入顺序一致。

多数实现确实保持顺序，但：

• 部分中转站的实现会做分片并发，返回顺序可能与输入顺序不同；
• 有极少数实现会去重（相同的输入返回一次），导致 length 不匹配。

症状：向量与文档错位。这个 bug 极其难发现 —— 检索会返回「相关但不对应」的文档，看起来像排序问题。

预防：

1. 每条记录写入时用唯一 ID 关联，而不是靠数组下标；
2. 校验返回数组的 len() 与输入是否一致，不一致就报错而不是继续；
3. 写入后用「拿自己的原文去检索自己」做一次自检，位置正确率应为 100%。

第 3 项是一个非常好用的自检：用自己的文本查自己，排第一的必须是它自己。如果出现错位，这个测试立刻能发现。

坑四：Embedding 走的是另一套渠道

这是中转站特有的坑。一家站可能在 chat 模型上有很好的渠道，但 embedding 走的是完全不同的来源（更便宜的、或逆向的）。

判断方法：

1. 单独看 embedding 的价格。如果远低于官方价，而 chat 部分价格正常，说明它来自不同渠道；
2. 测一致性：同一段文本今天和一周后各测一次，比对向量。如果差异显著（余弦相似度明显低于 0.999），说明后端在变；
3. 测语义排序质量：准备一组有明显语义关系的句子对（近义、反义、无关各若干），看排序是否符合预期。

为什么要测一致性：如果站方在不同时间把请求路由到不同后端，你的索引里会混入多个向量空间的向量 —— 效果等同于坑一，但更难发现。

一份上线前检查清单

□ 单一供应商：一个 collection 只用一个来源的 embedding
□ 维度记录：collection 元数据里写清模型名与维度
□ ID 关联：向量与文档用 ID 关联，不靠数组下标
□ 长度校验：返回数组长度与输入不一致时直接报错
□ 自检：用原文检索自己，命中率应为 100%
□ 一致性：间隔一周复测同一文本，比对向量差异
□ 重建预案：换供应商时能全量重建（这一步必须有脚本）

最后一项最容易被忽略，但它是唯一能兜住前六个坑的保险。如果你的索引无法快速重建，你就无法安全地更换 embedding 供应商 —— 这等于把自己锁死了。

成本提示

Embedding 的单位成本极低（比 chat 低两到三个数量级），所以在这项上省钱的意义不大；但重建索引的成本不低（要重新切分、重新请求、重新写入）。

所以务实的策略是：在 embedding 上优先选稳定而不是便宜。省下的那点钱远不抵一次索引重建的工时。