核心要点
别把 demo 当产品——PoC 验证可行性，生产化才是主要工作量
数据管线与训练/线上特征一致性（避免 train-serving skew）
工程指标：延迟、吞吐、可扩展、高可用、成本
可靠性闭环：监控、告警、回滚、定期重训、离线评测、合规审计
标准回答
PoC 只证明"模型能跑通、效果有希望"，生产化才是 80% 的工作量，核心是工程化与可靠性。
1. 数据与特征
- 把一次性脚本变成稳定的数据管线（调度、重试、数据质量校验）。
- 保证训练特征与线上特征完全一致，避免 train-serving skew。
2. 服务与性能
- 满足延迟/吞吐 SLA，做好水平扩展、限流、降级。
- 评估推理成本，必要时量化/蒸馏/缓存。
3. 可靠性闭环
- 监控：数据漂移、模型衰减、线上业务指标。
- 回滚：灰度发布 + 一键回滚到上一版本。
- 重训：自动化重训与离线评测回归，建立数据飞轮。
4. 上线验证与合规
一句话：PoC 关注"能不能"，生产关注"稳不稳、可不可维护"。
常见误区
⚠️ 常见踩坑
把 PoC demo 直接当产品上线，忽略特征一致性、监控、回滚和重训机制；只在离线数据上验证就上线，没有 A/B 测试和线上监控，结果上线后效果衰减无人知晓。
追问
追问 1：什么是 train-serving skew？如何避免？
指训练时和线上推理时的特征计算逻辑不一致（如不同代码、不同数据源、时间口径不同），导致线上效果远差于离线。避免方法：用统一的特征定义与 Feature Store、共享特征计算代码、对线上线下特征做一致性校验。
追问 2：上线后如何知道模型在"变坏"？
监控三层：输入侧（特征分布漂移）、模型侧（预测分布、置信度变化）、业务侧（核心业务指标）。设置告警阈值；同时定期用新标注数据做离线评测回归，触发重训或回滚。
追问 3：为什么 PoC 效果好，上线却拉胯？
常见原因：离线数据分布与线上不一致、特征一致性问题、PoC 用了未来信息（数据泄漏）、评估集过于干净、延迟约束下不得不用更轻的模型。生产化要逐一排查这些可靠性和工程问题。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。