Мониторинг ИИ-систем. Часть 2

В жизни ИИ-системы, медицинской или любой другой, случаются неудачные моменты.

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

К примеру, неправильно заполненный тег части тела в DICOM-файле и некорректная работа модели по фильтрации снимков может привести к возникновению пневмоторакса в стопе:

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

Часть ошибок - вполне себе ожидаемые. Не зря в регистрационном удостоверении любого ИИ-медизделия указаны какие-то характеристики (точность, чувствительность, специфичность), и они не равны единице. Более того, ошибки обычно хорошо кластеризуются по категориям. К примеру, одна из первых версий систем по ишемии часто давала ложноположительные срабатывания на кистозно-глиозных изменениях.

А иногда проблемы возникают не из-за самой ИИ-системы, а из-за изменения свойств входных данных. Распространённый случай - подключение нового оборудования к той же модели.

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

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

Технический мониторинг

В первую очередь любая ML-система - это программное обеспечение. Соответственно ей свойственны все проблемы, которые могут возникать в работе ПО:

• Ошибки при выполнении кода - они же баги.

• Проблемы с железом - сгорела видюха, уборщица вырвала провод.

• Увеличилась нагрузка на систему, выросло среднее или пиковое количество запросов - соответственно, просела скорость работы системы (latency и/или throughput).

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

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

• Автоматические алерты - должны появляться только в том случае, если с какой-то вероятностью нужна реакция.

• Регулярный мониторинг - с какой-то периодичностью определённый человек или команды осуществляют мониторинг.

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

Sentry - мой любимый инструмент ещё с 2014 года, особенно в паре с интеграцией в мессенджер. У каждой команды есть свой канал для алертов в Маттермосте, и прям там можно обсудить ошибку и какие действия нужно предпринять. Отдельно отмечу раздел Performance, который позволяет анализировать время работы разных компонентов системы.

Ещё одна классика - Grafana, которая может кушать информацию из самых разных источников - например, из Prometheus и ElasticSearch. Подходит как для железного мониторинга, так и для сбора статистики о предсказаниях.

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

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

• Работа оборудования - дефекты, артефакты, неправильные настройки.

• Работа лаборанта - некорректная укладка пациента, неверно заполненные теги.

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

Есть два основных способа обнаружения таких сэмплов данных:

• Uncertainty estimation - оценка уверенности модели в своём предсказании. Тут есть куча способов - от простейших (расчёт дисперсии по предсказанным вероятностям классов) до сложных, требующих изменения архитектуры модели или нескольких прогонов исследования через сетку.

• Логирование и детекция аномалий - логируем различные значения, которые появляются в ходе работы нашей системы, например, DICOM-теги, промежуточные значения (объёмы сегментированных целевых органов, яркость изображения) и предсказания системы. И сверху навешиваем какую-нибудь детекцию аномалий - да хоть алерты по порогам значений.

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

С точки зрения инструментов тут отлично справляется всё тот же Sentry - если при обработке исследования сработало одно из правил, посылаем алерт. В зависимости от ситуации при этом обработка либо продолжается, либо клиенту сразу отдаётся ошибка.

Кликнув на такой алерт, можно провалиться в Сентри и узнать айдишник исследования, который в свою очередь можно ввести на нашей платформе, сделанной на Streamlit. Он найдёт это исследование среди всех БД и даст ссылку на веб-вьюер.

Иногда исследование не является дефективным или редким, но модель при обучении не сталкивалась с такими картинками.

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

Мониторинг дрифтов

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

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

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

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

Мониторинг качества работы ML-модели

Так сказать, last but not least - сама модель (модели) или какие-то компоненты системы (препроцессинг, постпроцессинг) могут работать неправильно и это приводит к ошибкам - ложноположительным и ложноотрицательным срабатываниям. Конечно, мы получаем обратную связь от клиентов - от кого-то чаще, от кого-то очень редко, но очень желательно и самим иметь представление об онлайн-качестве работы системы. Особенно критично это в периоды после новых релизов.

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

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

Работа с инцидентами

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

Текущие проблемы

Основные проблемы с мониторингом сейчас связаны с деплоем в регионах.

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

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

При этом выражу респект - в некоторых регионах очень активно идут на встречу, слышат фидбек, исправляют ошибки. Ну и в любом случае у нас всё сильно лучше, чем в Индии =)

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