Тестирование ML-систем

Коллега вчера разместил в канале для обмена знаниями пару любопытных статей про тестирование ML-систем (раз и два). Тема мне крайней близкая и интересная — вот, например, моё выступление на митапе LeanDS про тестирование новых версий ML-систем, а вот видео с прошлого датафеста про оценку медицинских ML-систем.

Посты достаточно интересные, порекомендовал бы их прочитать, посмотреть информацию по ссылкам и подумать над тем, что у вас уже есть, а что можно было бы внедрить. А я бы хотел обсудить и развить две темы, связанные с тестированием — множественное тестирование и тестирование данных.

Множественное тестирование

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

Разметка рентгена ОГК двумя разными врачами
Разметка рентгена ОГК двумя разными врачами

Верифицированных данных (где диагноз подтверждён другим анализом или событием) в медицине немного, поэтому приходится жить с тем, что на одно исследование у нас обычно есть 2-5 вариантов разметки. Как считать метрики качества какой-нибудь модели детекции или сегментации в таком случае?

  • Объединять несколько разметок в одну с помощью разных эвристик и считать метрики по новой синтетической разметке.

  • Считать метрики независимо по каждому врачу и усреднять.

  • Считать worst-case сценарий — по разметке, которая наиболее далеко от предсказания.

  • Считать best-case сценарий — по разметке, которая наиболее близко к предсказанию.

А лучше всего — использовать все варианты сразу и получать целый набор метрик, который позволяет получить более полное представление о границах качества модели. Эта идея множественного тестирования прекрасно распространяется и на другие сценарии. Например, мы можем разделить валидационный датасет по разным характеристикам — источник данных, пол пациента, размер изображения, распределение таргета; и считать метрики по этим сабсетам. Таким образом, у нас образуется несколько виртуальных валидационных сетов. Можно создавать и отдельные, непересекающиеся с основным датасеты — к примеру, регресионный набор данных, состоящий из примеров, где мы когда-то ошибались, а потом сумели пофиксить проблему. Или демо-набор, состоящий из примеров, которые используются для демонстрации возможностей работы системы клиентам.

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

В отдельную подкатегорию можно вынести тесты на робастность и устойчивость к атакам.

  • Устойчивость к adversarial атакам. Достаточно редкий и специфический тест. В этом случае мы пытаемся в режимах white box (полный доступ к модели) и black box (доступ только к предсказаниям) подобрать некоторую трансформацию входных данных, которая кардинально изменит аутпут системы.

  • Робастность и стабильность системы. Можно различным образом аугментировать входные данные и измерять изменения в предиктах, создавать специальные тестовые датасеты с редкими или out-of-domain случаями. При релизе новой версии полезно также сравнить её предикты с предсказаниями предыдущей версии. Если это не какое-то глобальное улучшение модели, резкие сдвиги должны вызывать подозрения. Сильные изменения на конкретных примерах также можно проинспектировать вручную.

Дата-тестирование

Без чего невозможно машинное обучение? Конечно, без данных — это наш бич и бог. Тем более удивительно, что тестированию их качества не всегда уделяется большое внимание. Тестировать можно как обучающие данные, так и входные данные на проде. Начнём с проверок качества, специфичных для обучающих и валидационных данных:

  • Тесты на лик. Думаю, тут особо объяснять не надо, наверное, каждый дата-сайнтист в своей жизни сталкивался с разными явными и неявными дата-ликами между трейном и тестом. При разработке реальных больших ML-систем бывают случаи, которые совсем тяжело ловить без автоматических тестов — например, пример, который использовался для претрейна сети, внезапно всплывает в тестовой выборке этапа дальше по пайплайну, который использует ту самую сеть для генерации фич. Уф.

  • Тесты на техническое качество данных. Проставлены ли все теги у исследований в базе данных, есть ли разметка для всех исследований. Короче, те проверки качества данных, которые скрываются за разными большими словами — достоверность, полнота, актуальность, доступность, взаимосвязанность, консистентность… Для части таких проверок можно использовать простые ML-модельки. Например, можно распознавать не флипнута ли разметка горизонтально или вертикально относительно снимка из-за какого-нибудь свеженького бага в ETL-пайплайне.

  • Тесты на качество разметки. Некоторые косяки разметки вполне можно ловить автоматически. К примеру, иногда крепкая рука врачей дрожит и кликает не на тот класс объекта. На снимке снизу врач разметил перелом размером с лёгкое. Взгляд на гистограмму размеров объектов класса «Перелом» в обучающей выборке позволяет понять, что тут могла закрасться ошибка… Такие снимки можно автоматически помечать для последующего ревью.

Сломанное лёгкое
Сломанное лёгкое
Обычно ломают небольшую часть кости
Обычно ломают небольшую часть кости

Некоторые дата-тесты становятся даже более актуальными на продакшне:

  • Out-of-Distribution Detection. Никто и никогда не сможет вам гарантировать, что в систему для поиска рака молочной железы вам не засунут рентген канистры, тазобедренного сустава или фото котика. Сюда же можно отнести и менее экзотические случаи — плохое качество изображения, частично обрезанный орган на снимке, точки и пятна от пыли на рентген-аппарате. Все эти кейсы можно и нужно отлавливать автоматически — как классическими способами, так и ML-модельками и DL-головами.

Острая форма заболевания
Острая форма заболевания
  • Data Drift. На продакшне случается всякое — подключилась новая больница, дети вернулись с каникул, поменяли настройки оборудования. Явные и резкие случаи можно ловить с помощью Out-of-Distribution модулей, но случаются и более плавные и неявные изменения распределения входных данных. Для целей мониторинга и алертинга таких случаев есть много разного софта — Evidently AI, whylogs, Torchdrift. Можно мониторить распределение входных фич (пикселей), эмбеддинги сеток, предсказания. Можно заранее тестировать робастность системы к таким изменениям (см. предыдущую секцию).

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

Если вы хотите узнать ещё больше об организации процессов ML-разработки, подписывайтесь на наш Телеграм-канал Варим ML


ссылка на оригинал статьи https://habr.com/ru/post/680822/

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *