В жизни ИИ‑системы, медицинской или любой другой, случаются неудачные моменты.
Часть таких ситуаций — непредвиденные ошибки. Да, все разработчики понимают, что рано или поздно что‑то пойдёт не так, но случается это всегда по‑разному и иногда в самые неподходящие моменты.
К примеру, неправильно заполненный тег части тела в 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.
