Привет, Хабр! Сегодня поговорим о документообороте и привлечении нейросетей к автоматизации этого процесса. HR‑отдел Сбера ежемесячно обрабатывает тысячи кадровых документов. Так, например, помимо приёма на работу необходимо поддерживать данные всех сотрудников в актуальном состоянии. Такую возможность предоставляет собственная HR‑платформа «Пульс».
Наши специалисты по искусственному интеллекту работают над автоматизацией процесса вноса кадровых документов в систему. При этом разработка моделей под каждый тип документов является финансово затратным процессом. Дело в том, что создание отдельного проекта состоит из нескольких ресурсоёмких этапов, включая разработку, тестирование, верификацию, деплой, мониторинг, поддержание кодовой базы. В этой статье я хочу рассказать, как мы пришли к созданию одной модели, которая распознаёт 7 типов документов:
документ об образовании;
свидетельство о рождении ребёнка;
свидетельство о заключении брака;
свидетельство о расторжении брака;
паспорт;
ИНН;
СНИЛС.
![](https://habrastorage.org/getpro/habr/upload_files/4a8/a45/ca2/4a8a45ca2d6667a94720e16c25c5f764.png)
С чего всё началось
Изначально наша команда использовала для «умного» распознавания документов стороннее решение. Оно отвечало за классификацию документов и распознавание свидетельств и дипломов. Паспорта, СНИЛС и ИНН обрабатывались собственными моделями. Ниже представлена упрощённая схема процесса:
![](https://habrastorage.org/getpro/habr/upload_files/92a/485/1c3/92a4851c3fabace3d2da60c410eddd12.jpg)
К сожалению, на этапе классификации происходило много ошибок, которые портили статистику по всем документам. Метрика точно распознанных полей не превышала 70%, общее качество распознавания было неудовлетворительным. И мы решили создать собственное решение с искусственным интеллектом и обработкой изображений.
На пути к собственному решению
В самом начале пути мы решили создать универсальный пайплайн обработки 7 типов документов, наиболее важных для Сбера. Ниже я немного расскажу о критериях системы, с которыми мы приступили к построению архитектуры модели.
Природа данных. Модель должна обрабатывать как сканы, так и фотографии документов. Помимо изображений могут присылаться PDF‑файлы, где содержится много страниц документа.
Данные. Документы одного типа могут отличаться друг от друга. Важно составить обучающую выборку так, чтобы все шаблоны были представлены в достаточном количестве. Вот несколько примеров:
![](https://habrastorage.org/getpro/habr/upload_files/696/3ba/725/6963ba72559e34946aa6bce8d26837b8.jpg)
Задача, которую мы поставили перед собой, упрощалась тем, что сегодня для всех популярных архитектур можно найти предобученные веса. Благодаря этому не требуется размечать десятки тысяч документов, чтобы обучить ту или иную модель. Мы начали с того, что разметили примерно по 300 документов каждого типа. После первого обучения добавили по 500 документов, размеченных уже моделью и исправленных разметчиком.
Типы полей. В совокупности модель должна успешно обрабатывать 58 полей.
![](https://habrastorage.org/getpro/habr/upload_files/869/f12/ee6/869f12ee69ef058fb1b8b2b41fc1f208.jpg)
Несмотря на довольно большое количество полей, сущности в разных документах повторяются: ФИО, серия и номер, даты. Это позволяет унифицировать работу.
Метрика качества. Когда речь заходит о том, как измерить эффект от внедрения модели, очень важно правильно определить метрику, по которой этот эффект будет измерен. В нашем случае используется такая бизнес‑метрика, как процент распознанных полей. Это количество полей, в значения которых не вносились правки HR‑специалистом после работы модели, относительно общего количества полей документа. Пример: в паспорте 10 полей, из них правильно распозналось 7, тогда 7/10=0,7 или 70% распознанных полей.
Выходной формат. Словарь JSON, где возвращаются тип документа и список всех распознанных полей.
Техническое решение
После разработки плана и описания всех важных для нас критериев команда приступила непосредственно к разработке. Здесь есть ещё пара моментов, которые нужно упомянуть. Так, во всех моделях по распознаванию документов можно выделить два основных этапа:
найти на документе, где находится необходимая информация;
извлечь эту информацию.
Конкретная реализация каждой части зависит непосредственно от задачи, которую необходимо решить. В нашем случае обработка документа была разбита на этапы:
Модель классификации. Если передан PDF‑файл, выбирается необходимая страница документа.
Модель определения угла поворота. Некоторые документы могут быть повёрнуты на 90 или 180 градусов.
Модель сегментации. Определение на документе расположения всех полей.
Character‑Region Awareness For Text detection (CRAFT). Поля, в которых содержится много текста, предварительно разбиваются на отдельные слова.
Модель распознавания текста. Из переданного изображения извлекается текст.
Постпроцессинг ответа. Исправление опечаток, ошибок распознавания, сверка со справочниками.
![](https://habrastorage.org/getpro/habr/upload_files/62f/127/cf9/62f127cf98f078f7b6a24f8e5118fe5c.jpg)
Далее подробно пройдёмся отдельно по каждому этапу, чтобы понять, для чего каждый из них необходим.
Этап 1: модель классификации
Каждое изображение относится к одному из классов:
0 — на изображении документа нет;
1 ‑ на изображении присутствует необходимая страница документа.
![](https://habrastorage.org/getpro/habr/upload_files/b5f/1f2/e0f/b5f1f2e0f7c8b777701377780a5bb08c.jpg)
К классу 0 были отнесены все страницы документов, не используемые в распознавании. Туда мы добавили сторонние документы, пустые страницы, случайные изображения.
Извлечение картинок из PDF‑файла — достаточно трудоёмкая операция. Время работы с одним изображением может достигать 200 мс. Следовательно, для 10–15 страниц обработка займёт несколько секунд. Мы протестировали 3 основные библиотеки для работы с PDF‑документами: Poppler, PyPDF2, PyMuPDF. Явное преимущество по скорости работы было у последнего варианта. Он был быстрее двух остальных в среднем в 1,5 раза. Среднее время извлечения одного изображения — 80 мс. Мы остановились на этом решении.
Все извлечённые из PDF‑файла страницы документа упаковываются в единый массив и отправляются в модель. На выходе получаем вероятности принадлежности к классу для каждого изображения. Выбирается то, в котором модель «уверена» больше всего. В качестве архитектуры использовалась очень лёгкая предобученная MobileNetV3-small, её возможностей хватило для достижения необходимого качества. Размер входного изображения сжимался до 224 х 224 — именно такое разрешение используется для обучения большинства моделей на датасете ImageNet.
Этап 2: модель определения угла поворота
Сначала мы использовали регрессионный подход — угол определялся в промежутке [-179; 180]. Сразу выяснились минусы такого решения:
модель путается в крайних значениях, что очень сильно сказывается на функции потерь;
на обучении изображения поворачивались случайным образом, выборка мало описывала генеральную совокупность. Поэтому на реальных данных необходимого качества достичь не удалось.
В итоге решили упростить модель. Так, предсказание ограничилось 4 классами: -90°, 0°, 90°, 180°. При этом удалось избавиться от дорогих операций поворота на основе аффинных преобразований. Как и в модели классификации, использовалась предобученная нейросеть MobileNetV3-small.
![](https://habrastorage.org/getpro/habr/upload_files/82e/3cb/3f8/82e3cb3f8cd6b91b7c128ae2b7381bd4.jpg)
Можно заметить, что в такой конфигурации допускается поворот до 45°, который никак не будет обработан. Здесь на помощь пришёл CRAFT, но об этом ниже.
Этап 3: модель сегментации
Задача этапа — получить расположение всех полей на изображении. Если обобщить, используются 2 подхода:
Сегментация — каждому пикселю присваивается один из заранее определённых классов. Это даёт большую гибкость — нейросеть пытается выделить необходимый объект как можно точнее.
Bounding‑box — для каждого объекта на изображении определяется ограничивающий прямоугольник — область, в которой он находится. Имеет широкое применение там, где не важна точность расположения объекта вплоть до пикселей, но критична скорость работы.
![](https://habrastorage.org/getpro/habr/upload_files/255/ebe/50e/255ebe50ea57069783f649a4d17a9a35.jpg)
Мы используем оба варианта. Сначала определяем местоположение поля, а затем сегментируем необходимый текст в нём, убирая лишние слова и артефакты, которые часто попадаются в документах. Это позволяет избежать дополнительных вычислений по сравнению с semantic segmentation.
Здесь можно и нужно использовать связку perspective transformation + bounding box detection. Когда документ будет полностью выровнен после первого этапа, останется только выделить прямоугольные формы вокруг необходимого текста. С одной стороны, это позволит ускорить работу этого этапа на порядок, с другой — для perspective transformation либо нужна отдельная модель, для которой необходима разметка, либо нужно использовать алгоритмы, разработка которых очень трудоёмка. Такой подход используют в условиях ограниченных ресурсов, например при разработке моделей на мобильных устройствах.
Именно на этапе сегментации определяется тип документа: модель просто размечает переданное изображение любыми классами из всех типов документов, а на основе найденных полей происходит неявная классификация. Может ли в документ одного типа попасть поле из документа другого типа? Да. Однако это происходит крайне редко, и такие поля можно убрать методом исключения.
Таким образом, после обработки документа на этом этапе мы узнаем:
тип документа;
где и какие поля находятся на изображении.
Этап 4: Character-Region Awareness For Text detection (CRAFT)
После сегментации изображения из него вырезаются отдельные поля. Но тут возникает проблема: модели OCR плохо справляются с текстом, разбитым на несколько строк. Даже увеличение количества букв в одном изображении плохо сказывается на качестве распознавания.
Для решения проблемы используются модели, которые разбивают текст на строки, строки — на слова. Одной из таких и является CRAFT: он даёт оценку region score — область каждого символа на изображении, а также affinity score — насколько символы близки друг к другу. К CRAFT в данном случае добавляется LinkRefiner для получения link score — скорректированная affinity score для длинных текстов.
Почти все библиотеки, поддерживающие работу с CRAFT, используют один и тот же алгоритм для перехода от оценок к выделению отдельных слов. Этот этап стал bottleneck качества нашей модели, поэтому мы его переписали следующим образом.
На основе link score определяем угол поворота всего документа, выравниваем текст горизонтально.
Все буквы объединяются по строкам, все шумные объекты убираются.
При определённых условиях каждая строка может быть повторно оценена через CRAFT.
Буквы объединяются в слова, составляется список контуров слов на изображении.
Из исходного изображения извлекаются слова по их контурам.
Слова объединяются в подстроки до 40 символов.
![](https://habrastorage.org/getpro/habr/upload_files/bda/2fe/fbb/bda2fefbba0836471bd6b0bbfb0df047.jpg)
Крайне важный момент: с помощью CRAFT можно выравнивать текст. Если на этапе определения угла поворота изображение поворачивается с погрешностью до 90 градусов, то с помощью CRAFT этот недостаток устраняется.
Мы достигли сразу 2 целей: оценили, как текст повёрнут во всём документе, и добились извлечения слов из изображения лучшим для нас образом.
Этап 5: Модель распознавания текста
![](https://habrastorage.org/getpro/habr/upload_files/551/3d9/7e0/5513d97e03ecc4cca5e4999afd289902.jpg)
На этом этапе у нас имеется список небольших изображений с текстом, откуда его надо извлечь. Для решения задачи существует целое направление — Optical Character Recognition (OCR). Существует множество архитектур в открытом доступе. Мы сосредоточились на поиске быстрого решения, стараясь ничего не потерять в качестве. За основу сети была взята ViTSTR, предобученная на английских текстах.
Переобучение на русский язык мы начали с того, что сгенерировали синтетические данные. Для документов список распознаваемых сущностей достаточно ограничен: ФИО, даты, последовательности цифр, тексты с названием учреждений. Туда же были подмешаны изображения, сгенерированные с помощью GAN.
Основной этап обучения происходил на реальных изображениях с текстом из документов, которые были предварительно размечены. Для того чтобы не искажать текст, в обучение помимо аугментации были добавлены случайные отступы для приведения к размеру 450 x 45. Всё это позволило достичь предельно хорошего качества распознавания текста.
Этап 6: постпроцессинг ответа
Распознанный текст должен пройти:
Исправление опечаток, ошибок распознавания. В этой области даже проводятся соревнования. Из того, что можно сразу поправить: даты ограничены календарём, поля с номерами должны содержать только цифры и наоборот, пол имеет всего 2 значения — мужской/женский. Мы не применяли алгоритмы на основе нейросетей, так как объём ошибок, который они призваны решать, в общей массе невелик.
Приведение к единому формату. Даты могут записываться по‑разному: месяц пишется текстом, год сокращается до 2 цифр и т. д. Поэтому здесь очень удобно прийти к одному согласованному формату (например, «дд.мм.гггг»). Также в словарь распознавания текста не включались английские символы, однако они могут присутствовать в документах. Например, это может быть серия документа, где обычно присутствует латиница. В таких случаях модель OCR распознаёт русские буквы или цифры, а на этапе постпроцессинга они переводятся в латинские.
Сверка со справочниками. В документах текст не случаен и содержит информацию об определённых сущностях. Это могут быть отделы ЗАГС, ФМС (федеральная миграционная служба), вуз, города, области, страны. Большинство этих данных можно найти в открытых источниках, они хорошо помогают исправить ошибки распознавания, недочёты в виде дефектов/искажений на документе. Однако здесь есть недостатки:
Работа со справочниками может увеличить время работы. Ведь нужно сравнить текст, распознанный моделью, со всеми строками в справочнике, чтобы впоследствии найти наиболее подходящую.
Со временем справочники необходимо обновлять. Туда могут добавляться новые строки либо меняться старые. Это требует поддержания справочников в актуальном состоянии, в противном случае качество модели будет со временем ухудшаться.
Тем не менее работа со справочниками даёт хороший прирост в качестве и сполна перекрывает все недостатки.
Обучение моделей
Для всех моделей был написан единый пайплайн, позволяющий запустить обучение на уровне конфигураций.
Хранилище архитектур. Все модели так или иначе уже реализованы в разных библиотеках — это очень удобно для быстрой проверки того или иного решения. Однако здесь есть и недостатки:
если необходимо залезть во внутренности архитектуры, придется её доставать из кода библиотеки;
копятся лишние зависимости;
при обновлении библиотеки может измениться логика работы;
код в библиотеках максимально обобщён для всех возможных случаев использования — это может замедлить скорость обучения.
Поэтому все архитектуры были вынесены в отдельный модуль, откуда их удобно доставать.
Валидация. Все документы были разбиты на тренировочную и валидационную выборки. Ни на одном этапе ни один файл из валидационной выборки не попадал в обучение, тем самым можно оценить качество работы всей модели в целом. Однако есть ещё тестовый датасет — он необходим, чтобы получить финальное качество.
Аугментация. На всех этапах применялось увеличение размера обучающей выборки за счёт различных преобразований изображения. Аугментации делятся на 2 направления:
преобразования на уровне пикселей. Сюда относятся наложение шумов, изменение цветовой палитры, размытие;
пространственные преобразования. Типичными примерами являются случайный поворот, обрезание сторон изображения, оптическое растяжение.
Аугментации — полезный инструмент для обучения, по сути он является одним из способов регуляризации моделей. Учтите, что злоупотребление этим инструментом может привести к тому, что наложенные искажения будут мешать обучению модели.
Анализ результатов
Наконец, всё готово, а метрики собраны на тестовом датасете таким образом, что для каждого типа документа представлено примерно по 150 экземпляров.
Модель | Метрика | Значение |
Классификация | Accuracy | 99,2% |
Угол поворота | Accuracy | 99,8% |
Сегментация | IoU | 82,6% |
Распознавание текста | Accuracy | 99,4% |
Метрика точности вполне понятна. Так, если предсказанное значение совпадает с действительным, то точность растёт.
С метрикой IoU (Intersection over Union) всё немного сложнее. Очевидно, что чем больше значение метрики, тем лучше. Но она также зависит от разметки, ведь человек далеко не всегда точно выделяет поля. К тому же некоторые поля больше по площади, чем остальные, поэтому модель может переобучаться на больших полях, игнорируя мелкие. Соответственно, интерпретировать результаты этой модели необходимо совместно с остальными частями.
Наиболее важный показатель качества работы модели — значения бизнес‑метрики. Вот таблица по каждому типу документов:
![](https://habrastorage.org/getpro/habr/upload_files/d8e/649/33a/d8e64933a884aadc5a308b87cba74ac6.png)
Паспорт, ИНН, СНИЛС — однотипные документы, поэтому качество распознавания на них высокое. Документы об образовании достаточно разнообразны — в зависимости от вида учебных заведений, годов выдачи, а также от квалификации. Свидетельства имеют различные оформления, дефекты в виде печатей и межстрочный текст. Также мы собрали статистику ошибок по причине их возникновения:
![](https://habrastorage.org/getpro/habr/upload_files/467/6b1/3eb/4676b13ebba2e5891b875b7b6e0b7bba.jpg)
Ошибки сегментации. Обычно возникают, если формат документа редко встречался в обучающей выборке. Особенно это ощущается на дипломах, где разнообразие шаблонов выше, чем в других документах. Также модель сегментации допускает ошибки, если изображение представлено в необычной экспозиции или есть какие‑то большие посторонние объекты. В данном случае может помочь определение точного расположения документа и выравнивание его по перспективе.
Ошибки CRAFT. Это единственная часть, которая не дообучалась под выборку. Отчасти это и становится причиной ошибок на этом этапе. Здесь мы будем проводить дополнительные эксперименты по бинаризации изображения, увеличению контрастности текста, уменьшению шумов на изображении.
Фотография неисправна. Сюда можно отнести блики, затёртый текст, печати, перекрывающиеся поля, рукописный текст (с ним модель не работает).
Распознавание текста. Можно подумать, что здесь основной проблемой являются неправильно распознанные буквы, но это не так. Дело в том, что на документе присутствует шумный текст, который иногда попадает на этап распознавания. В основном паттерны этих текстов повторяются, и модель OCR учится выдавать пустой ответ в таких случаях.
Угол поворота. На этом этапе модель ошибается достаточно редко, но каждая ошибка стоит очень дорого — все поля документа распознаются неверно.
Классификация документа. Эта модель актуальна только в случае присутствия сразу нескольких страниц документа, из которых нужно выбрать основную. Ошибки на этом этапе крайне редки и составляют менее 1%.
![](https://habrastorage.org/getpro/habr/upload_files/4f9/3b9/c62/4f93b9c62e2d9b86f7bf55899c75d524.jpg)
Что сейчас?
Разработанная нашей командой модель ежемесячно обрабатывает тысячи документов в HR‑платформе «Пульс» от Сбера. Но работа над проектом не закончена — мы экспериментируем с новыми подходами, постепенно повышая качество. Создание таких универсальных моделей помогает уменьшить издержки бизнеса и является перспективным направлением машинного обучения.
Спасибо всем за уделённое время, надеюсь, кому‑то статья будет полезной и поможет узнать что‑то новое. Задавайте вопросы в комментариях — постараюсь ответить.