如何监控推荐系统？

Tubi 是一家由广告支持的视频点播（AVOD）流媒体公司，为观众免费提供视频内容，其庞大的视频内容库包含电影、电视剧、新闻直播和体育赛事。

观众可以在网页、移动设备和 OTT 上使用 Tubi

推荐系统作为 Tubi 的核心部分，能帮助用户找到他们接下来最想看的视频内容；因此，监控推荐系统以确保其按照预期正常运行是至关重要的。

我们深知，仅依赖传统服务的监控方式，对于推荐系统来说是远远不够的，因为推荐系统与传统服务之间存在着显著差异。例如，网页只有停止运行和正常运行两种状态，但推荐系统即使在运行，也可能是以严重降级的状态运行。

对推荐系统的质量变化进行监控是一个挑战，欢迎继续阅读本文，了解 Tubi 是如何解决这一问题的。

推荐系统的质量问题出现在哪些地方？

为了监控推荐效果的变化，我们需要确定那些可能出现错误并影响推荐质量的地方；一旦我们找出这些地方，我们就能可以找到对其进行监控的解决方案。

上图展示了推荐系统的工作流程，实线箭头显示了用户在请求推荐时数据的流向，而虚线则显示了推荐系统模型离线更新的过程

为了找出推荐系统可能出现质量问题的地方，我们可以看看在用户请求推荐时会发生什么：

(1) 客户端将用户数据发送给后端以获取推荐结果；

(2) 后端将用户数据转发给推荐服务器；

(3) 推荐系统利用用户数据进行模型预测，并将预测结果返回；

(4) 后端获取推荐结果后进行后处理；

(5) 将后处理规则应用于推荐结果，例如删除不存在的视频内容；

(6) 后端将推荐结果返回给客户端；

(7) 预测模型根据用户数据进行异步训练；

(8) 训练过的预测模型异步更新至推荐系统服务器。

潜在问题

(1) (2) 用户信息可能会出现异常

基于 Garbage in Garbage out 的原则，当用户信息有误时，模型很有可能会做出不准确的预测。例如，当用户的位置信息缺失时，预测将会基于其他用户的信息进行，从而导致推荐质量的下降。

(5) (6) 推荐系统之外的过程也可能出现错误

例如确定视频内容是否过期的逻辑可能会出错；因此，监控返回给客户端的推荐结果是必要的。

(7) (8) 上图中的虚线代表推荐系统模型的更新过程

这一过程包括数据清洗、生成训练数据、训练新模型以及将训练后的模型同步到推荐系统服务器。模型的质量在很大程度上取决于训练数据的质量，训练数据的异常可能出现在以下几个方面：

• 内容特征 —— 内容元数据可能会出现缺失的情况。
• 上下文特征 —— 传递给预测模型的数据可能会出现问题，并引起模型的推断问题和训练数据问题。
• 标签 —— 如果数据处理不恰当，可能会显著减少正样本数量。
• 上游数据 —— 这些数据对于训练数据至关重要，但这通常不在机器学习团队的负责范围内；例如，第三方提供的内容元数据和用户在主页的浏览互动数据。监控并捕获由上游数据变化而导致的未预期的数据问题，对于保证机器学习系统的正常运行至关重要。

监控潜在问题的解决方案

在深入理解可能存在的问题后，我们提出了通过监控以下三个关键数据来监控推荐系统的方案：

• 传递给模型用于做出预测的数据；
• 在客户端显示的最终推荐结果；
• 决定模型质量的模型训练数据。

传递给模型的数据监控

将数据传递给模型是推荐系统工作流程中最早的环节，一旦这一步出现错误，就会导致推荐质量的下降。这种问题可能较难识别，因为客户端发送的数据由后端接收并传递给推荐系统，而客户端和后端团队可能对于推荐出现的异常变化并不敏感。因此，记录并监控客户端传递的数据是非常重要的；例如，传递给模型的用户设备所设置语言所占的百分比。

2023 年 1 月用户设备所设置语言百分比的变化趋势，每条线都代表了一种语言的百分比

上图展示了从客户端获取的语言为空在一段时间内比例上升非常严重的情况。客户端的语言设置是一个关键信息，推荐模型会通过它为用户展示更多对应语言的内容。我们发现两个客户端平台做了不符合预期的改动，并及时通知了客户端团队，问题因此很快得到了解决，这很好地体现了此监控系统所带来的帮助

最终推荐结果的监控

客户端的最终推荐结果由推荐模型和后处理步骤决定。我们团队需要找出并监控基于最终推荐结果的关键属性，例如各种类型视频内容的推荐百分比。为了对推荐结果建立监控，我们需要对业务有深入的理解。

2023 年 1 月推荐列表中内容数量过少 (<X) 的比例变化趋势，百分比过高则意味着整个推荐系统可能存在问题

模型训练数据监控

训练数据的质量决定了模型的质量和推荐的质量。我们观察到训练数据的关键属性通常随时间的推移变化不大，但如果关键属性的变化较大，则可能存在问题。例如：

• 训练数据的行数发生变化；
• 训练数据中正样本比例变化；
• 训练数据中特征字段的缺失值比例。

监控最终的训练数据可以确保其属性与预期相符，这种监控概念也同样适用于基础数据的监控。

2023 年 1 月正样本比例的变化趋势，如果变化过大，则可能存在问题

实施设计和考虑因素

监控模型的主要焦点是监控数据分布的变化，遵循 Garbage in Garbage out 的原则，我们的初始版本是通过对失败的事后分析并从中学习而得出的，这让我们积累了许多宝贵的用例，为最终构建整个平台提供了支持。基于对数据监控的重视，我们需要根据数据的特性考虑以下几个方面：

• 及时性
  监控系统的及时性是至关重要的，我们的目标是在最短的时间内监测到异常。在推荐系统中，我们观察到两种类型的数据（用户请求和响应）构成了实时数据流，对这些数据进行实时监控非常必要，这样我们可以及时识别部署模型或服务中的任何异常，并及时进行干预。
• 数据特点
  实时监控事件流需要时序数据库的支持，这种数据处理有一个特点是处理时间和事件发生时间接近；因此我们在处理数据时，可以忽略处理时间和事件发生时间的差别。(1) (2) (5) (6) 属于这种数据类型。
  另一种数据类型为批处理数据，是按小时或者天级别更新的数据；这种数据的分析数据规模较小，数据特点是事件时间和处理时间有较大差别且不稳定。我们在处理时应以事件时间为准，因此这两种数据需要不同的处理方式，(7) 和 (8) 中的大部分属于第二种。
• 可扩展性
  商业需求的不断变化使得确保监控指标彼此独立变得至关重要，这样可以确保任何指标的部署或撤销都不会影响其他指标的监控，尤其是在实时场景中，不会对其他监控产生影响。

为了适应业务需求的不断扩展，实现水平扩展也是必要的。例如，当新模型引入时，应同时部署一套默认的监控指标，以确保系统基本的稳定性，并通过监控系统来监测其稳定性。

• 数据量的可扩展性 —— 系统应在不影响性能的前提下，能够流畅地处理增加的数据量。
• 支持类型的可扩展性 —— 系统应具备足够的灵活性，能够支持添加不同的类型，以适应新的业务需求或引入多样化的模型。

数据监控指标数据流

为了实现这些目标，我们进行了以下操作：

• 定义了灵活且明确的协议
  我们建立了一个相对宽松且清晰的结构协议，一个指标包含三个属性：数据源，作用范围和指标名称。用户定义指标时，可以通过共享的源和范围属性以及唯一的名称来区分不同的实例，从而方便扩展。
• 为用户提供了多种定义成指标的方式
  用户可以使用 Scala，Python API 或我们提供的 DSL 语言来定义指标；在 DSL 中，我们使用了简单且有效的 JSON 路径表达式来定义提取逻辑。例如，我们可以使用 .containers[*]{.slug == \\"featured\\"&& .contents < 8 来确认是否有足够的内容。
• 配置文件更新取代作业部署
  对于实时数据监控，专用的监控作业需要作为稳定的服务、长时间运行。为了提高资源利用效率，我们为每个实时数据源配置了一个服务。但我们选择通过更新配置文件来动态调整服务的指标提取规则，实现及时且高效的更新，而无需重新部署作业。这些配置规则与第二点中提到的 DSL 相一致。

收获

以下是一些重要的收获：

• 监控推荐系统的质量是一个长期的任务。现有的监控指标可能需要进行调整，并需要新的指标来捕获新类型的问题。
• 使监控系统可扩展的关键是将其委托给领域的所有者。领域所有者负责管理警报，设置警报阈值，并识别潜在问题。
• 将警报的精确度置于召回之上是很重要的。因为精确度意味着真正存在问题的警报的比例，而召回则意味着问题被警报捕获的比例。当警报的精确度较低时，人们可能会倾向于忽视这些警报。
• 每月的监控总结对于团队了解推荐系统的情况非常有帮助。

总结

监控推荐系统的挑战主要在于监控推荐质量的变化。基于对众多实际问题的事后分析和对推荐系统的全面理解，Tubi 机器学习团队和数据团队设计了一个高效且可扩展的、基于数据的监控解决方案，并展示了如何监测和监控这些变化。

Tubi 正在招聘！

如果你对类似的高影响、大规模项目感兴趣，欢迎加入 Tubi，中国团队正在招聘!

作者：Qiang Chen，Bin Chen

校对：Shengwu Yang，Chun Shang