Розробка ШІ для аналізу гістологічних зображень

Чому аналіз гістологічних зображень упирається в ручну розмітку

Аналіз гістологічних зображень упирається не в оптику сканера і не в обчислювальні ресурси, а в те, що фінальне рішення ухвалює людина.

Патоморфолог вивчає препарат і формулює висновок, спираючись на власний досвід: під час повторного розбору того самого скельця розбіжності за окремими нозологіями сягають 10–20% випадків. Це не наслідок низької кваліфікації — так влаштована сама оцінка.

Неоднорідне забарвлення, різна товщина зрізу, артефакти заливки та пограничні картини залишають простір для трактування, і розбіг висновків патоморфологів проявляється навіть у межах однієї лабораторії.

Оцифрування мікропрепаратів цю проблему не знімає, а загострює. Сканер видає цілі серії зображень високої роздільної здатності, але щоб модель упевнено відокремлювала пухлинну тканину від строми та лімфоїдних елементів, потрібні контури, розмічені вручну на тисячах скелець.

Розмітку звіряють з Класифікацією пухлин ВООЗ і протоколами лабораторії, однак сам розбір залишається ручним: жоден автоматичний метод поки не дає готової розмітки прийнятної якості на всьому різноманітті забарвлень.

Тут і є вузьке місце лабораторії. Ручна розмітка скелець — найдорожча за часом операція: на один складний препарат іде кілька годин лікарської уваги, а узгодженість між двома розмітниками за тонкими структурами падає настільки, що модель доводиться перенавчати.

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

Обмеження не в якості зображень і не в архітектурі моделі, а в швидкості та стабільності людської розмітки. Далі розбираємо, як це закривається: якими прийомами скорочують обсяг ручної праці та як утримують відтворюваність висновків на потоці.

Що дає автоматичний розбір скелець: вимірювані зміни

Скельце оцифровується в цілісне зображення й нарізається на фрагменти фіксованого розміру.

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

Відтворюваність висновків — перша вимірювана вісь.

Фіксована попередня обробка (нормалізація кольору за референсом, відсікання фону, незмінний масштаб) разом із версіонуванням ваг моделі дає на одному й тому самому скельці збіг розмітки понад 99% між прогонами, тоді як повторна розмітка двома фахівцями розходиться помітно сильніше.

Пропускна здатність лабораторії зростає не від того, що лікар працює швидше, а від того, що він дивиться лише позначені зони.

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

Час до відповіді складається з часу розбору партії скелець і черги на верифікацію. Розбір іде пакетом: нічний прогін віддає готові карти до ранку, а не по одному скельцю в руки.

Розмітку для навчання й приймання ведемо в QuPath — одне скельце розмічають кілька фахівців, розбіжності фіксуються окремо, тому видно, де помиляється модель, а де спірна сама розмітка.

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

Режими роботи з архівом зображень: три варіанти проєкту

Режим проєкту визначається не вподобаннями, а станом архіву скелець і тим, що лабораторія готова робити власними силами. Три робочі конфігурації різняться обсягом розмітки, яку потрібно створити до старту, і глибиною доступу до даних. Розбираємо їх за умовами застосовності та обмеженнями.

Що з чим порівнюємо

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

Якщо даних багато, але розмітки мало, дообучення готової моделі дає робочий результат помітно раніше за повне навчання, а дорозмітка архіву йде паралельно й поступово розширює охоплення класів.

Режим не фіксується назавжди: конфігурація, розпочата як вбудовування готового розбору, згодом переводиться в дообучення на накопиченому матеріалі без перезбирання лабораторного контуру.

Етапи впровадження: від аудиту архіву до передачі моделі

Робота йде ітераціями, і кожна наступна спирається на результат попередньої. Доки не зрозумілий склад архіву та якість розмітки, будь-яка архітектура рішення залишається здогадом — тому порядок етапів фіксований: спочатку дані, потім схема, потім збирання й перевірка.

1. Аудит архіву скелець. Рахуємо обсяг випадків, розподіл за забарвленнями й локалізаціями, перевіряємо, як зберігаються знімки та чи пов'язані вони з висновками. На виході — карта даних і перелік прогалин, які доведеться закрити до старту.
2. Контроль якості розмітки. Зводимо розмітку лікарів на вибірці, що перетинається, і рахуємо розбіжності між розмітниками. Спірні класи отримують письмові правила: без цього модель вчиться відтворювати чиїсь звички, а не морфологію.
3. Схема рішення. Фіксуємо, що саме модель віддає назовні — сортування за пріоритетом, виділення підозрілих областей або другий погляд на складний випадок, — і що вона не вирішує ніколи.
4. Пілот на ретроспективних скельцях. Збираємо модель на даних, які вже є в архіві, і перевіряємо на вибірці, що не брала участі в навчанні, з розбиттям за періодами надходження та за джерелами. Рахуємо чутливість, специфічність і частку випадків, що йдуть на ручну перевірку.
5. Валідація моделі. Перевіряємо стійкість до артефактів сканування, різних сканерів і перефарбувань, окремо дивимося класи, де помилка коштує найдорожче. Поріг спрацювання налаштовуємо так, щоб пропусків було мінімум.
6. План впровадження. Визначаємо, як рішення вбудовується в поточний маршрут зразка, хто розбирає спірні висновки та за якою метрикою ми вважаємо, що якість не просіла.
7. Передача та навчання команди. Віддаємо розмітку правил, протокол перевірки, інструкції для лікаря-користувача й розбір типових помилок — команда має вміти супроводжувати модель без нас.

Кожен етап закінчується артефактом, який можна перевірити: карта даних, правила розмітки, протокол валідації, регламент. Це дає змогу зупинити роботу на будь-якому кроці, якщо дані не витримують перевірку.

Що залишається в команди клієнта: модель, розмітка, регламенти

Модель, яка добре працює на тестовій вибірці, але залишається в розробника, — це демонстрація, а не впровадження. Передаємо все, що потрібно для самостійної роботи: артефакти, правила їх оновлення, доступи й інструкції для тих, хто користується системою щодня.

• Ваги моделі та її картка. Фіксуємо, на яких препаратах і забарвленнях модель навчалася, як поводиться за кожним класом знахідок і де межі застосовності.
• Порядок оновлення. Описуємо, як дообучати модель на нових скельцях, хто підтверджує випуск версії та як повернутися до попередньої, якщо метрики на контрольній вибірці просіли.
• Регламент роботи з розміткою. Правила розмітки спірних областей, порядок розв'язання розбіжностей між лікарями, версіонування наборів даних і частка випадків із перехресною перевіркою.
• Схема інтеграції. Як результат потрапляє в лабораторну систему, у якому вигляді розмітку бачить лікар і що відбувається за недоступності сервісу — приймання пацієнтів не зупиняється.
• Політики доступу до даних пацієнтів. Ролі та права всередині системи, знеособлення до обробки, журнал звернень до знімків, строки та умови зберігання.
• Інструкції для лаборантів. Вимоги до підготовки й сканування скелець: артефакти, бульбашки, якість зрізу та ознаки, за яких знімок пересканується, а не йде в обробку.
• Інструкції для лікарів. Як читати висновок моделі, що підтверджується вручну та в яких випадках висновок формується без її участі.

Документи зберігаємо поруч із системою й оновлюємо разом із нею: нова версія не випускається, поки картку моделі, регламенти та інструкції не приведено у відповідність. Через місяць супроводу команда клієнта веде оновлення сама, а ми підключаємося до розбору складних випадків.

Кейс: як скоротили частку розбіжностей між експертами

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

Розбіг рішень тримався приблизно на кожному п'ятому випадку, а частину препаратів переглядали повторно — не через брак даних, а через відсутність єдиної точки відліку.

Що показували заміри до впровадження

Що змінили і чому це спрацювало

Розмітку вели в QuPath за єдиним протоколом: спірні поля препарату незалежно відзначали всі експерти, а розбіжності не згладжували, а зберігали окремим класом.

Модель навчалася не на одному «правильному» висновку, а на розподілі думок, тому віддає впевненість за кожним класом, а не жорсткий ярлик.

Поріг упевненості налаштували так, щоб сумнівні випадки не потрапляли в готовий звіт, а одразу ставали в чергу на повторний перегляд.

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

Підсумок — не «звіт замість лікаря», а передбачуваний розбір: спірні препарати відсіюються до підпису, а регламент перегляду однаковий для всієї зміни.

Чим відрізняється дообучення готової моделі від навчання з нуля?

Дообучення — це перенесення моделі: мережа, яка вже бачила великий масив зображень, доналаштовується на вашому архіві під конкретну задачу — «норма/патологія», пошук метастазів у лімфатичному вузлі, сегментація ядер.

Малої вибірки в кілька сотень розмічених препаратів зазвичай достатньо, бо базові ознаки — контури, текстура хроматину, форма ядра — у моделі вже є.

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

Той обсяг розмітки, який рятував під час дообучення, тут не працює — потрібно на порядок більше препаратів.

Головний ризик обох шляхів — розмітка й валідація. Якщо фрагменти одного скельця потрапляють і в навчання, і в перевірку, метрики виявляються завищеними: модель запам'ятовує препарат, а не ознаку.

Тому вибірку ділять за пацієнтами й сканами, а не за окремими фрагментами, і тримають окремий набір, що не брав участі ні в доналаштуванні, ні в підборі порогів.

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

Якщо розмітки мало, класи рідкісні або потрібен розбір усього слайда — рахуємо збирання з нуля, і тоді в план одразу закладаємо цикл розмітки: модель підказує патологу спірні поля, той підтверджує або править, і точність зростає від ітерації до ітерації.

Інтеграції, якість скелець і захист даних: часті сумніви

До старту піднімаються ті самі сумніви: як модель стане в контур лабораторії, що робити з неоднорідним архівом і де межа в даних пацієнта. Нижче — короткі відповіді.

Дані пацієнтів ідуть на сторону?

Ні. Ідентифікатори знеособлюються до подання в модель, обробка йде у вашому контурі, а зворотне зіставлення зберігається лише у вас.

Що робити з неоднорідним архівом і якістю скелець?

Слабкі скани відсікаються на попередньому перегляді, а модель дообучається на ваших серіях — точність не просідає на старих і нерівно забарвлених скельцях.

Чи багато хибних спрацювань?

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

Що відбувається після запуску?

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

Обговоримо задачу: що надіслати для оцінки та плану

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

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

• Набір гістологічних зображень: кілька десятків сканів різних забарвлень, апаратів і лабораторій — за ними ми перевіряємо, наскільки однорідні дані та що доведеться нормалізувати.
• Формулювання цільової задачі: що саме визначаємо на знімку, які класи нас цікавлять і як вони співвідносяться між собою.
• Розмітка: розмічені приклади або хоча б частково перевірені — щоб оцінити обсяг ручної роботи та схему контролю якості.
• Поточний процес: хто сьогодні дивиться знімки, за який час, де вузьке місце і яка частка спірних випадків іде на повторний перегляд.
• Вимоги до результату: допустима частка пропусків, чи потрібна оцінка впевненості та як рішення вбудовується в наявний порядок роботи лікаря.
• Обмеження за даними та контуром: де зберігаються зображення, чи є ізольований контур, хто власник і який режим доступу потрібен нашим інженерам.
• Критерії приймання: на якій вибірці перевіряємо, хто з боку замовника підтверджує результат і яким документом фіксуємо етапи.

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