2. Databricks平台AI能力地图

在Databricks上做AI产品化，最容易犯的错误不是模型效果不好，而是把平台组件当成一堆可以随意拼装的积木。实际上，Unity Catalog、MLflow、Model Serving、Feature Store、Workflows、Delta Lake、Vector Search这些组件各自解决的是产品化链条上不同阶段的问题，它们之间有明确的职责边界和依赖关系。理解这张能力地图，比记住每个组件的API更重要。

从数据到服务的四层能力结构

把Databricks的AI能力按产品化交付的视角重新组织，可以分成四个层次：数据与治理层（Delta Lake、Unity Catalog）、特征与实验层（Feature Store、MLflow）、服务与检索层（Model Serving、Vector Search）、编排与调度层（Workflows）。这四层不是简单的上下堆叠，而是存在交叉依赖——比如Model Serving的模型版本来自MLflow，而MLflow记录的训练数据血缘又依赖Unity Catalog。

各组件在产品化交付中的真实定位

Delta Lake是整条链路的数据底座。它的价值不在于“能存数据”，而在于ACID事务、时间旅行和增量读取这三个能力让AI产品化中的可复现性成为可能。训练一个模型时，如果数据源是Delta表，你可以精确记录训练时读取的表版本号，三个月后需要复现实验时，用VERSION AS OF就能回到完全相同的数据快照。没有这个能力，模型复现就是一句空话。

Unity Catalog解决的是“谁能在什么数据上做什么”的问题。在产品化交付中，它至少承担三个关键职责：第一，统一管理所有数据资产（表、视图、卷、函数、模型）的权限，避免每个团队各自维护一套ACL；第二，自动捕获数据血缘，当上游表结构变更时能快速定位受影响的模型和作业；第三，提供审计日志，满足合规要求。一个常见的选型误区是认为Unity Catalog只是“权限管理”，实际上它的血缘能力在故障排查时的价值往往更大。

Feature Store的核心价值是解决训练与推理的特征一致性。离线训练时用Spark计算特征，在线推理时用点查获取特征，如果两套逻辑分别实现，特征漂移几乎不可避免。Feature Store通过统一的特征表定义和自动化的在线/离线同步机制，把这个问题从“工程难题”降级为“配置问题”。但要注意，Feature Store并非所有场景都必需——如果模型只做批量推理，没有实时在线服务需求，直接用Delta表管理特征反而更简单。

MLflow是实验管理和模型生命周期的中枢。Tracking模块记录每次训练的入参、指标和产物，Registry模块管理模型版本和阶段转换（Staging → Production → Archived）。在产品化交付中，MLflow Registry的“模型版本+阶段”机制是与CI/CD流水线对接的关键接口——发布流程本质上就是把某个模型版本从Staging推进到Production，并触发Model Serving的更新。

Model Serving负责把模型变成可调用的REST端点。它支持自动扩缩容、灰度发布和请求日志记录。选型时需要关注两个参数：一是并发度（每个副本能同时处理的请求数），二是扩缩容的冷启动时间。对于延迟敏感的在线服务，通常需要设置最小副本数大于0，避免冷启动导致的尾延迟飙升。

Vector Search是RAG类应用的基础设施。它提供向量索引的构建和相似性检索能力，支持Delta表同步和实时更新。在产品化交付中，Vector Search的选型关键点是索引类型和更新频率的权衡：HNSW索引查询快但构建成本高，适合更新不频繁的场景；如果数据每天大量新增，可能需要考虑增量索引策略或接受一定的查询延迟。

Workflows是串联所有组件的编排层。它把数据预处理、特征计算、模型训练、评估、注册、部署这些步骤组织成DAG，并处理重试、告警和依赖管理。一个常见的实践是：用Workflows调度每日的特征更新和模型再训练，训练完成后自动评估，指标达标则自动注册新版本并触发Serving更新，不达标则保留旧版本并发送告警。

选型原则：从交付目标反推组件组合

组件选型不应该从“平台有什么”出发，而应该从“产品需要什么”反推。以下三条原则在实际项目中反复被验证有效：

• 按推理模式选服务层：批量推理优先用Delta表+Workflows，不需要Model Serving；实时在线推理才需要Model Serving+Feature Store在线点查；RAG应用则需要Model Serving+Vector Search组合。
• 按复现要求选实验层：如果模型需要定期再训练且要求可复现，MLflow Tracking+Registry是必选项；如果只是一次性分析，可以只用Notebook+Delta表版本控制。
• 按合规要求选治理层：涉及敏感数据或需要审计追踪的场景，Unity Catalog是硬性要求；内部实验性项目可以先用工作区级别的权限控制，但要在产品化前完成迁移。

一个典型的组合示例

假设要交付一个“客户流失预警”在线服务，典型的组件组合是：Delta Lake存储客户行为宽表，Unity Catalog管理表和模型的权限与血缘，Feature Store定义并同步“近30天活跃天数”“近7天投诉次数”等特征，MLflow Tracking记录XGBoost训练实验并用Registry管理版本，Model Serving部署模型并提供REST端点，Workflows每日调度特征更新和模型再训练，Vector Search在这个场景中不需要。这个组合中每个组件都有明确的不可替代性，没有为了“用全平台”而引入多余组件。

反过来，如果是一个“知识库问答”RAG应用，组合会变成：Delta Lake存储文档原始数据和分块后的文本，Unity Catalog管理文档权限，Vector Search构建和检索向量索引，Model Serving同时部署Embedding模型和LLM，MLflow管理Prompt模板和模型版本，Feature Store通常不需要，Workflows负责文档增量同步和索引更新。可以看到，同样是Databricks平台，不同产品形态的组件组合差异很大，这正是能力地图的价值——它让你看清每个组件的适用边界，而不是盲目堆砌。