Ключевые выводы

Одной мультимодальной модели «зрение + язык» (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, размер эталонного набора и калибровка порогов — и это нормально говорить вслух.

Главный урок практики простой: лучше жёлтое поле на проверку, чем тихая ошибка в миллиметрах.