Как РСХБ Abbyy импортозамещал

Привет, Хабр! Меня зовут Михаил Пушкарёв, в команде РСХБ.Цифра я отвечаю за развитие систем класса ECM и OCR. Иными словами, если надо информацию распознать, ее сохранить, да так, чтобы она не потерялась, и выдать по запросу – это все ко мне и моим коллегам!

Дисклеймер: при написании этой статьи мне хотелось не только рассказать о проекте импортозамещения, который мы реализовали в банке, но еще и рассказать о том, как продвинулись технологии оптического распознавания текста (OCR). И сначала я думал, что рассказ будет в формате "Когда-то в 1950-х годах появились первые устройства OCR". Но что-то пошло не так…

Итак, встречаем, очень краткая историческая сводка!

Как бы это ни прозвучало, но в книге "История OCR: оптического распознавания символов. Ассоциации пользователей технологии распознавания" первенство в технологии распознавания отдается Чарльзу Р. Кэрри. Именно он в далеком 1870 году изобрел сканер сетчатки глаза. Только вдумайтесь: 1870 год и сканер сетчатки глаза. Ну а дальше, что называется, "пошло-поехало".1914 год: оптофон – портативное устройство считывания текста и перевода в звук.Начало 1920-х годов: устройство с названием "Статистическая машина" для поиска в микрофильмах с помощью распознавания кода. В 1931 году на свое изобретение Эмануэль Голдберг получил патент, собственно он то и был приобретён IBM. 1950 год: Дэвид Шепард и Харви Кук-младший изобрели устройство, которое преобразовывало текст в машинный код, ну и конечно же, это не осталось незамеченным, и компания IBM купила лицензию, представив миру систему "Машинное оптическое распознавания символов" (сокращенно OCR - Optical Character Recognition).

Можно долго продолжать эту историческую сводку, вспомнив и появление технологии ICR (Intelligent Character Recognition) – расшифровки рукописных символов от исследовательской группы Массачусетского технологического института в 1960 годах. И MICR (Magnetic Ink Character Recognition) – считывание символов, нанесенных магнитными чернилами.

Технологии OCR не обошли стороной и советские ученые, реализовав систему Tiger, направленную на оцифровку книг для последующего перевода их на шрифт Брайля.

Конечно, не стоит забывать про отечественную компанию Abbyy, основанную в 1989 г. Дэвидом Яном, выпускником Московского физико-технического института. Именно он подарил миру FineReader и CuneiForm. В 2022 году компания официально ушла из России. В связи с чем и появилась необходимость замены всех систем ОСR в России. Рассказываю, как мы решили этот вопрос в РСХБ.

В РСХБ технологии OCR применяются начиная с 2010 года и развиваются до сих пор. Технология направлена, в первую очередь, на ускорение обслуживания клиентов банка. На начало 2023 года покрытие процессов и использование различных технологий можно представить в виде следующей сводки:

Функции, компонентов:

Верхнеуровневая схема работы:

Применение решений в процессах банка:

• Обработка платежных документов – используется установленный на локальных станциях FineReader.

• Брокерское обслуживание – вызов станции сканирования по API.

• Открытие расчетного счета (потребитель система ECM "АСОА" стоящая на импортозамещении) – используется толстый клиент станции сканирования, установленный на локальных станциях.

• Открытие расчетного счета (потребитель система ECM "CSP" призванная заместить систему "АСОА") – используется тонкий клиент станции верификации.

• Процесс кредитования физических лиц – вызов станции сканирования по API.

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

• 850 локально установленных приложений FineReader.

• Более 15 000 локально установленных стаций сканирования,

• Тонкие клиенты станции сканирования и верификации, вызываемые по API.

• Так как внедрение процессов было в разное время, а в качестве потребителей системы сканирования выступают разные системы, исторически было развернуто два независимых контура FlexyCapture.

• Суммарное количество видов документов, которые обрабатывала система сканирования, – более 140, среди них, например паспорт гражданина РФ или справка клиента об открытии счета в иных кредитных организациях.

Сформированная конструкция контуров и наличие локальных установок делали процесс развития и обновления системы не просто сложным, а очень сложным. Помимо этого, на горизонте всё более явно начинал "маячить" процесс переходов на отечественные ОС, что привело бы к невозможности работы со всеми программными комплексами из-за того, что толстые клиенты предусматривали работу только с ОС Windows.

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

Все факторы в совокупности, а также желание навести порядок в архитектуре решений и избавиться от нескольких разных решений с разными принципами работы подвели нас к тому, что проект импортозамещения стал актуальным и нужным для реализации. Первый вопрос, который волновал всех: "А на что собственно меняем?!".

Мы сформулировали набор основных требований к предполагаемому решению:

Критические требования:

• Решение должно быть включено в Реестр Российского ПО.
• Решение должно быть клиент-серверным и поддерживать возможность установки на отечественные ОС, как серверные – для развертывания программного комплекса, так и пользовательские – для работы с тонкими / толстыми клиентами.
• Решение должно быть полностью изолировано и исключить возможность какого-либо влияния извне. Это вытекало из предыдущего требования: нужна возможность установки на сервера без необходимости подключения к внешним базам / облакам.
• Решение должно поддерживать возможность самостоятельного развития в части добавления новых видов документов для распознавания.
• Пользователи должны в минимальной степени ощутить изменение ПО. Из-за большого количества сотрудников, которые пользуются решением, обучение сотрудников потребовало бы значительных временных затрат на обучение. Интерфейс должен быть максимально дружелюбным, желательно с минимальными изменениями относительно предыдущего решения.
• Скорость и качество распознавания документов – краеугольный показатель, призванный сделать посещение офисов банка максимально быстрым и беспроблемным.
• Решение при обработке документов не должно использовать GPU, так как это значительно сужает возможности по масштабируемости и переиспользованию серверных ресурсов.
• Обязательная поддержка распознавания сложных табличных представлений с динамической длиной таблиц. Все же помнят справки 2НДФЛ и их размер? =)
• Последнее, что следует указать, – срок реализации проекта, включая развертывание, миграцию существующих шаблонов и реализацию интеграций с смежными системами.

Менее критичные требования:

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

Минорные требования:

• Поддержка CI\CD.
• Количество успешных внедрений у крупных заказчиков.
• Сам процесс выбора.

Обо всём процессе поиска рассказывать не буду, но есть несколько примечательных моментов. Большинство потенциальных решений отсеялись еще на этапе первичного анализа, так как многие или не поддерживали отечественные ОС, или требовали обязательное внешнее подключение, или банально "витали в облаках". В результате первичного отбора мы выдели трех финалистов, это были ContentCapture, Soica, DreamDocs.

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

В ходе проверки на качество и скорость распознавания каждый из вендоров нам предоставил свой тестовый стенд (за что им спасибо) с преднастроенным шаблоном распознавания паспорта (как самый сложный и частый документ). Тестировали мы просто – взяли скан-образы фейковых паспортов, которые мы специально нарисовали для тестирования (естественно все паспорта были разного качества от удобочитаемых до "а что ту написано не понятно!"). Ну, знаете, такие, чтобы некоторые символы даже самим было не просто разобрать. Дальше поочередно закидывали шаблон и фиксировали, какие поля распознались качественно, какие нет.

И тут надо отметить, что одно из решений удивило даже нас. Мы все среагировали примерно одинаково: "Да как они так сделали?!", потому что там, где другие решения разбились об сложно читаемые символы, это решение успешно его могло распознать. Какое это именно решение, рассказывать не будем, в этой статье нет рекламы).

Что мы считаем главным показателем качества распознавания? Согласно общепринятым нормам, показатели качества для печатных материалов варьируются от 60 до 90%. Основные показатели всех кандидатов были сопоставимы, какой-то глобальной дельты не было. На одном шаблоне у одного решения были какие-то заоблачные показатели качества распознавания, а у других было все плохо, а на следующем шаблоне ситуация могла сложиться диаметрально противоположная. В результате средний показатель был сопоставим.

Так как все решения обладали плюс-минус идентичными показателями, во главу угла по выбору решения мы поставили скорость перехода на новое решение и наличие собственных компетенций. В результате было выбрано решение Content Capture. Собственно переходим к самому интересному. Ура! Мы стартуем работы по импортозамещению!

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

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

• Регулярные статусы по анализу и разбору возникающих проблем при разворачивании комплекса.
• Регулярные технические встречи с представителями вендора.
• Формирование дорожной карты со сроками исправления дефектов.

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

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

А дальше у нас начались исключительно работы внутренней командой с редкими консультациями вендора.

Миграцию процессов мы разделили на несколько условных блоков:

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

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

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

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

Вот тут надо сделать ремарку, что к этому моменту мы уже развернули тестовую и продуктивную среду. И надо сказать, что после всех "шишек", которые мы собрали на разворачивании dev-контура, эти процессы пролетели очень быстро, спасибо коллегам из смежных подразделений, ответственных за поддержку сред.

Как бы то ни было, окрылённые первым успехом, мы кинули все силы на миграцию оставшихся процессов, и вот тут мы вышли на по-настоящему крейсерскую скорость. Новый программный комплекс был сопоставим со старым, а процесс переноса заключался в копировании кода, проверки его работы, корректировки (в новом решении была версия C#7 относительно C#5 в предыдущем решении). Если что-то не работало, но это правилось очень быстро.

Первоначальная цель была в том, чтобы мигрировать решение и заставить его работать. Рефакторинг и оптимизация сразу ушли на второй план, так как лучшее – враг хорошего! Дальше был короткий процесс обучения, при этом модели мы по факту переносили из предыдущего решения, проверяя корректность распознавания и отметку о готовности. И так для всех шаблонов.

И вот по прошествии нескольких недель от начала работ мы сдали еще один кусок функционала, в рамках которого также использовались толстые клиенты станции сканирования и верификации. У нас появилась надежда, что мы не только закроем проект, но и еще сдадим его с опережением плановых сроков. И вот как обычно бывает в проектах, как только начинают появляться крамольные мысли на тему "Вазу! Сделаем все быстрее!", что-то идёт не так, и это случилось:

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

Оооо, как же мы ошибались! В результате нам потребовалась срочная переделка интеграционных взаимодействий, и этот "маневр" нам обошелся в общей сложности в 4 недели, потому что оказалось, что СУР (внутренний механизм оркестратор "Система управления распознаванием") тоже не шибко "молодая", и современные веяния отвергает. Поэтому делали системе срочное "омолаживание" и допилили её до нужного состояния. Конечно же, были тестирование и отладка – и вот из "Е! Мы идем с опережением" мы быстро и качественно скатились "ААА! Пожар! Горит!".

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

Ну а про все приключения департамента информационных технологий по раскатке такого количества толстых клиентов (напоминаю, станций сканирования и FineReader было больше 16000) и лучи добра и счастья от коллег, которым приходилось это раскатывать, они расскажут когда-нибудь сами (массовый переход на отечественные ОС, вот это кейс!)Проект мы реализовали качественно в срок и точка!

Вы поняли, да? Наверное, стоит подвести результаты, к чему мы пришли?

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

По факту команда в количестве 5 человек смогла реализовать проект импортозамещения под ключ. Отвечая на вопрос по срокам и временам года: зима и весна и первый месяц лета ушли на первичные подготовки (ведь планы всегда хороши) и войну с "кирпичом", обкатку разворачивания и непосредственно разворачивание контуров, ну а июль-конец октября – на миграцию процессов и вывод их в продукты.

Самый главный вывод: импортозамещение возможно! И, оглядываясь назад, мы можем это с полной уверенностью подтвердить!

Что дальше?

Как не поделиться тем, куда мы идем? Казалось бы, импортозаместились и сидите-поддерживайте, но руки нам даны не для скуки, поэтому планы у нас лаконичные:

• Отказ от толстых клиентов. К моменту, когда эта статья будет опубликована, мы уже можем утверждать, что мы это сделали в части процессов расчётно-кассового обслуживания.
• Оптимизация скорости распознавания и обработки документов. Тут мы уже тоже достигли небольших успехов (ускорение всего на 20%), но мы не останавливаемся.
• Конечно же, расширение списка документов, которые мы умеем обрабатывать.
• И самое главное – рефакторинг и оптимизация. Там есть, что поделать.

Планы интересные, местами непростые, но и мы не из пугливых, потому сделаем! Я не сомневаюсь!