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

Однієї мультимодальної моделі «зір + мова» (VLM, Vision-Language Model) на весь аркуш мало. Спочатку геометрія, порожні комірки й вирізані області — потім читання.

Локальний комп’ютерний зір (CV, Computer Vision) і оптичне розпізнавання символів (OCR) потрібні навіть за слабкої точності на рукописі. У пілоті етап CV/OCR на рукописних замірах давав близько 35% точності — цього недостатньо для приймання, але достатньо, щоб знати, де таблиця, де чорнило і куди вішати оцінку надійності.

Кілька проходів vision LLM + перевірка другою моделлю зменшують мовчазні помилки краще, ніж одна «впевнена» відповідь.

Оцінка надійності — продукт, а не побічний бал. Ваги сигналів, доменні правила й жорстка заборона статусу ok для неоднозначних десятих ,5 / ,6 / ,7 важливіші за гарний промпт.

Звіт для перевірки (HTML/CSV) — межа продукту до ERP. Оператор виправляє сумнівне, а не перебиває весь аркуш знову.

Еталонний набір і порівняння моделей потрібні з першого дня пілота — інакше неможливо чесно порівняти «дешевий» і «дорогий» режим.

Донавчання (TrOCR / CRNN) — опційний шлях, не заміна системної архітектури. Розбір моделей цифр — в окремій статті «від CNN до TrOCR».

Завдання і ціна помилки

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

Ціна помилки тут ближча до промислової безпеки й якості обліку, ніж до друкарської помилки в інтерфейсі. Тому в пілоті ми одразу відмовились від схеми «відправили весь JPG у чат із моделлю → вставили відповідь в ERP». Потрібен контур, де сумнівне видно і не приймається мовчки.

Той самий принцип — «низька впевненість розпізнавання не повинна тихо потрапляти далі» — описаний і для корпоративного завантаження документів у завантаження документів у RAG. Тут домен інший (бланк УЗТ, не скан політики в PDF), але дисципліна та сама.

Чому не «весь аркуш в одну VLM»

Здається природним: сучасна модель «зору» «бачить» сторінку, навіщо різати? На практиці цілий бланк — поганий вхід для промислового пілота.

На одному аркуші змішані друкована шапка, QR-код, напівдруковані відомості рядків і щільна сітка рукописних замірів. Різні зони потребують різної уваги: у шапці мало полів, але виконавець часто нерозбірливий; у сітці — сотні дрібних цифр, де критичні десяті частки (12,3 проти 12,8). Одна модель на весь кадр легко «згладжує» порожні комірки, плутає рядки й видає правдоподібний JSON без прив’язки до геометрії.

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

flowchart LR
  photo[PhotoForm] --> cv[LocalCV_OCR]
  cv --> vlm[MultiPass_VLM]
  vlm --> conf[ConfidenceFusion]
  conf --> review[OperatorReview]
  review --> erp[ERP_Phase2]

Етап CV: геометрія важливіша за «вгадайку»

Перший етап виконується локально: нормалізація фото, корекція перспективи, QR-код, пошук таблиці, пошук чорнила, чорновий OCR. Оркестрація на TypeScript, важка частина комп’ютерного зору на Python (PaddleOCR для друкованого, EasyOCR як підказка з рукопису).

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

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

Режими роботи в пілоті варто розділяти явно:

Цифри за точністю й грошима нижче — з внутрішніх замірів на еталонному аркуші пілота; на інших бланках картина буде іншою, поки еталонний набір малий.

Кілька проходів vision LLM і перевірка другою моделлю

На другому етапі в хмару йдуть не «весь аркуш», а вирізані області. Три проходи:

1. шапка (дата, виконавець, прилад);
2. відомості рядків (зона, тип елемента, діаметри, проєктна/відбракувальна товщина);
3. сітка замірів за секціями.

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

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

Оцінка надійності як продукт

Підсумкова оцінка поля — зважена сума сигналів (ваги з пілотної моделі; у коді нормалізуються за наявними сигналами):

Статуси для оператора (пороги за замовчуванням):

Доменні правила не менш важливі, ніж модель: товщина в розумному діапазоні (у пілоті за замовчуванням приблизно 0.5–80 мм), дата в очікуваному форматі, тип елемента зі словника. Занадто «велике» число після OCR часто виявляється злиттям сусідніх цифр — такі значення краще скинути, ніж мовчки прийняти.

Жорстке правило для десятих часток

У кириличній рукописі десяті ,5, ,6 і ,7 часто нерозрізнювані. У пілоті такі значення ніколи не отримують статус ok автоматично — лише review або error, якщо моделі ще й не згодні. Краще зайва жовта комірка, ніж тиха помилка в міліметрах стінки.

Звіт для перевірки — межа продукту до ERP

На виході прогону — не лише JSON. Файл review.html візуально повторює бланк із кольоровою підсвіткою; review.csv зручний для Excel; result.json несе значення, оцінку надійності, статус і розбір сигналів.

Типовий набір артефактів на одне фото:

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

Вивантаження в ERP свідомо відокремлене. Поки контракт нестабільний, в артефактах лежить заглушка legacy-payload. Змішувати пілот розпізнавання і контракт обліку в робочій системі — швидкий спосіб зламати обидва контури.

Окремо важливо не плутати ролі:

• редактор еталонів — лабораторія якості й розмітки;
• інтерфейс оператора — робочий перегляд і правка перед обліком;
• правки з робочої системи не повинні автоматично ставати еталоном без явного переведення в еталонний набір.

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

Еталони, оцінка і порівняння моделей

Без еталонної розмітки будь-яка розмова про «97%» — маркетинг. У пілоті еталонний набір на момент замірів був маленьким (одиниці аркушів) і розширюється. Це обмеження потрібно казати вголос: цифри нижче — орієнтир на конкретному еталонному бланку, не гарантія на всьому архіві.

Порівняння режимів на еталонному аркуші (~313 полів) із внутрішніх замірів пілота:

За ~97% на 313 полях лишається порядку 8–10 комірок на ручну правку. За ~70% — порядку 90. Вибір моделі — це вибір обсягу ручної роботи й бюджету API, а не пошук «єдино правильної» нейромережі.

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

Стек пілота публічно можна назвати без деталей замовника: TypeScript і Python, схема відповіді через zod, обробка зображень, локальний OCR, хмарні моделі «зору» через сумісний API. Близько половини коду оркестрації — TypeScript, близько третини — Python. Це важливо для команд, які думають, що «OCR = один скрипт на Python»: промисловий бланк майже завжди перетворюється на сервіс із контрактами, звітами й оцінкою якості.

Що ще не закрито

• Інтеграція з ERP — фаза 2; контракт вивантаження стабілізуємо окремо від пілота розпізнавання.
• Калібрування порогів оцінки надійності на більшому еталонному наборі.
• Прохід перевірки другою моделлю і вартість — перевірка кожної комірки другою моделлю дорожча; потрібна економна політика (коли перевірка обов’язкова, коли достатньо сигналів).
• Шлях донавчання (TrOCR / CRNN) — заділ є; це не заміна гібридного контуру. Практичний розбір моделей — у статті про рукописні цифри.
• Якість фото — попередня обробка компенсує частину кутів і тіней; сильні відблиски й зім’ятий папір усе ще ронять якість.

Типові помилки команд зі схожими бланками

Згодувати весь аркуш одній моделі й назвати це пілотом. Отримаєте демонстрацію на одному гарному фото й регрес на архіві.

Оцінювати лише «загальну точність». Без розбиття на шапку / рядки / сітку / порожні комірки ви не побачите, де система реально ламається.

Довіряти самооцінці моделі. «Я впевнений на 0.92» без згоди другої моделі й доменних правил — слабкий сигнал.

Автоматично приймати неоднозначні десяті. У промконтролі це дорожче, ніж зайвий клік оператора.

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

Обіцяти ERP «на наступному тижні», поки немає стабільного JSON і звіту для перевірки. Спочатку контракт полів і статусів — потім шина обміну.

Що зробити сьогодні

1. Зафіксуйте контракт полів бланка і ціну помилки за кожним типом (замір, дата, тип елемента, порожньо).
2. Зберіть міні-еталон (хоча б кілька реальних фото) і рахуйте метрики за зонами, не однією цифрою.
3. Розділіть контур на геометрію → читання → оцінку надійності → перевірку людиною; не пропускайте перевірку «тому що модель розумна».
4. Введіть хоча б одне жорстке доменне правило (діапазон, формат, заборона автоматичного ok на відомих плутанинах почерку).

Часті запитання

Підсумок

Чи варто уваги команді зі схожими промисловими бланками? Так — якщо ви готові будувати контур, а не шукати одну магічну модель. У пілоті вже працює зв’язка локального CV/OCR, багатопрохідної моделі «зору», злиття оцінок надійності і звіту для оператора. Ще не закриті фаза ERP, розмір еталонного набору й калібрування порогів — і це нормально казати вголос.

Головний урок практики простий: краще жовте поле на перевірку, ніж тиха помилка в міліметрах.