什么是机器学习模型监控？
为了选择合适的解决方案，首先需要就问题的定义达成一致。机器学习模型监控的首要目标是提供解决方案，在ML应用程序中的缺陷对下游业务KPI产生负面影响之前，对其进行检测。由于在KPI受到影响之前通常很难检测到模型问题，因此需要专门的监控工具。本着这种精神，以下是ML监控工具的基本要求。
首先，ML监视与传统软件产品的监视不同，并且通常更复杂。在ML上下文中，仅了解系统是运行还是关闭是不够的。相反，有必要确保系统正在发挥其预期功能。 算法是否预测了它应该做的事情？ 客户数据是否可靠且定期地获取并用于重新训练模型？ 企业及其客户能否信任该模型的结果？ 这些都是在生产中监控机器学习模型时要问的重要问题。
Mona 的“状态检查”仪表板 - 为您提供基于 AI 的流程的健康状况的全貌，而不仅仅是您的模型
其次，需要在其业务功能的上下文中监控和理解 ML 模型。这在很大程度上归结为设计和衡量正确的指标，衡量业务流程性能的指标，而不仅仅是模型行为。需要比模型遥测提供的更细致入微的理解。
第三，适当的监控工具需要在非常精细的级别上进行监控，但要智能地进行监控，而不会产生太多的警报，以至于它变得嘈杂和分散注意力。也就是说，模型行为的变化需要在它们传播到对业务 KPI 产生更显着影响、损害您的业务并失去您的客户之前被检测到。因此，最好的监控工具执行一个非常微妙的平衡行为，提供丰富、细粒度的数据，而不会频繁发出警报，以至于它变得不堪重负。
什么不是机器学习模型监控？
鉴于 MLOps 领域的炒作和投资标准，许多玩家如雨后春笋般涌现，声称已经创建了下一个最好的监控工具。然而，这些人工智能监控索赔人中的许多人并没有像宣传的那样表现。它们通常可以分为不同的子类别，并且大多数可用工具将仅涵盖其中一个功能集。
提供基础架构和应用程序性能监控 (APM) 的工具
落入此桶的工具通常是传统软件监控方法的遗留物，只是经过松散调整以解决 ML 上下文。它们通常通过跟踪延迟、错误率和停机时间等指标来提供系统表层机制的良好快照，但它们通常完全无法解决 ML 管道的算法和数据方面的问题。换句话说，它们只关注基础设施堆栈的健康状况，但当基础设施用于服务 ML 模型时，有时会被当作“ML 监控”工具。虽然这种类型的监控很重要，但它是许多现有解决方案的问题，而且它不是“ML 监控”。 APM 工具通常是云服务产品的一部分，因为它们完全属于云基础架构堆栈。
异常检测工具
虽然能够检测异常是监控的关键部分，但它只是端到端解决方案所需的一小部分。 Mona 检测到此类异常，提供完整的仪表板和警报系统等
顾名思义，异常检测工具旨在根除数据集中发现的异常。他们可以识别异常值、基于时间序列的异常和分布差异等现象。不可否认，这些是构建监控解决方案时的重要功能。然而，一个成熟的监控解决方案将包括许多额外的组件。大数据层对于收集有关模型输入和输出、业务和技术元数据以及来自所有相关环境（开发/生产、训练/推理和ground truth标签）的业务反馈信息的相关信息至关重要。交互式可视化层允许仪表板、故障排除、报告创建和数据探索，并允许非技术用户一瞥系统。此外，ML 监控工具应该是智能的，并且能够以可配置的方式自动检测异常，并提供有关它发现的异常的有见地的上下文。最后，需要有一个操作层来连接您的工作流程，在正确的时间提醒相关的人，并随着时间的推移跟踪问题。
实验跟踪工具
当在生产中跨模型版本进行测量时，Mona 检测到特定细分市场的性能漂移
实验跟踪工具在研究环境中非常有用。 它们允许您从端到端跟踪您的实验并比较模型在孤立数据集上的执行情况，并且通常提供指标记录和跟踪、自动绘图生成、数据版本控制等功能。但是，当您尝试将模型投入生产时，它们的局限性开始显现。 虽然它们可能能够在有限的意义上继续监控模型的性能，但它们并不是为了了解整个业务流程如何受到软件和 ML 组件的联锁系统的影响。尽管它们可能提供基本的基础设施监控功能，但不应将它们与一个成熟的监控解决方案混淆，该解决方案可以查明您的业务 KPI 如何受到链式模型和数据交互的影响。
可解释性工具
Mona 通过相关的指标和特征自动找到性能不佳的可能解释
可解释性工具是为了响应神经网络和类似的不透明深度学习模型的广泛使用而开发的，尽管大多数可用于任何模型类型。 他们专注于提供对模型如何运作的理解，通常通过使用诸如 SHAP 等指标来阐明特征重要性。 可解释性通常与监控混为一谈，因为这两种工具都可以从机器学习系统中传递信任。 虽然这很重要，但应将可解释性工具与监控解决方案结合使用，而不是代替它们。 从根本上说，可解释性产品仅限于理解单个模型的特征，并不能像真正的监控解决方案那样将整体观点传递到数据、模型、基础设施和业务流程中。
故障排除工具
Mona 的“调查”页面 - 虽然在问题出现时解决问题的能力很重要，但这还不足以实现监控的总体目标
也许增长最快的监控“冒名顶替者”类别是故障排除工具。它们也可能是最虚幻的，通常给人一种似是而非的印象，即系统正在被监控，而实际上并非如此。事实是，故障排除工具不会在潜在问题表现为实际问题之前识别它们。相反，它们被设计为“响应”工具，允许用户更清楚地了解系统在功能中断并产生用户投诉后发生的情况。显然，仅在 KPI 受到负面影响后才修复系统并不理想，而这正是故障排除工具旨在提供的功能。真正的监控解决方案允许您在这些问题传播之前识别它们。
寻找真正的机器学习监控解决方案
围绕 ML 监控的概念有如此多的噪音和混乱，难怪业务领导者甚至技术人员在为他们的用户场景选择正确的工具时都会感到困惑。我们希望本文有助于描述真正的监控解决方案所提供的功能。也就是说，在评估和测试产品时，您需要确保它们不是
- 将面向 devops 的监控（APM、云基础设施）与算法和数据监控相结合。
- 将监控与其他听起来很花哨的功能（例如可解释性和公平性）混为一谈。
- 将全面解决方案与其特定层合并；例如，异常检测或故障排除。
最重要的是，您需要验证您正在考虑的解决方案是否能够检测并提供有关新生问题的信息，以免它们冒出更复杂、难以解开且对下游业务 KPI 有害的问题。
