Как локальный AI распознаёт сложные архивные документы

Локальная система OCR превращает закрытые сканы и PDF в текст и структурированные данные прямо на сервере организации. Внедрённое решение не полагается на одну «волшебную» модель: оно различает типы страниц, выбирает подходящий способ обработки и направляет сомнительные поля сотруднику.

Это важно для архивов, где встречаются старые копии, сложная вёрстка, таблицы, печати и рукописные фрагменты. На таких материалах средняя точность по всем символам мало что говорит о реальной пользе. Ошибка в одной сумме, дате или номере может быть важнее десятка неверных запятых.

Какую задачу получил заказчик

Организации требовалось извлекать данные из документов, которые нельзя передавать внешнему AI-провайдеру. Ручная обработка занимала время, а обычный OCR хорошо работал только на наиболее чистых страницах.

После внедрения процесс выглядит так:

1. сотрудник загружает документ во внутреннюю очередь;
2. система определяет тип и качество страниц;
3. каждая страница идёт по подходящему маршруту распознавания;
4. текст, таблицы и поля показываются рядом с оригиналом;
5. сомнительные места попадают в очередь проверки;
6. подтверждённый результат передаётся в архив или учётную систему.

Документ на всём пути остаётся в инфраструктуре заказчика.

Почему одной модели недостаточно

Документы отличаются не только качеством изображения. На одной странице может быть сплошной печатный текст, на другой – таблица с объединёнными ячейками, на третьей – рукописная пометка поверх печати.

Модель, сильная на обычном тексте, может разрушить таблицу. Универсальная визуально-языковая модель лучше понимает расположение элементов, но иногда формулирует правдоподобный ответ вместо точного чтения символов. Поэтому рабочая система сначала классифицирует страницу, а затем выбирает маршрут.

Исследование olmOCR показывает, как визуально-языковая модель может сохранять структуру разделов, таблиц, списков и формул. В описанном внедрении этот класс моделей используется не как единственный источник истины, а как один из специализированных инструментов.

Что именно проверяет человек

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

• суммы, даты и номера;
• строки таблиц с нарушенной структурой;
• рукописные фрагменты;
• поля, по которым разные модели дали разные ответы;
• страницы слишком низкого качества;
• обязательные реквизиты, которые не удалось найти.

Исходный ответ модели хранится отдельно от исправленного. Это позволяет видеть реальные причины ошибок и не путать качество системы с результатом последующей ручной вычитки.

Как качество связано с бизнесом

Для текстового архива можно считать долю правильно распознанных символов или слов. Для автоматизации процесса нужны дополнительные показатели.

Контрольный набор составляется из реальных типов документов заказчика. Публичный результат модели на англоязычном наборе не заменяет эту проверку: даже официальный набор olmOCR-bench отражает другую предметную область и другой язык.

Как решение адаптируется под другую компанию

Готовое ядро не нужно писать заново. Под нового заказчика настраиваются:

• виды документов и обязательные поля;
• словари организаций, товаров и отраслевых терминов;
• правила проверки чисел и таблиц;
• роли сотрудников и маршрут согласования;
• сроки хранения исходников и результатов;
• выгрузка в архив, ERP, 1С или другую систему.

Например, для бухгалтерского процесса важны суммы, валюты и реквизиты сторон. Для технического архива – обозначения, номера объектов и связь текста с чертежом. Это одна платформа, но разные правила качества.

Техническим специалистам

На локальном GPU-сервере работают несколько OCR- и VLM-моделей. Сервис подготовки приводит PDF и изображения к воспроизводимому виду, а маршрутизатор выбирает модель по типу страницы. Вместе с результатом сохраняются версия модели, параметры запуска и контрольная сумма входного файла.

Критичные поля проходят обычные программные проверки. Арифметический итог таблицы, формат даты или контрольная сумма номера не поручаются языковой модели, если это можно надёжно проверить кодом.

Обновление модели сначала прогоняется по неизменному контрольному набору. Только после сравнения ошибок новая версия становится рабочей. Такой подход соответствует общей идее NIST AI RMF: управлять нужно не абстрактной «умностью модели», а риском конкретного применения.

Итог

Рабочий OCR для сложного архива – это не кнопка «распознать». Это управляемый процесс: локальная обработка, несколько маршрутов, отдельная проверка важных полей и понятная интеграция с системой, где данные будут использоваться дальше.

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