LLM-агенты в медицине

Раз в месяц во всех телеграм-каналах про AI/LLM появляются новости в духе - "ИИ сдал экзамен по медицине лучше 90% студентов-медиков", "ИИ точнее врачей предсказал развитие редких заболеваний", "ChatGPT через год заменит врачей-терапевтов". У меня почти всегда такое впечатление, что авторы этих постов читают только заголовок и абстракт и даже в тот же ChatGPT пдфку засунуть ленятся. Я решил поглубже разобраться в самых хайповых статьях от Google, Microsoft и OpenAI, чтобы понять, как устроены эти агенты и действительно ли профессия врача под угрозой. А в конце поста поанализируем тренды и поразмышляем о будущем.

AMIE (Google)

Towards Conversational Diagnostic AI

Первая статья из серии AMIE (Articulate Medical Intelligence Explorer) вышла аж в начале 2024 года, но надо её разобрать, потому что на этом фреймворке основаны дальнейшие итерации.

Каждую статью буду описывать по такой структуре:

• Основная идея - может ли LLM-агент исполнить роль врача в диалоге с пациентом - собрать нужную информацию и сформировать дифференциальный диагноз?
• LLM в основе - PaLM 2.
• Дообучение - итеративное дообучение на симулированных медицинских диалогах, каждая следующая итерация обучается на диалогах врач-пациент, где каждую роль играет LLM-агент на основе модели с предыдущей итерации. Плюс разные медицинские датасеты - реальные транскрипты, суммаризация, MedQA.
• Сценарий работы - доработанный протокол экзаменации OSCE (Objective Structured Clinical Examination). Роль пациента играют "актёры", которым выдают сценарий, в котором описано состояние пациента - история болезни, симптомы, демографические характеристики. Этот актёр общается в текстовом интерфейсе либо с врачом, либо с ИИ-агентом.
• Особенности агентского пайплайна на инференсе - на каждом этапе разговора модель вызывается несколько раз для имитации клинического мышления. Сначала производится суммаризация симптомов и другой важной информации, генерируется текущий дифференциальный диагноз, выделяется важная отсутствующая на данный момент информация, а также оценивается уверенность в текущем дифдиагнозе. На втором шаге генерируется ответ на последнее сообщение пациента - например, производится дальнейший сбор информации или генерируется финальный ответ с диагнозом. Наконец, ответ с предыдущего этапа улучшается по определённым критериям - форматирование, эмпатия, отсутствие фактически противоречивой информации.
• Что сравнивается - точность дифференциального диагноза (по сравнению с GT-диагнозами из сценария), качество ведения диалога (актёры и специалисты оценивали как "человеческие качества" - вежливость, эмпатию, так и "профессиональные" - умение собирать информацию, соблюдение приватности, качество плана лечения).
• Результат - ИИ-агент точнее предсказывает диагнозы (top-3 точность около 89% и 77% соответственно) - и эмпатичнее общается с пациентами, чем врачи-терапевты.
• Ограничения - конечно, главным ограничением является искусственная среда оценки. Общение велось только в чате, ролей пациентов играли актёры с ограниченным и чётким описанием того, какие симптомы у них есть.

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

Towards Conversational AI for Disease Management

• Основная идея - может ли LLM-агент составлять план диагностики и лечения на протяжении нескольких визитов пациента, основываясь на клинических рекомендациях?
• LLM в основе - Gemini 1.5 Flash с контекстным окном 2 миллиона токенов.
• Дообучение - аналогично предыдущей статье, но используются не просто синтетические однократные диалоги пациент-врач, а серия диалогов с одним пациентом. Также помимо этапа SFT используется RLHF и RLAIF - reward-модель обучается на датасете предпочтений людей и LLM-моделей.
• Сценарий работы - аналогично предыдущей статье, но каждый пациент "посещает" врача три раза, причём в реальном мире паузы тоже делались - примерно по 2 дня. В каждом следующем диалоге становится известно больше информации - результатов тестов, изменение симптомов по результатам лечения и так далее.
• Особенности агентского пайплайна на инференсе - здесь нужно разобраться поподробнее, так как пайплайн значительно сложнее.

1. На каждом этапе разговора диалоговый агент делает три запроса к LLM - планирует следующее действие на основе имеющейся информации, генерирует ответ и проверяет ответ на соответствие критериям.
2. На протяжении всего диалога поддерживается и периодически асинхронно обновляется внутреннее состояние агента, в котором содержится саммери про пациента, текущий дифференциальный диагноз и текущий план лечения.
3. Кроме диалогового агента на бэкграунде работает агент, который отвечает за план лечения. Он основывается на клинических рекомендациях, объём которых превышает даже контекстное окно Gemini, поэтому первым этапом нам нужно извлечь около 6 из 627 документов. Для этого делается простой retrieval-шаг на основе эмбединнгов.
4. Далее идёт самый интересный шаг, в котором используется техника в духе schema-guided reasoning. С помощью constrained decoding мы можем "заставлять" нашу модель отвечать по заданной схеме (можно пробовать делать это и промптом, но гарантий никаких не будет). Причём мы можем задать не только схему ответа (например, питоновским классом), но и можем потребовать LLM "думать" в определённом порядке. Скажем, можно требовать перед генерацией каждого пункта плана лечения принуждать модель генерировать текстовое обоснование (можно даже многошаговое по схеме) и id цитируемого документа. Вот простой пример подобной схемы для задачи генерации протокола приёма. По такой заданной схеме этот агент анализирует симптомы и медицинскую историю пациента, устанавливает верхнеуровневые цели для плана лечения, а также планирует конкретные шаги (анализы, исследования, назначения лекарств) с цитатами соответствующих клинических рекомендаций.

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

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

Advancing Conversational Diagnostic AI with Multimodal Reasoning

• Основная идея - сможет ли LLM-система использовать в диалоге не только текстовую информацию, но и медицинские изображения - фото кожи, ЭКГ, фото документов?
• LLM в основе - мультимодальная Gemini 2.0 Flash.
• Дообучение - используется базовая модель, поскольку дообучение дало смешанные результаты.
• Сценарий работы - так же, как в оригинальной статье, но с дополнительными картинками.
• Особенности агентского пайплайна на инференсе - каждый диалог разбивается на три фазы - сбор анамнеза, постановка диагноза и составление плана лечения, ответы на дополнительные вопросы пациента. После каждого шага агент решает, переходить ли на следующий этап. На каждом этапе поддерживается и обновляется внутреннее состояние с профилем пациента, на первом этапе дополнительно есть состояние с текущим дифдиагнозом.
• Что сравнивается - стандартный набор (top-k точность постановки диагноза, качество диалога с точки зрения медицины и коммуникации), а ещё отдельно проверялись метрики на картиночных датасетах.
• Результат - по большинству метрик LLM-система превосходит врачей, кроме того ablation studies показывают, что сам диалог важен и значительно повышает метрики по сравнению с постановкой диагноза по картинке.
• Ограничения - примерно те же самые, что и в прошлых статьях.

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

Towards physician-centered oversight of conversational diagnostic AI

• Основная идея - может ли LLM-агент выступать в качестве первичного звена сбора информации и постановки диагноза, если результат его работы потом перепроверяет опытный доктор?
• LLM в основе - Gemini 2.0 Flash.
• Дообучение - отсутствует.
• Сценарий работы - LLM-агент ведёт диалог с пациентом, собирает информацию, при максимально воздерживается от раздачи медицинских советов. Итоговый диалог превращается в структурированные заметки по формату SOAP (Subjective - Objective - Assessment - Plan), дополнительно генерируется черновик письма пациенту по итогам приёма. Опытный врач-терапевт в специальном интерфейсе может просмотреть все заметки, а также сам текст чата. Затем врач может выбрать отправить сообщение от LLM-агента в исходном виде, отредактировать его или отправить сообщение с просьбой о дополнительном приёме.
• Особенности агентского пайплайна на инференсе - давайте разберём, какие особенности есть в этом пайплайне.

1. На каждом шаге поддерживается и обновляется саммери о пациенте, которое используется для генерации следующего вопроса или решения о переходе на следующую стадию.
2. После того, как мы собрали информацию о пациенте, генерируется предварительный дифдиагноз, который затем уточняется во второй фазе, где задаются более точечные вопросы. Затем диалог завершается саммери приёма, пациент может исправить какие-то неточности или задать дополнительные вопросы.
3. Каждое сообщение, предназначенное для пациента, проверяется специальным агентом на предмет наличия медицинских советов. Это просто запрос с затюненным промптом. Если проблемы обнаружены, запускается процесс редактирования сообщения.
4. Саммери по шаблону SOAP генерируется в несколько запросов. Сначала генерируются секции анамнеза и осмотра (Subjective и Objective). Для каждой из секции задана structured output схема. Например, для Objective-секции генерируется JSON с полями "жизненные показатели", "результаты осмотра", "результаты анализов", "результаты инструментальных исследований", каждое из которых должно являться списком строк. Следующий запрос включает в себя и транскрипт диалога, и только что сгенерированные секции, и на этом этапе так же по своей схеме генерируются секции Assessment (пошаговый анализ и дифдиагноз), а также Plan (план лечения и дальнейших действий). Наконец, на основе всей сгенерённой информации формируется сообщение для пациента.

• Что сравнивается - отсутствие персонализированных медицинских советов, полнота сбора информации, качество коммуникации, качество итогового SOAP (до и после правок врача), качество дифдиагнозов и планов лечения, эффективность с точки зрения времени врача (экономит ли время генерация таких сообщений, насколько часто терапевты их редактируют и используют). Сравнение идёт между LLM-системой и медицинскими работниками (медсёстры, медбратья, ассистенты врача).
• Результат - как вы можете догадаться, все метрики лучше у LLM-системы
• Ограничения - искусственная среда, потенциально непривычная для медперсонала и врачей схема с асинхронным надзором и исправлениями.

Идея с экономией время на этапе сбора первичной информации давно витает в воздухе. Кажется, из всех кейсов это самый реалистичный сценарий. Захотят ли сами пациенты общаться с ботами? Судя по твиттеру у людей назрела большая неприязнь к службам поддержки с ботами - возможно, это из-за их плохого качества, но риск точно есть. Хотя я бы с радостью асинхронно пообщался с LLM-системой - сразу назначит нужные анализы, и к врачу придёшь уже подготовленным.

Другие агентские системы

Sequential Diagnosis with Language Models (Microsoft)

• Основная идея - может ли LLM-система не просто поставить диагноз по имеющейся информации, но и сама выбирать нужные анализы и исследования с учётом их стоимости?
• LLM в основе - модель-агностичный оркестратор под названием MAI-DxO, в качестве основы попробовали разнообразные модели из семейств GPT, Gemini, Claude, Grok, DeepSeek, LLaMa. Лучшие результаты показала модель o3.
• Дообучение - отсутствует.
• Сценарий работы - собрали новый бенчмарк под эту задачу, 304 сложных случая, которые были преобразованы в специальные кейсы. Всё начинается с краткого описания кейса, затем агент (или врач) могут задавать вопросы виртуальному пациенту (его роль играет специальный агент Gatekeeper), заказывать различные тесты (за виртуальные деньги) и наконец объявлять их финальный диагноз.
• Особенности агентского пайплайна на инференсе - разберёмся по шагам.

1. Сам агентский фреймворк состоит из виртуальной панели из пяти врачей, у каждого из которых есть свой промпт. Например, доктор Hypothesis отвечает за обновление вероятностей различных диагнозов, а доктор Stewardship следит за стоимостью тестов и предлагает более дешёвые альтернативы. Далее происходит некий "Chain of Debate" (я не нашёл описания) и выбирается одно из действий - задать вопрос, заказать тест, предоставить диагноз.
2. Gatekeeper отвечает за то, чтобы выдавать только запрошенную информацию, а также генерировать синтетические результаты тестов, если запрошенный тест отсутствует в сценарии. Если бы агент отдавал ответ, что информации по тесту нет, это бы было сильной подсказкой, раз такой тест не делался
3. Агент-судья оценивает правильность диагноза по пятибалльной шкале.

• Что сравнивается - точность диагноза с разными бюджетами на тесты.
• Результат - оркестратор значительно обыгрывает по точности и просто LLM без обвязки, и врачей.

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

AI-based Clinical Decision Support for Primary Care: A Real-World Study (OpenAI)

Не совсем агентская система, но не хотелось исключать её из обзора - всё-таки единственное реальное внедрение.

• Основная идея - может ли LLM-система выступать как подстраховка для врачей при заполнении протокола прямо во время визита пациента?
• LLM в основе - неважно, но здесь использовалась модель GPT-4o.
• Дообучение - отсутствует.
• Сценарий работы - в реальной клинике Penda Health LLM интегрирована с медицинской информационной системой и висит на фоне. Вмешивается только, когда врач изменяет что-то важное в протоколе - например, в секциях анамнеза или назначений лекарств. Ответ системы выглядит для врача как светофорная система - зелёное (всё ок), жёлтое (рекомендуется пересмотреть), красное (требуется проверить).
• Особенности агентского пайплайна на инференсе. Самая интересная часть - это вызов LLM по событиям, когда врач что-то изменяет в протоколе. При этом пришлось тюнить логику срабатываний, иначе врачи мощно уставали от постоянных алертов. В остальном система построена на обычных промптах с few-shot примерами, задизайнеными под контекст конкретной клиники и страны.
• Что сравнивается - клиническая точность подсказок, бизнес-метрики использования (сколько подсказок осталось в "красной зоне", опросы), исходы для пациентов (обзвоны по самочувствию спустя время). Сравнивается с группой без ИИ-инструмента.
• Результат - доля ошибок в ИИ-группе ниже, врачам система тоже понравилась, при этом статически значимых исходов для пациентов обнаружено не было.
• Ограничения - непонятно, насколько внедрение такой системы оправдано с точки зрения экономики и усложнения/замедления процесса работы.

Обсуждаем

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

• Есть тренд на отказ от дообучения моделей на медицинских датасетах. Во-первых, современные модели и так обладают значительными медицинскими знаниями. Во-вторых, это сложно - собрать или сгенерировать качественные данные, а потом дообучить систему так, чтоб она не потеряла часть важных исходных знаний или качеств.
• Практически все кейсы ограничиваются виртуальными сценариями. Статья от OpenAI - один из немногих примеров применения LLM в реальном мире. Неспроста выбрали Кению - подозреваю, что там законодательство сильно попроще в этом плане, ну и цена пилота, само собой. Как тестировать всякие сложные агентские пайплайны в реальном мире - вообще непонятно. Шаг в правильном направлении - системы, которая общается с пациентом, но итоговое решение о дальнейших действиях принимает врач в специальном интерфейсе.
• Какие-то сложные агентские паттерны применяются далеко не всегда, хотя в последних статьях AMIE всегда используются и memory management (внутренние обновляемые состояния агентов), и structured reasoning / output. Конечно, для многих кейсов достаточно просто правильно собрать контекст по запросу и подобрать правильный промпт. В таком случае over-engineering - грех, но в более сложных пайплайнах без зарекомендовавших себя трюков не обойтись.
• Ни в одной из систем на инференсе не используется вызов внешних инструментов - других специализированных моделей (например, для анализа других модальностей) или веб-поиска. RAG тоже в каком-то виде присутствует только в одной из статей. Кстати, и с реальными медицинскими документами в каком-то виде представлена только в одной из статей. А именно работа с PDF, таблицами и другими форматами часто является одним из сложнейших и важнейших компонентов LLM-систем в бизнесе. Есть вот такая статья, где LLM-агент как раз мог вызывать и MedSAM, и искать в Pubmed, и запускать Python-интерпретатор, но я её не стал включать из-за неубедительной валидации.
• Статья от OpenAI неоднократно подчёркивает, насколько важной для результата оказалась UX-инженерия - правила срабатывания, интерфейс. В g-AMIE специальный "кокпит" для врача-надзорщика был разработан по результатам консультаций с врачом. Интересно, как LLM-системы будут взаимодействовать с медицинским персоналом, который, конечно же, никуда не денется.
• В качестве интерфейса взаимодействия с пациентом везде используется текстовый чат, но в реальности, скорее всего, агенты должны уметь понимать и голос. Пока мы разрабатывали наш продукт по генерации протоколов по записи приёма, мы не раз сталкивались с нюансами медицинских диалогов и их сложностью для моделей распознавания голоса. А чем хуже входные данные - тем хуже будет работать LLM-система.
• Везде используется английский язык. Насколько легко всё это перенесётся на другие языки? Понадобится ли тюнинг LLM на медицинских данных таргетного языка, чтоб сохранить качество работы? А ещё в каждой стране используются свои клинические рекомендации, названия лекарств, способы взаимодействия между пациентом и медицинским персоналом.

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