Від сканованих звітів лабораторій до структурованих даних: компроміси в архітектурі OCR

Перетворення фото з виводу з лабораторії на рядок із текстом „Гемоглобін, 13.2, г/дЛ, норма 12.0–15.5“ здається проблемою OCR, але розпізнавання звичайного тексту — це лише перший крок. Справжня робота полягає у тому, щоб дешево, надійно та без витоку даних пацієнтів отримати з неорганізованого скану значення. У цьому посібнику розглядаються архітектурні рішення, які лежать в основі одного з таких механізмів обробки для MVP медичних звітів, щоб ви могли повторно використати ці методи при розв’язанні подібних проблем з розумінням документів за обмежений бюджет.

Вимога, яка керує всім

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

Рішення 1: Вибір мови для роботи

Перевага екосистеми Python є реальною

Якщо почати з питання „яка мова має найкращі інструменти для OCR та штучного інтелекту“, то Python без сумнівів перемагає. Зрілі движки з відкритим кодом, такі як PaddleOCR та EasyOCR, розроблені на Python, у OpenCV є першокласні інтеграції з цією мовою, а більшість прикладів комп’ютерного зору передбачають використання саме Python. Підхід до створення системи OCR з нуля також природно почнеться з Python.

Також варто бути чесними щодо того, що не є фактором відмінності. API Vision від Google була одним із оплачуваних варіантів, які розглядалися, і Google публікує клієнтські бібліотеки як для Python, так і для Go. Тож наявність SDK не віддавала переваги жодній з мов.

Чому все одно перемогло Go

Вирішальними факторами були аспекти навколишньої системи, а не сам OCR. Решта асинхронної ланцюгової обробки вже була спланована як робочий процес на Go: він отримує завдання з Redis Streams, завантажує викладені файли з об’єктного сховища Cloudflare R2 та записує результати у Postgres. Реалізація кроку вилучення інформації на Python означала б роботу двох робочих середовищ із окремим розгортанням, керуванням залежностями та моніторингом для однієї функції. Інженер, який її створював, також досягав найкращої продуктивності у роботі з Go для таких інфраструктурних сервісів.

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

Рішення 2: Хмарні API проти самостійного хостингу, з урахуванням вартості

Команда порівняла чотири варіанти з очікуваною кількістю 30 000 сторінок на місяць. Наведені нижче цифри — це оцінки, використані під час оцінки; ціни в хмарах змінюються, тому перевіряйте актуальні списки цін перед тим, як покладатися на них.

• Google Cloud Vision з функцією DOCUMENT_TEXT_DETECTION. Повертає необроблений текст разом із координатами без структурованих полів. Вартість становить приблизно 1,50 долара за 1 000 сторінок, тобто приблизно 45 доларів на місяць.

Google Document AI (Form або Custom Parser). Повертає структуровані пари ключ-значення та таблиці. Вартість становить від $30 до $65 за 1 000 сторінок, що приблизно дорівнює $900–$1 950 на місяць.

Gemini Flash у Vertex AI. Багатомодальний інструмент, який працює за запитом та повертає структурований JSON. Вартість розраховується за токенами, і орієнтовна сума становить приблизно $20–$50 на місяць.

Самостійно розміщений модель LLM для обробки зображень (MiniCPM-V від Ollama). Прямо генерує структурований JSON. Витрати складають фіксовану суму за сервер, приблизно $40–$80 на місяць для VPS, незалежно від обсягу роботи.

Правильне тлумачення цифр

API Vision здається дешевим, але він вирішує іншу проблему. Він повідомляє про те, що символи „13.2“ знаходяться у певних координатах; він не має жодного уявлення про те, що це показники гемоглобіну. Вам все одно доведеться самостійно створити весь шар обробки даних, тому його ціна не може порівнюватися з варіантами, які повертають структуровані дані.

Document AI дійсно повертає структуровану інформацію, але витрати у розмірі близько 1 000–2 000 доларів на місяць є значними для продукту, який ще не приніс доходу.

Gemini Flash — справді цікавий конкурент. Ціноутворення на основі токенів для сканованих сторінок знаходиться в тому ж діапазоні, що й самостійне хостингу, і ви уникаєте необхідності використання інфраструктури GPU. То чому б не обрати саме його?

Чому самостійний хостинг все одно виявився кращим

Три аргументи вплинули на рішення:

• Ліміт витрат. Спеціалізований вузол коштує однаково, незалежно від того, обробляє він 5 000 чи 50 000 сторінок. API з обліком використання не має такого ліміту: різкий сплеск трафіку, серія повторних спроб чи масовий імпорт безпосередньо відображаються у рахунку.
• Ізоляція даних. Медичні звіти містять конфіденційну інформацію про здоров’я. Виконання операцій обробки всередині приватної мережі команди означає, що документи пацієнтів ніколи не надсилаються до API сторонньої організації під час кожного завантаження, що уникає цілої низки питань, пов’язаних із дотриманням стандартів та перевіркою постачальників, з якими команда MVP не може ефективно впоратися.
• Відсутність зовнішніх квот чи затримок. Не існує обмежень щодо швидкості, рівнів одночасного використання чи додаткових етапів передачі даних у критичному шляху.

У результаті було відмовлено від опцій Google Cloud та Vertex AI та обрано повністю самостійно розгорнуту систему.

Корисно також подивитися іншу сторону справи. Рівень витрат на сервер можна передбачити лише до меж пропускної здатності, яку може обробити один пристрій; поза цими межами доводиться купувати більше обладнання та самостійно займатися плануванням потужностей та забезпеченням безперервної роботи. Самостійне хостинг також не скасовує обов’язків щодо дотримання стандартів, адже ви все одно несете відповідальність за зберігання, контроль доступу та аудит цих даних. Для невеликого, стабільного обсягу роботи з конфіденційними даними самостійний хостинг зазвичай є кращим варіантом; для різкого зростання обсягу даних та команди, яка не має можливостей для їх обробки, кращим вибором може бути API з управлінням.

Рішення 3: Відмова від традиційних бібліотек OCR

Розроблені на основі відкритого коду движки, такі як PaddleOCR та Docling, є здатними до виконання завдань, але їхній результат призначений для відображення. Зазвичай контент форматується за допомогою тегів макетування або у форматі Markdown, щоб він гарно виглядав у інтерфейсі користувача чи HTML-виджеті. Це ідеально, коли результат буде читатися людиною, але незручно, коли коду потрібно отримати значення на кшталт „Гемоглобін: 13,2 г/дл“ у вигляді чистого поля.

Продовження цього прогалини — це проект сам по собі. Доведеться витягувати значення зі структури тегів, пройти багато спроб і помилок для роботи з різними лабораторіями та форматами звітів, а також, ймовірно, додати функції попередньої чи післядоданої обробки з використанням OpenCV для таблиць та ділянок, які двигун не зміг належним чином сегментувати. Усе це додається до роботи з інтеграцією та розміщенням двигуна OCR. Для MVP це значний обсяг інженерної роботи щодо чогось, що є інфраструктурою, а не самим продуктом.

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

Рішення 4: Самостійно розміщений мовний модель для обробки зображень, підібраний за бюджетом

Вилучення сенсу замість символів

Альтернативою підходу „OCR, потім написати парсер для результатів OCR“ є використання мовного моделю, здатної обробляти зображення, яка може виконати обидві дії одночасно. Класичний OCR розпізнає символи. Мовний модель для обробки зображень, отримавши добре структуроване запитання, може проаналізувати надруковану сторінку та безпосередньо повернути поля параметра, значення та одиниці виміру, пропускаючи проміжний крок обробки маркдауну з тегами.

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

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

Вибір моделі, яку можна фактично запустити

Вибір моделі відбувався з урахуванням тієї ж логіки бюджетування. Більші моделі Qwen з можливістю обробки зображень є потужними, але для їх роботи на власному обладнанні потрібно більше VRAM та обчислювальних ресурсів, ніж це було доцільно для інфраструктури, яку команда оплачувала з бюджету MVP. Тож було обрано MiniCPM-V — значно меншу модель, яку Ollama може запускати на недорогому обладнанні без перевантажень, проте вона все ще достатньо якісна для структурованого вилучення інформації з зображень лабораторних звітів.

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

Що потрібно додати для реалізації

Описана вище архітектура визначає що потрібно обробити; процес виробництва все ще має вирішити як. Наступні кроки включають перетворення PDF-файлів на зображення, які може читати модель, структурування запиту та інструкцій до API Ollama, обережне парсування JSON у разі, якщо невелика модель відхиляється від запитаного формату, а також використання Redis Streams у робочому процесі на Go для надійної обробки звітів у міру зростання обсягу даних.

Ключові висновки

• Визначте результат, який вам потрібен (тут: назва, значення, одиниця вимірювання, діапазон значень), перш ніж порівнювати інструменти; сирий текст, отриманий за допомогою OCR, та структуровані дані — це різні продукти з різною вартістю.
• Вибирайте мову для всієї системи, а не лише ту, яка має найбільшу кількість бібліотек для окремого компонента.
• Порівнюйте хмарні опції за еквівалентним результатом, а потім оцінюйте ліміти витрат, ізоляцію даних та квоти разом із загальною ціною.

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

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