Поддерживаемые форматы документов при распознавании

Что на самом деле означают поддерживаемые форматы документов при распознавании

Когда речь заходит про поддерживаемые форматы документов при распознавании, заказчик обычно имеет в виду список расширений: PDF, JPEG, PNG, TIFF, иногда HEIC со смартфонов. Это верхний слой, но он не описывает задачу целиком. Инженерно формат распадается на три независимых уровня: контейнер файла, физическое качество носителя и семантический тип самого документа. Каждый уровень обрабатывается своим этапом конвейера, и сбой на любом из них даёт нечитаемый результат при формально «поддерживаемом» расширении.

В практике ZoomApps мы разделяем эти уровни с самого начала интеграции. Одно расширение PDF скрывает как минимум два разных объекта: текстовый PDF, где символы уже присутствуют как данные, и PDF-обёртку над сканом, внутри которой лежит растровое изображение без единого извлекаемого знака. Первый разбирается парсером слоёв, второй требует полноценного распознавания документов через оптическую модель. Пользователь в обоих случаях видит файл с иконкой PDF, а система обязана различать их автоматически.

Растровые входы: сканы, фотографии и мобильная съёмка

Основной поток в финсекторе Казахстана — это не аккуратные сканы, а фотографии, сделанные клиентом на телефон в отделении или через мобильное приложение. Такой вход приходит в JPEG или HEIC, с перспективными искажениями, бликами от ламинирования и неравномерной подсветкой. Формат файла тут поддерживается тривиально, но без геометрической коррекции, устранения бликов и выравнивания страницы модель распознавания получает мусор. Поэтому предобработка — детекция границ листа, разворот, бинаризация — входит в понятие поддержки формата не меньше, чем сам декодер.

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

Структурированные и многостраничные документы

Чем сложнее документ, тем меньше значит расширение файла и тем больше — модель его структуры. Банковские выписки приходят и как выгруженный из интернет-банка PDF с ровными таблицами, и как фотография распечатки. Для первого варианта разумно читать табличные координаты напрямую, для второго — восстанавливать сетку строк и колонок по изображению. Один целевой формат вывода, разные конвейеры на входе; заказчику важно, чтобы на выходе в обоих случаях получился один и тот же структурированный набор операций с датами и суммами в тенге.

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

Языки, кодировки и национальные идентификаторы

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

Национальные идентификаторы — ИИН и БИН — это отдельный поддерживаемый формат данных внутри документа. Двенадцать цифр ИИН несут контрольную структуру, по которой извлечённое значение можно валидировать сразу после распознавания и отбраковать явную ошибку модели. То же касается сумм в тенге, дат в принятом формате и номеров документов. Проверка на уровне доменных правил превращает сырой распознанный текст в данные, которым можно доверять в процессах KYC и открытия счёта.

Что происходит с форматом внутри контура клиента

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

Финальный слой — структурированный вывод, согласованный с учётными системами. Распознанный документ отдаётся не как картинка с текстом, а как набор полей в JSON, готовый к загрузке в 1С или в банковскую АБС. Здесь список поддерживаемых форматов замыкается: на входе — разнородные PDF, сканы и мобильные фото, на выходе — единая типизированная структура. Именно эта пара, широкий вход и строгий выход внутри изолированного периметра, определяет, насколько распознавание применимо в реальном документообороте, а не в демонстрации.

Хотите увидеть распознавание на своих документах? Посмотрите что умеет ZoomApps или сразу напишите нам в WhatsApp — покажем на демо.