MLOps 工程师

按「服务对象—能力版图—技术选型—量化效果」组织：服务多少算法团队、覆盖哪些环节（数据、训练、评估、部署、监控）、核心选型（自研还是 Kubeflow/MLflow 拼装、调度用 K8s Operator 还是 Argo）、关键指标（训练任务排队时长、部署周期从 X 天到 Y 小时、GPU 利用率提升）。MLOps 本质是平台工程，讲清楚「用户是谁、痛点是什么、平台怎么解决了它」比堆砌组件名重要。

监控两层：数据漂移（特征分布 PSI/KL 散度对比训练基线）与概念漂移（延迟到达的真实标签与预测的差异）。发现后处理路径：临时降级到备用模型或规则，然后重训练（自动触发或人工确认）、灰度验证、再上线。长期机制是建立「监控-告警-再训练-评估-发布」的闭环流水线。加分点：谈标签延迟场景（如信贷逾期要几个月后才有标签）下用代理指标监控，以及再训练不能无脑自动化、必须有评估门禁。

先测量后优化：看 GPU 真实利用率（nvidia-smi/DCGM）区分是排队等待、数据供给不足还是计算间歇。常见抓手：数据管道（预取、缓存、并行 loader，别让 GPU 等数据）；训练侧混合精度、梯度累积、编译优化；调度侧任务排队与抢占策略、碎 fragment 整理（bin-packing）；平台侧弹性伸缩与潮汐任务（离线训完即还）。组织侧推动资源配额与优先级规范。回答结构化展示「从指标出发定位瓶颈」的工程方法论。

STAR 讲故障处理最出彩：现象（如推理 P99 突增）、定位过程（监控下钻→发现某特征在线预处理有慢查询→特征服务超时拖垮整体）、止损（降级特征、扩容、回滚）、根因（特征线上线下一致性没保障/容量规划缺失）、长期改进（加特征服务缓存与熔断、建立容量压测机制）。展示冷静的排查顺序与闭环意识。若没经历过大故障，讲一次测试环境的演练或压测发现的问题也可。

根因通常是在线和离线用两套代码算同一特征。方案按成本递进：代码层面统一特征计算库（同一段逻辑离线批算/在线点算）；架构层面走特征平台（Feast 类），离线训练与在线推理都从同一存储取特征，只算一次；兜底层面做线上线下特征分布监控对账，偏差告警。再加数据源变更的测试（新字段、单位变化）。这个问题非常高频，答出「统一特征定义与服务」的思路是核心得分点。