Всем привет! Меня зовут Александра Пилюгина, я продакт-менеджер команды «QR и Фотоплатеж» в управлении «Платежи», банк ВТБ. К нам каждый месяц приходит около 500 тысяч новых клиентов. Специально для них наша команда разработала сервис переноса платежей в ВТБ Онлайн, попутно решив множество проблем с распознаванием платежных документов и извлечения из них полезной информации.
Современные клиенты банков грамотны и взыскательны, что приводит их к постоянному поиску лучших условий во всем. При переходе в новый банк клиент ожидает легкости и экономии времени в своих регулярных платежах. Сегодня пользователи легко переносят музыку между сервисами, клонируют приложения между iOS и Android, сверхбыстро и просто обмениваются любой информацией и больше не желают терпеть скуку традиционных платежек со скрупулезным заполнением квитанций. Еще лучше, если все обязательные регулярные платежи будут проходить автоматически, без комиссии и не особо беспокоя владельца кошелька ненужными подробностями.
Заходите под кат — расскажу, как мы всё это делали.
Миссия, команда, вызов
Мы второй по величине банк в стране, и ежемесячно к нам переходят тысячи новых клиентов. Чтобы пользователи чувствовали себя комфортно, одна из наших задач — снять с них головную боль по переносу ранее настроенных платежей. Для этого в июне прошлого года мы запустили проект по созданию сервиса распознавания платежных документов.
На первый взгляд тут не было ничего сложного: клиент сканирует QR с платежки, после чего попадает на страницу платежа. Хорошо, что с нами сотрудничают 18,5 тысяч юрлиц, передающих в банк реестр начислений, и найти в них нужную позицию достаточно просто. Но приключения начинаются, как только мы убираем QR или штрихкод с документа и пытаемся распознать реквизиты. Так мы приходим к необходимости построить систему, которая быстро и точно извлекает 51 атрибут (именно столько параметров мы насчитали) из более чем пятнадцати типов документов.
Сейчас мы умеем распознавать следующие типы и подтипы:
разнообразные виды квитанций;
счета;
платежные поручения;
чеки (чеки банков сильно различаются по структуре: у одного банка, связанного с почтой, это вообще похоже на какую-то таблицу из документа);
реквизиты юрлиц (могут быть чем-то документообразным, а могут быть вообще набором цифр на клочке бумаги);
экзотические типы платежных документов.
Чтобы научиться распознавать их, нам пришлось собрать объемный датасет (по 1000 документов одного типа), позволяющий точно отнести подаваемый клиентом скан к определенному типу и подтипу, и обучить на нем несколько моделей машинного обучения. Но, прежде чем начать распознавать фото от пользователей, нам пришлось готовить их к распознаванию: убирать шумы, блики и ряд других отягчающих признаков. Вы не представляете, в каком виде нам могут приходить документы. Обратите внимание, что квитанция подписана «Оплачено ВТБ». Да, это мы.
Для проверки нашей системы в действии мы даже объявили внутренний конкурс на самое испорченное фото, где все-таки можно распознать реквизиты. Дело в том, что как разработчики мы не видим самих сканов от пользователей: данные клиентов защищены, — однако можем судить о попытках системы по логам и в целом понимаем, куда копать. Выше была одна фотография-призер этого конкурса, ниже — еще парочка. У нас была фотография, где клиенты решили, что вафля очень похожа на QR-код и мы точно что-то да распознаем. Увы, мы еще не внедрили чтение вафельных кодов.
Над задачей работала agile-команда из 14 специалистов, иногда расширяясь до 30 при подключении других команд. Помощь других отделов потребовалась, так как ограничением для команды стала необходимость по максимуму использовать текущие наработки банка. Команд у нас много, используемых ими зависимостей еще больше, поэтому наш сервис должен был аккуратно интегрироваться в существующие реалии и максимально переиспользовать существующие решения. Создание новых интеграций было бы очень затратно. Итак, мы начали работу.
Скорость или качество? И то, и другое, и можно без хлеба и переделки процессов
Когда создается сервис распознавания текста, разработчики стоят перед выбором: скорость или качество распознавания. К сожалению, как банк мы не смогли себе позволить выбрать что-то одно, поэтому пришлось мобилизоваться и оптимизироваться по обоим направлениям. Мы делали рефакторинг, сокращали длину пайплайна распознавания, оптимизировали алгоритмы преобразования изображений и распознавания текста, бились за каждую секунду и пиксель. Понятно, что в таких условиях трансформерным моделям было не выжить, и мы использовали deep learning, но не такой тяжелый. Кроме того, разработали целую плеяду эвристических алгоритмов, которые улучшают извлечение информации. Для документов сервиса была выделенная отдельная очередь, в которой воркеры обрабатывали только документы нашего сервиса.
Прежде всего начали с подготовки изображений. Понятно, что клиент вряд ли думает перед нажатием кнопки «фото» о том, как бы ему так получше сфотографировать квитанцию, чтобы бэк банка смог быстро и без ошибок распознать его чек или квитанцию. В результате команде пришлось иметь дело с ситуациями, когда:
документ сфотографирован под углом и вместо прямоугольника мы получили трапецию;
блики перекрыли текст;
фото снято при неравномерном освещении;
у нас слабое освещение;
у нас низкая контрастность;
снимок сделан с экрана монитора, и на фотографии яркая радуга с рябью;
сделали снимок с очень низким разрешением (попробуйте разложить длинный чек любого банка и сфотографировать его так, чтобы он уместился в один снимок);
снимок сделан на пестром фоне (например, ковра или дачной скатерти).
В результате нам приходилось работать с фотографией уровня «сделана в полночь в машине при свете приборной панели с помощью видавшего виды шестилетнего бюджетного смартфона». Знаете, оказалось, что можно «вытащить» и это фото.
Я понимаю, что в сложившейся ситуации универсального алгоритма перевода «ничего-не-могу-прочитать» картинки в фото с снежно-белым фоном и угольно-чёрными буквами не существует. Поэтому нам пришлось искать набор эвристических подходов, характерных для каждого типа документов, и использовать их. Сюда входит и бинаризация изображения, и различные сглаживания, и морфологические операции. Например, наличие гильоша на водительском удостоверении и СТС доставляет определенные сложности при распознавании текста. На квитанциях мелких УК часто встречаются полосы от печати на умирающих принтерах. Но благодаря предварительной классификации фотографий с помощью ML мы умеем понимать, какой именно тип документа перед нами, и запускать целевой набор эвристики конкретно под него.
В итоге мы получаем черно-белое изображение, которое максимально очищено от всевозможных артефактов и готово для передачи движку OCR. Конечно, есть и более мощные подходы к очистке, которые используют огромные нейронные сети для улучшения качества изображения. Даже в такой «классической» библиотеке, как opencv, реализован метод, который позволяет улучшить качество изображения, и называется он соответствующе — super resolution. Впрочем, добиться существенно повышения читаемости текста с этим алгоритмом нам не удалось. Более того, этот метод работал очень медленно, а заставлять пользователя ждать ответа — это верный шаг к тому, чтобы потерять его для нашего сервиса навсегда.
Итоговая архитектура нашего сервиса следующая. За определение типов документа у нас отвечает библиотека MobileNetV3, обученная на большом датасете, затем запускаются алгоритмы Computer Vision, уже используемые в банке (мы же помним про условие по максимуму использовать существующие наработки), но подобранные под каждый тип документа. После чего текст распознается OCR-движком, а эвристические алгоритмы, включая и NLP, извлекают платёжные атрибуты, которые передаются на оплату.
Раз уж заговорили про условие «по максимуму использовать готовые наработки», самое время рассказать, как мы встроились в процесс оплаты распознанных реквизитов. Как банк мы уже умеем работать с QR-кодами на квитанциях, знаем случаи их использования и вообще не одну собаку на них съели. Чтобы не перенастраивать рабочий процесс, сервис научился генерировать QR-код из распознанной информации, после чего мы просто подаем его в оплату и дальше движемся уже по накатанной.
Конечно, изначально были опасения, что лишний шаг генерации замедлит наш процесс, однако на практике создание QR занимает минимум времени, зато существенно экономит время на разработку и тестирование полновесных решений при совершенной неочевидности выгоды.
Спустя полгода…
На реализацию сервиса «Фотоплатеж» у нас ушло полгода. Если смотреть широко, то моя команда реализовала привычный для многих импорт/экспорт данных только применительно к банковской сфере и платежам. И это получилось удобно.
Прежде чем двигать продукт в прод, мы запустили внутреннее тестирование на сотрудниках банка. Именно тогда коллеги включились в челлендж «а вот ЭТО ты распознаешь?!», присылая фотографии, на которых система «не шмогла». По фидбэку мы активно вносили правки, дообучали модель и через три недели выпустили «Фотоплатеж» в релиз.
К слову, процесс дообучения продолжается. Мы следим за тем, в каких типах документов у сервиса возникают сложности, и совершенствуем модель и алгоритмы улучшения фото.
Также мы контролируем метрики и фидбэк по сервису и с радостью отмечаем, что сервис людям нравится. Мы постарались довести до ума не только распознавание, но и реализовали подписку на счета: единожды распознав документ, мы можем настроить связь с провайдером платежек и выводить уведомление в случае появления новых. И это оказалось полезным: люди возвращаются в сервис, работая с ним по формату подписки, потому что им так удобнее.
Заглянем в будущее и в себя
Без ложной скромности могу сказать, что сервис удался, ни один из банков не предлагает такой же функциональности. Мы разработали его в сжатые сроки, у него хороший фидбэк со стороны пользователей.
Мы по-настоящему гордимся результатом и не собираемся останавливаться на достигнутом. Да, мы уже умеем распознавать прямые платежки и далее развиваем сервис в сторону агрегаторов платежей. Для справки: агрегаторы — это такие прокси от мира финансов, они получают деньги на свой счет, а по непосредственным исполнителям финансы раскидываются уже внутри. Естественно, это рождает комиссии, которых хотелось бы избежать.
Как уже говорила, мы обладаем внушительным реестром юридических лиц, грузящих в наши системы реестры платежей. Поэтому сейчас занимаемся практически дата-майнингом, пытаясь определить прямых конечных получателей.
А какие задачи с OCR решаете вы?
