1. 课程导入与全景认知

很多团队在 Databricks 上做 AI 项目时，都会经历相似的落差：Notebook 里模型指标很漂亮，Demo 演示也顺利，但一旦要交给业务方每天使用，问题就集中爆发——特征口径对不上、模型版本找不到、推理延迟不稳定、权限与合规说不清、上线后没人知道该看哪个指标。这说明“能跑通”与“能交付”之间，隔着一整套工程化能力。本课程讨论的正是这段距离：如何把 Databricks 上的 AI 原型，转化为可上线、可运维、可审计、可持续迭代的产品。

什么是 AI 项目产品化与工程交付

产品化指把一次性的实验成果，转化为具有明确用户、明确输入输出、明确服务等级和明确责任边界的可用产品。它回答的是“谁在什么场景下用它、它承诺达到什么效果、失败时怎么办”。工程交付指支撑这一产品的技术体系与协作过程，包括数据管道、特征管理、模型训练与注册、部署、监控、回滚、权限治理和成本控制。二者合起来，就是让 AI 从“项目”变成“资产”。

在 Databricks 语境下，这件事有独特的技术底座：Unity Catalog 统一治理数据与模型、Delta Lake 提供可靠的表存储、MLflow 负责实验追踪与模型注册、Workflows 编排任务、Model Serving 提供在线推理端点、Lakehouse Monitoring 观察数据与模型漂移。产品化与工程交付，本质上是把这些能力组织成一条从数据到服务的稳定链路。

核心挑战：为什么 AI 交付比普通软件更难

第一是数据与代码的双重版本。普通软件只需管理代码版本，而 AI 系统的行为同时取决于代码、训练数据、特征逻辑和超参数。若只记录模型文件而不记录训练数据快照，问题几乎无法复现。第二是离线与在线的一致性。训练时用批处理算出的特征，与线上实时请求时算出的特征，如果口径不同，就会出现训练-服务偏差，模型指标再好也会在线上失效。第三是效果会随时间衰减。数据分布漂移、用户行为变化、上游表结构变更，都会让模型悄悄变差，而系统本身不会报错。第四是治理与合规。谁能访问哪些数据、模型是否使用了敏感字段、推理结果是否可追溯，这些在受监管行业是硬性要求。第五是成本与性能的平衡。GPU 集群、常驻推理端点、大规模特征回填都会产生真实费用，交付方案必须对成本负责。

生命周期阶段与角色协作

一个完整的 Databricks AI 交付生命周期通常包含六个阶段：需求与场景界定、数据准备与特征工程、实验与模型开发、模型注册与评估、部署与服务化、监控与迭代。每个阶段都有明确的产出物和准出条件，而不是“做完就往下走”。

参与角色也远比“数据科学家一个人干完”复杂：业务方定义场景与验收标准；数据工程师建设与维护数据管道；数据科学家做实验与建模；ML 工程师负责把模型工程化并部署；平台/治理人员管理 Unity Catalog 权限、计算资源与合规；运维与 SRE 关注端点可用性与告警。协作模式上，最关键的是把“交接”变成“共同定义接口”：数据科学家交付的不只是模型，还包括特征定义、评估口径和已知局限；ML 工程师交付的不只是端点，还包括监控指标和回滚方案。

本课程的学习路径与实战项目

课程按“认知—建设—交付—运维”的主线推进。前段建立全景与术语共识，明确产品化与工程交付的边界；中段深入 Databricks 的关键工程环节：用 Delta Lake 与 Unity Catalog 组织可信数据、用特征工程保证线上线下一致、用 MLflow 管理实验与模型注册、用 Workflows 与 Model Serving 完成部署；后段聚焦监控、漂移检测、成本优化、权限治理与 CI/CD，最终形成可复制的交付方法。

贯穿全程的实战项目是一个客户流失预测服务。场景设定为：某订阅制业务希望每天识别高流失风险客户，供运营团队在后台查看并触发挽留动作。示例验收标准可设为：离线评估 AUC 不低于 0.80；在线推理 P95 延迟低于 200 毫秒；每日批量打分在 30 分钟内完成；模型与特征均可追溯到具体版本；当输入特征分布发生显著漂移时触发告警。这些数字属于教学示例设定，实际项目需与业务方共同确认。

围绕这个项目，我们会依次产出：清洗后的 Delta 表与特征表、MLflow 实验记录与注册模型、批量打分 Workflow、在线 Serving 端点、监控看板与回滚预案。每一章都会落到具体对象和可检查的产出上，而不是停留在概念层面。

需要建立的第一个认知是：AI 产品化不是数据科学工作的延伸，而是一次责任重构。模型只是产品的一个组件，围绕它的数据契约、服务接口、监控指标和治理规则，才是决定项目能否长期运行的关键。接下来的章节，我们就从这条链路的起点——场景界定与数据准备——开始动手。