Google опубликовала многостороннюю систему оценки ИИ в здравоохранении

Google объявила о публикации аналитического документа 4 ноября 2026 года, в котором описала, как оценивает генеративный ИИ общего назначения в сфере здравоохранения. Система объединяет тесты с закрытыми вопросами, автоматическую оценку с помощью ИИ и экспертную проверку специалистами, чтобы оценивать точность, безопасность и полезность в типичных сценариях и ситуациях повышенного риска.

Автор работы, доктор Сара Монтгомери-Тейлор, руководит клинической оценкой в Google for Health; доктора Элизабет Макглинн и Дана Гелб Сафран также участвовали в этой работе. В Google сообщают, что разработали этот подход и продолжают использовать его, чтобы оценивать, дают ли модели полезные и точные ответы, способствующие безопасному взаимодействию в сфере здравоохранения. Публикация методики призвана повысить прозрачность и помочь разработчикам, исследователям и клиницистам создавать инструменты, которым люди могут доверять.

Как соотнести оценку с реальной клинической практикой

Авторы утверждают, что методы оценки, разработанные для отдельных задач, не позволяют должным образом оценивать модели общего назначения. В качестве примера они приводят модель, созданную до появления генеративного ИИ: она способна обнаружить рак лёгких на КТ-снимке, но не может выявить рак молочной железы на маммограмме или составить краткую запись по итогам беседы. Когда одна модель может выполнять сотни, тысячи и более задач, разработчикам и организациям здравоохранения необходим способ расставлять приоритеты при оценке взаимодействий и связанных с ними рисков.

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

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

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

Сочетание масштабируемой автоматизированной оценки и экспертного суждения

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

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

Затем клиницисты и другие профильные эксперты изучают случаи, для которых автоматизированные критерии оценки наименее эффективны, в том числе сложные клинические картины, нестандартные ситуации и темы, по которым медицинский консенсус ограничен. Они также оценивают, соответствует ли результат местным клиническим нормам и потребностям разных групп пациентов. Отдельные проверки методом red teaming испытывают границы безопасности с помощью таких приёмов, как эмоциональные мольбы, вымышленный контекст или притворство медицинским работником, чтобы добиться ответа за пределами предусмотренной области применения продукта. Человеческая оценка тоже подвержена ошибкам: авторы отмечают, что оценки двух врачей в рамках одной задачи могут различаться на 30–40% и более, поэтому необходимо контролировать расхождения между экспертами и правильно анализировать результаты.

Мониторинг продолжается и после внедрения

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

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

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

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