机器学习 (ML) 模型是非常敏感的软件；它们的成功使用需要进行仔细监控以确保它们能正常工作。

　　当使用所述模型的输出自动做出业务决策时尤其如此。这在某种程度上预示着有缺陷的模型通常会对计算机显示终端的体验产生真正的影响。

　　因此，监控输入数据（和输出）对于模型实现其真正目标至关重要：有助于推动公司进行良好的决策并帮企业实现其目标。

　　在生产环境中使用机器学习模型时，您能够正常的使用以下一些可行的、与框架无关的技巧来制定更强大的监控策略。（许多技巧彼此之间有一些重叠——这是因为它们应该被用作综合策略的一部分，而不是一次性的解决方法）

　　您可以监控所使用模型中数值特征的平均值。您这样做是因为您想检验测试的数据问题，了解何时特征和标签分布发生明显的变化等。

　　平均值监控并不能告诉您全部情况，因为它带有一些不一定符合现实的假设。例如：

　　简而言之，有几率存在严重影响数据的问题，但特征的平均值可能根本不会移动，这就是为什么除了它之外还应该包含别的角度的一些原因。

　　该模型用于使用某种策略做出决策（拒绝/批准贷款，显示/不显示广告片等）。

　　您从技术角度（特征值、精度、准确性等）监控模型，但从中做出什么决策并不明显（这是策略/决策层）。

　　从技术角度监控模型是不够的，因为这并不能让其他利益相关者清楚地了解业务受到的影响。

　　监控使用模型做出的决策。例如：每天有多少人获得风险模型批准的贷款？每天有多少人的账户被欺诈？在这里监视绝对值和相对值通常很有用。

　　请注意根据目标受众调整粒度级别：如果您的模型多次为给定客户评分，那么您的目标受众可能对客户汇总的指标比对单个实体评分更感兴趣。

　　如果您正在运行实时模型，由于训练/服务偏差不匹配而做出了多少错误决策？您还应该对此进行监控。

　　您负责维护大量使用的机器学习模型，这些模型用于每天对许多单独的样例进行评分。

　　您通过仪表板监控特征，并且您想要调查几个“有趣”的模式，但常常要花费大量时间来追踪这样一些问题的原因。

　　一种更容易理解数据或模型问题的方法是将监控数据拆分为子群体（模型评分的数据子集）并分别监控。

　　这样做的原因是，许多数据问题对样例的某些子集具有关键影响，但它们在整个数据集的影响可能会“消失”，因为当您查看整个数据集的聚合值时，它们的绝对影响不足以感受到。

　　模型中使用的特征通常经过预处理或编码，以使其能够在某些分类器中使用。这有时是一个问题，因为很难以可视化或程序化的方式监控复杂的、精心设计的特征，而这些特征在第一眼看起来并不明显。

　　通过仔细编码（或解码）特征，您可以更轻松地进行监控。这是因为大多数监控框架更适合数值和分类值。如果您使用不相同类型的特征（例如：词嵌入、地理位置坐标），您在大多数情况下要将它们解码（例如：分别解码为字符串和城市名称），以便您可以更轻松地分析报表和在绘图中的展示这些特征。

　　此外，您可能希望监控原始（非预处理、非编码）值，因为这样做才能够更轻松地与其他团队沟通并在出现一些明显的异常问题时进行故障排除。

　　除了特征本身之外，还监控输入值（即不一定是特征本身，而是用于构建特征的信息）。当您对它们应用多个数字转换时，这很有用。

　　只要有可能，将布尔特征值编码为浮点数（1.0、0.0 和 null），以便像常规数值变量（提取平均值和其他数值属性等）一样更容易监控它们，并重用为这些变量制作的所有工具。

　　对于使用 one-hot-encoding 或 target-encoding 等策略编码的分类特征，您可能希望将它们解码回其原始值，以便您可以监控实际的类，而不是编码的类别。

　　你负责维护/运营一个或多个机器学习模型，每个模型都有几个特性，以不同的方式使用，等等。

　　您有多个仪表板和报告正在生成；但是，它们所需的工作量太大并且需要大量时间。

　　可以减少负担和通过仪表板和监控报告所需的时间。做到这一点的一种方法是促进一致性和标准化，从而最大限度地降低上下文切换成本，并使您的团队更高效/有效。

　　使用单一工具监控一切。如果可能的话，使用单一工具/供应商监控所有模型。这使得在多个模型之间共享配置变得更容易。

　　一致地排序特征。例如：根据特征重要性对特征图进行排序，以便您能够迅速查看是不是存在需要调查的严重问题（或仅按字母顺序排列）

　　统一命名：如果您需要命名文件、数据集、仪表板、表格等，请确保遵循某种模式（如：

　　team-name-model-name-date

　　您使用辅助例行程序、批处理作业或临时脚本来处理模型日志数据。您能够正常的使用这些例行程序来分析模型特征和分数并输出聚合值。您还可以使用这一些工具在特定条件下生成警报。

　　模型监控批处理作业/例行程序只是另一个软件，它们通常会不时停止工作（有人更改了表的名称，脚本中断，您的凭据过期等）。

　　如果您指望监视作业/例行程序/脚本来运行并发出问题信号，那么缺少警报可能会导致您认为一切正常，而实际上监视作业只是没有运行或它们存在一些问题。

　　监控作业的执行时间。稳步增加的执行时间可能表明您很快将不得已改变策略。执行时间太短可能表明作业中存在别的问题。

　　使用心跳式警报。您可以在每个作业/脚本的末尾添加一个步骤，以向其他系统发送 ping。当某些事情没发生时，心跳警报就会响起，例如，如果后端超过 24 小时没有收到 ping。

　　您有批处理作业来分析模型日志数据并计算这一些数据的聚合（每天的平均特征值、平均分数等），但实际上需要有人去查看数据以查看是不是一切正常。

　　创建被忽略的监控报告很容易，因没有人有时间主动去仪表板/笔记本并查看结果。以下是一些使它们更有用和更有效的方法。

　　这会产生用于训练的数据路径与用于推理的数据路径不完全匹配的风险（通常是 HTTP 调用外部服务以获取特征）。这称为训练/服务偏差。

　　训练/服务偏差是部署实时模型时应考虑的主要风险。只要模型在使用中，就必须持续监控。

　　监控批处理/实时流之间的精确匹配率（即，如果两个流之间有精确匹配，则为 1，假如没有精确匹配，则为 0）并像监控其他特征一样监控此值。这样你就能够正常的看到每个特征有多少偏差。

　　监控偏差的大小：对于批处理和实时数据路径之间不匹配的情况，它有多严重？这只是一个小差异还是一个大差异？

　　监控计数：监控给定日期的每个数据路径中有多少示例。这很重要，因为未知的变化可能会导致更多示例被您预期的实时模型评分。

　　您创建了一些实时警报（电子邮件、移动推送通知等），以在模型以意想不到的方式表现时提醒您，例如奇怪的特征值、缺失的特征、分数太高/太低，等等。

　　很容易导致警报过于嘈杂（经常发出警报，人们不再认认真真地对待它们）或根本不敏感（警报从不发出，即使它们应该发出）。

　　您应该尝试使警报保持相关且易于操作（包括足够的信息，以便人们较快地断定警报是否表明存在实际问题）。

　　注意奇怪的时间段，如清晨、周末等。由于在这些时间段，模型评分的示例可能会少得多，警报可能会因为样本量太小而发出。

　　始终包括用于警报的时间范围和特定数据点，以便人们评估它是否是误报： 坏：“模型 Y 中的特征 X 太高了”。好：“过去 15 分钟模型 Y 中的特征 X 的平均值太高（预期在 0.4 和 0.5 之间，但其实就是 100.0）”

　　如果可能，请包含指向完整仪表板的链接或能查看更完整数据并决定是不是应该进一步调查的地方。

　　如果可能，手头有一些故障排除指南，以便新的小组成员能轻松地对警报采取行动。

　　这些是我们在Nubank 监控多个 ML 模型时发现的一些有用的技巧。它们用在所有业务环境（信用、欺诈、CX、运营等），我们始终相信它们足够通用，也适用于其他公司。