Уроки, извлеченные из создания и развертывания продукта машинного обучения с нуля

Уроки, извлеченные из создания и развертывания продукта машинного обучения с нуля

Рентгенологические отчеты могут быть трудны для интерпретации немедицинскими работниками, поскольку они полны технического жаргона. Одной из уникальных услуг, которую мы предоставляем нашим участникам в Ezra, является исчерпывающий отчет, написанный нашими лицензированными медицинскими работниками (MPs), объясняющий все медицинские выводы, отмеченные рентгенологом, переведенный на удобный для чтения, нетехнический язык. Кроме того, наша медицинская команда включает в себя список возможных дальнейших действий для каждого заметного результата в рентгенологическом отчете, в зависимости от его серьезности. Этот всеобъемлющий отчет Ezra Report дает нашим участникам душевное спокойствие и заботу, которых они заслуживают.

Я присоединился к Ezra, чтобы создать решение на основе машинного обучения, которое автоматизирует процесс создания отчета Ezra на основе рентгенологических отчетов. В то время, когда я присоединился, процесс был ручным, трудоемким и подверженным ошибкам. Перенесемся в сегодняшний день: с веб-приложением Ezra Reporter, основанным на машинном обучении, медицинская бригада экономит 75 минут на отчете, что повышает производительность на 600%!

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

Обратите внимание, что подробности о приложении и самой модели выходят за рамки этого поста, и основное внимание здесь уделяется обучению на каждом этапе создания сквозного продукта машинного обучения в целом. При этом, чтобы истории и примеры имели смысл, я начну с общего обзора того, что представляет собой продукт Ezra Reporter и какие проблемы он решает.

Что такое Эзра Репортер?

За прошедшие годы медицинская команда Эзры создала внутреннюю базу данных известных медицинских результатов из различных рентгенологических отчетов и письменных фрагментов, объясняющих каждое открытие с точки зрения непрофессионала. Эта постоянно растущая база данных — это то, что члены парламента Эзры используют для создания отчета Эзры на основе входящих рентгенологических отчетов.

На рис. 1 ниже показан рентгенологический отчет МРТ тела. Мы называем текст рентгенологического отчета заключениями, которые могут быть либо из раздела Слепки, либо из раздела "Выводы", который мы называем результатами, не относящимися к оттискам.

На рис. 2 показан соответствующий отчет Ezra, который включает все важные результаты, упомянутые в отчете о радиологии, с четкими пояснениями по каждому выводу. Эти пояснения, называемые фрагментами (каждый фрагмент имеет заголовок и содержание, объясняющее заголовок), извлекаются из базы данных фрагментов. Обратите внимание, что это пример отчета, созданный только в иллюстративных целях.

Ezra Reporter — это веб-приложение, которое принимает радиологические отчеты и выводит предлагаемый отчет Ezra, который может быть просмотрен и отредактирован членами парламента и отправлен участнику.

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

Поймите процесс, который вы хотите улучшить

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

Скройте своих потенциальных пользователей

Я считаю слежку лучшим первым шагом, чем собеседование, потому что на этом этапе вы не знаете, чего не знаете; другими словами, вы недостаточно знакомы с тем, как что-то делается, чтобы знать, какие вопросы задавать. Увидев процесс из первых рук, вы сможете лучше понять его ход, неэффективность и проблемы, для которых вам нужно будет найти решения. Например, перед слежкой за пользователями я не задумывался о порядке выводов (и фрагментов), упомянутых в каждом разделе отчета Эзры. Я просто предполагал, что это будет в соответствии с порядком появления в рентгенологическом отчете. Однако, когда я отслеживал пользователей, я заметил, что они начинают с нижней части отчета и включают результаты показов, а затем поднимаются вверх к верхней части отчета, где были результаты, не связанные с показами. Только в этот момент я задумался над вопросом: «Существует ли определенный порядок выводов и их объяснений и почему?». Я бы не задумался над этим вопросом, если бы не проводил время с пользователями, пока они пишут отчеты.

Если возможно, создайте тень для нескольких пользователей. Это помогает понять изменчивость и различные подходы, которые используют разные пользователи. Например, я заметил, что некоторые пользователи не включают некоторые результаты из рентгенологического отчета, несмотря на то, что у них есть точное совпадение фрагментов, но некоторые делают это. У меня сложилось впечатление, что независимо от местоположения вывода в рентгенологическом отчете, если в базе данных есть соответствующий фрагмент, он должен быть включен в отчет Эзры. Это наблюдение помогло понять, почему некоторые исторические отчеты включали определенные пары выводов и фрагментов, а другие отчеты с теми же выводами — нет. Это также вызвало вопрос, каково ожидаемое поведение решения для машинного обучения в этих случаях?

Чем больше пользователей вы затеняете, тем больше вероятность того, что ваше решение столкнется с пограничными случаями. Например, во время одного сеанса теневого копирования я узнал, что в некоторых случаях, когда в рентгенологическом отчете есть опечатки или неясности, т.е. отчет тела, наши депутаты просят разъяснения от рентгенолога. Затем радиолог отправляет новый отчет с дополнительным разделом Дополнение вверху, соответствующим вопросу MP. В этом случае члены парламента начинают писать отчет Эзры на основе других радиологических отчетов для этого участника, например. Сканирование головы или компьютерная томография в ожидании ответа рентгенолога и добавление секции тела при получении приложения. При этом я обратил внимание на такой сценарий, о котором следует подумать при реализации компонента машинного обучения.

Задавайте вопросы, много вопросов

После наблюдения за пользователями задайте вопросы, основанные на ваших наблюдениях, чтобы определить, какие функции необходимы для вашего решения, а какие — желательно иметь. Подумайте о вопросах, которые помогут вам понять причину различных действий, например. «Почему вы сначала скопировали результаты впечатлений?» или «Всегда ли порядок разделов в Отчете Эзры такой?», «Я заметил, что X включает поиск Y из раздела, не связанного с впечатлением, но вы этого не сделали, почему?»

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

Создать схему текущего процесса

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

Рис.3 иллюстрирует ручной процесс создания отчетов Ezra от начала до конца.

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

1. Средство сканирования отправляет рентгенологические отчеты, которые вручную загружаются в облачное хранилище Ezra.
2. Подробная информация о рентгенологических отчетах, например. имя, доб, тип сканирования и имя заказывающего MP проверяются на соответствие этим данным на платформе Ezra’s Hub. Hub — это веб-приложение, которое содержит всю информацию о приеме, историю болезни, клинические заметки о консультациях и т. д.
3. Отчет Ezra пишется вручную путем копирования/вставки сведений об участнике в документ-шаблон и добавления результатов с нетехническими пояснениями. Объяснения ищутся во внутренней базе данных сниппетов.
4. После того, как отчет Ezra будет завершен, просмотрен и загружен в Hub для доступа участника

Процесс полон рутинных задач, которые можно автоматизировать, например. загрузки и проверки деталей. Кроме того, база данных фрагментов в настоящее время содержит около 1500 фрагментов и продолжает расти. Очевидно, что по мере увеличения размера депутатам становится все труднее запомнить все живущие там сниппеты со всеми их нюансами и понять, какой из них искать.

Подумайте об утонченном процессе

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

Для Ezra Reporter это означало замену ручных и повторяющихся задач автоматизацией, перенос данных в одно место и т. д.

Обратите внимание, что это упражнение очень высокого уровня и поможет вам взглянуть на решение через призму более широкой картины. В нашем случае, например, было слишком рано думать о том, как Hub и Reporter взаимодействуют, но из сеансов пользователей у нас было достаточно информации, чтобы понять, что они должны общаться.

Понимание данных

Что такое ресурсы исторических данных? Где они живут? Как получить к нему доступ? Они структурированы? Они чистые?

Для Ezra Reporter исторические данные представляли собой отчеты Ezra, написанные вручную, и соответствующие отчеты по радиологии в формате pdf, без структуры, хранящейся в облаке. Мне нужно было извлечь результаты из раздела «Результаты МРТ» Ezra Reports и сопоставить их с проанализированным текстом из рентгенологических отчетов. Основная проблема заключалась в том, чтобы найти, какие фрагменты в разделах «Что это значит и рекомендации» связаны с каждым открытием, поскольку мое затенение показало, что между ними не всегда есть карта 1: 1. На рис. 4 ниже показан аннотированный отчет Эзры, иллюстрирующий разделы и ссылки, которые мне нужно было найти в pdf. Ссылки отображаются с теми же цветами блоков, например. фиолетовая рамка вокруг находки «Несколько кист печени…» должна быть соединена с фрагментом «Маленькие кисты печени — карманы…».

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

Стало очевидным, что наше решение должно хранить данные таким образом, чтобы связи между результатами и фрагментами были четкими, и даже если фрагменты редактируются для отчета, чтобы удовлетворить участника, исходный текст должен быть извлекаемым. Для этого мы добавили UUID для каждого фрагмента.

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

Внедрить несколько проверенных прототипов машинного обучения

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

Важно сначала изучить решения, отличные от мл, по двум причинам:

1. Избегайте чрезмерного проектирования. Хотя создание решений машинного обучения для решения проблем может показаться сложной задачей. Тратить время и ресурсы на проблему, имеющую более простые решения, отличные от ML, — ошибка.
2. Повышение базовых показателей производительности. Вы получаете базовые показатели производительности, которые необходимо улучшить с помощью настраиваемых и более сложных решений.

Так что не торопитесь, чтобы изучить и поэкспериментировать с решениями, отличными от ML, которые могут работать для решения вашей проблемы, прежде чем вы начнете инвестировать в ML. Для Ezra Reporter я начал с поиска совпадений между результатами и фрагментами на основе сходства Жаккара, которое равно количеству перекрывающихся слов по длине объединения. Этот простой критерий соответствия работал в простых случаях, но не мог найти соответствия, когда длина предложений была очень разной или предложения имели одинаковую семантику, но использовали разные слова. С помощью этого теста я получил основу для следующих итераций и потребностей, то есть семантического моделирования.

Дизайн

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

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

Разработка презентации рекомендаций по машинному обучению

На это решение повлияло несколько аспектов:

1. Поскольку каждый фрагмент связан с определенным результатом рентгенологического отчета, мы решили усилить связь между ними в Ezra Reporter. Это уменьшит любую двусмысленность в будущем для переобучения модели, поскольку у нас будет четкий набор правильных пар между выводами и фрагментами.
2. Следя за пользователями и просматривая сотни исторических отчетов Эзры, я заметил, что в большинстве случаев каждому выводу соответствует один-два фрагмента; однако в базе данных фрагментов есть много фрагментов по той же теме, которые потенциально могут быть предложены ML. Возврат пользователю всех фрагментов, предложенных ML, и требование принять меры для удаления тех, которые он считает неправильными, будет обременительным для пользователя.

Поэтому мы разработали презентацию предложений машинного обучения, аналогичную ожидаемому шаблону отчета Ezra, каждый раздел тела имеет поле «Выводы» и поле «Фрагменты» внизу. Щелкнув по каждой находке, вы увидите только первый фрагмент, связанный с этой находкой.

На рисунке ниже показано, что для выделенного полужирным шрифтом рентгенологического отчета, обнаружившего «Доброкачественные кисты печени и почек, которые не требуют последующего визуализирующего наблюдения», предложение ML в верхнем фрагменте называется «Киста печени / киста печени». Однако в находке также упоминаются кисты почек. Пользователь может добавить фрагмент, щелкнув нижний знак плюса, который открывает панель поиска с предложениями машинного обучения от первых двух до первых k для этого конкретного результата. Это показано на рис. 6, красный прямоугольник под надписью «Предполагается» — это другой найденный фрагмент ML, соответствующий обнаружению «Доброкачественные печеночные и почечные кисты…»

Проектирование конвейера тестирования

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

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

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

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

Мы учли этот план при разработке общей структуры приложения. На изображении ниже показано, как мы отделили тестирование модели машинного обучения в тестовой среде от остального приложения. Отчеты о радиологических испытаниях отправляются в компонент машинного обучения Ezra Reporter для вывода через маршрутизатор, метрики вычисляются и сохраняются, а предполагаемые результаты отправляются обратно. Компоненты, отличные от мл, подробно не демонстрируются, поскольку они не имеют отношения к этому примеру.

Выполнение

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

Воспроизводимость конвейеров машинного обучения

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

Шкала

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

Для Ezra Reporter мы используем несколько языковых моделей и решили обслуживать их в отдельном контейнере на графическом процессоре, управляемом сервисами эластичных контейнеров (ECS) AWS.

Держите пользователей в курсе

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

Развертывание

Полезным упражнением, которое мы проделали в Ezra перед запуском Ezra Reporter в производство, был неофициальный выпуск. Мы хотели протестировать приложение от начала до конца и получить образец отзывов пользователей о нем. Это имело то преимущество, что учитывало любые недавние изменения, которые произошли с тех пор, как вы в последний раз обучали свою модель.

Одним из выводов этого теста было отсутствие шага постобработки по предложению модели. Депутаты попросили, чтобы определенные типы результатов упоминались только в том случае, если они взяты из Impression. Мы сделали корректировку до фактического релиза.

Мониторинг и оповещения

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

Для Ezra Reporter мы используем CloudWatch AWS для ведения журнала и Sentry для общего отслеживания ошибок во всех контейнерах. С помощью CloudWatch вы можете устанавливать метрики в журналах, и это то, что мы в основном используем для мониторинга модели в производстве. Вы также можете запрашивать журналы, используя статистику журналов, и создавать информационные панели.

Вот некоторые показатели, которые мы регистрируем и включаем в нашу панель мониторинга:

1. Средняя точность и полнота для предложений машинного обучения во всех отчетах
2. Средняя точность и отзыв для предложений ML для разных областей сканирования МРТ, например. голова, пэ
3. Время, затраченное на каждый отчет от начала до конца (по нескольким сеансам, если применимо).

В дополнение к созданию информационной панели с использованием метрик журнала мы агрегируем результаты по временным рамкам и устанавливаем сигналы тревоги для каждой агрегации на основе некоторого порога. С помощью SNS и Slack API у нас есть оповещения (и ошибки Sentry), которые отправляются в канал Slack, чтобы получать уведомления о любых оповещениях в режиме реального времени.

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

Теневые пользователи, использующие приложение

Как только пользователи познакомятся с продуктом, найдите время, чтобы следить за ними во время его использования. Увидеть, как продукт используется «в дикой природе», — лучший способ увидеть, насколько ваши тесты выдерживают испытание в реальности; вы можете заметить некоторые ошибки, непреднамеренное поведение или неправильные измерения, которые в противном случае вы бы не заметили.

Одна вещь, которую я заметил во время слежки за пользователями, заключалась в том, что пользователи иногда добавляли сводку, которая выведена из рентгенологического отчета, и, поскольку модель машинного обучения представляет собой алгоритм обобщения с извлечением, она не может предложить такую ​​сводку фрагмента. Однако мы включили этот фрагмент сводки вручную в расчет отзыва, что было несправедливым наказанием для модели. Это была деталь конкретного случая, которую невозможно было бы зафиксировать без затенения. Увидев этот случай, мы удалили эти точки данных из знаменателя отзыва.

Переподготовка

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

Заключение

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