Cloudflare 的机器人管理被世界各地的组织用来主动检测和缓解自动化机器人流量。为此，Cloudflare 利用机器学习模型来帮助预测特定 HTTP 请求是否来自机器人，并进一步区分良性机器人和恶意机器人。Cloudflare 每秒处理超过 5500 万个 HTTP 请求，因此我们的机器学习模型需要在 Cloudflare 的规模上运行。
我们不断改进为机器人管理提供支持的模型，以确保它们纳入最新的威胁情报。这一迭代过程是确保我们的客户领先于恶意行为者一步的重要组成部分，并且需要严格的实验、部署和持续观察过程。
我们最近分享了 Cloudflare 的 MLOps 方法介绍，该方法提供了 Cloudflare 模型训练和部署流程的整体概述。在这篇文章中，我们将更深入地探讨监控，以及我们如何持续评估支持机器人管理的模型。
为什么监控很重要
在发布机器人检测模型之前，我们会进行广泛的模型测试/验证过程，以确保我们的检测按预期执行。通过浏览器、HTTP 协议和其他维度，在大量 Web 流量段中验证模型性能，以便更详细地了解我们期望模型在部署后的执行情况。如果一切顺利，该模型就会逐渐投入生产，我们的机器人检测也会得到提升。
将模型部署到生产后，在粒度级别上了解性能可能具有挑战性。当然，我们可以查看基于结果的指标，例如机器人分数分布或挑战解决率。这些内容提供了丰富的信息，但随着机器人评分或挑战解决率发生任何变化，我们仍然会问：“Web 流量的哪些部分受此变化影响最大？这是预期的吗？”。
训练互联网模型就是针对移动目标训练模型。只要输入不改变，任何人都可以使用静态数据训练模型并取得很好的结果。构建一个适用于具有新威胁、浏览器和机器人的未来的模型是一项更加困难的任务。机器学习监控是这一过程的重要组成部分，因为它为我们提供了信心，让我们相信我们的模型能够通过严格、可重复的流程不断进行推广。
在机器学习监控之前的日子里，团队将分析 Web 流量模式和模型评分结果，以跟踪被评分为机器人或人类的 Web 请求的比例。这个高级指标有助于评估模型的总体性能，但没有提供模型如何处理特定类型流量的详细信息。为了进行更深入的分析，我们需要进行额外的工作来调查各个流量段的性能，例如来自 Chrome 浏览器或使用 iOS 的客户端的流量。
通过机器学习监控，我们不仅可以在高层次上了解模型的行为方式，而且可以更精细地了解模型的行为方式，而无需进行大量的手动调查。监控通过回答关键问题来关闭反馈循环：“我们的机器人检测模型在_生产中_的表现如何？”监控为我们提供了与部署前模型验证/测试相同的置信度，但应用于生产中的所有模型除外。
事实证明，监控功能非常有用，其中包括：
调查机器人评分异常：如果客户报告机器学习评分出现假阳性/阴性，而我们怀疑检测子集存在更广泛的问题，那么监控可以帮助我们找到答案。工程师可以从我们的全球监控仪表板中获得见解，也可以关注特定数据集的性能。
监控任何模型预测或请求字段：监控服务非常灵活，可以在我们的 Web 请求数据库中存储的任何请求工件上添加可观察层。如果模型预测或相关结果与我们的请求日志一起存储，那么就可以对其进行监控。我们可以跨工程团队合作，以监控任何结果。
部署新模型：我们逐步部署新模型版本，最终逐步在 Cloudflare 的全球 Web 流量上运行。在此过程中，我们会进行一系列检查，然后才能将新模型部署到下一个发布步骤。监控使我们能够在每个部署阶段将最新模型与以前的版本和细粒度流量段进行比较，这让我们在继续部署时充满信心。
机器学习监控如何运作？
该过程从真实数据集开始，这是一组已知由人类或机器人生成的流量数据，且已进行相应且准确的标记。如果我们的模型将特定请求识别为机器人流量，当我们的真实标签表明该请求源自人类时，我们就知道该模型对该请求进行了错误分类，反之亦然。这种标记数据（我们将流量标记为来自机器人或人类）是我们的模型首先接受训练以学习进行检测的数据。
在训练时收集的数据集使我们能够及时评估该快照的训练模型的性能。由于我们希望在生产中持续评估模型性能，因此我们同样需要获取实时标记数据以与我们的机器人分数进行比较。当我们确定 Web 请求来自某个参与者时，我们可以为此目的生成一个带标签的数据集。例如，我们的启发式引擎是高可信度标记数据的来源之一。其他可靠的标记数据来源包括客户反馈和攻击模式研究。
我们可以直接将模型对 Web 请求的机器人评分与最近标记的数据集进行比较，以判断模型性能。为了确保我们在评估模型随时间变化的分数时进行同类比较，一致性至关重要：数据本身会有所不同，但我们希望方法、条件和过滤器在采样窗口之间保持相同。我们已经自动化了这个过程，从而实时生成标记数据集，让我们能够及时了解模型的性能。
获取详细的性能指标
假设我们检测到标记为机器人流量的给定数据集的准确性突然下降，这意味着我们的检测错误地将机器人流量计为人类流量。我们很想确定造成评分失误的确切流量子集。它来自最新的 Chrome 浏览器还是某个 ASN？
为了回答这个问题，性能监控使用了专门化，这是针对我们的数据集应用的过滤器，重点关注感兴趣的维度（例如浏览器类型、ASN）。通过对数据集的专门化，我们既可以提出_应该_如何对流量评分的期望，也可以深入了解导致失误的确切维度。
将监控功能整合到我们的机器人机器学习平台中
监控系统在名为 Endeavor 的统一平台上运行，我们构建该平台是为了处理与机器人相关的机器学习的各个方面，包括模型训练和验证、模型可解释性以及向运行机器人检测的服务器提供最新信息。我们可以将监控分解为几个任务：渲染监控查询以获取数据集、计算性能指标和存储指标。Endeavor 使用 Airflow（一种工作流执行引擎），使其成为在 kubernetes 集群和 GPU 上运行监控任务的好地方，并可以访问 Postgres 和 ClickHouse 数据库。
渲染监控查询
监控查询只是对 ClickHouse Web 请求数据库的 SQL 查询，询问“机器学习评分现在看起来如何？”。当我们添加数据集和专门化条件时，查询会变得更加精确，以便我们可以提出更精确的问题“对于这组已知（非）自动化流量，在相关维度上的机器学习评分看起来如何？”。
在我们的系统中，用于训练和验证的数据集是使用 SQL 查询确定的，这些查询专门用于捕获请求流量的片段，例如由我们的启发式引擎标记为机器人的流量。对于模型监控，我们调整这些查询来测量准确性等性能指标，并不断更新时间范围以测量最新的模型性能。对于训练和验证中使用的每个数据集，我们可以生成一个监控查询，以产生对模型性能的实时见解。
计算性能指标
准备好渲染的监控查询后，我们可以继续从 Web 请求数据库中获取机器人分数分布。MetricsComputer 将机器人分数分布作为输入，并针对可配置的时间间隔生成相关的性能指标，例如准确性。
我们可以根据任何感兴趣的指标评估模型性能。MetricInterface 是一个 Python 接口，充当性能指标的蓝图。任何新添加的指标只需要实施接口的 compute_metric 方法，该方法定义 MetricsComputer 应如何执行计算。
存储指标
每次监控运行后，我们都会按数据集、模型版本和专门化值将性能指标存储在 ml_performance ClickHouse 表中。预计算指标支持较长的数据保留期，因此我们可以根据模型版本或感兴趣的维度随时间的推移来审查模型性能。重要的是，可以根据需要回填新添加的性能指标，因为 ml_performance 表还存储用于计算每个指标的分数分布。
在 GPU 上运行任务
指标计算在跨 GPU 运行的 endeavour-worker 实例之间进行负载平衡。从系统角度来看，airflow-scheduler 将监控任务添加到 Redis 队列中，并且在每个 GPU 上运行的 Airflow Celery worker 会从队列中提取任务进行处理。与只运行临时模型训练工作负载相比，我们从 GPU 持续提供的生产服务中获益匪浅。因此，监控服务充当健康检查的角色，确保各种 Endeavor 组件在 GPU 上正常运行。这有助于确保 GPU 始终处于更新状态，并随时准备运行模型训练/验证任务。
机器学习监控的实际应用
为了更好地说明 Cloudflare 如何使用机器学习监控，让我们来看看最近的一些例子。
提高机器学习机器人检测的准确性
当第一次部署监控系统时，我们很快发现了一个异常：我们的模型在使用 HTTP/3 的 Web 流量上表现不佳。当时，HTTP/3 的使用在 Web 上几乎看不到，而且生产中的主要模型没有接受过 HTTP/3 流量的训练，导致机器人分数不准确。幸运的是，另一个机器人检测层（即我们的启发式引擎）仍然可以准确地查找使用 HTTP/3 的机器人，因此我们的客户仍然受到保护。
尽管如此，这一发现还是指出了下一次模型迭代的一个关键改进领域。我们确实有所改进：下一个模型迭代始终能够区分机器人和人类发起的 HTTP/3 Web 请求，与之前的模型版本相比，准确度提高了 3.5 倍以上。随着我们启用更多数据集和专门化，我们可以发现特定的浏览器、操作系统和其他维度，从而在模型训练期间提高性能。
早期检测，快速干预
在全球范围内部署机器学习，在遍布全球 100 多个国家/地区的数据中心中运行，是一项具有挑战性的工作。事情并不总是按计划进行。
几年前，我们对机器学习驱动的机器人检测进行了更新，这导致机器人检测误报增加——我们错误地将一些合法流量标记为机器人流量。我们的监控系统很快显示出住宅 ASN 的性能下降，而我们预计其中大部分都是非自动化流量。
在上图中，显示的是部署到 1-3 三个主机托管“层”的情况。由于软件部署从第 3 级主机托管中心开始，然后逐步升级到第 1 级主机托管中心，因此其影响也遵循相同的模式。
与此同时，我们正在将一个软件版本部署到我们的全球网络，但我们不知道这是否是性能下降的原因。我们进行分阶段部署，每次在一批数据中心更新软件，最终覆盖到全球流量。我们的监控仪表板显示，性能的下降与这一部署模式完全一致，而且该版本已开始到达我们最大的数据中心。
监控仪表板清楚地显示了软件更新后的模式。我们在更新到达大部分数据中心之前还原了这一更改，并恢复了正常的机器学习机器人检测性能。通过监控，我们可以捕捉性能异常，挖掘根本原因，并快速采取行动。
适用于所有人的模型部署监控
我们看到了能够监控和控制我们的模型和部署的巨大价值，并意识到其他人也一定会遇到同样的挑战。在接下来的几个月里，我们将为 AI Gateway 构建更高级的功能——我们的代理可以帮助人们更好地观察和控制他们的 AI 应用程序和模型。借助 AI Gateway，我们可以在一个统一的控制平面中执行与机器人检测模型相同的所有部署、监控和优化策略。我们很高兴能够在内部使用这些新功能，但对于向公众发布这些功能感到更为兴奋，这样所有人都能够部署、测试、监控和改进他们使用 AI 或机器学习模型的方式。
下一步
如今，机器学习监控可以帮助我们调查性能问题，并在我们推出新模型时监控性能，而这一切才刚刚开始！
今年，我们加快了机器人检测机器学习模型的迭代速度，以比以往更快的速度提供更好的检测结果。监控是实现快速安全部署的关键。我们很高兴能添加基于模型性能的警报功能，这样，如果模型性能超出我们的预期范围，就会自动向我们发送通知。
除了推出 Workers AI 之外，我们最近还在 100 多个城市部署了 GPU，在全球范围内提升了我们的计算资源。这个新的基础设施将解锁我们的模型迭代过程，使我们能够探索具有更强大机器人检测能力的新尖端模型。在我们的 GPU 上运行模型将使推理更接近用户，从而获得更好的模型性能和延迟，我们很高兴能够将新的 GPU 计算与我们的机器人检测模型结合使用。