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

Сегодня медтех трудно описывать как систему, которая “вот-вот готова заменить врача”. Такая картинка удобна для кликбейтных заголовков, но плохо описывает реальность. В клинике искусственный интеллект выглядит скорее как синтез разных стеков: табличные данные, электронные медицинские карты, снимки, предобработка, классические модели машинного обучения, NLP, LLM, RAG, мультимодальные модели, reinforcement learning, мониторинг, регуляторика и, что важно, человек, за которым остается итоговое решение.

Точнее, в реальной клинике решение и ответственность распределены внутри медицинской команды. Врач интерпретирует данные и определяет тактику, но значительную часть наблюдений формируют медицинские сёстры, лабораторные специалисты, рентгенолаборанты и другие участники процесса. Поэтому корректнее говорить не только о doctor-in-the-loop, но и о clinical-team-in-the-loop, если выражаться по-модному.

Медицинский AI уже давно перестал быть про сугубо "угадывание диагнозов по картинке". Гораздо интереснее разобраться в том, как встроить разные модели в реальный клинический процесс и экономить время, снижать число ошибок, не ломаться на плохих данных и не создавать ложного ощущения безопасности — потому что медтех остается одной из самых чувствительных сфер применения ИИ из-за прямого взаимодействия с человеками.

В этой статье постараемся покрыть различные аспекты современного ИИ-медтеха: от чистки данных и выбора архитектур до этических вопросов внедрения ИИ-систем в медицинский контур. В этом мне поможет Наташа — студентка 5 курса педиатрического факультета ПСПбГМУ, практикующий медик: медсестра в детской психиатрической больнице, — привнося собственный взгляд на применение ИИ в медицине с ракурса медицинского работника — заходите к ней на канал!

Зачем ИИ в медицине?

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

Недостаточно просто увидеть, насколько модель точна на тестовой выборке. Приходится разбирать, на каких данных она обучалась, похожи ли эти данные на поток конкретной больницы, на одинаковых ли аппаратах КТ/МРТ были сделаны исследования или на разных, как обработаны пропуски и выбросы, кто проверяет ответ, что происходит после обновления модели, как фиксируются инциденты и можно ли объяснить результат врачу или пациенту.
Медицинский AI постепенно переходит в мир медицинских изделий, клинических процессов и юридической ответственности. А зарегистрировать свой сервис в качестве медицинского изделия - та ещё бумажная волокита

Это видно и по регуляторике. FDA ведет публичный список AI-enabled medical devices, авторизованных для рынка США.

FDA — это главное агентство США по надзору за качеством товаров, обеспечивающее защиту здоровья населения через контроль безопасности

Значительная часть решений относится к радиологии, но встречаются также кардиология, гастроэнтерология, неврология и другие направления. FDA отдельно подчеркивает, что такой список нужен не только разработчикам, но и врачам с пациентами: он помогает понять, где именно в устройстве используется AI.

WHO (Всемирная Организация Здравоохранения) формулирует более широкий принцип: AI в здравоохранении должен внедряться научно обоснованно, безопасно, этично, справедливо и с адекватным управлением.

EU AI Act добавляет юридический контур: многие медицинские AI-системы попадают в зону высокого риска, особенно если они влияют на диагностику, лечение, доступ к медицинским услугам или встроены в регулируемые медицинские продукты.

Карта медицинского AI

Медицинский AI удобнее всего понимать не по названиям моделей, а по типам данных, с которыми работают эти системы, и выполняемым задачам. Разные данные требуют специальных методов и принципиально иных подходов, несут под собой разные риски. Например, текст EHR — электронной карточки пациента — подходит для применения NLP: алгоритмов вроде TF-IDF, BioBERT, ClinicalBERT, LLM и RAG в целом. Однако не редки сложности с аббревиатурами, семантической трактовкой текстов, локальными сокращениями и рисками галлюцинаций — об этом чуть позже.

Табличные клинические данные, как и любые другие табличные данные, требуют EDA (предварительного разведывательного анализа данных): визуализации, заполнения пропусков, feature engineering и последующей аккуратной обработки, потому что пропуски часто неслучайны, а значения могут зависеть от конкретных протоколов конкретной клиники.

Медицинские изображения требуют тщательной предобработки, умеренно-агрессивных аугментаций, специальных архитектур — CNN, U-Net-подобных, DenseNet, MONAI, VLM и мультимодальных моделей. С 3D-изображениями на этапе предобработки часто всплывают проблемы, связанные с физическими параметрами медицинских изображений (для примера — формата DICOM): нужно учитывать spacing между пикселями изображения (физическое расстояние между пикселями изображения в миллимиетрах), ориентацию пациента в пространстве, — а также всегда держать в голове возможный domain shift и ошибки локализации.

Трехмерная визуализация надпочечеников и их патологий

Есть и последовательные клинические решения: дозировка инсулина, вентиляция, инфузии, терапевтические политики. Здесь может возникнуть reinforcement learning, чаще offline RL, Q-learning. Но именно в этой зоне особенно опасен обычный подход с exploration, то есть с постановкой задачи, где “агент” будет работать по некоторой “среде”: нельзя “попробовать” рискованное действие на пациенте ради обучения агента. Такие алгоритмы будут обучаться в симуляционных средах, однако их может быть непросто настроить ввиду сложности медицинского домента и/или рассматриваемой задачкой.

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

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

Большая часть работы в медицинском AI уходит не столько на выбор архитектуры, а на приведение данных в порядок. Медицинские данные редко похожи на аккуратную таблицу из учебника. В одной колонке пропуски могут быть закодированы как ?, в другой как пустая строка, в третьей как unknown, а в четвертой отсутствие измерения вообще несет клинический смысл.

Например, один и тот же показатель давления может храниться как Systolic BP, ArtBP Systolic, Arterial Blood Pressure systolic или NBP [Systolic]. Excel может превратить какой-нибудь биомаркер MARCH1 в дату, а значение 10.02 в 10 февраля.

Другой пример: врачи не всегда указывают наличие контрастного вещества при проведении исследования, хотя в DICOM-файлах есть соответствующее поле под это; возникает эвристика — ключевые слова, по которым можно определить наличие контрастного вещества, вводимого пациенту при проведении исследования (например, КТ) по описанию серии (тэг SeriesDescription DICOM-файла): "arterial", "aorta", "venous", "portal", "delay", "ce", "cta", "head", "ven", "art", "del", "angio", "bodyangio", "nephro", "excretory"; а на нативность КТ-изображения могут указывать такие ключевые слова — "native", "nat", "standart", "std".

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

С медицинскими выбросами тоже нельзя работать только статистикой. Температура выше 40 градусов Цельсия может быть редкой, но реальной гиперпирексией. Температура 375 градусов — почти наверняка артефакт: например запись 37.5 без точки. Границы давления, пульса, температуры, длительности госпитализации и числа диагнозов должны задаваться врачом, который понимает физиологию и контекст измерения.

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

LLM в медицине

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

Например, врач вводит жалобы, симптомы, возраст, пол, какие-то жизненно важные показатели организма (vitals), лабораторные данные и предварительное мнение. Модель структурирует свободный текст, извлекает жалобы, симптомы и показатели, формирует врачебный отчет, а после ввода решения врача превращает его в пациент-ориентированное заключение простым языком. Затем к этому добавляется, например, RAG-поиск по базе медицинских правил.

LLMки помогают закрыть несколько неприятностей:

Врач не хочет вручную переносить каждую жалобу в десяток полей — использует LLMки для автоматической конвертации/заполнения шаблонов;
Пациенту трудно читать выписку с профессиональной терминологией — натравливает LLMку для расшифровки, чтоб понять написанное;
Студенту полезно тренироваться в симуляционной среде, а не только решать статичные тесты — имитируется “клиническая сцена”, где студент будет взаимодействовать с LLMкой и “вытягивать” детали анамнеза LLM-пациента посредством диалога, например, и пытаться определить, построить картину заболевания;
Больнице нужны полные записи, меньше пропусков и понятная документация — заполнение пробелов языковыми моделями, автоматизация поддержания документации с свежом состоянии так далее.

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

RAG как клиническое заземление LLM

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

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

Минимальная архитектура ванильного RAG-ассистента может выглядеть так: локальные документы нарезаются на фрагменты, переводятся в векторные представления, сохраняются в FAISS или аналогичном векторном хранилище (например, Qdrant), далее retriever достает top- релевантных фрагментов, а LLM формирует ответ с учетом найденного контекста.

Минимальная простейшая схема ванильного RAG-ассистента

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

RAG снижает риск галлюцинаций, но не отменяет валидацию. Если база знаний устарела, retrieval нашел не тот документ или промпт смешал источники, система все равно может ошибиться. Поэтому клинический ответ должен включать основания, найденные источники и границы применимости.

Как оценивать LLM в медицине

Оценивать медицинскую LLM обычно принято не только по общеизвестным LLM-метрикам, а по специализированным бенчам. Можно выделить фреймворк MEDIC, который смотрит на пять измерений клинической компетенции:

медицинский reasoning,
этические вопросы,
понимание данных рассматриваемого домена,
in-context learning
и клиническая безопасность.

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

Бенчмарки тоже должны быть разными. MedQA проверяет клинические знания и USMLE-подобные задачи (United States Medical Licensing Examination). MedCalc смотрит на медицинские расчеты, дозировки и шкалы. MEDEC проверяет обнаружение и исправление ошибок в клинических заметках. EHRSQL оценивает генерацию SQL-запросов к электронным медицинским картам. Summarization и SOAP-задачи проверяют полноту, согласованность и отсутствие галлюцинаций. Med-Safety и ToxiGen важны для отказа от вредных запросов.

Есть показательный пример с расчетом CHA2DS2-VASc (клиническая шкала для оценки риска развития ишемического инсульта и системных тромбоэмболий у пациентов с фибрилляцией (или трепетанием) предсердий): обе модели могут прийти к правильному итогу, но одна делает это более устойчиво и структурированно, а другая колеблется в рассуждении. Для клиники это не мелочь. Врач должен понимать, можно ли доверять не только финальному числу, но и способу, которым модель к нему пришла. Поэтому “одна лучшая модель для всего” — плохая стратегия. Нужен портфельный подход: модель выбирается под конкретную задачу и проверяется на конкретном типе ошибок.

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

SOAP, документация и заключения

Один из самых практичных кейсов LLM — медицинская документация. SOAP-заметка делит информацию на Subjective, Objective, Assessment и Plan. Модель может взять диалог врача и пациента, выделить жалобы, объективные данные, вероятную оценку и план, а затем подготовить черновик.

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

Предсказание — ещё не медицинская помощь

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

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

Некоторые сценарии из реальной жизни

Болевые сценарии в государственной клинике

Если посмотреть на обычную поликлинику или стационар, то самые ценные сценарии часто оказываются не там, где “ИИ ставит диагноз вместо врача”, а там, где он снимает с врача лишнее когнитивное и бюрократическое трение. Врач первичного звена не страдает от отсутствия еще одного чат-бота, которые помогал бы с вопросами вроде “что у вас болит?”. Он страдает от того, что за короткий прием нужно заново собрать анамнез, понять красные флаги, сверить лекарства, оформить запись, направление, льготы, коды, лабораторию и объяснение пациенту.

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

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

Исследование Google/DeepMind про LLM для дифференциальной диагностики на 302 сложных кейсах NEJM показало, что специализированная модель может улучшать полноту DDx-списка у врачей, но сами авторы подчеркивают необходимость реальной клинической проверки.

Отдельная работа 2025 года по извлечению анамнеза из клинического текста показывает более приземленный, но очень полезный сценарий: выделять chief complaint, HPI, past/family/social history из свободного текста и превращать их в структуру EHR.

Здесь важно не переоценить обычные потребительские LLM. Например, в JAMA Pediatrics обсуждалась проверка ChatGPT на 100 педиатрических кейсах, где модель часто давала неверные или слишком широкие диагнозы; это хорошо пересказывает Axios. Такой результат не означает, что LLM бесполезны в первичке. Он означает, что пациентский чат без клинического workflow, без ограничения области, без красных флагов, без локальных протоколов и без проверки врачом — плохая форма медицинского продукта.

Педиатрия: пациент постоянно меняется

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

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

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

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

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

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

Оптимизация бумажной волокиты

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

Один из ярких примеров — ambient clinical documentation: система слушает прием, распознает речь, отделяет врача от пациента, извлекает клинические сущности и готовит черновик записи, направления, пациентской инструкции или SOAP. Регуляторный статус таких систем зависит от заявленного назначения, но по смыслу это уже часть клинического процесса: черновик попадает в медицинскую документацию и должен проверяться врачом.

В 2025 году появились реальные оценки: кастомный ambient scribe в телемедицинской практике на базе Whisper и GPT-4o, описанный в работе Included Health, был принят сотнями клиницистов; большинство опрошенных врачей сообщили о снижении когнитивной нагрузки и документационной нагрузки.

При этом параллельно появляются и исследования о рисках: работа о patient safety risks from AI scribes разбирает ошибки транскрипции и черновиков, особенно вокруг лекарств и лечения.

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

Для российской государственной клиники это может быть не “врач говорит с красивым AI-ассистентом”, а набор скучных, но полезных функций: черновик записи приема, автозаполнение осмотра из диктовки, сверка назначений с аллергиями и дубликатами, генерация направления по локальному шаблону, подготовка пациентской памятки, извлечение анамнеза из прошлых записей, подсказка “в прошлом визите уже была такая жалоба”, проверка обязательных полей перед закрытием случая. Самый ценный интерфейс здесь должен быть встроен в EHR, а не существовать отдельным окном, куда врач вручную копирует текст.

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

Геронтология, деменция и одинокие пожилые люди

Геронтология - один из самых человечески понятных сценариев для AI, потому что проблема не сводится к диагнозу. Одинокому пожилому человеку с когнитивным снижением нужны напоминания, повторяемость, мягкий контроль, связь с родственниками или соцработником, обнаружение изменений поведения и снижение тревоги. Это не обязательно должен быть человекоподобный робот; иногда достаточно голосового ассистента, приложения, датчиков активности, календаря лекарств и канала уведомлений.

Уже есть социальные роботы и AI-компаньоны для пожилых людей.

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

В научной литературе направление шире: socially assistive robots используются для социальной, когнитивной и физической поддержки, а работы 2024-2025 годов обсуждают долгосрочное вовлечение, дизайн активностей и ethical design для людей с деменцией.

Особенно важна работа про social robots for people living with dementia: авторы показывают, что в деменции легко размывается граница между полезным взаимодействием и роботизированным обманом.

Для одиноких пожилых людей с деменцией AI интересен не столько в качестве “замены сиделки”, сколько в лице постоянного персонального помощника: напомнить, успокоить, связать с врачом или родственником, когда ситуация становится опасной.

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

Диабет: от помпы к автоматизации рутины

Диабет уже ближе многих направлений к реальной автоматизации, потому что данные измеряются часто, действие повторяется, а эффект виден в динамике глюкозы. Современный контур состоит из continuous glucose monitor (CGM), помпы, алгоритма и приложения.

NHS (Национальная служба здравоохранения) в 2024 году начала масштабное раскатывание систем для людей с диабетом 1 типа: система постоянно мониторит глюкозу и автоматически корректирует подачу инсулина через помпу, что должно снижать риск гипо- и гипергликемий.

FDA в августе 2024 года расширила показания Insulet SmartAdjust на взрослых с диабетом 2 типа, отдельно подчеркнув, что автоматическое дозирование раньше было доступно в основном людям с диабетом 1 типа.

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

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

С точки зрения ML это очень интересная задача: состояние меняется каждые минуты, действия имеют задержанный эффект, а награда асимметрична — гипогликемия обычно опаснее кратковременной умеренной гипергликемии. Поэтому в реальных продуктах нужны не только RL-идеи, но и жесткие ограничения по безопасности, fallback-режимы, сигнализация, ограничение максимальных болюсов, ручное подтверждение еды и врачебная настройка целевых диапазонов.

Цифровая психотерапия и сопровождение вне стационара

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

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

В 2025 году появился RCT Therabot — рандомизированное исследование по применению ИИ-чатботов для помощи лечения ментальных заболеваний; обзорно это резюмируется в статье AI therapist.

Есть и более новые наблюдения 2025 года по специализированному mental health GAI, где были улучшения PHQ-9/GAD-7 и срабатывания safety guardrails. Но рядом с этим есть систематический обзор LLM в mental health, который прямо подчеркивает риски приватности, ненадежности, избыточного полагания на эти LLMки и нехватки клинической валидации.

Самый интересный вариант — не автономный “ИИ-психотерапевт”, а связка врач + ИИ. Пациент вне стационара получает персонального помощника, а врач получает уведомление, если появляются опасные сигналы.

В психиатрии это различие критично. Система не должна спорить с психотическим бредом “на равных”, не должна романтизировать суицидальные мысли, не должна подталкивать к отказу от врача и не должна становиться единственным эмоциональным контактом пациента.

В 2025-2026 годах появились тревожные работы и расследования:

Исследование по неявным суицидальным мыслям (implicit suicidal ideation) показывает, что LLM плохо справляются с их обнаружением;
Фреймворк для clinical AI red teaming находит риски валидирования бредовых идей и неудачной деэскалации суицидального риска;
Журналистские материалы вроде этого фиксируют обеспокоенность психотерапевтов из-за зависимости, усиления тревоги и небезопасных ответов.

Поэтому безопасный дизайн цифровой психотерапии должен быть гибридным:

AI помогает вести дневник, структурировать симптомы и давать низкорисковые навыки самопомощи.
Врач видит summary, — выжимку, — динамику и тревожные маркеры, а не бесконечный чат-лог.
Есть явные “правила эскалации”: суицидальный риск, психоз, мания, насилие, отказ от еды/лекарств, тяжелая бессонница, интоксикация.
Модель обучена не “угождать” пациенту, а мягко возвращать его к плану лечения и человеку-специалисту.
Пациент заранее понимает, какие данные видит врач, какие события триггерят уведомление и где границы конфиденциальности.

Психиатрический стационар: видео, походка и риск агрессии

Идея анализировать походку, жестикуляцию и поведение пациентов в общепсихиатрическом отделении звучит футуристично, но логика понятна: аутоагрессия и агрессия могут развиваться быстро, а персонал физически не может одновременно видеть всех пациентов. Технически это задача multimodal risk monitoring: видео, поза, скорость движения, траектория, жесты, приближение к другим пациентам, длительное пребывание в опасной зоне, изменения сна, речь, записи медперсонала, назначения, недавние конфликты.

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

Пока доказательная база здесь слабее, чем в радиологии или диабетических closed-loop системах. Есть работы по violence risk prediction на клинических заметках: например, модель на Dutch clinical notes достигала AUC около 0.8 и была сопоставима с анкетным методом, а federated learning для violence incident prediction показывает, как можно обучать NLP-модели между учреждениями без прямого обмена данными. Но свежий систематический обзор machine learning for violence prediction формулирует трезвый вывод: большинство моделей имеют высокий риск смещения, мало внешней валидации, слабую калибровку и ограниченную клиническую полезность.

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

Даже в более узкой задаче обнаружения пациента на клиническом видео обычный Mask R-CNN без fine-tuning работал плохо, а после дообучения результаты заметно улучшались, но оставались зависимыми от конкретного видео.

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

Если такую систему проектировать, ее нельзя делать как “черный ящик, который ставит метку опасен”. Более разумный MVP:

Персональный baseline: как конкретный пациент обычно ходит, жестикулирует, спит и взаимодействует.
Детекция отклонений: резкая моторная ажитация, повторяющиеся удары, бег, попытка залезть на опасный объект, долгий ступор в необычной зоне.
Low-latency уведомление посту, но без автоматических санкций.
Возможность быстро пометить false positive и улучшать локальную модель.
Privacy-by-design: маскирование лиц там, где можно, локальная обработка видео, короткое хранение, строгий доступ, журнал просмотров.
Обязательная клиническая и этическая проверка: нельзя превращать отделение в систему тотальной подозрительности, где пациент становится объектом постоянного скоринга.

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

Другие подходы

Медицинские изображения

AI в медицинских изображениях может считаться самой зрелой частью области. Радиология, патоморфология и нейровизуализация давно работают с цифровыми изображениями, а задачи классификации, сегментации и детекции хорошо ложатся на нейросетевые методы. Они начали сносно решаться сверточными нейронками, — а позднее — трансформерами, — еще в 2016-2019 годах. Но клиническое изображение — это не просто jpeg/png картинка, а более сложный комплексный формат.

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

Когда вы делаете КТ или МРТ в клинике, то вам могут выдать на руки CD-диск с записанным исследованием — он будет именно в формате DICOM, который либо удобно открывается специальными редакторами вроде MicroDicom, RadiAnt (нужна лицензия), 3D Slicer и др., либо его можно прочитать в Python через pydicom

DICOM хранит изображение вместе с patient/study metadata и привычен клиническому workflow, PACS и отчетам. NIfTI удобен для 3D ризёрча, потому что хранит объем, affine matrix (которая нужна при всяких преобразованиях над “кубиком” исследования) и хорошо подходит для обучения 3D-моделей. Если просто сконвертировать все в jpg, можно потерять ориентацию, spacing, связь между срезами и важную метаинформацию. Кроме того, DICOM-изображения закодированы 16 битами (это дает $2^{16}=65536$ градаций серого), а jpeg — 8 битами ( градаций)

На этапе предобработки для медицинских изображений важны ориентация пациента (та, которая описывает его положение в пространстве), — часто происходит приведение к RAS: это такое соглашение, которое располагает пациента привычным образом — вверх головой, лицом к нам; также делают выравнивание pixel spacing, нормализацию интенсивности пикселей — приведение значений пикселей к числам Хаунсфилда, если мы говорим про КТ —, всевоможные 2D/3D кропы и аугментации.

Про ориентацию и pixel spacing нужно особенно тщательно помнить, потому что не всегда пациент будет при проведении исследования находиться головой к аппарату и на спине (вдруг он будет на животе, на боку или еще как-то). Pixel Spacing в свою очередь отражает реальные размеры между пикселями на изображении - как правило, в миллиметрах. Это нужно потому, что пациенты различных размеров должны уместиться на картинку $512\times 512$ .

Слева — основные "плоскости сечения пациента", справа — определение RAS ориентации пациента в пространстве

Для 3D-сегментации особенно важно уметь инвертировать преобразования на inference: если модель предсказывает маску после ресемплинга и crop, результат нужно вернуть в исходное пространство изображения. Иначе врач получит кривую маску.

В реальности изображения приходят с разных аппаратов, по разным протоколам, с разными артефактами и распределениями пациентов. 2D-подход проще, легче и быстрее, но теряет пространственный контекст. 3D-подход тяжелее по памяти, зато нужен для объемных структур, сегментации органов, опухолей, сосудистых аномалий и задач, где важна анатомическая непрерывность.

Sliding Window Inference, например, помогает обрабатывать 3D-объемы, которые не помещаются в память целиком, но размер окна тоже становится гиперпараметром: слишком маленькое окно теряет контекст, слишком большое может не влезть в VRAM или подтянуть нерелевантный фон. Кроме того, можно задавать процент пересечения, или наложения, скользящих “кубиков”, которые вырезаются из 3D-тензора КТ/МРТ исследования на обучении или инференсе.

Sliding Window Inference (SWI) может порождать дефекты при "склеивании" кубиков меньшего размера в зависимости от гиперпараметров метода "склеивания" — они могут быть разными. В примере — SWI с гауссовским взвешиванием

Что касается моделей, то для классификации используются DenseNet, EfficientNet, CNN-baseline и vision transformers; для сегментации - U-Net, DeepLabV3, SegResNet, ResUNet, VNet, Attention U-Net, UNETR, SwinUNETR, TransUNet, SegFormer, MedFormer и др. Также можно упомянуть foundation/medical models вроде RAD-DINO, MedImageInsight, BiomedParse, MedVersa, MedGemini, OpenBioLLM-70B, BioMistral и Med42.

Но список архитектур сам по себе мало что решает. В медицинском домене важны формат, геометрия, метрики, качественный просмотр ошибок и разбиение train/test по пациентам, а не по отдельным срезам.

После обучения нейронки приходится, как правило, в ручном режиме отсматривать большое количество исследований, на которых мы прогнали модель в тестовом режиме, и смотреть, где были получены ошибки. Если процессы настроены ладно, то этим будет заниматься врач-специалист, который сможет лучше разглядеть ошибки и неточности. В моей практике периодически имело место, например, еженедельное отсматривание нескольких десятков NIfTI-кубиков после инференса ансамбля моделей 3D-сегментации на органах брюшной полости (ОБП). Мы грузили их в 3D Slicer и более-менее сносно отсматривали результаты (хотя в 3D Slicer очень древний и не очень очевидный UX/UI), сравнивали с GT разметкой, если та имелась

Мультимодальные модели

Мультимодальные LLM и VLM особенно привлекательны для медицины, потому что врач почти никогда не принимает решение по одному источнику. Он смотрит жалобы, анамнез, лабораторию, снимки, заключения, лекарства, динамику, факторы риска и локальные протоколы. Модель, которая умеет объединить EHR, рентген, КТ, МРТ, патоморфологию и генетику, кажется естественным следующим шагом.

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

Бенчмарки вроде MedBookVQA и MedFrameQA хорошо иллюстрируют этот разрыв. На одиночных изображениях из учебников модель может уверенно распознать тип картинки, но хуже связать ее с симптомами и заболеванием.

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

Обучение с подкреплением

В медтех-задачках Reinforcement learning (RL, обучение с подкреплением) может пригодиться и становится интересным там, где медицина является не разовой классификацией, а последовательностью действий. Дозировка инсулина, вазопрессоры, инфузии, вентиляция, химио- или лучевая терапия, реабилитация - все это похоже на задачу выбора политики во времени. Агент наблюдает состояние пациента, выбирает действие, получает награду и учится максимизировать ожидаемый долгосрочный результат.

Формально задача задается марковским процессом принятия решений: есть пространство состояний , пространство действий , функция переходов , функция награды и политика $\pi$ . Value-based методы оценивают ценность состояний и действий, policy-based методы напрямую оптимизируют политику, а actor-critic совмещает оба подхода. В клинике особенно важен off-policy режим, потому что агент учится на исторических данных, а не экспериментирует на реальных пациентах.

Можно визуализировать на задаче управления дозой инсулина. Состояние включает уровень сахара 50-250 мг/дл, возраст 20-70 и физическую активность 0-1. Действия - не давать инсулин, дать низкую, среднюю или высокую дозу. Награда положительная, если сахар находится в нормальном диапазоне, и отрицательная, если он опасно высокий или низкий.
Это хорошая учебная демонстрация, но не клиническая модель. В реальной медицине RL сталкивается с высокой размерностью состояния, шумом измерений, несвоевременными анализами, пропусками, демографическим смещением (bias), нарушением марковского предположения (будущее состояние системы зависит только от ее текущего состояния) и сложным стратегиям выдачи награды (reward). Текущее состояние пациента редко содержит всю историю, генетику, контекст лечения и скрытые факторы. А стандартный exploration опасен: нельзя пробовать рискованные действия на пациенте ради обучения.

Поэтому практический RL в медицине должен быть offline, ограниченным и жестко отвалидированным. Нужны action masking, жесткие и мягкие штрафы, guideline constraints, off-policy evaluation, симуляции с врачом и проспективная проверка до клинического применения. В зрелом варианте RL не заменяет врача, а помогает исследовать терапевтические политики и искать стратегии, которые стоит обсуждать клинической команде.

Метрики: accuracy недостаточно

Вообще, accuracy в медицине часто обманчива и лучше её не рассматривать (да и в целом в ML редко когда стоит полагаться на accuracy). Если болезнь редкая, модель, которая всегда говорит “патологии нет”, может иметь высокий accuracy и тем самым быть бесполезной в клиническом применении.

Ошибка модели и клинический вред — не одно и то же

False positive (FP) и false negative (FN) математически являются разными типами ошибок (первого и второго рода соответственно), но их клиническая цена зависит от конкретной задачи. Ложноположительный результат (FP) может привести к ненужным обследованиям, тревоге пациента, дополнительной лучевой нагрузке и перегрузке персонала. Ложноотрицательный (FN) — к пропуску сепсиса, кровотечения, онкологического заболевания или суицидального риска.

Поэтому порог срабатывания модели нельзя выбирать только по одной метрике (например, -score или ROC-AUC) — нужно руководствоваться контекстом задачи и взвешивать все риски. Необходимо учитывать последствия ошибки, доступные ресурсы и то, что персонал должен делать после сигнала.

Слишком чувствительная система может создавать сотни малозначимых предупреждений и приводить к тому, что начинает сыпаться миллион алёртов: медицинский персонал постепенно перестаёт реагировать даже на важные сигналы (помните притчу про мальчика, который кричал “волки-волки”?)

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

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

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

Для классификации нужны specificity, precision, recall, , ROC-AUC, PR-AUC, confusion matrix. Для вероятностных моделей важна калибровка: если модель говорит “риск 80%”, это должно соответствовать реальной частоте события. Для изображений нужны Dice, IoU, lesion-level sensitivity (recall на уровне каждого отдельного органа, например, если мы решаем задачу сегментации патологий внутренних органов), false positives по сканам, метрики, которые считаются по поверхностям (в 3D-задачах сегментации) и качественный просмотр ошибок врачом. Для RAG важно оценивать не только финальный ответ, но и retrieval: нашлись ли правильные документы, не попал ли устаревший протокол, достаточно ли контекста и умеет ли модель сказать, что ответа в базе нет.

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

Для RL важны off-policy evaluation, safety constraints, worst-case outcomes, robustness и интерпретируемость политики. Во всех случаях полезен анализ по подгруппам: модель может хорошо работать в среднем и плохо на конкретной возрастной, демографической или клинической группе.

От тестовой выборки до клинического отделения

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

1. Ретроспективная валидация. Систему тестируют на данных, которые не участвовали в обучении.

2. Внешняя валидация. Модель проверяют на данных другого учреждения, оборудования и состава пациентов.

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

4. Ограниченный пилот. Результаты видит небольшая группа специалистов; для каждого сигнала фиксируется, был ли он полезным, понятным и своевременным.

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

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

7. Внедрение медицинского AI — это не единичная сертификация модели, а непрерывный процесс наблюдения за её работой, ошибками и влиянием на действия медицинского персонала.

Вывод

В завершение хочется подчеркнуть, что искусственный интеллект в медицине 2026 года, безусловно, довольно сильно продвинулся за последние несколько лет. AI в медицине используют для самых разных задач: диагностической помощи, помощи принятия медицинских решений (clinical decision support), документации, patient-facing сервисов, анализа изображений и видео, прогнозирования риска, оптимизации лечения и обучения врачей.

Основой всего являются данные: грязные, неполные, неоднородные, но клинически ценные. Над ними — предобработка, нормализация и извлечение признаков. Дальше — классические NLP-модели, компьютерное зрение, LLM, RAG, мультимодальные модели и RL. Еще выше — интерфейс врача, пациентские сервисы, документация и workflow. А вокруг всего этого — мониторинг, регуляторика, этика и ответственность.

На сегодняшний момент самый зрелый подход звучит довольно прозаично:

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

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

Думается мне, что до более-менее сносной автоматизации медицинских пайплайнов еще довольно далёко: нужно, чтобы и агентные системы стали как можно более робастными, и соответствующие LLM-ки, которые работают под капотом, вышли на некий футуристический Парето-фронт по ключевым метрикам, которые имеют смысл в медицинском домене, — то есть мы бы имели на руках “неулучшаемое” множество LLM-ок/агентных систем и ясное знание того, как именно применить весь этот сыр-бор в задачках автоматизации медицинских процессов; но это слишком большая материя, и на данный момент здесь я не берусь об этом рассуждать: поля этой хабр статьи слишком маленькие…

Заключительное слово

Спасибо, что долистали до конца! Пишите в комментариях, что вам показалось наиболее любопытным, а также подписывайтесь на канал Наташи! Буду рад предложениям по улучшению статьи и конструктивной критике. За рамками этой статейки осталась целая уйма материала, который просто не влез бы в один пост, — поэтому не все темы оказались покрытыми.

А если вам хочется изучить ML — загляните в профиль за подробностями.

ИИ в медицине. Часть 1