适用检索应用团队

为检索应用建立清晰的向量模型边界

RAG 应用必须让文档向量、查询向量、检索索引与回答模型保持明确关系。KeepRouter 可提供目录中已公布的向量与生成路由，但索引、相关性测试、引用依据，以及更换向量模型后的重新生成工作仍由应用负责。 [1] [3] [4]

最后复核 2026-09-28 · 编辑复核: KeepRouter Editorial

先定义检索契约

不要把向量模型当成配置里可以随意替换的字符串。文档与查询向量必须采用相容的模型、输入预处理、维度和距离度量。新的回答模型通常可先在旧检索结果上测试；更换向量模型则通常需要新的向量空间和重新生成向量。Qdrant 的迁移指南说明了双集合或命名向量的做法。KeepRouter 不提供向量数据库，也不替应用判断检索相关性。

两条路由的架构

阶段	应记录什么	责任方
入库	文档 ID、来源版本、分块规则、向量模型 ID、维度	应用的入库服务
查询	查询向量模型 ID、索引版本、过滤条件、top-k 与延迟	应用的检索服务
回答	被引用段落 ID、生成模型 ID、token 用量与费用	应用与网关记录
复核	有依据的回答、无依据的回答、漏检、权限过滤失败	应用评测集

当前可用模型 ID 和端点以实时目录为准。API 契约区分普通文字向量接口与独立的多模态向量接口，但不代表目录当前同时提供两种模型。接收文字、图像和视频的模型可能使用 /v1/embeddings/multimodal，而不是 /v1/embeddings。发送生产媒体前，应核对准确的模型页和 OpenAPI 契约。多模态向量指南解释输入边界，并不代表任意两种模型共用一个向量空间。

不让换模型悄悄损坏检索

旧索引继续提供服务，同时从同一份源文档回填新索引。回填期间双写新增和变更，核对文档数量与删除状态，再用固定查询集对比两个索引。记录必需段落的召回、权限过滤失败、答案依据、p95 检索延迟，以及向量与生成两段费用。指标过关后只切一小部分流量，保留旧索引与模型 ID 供回滚。重新建索引清单提供完整顺序。

在正确层级控制权限和费用

把 API Key 留在服务端。向量入库任务使用模型白名单与消费上限，回答生成使用另一把 Key。KeepRouter 的请求记录可显示路由、模型、状态、用量和扣费，却无法判断是否检索到了正确段落。应用应通过自己的文档、查询和结果 ID 关联两层记录，不要把私有文档正文塞进网关元数据。记录边界见用量与可观测指南。

如果实时目录不包含所需的向量模型或能力，就为该阶段保留供应商直连。拆分架构比宣称不存在的网关兼容能力更可靠。

常见问题

只换向量模型 ID 而不重建索引可以吗？

通常不可以。应由源文档建立并评估新的向量空间，保留旧索引用于回滚。

KeepRouter 托管向量数据库吗？

不托管。它提供目录中的模型路由；存储、索引、权限过滤和检索评测由应用负责。

多模态向量接口等于 /v1/embeddings 吗？

不等于。应使用所选模型页列出的准确端点；部分多模态模型使用 /v1/embeddings/multimodal。

怎样证明 RAG 迁移成功？

用固定查询集核对段落召回、权限过滤、答案依据、延迟和费用，再逐步放量。

参考的一手资料

来源复核日期 2026-09-28