更换Embedding模型后检索报错怎么办？向量维度、索引重建与迁移检查指南

先区分：维度报错，还是检索结果变差

知识库更换Embedding供应商后，如果写入或查询提示向量维度不匹配，先检查应用生成的向量与目标集合配置，不要急着修改集合维度。如果没有报错，但相关文档排名明显下降，应进一步检查是否把新模型的查询向量发到了旧模型的文档索引。

维度一致只是能否写入或计算的条件之一，不代表向量语义兼容。不同模型即使输出相同长度，也不能默认放在同一向量空间中比较。

第一步：核对模型、实际输出和集合配置

1. 确认实际调用的模型。检查文档入库任务与在线查询服务的模型标识、服务端点和部署配置，排除只更新了其中一条链路的情况。
2. 测量实际输出维度。用一段固定文本调用当前Embedding服务，查看返回向量的元素数量。若接口支持指定输出维度，还要核对请求参数，不能只凭模型名称推断。
3. 读取目标集合配置。检查向量字段的维度、距离度量，以及应用实际连接的集合或索引名称。使用命名向量时，应确认查询命中了正确的向量字段。
4. 抽查现有数据。结合入库日志和文档元数据，确认旧文档由哪个模型编码，是否存在部分任务已换模型、部分任务仍使用旧配置的情况。

例如，报错发生在查询阶段，应优先比较“查询向量实际长度”和“目标向量字段配置”；发生在批量入库阶段，则应检查新生成向量与写入目标。两条链路要分别验证。

第二步：不要用改维度代替重新编码

修改配置不会让旧向量自动变成新模型的表示。对旧向量补零、截断，或强行沿用旧索引，也不能解决模型空间不兼容的问题。即使向量库支持某些配置调整，也不意味着已经存储的数据完成了模型迁移。

正确做法是用新模型重新编码需要参与检索的全部文档片段，并写入独立的集合、向量字段或索引。迁移期间，新旧模型的数据应隔离，避免一次检索混用两种表示。

第三步：建立可追踪的新索引

1. 确定文档范围、切分规则与文本清洗方式。若本次主要验证模型变化，尽量保持切分规则不变，减少干扰因素。
2. 按新模型实际输出维度创建目标集合，并核对距离度量与归一化要求。
3. 重新编码文档，保存文档标识、片段标识、模型标识及编码配置等必要元数据，便于核对和重跑。
4. 检查写入失败记录、片段数量及重复数据。迁移期间发生的新增、修改和删除，也要按明确规则同步到新索引。

如果只完成了一部分文档的编码，不宜直接把全部查询切到新索引。能正常查询不等于文档已经完整迁移。

第四步：让查询链路与文档链路匹配

新索引必须使用匹配的新模型生成查询向量，并遵循模型要求的输入格式。某些模型对查询和文档采用不同任务参数或前缀，应分别使用正确配置，而不是机械地让两端输入完全相同。

同时核对文本清洗、截断、输出维度和归一化设置。切换配置时，应将“查询模型”和“目标索引”作为一组更新，避免新查询向量仍进入旧索引。

第五步：验证召回，再切换并保留回滚

选取有代表性的真实问题，覆盖术语查询、长问题、相近概念和预期无答案的问题。在相同检索条件下比较新旧索引，检查目标文档是否被召回、前几条结果是否相关，以及延迟和失败率是否可接受。不同模型的相似度分数不宜直接横向比较，旧阈值也需要重新验证。

切换前记录旧模型与旧索引的配套配置，保留可用的旧查询链路。若新方案出现异常，应同时回退查询模型和索引指向，而不是只改其中一个。回滚窗口内，还应明确旧索引如何接收数据更新，防止回退后遗漏新增内容。

换模型不保证检索质量提升。安全迁移的关键，是核对实际维度、隔离不同模型的向量空间、完成文档重编码，并在效果验证后成组切换查询链路。