Сравнение OCR: ABBYY, Tesseract и Google Document AI

Что именно вы хотите улучшить: текст, поля или процесс

Многие говорят: «нужен OCR», но под этим часто скрываются разные задачи.

Первая - просто получить читаемый текст из скана, чтобы по нему искать и копировать фрагменты.

Вторая - извлечь конкретные поля: ИИН/БИН, номер счета, дату, сумму, адрес, ФИО.

Третья - улучшить весь процесс: кто сканирует, как проверяют, куда данные уходят дальше и что происходит при ошибке.

Одна и та же система может показывать разную точность на разных бланках. Причины обычно простые: качество сканов, язык и шрифты, печати и подписи поверх текста, таблицы, перекос страницы, разная верстка у поставщиков. Поэтому, сравнивая ABBYY, Tesseract и Google Document AI, фиксируйте не только «тип документа», но и его вариации.

Прежде чем мерить качество, решите, что важнее именно вам: полнота (вытащить максимум, даже с лишним), точность (реже ошибаться, даже если часть пропустить) или скорость (быстрее обработка, но больше спорных мест). Для архивного поиска важнее полнота текста, для бухгалтерии и договоров - точность полей.

Заранее ответьте на несколько вопросов:

• Что нужно на выходе: сплошной текст или значения полей с оценкой уверенности?
• Какие поля критичны, а какие можно оставить на ручной ввод?
• Где ошибка обходится дороже всего: в деньгах, времени или рисках?
• Какая доля документов допустимо уходит на проверку?

Ошибки OCR становятся реальными потерями, когда попадают в операционную часть. Неверная сумма в счете ведет к возвратам и сверкам, перепутанная дата - к просрочкам, ошибка в ИИН/БИН - к отклонению заявки и повторной подаче. Поэтому «оценка точности OCR» должна быть привязана к последствиям, а не к красивому проценту в отчете.

Ваши шаблоны и требования: как зафиксировать задачу

Чтобы сравнение было честным, сначала зафиксируйте, какие документы вы распознаете и что хотите получить на выходе. Без этого любое «точность 98%» мало что значит: у счетов, актов и анкет разные риски и разная цена ошибки.

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

Дальше разделите документы на «шаблоны». Это не только про одинаковую верстку, но и про предсказуемость. Счета от одного поставщика часто выглядят одинаково. Счета от 50 поставщиков - это уже «класс документов», где поля могут быть в разных местах.

Затем опишите требования к полям и правилам проверки. Обычно достаточно короткой спецификации на 1-2 страницы:

• Тип документа и шаблон (например, «счет, поставщик А» или «анкета, разные источники»)
• Обязательные поля (ИИН/БИН, дата, сумма, номер документа, наименование)
• Формат и ограничения (ИИН - 12 цифр, дата - ДД.ММ.ГГГГ, сумма не может быть отрицательной)
• Допуски (пробелы, запятые в суммах, «O» вместо «0»)
• Приоритет ошибок (что критично, а что допустимо)

Последний шаг - определить, что считать успехом. Для анкеты это может быть «все обязательные поля заполнены и проходят валидацию», а для счетов - «сумма, дата и ИИН распознаны без ошибок». Простой пример: если из 1 000 документов 20 не прошли проверку ИИН, это не просто 2% ошибок, а 20 кейсов, которые попадут в ручную обработку и повлияют на стоимость процесса.

Как измерять точность, чтобы цифры были честными

Точность OCR легко «улучшить» на бумаге, если мерить не то. Сначала определите, что вы оцениваете: сплошной текст (например, договор), отдельные поля (счет) или итоговый процесс (провести документ без возвратов). Тогда и метрики будут честными.

Для сравнения систем обычно хватает трех уровней:

• По символам (character accuracy): хорошо показывает качество текста, но может скрыть критичные ошибки внутри одного поля.
• По словам (word accuracy): ближе к восприятию человека, но «1 000,00» и «1000,00» могут считаться одним словом и запутать оценку.
• По полям (field accuracy): самый полезный вариант для ввода данных, потому что оценивает то, что реально уходит в учетную систему.

Договоритесь, что считается ошибкой. Пропуск, лишний символ и замена символа - это очевидно. Но на практике «ломают» качество мелочи: неверная запятая в сумме, перепутанный минус, «0» вместо «O» в ИИН/БИН. Для полей удобно считать ошибкой любой результат, который меняет смысл или не проходит валидацию.

Отдельно задайте правила форматирования: даты (01.02.2026 vs 1/2/26), валюты, пробелы в разрядах, лидирующие нули в кодах, регистр букв. Если вам важно хранить «000123», то «123» - ошибка, даже если «по смыслу» верно.

Confidence полезен как подсказка, но ему нельзя верить вслепую. Высокая уверенность бывает и у неправильно распознанной суммы, если шаблон выглядит «типично». Лучше использовать confidence как триггер контроля качества: отправлять на проверку поля ниже порога и поля, которые не прошли простые проверки (формат даты, длина номера, контрольная сумма).

Подготовка тестового набора и эталона

Сравнение OCR почти всегда ломается не на модели, а на данных. Если тестовый набор маленький или в нем только «идеальные» сканы, вы получите красивые цифры, которые не повторятся в работе.

Начните с выборки по каждому шаблону. Если у вас 5 типов документов (например, счет, акт, заявление, договор, накладная), берите минимум по нескольку десятков документов на каждый тип. Важно, чтобы они были из реального потока: разные отделы, разные МФУ и сканеры, разные годы, разное качество печати.

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

Проверьте, что набор действительно «живой»: присутствуют разные качества сканов, встречаются версии шаблонов (старые бланки, новый логотип, новый шрифт), есть документы с рукописными пометками, если это типично, и понятно, к какому шаблону относится каждый файл.

Если в документах есть персональные данные, анонимизируйте их так, чтобы не сломать разметку. Лучше закрывать значения, но сохранять длину и формат (например, маска вместо ИИН и номера телефона), иначе метрики по полям станут нечестными.

Дальше нужен эталон (ground truth) - правильный текст и правильные значения полей. Определите, кто размечает: операторы, бухгалтерия, архив или отдельная команда. Практичный вариант - двойная проверка: один размечает, второй выборочно перепроверяет спорные места.

Простой пример: если вы тестируете извлечение ИИН, суммы и даты из заявлений, заранее договоритесь, что считать «правильно» (формат даты, разделитель тысяч, валюта, округление). Без этих правил два человека сделают «верно», но по-разному, и к цифрам будет меньше доверия.

Пошаговый план сравнения на ваших документах

Начните с базового прогона: одинаковый набор файлов в каждом OCR, без тонких настроек. Это даст отправную точку и быстро покажет, где качество проседает из-за сканов, шрифтов, печатей или фото с телефона.

Дальше переходите от «распознать текст» к «достать нужные поля». Для счетов, заявлений, накладных и медформ важны конкретные значения (номер, ИИН/БИН, дата, сумма, адрес, строки таблицы). Настройка может быть разной: зоны на странице, поиск по ключевым словам, правила для дат и сумм, разбор таблиц. Смысл один: проверять не абстрактный текст, а то, что реально идет в систему.

Чтобы сравнение было повторяемым, зафиксируйте условия теста:

• один и тот же тестовый набор и одинаковая предобработка (поворот, удаление шума, DPI)
• версии движков или моделей, язык распознавания, включенные режимы
• единые правила постобработки (нормализация дат, пробелов, разделителей)
• одинаковый формат вывода (JSON, CSV, таблица)

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

Оформите итоги в простой таблице: по шаблонам, по полям и по типам ошибок. Например: «путает 0 и О», «не видит текст под печатью», «съезжает таблица», «путает ИИН и номер документа». Так становится видно, что лечится настройкой, что - качеством скана, а что требует другого подхода к извлечению.

Если вы внедряете ввод документов в организации (госструктуры, банки, образование), такой протокол удобно сразу согласовать с ИТ и службой качества. В проектах системной интеграции это экономит время на повторные прогоны и споры о результатах.

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

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

Порог confidence: что блокировать, а что пропускать

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

Для ИИН/БИН, номера счета, суммы и даты нужен высокий порог: если confidence ниже, документ уходит в очередь оператора. Для второстепенных полей (комментарий, адрес, название отдела) порог можно снизить или не блокировать поток, а только помечать риск.

Чтобы это работало устойчиво, используйте двухконтурную проверку:

• Контур 1: автоматическая валидация и пороги confidence.
• Контур 2: оператор видит только поля с флагом риска, а не перепроверяет весь документ.

Правила валидации: ловим ошибки без оператора

Confidence помогает, но не спасает от логических ошибок. Поэтому добавьте простые правила, которые проверяют смысл.

Быстрый эффект обычно дают проверки формата и длины (ИИН/БИН - 12 цифр), диапазонов (дата не в будущем, сумма больше нуля, НДС в разумных пределах), контрольных сумм (где применимо), справочников (коды, МФО, БИК, названия организаций) и связей между полями.

Пример: в счете-фактуре OCR может уверенно распознать "8" вместо "3" в сумме. Confidence будет высокий, но правило "сумма = итог по строкам" поймает расхождение и отправит на проверку только это поле.

Журнал качества и обновления без хаоса

В эксплуатации важно не только исправлять отдельные ошибки, но и понимать, почему они появляются. Ведите журнал качества: доля документов с ручной проверкой, топ полей с ошибками, причины (плохой скан, новый шаблон, необычный шрифт). Добавьте выборочную проверку, например 1-3% документов даже при высоком confidence.

Обновления правил и шаблонов проводите как изменения в продукте: отдельная версия, тест на небольшом потоке, сравнение метрик до и после, и только потом раскатка на весь объем. Так точность растет без неожиданных сбоев.

Как посчитать стоимость на 1 000 документов

Чтобы сравнение было честным, считайте стоимость не только по прайсу, а по полной цене владения на одинаковом объеме и одинаковом качестве. Удобная единица - 1 000 документов (или 1 000 страниц, если документы разной длины). В расчет заранее заложите целевой SLA: сколько документов в час и какое время ответа нужно бизнесу.

Соберите затраты в один шаблон. Обычно хватает четырех блоков: платежи поставщику, инфраструктура, трудозатраты, потери от ошибок.

Платежи за распознавание включают лицензию или подписку, тарификацию за страницу или пакет, оплату API-вызовов, доплаты за извлечение полей или классификацию.

Инфраструктура - это серверы или облако, хранение сканов и результатов, резервное копирование, сеть, мониторинг. При on-prem добавьте амортизацию и администрирование.

Люди - разметка эталона для теста, настройка шаблонов, поддержка после запуска, выборочная проверка оператором, обработка исключений.

Скорость обработки напрямую влияет на цену. Если нужно быстро, растут затраты на параллельные потоки, мощность машин или тарифы API. Если можно подождать, часть затрат снижается, но растут очереди и риск срыва сроков.

Практичная формула:

Итог за 1 000 документов = платежи за распознавание + инфраструктура на этот объем + часы людей x ставка + стоимость ошибок.

Полезно посчитать три сценария:

• Бюджетный: минимум настроек, больше ручной проверки, ниже требования по скорости.
• Базовый: настроенные шаблоны, выборочная проверка 5-10%, нормальная скорость.
• Премиум: максимальная точность по полям, строгий SLA, минимум ручного труда.

Так видно не «цену за страницу», а реальную стоимость обработки 1 000 документов при нужном качестве и сроках.

ABBYY, Tesseract и Google Document AI: на что смотреть в реальности

Смысл сравнения - не в красивых демо, а в том, как решение ведет себя на ваших сканах, ваших полях и вашем потоке.

Качество и работа с шаблонами

ABBYY часто выигрывает там, где нужны готовые компоненты для ввода документов и удобная настройка под формы. Если у вас много типовых бланков (заявления, счета, анкеты) и важны поля (ИИН, номера договоров, суммы), обычно проще быстрее дойти до стабильного результата: есть инструменты для правил, проверки и исправления.

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

Google Document AI удобен, когда важна скорость запуска и есть готовые модели под типы документов. Но качество нужно проверять на ваших примерах: модели могут отлично работать на одних шаблонах и заметно хуже на других, особенно если документы локальные, с нестандартной версткой или смешением языков.

Данные, развертывание и стоимость

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

Чтобы выбор не уперся в эмоции, заранее задайте короткие вопросы бизнесу и ИБ:

• Какие поля критичны и какая цена ошибки по каждому (например, сумма vs комментарий)?
• Можно ли отправлять документы в облако и какие есть ограничения по регионам хранения?
• Нужна ли работа 24/7 и как быстро должен быть отклик при сбое?
• Как будет проходить аудит: логи, доступы, хранение исходников и результатов?
• Какой ожидаемый объем: 1 000 документов в месяц или 100 000?

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

Типовые ошибки при пилоте OCR

Самая частая ошибка - сделать пилот «для галочки» и получить красивые, но бесполезные цифры. Обычно это случается, когда берут 10 документов, прогоняют через 2-3 движка и сразу выбирают «лучший». На малой выборке результат почти всегда случайный: один удачный скан может сильно поднять среднюю точность.

Вторая проблема - смешивать разные типы документов и источники в один тест. Сканы с МФУ в офисе, фото с телефона и выгрузки из архива ведут себя по-разному. Если не разделить тест по шаблонам и каналам (сканер, мобильная съемка, PDF из системы), вы не поймете, что именно ломает качество и где это лечится настройками.

Еще один перекос - свести все к одной цифре «точность OCR». Распознавание текста и извлечение полей - разные задачи. Можно идеально распознать абзацы, но регулярно ошибаться в ИИН, номерах счетов или датах. Для бизнеса важнее качество по критичным полям, а не общий процент символов.

Многие команды игнорируют плохие сканы, считая их «шумом». В реальности именно они создают очередь на ручную проверку. Иногда проще устранить причину (контраст, обрезка, поворот, единые настройки сканера), чем бесконечно донастраивать OCR.

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

Пример: из 1 000 счетов 12% требуют ручной проверки по сумме и БИН. Если не учесть эти минуты, «дешевый» движок может оказаться дороже в общей цене процесса.

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

Если начинать пилот без подготовки, результаты получаются шумными: разные типы документов смешаны, ошибки считаются по-разному, а стоимость считают только по лицензии, забывая про ручную проверку.

Перед стартом зафиксируйте минимум:

• Список шаблонов: какие документы входят в пилот и какие поля в них критичны.
• Эталон и правила: кто размечает, какой формат дат и сумм, что считается ошибкой.
• Три сценария: базовый (как сейчас), целевой (что нужно для запуска), худший (что делаем, если часть шаблонов проседает).
• Пороги confidence и проверки: где доверяем распознаванию, где просим оператора подтвердить, а где отправляем в повторную обработку или ручной ввод.
• Владелец качества после запуска: кто следит за метриками, кто обновляет шаблоны и правила, как быстро команда реагирует на новые формы.

Короткий пример: при обработке счетов и актов можно разрешить автопроведение только когда совпали ИИН/БИН и сумма, а дата и номер документа при низком confidence уходят на подтверждение.

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

Пример сценария и следующие шаги

Представьте пилот: 1 000 счетов от 5 поставщиков. У каждого счета свой шаблон, но вам нужны одни и те же 12 обязательных полей: ИИН/БИН, номер и дата, наименование поставщика, сумма без НДС, НДС, итог, валюта, номер договора, период, банковские реквизиты и назначение платежа. Цель - не просто распознать текст, а получить поля без ручной правки.

Чтобы сравнение было честным, договоритесь о правилах выборки и разметки. Возьмите документы в реальных пропорциях: например, 600 счетов от самого частого поставщика, 200 от второго и по 100 от остальных. Отдельно отметьте плохие сканы (смазы, тени, фото с телефона), чтобы понять, как системы ведут себя в худших условиях.

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

• Разметьте эталонные значения 12 полей вручную по четким правилам (формат дат, округление, пробелы, нули).
• Сделайте двойную разметку хотя бы для 10-15% документов и сверяйте расхождения.
• Зафиксируйте, что считается ошибкой: лишний пробел в ИИН/БИН, пропущенная копейка, неверная валюта и т.д.
• Разделяйте причины: ошибки распознавания текста, ошибки извлечения поля, ошибки бизнес-логики (например, неверная проверка НДС).

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

Переход от пилота к внедрению лучше оформлять как понятный SLA на поля, а не как «точность OCR вообще». Минимальный набор:

• целевая точность по каждому из 12 полей и допустимая доля документов на ручную проверку
• время обработки 1 000 документов и пиковая нагрузка
• правила эскалации, когда качество падает (например, появился новый поставщик)

Следующий шаг - короткий пилот на 200-300 документах, чтобы быстро проверить гипотезы, затем расчет инфраструктуры под нужную скорость и хранение.

Если вы разворачиваете решение on-prem и параллельно строите инфраструктуру под интеграцию и поддержку, это удобно планировать вместе с системным интегратором. Например, GSE.kz (gse.kz) поставляет рабочие станции, серверы и помогает с интеграцией ИТ-решений, что упрощает расчет мощности под очереди обработки и требования по доступности.