Netflix 撰写了一篇激动人心的博客，讲述了在生产环境中操作推荐引擎的最佳实践。
运营一个大规模的推荐系统是一项复杂的工作：它需要高可用性和吞吐量，涉及许多服务和团队，推荐系统的环境每秒都在变化。例如，新成员或新项目可能随时来服务。新代码和新 ML 模型经常部署到生产环境中。我们需要在 Netflix 解决的一个问题是，我们如何确保我们的推荐系统在这样一个动态环境中健康运行？
在这篇博文中，我们向RecSysOps介绍了我们在 Netflix 运营大型推荐系统时学到的一组最佳实践和经验教训。这些做法帮助我们保持系统健康，同时 1) 减少我们的救火时间，2) 专注于创新，以及 3) 与我们的利益相关者建立信任。
RecSysOps 有四个关键组件：问题检测、问题预测、问题诊断和问题解决。接下来，我们将回顾每个组件并分享我们的一些经验教训。
问题检测
在 RecSysOps 的四个组件中，问题检测是最关键的一个，因为它会触发其余步骤。缺乏良好的问题检测设置类似于闭着眼睛开车。
形式上，问题检测非常简单。如果生产中出现问题，我们需要能够快速检测到它。然而，出错的方式有无数种，其中许多我们可能还没有遇到过。以下是我们学到的一些经验教训，以增加我们在检测问题方面的覆盖面。
第一步是整合相关学科的所有已知最佳实践。因为创建推荐系统涉及软件工程和机器学习，这包括所有 DevOps 和 MLOps 实践，例如单元测试、集成测试、持续集成、数据量检查和模型指标检查。幸运的是，有许多可用资源，例如本文[1] 以及可用于检查 ML 系统并确定其差距的清单。
第二步是从您的角度对系统进行端到端的监控。在大型推荐系统中，经常会涉及到许多团队，从 ML 团队的角度来看，我们既有上游团队（提供数据），也有下游团队（使用模型）。我们学到的一件事是不要只依赖合作伙伴团队的审计。最好（从我们自己的角度）审核所有输入和输出，例如模型和这些模型生成的分数。例如，我们可能对上游团队生成的数据的特定部分感兴趣，而这部分的变化可能不会显示在该团队的整体审计中。再举一个例子，如果一个团队有兴趣使用我们的模型并进行预测，我们可以与他们合作记录模型预测的详细信息，例如特征、获取一小部分流量并从我们自己的角度对其进行审核。这种端到端的审计帮助我们发现了下游和上游的许多问题，尤其是在涉及新数据源的新项目开始时。
获得全面报道的第三步是了解利益相关者的担忧。这是增加问题检测组件覆盖率的最佳方式。在我们的推荐系统的上下文中，我们有两个主要观点：我们的成员和项目。
从成员的角度来看，问题非常简单。如果成员选择了服务排名模型排名不高的项目，这是一个潜在的问题。因此，监控和分析这些案例对于发现问题很重要，也是未来创新的重要灵感来源。
从项目的角度来看，我们需要确保与负责项目的团队合作并了解他们的担忧。就 Netflix 而言，这些团队表示担心适当的项目冷启动和潜在的生产偏差。这些都是 RecSys 社区中活跃的研究领域，但首先我们帮助这些团队围绕他们的关注点定义指标并构建工具来监控它们。我们还帮助他们深入了解这些问题是否在每个项目的基础上发生。后来我们将这些工具直接集成到我们的问题检测组件中。这使我们能够 1) 扩大问题检测范围，2) 主动解决与项目相关的关键问题并与利益相关者建立信任。
概括：
- 实施所有已知的最佳实践
- 以自己的方式端到端监控系统
- 了解利益相关者的担忧
问题预测
快速检测生产问题固然很棒，但如果我们能够预测这些问题并在它们投入生产之前修复它们，那就更好了。例如，一个项目（例如新电影、节目或游戏）的正确冷启动在 Netflix 很重要，因为每个项目只启动一次。所以我们想知道我们是否可以预测一个项目是否会在发布日期之前出现冷启动问题。这需要预测我们未来的生产模型，这是具有挑战性的。使用历史数据点，我们构建了一个模型，可以预测我们的生产模型在发布当天的行为统计数据。该模型使我们能够提前一周或更长时间发现与项目冷启动相关的潜在问题，这样我们就有时间在项目进入服务之前解决问题。
概括：
- 尝试在问题发生之前对其进行预测，而不是在问题投入生产后进行检测
问题诊断
一旦通过检测或预测模型确定了问题，下一阶段就是找到其根本原因。此过程的第一步是单独重现问题。然而，大规模推荐系统是非常动态的，我们可能无法通过简单地重新运行代码来重现问题，例如底层输入数据或特征值可能已经改变。因此，要重现该问题，我们需要提前设置正确的日志记录。这包括记录候选项目、上下文、功能、服务模型 ID 或重现问题所需的任何内容。为了降低成本，会为一小部分流量记录此信息。在这种情况下，我们需要精心设计一种采样方法，使其能够充分覆盖所有重要的流量切片。
重现问题后的下一步是确定问题是否与 ML 模型的输入或模型本身有关。要了解问题是否与输入数据有关，我们需要验证输入是否准确有效。虽然某些特征值可能可以将它们追溯到其原始事实并进行验证，但可能有许多特征涉及复杂的数据处理或机器学习模型本身的特征。因此，在实践中验证输入值是一个具有挑战性的问题。
一个简单的解决方案是将特征值与可比较项或成员的对应值进行比较。这使我们能够确定特征值是否在预期范围内。虽然简单，但这种方法对于标记异常非常有效。例如，在一种情况下，此方法标记了与项目的语言特征相关的异常值。经过进一步调查，我们发现该项目的语言在上游数据库中没有正确配置。
如果所有输入特征都正确，下一步就是深入挖掘 ML 模型及其训练数据，找出问题的根本原因。有许多用于模型检查和模型解释的工具，例如 Shap [2] 和 Lime [3]。基于模型的架构，我们还可以开发自定义工具来检查预期的属性。例如，可视化决策树的节点或神经网络的层。这种类型的分析曾经帮助我们识别处理缺失值的错误，在另一种情况下帮助我们识别训练数据的错误片段。
摘要：
- 设置日志记录以重现问题
- 开发工具来检查输入的有效性
- 开发工具来检查 ML 模型的内部组件
问题解决
一旦确定了问题的根本原因，下一步就是解决问题。这部分类似于典型的软件工程：我们可以有一个短期的修补程序或一个长期的解决方案。但是，为 ML 模型应用修补程序具有挑战性。这是因为这些模型是高度优化的，可能需要一段时间来训练，并且任何手动更改都可能导致次优推荐。那么，我们如何才能在解决问题的同时最大限度地降低生态系统其他部分的成本呢？该解决方案需要高度依赖于产品、平台和利益相关者的领域洞察力和创造力。由于每个修补程序都有自己的取舍，因此最好提前准备好修补程序解决方案的菜单。这使我们能够为每种情况快速选择和部署最合适的一个。
除了解决问题之外，问题解决的另一个阶段是改进 RecSysOps 本身。例如：
是否可以更快地发现问题？或者也许预测它？
是否可以改进我们的工具以更快地诊断问题？
最后，重要的是让 RecSysOps 尽可能顺畅。这使操作更顺畅，系统更可靠。例如：
确保检测或预测组件的检查定期自动运行。
如果在某些步骤（例如诊断或解决方案）需要人为判断，请确保该人已准备好所有必需的信息。这将使他们能够迅速做出明智的决定
确保部署修补程序就像单击几下一样简单
摘要：
- 准备好一系列修复策略并量化与每个策略相关的权衡
- 每一次事件都让 RecSysOps 变得更好
- 使 RecSysOps 尽可能顺畅
结论
在这篇博文中，我们介绍了 RecSysOps 以及我们在 Netflix 学到的一组最佳实践和经验教训。RecSysOps 由四个部分组成：问题检测、问题预测、问题诊断和问题解决。我们认为这些模式对于任何操作真实世界推荐系统的人来说都是有用的，可以让它保持良好的性能并随着时间的推移而改进。为大型推荐系统开发此类组件是一个迭代过程，对于未来的工作具有自身的挑战和机遇。例如，可能需要不同类型的模型来进行问题检测和预测。对于问题诊断和解决，需要对 ML 架构和设计假设有更深入的了解。总体而言，将这些方面放在一起帮助我们显着减少了问题，