Коллега вчера разместил в канале для обмена знаниями пару любопытных статей про тестирование 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