Искусственный интеллект в медицине: как мы тестировали диагностические алгоритмы и что выявила проверка

Искусственный интеллект в медицине: как мы тестировали диагностические алгоритмы и что выявила проверка

Искусственный интеллект в медицине: как тестируют диагностические алгоритмы и что выявляет проверка

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

Именно здесь начинаются содержательные ответы на вопросы о применении методов искусственного интеллекта в медицине. Не про магическую «точность 98%» на лендинге, а про скучную, зато решающую механику: на ком проверяли систему, с чем сравнивали, как она ведёт себя вне лаборатории и что происходит после установки в клинике.

В систематическом обзоре 83 исследований, включившем 86 алгоритмов глубокого обучения для лучевой диагностики, у 70 алгоритмов — то есть у 81% — показатели на внешних данных хотя бы немного ухудшились по сравнению с внутренней проверкой. Почти у половины падение составило не менее 0,05, а у каждого четвёртого — не менее 0,10 по соответствующей метрике. Не сенсация и не приговор ИИ. Просто напоминание: модель, натренированная на «своём» мире, не обязана безошибочно ориентироваться в реальном.

Ловушка внутренней валидации: почему цифра в презентации почти ничего не гарантирует

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

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

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

  • Другая популяция пациентов. Возраст, пол, этническое происхождение, распространённость заболеваний, сопутствующие состояния — не декоративные поля в анкете. Они меняют клиническую картину и исходную вероятность находки.
  • Иная техника получения данных. Производитель томографа, настройки протокола, толщина срезов, качество УЗ-изображения, тип датчика, даже особенности оцифровки — всё это может стать для модели скрытым ориентиром.
  • Другой клинический поток. В профильном онкоцентре и в районном приёмном отделении разная доля сложных случаев. Алгоритм, блестяще работающий на отобранной когорте, может начать шуметь там, где много неспецифических жалоб.
  • Слабый референсный стандарт. Если «правильным ответом» считают не гистологию, контрольное исследование или согласованное заключение экспертов, а просто запись в электронной карте, модель учится на чужих ошибках. Тоже своего рода машинное обучение, только без машины.
  • Пересечение данных. Один пациент, его повторные исследования или данные одной организации могут незаметно оказаться по обе стороны баррикады — в обучении и тесте. Алгоритм не «обобщает», а узнаёт знакомый контекст.

Международные принципы Good Machine Learning Practice, сформулированные IMDRF, требуют независимости обучающих и тестовых наборов. Причём проверять надо не только прямое совпадение файлов. Учитываются пересечения по пациентам, медицинским организациям и способам получения данных.

Высокая точность на знакомой выборке — это повод продолжить проверку, а не повод печатать слово «прорыв» на баннере.

Внутренняя и внешняя проверка — не конкуренты, а разные экзамены

ПараметрВнутренняя валидацияВнешняя валидация
Откуда данныеТа же или очень похожая среда, что и обучающая выборкаДругие клиники, аппараты, регионы или клинические потоки
На какой вопрос отвечаетНаучилась ли модель решать задачу в знакомых условияхСохраняет ли она работоспособность вне «домашней теплицы»
Главный рискСкрытая близость теста к обучению, завышенные показателиВыявление падения качества, которое не понравится маркетингу
Практическая ценностьНеобходимый первый этапОснование для разговора о внедрении в реальную клинику
Что делать при провалеИскать утечку данных, ошибку дизайна, переобучениеОграничивать сценарий применения, дорабатывать и тестировать заново

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

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

Репрезентативная выборка: кого алгоритм вообще умеет «видеть»

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

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

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

1. Какова медицинская задача?

Алгоритм ищет очаг, измеряет объём, сортирует исследования по срочности, предлагает дифференциальный ряд или автоматически формирует заключение? «ИИ для КТ» — не задача, а рекламная каша.

2. Как определяли истину?

С чем сверяли предсказание: с гистологией, клиническим исходом, повторным обследованием, консилиумом экспертов? Если референсный стандарт слабый, красивые метрики становятся красивой упаковкой для неопределённости.

3. Какие пациенты попали в проверку?

Нужно понимать долю тяжёлых и лёгких случаев, возрастные группы, сопутствующие болезни, долю исследований с плохим качеством. В реальной практике «идеальных» снимков примерно столько же, сколько идеально заполненных направлений: иногда встречаются, но строить на них систему рискованно.

4. Где и на чём получены данные?

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

5. Что показали подгруппы?

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

Для сервисов и клиник это не теоретическая бюрократия. Если организация закупает медицинский софт с ИИ, она должна понимать границы заявленного назначения: для какого исследования, какого оборудования, какого клинического сценария и какого пользователя рассчитан продукт. Алгоритм, предназначенный для сортировки КТ в экстренной помощи, не превращается в систему окончательной диагностики только потому, что менеджер добавил к описанию слово «экспертный».

Человек и машина: проверяют не только нейросеть

Самый недооценённый объект тестирования — не модель, а связка «врач + интерфейс + алгоритм + рабочий процесс». Именно она работает в клинике. Не нейросеть в вакууме, где ей торжественно подают один идеальный снимок и просят угадать диагноз.

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

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

Обратная крайность тоже реальна: система даёт слишком много ложных подсказок, врач перестаёт на неё смотреть или тратит время на разбор шума. В отчёте получится, что ИИ «внедрён». В реальности — он стал дорогой заставкой между загрузкой исследования и работой рентгенолога.

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

Что должна проверить клиника до запуска системы

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

Минимально разумный план выглядит так:

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

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

Дрейф данных: почему модель нельзя один раз одобрить и забыть

Есть удобная иллюзия: программу проверили, установили, значит дальше она работает как калькулятор. Но клинический ИИ — не калькулятор. Он существует в меняющейся среде.

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

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

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

Поэтому безопасность ИИ-систем в здравоохранении — это не печать «одобрено» на старте, а жизненный цикл:

1. До внедрения — определить назначение, границы применения, риски и способ локальной проверки.

2. На старте — оценить работу в конкретном workflow, а не на демонстрационных файлах.

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

4. При обновлениях — понимать, что именно поменялось и не повлияло ли это на безопасность.

5. При деградации — иметь понятный режим ограниченного использования или отключения, а не надеяться, что проблема «сама рассосётся после следующего релиза».

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

Это не даёт модели индульгенцию на любое самообучение. Наоборот: убирает любимую технологическую дымовую завесу «алгоритм постоянно становится умнее». Хорошо. Покажите, за счёт чего, на каких данных, в каких пределах и кто проверит, что умнее он стал не только в рекламной презентации.

Перечни «одобренных ИИ»: полезная справка, но не знак качества для всех случаев

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

FDA прямо предупреждает, что её перечень AI-enabled medical devices не является исчерпывающим. В него попадают устройства, идентифицированные в том числе по ИИ-терминам в публичных описаниях разрешений и классификации. Наличие в перечне означает прохождение применимых предпродажных требований в США, но не превращает публичную карточку в полный досье на продукт и не доказывает пригодность для иной страны, версии софта, аппарата или сценария использования.

Для пациента практический вывод прост: не стоит выбирать диагностику по наклейке «с искусственным интеллектом». Гораздо продуктивнее спросить у клиники:

  • для какой задачи используется система — триаж, подсказка врачу, измерение, контроль качества или что-то ещё;
  • кто подписывает итоговое заключение;
  • на каких исследованиях и оборудовании работает решение;
  • есть ли у клиники порядок разбора ошибок и контроля качества после внедрения;
  • как алгоритм встроен в маршрут, а не просто установлен ли он где-то на сервере.

Хорошая клиника ответит без шаманских слов про «уникальную нейросетевую платформу». Плохая начнёт объяснять, что «ИИ исключает человеческий фактор». Это особенно удобная фраза, потому что с её помощью обычно исключают только неудобные вопросы.

Вердикт: доверять нужно не алгоритму, а доказательствам его работы

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

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

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

Частые вопросы

Почему алгоритм, который отлично работал при тестировании, ошибается в реальной клинике?
Это происходит из-за различий в данных: другой аппаратуры, протоколов исследования, популяции пациентов или клинического потока, которые не были учтены при обучении модели.
Что такое внутренняя и внешняя валидация?
Внутренняя валидация проверяет модель на данных из той же среды, где она обучалась, а внешняя — на данных из других клиник и регионов, что позволяет оценить реальную работоспособность системы.
На что нужно смотреть при выборе медицинского ИИ, кроме точности?
Важно уточнить медицинскую задачу, способ определения «истинного» диагноза, характеристики выборки пациентов, особенности оборудования и влияние алгоритма на рабочий процесс врача.
Что такое дрейф данных в медицинском ИИ?
Это ситуация, когда реальный поток данных в клинике перестает соответствовать тем данным, на которых модель обучалась или проходила проверку, что приводит к снижению качества работы алгоритма.
Гарантирует ли наличие ИИ в перечне FDA качество и безопасность продукта?
Наличие в перечне означает прохождение предпродажных требований в США, но не является исчерпывающим доказательством пригодности продукта для любой клиники, пациента или сценария использования.