MLOps 服务化：检索链路失真时从哪里开始查

MLOps 服务化：检索链路失真时从哪里开始查

向量检索、重排和模型生成连成一条链后，用户看到的“答案变差”未必来自模型本身。可能是索引版本切换、过滤条件遗漏、候选集过小，也可能是重排输入被截断。本文整理服务化阶段应保留的检查点，案例仅为排查思路，不代表任何已验证的线上结果。

先标识一次请求用了什么

每个检索请求至少应能关联到：查询规范化版本、embedding 模型与维度、索引或 collection 版本、过滤条件、召回条数、重排模型版本，以及最终传给生成模型的文档 ID。没有这些字段时，评审人只能凭主观感受讨论“效果退化”，无法区分是数据变化还是代码变化。

日志无需保存全部用户原文。对敏感场景可以记录加盐哈希、语言类型、长度区间和命中的文档标识；确需保留原请求时，应单独遵循数据权限和保留期限。诊断信息应与用户可见答案分开，避免把内部文档片段误回传。

给 token 预算一个明确的分配规则

重排之前先限定候选集数量，重排之后再按文档长度、相关性和来源多样性挑选上下文。所谓“超出 token 限制”不应靠服务端静默截断解决：截断位置、被舍弃的文档及原因应可观察。若关键文档被截掉，结果看似正常却很难复现。

实践中可把上下文装配写成纯函数，输入为候选文档、预算和策略版本，输出为入选 ID、各文档占用量与舍弃原因。这样可以用固定夹具测试边界，例如长文档是否挤掉多个短但高相关的条目，或过滤后的候选集为空时是否返回明确状态。

部署和回滚

索引、embedding 模型和重排模型最好独立版本化。发布新版本前，用一组脱敏评测查询检查召回、过滤与上下文拼装是否符合预期；不要把未标注来源的“命中率提升”写成结论。发布后若出现异常，应能将流量切回旧索引或旧策略，并记录切换发生的时间和范围。

还要注意异步建索引的完成状态。索引任务未完成就切别名，会得到部分数据可检索的结果。切换条件应包含文档数量核对、抽样查询和失败任务清单，而不仅仅是任务进程退出。

结语

MLOps 的重点不是把模型放进容器，而是让每次回答都能追溯到数据、策略与版本。先把链路中的身份信息和 token 决策记录下来，效果问题才有可讨论、可回滚的依据。

当检索质量出现波动，不要马上同时更新 embedding、索引和提示词。一次只变更一个可定位要素，并保留前后请求清单，才能判断差异来自召回还是生成阶段。评测集也要定期检查是否过度贴合历史问题；否则离线结果会掩盖新数据上的缺口。

容量规划同样应以实际记录为准。观察排队时间、索引任务耗时和失败类别，再为不同租户或任务类型设置配额；不要把某次测试中的数字直接写成固定阈值。

排查记录最好附上索引变更、过滤规则变更和数据导入的时间线。它能避免团队在模型版本上反复猜测，却忽略了数据源已经发生改变。

索引统计与抽样结果也应一并留存。