Распознавание двухколоночных двуязычных документов

Где обычный OCR ломается на двухколоночной вёрстке

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

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

Казахский и русский на одном листе: специфика документооборота Казахстана

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

Отдельная сложность — сам казахский алфавит. Специфические буквы (ә, ғ, қ, ң, ө, ұ, ү, һ, і) визуально близки к русским, и движок без языковой модели казахского регулярно подменяет их похожими кириллическими символами. Если распознавание идёт единой моделью на смешанном потоке, точность падает именно на этих знаках, а они встречаются в фамилиях, адресах и наименованиях. Поэтому язык колонки лучше определять до символьного распознавания и подключать соответствующую языковую модель для каждой колонки отдельно.

Практика ZoomApps показывает, что устойчивый результат даёт конвейер, где определение раскладки, сегментация колонок и языковая маршрутизация выполняются как самостоятельные шаги перед OCR. Такой подход применим ко всей линейке задач распознавания документов — от типовых форм до сложной юридической вёрстки.

Как устроено распознавание двухколоночных двуязычных документов

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

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

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

Структурированный вывод: ИИН, БИН и суммы в тенге

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

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

Изолированное развёртывание в контуре клиента

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

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

Интеграция с 1С и процессами KYC

Структурированный вывод рассчитан на прямую передачу в учётные и скоринговые системы. Извлечённые реквизиты договоров, суммы и данные удостоверений отдаются в форматах, которые принимает 1С и внутренние KYC-модули, что убирает ручной ввод и связанные с ним опечатки. При проверке клиента система сопоставляет данные из удостоверения и договора, а расхождения между казахской и русской редакциями фиксирует до того, как документ уйдёт в дело.

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

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