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

Почему «точность» — это не одна цифра

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

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

Символьная и пословная точность: CER и WER

Самая низкоуровневая метрика — символьная ошибка, CER (character error rate). Она считается как расстояние Левенштейна между распознанной строкой и эталоном, делённое на длину эталона: сумма вставок, удалений и замен символов относительно того, сколько символов должно было быть. Пословный аналог WER устроен так же, но единицей считается слово. Обе метрики удобны для сравнения моделей между собой, но плохо отражают бизнес-результат: замена одного символа в примечании к платежу и замена одного символа в ИИН дают одинаковый вклад в CER, хотя последствия несопоставимы.

Поэтому символьную точность мы используем как инженерный индикатор качества самой модели OCR, а не как приёмочный критерий. Она показывает, деградирует ли распознавание на плохих сканах, рукописных пометках или смешанном казахско-русском тексте, но не отвечает на вопрос, можно ли доверять извлечённому значению суммы или номера договора.

Как измеряется точность распознавания на уровне полей

Для прикладных задач точность распознавания измеряется не по символам, а по полям — по тем структурированным значениям, которые система должна вернуть: ИИН, БИН, номер и дата документа, сумма, валюта, наименование контрагента. Каждое извлечённое поле сравнивается с эталоном по принципу «верно или нет» целиком: ИИН из двенадцати цифр считается распознанным правильно только если совпали все двенадцать. Частичное совпадение здесь не засчитывается, потому что в 1С или в KYC-анкету значение попадает целиком.

На уровне полей работают три метрики. Precision показывает, какая доля извлечённых значений оказалась верной, — это защита от ложных данных, попавших в учётную систему. Recall показывает, какую долю нужных полей система вообще нашла и заполнила, — это защита от пропусков. F1 — их гармоническое среднее, единый показатель для сравнения версий. Для потока договоров разумно требовать высокого recall по реквизитам сторон, а для платёжных полей — высокого precision, потому что молчаливая ошибка в сумме обходится дороже, чем поле, отправленное на ручной ввод.

Эталонная разметка: с чем сравнивают

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

Отдельный вопрос — правила нормализации при сравнении. Дата «01.02.2026» и «1 февраля 2026 г.» — это одно значение или два разных? Суммы «1 500 000,00» и «1500000» совпадают? Прежде чем считать точность, нужно договориться, что именно считается совпадением: как приводятся пробелы в разрядах, символ тенге, регистр в наименованиях. Без явных правил нормализации две команды получат разные проценты на одних и тех же данных.

Порог уверенности и доля документов без ручной проверки

Верно ли поле, система знает не всегда, но она оценивает собственную уверенность — confidence. Это позволяет ввести порог: значения выше порога уходят в учётную систему автоматически, ниже — на ручную проверку оператором. Настройка порога — это управление балансом между двумя ошибками. Слишком высокий порог отправляет на проверку почти всё и обесценивает автоматизацию; слишком низкий пропускает ошибочные значения в 1С.

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

Специфика казахстанских документов

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

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

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