Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Диагностический агент для редких болезней научился сам запрашивать недостающие клинические признаки по ходу беседы. В препринте HPOQuest команды Technical University of Munich и партнёров, который не прошёл рецензирование и приводит замеры самих авторов, доля случаев с верным диагнозом на первом месте выросла с 5 до 35%. Для продуктовой команды это аргумент отделить выбор вопросов от LLM и хранить диагностическое состояние в явной модели.
Как агент превращает ответ в следующий вопрос
HPOQuest начинает с трёх известных признаков пациента из Human Phenotype Ontology — иерархического справочника клинических отклонений. Система сопоставляет подтверждённые признаки с профилями болезней из Orphanet и HPOA, рассчитывает вероятности диагнозов и получает текущий список кандидатов.
Следующий вопрос выбирает политика CAR, которой не требуется дополнительное обучение. Она предпочитает признаки, которые часто встречаются у текущих болезней-кандидатов, но редко встречаются во всём каталоге. Общий признак получает меньший вес, а специфический может быстро отделить несколько похожих диагнозов друг от друга.
Иерархия HPO ограничивает допустимые вопросы. Сначала агент рассматривает соседние и более частные понятия относительно исходных признаков; LLM помогает добавить подходящие верхние ветви, но не придумывает новые термины и не управляет последующей последовательностью.
Ответ может подтвердить признак, указать, что у пациента есть более частный вариант, или исключить всю ветвь. Подтверждение меняет вероятности болезней, а отрицательный ответ удаляет лишние вопросы. Агент останавливается, когда уверенность стала достаточной или исчерпан бюджет в 20 вопросов.
После опроса отдельный этап собирает короткий список диагнозов, добавляет сведения из поиска, PubCaseFinder и профилей Orphanet, а затем передаёт материал LLM для итогового ранжирования. Получается не свободная беседа с моделью, а управляемый процесс: онтология задаёт пространство действий, вероятностная модель хранит состояние, LLM обобщает найденные свидетельства.
Последовательные вопросы помогают не на каждом наборе
Систему проверяли на четырёх ретроспективных когортах RareBench. Все сравниваемые варианты получали одинаковый короткий профиль, использовали Qwen2.5-32B, общий поиск, диагностический модуль и модель-оценщик. Для большинства записей исходный набор составляли из двух самых редких признаков и ещё одного признака пациента.
Самый заметный эффект получился на MME, где исходных данных не хватало обычному варианту DeepRare. Полнота первой пятёрки — доля случаев, где правильный диагноз попал хотя бы в пять первых позиций, — выросла с 5 до 50%. HPOQuest также обошёл вариант DeepRare, которому передавали полный записанный профиль пациента.
На LIRICAL система не улучшила первую позицию, но чаще помещала диагноз в первые несколько вариантов. На HMS и RAMEDIS результат оказался смешанным: исходная LLM уже могла определить подходящую область болезней, поэтому дополнительные вопросы в основном переставляли кандидатов внутри списка.
Универсально лучшего способа выбирать вопросы тоже не нашлось. CAR лучше работал на одних когортах, выбор по ожидаемому снижению неопределённости и прямой выбор через LLM — на других. Политика опроса здесь остаётся компонентом, который придётся проверять на собственном потоке пациентов.
Планы меняет архитектура, а не готовность к клинике
Для команды, которая строит медицинский агент, работа предлагает практичное разделение ответственности. LLM не обязана вести весь опрос: надёжнее хранить подтверждённые и исключённые признаки отдельно, разрешать вопросы через медицинскую онтологию и пересчитывать список диагнозов после каждого содержательного ответа.
Последовательный опрос стоит включать не всегда. Если первые признаки уже вывели систему в правильную область болезней, он уточняет порядок кандидатов. Если правильной болезни нет даже в исходной области поиска, вопросы, привязанные к текущим кандидатам, редко исправляют траекторию. Значит, агенту нужен механизм расширения поиска, а не только более точный выбор следующего признака.
Проверка воспроизводит ответы по готовым HPO-профилям: отсутствующий в записи признак считается отрицательным. В реальном анамнезе отсутствие записи, отрицание пациента и неизвестный статус — разные состояния, поэтому их нельзя сводить к одному значению в продуктовой модели.
Работа измеряет качество ранжирования на ретроспективных данных, а не поведение системы в живом клиническом разговоре. HPOQuest можно рассматривать как схему для прототипа помощника врачу: сначала структурированный сбор признаков, затем поиск и LLM-синтез. Решение о клиническом использовании потребует отдельной проверки на реальных диалогах и неоднозначных ответах.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
