Требования, которые определили решения

• Офлайн. Медицинские изображения не покидают контур — это исключило внешние модели и облачные API на всех этапах, включая разметку.
• Контейнер и скрипт запуска. Зафиксированные версии зависимостей, образ без данных; веса монтируются при запуске.
• До трёх минут на исследование. Мы укладываемся с запасом более тысячи раз.
• Воспроизводимость. Фиксированные генераторы, состав разбиения в файле, происхождение модели внутри чекпоинта.
• Приоритетные метрики. F1 и ROC-AUC с 95 % доверительными интервалами — отсюда вся логика сравнения на слайдах 8–9.

Что пришлось учесть

• Дубли. Склейка по хешу пиксельных данных: иначе один снимок попадал в обучение и в валидацию одновременно.
• Конфликт имён. Два дубля одного снимка названы как разные области — область решается голосованием по именам.
• Каталог ≠ StudyInstanceUID. Экспертная таблица ссылается на имя каталога, в DICOM лежит другой идентификатор.
• Латеральность пуста. Теги стороны бедра не заполнены — сторону нельзя проверить по метаданным.
• Разметки ROI нет. Ни оверлеев, ни графических аннотаций — сравнить нанесённые области напрямую не с чем.

Почему дубли — это не мелочь

Распределение

Позвоночник 33 нарушения из 99, правое бедро 21 из 79, левое 22 из 73. Неравномерность учитываем отдельно: область почти однозначно определяется шириной кадра, поэтому общая метрика частично отражает различение области, а не качества.

1. Ключ склейки — имя каталога. Таблица ссылается на каталог исследования, а не на тег DICOM; соответствие проверено — сто из ста.
2. Область — голосование по именам файлов. Когда один снимок назван и как позвоночник, и как бедро, побеждает частое имя; при равенстве область остаётся неопределённой.
3. Перенос вердикта. Оценка области переносится на её снимок. Основание — область встречается в исследовании ровно один раз, поэтому не нужно решать, какой из снимков «плохой».
4. Тип нарушения — из структурированных критериев таблицы. Комментарии вроде «сколиоз» сохранены дословно: перекладывать свободный текст в код означало бы догадку.

Что получилось

Почему не полное дообучение

Почему порог не 0.5

Вероятности насыщаются у краёв распределения, поэтому фиксированный порог при доле нарушений около 30 % давал почти нулевой recall. Порог подбирается по F1 на валидации и хранится в чекпоинте вместе с весами.

Почему при заморозке отключён и train-режим

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

Что сделали

1. Зафиксировали разбиение по исследованиям — стратификация по вердикту эксперта.
2. Обучили оба варианта пятью seed'ами на одном и том же наборе исследований; отличаются только метки.
3. Оценили оба по одному эталону — вердикту эксперта на снимках валидации.

Схема

Порог для F1 подбирается на эталоне отдельно для каждой модели, поэтому F1 сравнивается как рабочая точка, а ROC-AUC и PR-AUC — как беспороговые метрики.

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

Как читать числа

• Общий — по всему набору, включая обучающие снимки, поэтому значения смещены вверх.
• Проверка отвечает на вопрос «есть ли вклад содержимого», а не «каково качество на новых данных».
• Общий AUC у правила 0.529 — тоже выше 0.5, потому что в позвоночнике нарушений чуть больше: это и есть та подсказка, которую проверка исключает.

Что это означает для внедрения

Ориентир для планирования — ROC-AUC около 0.68. Модель стоит использовать как фильтр для приоритизации ручного просмотра, а не как единственное заключение: пропуск нарушения дороже ложной тревоги.

Нарушение. Бейдж «Нарушение», уровень HIGH, заключение с вероятностью и порогом, тип нарушения с пометкой «эвристика».

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

Что здесь важно

• Названо происхождение чекпоинта: разметка, эпоха, порог решения.
• Метрики сравнения правил с 95 % интервалами — те же числа, что в отчёте, а не отдельная «красивая» сводка.
• Состав данных: 252 снимка, 100 исследований, 77 нарушений в разметке, 3 снимка без экспертной оценки — они не спрятаны.
• Словарь типов нарушений с указанием источника каждого кода.
• Список ограничений — прямо в интерфейсе, а не только в документации.

Что показали замеры

• Разница между ускорителем и процессором — в пределах 1.4×. Время уходит на декодирование DICOM и препроцессинг, а не на сеть.
• Значит, ускоритель для этой задачи не обязателен: минимальная конфигурация — CPU.
• Чекпоинт 42.8 МБ, память ограничена средой исполнения, а не моделью.

Упаковка и API

• Контейнер с зафиксированными версиями; образ без данных и без весов — чекпоинт монтируется при запуске.
• Пакетная обработка, выгрузка XLSX, текстовый отчёт DICOM SR, веб-интерфейс с панелью «О модели».
• processing_status = Failure вместо исключения — отчёт формируется всегда.
• 208 автотестов, включая три браузерных сценария на живом сервере.