Скорее всего вы сталкивались с этим. Вы создали модель машинного обучения (ML) и обучили ее на большом количестве данных. Результаты валидации выглядят очень многообещающе, поэтому вы отправляете модель на подготовку к производству, и вдруг что-то не так. Модель не провалилась полностью, но ваши показатели не соответствуют тому, что вы наблюдали на этапе обучения и оценки. Пришло время выделить время для проверки работоспособности, чтобы вы могли выяснить, что пошло не так, и как это исправить.

Но если бы вы могли автоматизировать эту проверку работоспособности, вы могли бы просто… исправить это. Это может сэкономить вам (и всем в вашей команде) много энергии и стресса.

В Intuit мы развертываем модели машинного обучения в ряде критически важных систем на нашей платформе финансовых технологий, чтобы предоставлять персонализированные возможности ИИ более чем 100 миллионам потребителей и клиентов малого бизнеса с помощью TurboTax, Credit Karma, QuickBooks и Mailchimp (с диалоговым ИИ, рекомендации, а также безопасность, риск и мошенничество, и это лишь некоторые из них). Чтобы упростить развертывание, уменьшить вероятность человеческой ошибки и обеспечить ожидаемое поведение моделей, от разработки до производства, мы используем автоматическую проверку работоспособности.

Проверка работоспособности модели: выявление источников систематических ошибок или предвзятости на этапе подготовки к производству

Крайне важно убедиться, что модели машинного обучения надежны и точны, прежде чем развертывать их в рабочей среде. Автономные проверочные тесты помогают выявлять проблемы проектирования, такие как переоснащение или недооснащение. Предварительные среды могут по-прежнему вызывать сбои или систематические ошибки, которые делают модель непригодной для производства. Эти проблемы называются смещением ML, когда модель ML дает систематически предвзятые результаты в пользу или против одной категории входных данных модели. Например:

  • Смещение выборки, вызванное различиями между наборами данных, используемыми для автономного обучения и проверки, по сравнению с онлайн-наборами данных, с которыми ваша модель сталкивается на стадии подготовки.
  • Смещение прогноза, когда разница между средним прогнозируемым результатом и средним наблюдаемым результатом в реальном мире различается между наборами данных в автономном и онлайн-режиме.
  • Смещение распределения прогнозов, когда распределение онлайн-прогнозов не соответствует распределению меток в наборе для обучения и проверки. Например, если модель выдает нормально распределенные прогнозы на этапе обучения и проверки, мы ожидаем, что распределение будущих значений также будет соответствовать нормальному распределению.

Проверка работоспособности модели машинного обучения – это набор тестов, выполняемых в предпроизводственной среде для выявления подобных систематических ошибок и предубеждений, чтобы вы могли убедиться, что модели работают должным образом, прежде чем развертывать их в рабочей среде. В Intuit мы рассматриваем обнаружение и предотвращение предвзятости модели как неотъемлемую часть оценки и развертывания каждой модели.

Четыре основных шага проверки работоспособности

Типичная проверка работоспособности машинного обучения должна включать четыре шага, изображенных на рисунке 1:

1. Убедитесь, что оценки онлайн-моделей попадают в выходное хранилище. Этот шаг самый простой. В правильно настроенной системе мы можем ожидать, что оценки модели опустятся до выходного местоположения. Мы можем проверить это, успешно извлекая оценки модели из ожидаемого результата. Например, если предполагается, что оценки модели должны быть записаны в таблицу Hive, мы можем выполнить простой SQL-запрос для получения прогнозов.

В противном случае причиной может быть одна из следующих причин:

  • Отсутствие доступа или неадекватное разрешение на доступ к выходному хранилищу.
  • Невозможность чтения входных данных из-за прав доступа.
  • Ошибки в конвейере машинного обучения, из-за которых модель не дает результатов.
  • Отказ инфраструктуры.
  • Неправильная интеграция между конвейером данных и службой машинного обучения.

2. Повторная оценка с помощью офлайн-модели. Как только мы подтвердим, что наша модель выдает прогнозы, следующим шагом будет передача выборочного набора входных онлайн-данных в офлайн-модель и обеспечение того, чтобы мы получили тот же результат. На этом этапе рекомендуется перепроверить входные данные, чтобы убедиться, что ваша тестовая выборка представляет все категории, которые ваша модель намеревается предсказать, и эти выборки охватывают весь диапазон оценок. Например, если ваша выборка состоит из 100 электронных писем для проверки на спам, и все они относятся к классу, не относящемуся к спаму, то данные вашей выборки сомнительны, а результаты прогнозирования вводят в заблуждение. Если офлайн- и онлайн-оценки не совпадают для репрезентативной выборки входных данных, мы углубляемся в сделанные прогнозы.

Обратите внимание, что, хотя обычно мы ожидаем одинакового прогноза для заданного набора входных данных в онлайн- и офлайн-моделях, в некоторых ситуациях может быть допустим определенный уровень различий. Например, незначительная разница между офлайн- и онлайн-предсказаниями не будет тревожным сигналом для таких алгоритмов, как байесовские нейронные сети, которые состоят из стохастического компонента, вносящего случайность в процесс предсказания. Точно так же различия между машинными библиотеками и зависимостями могут привести к приемлемым различиям в результатах моделирования.

3. Сравните оценку онлайн-модели с оценкой автономной модели. На этом этапе мы проверяем и подтверждаем статистические характеристики оценки онлайн-модели по сравнению с оценками в автономном наборе данных, а также с набором данных для тестирования и проверки, используемым перед развертыванием. к предпродакшену. Если модель работает правильно, мы ожидаем, что распределение прогнозов в онлайн-модели будет следовать очень похожему шаблону, что и автономные прогнозы и прогнозы обучения/тестирования. Большое несоответствие (например, 20-процентная разница между прогнозами в интервалах оценки) — это красный флаг того, что модель не работает должным образом.

Если на этом этапе выявляются существенные различия между онлайн- и офлайн-моделями, нам необходимо проверить наши входные данные на наличие потенциальных проблем.

4. Проверьте входные данные. Если мы обнаружим существенные различия между онлайн- и офлайн-моделями, нам нужно проверить наши входные данные на наличие потенциальных проблем. Это включает в себя изучение характеристик входных функций, которые подаются в онлайн-модель, и сравнение их с характеристиками данных обучения/тестирования/проверки. Проверки здесь могут включать:

  • Проверка того, что все функции доступны во входных данных. Все функции, связанные с весами, способствуют получению оценок прогнозирования. Отсутствующая функция может исказить фактическую оценку.
  • Проверка онлайн-хранилища, чтобы убедиться в отсутствии проблем, которые могут негативно повлиять на входные данные. Это может включать в себя права доступа, настройки времени ожидания, проверку местоположения данных и т. д.
  • Проверка доли нулевых значений для функций. Например, если мы наблюдали 10% нулевых значений в нашем наборе для обучения/проверки, то пропорция 20% нулевых значений может создать проблему с самой моделью или вышестоящим сервисом.
  • Проверка распределения значений функций и сравнение их с их аналогами в наборе для обучения/тестирования/проверки. Распределение значений должно иметь очень похожие формы для каждой функции. Большое отклонение указывает на то, что входные онлайн-данные неупорядочены в конвейере данных и требуют устранения неполадок.

На рис. 2 показаны две диаграммы для сравнения распределения категориальных признаков и скалярных признаков. Глядя на Categorical_Feature_1 слева, мы видим, что распределение четырех категорий в онлайн-данных близко по сравнению с тестовыми данными. Таким образом, мы можем быть уверены, что наши тестовые данные представляют собой онлайн-данные. Аналогичным образом, для Continuous_Feature_1 справа мы видим, что шаблон распределения для онлайн-данных и тестовых данных следует аналогичному шаблону.

Автоматизируйте процесс, чтобы сделать его еще более разумным

Чтобы сэкономить время и уменьшить количество человеческих ошибок, мы можем внедрить этот процесс проверки работоспособности в рабочий процесс автоматизации. Инструменты, доступные для этого процесса, зависят от технологического стека вашей организации. Например, каждый шаг можно вызвать с помощью функции шага в среде AWS, или процесс можно реализовать, создав конвейер Kubeflow или задание Apache Airflow, в котором все шаги будут объединены в цепочку. Каждый шаг также может быть реализован в виде скрипта Python или PySpark. Как бы вы ни развернули тестирование, вы захотите создать исчерпывающий отчет, содержащий результаты анализа каждого шага. Этот процесс может выполняться в фоновом режиме, что значительно экономит время, необходимое для выполнения этих проверок вручную, и значительно снижает вероятность человеческой ошибки.

Оптимизация разработки и развертывания модели

Модели машинного обучения являются важнейшим инструментом для повышения простоты использования и безопасности широкого спектра приложений, ориентированных на потребителей и предприятия. Наличие автоматизированной проверки работоспособности модели может помочь командам более уверенно развертывать свои модели в рабочей среде, гарантируя, что модели ведут себя так, как задумано, и сокращая ресурсы, необходимые для работы с этими моделями, когда их поведение не соответствует ожиданиям.

В результате команды могут сосредоточить свои усилия на разработке новых и более совершенных моделей, которые они затем могут развернуть на благо своих конечных пользователей.

Большое спасибо команде!

Я хотел бы поблагодарить Daniel Viegas, Andreas Mavrommatis, Richard Chang, Lin Tao и April Liu за их неоценимый вклад!