Распознавание

Если вам нужно найти фотографию, сделанную на пикнике несколько лет назад, вряд ли вы помните имя, которое камера автоматически присвоила файлу в момент съёмки, например, 2017-07-04 12.37.54.jpg.Вы просматриваете всё подряд фотографии, их эскизы, пытаетесь определить объекты или признаки искомого и не важно, ищете ли вы потерянное фото или хотите подыскать в архивах приличный снимок для презентации нового проекта.

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

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

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

Наш метод

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

s = f(q, j).

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

Классификация изображений

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

Категории могут быть следующими:

• конкретные объекты на изображении, например, дерево или человек;

• общие дескрипторы сцены, например, на улице или свадьба;

• характеристики самого изображения, например, чёрно-белое или крупный план.

За последнее десятилетие был сделан огромный шаг вперёд в области в классификации изображений с помощью свёрточных нейронных сетей достаточно упомянуть замечательную работу 2012 года. Krizhevsky и др. на турнире ImageNet Сhallenge. С тех пор, благодаря усовершенствованию архитектуры моделей, улучшению методов обучения, большим базам данных, например Open Images или ImageNet, и простым в использовании библиотекам, таким как TensorFlow и PyTorch, исследователи создали классификаторы изображений, способные распознавать тысячи категорий. Оцените, насколько качественно сегодня работает классификация изображений:

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

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

Векторы слов

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

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

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

1. Для слова запроса q можно получить d-мерный вектор слов q_w, нормализованный к единичному вектору. Для векторов в пространстве слов будем использовать нижний индекс w, а для векторов в пространстве категорий нижний индекс c.

2. Для каждой категории получаем нормализованный вектор слов для названия категории cⁱ_w. Затем определяем значение mi = q_w - cⁱ_w косинусное сходство векторов запроса и i-й категории. Полученная оценка от -1 до 1 показывает, насколько близко слово запроса соответствует названию категории. Сводя отрицательные значения к нулю (то есть применяя функцию mi = max(0, mi)), получаем оценку в том же диапазоне, что и результаты классификатора изображений.

3. Таким образом, можно вычислить q_c = [m1 m2 ... mC], вектор в C-мерном пространстве категорий, показывающий, насколько близко запрос соответствует каждой из категорий аналогично тому, как вектор классификатора изображений для каждого изображения показывает, насколько близко изображение соответствует каждой из категорий.

Шаг 3 осуществляем обычное векторно-матричное умножение, q_c = q_wC, где C матрица со столбцами векторов слов категории cⁱ_w.

После сопоставления запроса с вектором пространства категорий q_c к вектору пространства категорий для каждого изображения можно применить косинусный коэффициент и получить таким образом окончательный балл релевантности для изображения s = q_cj_c.

Мы получили функцию релевантности. С её помощью мы ранжируем изображения побалльно и формируем список результатов запроса. Применение данной функции к набору изображений можно также выразить как векторно-матричное умножение, s = q_cJ, в котором каждый столбец J представляет собой выходной вектор классификатора j_c для изображения, а s вектор балльных оценок релевантности для всех изображений.

Пример

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

Предположим, пользователь искал берег. Просматриваем вектор слов, получаем [0,350,62 0,70], затем умножаем на матрицу векторов слов категорий и проецируем запрос на пространство категорий.

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

Описание модели

Наш классификатор изображений представляет собой сеть EfficientNet, натренированную на наборе данных OpenImages. Классификатор выдаёт балльные оценки примерно по 8500 категориям. Мы выяснили, что данная архитектура и набор данных обеспечивают хорошую точность при разумных затратах. Это довольно важно, если приходится работать с клиентской базой Dropbox.

Для тренировки и запуска модели будем использовать TensorFlow и заранее обученные векторы слов ConceptNet Numberbatch. Полученные результаты оказались удовлетворительными, и, что важно для нас, модель способна работать с несколькими языками, возвращая сходные векторы для слов на разных языках со сходными значениями. Это упрощает процесс поиска изображений на разных языках: векторы слов dog на английском языке и chien на французском сходны, поэтому мы можем осуществлять поиск на обоих языках без перевода поискового запроса с одного языка на другой.

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

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

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

Поэтому вместо создания экземпляра J для каждого запроса мы используем описанный выше приближённый метод, который может быть эффективно реализован на поисковом движке Dropbox Nautilus.

По сути, Nautilus состоит из прямого индекса (forward index), сопоставляющего каждый файл с определёнными метаданными (например, именем файла) и полным текстом файла, и инвертированного индекса (inverted index), сопоставляющего каждое слово со списком публикаций (posting list) для всех файлов, содержащих это слово. При текстовом поиске содержимое индекса для нескольких файлов с рецептами может выглядеть примерно так:

Если пользователь ищет белое вино, мы ищем эти два слова в инвертированном индексе и обнаруживаем в doc_1 и doc_2 оба слова, поэтому мы должны включить их в результаты поиска. В doc_3 есть только одно из этих слов, поэтому мы должны либо опустить его, либо поставить последним в списке результатов.

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

Применение методов текстового поиска для поиска изображений

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

Предположим, пользователь ищет слово пикник:

1. Находим вектор q_w для слова пикник и умножаем его на матрицу проекции пространства категорий C и получаем q_c, как описано выше. C это фиксированная матрица, одинаковая для всех пользователей, поэтому её можно хранить в памяти.

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

3. Для каждого результата поиска возьмём вектор пространства категорий j_c из прямого индекса и умножим его на q_c, чтобы получить балльную оценку релевантности s. Получаем результаты с балльной оценкой выше порогового значения, ранжированные по этой балльной оценке.

Оптимизация для масштабируемости

Описанный подход по-прежнему связан со значительными затратами как с точки зрения пространства для хранения данных, так и с точки зрения времени обработки запросов. Для 10000 категорий в прямом индексе для каждого изображения необходимо хранить 10000 балльных оценок классификатора, что при использовании четырёхбайтовых значений с плавающей запятой составляет 40 КБ. А поскольку оценки классификатора редко когда бывают строго нулевыми, в большинство из таких 10000 списков идентификаторов будет добавлено стандартное изображение. Если для идентификаторов изображений использовать четырёхбайтовые целые числа, добавятся ещё 40 КБ и стоимость индексирования одного изображения составит 80 КБ. Другими словами, для многих изображений их индекс будет больше по размеру, чем сам файл изображения!

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

К счастью, существует множество близких к нулю значений, которые вполне можно отбросить, и это не повлияет качество поиска. Оценка релевантности для каждого изображения была представлена выше как s = q_cj_c, где q_c балльная оценка соответствия между запросом и каждой из примерно 10000 категорий, а j_c балльные оценки приблизительно 10000 категорий, полученные с помощью классификатора. Оба вектора в основном состоят из близких к нулю значений, которые не вносят практически никакого вклада в s.

В нашем приближении мы определим значения всех записей q_c и j_cкак равные нулю, кроме нескольких самых больших. Экспериментально было выяснено, что сохранение 10 записей в q_c и 50 записей в j_c вполне достаточно для получения не менее содержательного итогового результата. Экономия на хранении и обработке данных получилась довольно существенной:

• В прямом индексе вместо 10000-мерных плотных векторов мы храним разрежённые векторы с 50 ненулевыми записями, то есть с 50 записями с наиболее высокими балльными оценками категорий для каждого изображения. В разрежённом представлении мы храним позицию и значение каждой ненулевой записи; 50 двухбайтовых позиций (записанных целыми числами) и 50 четырёхбайтовых значений (записанных в виде числа с плавающей точкой) требуют всего около 300 байт.

• В инвертированном индексе каждое изображение добавляется не в 10000, а в 50 списков идентификаторов, что обходится всего в 200 байт. Таким образом, общий размер индекса для каждого изображения составляет 500 байт вместо 80КБ.

• Во время запроса q_c имеет 10 ненулевых записей, поэтому нужно просканировать только 10 списков идентификаторов примерно такой же объём работы выполняется в текстовых запросах. Набор результатов сужается, и такой набор можно быстрее оценить.

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

Доступность функций

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

Поиск в видео?

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

Искусственный интеллект сегодня экономит не только время, но и силы, которые направляются на решение всё более сложных задач. И если вам интересно решать задачи в области искусственного интеллекта, вы можете обратить внимание на наш курс "Machine Learning и Deep Learning", разработанный совместно с компанией NVIDIA.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Привет, хабр! С 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 научных текстов в год и регулярно подаем заявки на патенты.

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

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

Рентгеновская томография - один из двух (наряду с МРТ) самых известных способов заглянуть внутрь непрозрачных объектов. В медицине он является инструментом клинического мониторинга и средством терапии, в индустрии помогает контролировать технологические процессы, в таможне - найти то, что кое-кто предпочел бы спрятать. Эта технология в нашей стране развивается in house на мировом уровне. Но мы в Smart Engines пишем про томографию так часто не только поэтому. Мы - ученые и изобретатели, а томография - неиссякаемый источник проблем и задач, требующих решения (мы уже писали о несовершенных детекторах и широкополосном излучении). Сегодня мы расскажем о том, что делать, если объект исследования не помещается в томограф. Вот как, например, британские ученые исследуют коня в зоопарке. Голову коня в гентри поместить удается, а с остальным дела обстоят сложнее. Пример не очень серьезный, но жизненный. Кто в лаборатории работал, тот в зоопарке не смеется. Заглянув под кат вы узнаете, как получается, что у физиков сантиметровый образец не помещается в километровый томограф, и чем тут могут помочь вычислительные математики.

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

Впрочем, для боди-позитивного маскота можно было бы построить гентри побольше - в чем проблема? Но не все томографические комплексы вообще используют гентри. Есть такая машина - синхротрон. Машиной их называют специалисты, и это может вызвать неправильные образы при первом знакомстве. Размеры такой машины достигают километров, а строятся они, бывает, всем миром. В полном смысле этого слова. Например, синхротрон ESRF, расположенный во французском городе Гренобле, был построен в 1994 году совместными усилиями 20 стран. Синхротрон дает мощнейший узконаправленный пучок рентгеновских лучей. Такой мощный, что время многих измерений сокращается в десятки и сотни тысяч раз. Для регистрации рентгеновского излучения на его станциях используются уникальные плоскопараллельные детекторы с высочайшим пространственным разрешением. Излучатель и детектор остаются неподвижными, а образец вращается. Часто размеры исследуемых объектов, мельчайшие детали которых требуется рассмотреть, большие, а вот размеры детекторов ограничены.

Давайте посмотрим на результат измерений типичного биологического объекта в такой томографической схеме. Это фрагмент кости, отснятый с субмикронным разрешением. Измерения проведены на современном швейцарском синхротроне Swiss Light Source Paul Scherrer Institut. Намётанный глаз позволяет увидеть и контуры объекта, и трабекулы (перегородки) внутри. Но при таком разрешении объект не помещается целиком в поле зрения детектора. На каждой из проекций просматривается только часть объекта.

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

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

По структуре орех похож на кость, и для него нам известен ground truth - реконструкция, полученная при полных данных.

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

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

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

Будем строить такую синограмму, чтобы 1) она в области измерений совпадала с экспериментальной синограммой, 2) существовал объект, которому соответствовала бы наша синограмма (это нетривиальный факт, но не любая функция является синограммой). Предложенный нами для этого итерационный алгоритм называется Field Of View Extension Algorithm - FOVEA (любопытные хабровчане могут порыться в интернете и отгадать, почему аббревиатура составляет именно это слово).

Вот пошаговое описание алгоритма:

1. Создадим массив , заполненный . В нём мы будем итеративно обновлять значения элементов восстанавливаемого цифрового объёма.

2. Рассчитаем синограммы от .

3. Заменим рассчитанные на Шаге 2 значения доступными нам экспериментальными значениями - .

4. Проведём томографическое восстановление из синограммы методом FBP.

5. Рассчитаем синограмму от .

6. Сравним (например, рассчитав L2 норму) и в той области, где мы знаем экспериментальные значения. Если расхождение малое, т.е. экспериментальная и модельная синограммы совпадают, то конец расчёта: искомая реконструкция лежит в . В противном случае переходим на Шаг 3.

Ниже приведены результаты реконструкции обрезанной синограммы методами FBP и FOVEA.

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

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

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

В сегодняшней статье на Хабре мы расскажем про очередную задачу распознавания. Рассмотрим проблему распознавания штрихкодов, которая очень актуальна в связи с непрерывным развитием системы маркировки и системы оплаты товаров по QR-коду в 2021 году.

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

Сегодня не будем углубляться в техническую часть, а рассмотрим существующие проблемы при внедрении технологии распознавания баркодов. Действительно, откуда могут возникнуть проблемы, если штрихкодирование это такой особый способ кодирования данных, который как раз призван обеспечить быстрое и беспроблемное считывание данных машиной? Все алгоритмы декодирования баркодов разжёваны до самых мелочей. Задача декодирования баркодов отлично решается без использования каких-либо нейронных сетей и прочих страшилок нашего века. Кажется, что технология распознавания баркодов это тот космодром, с которого должны взлетать в счастливое будущее большое количество opensource-библиотек.

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

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

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

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

Есть еще одна причина, почему мы не остались в стороне от решения проблемы распознавания штрихкодов. В нашей стране семимильными шагами развивается технология оплаты по QR-кодам (в подтверждение моих слов смотрите, например, материал на vc.ruздесь,здесьиздесь). БудучиучастникамиГлобального договора ООН и ярыми приверженцами ответственного ИИ, мы просто не могли допустить, чтобы рынок не оценил всех преимуществ оплаты по QR из-за фактической неспособности имеющихся бесплатных библиотек распознавания. И не будем забывать про набирающую обороты Систему маркировки и прослеживаемости товаров. Все это натолкнуло нас на создание модуля распознавания штрихкодовSmart Code Engine.

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

Как видите, изображения далеки от идеальных. Мы сравнили качество работы Smart Code Engine с двумя популярными opensource-решениями:OpenCV 4.5.1(библиотека компьютерного зрения с открытым исходным кодом, которую часто применяют при создании системы с ИИ) иZxing(библиотека с открытым исходным кодом для распознавания баркодов). В таблице ниже представлены результаты:

Как трактовать эти числа? Достаточно просто:

• OpenCV серьезно проигрывает Zxing по качеству декодирования;

• Smart Code Engine обеспечивает в 19 раз меньше ошибок, чем Zxing (с OpenCV даже и смысла сравнивать нет).

Возникает вопрос: А на чем ошибаются рассмотренные системы? Проведем анализ ошибок только для Smart Code Engine и Zxing. Ниже представлено единственное изображение, на котором ошиблось Smart Code Engine.

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

А вот несколько примеров, на чем ошибается ZXing. Тоже не самые простые случаи (серьезные проективные искажения, высокая плотность, сложный фон).

На сегодняшний день Smart Code Engine обеспечивает качественное распознавание одно- и двумерных штрих-кодов из различных счетов и квитанций, включая счета за коммунальные и государственные услуги, налоговых документов и счетов, а также билетов, чеков, счетов-фактур, ценников, плакатов и объявлений. Модуль чтения QR-кодов способен читать инвертированные коды, а также устойчив к любой ориентации. Текущая версия Smart Code Engine поддерживает распознавание QR Code, AZTEC, PDF 417, Data Matrix, codabar, CODE_39, CODE_93, CODE_128, EAN_8, EAN_13, ITF, UPC_A, UPC_E.

Smart Code Engine уже внедрен в мобильные приложения Тинькофф Банка, Рокетбанка, СДМ-Банка, Банка Санкт-Петербург. Мы уверены, это только начало.

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

Данные

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

Выбор модели

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

Использовать только ограничивающие рамки (Bounding Box) было бы недостаточно (Object detection). Они могли сильно перекрывать друг друга при разметки, обучении и распознавании, поэтому для обучения решили выбрать одну из моделей, с поддержкой метода сегментации изображения (Image segmentation) . (Рис. 2)

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

В нашем случае разметка объектов на изображении выполнялась вручную на стороннем облачном сервисе. Он предоставлял возможность нескольким сотрудникам размечать один и тот же набор данных удаленно и после завершения разметки скачивать весь набор данных. (Рис. 3, 4, 5, 6)

После разметки достаточного количества фотографий для экспериментов проводилось обучение первых моделей для распознавания деталей на сервере HPE DL380 c двумя видеокартами NVIDIA Tesla v100. В среднем, на обучение первых моделей было затрачено от 8 до 12 часов.

По результатам обучения, были выявлены проблемы, которые препятствовали распознаванию:

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

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

Что делать с ликами?

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

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

Что делать с зеркальными деталями?

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

Как создать модель для разметки

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

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

После этого модели для распознавания были обучены и подобраны параметры. (Рис. 10, 11).

Распознавание бирок и накладных

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

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

Для удобного развёртывания моделей весь backend был перенесен на SAP Data Intelligence.

Интерфейс и SAP Data intelligence

SAP Data Intelligence позволяет не только публиковать и встраивать модели, но и создавать на их базе новые собственные операторы (например, от python оператора). Это помогает переиспользовать существующие модели и встраивать их в необходимых форматах (батч-обработка, стриминг, или публикация REST-сервисов). Кроме этого, основанный на flow-based подходе пайплайн может быть быстро адаптирован под меняющиеся условия. Например, если в будущем потребуется интеграция с ERP / MES или любой другой системой, это будет сделать довольно просто. Также все получаемые фотографии можно собирать в используемое Озеро Данных для дообучения модели и улучшения качества распознавания. Если потребуется масштабировать данный сервис, это будет сделать легко. Достаточно настроить уровень параллелизма (параметр multiplicity) и под модель будет поднято соответствующее количество реплик на уровне kubernetes. Есть встроенные инструменты для отладки пайплайна, логирования, трассировки, мониторинга.

Кстати, нужно пару слов сказать о том, на какой платформе собирался данный проект. Так как система в будущем должна пойти в промышленную эксплуатацию, желательно использовать оборудование промышленного класса надежности. Компания Cisco предоставила для пилота гиперконвергентную систему Cisco Hyperflex, про которую ранее на Хабре уже писали здесь, здесь и здесь .

Так как SAP Data Intelligence полностью построен на контейнерах, важно, чтобы были решены задачи отказоустойчивости кластера Kubernetes и его интеграция с сетями центра обработки данных, в котором будет развернуто решение. Фактически, мы полностью повторили в лаборатории типовой валидированный дизайн Cisco&SAP, описанный здесь и голова за инфраструктуру у нас больше не болела.

В SAP Data Intelligence был создан контейнер со всеми необходимыми библиотеками. Для публикации сервиса использовался стандартный оператор OpenAPI. Весь backend работал в контейнере на сервере. Пайплайн можно было так же запускать на любом другом сервере Data Intelligence (рис. 12).

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

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

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

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