Что вообще обсуждали на конференции по AI в медицине в Литве
Лаборатория AIML.lt показала на конференции экспериментальные модели для медицинских вопросов и ответов на базе Qwen3.5-4B: laya-multilingual-lt-med и Qwen3.5-4B-LT-med. В той же программе стояли MCP-сервер, ускоряющий работу генетиков, и доклад о массовом переводе медицинских обучающих датасетов на литовский. Отчёт участника короткий: метрик нет, архитектуры не раскрыты, даты выпуска моделей не указаны.
Главный вывод звучит буднично. Медицинские исследователи работают с локальными моделями, потому что медики предельно строги к приватности пациентских данных. Локальный инференс снимает вопрос «куда уходит текст клинического случая» на уровне архитектуры, а не на уровне обещаний поставщика сервиса.
Программа не ограничилась языковыми моделями. Классического ML и обычных нейросетей было даже больше, чем докладов про LLM. Пример из отчёта: работа «Diagnostic Reliability of Multi-Label Chest X-Ray AI outside the Training Hospital: Accuracy, Calibration and Fairness across Seven Architectures» Паулюса Бундзы и Юстаса Тринкунаса про надёжность мультилейбл-модели для рентгена грудной клетки за пределами обучающей больницы. Сюжет знакомый: дома модель показывает одно качество, в чужой клинике другое, поэтому accuracy без калибровки и оценки справедливости мало о чём говорит.
Отдельный трек заняли регуляторы. Их темы в пересказе выглядят как «финансирование плюс качество заявок», и качество касалось безопасности пациентских данных и безопасности применения технологий, включая регулярный анализ инцидентов.
Чего в отчёте нет: даты проведения, числа участников, названия площадки. Домысливать эти детали смысла нет, на выводы они не влияют.
Модели AIML.lt: laya-multilingual-lt-med и Qwen3.5-4B-LT-med
Формат задачи в докладе описан как decision models for medical Q&A: на вход подаётся медицинский реферат, вопрос и варианты ответа, модель выбирает один вариант. По сути это экзамен с вариантами ответов, а не свободный диалог с пациентом. Разница принципиальная: набор вариантов сужает пространство выходов, снижает риск длинных уверенных галлюцинаций и упрощает автоматическую проверку.
laya-multilingual-lt-med заявлена как мультиязычная модель для медицинских вопросов и ответов, Qwen3.5-4B-LT-med - медицинская модель на базе Qwen3.5-4B. Обе описаны как экспериментальные и лежат на Hugging Face лаборатории. Параметры, лицензии, состав обучающих данных и метрики качества в отчёте не раскрываются, поэтому сравнивать их с чем-либо по цифрам нельзя.
Мультиязычность в литовском контексте решает конкретную проблему. Английских медицинских корпусов много, литовских мало, и модель, обученная только на английском, на литовском вопросе отвечает хуже, даже когда знает факт. Отсюда интерес к вариантам, которые держат оба языка в одном пространстве токенов.
Статус «экспериментальная» здесь не формальность. Это исследовательские артефакты, а не сертифицированные медицинские изделия. Применять их для решений о пациентах до валидации и клинических испытаний нельзя.
Почему база Qwen3.5-4B - разумный выбор для медицинского Q&A
4B параметров - класс, который поднимается на одной потребительской видеокарте. Отсюда три практических следствия: модель запускается в клинике или лаборатории без облака; дообучение под домен стоит на порядки дешевле, чем для моделей на 70-120B; цикл «поменял датасет, переобучил, проверил» укладывается в дни, а не в месяцы.
Ограничения у такого выбора честные. Небольшая модель слабее на многошаговых клинических рассуждениях, где нужно удержать несколько противоречащих факторов сразу. Она чувствительна к формулировкам промпта и к языку: медицинская терминология на литовском или русском встречается в предобучении реже английской. Дообучение под домен не заменяет клинические испытания и не снимает ответственность с врача.
Ориентир по запуску, и он не из доклада: модель на 4B в 4-битной квантизации обычно занимает несколько гигабайт весов и живёт на GPU с 8-16 ГБ, если не раздувать контекст. Для экспериментов с медицинскими датасетами такого класса хватает одной карты среднего уровня, а качество ответа упирается уже в данные, а не в железо.
MCP-сервер для генетиков: как LLM ускоряет оценку точек разрыва хромосомных перестроек
Вторая заметная работа - «Interpretable language model assistant for evaluating evidence of structural chromosomal rearrangement breakpoints in rare disease diagnostics». Авторы: Vytautas Rimas, Erinija Pranckevičienė, Eglė Preikšaitienė и Živilė Maldžienė. Задача из клинической генетики: при диагностике редких заболеваний нужно оценивать доказательства по точкам разрыва структурных хромосомных перестроек. Работа аккуратная, рутинная и плохо масштабируется на людей: каждый случай требует сверки с источниками и разбора, что именно подтверждает гипотезу.
Роль MCP-сервера здесь - ускорение работы специалиста, а не его замена. Модель не «вспоминает» геномные данные из обучающего корпуса, а обращается к инструментам через стандартизованный интерфейс. Слово interpretable в названии указывает на главное требование клинической генетики: результат должен объясняться, иначе генетик не сможет его принять, каким бы правдоподобным он ни выглядел.
Деталей в отчёте нет: ни перечня инструментов MCP, ни метрик ускорения, ни описания архитектуры. Их стоит искать в самой работе, а не в пересказе.
Что такое MCP и почему он важен именно в клинических пайплайнах
MCP (Model Context Protocol) - способ подключить LLM к внешним инструментам и источникам данных через единый интерфейс. Для медицины ценность не в моде на протоколы. Модель, которая дергает конкретный инструмент, оставляет след: какой запрос ушёл, какой ответ вернулся, на каком основании сделан вывод. Это упрощает аудит и разбор инцидента.
Второй эффект связан с приватностью. Локальный MCP-сервер держит обращения к данным внутри периметра: пациентские записи не уходят в сторонний API, а остаются между моделью и внутренними базами. Ровно этого требует логика регулярного анализа инцидентов, о которой говорили представители регуляторов.
Отчёт с конференции подтверждает только сам факт работы с MCP-сервером и состав авторов. Всё остальное, включая скорость, придётся проверять по публикации.
Перевод медицинских датасетов на литовский: почему это отдельная инженерная задача
Третье направление - массовый перевод медицинских текстовых датасетов на литовский с корректной литовской терминологией. В программе была работа «Strategies for translating medical training data into Lithuanian» (Augustė Raišytė, Linas Petkevičius, Dalius Matuzevičius). Логика простая: доменную модель на литовском не обучить, если корпус на языке существует только в виде машинного перевода, где половина терминов звучит как из инструкции к микроволновке.
Оценок BLEU, названий датасетов и размеров корпусов в отчёте нет. Есть тезис: локальные модели применяют именно для массового перевода, и корректность терминологии считается отдельной задачей, а не побочным эффектом прогона через переводчик.
Терминология как главный риск: что ломается при массовом переводе
Медицинская лексика плохо переносит автоматический перевод по четырём причинам. Омонимия: одно слово в бытовом и клиническом смысле означает разное. Ложные друзья переводчика: калька звучит правдоподобно и означает другую процедуру. Разная степень стандартизации: часть терминов закреплена в классификаторах, часть живёт в свободной форме. Потеря контекста в коротких формулировках: заголовок анализа без surrounding текста переводится наугад.
Хуже всего то, что ошибки перевода не случайны, а систематичны. Если переводчик стабильно превращает один термин в другой, модель выучит закономерную ошибку, и потом её не отличить от знания. Практический вывод: глоссарий терминов, автоматическая проверка на запрещённые соответствия и выборочная проверка человеком. Слепой bulk-перевод всего датасета экономит неделю и портит корпус, на котором потом учатся.
Логика переносится на любой язык с развитой медицинской терминологией, включая русский. Схема та же: сначала терминологический контроль, потом массовый прогон.
Какие модели упоминались: Qwen3.5-4B, Qwen3.6-35B-A3B, Qwen3.5-122B-A10B и medgemma-27B
В докладах всплывали четыре имени: Qwen3.5-4B, Qwen3.6-35B-A3B, Qwen3.5-122B-A10B и medgemma-27B. Отчёт фиксирует список и не даёт сравнений качества. Полезнее разложить их по классам железа.
| Класс | Пример из докладов | Что нужно для локального запуска (общий ориентир) |
|---|---|---|
| ~4B dense | Qwen3.5-4B, Qwen3.5-4B-LT-med | Одна потребительская GPU на 8-16 ГБ, квантизация в 4 бита |
| ~27B dense | medgemma-27B | 24-48 ГБ VRAM либо гибридный оффлоад с просадкой скорости |
| ~35B MoE | Qwen3.6-35B-A3B | Рабочая станция или сервер: в бытовую карту без компромиссов по контексту не влезает |
| ~122B MoE | Qwen3.5-122B-A10B | Серверная инфраструктура, несколько GPU, отдельный бюджет на питание |
Цифры в таблице - общие соображения по запуску моделей такого размера, замеров из докладов за ними нет. Обозначения A3B и A10B в названиях MoE-моделей указывают на число активных параметров: веса держат в памяти целиком, а на токен считают только часть экспертов. Отсюда типичный компромисс: память под весь ансамбль, скорость как у модели поменьше.
Почему академические медицинские модели отстают от фронта
Часть моделей на момент доклада уже выглядела устаревшей. Причина не в небрежности авторов: цикл от гипотезы до публикации долгий, доменных медицинских моделей выпускается мало, а общие модели обновляются каждые несколько месяцев. Пока работа проходит ревью, базовая модель успевает смениться дважды, и дообучение приходится переделывать.
Практический вывод: смотрите на дату публикации и на базовую модель, а слово med в названии мало о чём говорит. Для локального запуска важнее воспроизводимость пайплайна и понятный набор валидации, чем «самая свежая» модель из статьи.
Второй слой проблемы - ресурсы на обучение. Может ли небольшая команда обучить модель уровня лидеров - разбор того, где заканчиваются вычисления, данные и экспертиза и какие сценарии остаются реальными для независимой лаборатории. Краткий отчёт эту тему только обозначает.
Почему в медицине локальные модели выигрывают у облачных API
Причина одна и она скучная: пациентские данные. Автор отчёта называет локальный запуск единственным способом гарантировать приватность, и это его оценка, а не измеренный результат. Изолированный контур можно собрать и вокруг облачного решения, с шифрованием и обезличиванием. Но в клинической практике локальный инференс снимает целый класс рисков сразу, без юридической эквилибристики.
Регуляторный трек подтверждает это по-своему. Представители регуляторов говорили о финансировании и качестве заявок, и качество упиралось в безопасность пациентских данных и безопасность применения технологий, включая регулярный анализ инцидентов. Регулярный анализ означает прослеживаемость: кто, когда и с какими данными работал. Локальный стек с логированием отвечает на эти вопросы проще, чем чужой API, где часть телеметрии недоступна.
Ограничения локального пути реальные. Железо стоит денег, поддержка ложится на свою команду, обновления моделей и патчи безопасности сервера тоже на вас. Облако эти заботы забирает, но взамен требует доверия к чужому периметру и готовности описать его в документах.
Кто хочет увидеть сценарии шире клинических, найдёт их в разборе практических кейсов локальных LLM от сообщества: там про анализ документов, полевые заметки и честный разбор ограничений.
Что это значит на практике: чек-лист локального медицинского стека
- Изолированный сервер без внешних вызовов: исходящие соединения закрыты, кроме обновлений по расписанию.
- Контроль доступа и логирование: кто задал запрос, какие данные попали в контекст, что вернула модель.
- Версионирование моделей и датасетов: возможность воспроизвести ответ полугодовой давности при разборе инцидента.
- Выборочная валидация выходов специалистом: регулярная ручная проверка части ответов, а не только финальных решений.
- План реакции на инцидент: кто останавливает систему, кому сообщает, что фиксирует в журнале.
Локальность - необходимое, но недостаточное условие. Модель всё равно ошибается, и клиническое решение остаётся за человеком. В продакшене такие системы вытягивает обвязка, а не сама модель: разбор 1352 кейсов показывает, как пороги уверенности, детерминированный код и человек на границе определяют результат.
Что из этого стоит пробовать, а что пока остаётся экспериментом
Модели на базе Qwen3.5-4B и подход с MCP-сервером - исследовательские направления. Готовыми клиническими продуктами они не стали, и в отчёте нет ни одного подтверждения обратного.
Что реально сделать практику: поднять 4B-модель локально на своём железе, прогнать её на открытом медицинском Q&A-датасете с вариантами ответов, посмотреть, где она ломается, и сравнить с базовой Qwen3.5-4B без дообучения. Такой эксперимент стоит вечера и даёт больше, чем чтение названий моделей. Дальше по вкусу: свой глоссарий терминов, свой набор валидации, замер доли ответов, которые пришлось править человеку.
Чего делать нельзя: использовать такие модели для решений о пациентах без валидации и клинических испытаний. Это не перестраховка. Идея заменить врача моделью разобрана отдельно в материале про второе медицинское мнение от ИИ: там про галлюцинации, отсутствие клинической ответственности и рабочие сценарии вроде подготовки к приёму.
Кому тема полезна: исследователям, разработчикам медицинских пайплайнов и владельцам GPU-серверов, которым нужен локальный стенд для экспериментов. Всем остальным на этом этапе достаточно одного факта. Локальные модели в медицине выбирают не из любви к опенсорсу, а потому что иначе данные пациентов не удержать внутри периметра.