Утечки данных, реальные модели и путь к production AI в здравоохранении
Иллюстрация Luky Triohandoko на Unsplash
Моя первая предсказательная модель в здравоохранении выглядела как большой успех.
Она ответила на деловой вопрос. Показатели производительности были сильными. Логика была чистой.
Она также спектакулярно бы провалилась в production.
Этот урок изменил то, как я думаю о data science и что необходимо для успеха в здравоохранении в эпоху AI.
Оглядываясь назад, этот сбой повторялся на протяжении всей моей карьеры, но он был критически важен для моего роста и успеха как data scientist'а: сложная модель в notebook не стоит ничего, если вы не понимаете среду, в которой она должна работать.
Data Analyst
После трёх изнурительных месяцев поиска первой работы в реальном мире, на рынке с растущим спросом на data специалистов, но также переполненном талантами, я наконец-то получил свой первый большой шанс. Я получил позицию начальной data analyst в команде Business Intelligence крупной сетевой больницы. Было так много всего, что нужно было узнать. Огромным препятствием, с которым придётся столкнуться многим, кто хочет войти в сферу healthcare data, было изучение всех тонкостей Epic — крупнейшего провайдера EHR (электронных медицинских записей) по доле рынка. Работать с SQL на чрезвычайно сложных данных EHR было непросто. В течение первых нескольких месяцев я полагался на своих старших коллег при написании SQL-запросов для анализа. Это меня расстраивало: как я мог только что закончить степень магистра в области статистики и всё ещё испытывать трудности с освоением SQL-логики?
Ну, с практикой (много практики) и терпением коллег (много терпения) всё в конце концов начало становиться ясным. По мере того, как я становился увереннее, я погрузился в мир Tableau и создания дашбордов. Я увлёкся процессом создания эстетически привлекательных дашбордов, рассказывающих data stories, которые очень необходимо было рассказать.
Иллюстрация Luky Triohandoko на Unsplash
На протяжении первого года мой менеджер был чрезвычайно поддерживающим, регулярно проверяя мой прогресс и спрашивая о моих карьерных целях и том, как она может мне помочь их достичь. Она знала, что мой опыт в школе был более техническим, чем ad-hoc анализы, которые я делал как начальный data analyst, и что я хотел создавать предсказательные модели. В горько-сладком завершении моей первой главы она предложила перевести меня в другую команду, чтобы дать мне этот опыт. Эта команда была Advanced Analytics. И я должен был стать Data Scientist'ом.
Data Scientist I
С первого дня я работал в тесном сотрудничестве с гуру data science, который глубоко разбирался в здравоохранении и имел технические возможности, чтобы создавать удивительные продукты и прокладывать путь для нашей небольшой команды. Он был первым в нашей системе, кто разработал пользовательскую предсказательную модель и запустил её в production среду, генерируя оценки пациентов в реальном времени. Эти оценки использовались в клинических рабочих процессах. Когда мой менеджер спросила меня о моих профессиональных целях на предстоящий год, я дал немедленный и уверенный ответ: я хотел запустить пользовательскую предсказательную модель в production.
Я начал с нескольких POC (Proof of Concept). Моя первая модель была линейной логистической регрессионной моделью, которая пытался предсказать вероятность осложнений от диабета. Хотя это был хороший первый попыт, мой подход к выборке данных был совершенно неправильным, и в peer review мой коллега указал на это. Один из ключевых уроков, которые я усвоил при первой попытке создания предсказательной модели в здравоохранении, был:
При сборе данных для обучения предсказательной модели крайне важно имитировать условия, контекст пациента и рабочий процесс, в которых модель будет использоваться в production среде.
Пример: вы не можете просто собрать текущие лабораторные значения каждого пациента и использовать их в качестве признаков модели. Если вы ожидаете, что модель будет делать предсказания, скажем, через 15 минут после прибытия в отделение неотложной помощи, вам нужно это учитывать. Таким образом, при сборе двух лет исторических данных для обучения модели вам нужно собрать лабораторные значения каждого пациента такими, какими они были через 15 минут после прибытия, то есть на момент их имитируемого времени предсказания, а не такими, какими они являются сегодня/в настоящее время. Неспособность сделать это создаёт модель, которая может работать лучше в POC, чем в real-time production среде, потому что вы даёте модели доступ к данным, которые не были бы доступны ей во время предсказания — концепция, известная как утечка данных.
Урок усвоен, я был готов попробовать снова. Я потратил следующие несколько недель на разработку модели для предсказания неявок на приёмы. Я очень тщательно подошёл к сбору данных, использовал более надёжный и мощный алгоритм — XGBoost, и снова дошёл до этапа peer review. AUC модели (Area Under the Receiver Operating Characteristic curve) был потрясающим, находился в низких 0.9-х, значительно превосходя ожидания всех по модели неявок. Я чувствовал себя непобедимым. Затем всё рухнуло. Во время глубокого анализа необычайно сильной производительности я заметил, что наиболее важный признак — это время запланированного приёма. Удалите этот признак, и AUC упадёт в середину 0.5-х, что означает, что предсказания модели практически не лучше случайного угадывания. Чтобы расследовать это странное поведение, я переключился на SQL. Вот оно было. В базе данных каждый пациент, который не пришёл на приём, также имел время запланированного приёма в полночь. Какой-то процесс обработки данных ретроспективно изменил время приёма всех пациентов, которые никогда не завершили свой приём. Это дало модели почти идеальный признак для предсказания неявок. Каждый раз, когда у пациента был приём в полночь, модель знала, что этот пациент не придёт. Если бы эта модель попала в production, она бы делала предсказания за недели до предстоящих приёмов и не имела бы этой магической особенности для повышения своей производительности. Утечка данных, мой заклятый враг, вернулась преследовать меня. Мы пробовали неделями спасать производительность, используя творческую feature engineering, большие наборы данных для обучения, более интенсивные процессы обучения — ничего не помогло. Эта модель не попадёт в production, и я был разбит.
В конце концов я нашёл свой ритм. Мой первый большой успех с предсказательной моделью также имел забавное имя: DIVA модель. DIVA расшифровывается как Difficult Intravenous Access (сложный венозный доступ). Модель была разработана для уведомления медсестёр о том, что у них могут быть трудности при установке внутривенных катетеров определённым пациентам, и они должны обратиться в IV-команду для установки. Цель была уменьшить количество неудачных попыток установки капельницы, повысить удовлетворённость пациентов и снизить осложнения, которые могут возникнуть из-за таких неудач. Модель работала хорошо, но не подозрительно хорошо. Она прошла peer review, и я разработал скрипт для развёртывания её в production среде — процесс, намного более сложный, чем я мог себе представить. IV-команде понравился их новый инструмент, и модель использовалась в клинических рабочих процессах по всей организации. Я достиг своей цели — запустить модель в production, и я был в восторге.
Иллюстрация Round Icons на Unsplash
Data Scientist II
После успешной реализации ещё нескольких моделей меня повысили до Data Scientist II. Я продолжал разрабатывать предсказательные модели, но также выделил время для изучения постоянно растущего мира AI. Вскоре спрос на AI решения увеличился. Наш первый официальный AI проект был внутренним вызовом отдела, где мы использовали языковые модели для автоматизированного резюмирования финансовых отчётов публично торгуемых компаний. Этот проект, как и большинство других AI-проектов, был довольно отличен от типичной разработки ML моделей, к которой я привык, но разнообразие приветствовалось. Мне было так весело погружаться в мир ETL процессов, эффективного prompting и автоматизации. Хотя мы только начинаем осваиваться с AI инициативами, я в восторге от новых типов деловых проблем, которые мы теперь можем решать.
Моя роль как data scientist'а эволюционировала по мере совершенствования AI систем. Разработка DS/ML и AI решений требует значительно меньше технической работы.