Ocr

Прошло больше года с момента введения жестких ограничительных мер, связанных с распространением COVID-19. Сейчас мир постепенно возвращается в нормальный режим жизни, хотя угроза новых вспышек заболевания остается. Поэтому принимаются все необходимые меры: маски, перчатки и сдача ПЦР-тестов по разным поводам. С административной точки зрения, это, скорее всего, правильно. А вот с организационной система не готова. Главная проблема слабо организованная система проведения ПЦР-тестов. В сегодняшней статье поговорим о том, как ее усовершенствовать.

С точки зрения организации администрирования всего процесса, в целом, ПЦР-тестирование это не просто мазок из носоглотки. Необходимо организовать следующие процессы:

• регистрация клиента и взятие мазка из ротоглотки ПЦР-теста (в стационарных или мобильных пунктах);

• логистика биоматериала до исследовательской лаборатории;

• проведение анализа биоматериала;

• предоставление результатов тестирования;

• контроль результатов на пропускных пунктах (в аэропортах, гостиницах, офисах и т.п.).

Оказывается, в качестве bottle neck в приведенном списке выступают первая и последняя позиции. Действительно, логистика и проведение самого анализа биоматериала давно автоматизированные и проработанные со стороны лабораторий процессы. А вот процедура взятия мазка и последующий контроль результатов исследования на пропускных пунктах в условиях массового наплыва клиентов новая задача.

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

Регистрация клиента в лаборатории

Первый этап автоматизации ввод персональных данных клиента и заключение договора на оказание медицинских услуг. Smart Engines уже выпустил продукт для автоматизации ввода персональных данных. Намного проще вводить паспортные данные, просто сфотографировав документ на веб-камеру или приложив его на секунду к специализированному паспортному сканеру. Банки, мобильные операторы, транспортные компании уже оценили удобство технологии распознавания документов. Кстати, даже в РЖД автоматизировали кассы на вокзалах волшебными коробочками, которые за мгновение вводят паспортные данные.

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

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

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

Контроль результатов ПЦР-теста

Второй этап автоматизации это контроль валидности выданных тестов. Нет ничего сложного, если надо проверить результаты теста у 100 человек. А если их тысячи (крупные офисы в мегаполисе) или десятки и даже сотни тысяч человек (аэропорта, ж/д вокзалы, речные и морские порты)? И каждый идет со своим индивидуальным бланком справки (как бы это смешно ни звучало, но нет единого шаблона таких справок о результатах ПЦР тестирования).

Помимо проверки непосредственно результата теста, важно следить за валидностью и подлинностью таких справок. Помните этот громкий международный скандал, когда 190 пассажиров рейса Москва Чжэнчжоу предоставили идентичные результаты серологического теста на антитела к COVID-19, что в результате привело к проблемам международного авиасообщения?

Система распознавания Smart Document Engine не только автоматически контролирует результаты в сертификатах тестирования COVID-19 для трех основных лабораторий России (Гемотест, Инвитро и Хеликс), но и возвращает все необходимые данные (как текстовые, так и графические), которые могут быть использованы для анализа валидности и подлинности таких сертификатов.

Помимо мобильного кейса, на базе Smart Document Engine можно построить полноценный роботизированный комплекс - автономный программно-аппаратный комплекс сканирования и анализа данных, совместимый с различными системами СКУД. Роботизированный комплекс способен за мгновение распознать данные из сертификата, контролировать наличие или отсутствие РНК и передавать управляющее действие в СКУД. Таким образом удастся полностью исключить человека из контроля тестов на загруженных пропускных пунктах.

Итого

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

Update. Буквально вчера была опубликована новость о том, что россиян, прибывающих из Турции и Танзании до 1 мая, а после 1 мая всех граждан, прибывающих из-за границы, обязали дважды сдать тест на COVID-19. Такие нововведения лишь подтверждают, что крайне необходима автоматизация процесса проведения ПЦР тестирования и контроля полученных результатов.

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

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

Сделать модель для распознавания можно с помощью разных подходов, например, путем поиска и определения отдельных символов, или в виде задачи image-to-text. Мы рассмотрим модель с несколькими выходами (multihead-модель). В качестве датасета возьмём датасет с российскими номерами от проекта Nomeroff Net. Примеры изображений из датасета представлены на рис. 1.

Рис. 1. Примеры изображений из датасета

Общий подход к решению задачи

Необходимо разработать модель, которая на входе будет принимать изображение ГРЗ, а на выходе отдавать строку распознанных символов. Модель будет состоять из экстрактора фичей и нескольких классификационных голов. В датасете представлены ГРЗ из 8 и 9 символов, поэтому голов будет девять. Каждая голова будет предсказывать один символ из алфавита 1234567890ABEKMHOPCTYX, плюс специальный символ - (дефис) для обозначения отсутствия девятого символа в восьмизначных ГРЗ. Архитектура схематично представлена на рис. 2.

Рис. 2. Архитектура модели

В качестве loss-функции возьмём стандартную кросс-энтропию. Будем применять её к каждой голове в отдельности, а затем просуммируем полученные значения для получения общего лосса модели. Оптимизатор Adam. Используем также OneCycleLRWithWarmup как планировщик leraning rate. Размер батча 128. Длительность обучения установим в 10 эпох.

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

Кодирование

Далее рассмотрим основные моменты кода. Класс датасета (листинг 1) в общем обычный для CV-задач на Pytorch. Обратить внимание стоит лишь на то, как мы возвращаем список кодов символов в качестве таргета. В параметре label_encoder передаётся служебный класс, который умеет преобразовывать символы алфавита в их коды и обратно.

class NpOcrDataset(Dataset):   def __init__(self, data_path, transform, label_encoder):       super().__init__()       self.data_path = data_path       self.image_fnames = glob.glob(os.path.join(data_path, "img", "*.png"))       self.transform = transform       self.label_encoder = label_encoder    def __len__(self):       return len(self.image_fnames)    def __getitem__(self, idx):       img_fname = self.image_fnames[idx]       img = cv2.imread(img_fname)       if self.transform:           transformed = self.transform(image=img)           img = transformed["image"]       img = img.transpose(2, 0, 1)             label_fname = os.path.join(self.data_path, "ann",                                  os.path.basename(img_fname).replace(".png", ".json"))       with open(label_fname, "rt") as label_file:           label_struct = json.load(label_file)           label = label_struct["description"]       label = self.label_encoder.encode(label)        return img, [c for c in label]

Листинг 1. Класс датасета

В классе модели (листинг 2) мы используем библиотеку PyTorch Image Models для создания экстрактора фичей. Каждую из классификационных голов модели мы добавляем в ModuleList, чтобы их параметры были доступны оптимизатору. Логиты с выхода каждой из голов возвращаются списком.

class MultiheadClassifier(nn.Module):   def __init__(self, backbone_name, backbone_pretrained, input_size, num_heads, num_classes):       super().__init__()        self.backbone = timm.create_model(backbone_name, backbone_pretrained, num_classes=0)       backbone_out_features_num = self.backbone(torch.randn(1, 3, input_size[1], input_size[0])).size(1)        self.heads = nn.ModuleList([           nn.Linear(backbone_out_features_num, num_classes) for _ in range(num_heads)       ])     def forward(self, x):       features = self.backbone(x)       logits = [head(features) for head in self.heads]       return logits

Листинг 2. Класс модели

Центральным звеном, связывающим все компоненты и обеспечивающим обучение модели, является Runner. Он представляет абстракцию над циклом обучения-валидации модели и отдельными его компонентами. В случае обучения multihead-модели нас будет интересовать реализация метода handle_batch и набор колбэков.

Метод handle_batch, как следует из названия, отвечает за обработку батча данных. Мы в нём будем только вызывать модель с данными батча, а обработку полученных результатов расчёт лосса, метрик и т.д. мы реализуем с помощью колбэков. Код метода представлен в листинге 3.

class MultiheadClassificationRunner(dl.Runner):   def __init__(self, num_heads, *args, **kwargs):       super().__init__(*args, **kwargs)       self.num_heads = num_heads    def handle_batch(self, batch):       x, targets = batch       logits = self.model(x)             batch_dict = { "features": x }       for i in range(self.num_heads):           batch_dict[f"targets{i}"] = targets[i]       for i in range(self.num_heads):           batch_dict[f"logits{i}"] = logits[i]             self.batch = batch_dict

Листинг 3. Реализация runnerа

Колбэки мы будем использовать следующие:

• CriterionCallback для расчёта лосса. Нам потребуется по отдельному экземпляру для каждой из голов модели.

• MetricAggregationCallback для агрегации лоссов отдельных голов в единый лосс модели.

• OptimizerCallback чтобы запускать оптимизатор и обновлять веса модели.

• SchedulerCallback для запуска LR Schedulerа.

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

• CheckpointCallback чтобы сохранять лучшие веса модели.

Код, формирующий список колбэков, представлен в листинге 4.

def get_runner_callbacks(num_heads, num_classes_per_head, class_names, logdir):   cbs = [       *[           dl.CriterionCallback(               metric_key=f"loss{i}",               input_key=f"logits{i}",               target_key=f"targets{i}"           )           for i in range(num_heads)       ],       dl.MetricAggregationCallback(           metric_key="loss",           metrics=[f"loss{i}" for i in range(num_heads)],           mode="mean"       ),       dl.OptimizerCallback(metric_key="loss"),       dl.SchedulerCallback(),       *[           dl.AccuracyCallback(               input_key=f"logits{i}",               target_key=f"targets{i}",               num_classes=num_classes_per_head,               suffix=f"{i}"           )           for i in range(num_heads)       ],       dl.CheckpointCallback(           logdir=os.path.join(logdir, "checkpoints"),           loader_key="valid",           metric_key="loss",           minimize=True,           save_n_best=1       )   ]     return cbs

Листинг 4. Код получения колбэков

Остальные части кода являются тривиальными для Pytorch и Catalyst, поэтому мы не станем приводить их здесь. Полный код к статье доступен на GitHub.

Результаты эксперимента

Рис. 3. График лосс-функции модели в процессе обучения. Оранжевая линия train loss, синяя valid loss

В списке ниже перечислены некоторые ошибки, которые модель допустила на тест-сете:

• Incorrect prediction: T970XT23- instead of T970XO123

• Incorrect prediction: X399KT161 instead of X359KT163

• Incorrect prediction: E166EP133 instead of E166EP123

• Incorrect prediction: X225YY96- instead of X222BY96-

• Incorrect prediction: X125KX11- instead of X125KX14-

• Incorrect prediction: X365PC17- instead of X365PC178

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

Заключение

В статье мы рассмотрели способ реализации multihead-модели для распознавания ГРЗ автомобилей с помощью фреймворка Catalyst. Основными компонентами явились собственно модель, а также раннер и набор колбэков для него. Модель успешно обучилась и показала высокую точность на тестовой выборке.

Спасибо за внимание! Надеемся, что наш опыт был вам полезен.

Больше наших статей по машинному обучению и обработке изображений:

• Data Science: предсказание бизнес-событий для улучшения сервиса

• Как мы используем алгоритмы компьютерного зрения: обработка видео в мобильном браузере с помощью OpenCV.js

• Тестируем комплементарную кросс-энтропию в задачах классификации текста

В последнее время все чаще слышно про RPA или Robotic Process Automation. С одной стороны, говорят о его эффективности для банковского сектора и крупных корпораций, с другой про применимость и в среднем, и даже в малом бизнесе. На днях на Хабре вышла обзорная статья про интеллектуальную обработку документов с помощью RPA и мы подумали, что хабравчанам также будет интересен рассказ про наш опыт реализации такого проекта в деталях.

Он был выполнен для одного из крупнейших ритейлеров в РФ и Европе. Его магазины можно найти везде: в одной только Москве и области их десятки, а по всей России больше сотни. Это фантастическое количество товаров, поставщиков, поставок и связанного с ними документооборота, которого с каждым месяцем становится больше и больше.

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

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

С чем предстояло работать

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

Описанные выше проблемы возникали на этапе обработки документов. На стороне заказчика каждый день на эту задачу тратилось 72 часа. Это 9 полноценных бухгалтерских рабочих дней! Роботизации этого проекта от нас и ждали.

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

В качестве платформы роботизации был выбран UiPath: абсолютный лидер на рынке РФ и один из лидеров глобального рынка RPA, кроме того, уже обкатанный в головном офисе нашего партнера в Европе.

Чего мы хотели от робота?

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

выявить аномальные расхождения, которые человек может пропустить;

снизить риск ошибки специалистов по товарному предложению;

предотвратить расширение штата бухгалтеров при увеличении объемов поставок;

ускорить проведение оплат поставщикам.

На основе всего этого мы поставили перед собой такие задачи:

разработать роботов, которые будут выполнять работу бухгалтеров;

разработать сервис их взаимодействия с бухгалтерами и СТП; не допускающий использования вил и факелов

реализовать процесс извлечения данных из сканов бумажных документов;

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

Ну и как же без дополнительных требований от заказчика:

runtime-лицензии роботов должны использоваться максимально эффективно. Лишние действия, задержки все это должно быть сведено к минимуму;

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

отсутствие у роботов дублирования функций;

приоритизация срочных задач (например, отчетов);

минимизация поддержки решения после ввода в эксплуатацию;

автоматический онлайн-расчет окупаемости (дэшборд в Confluence);

и еще, чтоб участников процесса письмами/уведомлениями не спамило.

Подход к проблеме и проект

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

Итак, сформулировав процесс AS-IS, мы декомпозировали его на подпроцессы для роботизации. Получилось вот так:

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

Однотипные задачи мы сразу стали собирать в совместную обработку, помня о требовании об эффективном расходовании runtime-лицензии. На практике это значило, что если нужно выгрузить из ЭХД 10 доков, то открывать его мы будем 1 раз, выгружать нужное и 1 раз закрывать, а не открывать и закрывать для каждого документа.

Архитектуру системы полностью определило решение формировать списки задач для каждого роботизируемого процесса в СУБД (MS SQL). Тем более что, как мы выяснили, отчёт из учетной системы (на базе СУБД ORACLE) можно выгружать запросом. Поэтому мы решили сделать Link к БД учетной системы и настроить Job в БД для регулярной выгрузки новых приемок, готовых к сопоставлению. Этот Job будет также анализировать полученные данные и переводить приемки на нужный этап обработки: Требует согласования с СТП, Требует выгрузки в систему распознавания, Передать в оплату и т.д.

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

Что еще нужно было определить перед тем, как приступить к работе?

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

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

В этом процессе было несколько критически важных точек: качественное извлечение табличной части документа; проверка артикулов в БД (да, номенклатура также выгружалась из БД ERP-системы); сверка суммы документов; проверка совпадения штрихкода на документе и в ERP.

Формирование интерфейса

Для взаимодействия с пользователями изначально планировали использовать Jira, но затем мы приняли решение упростить интерфейс. Мы разработали собственный сервис по взаимодействию с пользователями. Если требуется согласовать расхождение, робот присылает сотруднику по товарному предложению ссылку в письме. При переходе по ней формируется web-страница, при этом проверяется, не был ли этот заказ уже согласован, а также имеет ли данный человек все необходимые права. На этой странице сотрудник выполняет согласование и вводит комментарий. После этого приемка в БД получает соответствующий статус для дальнейшей обработки роботом.

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

Формирование отчетности

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

Всего отчетов было реализовано четыре:

отчет по задачам бухгалтеров (требуются ли действия от бухгалтера?);

отчет главного бухгалтера (по задачам всех бухгалтеров);

общий отчет по выявленным расхождениям;

детальный отчет по расхождениям (с суммами по приёмкам и по поставщикам).

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

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

Формирование графиков в Confluence

Помимо отчетов, робот также должен был строить real-time графики окупаемости самого себя. Для этого был разработан набор представлений в БД, в которых рассчитываются ключевые метрики робота. Методология расчета метрик включает в себя все затраты на роботизацию процесса, в том числе стоимость лицензий, серверов, стоимость наших услуг, а также зарплату бухгалтеров, ведь полностью мы их не исключили из процесса. Для отображения графика на странице в Confluence используется плагин Database Query.

С какими трудностями мы столкнулись

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

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

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

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

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

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

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

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

Например, если учетная система падает во время исполнения роботом задачи, он должен через фиксированное время делать еще одну попытку. Если система остается недоступна несколько часов, робот должен писать заявку в поддержку этой системы в Jira.

В качестве основы всех процессов мы использовали Enhanced REFramework. Нас устраивали его расширенное логирование и централизованная обработка исключений.

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

Переиспользование частоиспользуемых процессов (инвоуков)

Ввиду большого количества разрабатываемых процессов встает вопрос о переиспользовании повторяющихся разработок. Например, во все наши процессы входит взаимодействие с базой данных, во многие получение и отправка писем, открытие и закрытие учетных систем. Все разработанные последовательности действий, которые могут быть переиспользованы, мы собрали в отдельные библиотеки и объединили в nuget-пакеты по области их применения. Пакеты хранятся в оркестраторе и GIT, соответственно, все разработчики имеют доступ к актуальной версии.

Кастомные активности

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

работа с БД (получение данных по приемкам, по отчетам, сохранение статусов и т.д.);

работа с почтой (получение запросов от бухгалтеров, отправка уведомлений);

работа с Excel (форматирование, группировка, сортировка и т.д.);

работа с учетными системами (авторизация, проверка ошибок).

Все это используется в разных роботизируемых процессах разными роботами и хранится в Оркестраторе, оставаясь доступным для всех разработчиков.

Курьезный случай исчезновение штрихкодов

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

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

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

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

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

Результаты

Как мы говорили в самом начале, от нас требовалась оптимизация рабочего процесса на 90%. Как вычислить этот показатель? Для этого нужно сравнить время, которое будет потрачено на нужный процесс с роботом и без него. Мы определили, сколько занимали все составляющие роботизированной работы выгрузка актов, работа в ABBYY, составление отчетов и даже написание писем; задали резерв на обслуживание робота.

И выяснили, что с задачами, на которые штат бухгалтеров ежедневно тратил время девяти полностью занятых профессионалов, робот справляется примерно за половину одного рабочего дня (0,47 рабочего дня, если быть точным). Точный показатель 94% оптимизации. Это была победа!

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

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

Спасибо всем дочитавшим до этого момента. Если у вас возникли вопросы, мы будем рады на них ответить!

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

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

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

Принципы

В первую очередь очертим требования, которые мы закладывали при проектировании системы. Четыре основных принципа, лежащих в основе Smart IDReader:

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

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

3. Автономность. Безопасность данных - превыше всего. Самый безопасный способ хранения данных - не хранить данные, самый безопасный способ передачи данных - не передавать данные. По нашему мнению, мобильная система распознавания обязана быть построена так, чтобы при распознавании никакие данные за пределы оперативной памяти конечного устройства не уходили. Следовательно, вся обработка изображений и все распознавание должно происходить непосредственно на устройстве, что накладывает дополнительные ограничения (см. п. 2) на используемые алгоритмы.

4. Масштабируемость. Наша первая система распознавания для мобильников (вот эта) поддерживала только внутренний паспорт РФ. При этом в мире существуют тысячи документов, удостоверяющих личность, и система должна быть устроена таким образом, чтобы добавить поддержку нового документа можно было быстро. Кроме того, добавление нового типа документа не должно требовать большого количества примеров, поскольку их неоткуда взять.

Трудности

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

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

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

Итак, держим в уме: всё должно быть сделано точно и быстро, только средствами мобильного устройства, при этом надо учитывать неконтролируемые условия съемки, но можно использовать несколько кадров.

Поиск документа

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

На первом этапе обработки изображения системой Smart IDReader мы детектируем страницы документа (мы их условно называем шаблонами). Шаблоны документов, которые мы ищем, нам заранее известны, все они представляются как изначально плоские прямоугольники (с известными физическими размерами), однако на изображении они могут быть проективно искажены. Кроме того, у одного документа могут быть несколько шаблонов: к примеру, передняя и оборотная стороны ID-карточки, или две страницы паспорта.

Для поиска шаблонов на изображении мы используем (иногда совместно) три основных подхода:

1. Быстрый поиск проективно искаженного прямоугольного объекта с известными соотношениями сторон. Метод основан на предварительном поиске прямых линий быстрым преобразованием Хафа и аккуратной переборной схеме. Про этот метод мы уже писали на Хабре, также про него можно почитать в этом докладе.

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

3. Наиболее общий подход, основанный на связке: особые точки + дескрипторы + RANSAC. Вначале на входном изображении производится поиск особых точек (мы используем модификацию особых точек YAPE для изображений с большим разбросом локального контраста, про эту модификацию можно почитать в этом докладе) и для каждой точки вычисляется локальный дескриптор (в нашем случае - методом RFD, модифицированным с целью ускорения). Далее в индексе известных дескрипторов запуском серии поисков ближайших соседей выявляются шаблоны-кандидаты. После этого кандидаты верифицируются при помощи метода RANSAC с учетом геометрического расположения особых точек. Этот метод используется в Smart IDReader для поиска и типизации подавляющего числа типов идентификационных документов. Подробнее про него можно почитать в этом докладе.

Поиск полей

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

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

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

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

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

Обработка и распознавание полей

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

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

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

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

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

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

Использование нескольких кадров

При использовании последовательности кадров Smart IDReader предполагает, что в рамках одной сессии распознавания на разных кадрах видеопотока виден один и тот же документ (это не означает, однако, что один и тот же шаблон - к примеру, при съемке ID-карты в рамках одной сессии документ можно перевернуть, показав оборотную сторону). Аккумулирование информации с нескольких кадров может быть полезно почти на любом этапе процесса анализа документа - начиная с поиска документа (как для дополнительной фильтрации набора возможных кандидатов, так и для уточнения геометрического позиционирования), и заканчивая распознаванием конкретного поля.

В системе Smart IDReader используется подход комбинирования результатов распознавания текстовый полей с нескольких кадров, что позволяет значительно повысить точность распознавания в видеопотоке и использовать даже информацию о частичном распознавании поля (если, к примеру, на каком-то кадре поле было прикрыто бликом). О методах комбинирования результатов распознавания текстовых строк можно прочитать, например, в этой статье.

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

Последним по порядку, но не по значению, аспектом работы с видеопотоком является анализ голограмм и других OVD (Optical Variable Devices) - элементов защиты документов, которые меняют свой внешний вид при изменении освещения или угла обзора. Для того, чтобы их детектировать и верифицировать их наличие, последовательность кадров просто необходима по определению. Рассматривая только одно изображение, верифицировать наличие такого элемента защиты нельзя.

Детали, детали

В этой статье мы постарались описать основные блоки нашей системы и ключевые принципы, на которые мы ориентировались при разработке. Разумеется, в таком формате невозможно охватить полный набор компонентов и нюансов системы распознавания документов. Поэтому в данную статью не вошли описания таких компонентов, как детектор рукописи, детектирование ключевых объектов (гербы, фотографии, подписи, печати), быстрое детектирование машиночитаемой зоны (MRZ) и её использование для уточнения позиционирования и типизации документов, форматирование полей до межкадрового комбинирования, определение степени уверенности распознавания и многое-многое другое. Даже грубое описание системы потребовало с десяток ссылок на научные тексты, и решение задачи, которая кому-то может показаться простой, достигается с помощью серьезных научных достижений большого коллектива. По теме распознавания документов мы публикуем порядка 40 научных текстов в год и регулярно подаем заявки на патенты.

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

Спасибо вам за внимание! Если вам интересно подробнее узнать о каких-то специфических компонентах нашей системы распознавания, пишите нам в комментариях!

Введение

Распознавание рукописного текста (англ. Handwritten Text Recognition, HTR) - это автоматический способ расшифровки записей с помощью компьютера. Оцифрованный текст рукописных записей позволило бы автоматизировать бизнес процессы множества компаний, упростив работу человека. В данной работе рассматривается модель распознавания рукописного текста на кириллице на основе искусственной нейронной сети. В исследовании использовалась система SimpleHTR разработана Гаральдом, а также LineHTR, расширенной версией системыSimple HTR. Подробнее о SimpleHTR можно почитать здесь.

Датасет

В этом разделе опишу два типа наборов данных: Первый набор данных содержит рукописные цитаты на кириллице. Он содержит 21 000 изображений из различных образцов почерка (названия стран и городов). Мы увеличили этот набор данных для обучения, собрав 207 438 изображений из доступных форм или образцов.

Второй HKR для рукописной казахско-русской базы данных состоял из отдельных слов (или коротких фраз), написанных на русском и казахском языках (около 95% русского и 5% казахского слова/предложения, соответственно). Обратите внимание, что оба языка являются кириллическими написаны и разделяют одни и те же 33 символа. Кроме этих персонажей, в казахском алфавите есть еще 9 специфических символов. Некоторые примеры набора данных HKR показаны ниже:

Этот окончательный набор данных был затем разделен на обучающие (70%), валидация (15%) и тестовые (15%) наборы данных. Сам тестовый набор данных был разделен на два субданных (по 7,5% каждый): первый набор данных был назван TEST1 и состоял из слов, которые не были включены в обучающий и проверочный наборы данных; другой субдатасет был назван TEST2 и состоял из слов, которые были включены в обучение набор данных, но полностью различные стили почерка. Основная цель разбиения тестового набора данных на наборы данных TEST1 и TEST2 нужно было проверить разница в точности между распознаванием невидимых слов и слов, видимых на стадии обучения, но с невидимыми стилями почерка.

SimpleHTR модель

Предлагаемая система использует ANN, при этом для извлечения объектов используются многочисленные слои CNN с входной фотографии. Затем выход этих слоев подается в RNN. RNN распространяет информацию через последовательность. Вывод RNN содержит вероятности для каждого символа в последовательности. Для прогнозирования конечного текста реализуются алгоритмы декодирования в выход RNN. Функции CTC отвечают за декодирование вероятностей в окончательный текст. Для повышения точности распознавания декодирование может также использовать языковую модель. CTC используется для получения знаний; выход RNN представляет собой матрицу, содержащую вероятности символов для каждого временного шага. Алгоритм декодирования CTC преобразует эти символические вероятности в окончательный текст. Затем, чтобы повысить точность, используется алгоритм, который продолжает поиск слов в словаре. Однако время, необходимое для поиска фраз, зависит от размеров словаря, и он не может декодировать произвольные символьные строки, включая числа.

Операции: CNN: входные изображения подаются на слои CNN. Эти слои отвечают за извлечение объектов. Есть 5х5 фильтры в первом и втором слоях и фильтры 3х3 в последних трех слоях. Они также содержат нелинейную функцию RELU и максимальный объединяющий слой, который суммирует изображения и делает их меньше, чем входные данные. Хотя высота изображения уменьшается в 2 раза в каждом слое, карты объектов (каналы) добавляются таким образом, чтобы получить выходную карту объектов (или последовательность) размером от 32 до 256. RNN: последовательность признаков содержит 256 признаков или симптомов на каждом временном шаге. Соответствующая информация распространяется РНН через эти серии. LSTM-это один из известных алгоритмов RNN, который переносит информацию на большие расстояния и более эффективное обучение, чем типичные РНН. Выходная последовательность RNN сопоставляется с матрицей 32х80.

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

Данные: Входные данные: это файл серого цвета размером от 128 до 32. Изображения в наборе данных обычно не имеют точно такого размера, поэтому их исходный размер изменяется (без искажений) до тех пор, пока они не станут 128 в ширину и 32 в высоту. Затем изображение копируется в целевой образ размером от 128 до 32 дюймов Белый. Затем значения серого цвета стандартизированы, что упрощает процесс нейронной сети.

LineHTR модель

Модель LineHTR - это просто расширение предыдущей модели SimpleHTR, которая была разработана для того, чтобы позволить модели обрабатывать изображения с полной текстовой строкой (а не только одним словом), таким образом, чтобы еще больше повысить точность модели. Архитектура модели LineHTR очень похожа на модель SimpleHTR, с некоторыми различиями в количестве слоев CNN и RNN и размере входных данных этих слоев: она имеет 7 слоев CNN и 2 слоя Bidirectinal LSTM (BLSTM) RNN.

Ниже кратко представлен конвейер алгоритма LineHTR:

• На входе изображение в градациях серого фиксированного размера 800 x 64 (Ш x В).

• Слои CNN сопоставляют это изображение в градациях серого с последовательностью элементов размером 100 x 512.

• Слои BLSTM с 512 единицами отображают эту последовательность признаков в матрицу размером 100 x 205: здесь 100 представляет количество временных шагов (горизонтальных позиций) в изображении с текстовой строкой; 205 представляет вероятности различных символов на определенном временном шаге на этом изображении)

• Слой CTC может работать в 2 режимах: режим LOSS - чтобы научиться предсказывать правильного персонажа на временном шаге при обучении; Режим ДЕКОДЕР - для получения последней распознанной текстовой строки при тестировании

• размер партии равен 50

Экспериментальные Материалы

Все модели были реализованы с использованием Python и deep learning библиотеки Tensorflow. Tensorflow позволяет прозрачно использование высоко оптимизированных математических операций на графических процессорах с помощью Python. Вычислительный граф определяется в скрипте Python для определения всех операций, необходимых для конкретных вычислений. Графики для отчета были сгенерированы с помощью библиотеки matplotlib для Python, а иллюстрации созданы с помощью Inkscape-программы векторной графики, аналогичной Adobe Photoshop. Эксперименты проводились на машине с 2-кратным " Intel Процессоры Xeon(R) E-5-2680, 4x " NVIDIA Tesla k20x и 100 ГБ памяти RAM. Использование графического процессора сократило время обучения моделей примерно в 3 раза, однако это ускорение не было тщательно отслежено на протяжении всего проекта,поэтому оно могло варьироваться.

SimpleHTR эксперименты

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

Создан словарь слов файлов аннотаций

Файл DataLoader для чтения и предварительного владения набором данных изображений и чтения файла аннотаций принадлежит изображениям

Набор данных был разделен на два подмножества: 90% для обучения и 10% для проверки обученной модели. Для повышения точности и снижения частоты ошибок мы предлагаем следующие шаги: во-первых, увеличить набор данных, используя данные увеличение; во-вторых, добавьте больше информации CNN слоев и увеличение ввода размера; в-третьих, удалить шум на изображении и в скорописи стиле; В-четвертых, заменить ЛСТМ двусторонними ГРУ и, наконец, использование декодера передача маркера или слово поиска луча декодирование, чтобы ограничить выход в словарь слова.

Первый Набор Данных: Для обучения на собранных данных была обработана модель SimpleHTR, в которой есть 42 названия стран и городов с различными узорами почерка. Такие данные были увеличены в 10 раз. Были проведены два теста: с выравниванием курсивных слов и без выравнивания. После изучения были получены значения по валидации данных, представленных в Таблице ниже.

Эта таблица показывает точность распознавания SimpleHTR для раличных методов декодирования (bestpath, beamsearch, wordbeamsearch). Декодирование наилучшего пути использует только выход NN и вычисляет оценку, принимая наиболее вероятный символ в каждой позиции. Поиск луча также использует только выход NN, но он использует больше данных из него и, следовательно, обеспечивает более детальный результат. Поиск луча с character-LM также забивает символьные последовательности, которые еще больше повышают исход.

Результаты обучения можно посмотреть на рисунке ниже:

На рисунке ниже показано изображение с названием региона, которое было представлено на вход, а на другом рисунке мы видим узнаваемое слово " Южно Казахстанская с вероятностью 86 процентов.

Второй набор данных (HKR Dataset): Модель SimpleHTR показала в первом тесте набора данных 20,13% символьной ошибки (CER) и второго набора данных 1,55% CER. Мы также оценили модель SimpleHTR по каждому показателю точности символов(рисунок ниже). Частота ошибок в словах (WER) составил 58,97% для теста 1 и 11,09% для теста 2. Результат например TEST2 показывает что модель может распознавать слова которые существуют в обучающем наборе данных но имеют полностью различные стили почерка. Набор данных TEST1 показывает, что результат не является хорошим, когда модель распознает слова, которые не существуют в обучении и наборы данных проверки.

Следующий эксперимент проводился с моделью LineHTR, обученной на данных за 100 эпох. Эта модель продемонстрировала производительность со средним CAR 29,86% и 86,71% для наборов данных TEST1 и TEST2 соответственно (рисунок ниже). Здесь также наблюдается аналогичная тенденция переобучения обучающих данных.

Заключение

Эксперименты по классификации рукописных названий городов проводились с использованием SimpleHTR и LineHTR на тестовых данных были получены следующие результаты по точности распознавания: 57,1% для SimpleHTR рекуррентного CNN с использованием алгоритмов декодирования с наилучшим путем, 58,3% для Beamsearch и 75,1% wordbeamsearch. Лучший результат был показан для Wordbeamsearch, который использует словарь для окончательной коррекции текст при распознавании.