Распознавание рукописного текста: честный план HTR

Что именно значит HTR для анкет и заявлений

HTR (Handwritten Text Recognition) в анкетах и заявлениях - это способ превратить рукописные ответы на бумаге в структурированные данные: ФИО, адрес, ИИН, номер телефона, суммы, даты, отметки в чекбоксах. Цель обычно простая: чтобы данные можно было искать, проверять, загружать в учетную систему и не перепечатывать вручную.

Важно не путать HTR с привычным OCR для печатных документов. OCR хорошо работает с ровным шрифтом и стабильной версткой. Рукопись меняется от человека к человеку: наклон, связность букв, пропуски, исправления, разные способы писать цифры. Поэтому обещание «распознать все на 100%» для рукописных полей почти всегда нереалистично, особенно в потоке.

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

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

Рабочий сценарий выглядит так: система уверенно распознает ИИН и дату, но сомневается в названии улицы из-за помарки. Тогда запись уходит в ручную валидацию только по одному полю, а не целиком. Именно так и появляется скорость: HTR делает основную работу, а человек подтверждает то, где риск ошибки выше.

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

Где HTR действительно работает, а где нет

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

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

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

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

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

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

Форма, качество изображения и разметка полей

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

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

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

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

Ключевой прием в проектах - разметка зон до распознавания. Сначала документ «режут» на поля (серия, номер, дата, ФИО, адрес), затем каждая зона идет в свой распознаватель и свои проверки.

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

Как выбрать подход: HTR, ICR, правила и проверки

Выбор проще, если сразу разделить анкету на типы полей. Не весь документ требует нейросети. Часто 60-80% ценности дают «земные» вещи: правильная разметка, проверка форматов и понятный процесс ручной валидации.

Когда достаточно правил и ICR

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

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

ICR обычно хватает, когда поле состоит из цифр или коротких печатных символов, а рукопись похожа на заполнение «по клеточкам». Пример: человек вписывает 12 цифр ИИН по одной в каждую ячейку. Здесь часто надежнее ICR по цифрам плюс строгая валидация, чем попытка тянуть туда сложный HTR.

Когда нужен HTR и как их сочетать

HTR нужен там, где начинается произвольная рукопись: ФИО, адрес, место работы, комментарии, причины обращения. Особенно если в одном поле встречаются буквы и цифры (например, «мкр 12, д. 7/2») и почерки сильно отличаются.

На практике надежнее всего работает связка:

1. правила и проверки (формат, справочники, диапазоны);
2. распознавание для оставшихся полей (ICR для цифр, HTR для рукописи);
3. ручная валидация только «сомнительных» мест (низкая уверенность или конфликт с правилами);
4. сохранение исправлений как обучающих примеров.

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

Пример проекта: оцифровка 10 000 заявлений в месяц

Типичный поток: поликлиника принимает заявления на прикрепление или согласие на обработку данных, либо банк - на выпуск карты. В день это 300-500 бланков, и часть из них нужна в системе «сегодня», а не через неделю. Главные риски понятны: очереди из-за ручного ввода, пропуски символов, перепутанные даты и «тихие ошибки», которые всплывают только при сверках.

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

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

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

В пилоте успех лучше считать не по средней точности модели, а по показателям процесса: среднее время на документ (до и после), доля полей без правок, число исправлений на 100 документов и где они возникают, процент документов, ушедших в ручную проверку, соблюдение SLA по срокам (например, 95% в тот же день).

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

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

Данные для обучения и теста: что собирать и как размечать

Качество HTR почти всегда упирается не в модель, а в то, какие примеры вы ей показали. Для анкет и заявлений важнее всего разнообразие: люди пишут по-разному, отделения сканируют по-разному, а бланки со временем «плывут».

Начните со сбора пакета документов, похожего на реальный поток. Не берите только «идеальные» сканы из одного кабинета. В наборе должны быть и хорошие, и средние, и проблемные случаи.

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

Дальше нужен эталон - «как правильно». Разметку лучше делать по полям, а не сплошным текстом: ФИО, дата, адрес, номер документа и так далее. Важно заранее решить, кто отвечает за правильность значения. Частая ошибка - отдавать разметку только оператору ввода без проверки: он работает быстро, но может «додумывать» по привычке.

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

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

Такая договоренность делает результаты сравнимыми и сильно упрощает приемку.

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

Внедрение HTR в реальные анкеты и заявления лучше строить как конвейер с понятными «входами» и «выходами». Тогда заранее видно, где появятся ошибки, и не приходится лечить качество распознавания там, где проблема в скане.

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

Дальше документ нужно «разложить по полям». Это делается по шаблону (если форма фиксированная) или авторазметкой (если вариантов много). Главная цель - чтобы HTR видел не весь лист, а конкретные зоны: ФИО, адрес, номер, дата.

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

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

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

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

Как строить ручную валидацию и контроль качества

Ручная валидация - не «запасной вариант», а нормальная часть проекта. Без нее качество будет плавать, а ошибки начнут попадать в учетные системы.

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

Интерфейс оператора решает многое. Рядом с распознанным значением показывайте оригинальный фрагмент поля, а не весь скан. Добавьте простые подсказки вроде «ожидается 12 цифр», «только кириллица», «формат даты ДД.ММ.ГГГГ». Так оператор тратит секунды, а не минуты.

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

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

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

Метрики, приемка и честная фиксация ограничений в ТЗ

Чтобы проект не превратился в спор «похоже или нет», договоритесь о метриках и правилах приемки до пилота. В требованиях важно фиксировать качество не «в среднем», а по конкретным полям и типам документов.

Метрики, которые реально помогают

В анкетах и заявлениях полезно измерять качество на двух уровнях: по полям и по потоку обработки. Тогда видно не только точность распознавания, но и экономию времени.

• CER (точность по символам) для свободного текста, где важны буквы.
• Field accuracy (точность значения поля): дата, ИИН/номер, сумма, ФИО.
• Доля автопрохождения: процент документов, ушедших дальше без ручной правки.
• Среднее время на документ в ручной проверке (и отдельно на «трудные» случаи).
• Операционные потери: возвраты на перескан, доля документов, где распознавание невозможно из-за качества изображения.

Критерии приемки задавайте по классам: отдельно для числовых полей, отдельно для дат, отдельно для ФИО, отдельно для адресов. И отдельно по типам бланков или версиям форм. Иначе хорошая средняя цифра легко «спрячет» провал по критичным полям.

Как записать ограничения без споров

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

Чтобы приемка была прозрачной, заведите протоколы тестирования: состав тестовой выборки, способ разметки эталона, правила подсчета метрик и пороги по каждому полю. Укажите периодичность повторных замеров (например, раз в квартал и после смены бланка или сканера) и регрессионный тест на одной и той же контрольной выборке.

Частые ошибки и ловушки при внедрении HTR

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

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

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

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

Наконец, недооценивают изменчивость потока. Меняются бланки, появляются новые ручки и маркеры, подключаются новые подразделения со своими привычками. Если не заложить процесс обновления правил и периодической донастройки, качество будет медленно снижаться.

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

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

Быстрый чеклист и следующие шаги для проекта

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

Короткий чеклист перед стартом:

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

Дальше стоит сделать пилот на реальном потоке, а не на «идеальных» примерах. За 2-4 недели обычно реально выбрать 1-3 типовые формы, собрать репрезентативную выборку (включая плохие сканы), разметить правильные ответы по ключевым полям и прогнать сквозной процесс от загрузки до выгрузки в вашу систему.

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

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

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