Как отслеживать качество и целостность данных

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

Что может пойти не так с данными?

Есть два типа проблем с данными. Проще говоря:
1) что-то не так с самими данными; или
2) данные изменяются из-за изменения среды.

Начнем с первой категории. Одного его много.

# 1 Проблемы с обработкой данных

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

Возьмем маркетинговый пример.

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

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

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

Этот конвейер использует несколько источников данных. И каждый из них обслуживает другой функциональный владелец. Неплохая возможность поиграть с этим!

Вот неполный список возможных неприятностей:

  • Неверный источник. Конвейер указывает на старую версию маркетинговой таблицы или существует нерешенный конфликт версий.
  • Утерян доступ. Кто-то переместил таблицу в новое место, но не обновил разрешения.
  • Плохой SQL. Или не SQL. Все, что вы используете для запроса данных. Эти JOINS и SELECT могут хорошо работать до первого усложнения. Допустим, пользователь пришел из другого часового пояса и сделал действие «завтра»? Запрос может не соответствовать.
  • Обновление инфраструктуры. У вас есть новая версия базы данных и автоматическая генеральная уборка. Пробелы заменены подчеркиванием, все имена столбцов в нижнем регистре. Все выглядит нормально, пока ваша модель не захочет рассчитать свою обычную характеристику как «Доход за последний месяц / Общий доход». С жестко заданными заголовками столбцов. Ой!
  • Неработающий код функции. Осмелюсь сказать, что код для анализа данных часто не является производственным. Он может выйти из строя в крайних случаях. Например, промо-скидки на обучение никогда не превышали 50%. Затем маркетинг вводит «бесплатное» предложение и впервые набирает 100%. Код некоторой зависимой функции внезапно теряет смысл и возвращает отрицательные числа.

Когда обработка данных идет плохо, код модели может просто вылететь. По крайней мере, вы быстро узнаете о проблеме. Но если в вашем коде Python есть предложения «Попробуйте… кроме», он может выполняться при неправильном и неполном вводе. Все последствия твои.

В рассмотренном нами промо-примере есть пакетный вывод. Это менее драматично. У вас есть право на ошибку. Если вы вовремя поймаете проблему с конвейером, вы можете просто повторить прогон модели.

В моделях потоковой передачи с высокой нагрузкой проблемы обработки данных умножаются (например, электронная коммерция, игры или банковские транзакции).

# 2 изменение схемы данных

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

Вдобавок к этому автор изменения часто не осознает воздействия. Или что там вообще существует какая-то модель.

Вернемся к промо-примеру.

Однажды операционная группа колл-центра решает привести в порядок CRM и обогатить информацию, которую они собирают после каждого звонка клиента.

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

Теперь это выглядит аккуратно!

Но не так с моделью.

С технической точки зрения это означает потерю сигнала.

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

Эта боль хорошо известна любому, кто занимается каталогами.

Например, в прогнозировании спроса или рекомендациях по электронной коммерции. Часто у вас будут сложные функции, основанные на типе категории. Скажем, «ноутбук» или «мобильный телефон» от слова «электроника». Это дорого. Давайте сделаем это функцией. «Чехол для телефона» входит в «аксессуары». Это вроде как «дешево». Мы тоже воспользуемся этим.

Затем кто-то реорганизует каталог. Теперь и «мобильный телефон», и «чехол для телефона» относятся к категории «мобильный». Совершенно другая категория, с другой интерпретацией. Модели нужно будет изучить все заново или подождать, пока кто-нибудь не объяснит, что произошло.

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

Еще несколько примеров:

  • Обновление исходной бизнес-системы приводит к изменению единиц измерения (например, Цельсия на Фаренгейт) или форматов дат (ДД / ММ / ГГ или ММ / ДД / ГГ?)
  • Новые функции продукта в приложении добавляют телеметрию, на которой модель никогда не обучалась.
  • Появился новый сторонний поставщик данных или API, или объявлено об изменении формата.

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

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

# 3 Потеря данных в источнике

Данные не только меняются. Он также может быть утерян из-за неисправности в самом источнике.

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

Такие сбои могут повлиять только на часть данных. Например, пользователи из одного региона или определенной операционной системы. Это затрудняет обнаружение. Если другая (должным образом отслеживаемая!) Система не полагается на тот же источник данных, сбой может остаться незамеченным.

Что еще хуже, поврежденный источник все еще может предоставлять данные. Например, сломанный датчик температуры вернет последнее измерение как постоянное значение. Это трудно заметить, если вы не отслеживаете «необычные» числа и закономерности.

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

# 4 Сломанные модели разведки и добычи

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

Это также означает: неверный прогноз одной модели - это искаженный признак другой модели.

Возьмите систему рекомендаций по содержанию или продукту.

Сначала он может спрогнозировать популярность данного продукта или предмета. Затем он дает рекомендации разным пользователям с учетом предполагаемой популярности.

Это будут отдельные модели, в основном связанные друг с другом. После того, как элемент будет рекомендован пользователю, он с большей вероятностью будет нажат, и, следовательно, с большей вероятностью будет замечен как «популярный» в первой модели.

Более технологичный пример: автомобильная навигационная система.

Во-первых, ваша система строит возможные маршруты. Затем модель предсказывает ожидаемое время прибытия для каждого из них. Затем другая модель оценивает варианты и выбирает оптимальный маршрут. Что как бы влияет на реальные пробки. Как только автомобили следуют по предложенным маршрутам, это создает новую дорожную ситуацию.

Другие модели логистики, маршрутизации и доставки часто сталкиваются с той же проблемой.

Эти связанные системы несут очевидный риск: если что-то не так с одной из моделей, вы получите взаимосвязанный цикл проблем.

Мониторинг качества и целостности данных

Как мы видим, множество вещей может пойти не так с входными данными для модели машинного обучения.

Мы хотим, чтобы этого никогда не происходило, но давайте будем реалистами. Поэтому наша цель - поймать их вовремя.

Обычно надежность и согласованность данных относятся к сфере инженерии данных. У вас могут быть даже системы проверки или мониторинга на уровне базы данных. Есть ли еще что-нибудь, за чем нужно следить?

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

Код обработки функций также является отдельным движущимся элементом для отслеживания. Это требует специальной настройки.

Итак, с точки зрения качества и целостности данных MLOps соответствует DataOps. Нам лучше перепроверить.

Есть несколько вещей, на которые стоит обратить внимание:

# 1 Модельные звонки

Первый вопрос, на который нужно ответить, - работает ли эта модель. Для этого посмотрите на количество ответов модели. Это простая, но полезная проверка, которую можно добавить к мониторингу программного обеспечения.

Почему? Сама служба может быть работоспособной, но не модель. Или вы можете полагаться на резервный механизм, например бизнес-правило, чаще, чем планировалось.

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

Анализируя количество обращений к модели, можно легко обнаружить, когда что-то очень не так.

В зависимости от модельной среды вам может потребоваться проверять запросы и ответы отдельно. Была ли модель не запрошена (например, из-за сбоя виджета рекомендаций) или не ответила (например, истекло время ожидания модели, и вместо этого нам пришлось использовать статическую рекомендацию)? Ответ укажет, где вам следует начать отладку.

Теперь давайте посмотрим на данные.

# 2 Схема данных

Как мы объяснили выше, схемы данных могут измениться. Будь то плохая практика или лучшие намерения; мы хотим его обнаружить.

Наша цель - узнать, когда функции удаляются, добавляются или изменяются.

Самый простой способ - выполнить поэтапную проверку и исследовать:

1 / Если набор функций остается прежним. В случае табличных данных: сколько столбцов там? Что-то отсутствует или что-то новое?

2 / Если типы данных объекта совпадают. Мы где-то получили категориальные значения вместо числовых? Например, у нас были числовые признаки от 1 до 10 в данном столбце. Теперь, когда мы запрашиваем его, мы видим такие значения, как «низкий», «средний» и «высокий». Мы должны уловить это.

В конце концов, вам нужно быстрое сводное представление о том, что входящий набор данных имеет ожидаемую форму.

# 3 Отсутствующие данные

Мы также хотим обнаружить любые недостающие данные.

Часто существует приемлемая доля отсутствующих значений. Мы не хотим реагировать на каждую пустую запись. Но мы хотим сравнить, остается ли уровень недостающих данных в пределах «нормального» диапазона как для всего набора данных, так и для отдельных функций. Утрачены ли какие-либо важные функции?

Это важно иметь в виду, поскольку отсутствующие значения могут быть разными. Иногда они пустые, а иногда - «неизвестно» или «999». Если вы выполните упрощенную проверку отсутствующих функций, вы можете пропустить другие. Лучше всего сканировать стандартные выражения отсутствующих данных, такие как «N / A», «NaN», «undefined» и т. Д. Проведение периодической проверки собственными глазами - тоже неплохая идея.

Если у вас ограниченное количество функций, вы можете визуализировать их все на одном графике. Вот как мы это сделали, выделив цветом долю пропущенных значений:

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

Один полезный совет: выделите ключевые движущие факторы. Вы можете сделать это на основе важности функций модели или значений SHAPley. Или комбинируйте любой метод со знаниями в вашей предметной области по тому, что имеет значение.

Идея состоит в том, чтобы настроить разные политики мониторинга. Для запуска модели вам всегда нужны критически важные функции. Со вспомогательными отсутствие - это не шумиха. Вы просто делаете заметку, а затем исследуете ее с владельцем данных.

# 4 Ценности характеристик

Наличие данных не означает, что они верны.

Примеры:

  • После провала в работе с Excel столбец «возраст» имеет значения от 0,18 до 0,8 вместо 18-80.
  • Физический датчик ломается и показывает какое-то постоянное значение в течение недели.
  • Кто-то уронил знак минус во время расчета функции, и вы видите отрицательные показатели продаж.

Во всех случаях модель работает, данные доступны - но повреждены.

Чтобы обнаружить это, вы хотите отслеживать статистику и распределение функций.

1 / Диапазон значений функции. Для числовых функций проверьте, находятся ли значения в разумных пределах. Для категориальных атрибутов определите список возможных значений и следите за новинками.

Как это сделать?

  • Вы можете напрямую определить свои ожидания (минимальные и максимальные диапазоны или возможные значения в данном столбце), посмотрев на распределение обучения.
  • Или положитесь на здравый смысл: мы знаем возможные значения «возраста» или «наружной температуры».
  • Если есть больше контекста, вы можете привлечь экспертов в предметной области, чтобы определить «нормальный» для конкретных входных данных.

Это также помогает указать, когда значения NULL разрешены явно.

2 / Статистика по ключевым характеристикам. Что касается числовых характеристик, вы можете посмотреть на среднее, среднее, минимальное и максимальное соотношение, квантили.

Последний поможет поймать такие случаи, как этот сломанный датчик. Формально он остается в пределах диапазона, но измерения полностью статичны:

Для категориальных входов вы можете проверить их частоту. Если вы работаете с текстами, эквивалентом может быть, например,% словарного запаса.

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

# 5 Обработка функций

Еще один аспект, который следует учитывать, - это где проводить проверки данных.

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

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

Например, мы прогнозируем отток клиентов мобильного оператора.

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

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

Подводя итоги

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

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

Конечно, на этом проблемы с данными не заканчиваются. В следующем посте мы углубимся в дрейф данных и концепций.

Первоначально опубликовано на https://evidentlyai.com.

В Evidently AI мы создаем инструменты с открытым исходным кодом для анализа и мониторинга моделей машинного обучения. Ознакомьтесь с нашим инструментом обнаружения дрейфа данных на Github.

Хотите оставаться в курсе? Подпишитесь на наши обновления и новости о продуктах, или присоединитесь к Twitter и Linkedin, чтобы получить больше информации о производственном машинном обучении, или присоединитесь к нашему сообществу Discord, чтобы общаться и общаться.