大数据上的机器学习

我们围绕几个核心理念设计机器学习平台：特征应一次定义并重复使用；实验应默认可复现；模型在投入生产前应进行版本控制和注册；以及推理路径应以与底层服务相同的方式进行可观察。这些理念并非新颖；持续应用这些理念的纪律性是将能累积改进的平台与僵化的平台区分开来的关键。

我们首选的工具包因环境而异。我们曾围绕托管服务（如Databricks、SageMaker、Vertex AI和Azure ML）、Kubernetes上的开源堆栈（MLflow、Feast、Ray、Kubeflow、Argo）以及两者的混合体进行构建。选择取决于您现有的投资、团队的操作舒适度以及相关工作负载的延迟配置文件。

在所有这些方面，我们坚持几个不可协商的原则：每个工件（数据集、特征集、模型）都由内容可寻址的哈希值标识；每次环境之间的升级都会记录所用输入的血缘关系和验证结果；生产中的每个模型都配有一个监控器，了解什么是“良好”状态。

• 可复现的训练管道
• 具有在线和离线一致性的特征存储
• 用于检索和相似性的向量存储
• 模型注册、阶段部署和回滚
• 漂移、性能和成本监控
• 成本感知的训练和推理

分布式训练被证明的合理性往往低于其尝试次数。我们的许多客户最初都相信他们需要一个多节点集群，结果却发现一个经过良好调优的单一大机器上的梯度提升模型，以更低的成本和更少的操作痛苦胜过了它。我们从建立一个强大的单机基准开始，并且只有当数据、模型架构或延迟目标明确要求时才进行扩展。

当确实需要分布式时——例如基础模型微调、分布式深度推荐系统，或非常大的特征空间——我们会酌情使用Ray、PyTorch DDP、DeepSpeed、Spark MLlib或Horovod，并密切关注数据路径。存储或洗牌瓶颈导致的分布式训练是一个令人沮丧的普遍失败模式，而其解决方案很少涉及更多的GPU。

可复现性被视为训练管道的一个属性，而不是一个美好的愿望。随机种子、库版本、环境定义、数据快照和超参数都会自动捕获，并与生成的模型工件绑定在一起。三个月后，当监管机构或分析师询问模型为何表现出特定行为时，所有的线索都完整无缺。

“更多GPU很少是答案；更好的数据管道通常是。”

推理架构由消费者决定，而非模型。告知每天一次批处理决策的风险评分与在毫秒级百分位下提供的实时推荐需要不同的平台。我们根据消费者的延迟、吞吐量和新鲜度要求设计服务路径，并且在合理的情况下，会毫不犹豫地在不同用例中重用基础设施。

对于实时推理，我们通常结合使用带有在线服务的特征存储、模型服务器（Triton、BentoML、KServe或托管等效项）以及在适当时使用请求侧缓存。对于批处理推理，我们依赖相同的训练集群，具有确定性窗口和与上游管道相同的血缘控制。对于流式推理，我们将模型直接集成到流处理拓扑中，在数据流中对事件进行评分。

我们在这个层面密切关注成本，因为这是机器学习项目最容易变得昂贵的地方。量化、蒸馏、批处理、请求合并、根据真实需求信号进行自动扩展以及在较小模型足够时愿意使用较小模型，通常可以使推理成本降低一个数量级，而准确性没有可测量的损失。

生产中的模型是一个活跃的工件。数据会发生变化，概念会演变，上游服务会改变，下游消费者会发现使用输出的新方式。我们设计机器学习系统时，期望它们在有效生命周期内会被再训练数十次，每次再训练都遵循与第一次部署相同的受控、可审计的路径。

漂移检测默认集成——包括特征漂移和标签漂移（当标签可用时）——并与明确的行动阈值配对。有些模型按计划再训练；另一些模型根据信号再训练；选择取决于标签的生成方式以及过期模型的成本。无论哪种方式，再训练都会产生一个新候选模型，该模型在相同的评估框架上与现有模型竞争，获胜者在与最初相同的发布控制下进行推广。

当模型面临对抗性条件（欺诈、滥用、游戏）时，我们将红队演练和影子部署作为标准实践。生产流量流向实时模型和候选模型，并在推广前详细比较候选模型的行为。这种纪律性是平凡的，但它提供的安全性是实质性的。

在我们的合作中，最一致的成果不是单个模型，而是机器学习生命周期的可衡量加速。过去需要数月才能将模型从笔记本电脑投入生产的客户，现在可以在数周内可靠地完成。以前需要专门团队操作的模型，现在可以在例行审查之间默默运行。过去用于维护现有模型的精力被释放出来，用于构建下一个模型。

第二个一致的成果是可防御的成本曲线。因为特征工作得到重用，因为推理规模适当，因为计算被视为首要关注点，所以下一个机器学习用例的边际成本下降。这是区分平台与试点项目组合的特性。