MLOps 服务化检索链路失真时从哪里开始查向量检索、重排和模型生成连成一条链后用户看到的“答案变差”未必来自模型本身。可能是索引版本切换、过滤条件遗漏、候选集过小也可能是重排输入被截断。本文整理服务化阶段应保留的检查点案例仅为排查思路不代表任何已验证的线上结果。先标识一次请求用了什么每个检索请求至少应能关联到查询规范化版本、embedding 模型与维度、索引或 collection 版本、过滤条件、召回条数、重排模型版本以及最终传给生成模型的文档 ID。没有这些字段时评审人只能凭主观感受讨论“效果退化”无法区分是数据变化还是代码变化。日志无需保存全部用户原文。对敏感场景可以记录加盐哈希、语言类型、长度区间和命中的文档标识确需保留原请求时应单独遵循数据权限和保留期限。诊断信息应与用户可见答案分开避免把内部文档片段误回传。给 token 预算一个明确的分配规则重排之前先限定候选集数量重排之后再按文档长度、相关性和来源多样性挑选上下文。所谓“超出 token 限制”不应靠服务端静默截断解决截断位置、被舍弃的文档及原因应可观察。若关键文档被截掉结果看似正常却很难复现。实践中可把上下文装配写成纯函数输入为候选文档、预算和策略版本输出为入选 ID、各文档占用量与舍弃原因。这样可以用固定夹具测试边界例如长文档是否挤掉多个短但高相关的条目或过滤后的候选集为空时是否返回明确状态。部署和回滚索引、embedding 模型和重排模型最好独立版本化。发布新版本前用一组脱敏评测查询检查召回、过滤与上下文拼装是否符合预期不要把未标注来源的“命中率提升”写成结论。发布后若出现异常应能将流量切回旧索引或旧策略并记录切换发生的时间和范围。还要注意异步建索引的完成状态。索引任务未完成就切别名会得到部分数据可检索的结果。切换条件应包含文档数量核对、抽样查询和失败任务清单而不仅仅是任务进程退出。结语MLOps 的重点不是把模型放进容器而是让每次回答都能追溯到数据、策略与版本。先把链路中的身份信息和 token 决策记录下来效果问题才有可讨论、可回滚的依据。当检索质量出现波动不要马上同时更新 embedding、索引和提示词。一次只变更一个可定位要素并保留前后请求清单才能判断差异来自召回还是生成阶段。评测集也要定期检查是否过度贴合历史问题否则离线结果会掩盖新数据上的缺口。容量规划同样应以实际记录为准。观察排队时间、索引任务耗时和失败类别再为不同租户或任务类型设置配额不要把某次测试中的数字直接写成固定阈值。排查记录最好附上索引变更、过滤规则变更和数据导入的时间线。它能避免团队在模型版本上反复猜测却忽略了数据源已经发生改变。索引统计与抽样结果也应一并留存。