Как выбрать лучшую ИИ-систему?

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

Есть ещё один понятный инструмент — это государственная сертификация. Регистрационное удостоверение на медицинское изделие Росздравнадзора в России, CE marking в ЕС, UKCA marking в Британии и, конечно, же FDA Approval в США. Казалось бы, если ИИ-система прошла такую сертификацию, то это доказывает её безопасность, эффективность и заявленные в клинических испытаниях метрики качества. Бери любую с хорошими подтвёрждёнными метриками точности — не прогадаешь. Конечно же, это очень далеко от правды, причём это верно не только для России — «FDA clearance of a model cannot serve as a reliable indicator of its performance in all radiology practices».

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

Если вы хотите узнать ещё больше об организации процессов ML-разработки, подписывайтесь на наш Телеграм-канал Варим ML

Обсудим:

• Как бизнес-проблема влияет на выбор критериев качества

• Как выбрать и разметить данные для тестирования

• Как обеспечить честное сравнение ИИ-систем по выбранным метрикам

• Какие особенности учреждения и региона важно не забыть

• Какие ещё факторы могут влиять на выбор

Сценарий применения

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

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

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

• Триаж. Классический триаж — это разбиение пациентов на несколько групп по срочности необходимых медицинских мероприятий. ML-модели позволяют делать это ещё детальнее — можно сортировать пациентов по вероятности патологии или другим признакам. Такая сортировка может потом использоваться для оптимизации рабочего процесса врача (срочных пациентов можно смотреть в первую очередь или автоматически отправлять на дополнительное обследование) или распределения пациентов по врачам разной квалификации и специализации.

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

• Автоматизация. Самый страшный для всех врачей сценарий — частичная или полная замена человека ИИ-системой, в статье он так и называется — replacement. Это, например, автоматическое определение исследований, где с близкой к 100% вероятностью нет никаких патологий — и автоматическая генерация протоколов для таких исследований.

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

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

• Для триажа, вероятно, важнее всего будет возможность ML-системы корректно сортировать пациентов по степени риска (ROC-AUC для бинарных предсказаний, MA-MAE для ординальных шкал) и количество некорректных определений пациентов с высоким риском в низкие группы (чувствительность). При ретроспективном анализе (пересмотр большой выборки исследований) на первый план может выйти минимизация ложноположительных срабатываний (специфичность, precision).

• В ССПВР в зависимости от конкретного применения могут играть ключевую роль количество ложных срабатываний (FPR, FROC-AUC), качество локализации (mAP, DICE, OC-cost, Hausdorff Distance), корректность оценки размеров (MAE), скорость работы системы и многие другие показатели.

• В сценарии автоматизации критическими становятся пропуски патологий системой, но важен и процент исследований, которые система может корректно отсеять как не содержащие патологию. Поэтому здесь может подойти метрика Specificity@(Recall = 1.0) — специфичность при фиксированной стопроцентной чувствительности.

Ещё одна вещь встречается постоянно, что меня ощутимо расстраивает. Представьте, что заказчик хочет использовать ИИ-систему для минимизации пропусков случаев рака на скрининге. Он приходит к двум вендорам, запрашивает демо-доступ без объяснения своего сценария применения и проводит на ИИ-системах с настройками «из коробки» мини-тест с такими результатами:

Какая система лучше? Вопрос с подвохом, без знания сценария применения ответить сложно. Но кажется, что ИИ-2 как минимум не хуже — ROC-AUC повыше, высокая чувствительность, неплохая специфичность, F1-score выше. Но неискушённый в ML заказчик почти наверняка предпочтёт ИИ-1, потому что для его сценария он подходит лучше — ведь не пропускает рак! А ведь если бы ИИ-2 быстро донастроили под сценарий заказчика — результаты могли бы быть совсем другими. Вывод — рекомендую в самом начале максимально подробно описать свой кейс использования и шарить его с ИИ-вендором в самом начале диалога о потенциальной покупке. Вот хороший пример того, как можно описывать кейсы использования.

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

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

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

• Какую бизнес-проблему должно решить внедрение ИИ-системы?

• Кто является конечным пользователем — терапевт, рентгенолог, пациент, заведующий отделением, администратор?

• Какие последствия будут при ошибках в работе ИИ-системы?

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

На чём тестируем?

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

Первая важная задача — выбор исследований, которые будут использоваться для тестирования. Не хочется повторять здесь простые истины про баланс классов и размер выборки, поэтому отсылаю вас к секции Independent Evaluation Performance Assessment и к секции Evaluating AI Models Using Site-Specific Data. Ещё можно обратиться к многолетней практике московского Эксперимента или к ГОСТу по тестированию.

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

Разметка

Самый простой и популярный вариант — сделать выборку ранее описанных врачами исследований и выделить из них нужную разметку — например, наличие/отсутствие патологии, категория по шкале, объём поражения. Если нужные данные хранятся в RIS отдельно — повезло, если нет — придётся расчехлять какие-нибудь NLP-методы для выделения нужной разметки.

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

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

Результаты тестирования практически всегда выявят какие-то расхождения между разметкой врачей и ИИ-системы. Какие у этого могут быть причины?

• Ошибки в работе ИИ-системы. Да, так бывает, ИИ-системы ошибаются, какие-то чаще, какие-то реже. Это самый понятный тип ошибки, и это первый кандидат на объяснение расхождений. При этом ошибки могут иметь разную степень критичности — и это редко учитывается при оценке. Например, в нашем любимом Эксперименте при клинической оценке используется такая шкала: 1 — полное совпадение, 0.5 — неверная трактовка или локализация, 0.25 — ложное срабатывание, 0.0 — пропуск патологии. Впрочем, часто и пропуск пропуску рознь.

• Data shift. ИИ-системы предназначены для работы с входными данными с заданными характеристиками. Если внезапно в тестовом наборе данных оказался ребёнок, а система обучена на снимках взрослых — вряд ли можно ожидать на этом исследовании хороших результатов. Включение таких «необычных» данных может помочь выявить несоответствия между ожиданиями медучреждений и возможностями ИИ-сервисов (об этом подробнее позже).

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

• Ошибки выгрузки данных. Если для получения разметки из текстовых протоколов использовались автоматические средства (регулярные выражения, ML-модельки), то с большой вероятностью найдутся случаи с ошибками.

• Разное понимание задачи у ИИ-системы и врача. Самая интересная и, возможно, наиболее важная причина. Расхождение между врачом и ИИ-системой может быть вызвано тем, что в них изначально закладывали разное понимание того, что такое — норма, а что — патология. Например, в некоторых учреждениях будут ожидать, что на рентгене органов грудной клетки ИИ-система отметит консолидированные (то есть, сросшиеся) переломы и инородные тела, а в других сочтут это лишним или даже ложным срабатыванием. Таких примеров много — спорные категории (типа Bi-Rads 3 на ММГ), плавающие пороги (размер лёгочных узлов, объём паракардиального жира).

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

А у тебя точно АУК 0.99?

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

Выбор на основе данных производителя

Начнём с самого плохого, но существующего варианта — идём на сайты компаний или в РУ, выбираем ту, у которой выбранная нами метрика максимальна, и пишем под них ТЗ. Думаю, не надо объяснять, что сайт компании — не очень хорошее место для получения такой информации. Даже если там удастся найти какие-то немаркетинговые числа, то справедливо сравнить таким образом разные системы невозможно. Разные датасеты, разные аутпуты системы — думаю, долго на этом останавливаться не надо.

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

Плюсы:

• Очень дёшево и быстро

Минусы:

• Очень слабо, а иногда даже отрицательно коррелирует с реальными результатами ИИ-системы в вашем учреждении

Независимая оценка

В этом случае мы опираемся на чужой опыт — смотрим, как ИИ-система проявила себя в схожих сценариях работы.

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

• Проспективный ROC-AUC (ось ординат) — рассчитывается на всём потоке обработанных исследований, за Ground Truth берётся мнение описывающего исследование врача (норма или патология)

• Клиническая оценка (диаметр круга) — ежемесячная оценка на сбалансированной выборке из 80 исследованиях, оценивается качество классификации и локализации, производится врачом-экспертом

• Процент дефектов (ось абсцисс) — технический показатель, сколько исследований по формальным критериям ушли в брак обработки

Насколько мне известно, в других странах пока экспериментов подобного масштаба и глубины проработки нет, но кое-где государственный регулятор ведёт общий каталог ИИ-сервисов. А в США и Великобритании можно обратиться к ACR и NHS соответственно с целью получения независимого заключения о качестве работы сервиса (полагаю, что за отдельную плату).

Ещё один вариант — обратиться за отзывами в другие медицинские организации, где использовалось или пилотировалось данное решение.

Плюсы:

• Независимая оценка качества работы системы

• Не нужно иметь опыта работы с ИИ-системами и экспертизы по их оценке

Минусы:

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

Передача датасета производителю

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

Плюсы:

• Дёшево и быстро

Минусы:

• Нужно создавать свои датасеты для тестирования, и для каждого производителя он будет работать ровно один раз

• Нужно очень сильно доверять производителю, потому что велико пространство для мухлежа

• В любом случае требуется предварительная анонимизация данных

Платформа для тестирования

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

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

Плюсы:

• Требуется интеграция только с платформой, а не с отдельными производителями

• Очень быстро можно получить сводные результаты по россыпи производителей

• Если ИИ-сервис развёрнут на платформе, то данные не попадут к разработчикам

Минусы:

• Нужно создавать свои датасеты для тестирования

• Если это коммерческая, а не государственная платформа, то нужно отвалить денежку

• Не каждый потенциально интересный ИИ-вендор будет представлен на платформе

Интеграция и ретроспективная валидация

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

Важное замечание, которое относится не только к этой схеме тестирования — в сфере здравоохранения действительно очень разнообразные и неочевидные данные. Иногда даже качественная система может показать плохие результаты из-за непредвиденной глупой ошибки — например, на ваших данных некорректно сработал алгоритм выбора серии. Если есть время и возможность — лучше всего предоставить ИИ-вендору небольшой пак (3-7 исследований) с вашими данными, чтобы заранее проверить корректность обработки и не тратить время на полноценный тест в случае необходимости доработок.

Плюсы:

• Нет ограничений по списку производителей

Минусы:

• Нужно создавать свои датасеты для тестирования

• Временные затраты на интеграцию или установку приложения

• Тяжелее обеспечить честность и прозрачность — в зависимости от конкретного процесса тестирования производитель ИИ-системы может иметь больше или меньше возможностей для обмана

Пилотные проекты

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

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

Плюсы:

• При правильной организации можно замерить не только проспективные ML-метрики, но и что-то более близкое к бизнесу

• Персонал получает возможно протестировать удобство работы с системой

Минусы:

• Долго и недёшево

• Большой простор для ошибок в организации

• Требуется заинтересованность и вовлечение персонала

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

Особенности национальных дайкомов

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

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

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

Устойчивость к аугментациям

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

Примеры — геометрические трансформации (флип, сдвиг, зум, поворот), пиксельные трансформации (яркость, контрастность, блюр, шумы).

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

Устойчивость к adversarial samples

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

Примеры — невидимые шумы, подобранные с помощью методов PGD, FGSM, UAP.

Как — берём любой тестовый датасет, для каждой картинки подбираем adversarial sample. Виды атак — black-box (доступ только к ответам модели на наборе данных), white-box (доступ к весам модели).

Общая генерализуемость

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

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

Как — расчёт метрик (общих и по подгруппам) на специально подобранных датасетах, статистические тесты разницы в метриках для разных подгрупп.

Устойчивость к протоколу сбора изображений

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

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

Как — расчёт статистической значимости разницы в метриках для разных категорий.

Устойчивость к артефактам

Зачем — позволяет оценить устойчивость модели к часто встречающимся для модальности артефактам.

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

Как — расчёт стандартных метрик и визуальный анализ результатов обработки.

Проверка возможности обработки исследований с неверной мета-информацией

Зачем — позволяет оценить возможность работы модели на исследованиях с пропущенными или неверно заполненными DICOM-тегами.

Примеры — пропущенные или неверно заполненные теги модальности, части тела, стороны, проекции, спейсинга.

Как — проверяем возможность и корректность обработки на исследованиях с разными проблемами. Можно взять имеющийся датасет и в нём затирать или изменять теги.

Проверка корректности работы алгоритма по выбору серии

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

Примеры — снимки разных проекций (прямая и боковая), серии с разным кернелом или спейсингом, снимки разных частей тела, бракованные снимки вместе с нормальными.

Как — посылаем архив с несколькими исследованиями в систему и смотрим, какое изображение или серия были выбраны. Также полезно проверить поведение системы, если в архиве содержится только «плохие» серии — в идеале модель должна вернуть ошибку.

Другие факторы

Высокие диагностические метрики — это, конечно, очень важно. А какие ещё факторы могут влиять на выбор ИИ-решения? Ещё подробнее об этом можно почитать, например, в этой статье.

• Наличие нужной сертификации — во многих сценариях использования ИИ-решение должно быть зарегистрировано как медицинское изделие с правильным классом риска. К сожалению, пока законодательство немного отстаёт от реальности, и поэтому ИИ-системы регистрируются по тому же процессу, что и другие медизделия. А это значит в числе прочего, что на каждую новую версию модельки нужно получать новое РУ, что может занять 6-12 месяцев…

• Сложность интеграции — в идеале процесс интеграции в IT-инфраструктуру медицинской организации должен быть максимально простым и занимать минимальное время.

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

• Скорость работы — для сценариев экстренной медицины это критический показатель, но и при обычном использовании в формате СППВР вряд ли врачам хочется ждать результатов обработки по 10-15 минут.

• Варианты деплоя — для некоторых медицинских учреждений критична возможность on-premise деплоя. Хотя для разработчиков облако, конечно, в разы удобнее.

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

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

• Стоимость — даже в такой сфере как здравоохранение не уйти от экономики. Если одно решение лучше другого по какой-нибудь метрике на 5 пунктов, но дороже в 10 раз — что делать? Конечно же, зависит от сценария применения и от задач конкретного учреждения и сферы здравоохранения в целом.

• Техподдержка, мониторинг ошибок и обновления — это тема для отдельного обсуждения, но ИИ-системы фейлятся. Фейлятся громко (падают сервера, вылетают баги в апишках) и тихо (например, при дрифте данных или просто на сложных случаях). А это значит, что их нужно мониторить, чинить и по возможности обновлять. Как выстроена система мониторинга, входят ли в стоимость обновления? Всё это стоит узнать заранее.

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

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

Подведём итоги

Итак, что нужно сделать, чтобы не ошибиться при выборе ИИ-системы?

• Чётко понимать, зачем мы хотим её купить и внедрить, а также как мы будем её использовать

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

• Брать чужое ТЗ и копировать все критерии — плохая идея. Проводить все возможные тесты — плохая идея. Формировать набор критериев и тестов под свой случай — хорошая идея

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

• Прозрачная коммуникация с ИИ-вендором — главный шаг на пути к успешному внедрению

Если вы хотите узнать ещё больше об организации процессов ML-разработки, подписывайтесь на наш Телеграм-канал Варим ML