平均值并不能说明全部情况
背景
您可以监控所使用模型中数值特征的平均值。您这样做是因为您想检测数据问题，了解何时/如果特征和标签分布发生变化等。
说明
平均值监控并不能告诉您全部情况，因为它带有一些不一定符合现实的假设。例如：
- 如果缺少数据，大多数数值工具会忽略这些数据并计算剩余（非空）数据的平均值；
- 它假设数据问题将大到足以显着移动平均值。或者，特征变化也可能使平均值移动很多，但不会影响更高的百分位数——这通常是做出模型决策的地方。
- 它假设模型分数的变化与基于它的动作具有线性关系。
简而言之，可能存在严重影响数据的问题，但特征的平均值可能根本不会移动，这就是为什么除了它之外还应该包括其他角度的原因。
建议
- 监控数字特征值的百分位数——例如：第 99、95、90 和 10、5、1 个百分位数。这样，即使平均特征值没有变化，您也可以检测尾部示例发生变化的情况。这对于数据分布偏斜或不平衡的情况特别有用。
- 监控所有特征的缺失值率。这需要单独监控，因为很大比例的缺失值是一个大问题——即使非缺失值的平均值没有太大变化。
- 将监控拆分为子群体，以检测仅影响总得分示例子集的问题。
策略/决策层需要额外的监控
背景
该模型用于使用某种策略做出决策（拒绝/批准贷款，显示/不显示广告片等）。
您从技术角度（特征值、精度、准确性等）监控模型，但从中做出什么决策并不明显（这是策略/决策层）。
说明
从技术角度监控模型是不够的，因为这并不能让其他利益相关者清楚地了解业务受到的影响。
您还应该监控使用模型做出的决策，以确保模型交付预期的业务价值。
建议
- 监控使用模型做出的决策。例如：每天有多少人获得风险模型批准的贷款？每天有多少人的账户被欺诈模式封锁？在这里监视绝对值和相对值通常很有用。
- 请注意根据目标受众调整粒度级别：如果您的模型多次为给定客户评分，那么您的目标受众可能对客户汇总的指标比对单个实体评分更感兴趣。
- 如果您正在运行实时模型，由于训练/服务偏差不匹配而做出了多少错误决策？您还应该对此进行监控。
将监控分解为亚群以获得更好的洞察力
背景
您负责维护大量使用的机器学习模型，这些模型用于每天对许多单独的示例进行评分。
您通过仪表板监控特征/分数，并且您想要调查几个“有趣”的模式，但通常需要花费大量时间来追踪这些问题的原因。
说明
一种更容易理解数据或模型问题的方法是将监控数据拆分为子总体（模型评分的数据子集）并分别监控。
这样做的原因是，许多数据问题对示例的某些子集具有关键影响，但它们可能会“消失”，因为当您查看整个数据集的聚合值时，它们的绝对影响不足以感受到。
建议
- 与其查看整个数据集的聚合特征/得分值，不如将其分解为子群体并监控它们。
- 例如：如果您有欺诈模型，则可能值得根据每个得分示例中使用的设备类型（网络、移动设备等）来拆分监控。
- 还要监控不同人群的原始计数（每天对每个样本评分的数量、百分比是多少等）
适当的特征编码使监控更容易
背景
模型中使用的特征通常经过预处理或编码，以使其能够在某些分类器中使用。
这有时是一个问题，因为很难以可视化或程序化的方式监控复杂的、精心设计的特征，而这些特征在第一眼看起来并不明显。
说明
通过仔细编码（或解码）特征，您可以更轻松地进行监控。这是因为大多数监控框架更适合数值和分类值。如果您使用不同类型的特征（例如词嵌入、地理位置坐标），您可能需要将它们解码（例如分别解码为字符串和城市名称），以便您可以更轻松地分析报表和绘图中的这些特征。
此外，您可能希望监控原始（非预处理、非编码）值，因为这样可以更轻松地与其他团队沟通并在出现问题时进行故障排除。
建议
- 除了特征本身之外，还监控输入值（即不一定是特征本身，而是用于构建特征的信息）。当您对它们应用多个数字转换时，这很有用。
- 只要有可能，将布尔特征值编码为浮点数（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、运营等），我们相信它们足够通用，也适用于其他公司。
