大模型应用里，向量检索常被说成“把文档转成 embedding 再搜”。这句话只描述了入口，没有描述上线后的麻烦。真实项目里，经常出现一个现象：模型没换，代码也没大改，但知识库更新后回答反而变差；或者 embedding 模型升级后，历史文档和新文档混在一起，检索结果开始漂。
向量检索不是一次性离线处理，而是一套有版本、有索引、有评测、有回滚的后端系统。面试里能不能讲清这些边界，会直接影响别人对你 AI 工程经验的判断。
embedding 版本不能混着用
不同 embedding 模型生成的向量空间不一定兼容。即使维度相同，语义分布也可能不同。把旧模型生成的向量和新模型生成的向量放进同一个索引里比较相似度，结果可能变得不可解释。
所以向量表里至少要记录 embedding 模型版本、切分策略版本和索引版本。模型升级时，不是只改一行配置，而是要考虑历史文档是否重算、双索引灰度、查询侧如何选择版本、效果不稳定时如何回滚。
切分策略会改变答案来源
RAG 里很多坏例不是模型不会答，而是检索到的片段不对。切分太短，上下文断裂；切分太长，向量表达被多个主题稀释；重叠太少，关键句落在边界外；重叠太多，又会制造重复召回和成本浪费。
切分策略一变，召回集合就会变。即使 embedding 模型不变，线上效果也可能明显变化。因此切分规则也应该版本化，并配合固定评测集观察：关键问题是否还能召回正确文档，噪声文档是否变多，权限过滤后是否还剩足够证据。
近似索引有召回和延迟取舍
很多向量数据库或检索库使用近似最近邻算法来提高速度。近似意味着它通常不会穷举比较所有向量，而是在速度和召回率之间做权衡。参数调得激进，查询更快，但可能漏掉更相关的文档；参数保守，质量更稳，但延迟和资源占用会上升。
这也是为什么不能只看“接口能返回结果”。需要准备一批真实问题，记录期望命中文档，比较不同参数、不同索引版本下的召回情况和耗时。没有评测集，向量检索调参就会变成凭感觉。
权限过滤要参与检索设计
企业知识库里，权限过滤不是生成答案后的修饰。用户无权访问的文档不应该进入候选集合。否则模型可能先读到敏感片段，再试图在回答阶段隐藏，这个设计本身就不可靠。
权限过滤会影响召回数量和排序。如果先做向量召回再过滤，可能过滤完只剩很少内容；如果先按权限缩小集合再检索，索引结构和性能又要重新考虑。这个取舍必须在架构阶段设计，而不是上线后补一个 if。
回滚要包括数据和索引
向量检索的回滚不只是回滚应用代码。embedding 版本、向量数据、索引文件、切分结果、元数据过滤规则都可能需要一起回退。比较稳妥的做法是保留旧版本索引一段时间，新版本先灰度到部分问题或部分用户，确认评测和线上反馈稳定后再切全量。
面试里可以这样总结：向量检索工程化的难点不是把文本变成向量，而是让向量、切分、索引、权限和评测都可版本化、可观测、可回滚。这样讲，才像真正做过大模型应用后端。