Что такое ocr в сканере
Сложности применения технологий OCR в DLP-системах, или Как мы OCR готовим
Решение задачи распознавания изображений (OCR) сопряжено с различными сложностями. То картинку не получается распознать из-за нестандартной цветовой схемы или из-за искажений. То заказчик хочет распознавать все изображения без каких-либо ограничений, а это далеко не всегда возможно. Проблемы разные, и решить их сходу не всегда удается. В этом посте мы дадим несколько полезных советов, исходя из опыта разруливания реальных ситуаций у заказчиков.
Но сначала немного истории. Прошло немало времени с момента выхода статьи о том, как мы переписывали сервис фильтрации. В ней мы немного рассказали о фильтрации и обработке сообщений, о том, как устроен наш сервис фильтрации в целом. В этот раз мы постараемся ответить на вопрос «А как же мы обрабатываем изображения, как взаимодействуют сервисы, и что происходит с системой под нагрузкой?» Если оперировать статьей про сервис фильтрации, то сейчас мы будем рассматривать только одну ветку взаимодействия сервисов – это взаимодействие сервиса фильтрации и OCR.
Что такое OCR?
Прежде чем говорить о взаимодействии сервисов и проблемах применения OCR попробуем понять, что такое OCR. Возьмем сложное определение из Википедии.
Оптическое распознавание символов (англ. optical character recognition, OCR) — механический или электронный перевод изображений рукописного, машинописного или печатного текста в текстовые данные, использующиеся для представления символов в компьютере (например, в текстовом редакторе).
Если говорить просто, то взяли картинку, отправили на распознавание, дальше магия вне Хогвартса и получили текст.
Еще можно взять опредление OCR с сайта ABBYY, которое выглядит проще.
Оптическое распознавание символов (англ. Optical Character Recognition – OCR) – это технология, которая позволяет преобразовывать различные типы документов, такие как отсканированные документы, PDF-файлы или фото с цифровой камеры, в редактируемые форматы с возможностью поиска.
А зачем оно (распознавание изображений) нам нужно?
Распознавание изображений мы можем использовать хоть на домашнем ПК для преобразования цифровых изображений в редактируемые текстовые данные.Но стоящая перед нами задача гораздо шире (DLP-система все-таки): нам нужно контролировать поток информации в организации.
DLP-системы давно появились на рынке и сейчас входят в привычный арсенал корпоративных СЗИ (средств защиты информации). Перед DLP стоит задача контроля движения графической информации (отсканированных документов, скриншотов, фотографий). Причем не просто контроля движения графических файлов, а в первую очередь, анализа их содержимого. Система должна уметь понимать, с какой именно информацией она столкнулась, сравнить с образцами защищаемой информации и обеспечить возможности для дальнейшего поиска этой информации пользователем. Применение других средств анализа, таких, как сравнение с цифровыми отпечатками, вычисление хэша, анализ по формату, размеру и структуре файла, также являются ценными источниками информации, но не позволяют ответить на вопрос: «а какой текст передается в данной картинке?» А между тем текст все еще является самым распространённым носителем структурированной информации, в том числе в графических файлах.
Традиционно для распознавания графической информации используют технологию OCR (что это такое мы уже определили). На самом деле OCR – это вообще единственный класс технологий, которые предоставляют возможности извлечения текстовой информации из изображений. Поэтому тут речь не то чтобы о традиционном подходе, а скорее об отсутствии выбора.
Сколько изображений приходит на обработку в DLP-систему?
Неужели нельзя обойтись без OCR? На самом ли деле так много изображений приходит в DLP, что нужно применять OCR? Ответ на этот вопрос – «Да!». За сутки в систему может попадать более миллиона изображений, и во всех этих изображениях может содержаться текст.
OCR в составе DLP-системы «Ростелеком–Солар» используются в компаниях нефтегазовой отрасли и госструктурах. Все заказчики используют возможности OCR для детектирования конфиденциальных данных в отсканированных документах. Что может содержаться в такой «графике»? Да все, что угодно. Это могут быть сканы различных внутренних документов, например, содержащие ПДн. Или информация из категории коммерческой тайны, ДСП (для служебного пользования), финансовая отчетность и т.п.
Как OCR распознает изображения?
Процесс выглядит следующим образом: DLP перехватывает сообщение, содержащее изображение (скан документа, фотографию и т.п.), определяет, что изображение действительно есть в сообщении, извлекает его и отправляет на распознавание в модуль OCR. На выходе DLP получает информацию о содержимом изображения (да и сообщения в целом) в виде извлеченного TEXT/PLAIN.
Если говорить о взаимодействии сервисов непосредственно в нашей системе Solar Dozor, то сервис фильтрации отправляет изображения (если они есть) из сообщения в сервис извлечения текста изображений (OCR). Последний, после завершения распознавания, отдаёт полученный текст в mailfilter. Получается что-то вроде жонглирования изображениями и текстом.
Рассмотрим механизм распознавания глубже на примере работы OCR-технологий ABBYY, которые мы используем в собственной DLP.
Пожалуй, главной проблемой для OCR при распознавании текста является написание того или иного символа. Если взять любую букву алфавита (например, русского или английского), то для каждой мы найдем несколько вариантов написания. OCR-движки решают эту задачу несколькими способами:
Про работу OCR достаточно много различных статей. Подробно о работе OCR можно почитать, например, здесь https://sysblok.ru/knowhow/iz-pikselej-v-bukvy-kak-rabotaet-raspoznavanie-teksta/
Как готовить OCR в целом для распознавания?
Мы уже выяснили, что в DLP может попадать более миллиона изображений. Но все ли изображения из этого миллиона нам полезны?
Ответ на вопрос более чем очевиден – конечно, нет. Но почему нам будут полезны не все изображения? Ответ на этот вопрос тоже достаточно прозрачен: в почте «гуляет» очень много картинок из подписей в сообщениях. Наверное, 90% сообщений (если не больше) будут содержать логотип компании.
Подобные картинки слишком мелкие для распознавания, текста в них может не быть совсем. Здесь мы можем посоветовать (и даже настойчиво порекомендовать) задавать ограничения на размер распознаваемых изображений. При этом ограничения необходимо задавать как по нижней границе, так и по верхней. Вероятность отправки на обработку тяжелых файлов ниже, чем для картинок из подписи, но все же достаточно высока.
Стоит отметить, что цифровые изображения часто имеют разные дефекты. Маловероятно, что в DLP всегда будут попадать сканы документов в хорошем разрешении. Скорее наоборот, сканы всегда будут не в лучшем качестве и с большим количеством дефектов.
Например, в цифровом фото может быть искажена перспектива, оно может оказаться засвеченным или перевернутым, строки скана – изогнутыми. Такие искажения могут усложнять распознавание. Поэтому OCR-движки могут предварительно обрабатывать изображения, чтобы подготовить их к распознаванию. Например, изображение можно покрутить, преобразовать в ч/б, инвертировать цвета, скорректировать перекосы строк. Все это можно задать в настройках OCR и, как следствие, эти инструменты могут помочь улучшить распознавание текста в изображениях.
В итоге мы пришли к базовым принципам подготовки OCR к распознаванию:
Какие челленджи возможны при эксплуатации OCR в DLP под большой нагрузкой?
1. Слишком широкие лимиты на размеры распознаваемых изображений
Начнем с того, о чем мы уже упомянули, – с лимитов.
Исходя из нашей практики, заказчики часто устанавливают слишком широкие лимиты на размеры распознаваемых графических файлов. Да, чтобы OCR работал хорошо, нужно ограничивать размеры изображений. Но заказчики стремятся контролировать все подряд, полагая, что даже в картинке размером 100×100 pixels и 5 Кб могут утечь ценные данные. В целом, конечно, 100х100 pixels и 5 Кб тоже ограничения, но слишком уж низки эти пороги.
Другая крайность – стремление распознать тяжелые файлы по несколько сотен Мб. Понятно, что через корпоративную почту такие изображения не пролезут из-за ограничений на размер пересылаемых сообщений. Но вот по другим каналам перехвата (например, с корпоративных сетевых шар) увесистые файлы настойчиво стремятся распознавать. Если же заказчик хочет добавить к этому еще и большой объем high-res изображений, то для этого нужно иметь соответствующие серверные мощности. В итоге, при столь широких минимальных и максимальных порогах на размер распознаваемых файлов создается высокая нагрузка на процессор на серверах, что замедляет работу всех подсистем.
Что здесь можно порекомендовать? Прежде всего проанализировать, в какой используемой в компании «графике» содержатся конфиденциальные данные, после чего прикинуть разумные минимальные и максимальные ограничения на размеры контролируемых изображений. Обычно мы рекомендуем заказчикам зафиксировать нижнюю границу разрешения изображения от 200 pixels, в идеале от 400 pixels (по осям X и Y), и размера файлов не меньше 20 Кб, лучше больше. Также не имеет смысла отправлять в OCR тяжеловесные изображения – они элементарно перегрузят ваши сервера и не факт, что будут распознаны.
2. Очереди на фильтрацию и таймауты обработки запросов
Чрезмерная нагрузка на серверы, возникающая по вышеописанным причинам, ведет по цепочке к увеличению времени распознавания изображений и обработки запросов в целом. В результате в DLP-системе начинает увеличиваться очередь сообщений на фильтрацию. Кроме того, в OCR-модуль могут приходить графические файлы, которые в принципе невозможно распознать (тяжелые файлы, низкое качество и т.п.), в результате чего возникают таймауты обработки изображений. Если нераспознаваемых файлов поступает много, а в системе установлены высокие таймауты на распознавание, сервис фильтрации ждёт, пока этот таймаут наступит, и только потом приступает к обработке следующего запроса. Весь процесс обработки может серьезно тормозиться.
Что можем посоветовать? При возникновении очереди на обработку графических изображений нужно посмотреть настройки OCR в DLP-системе и попробовать найти причину торможения. Это может происходить, например, из-за проблем межпроцессного взаимодействия на самом сервере. Вообще, эти проблемы заслуживают отдельного разговора. Некоторые подробности по общим вопросам можно узнать из статьи «Знакомство с межпроцессным взаимодействием на Linux».
Кроме этого важным моментом при настройке OCR является выставление адекватных таймаутов на распознавание изображений. В общем случае достаточно 90 секунд, чтобы изображение точно распозналось. Если из изображения не извлекся текст за 90 секунд, то можно предположить, что OCR не распознает изображение в принципе. В этом месте также могут возникать проблемы конфигурирования OCR, когда выставляют высокие таймауты на распознавание и тем самым делаются попытки распознать нераспознаваемое.
Что еще может стать причиной таймаута? Здесь мы снова вернемся к вопросу конфигурирования системы. Сервис фильтрации, как и сервис OCR, оперирует тредами, которые обрабатывают сообщения и изображения. Система может быть некорректно сконфигурирована в части количества обработчиков сервиса фильтрации и количества обработчиков OCR. Например, у сервиса фильтрации будет много тредов-обработчиков, а у OCR всего один. В такой ситуации в какие-то моменты OCR может просто не успевать обрабатывать все запросы на распознавание, и таким образом будут появляться таймауты обработки изображений.
Подобное поведение системы наводит на мысли о проблемах проектирования и багах в архитектуре, но на самом деле это не так. Архитектура нашей DLP предоставляет возможности гибкой конфигурации системы и настройки её под нужды заказчиков. Например, мы можем достаточно просто настроить один OCR на работу с двумя сервисами фильтрации без ущерба производительности.
3. Нераспознаваемые изображения
Если в DLP-систему попадает на анализ изображение, которое OCR не может распознать, существует несколько вариантов решения проблемы.
По каким причинам изображения могут не распознаваться? Например, по следующим:
1. Нестандартная цветовая схема изображения.
2. Низкое разрешение изображения.
3. Неправильная ориентация изображения и содержащегося в нем текста в пространстве.
4. Перекосы строк и искажения пропорций текста в изображении и др.
Приведем пример: у одного из заказчиков в процессе мониторинга выяснилось, что OCR не распознает pdf-документы, выполненные в нестандартной цветовой схеме. То есть изображение извлекалось из PDF-документа в штатном режиме, но когда дело доходило до обработки OCR-модулем, тот не понимал цветовую схему картинки и выдавал на выходе «квадрат Малевича». В нашем интерфейсе картинка выглядела примерно так:
В OCR-движках заложены различные функции автоматической коррекции изображения, которые сильно повышают шансы на успешное распознавание содержащегося в нем текста. Однако, на практике эти волшебные инструменты не всегда срабатывают. В данном конкретном случае мы донастроили для заказчика OCR-модуль таким образом, чтобы он распознавал эту нестандартную цветовую схему.
5. Несоответствие одного из параметров документа заданным размерам распознаваемых
изображений.
Например, в конфигурации системы заданы границы размеров распознаваемых изображений 200х1000 pixels, а в OCR поступил файл размером 500х1500 pixels (верхний лимит превышен). В этом случае необходимо исправить настройки OCR для распознавания таких изображений.
Это, пожалуй, один из самых популярных сценариев донастройки системы после того, как нам говорят, что OCR не работает.
Почему OCR не на агентах?
OCR в DLP-системах реализуется в двух вариантах – на агентах и на серверах. Мы являемся сторонниками второго подхода, поскольку распознавание изображений прямо на рабочей станции создает высокую нагрузку на ее процессор и, соответственно, тормозит работу других приложений. OCR сама по себе весьма прожорливая технология даже для серверов, и её применение требует правильного планирования процессорных мощностей и контроля эффективности.
При этом многие отечественные компании, в особенности в госсекторе, до сих пор владеют достаточно старым парком ПК. Что происходит в этом случае? Пользователи начинают жаловаться ИТ-подразделению на «торможение» ПК, а айтишники в конце концов выясняют, что причиной торможения является OCR-модуль DLP-системы. Это раздражает и их, и пользователей, которые не могут оперативно решать рабочие задачи. В конечном итоге все это складывается в головную боль для безопасника, у которого и других задач полно.
Использование OCR на агентах оправдано лишь тогда, когда DLP-система работает «в разрыв». В этом случае распознавание изображения должно происходить ровно в тот момент, когда пользователь совершает действия с этим графическим файлом на своей рабочей станции. То есть DLP-система должна мгновенно решить судьбу документа, содержащего это изображение – разрешить его к отправке/копированию или запретить. Но на практике только единицы заказчиков используют DLP-систему в режиме активной блокировки, и это касается не только нашей собственной DLP. Здесь работает принцип «все, что можно вынести для проверок на сервер, должно выполняться на сервере».
Итого
Технологии OCR предоставляют возможности распознавания графических изображений, а мы в дополнение всегда даем общие рекомендации по конфигурированию системы. Однако в конкретном проекте может возникать необходимость донастройки работы OCR-модуля под специфические потребности заказчика как на этапе пилотирования и внедрения решения, так и на этапе его промышленной эксплуатации. Это не просто нормально – это единственно верный путь, который даст ощутимый результат, сделает работу OCR в компании максимально эффективной и снизит до минимума утечки конфиденциальной информации через графические изображения.
Никита Игонькин, ведущий инженер сервиса компании «Ростелеком-Солар»
OCR-конвейер для обработки документов
Сегодня я расскажу о том, как создавалась система для переноса текста из бумажных документов в электронную форму. Мы рассмотрим два основных этапа: выделение областей с текстом на сканах документов и распознавание символов в них. Кроме того, я поделюсь сложностями, с которыми пришлось столкнуться, способами их решения, а также вариантами развития системы.
Первичным переводом документа в электронную форму является его сканирование или фотографирование, в результате которого получается графический файл в виде фотографии или скана. Однако такие файлы, особенно высокого разрешения, занимают много места на диске, и текст в них невозможно редактировать. В связи с этим, целесообразно извлекать текст из графических файлов, что успешно делается с применением OCR.
Про OCR и цели
Оптическое распознавание символов (OCR) — перевод изображений машинописного, рукописного или печатного текста в электронные текстовые данные. Обработка данных при помощи OCR может применяться для самых различных задач:
В настоящее время все больше организаций переходят от бумажной формы документооборота к электронной. На одном из моих недавних проектов для компании с большими объемами бумажных документов, требовалось перенести информацию, накопившуюся в сканах (около нескольких петабайт), в электронную форму и добавить возможность обработки новых отсканированных документов.
Мы выяснили, что использование готовых продуктов для решения нашей задачи приводило бы к большим затратам и низкой производительности, вызванной ограничениями объемов обрабатываемых документов. Поэтому мы решили разработать собственную систему OCR по принципу конвейера (OCR-pipeline), в которой последовательно выполняются следующие операции:
Извлечение слов и строк
Перед распознаванием символов из изображения документа целесообразно извлечь части, которые ограничивают слова или строки текста. Способов извлечения много. Существует два основных подхода — нейросетевой и с использованием компьютерного зрения. Остановимся на них подробнее.
В последнее время для детекции слов на изображениях все активнее применяются нейронные сети. При помощи сетей семейства resnet можно выделить прямоугольные рамки с текстом. Однако если документы содержат много слов и строк, то данные сети работают довольно медленно. Мы установили, что вычислительные затраты в этих случаях существенно превышают затраты с использованием методов компьютерного зрения.
Кроме того, нейронные сети resnet имеют сложную архитектуру и применительно к данной задаче их сложнее обучить, так как они больше предназначены для классификации изображений и обнаружения небольшого количества блоков текста. Их использование значительно замедлило бы разработку конвейера и в некоторых случаях снизило бы производительность. Поэтому мы решили остановиться на методах детекции строк посредством компьютерного зрения, в частности, на методе Максимальных Стабильных Экстремальных Регионов (MSER) [1].
Примеры MSER-детекции строк в документах
В ходе MSER-детекции текст в бинаризованном изображении скана предварительно «размазывается» в пятна. На основе субпиксельных вычислений полученные пятна ограничиваются связными областями и обрамляются в прямоугольные рамки. Таким образом, происходит сжатие исходных данных — из скана с документом извлекаются изображения, ограничивающие слова и строки. Стоит отметить, что данный метод не зависит от цвета извлекаемого текста. Важно лишь только то, чтобы он был достаточно контрастен по отношению к фону.
OCR AI
Следующим этапом после MSER-извлечения изображений с текстом является распознавание символов в них. В последнее время исследования в области AI показали, что распознавание символов на изображениях успешней всего выполняется на основе глубокого машинного обучения. В частности, используются нейронные сети, содержащие много уровней (глубокие нейронные сети), которые способны самостоятельно накапливать признаки и представления в обрабатываемых данных.
Генерация данных для обучения
Нейронные сети глубокого обучения, как правило, требуют больших объемов обучающих выборок для качественного распознавания. Ручная разметка и сбор обучающих данных занимают много времени и требуют больших трудозатрат, поэтому все чаще используются готовые датасеты или искусственно генерируются уже размеченные данные. При формировании обучающих выборок для устойчивости системы OCR к искажениям важно использовать как наборы строк хорошего качества, так и строки с различными эффектами и искажениями, обусловленные особенностями сканирования или плохим качеством печати в документах.
В качестве обучающей выборки мы использовали датасет University of Washington (UW3), состоящий из более чем 80K строк из сканированных страниц с современным деловым и научным английским языком. Однако набор геометрических и фотометрических искажений, а также количество используемых шрифтов в строках оказались недостаточными. Поэтому мы решили дополнить обучающую выборку искусственно сгенерированными строками при помощи разработанного автоматического генератора строк текста разного шрифта, цвета, фона, интерлиньяжа и т. п. Использовались 10 наиболее популярных шрифтов, встречающихся в документах: Times New Roman, Helvetica, Baskerville, Computer Modern, Arial и другие.
Дополнительной универсальности относительно шрифтов удалось достичь благодаря использованию информации из Font Map, в которой взаимное расположение шрифтов определяет их сходство — чем ближе два шрифта друг к другу, тем более они похожи. Для дообучения сети было дополнительно отобрано 10 шрифтов на карте, наиболее удаленных от тех, на которых модель уже обучена.
Карта шрифтов Font Map fontmap.ideo.com
Архитектура сети CNN
Входные данные для обучения и распознавания сети — это части изображений сканов со строками или словами, извлеченные на этапе MSER-детекции. Выходные данные — это упорядоченные наборы символов, формирующие текст в электронном формате.
Для распознавания символов в картинках эффективно используются сверточные нейронные сети CNN [2], формирующие представления частей изображений подобно зрительной системе человека.
Сверточная нейронная сеть обычно представляет собой чередование сверточных и пулинговых слоев, объединенных в сверточные блоки (сonvolutional blocks) и полносвязных слоев на выходе (fully connected layers). В сверточном слое веса объединяются в так называемые карты признаков (feature maps). Каждый из нейронов карты признаков связан с частью нейронов предыдущего слоя.
Сети CNN базируются на математических операциях свертки (convolutions) и последующих сокращениях размерности (pooling) с применением пороговых функций, исключающих отрицательные значения весов. Карты признаков после всех преобразований в сверточных блоках конкатенируются в единый вектор (concatenation) на вход полносвязной сети. Рассмотрим операции свертки и сокращения размерности подробнее.
Вычисления в сверточной сети
В сверточном слое входное исходное изображение или карта предыдущего сверточного блока (input data) подвергаются операции свертки (сonvolution) при помощи матрицы небольшого размера (ядра свертки, сonvolution kernel), которую двигают по матрице, описывающей входные данные (input data). Выходными данными (output data) является матрица, состоящая из значений суммы попарных произведений соответствующей части входных данных с ядром свертки. На рисунке показан пример сверточного слоя с ядром свертки размера 3X3.
В слое пулинга уменьшается размерность выходных данных сверточного слоя в два этапа.
На рисунке показан пример слоя пулинга с сокращением размерности в два раза с применением ReLU и max-pooling. Выходные значения передаются на вход следующего сверточного блока или вытягиваются в вектор для полносвязного слоя, если сверточных блоков больше нет.
Архитектура сети для OCR
В нашем случае одних сверточных блоков недостаточно, поскольку обрабатываются большие объемы данных и необходим учет последовательности символов в строках. Поэтому мы использовали гибридную архитектуру, состоящую из
Вычислительные эксперименты
В ходе обучения мы провели серию экспериментов относительно наборов строк в обучающих выборках. Выделим основные из них: на основе только сгенерированных строк (10 наиболее популярных шрифтов + 10 шрифтов из Font Map), на основе сгенерированных строк с тремя наиболее используемыми в документах шрифтами (Times New Roman, Helvetica, Computer Modern) со строками из датасета UW3 и на основе сгенерированных строк (10 + 10 шрифтов) со строками из датасета UW3.
Отметим, что к концу итерационного процесса максимальная точность (accuracy) на валидационной выборке практически одинакова. Точность по тестовой выборке, напротив, имеет существенное различие — добавление строк из датасета UW3 к сгенерированным строкам повышает точность распознавания. При этом увеличение количества шрифтов в искусственно сгенерированных строках также несколько увеличивает точность распознавания.
Обучение нейросети происходило по принципу «раннего останова»: через определенное количество итераций выполнялось распознавание случайно выбранного подмножества строк из обучающей (валидационной) выборки. Если в течение нескольких таких проверок максимальное значение точности не изменялось, то итерационный процесс обучения прекращался и сохранялись веса нейронной сети для распознавания строк из документов. Время обучения рассчитывалось от начала итерационного процесса до останова. Использовались графические ускорители GPU Nvidia семейства Tesla (K8 и V100).
Рассматривались документы с разрешением сканирования от 96dpi на английском языке, в том числе с присутствием цветного текста. Построенная архитектура позволила достичь точности распознавания символов до 95-99%.
Таким образом, в качестве выходных данных мы получаем символы, объединенные в слова или строки, формирующие электронные документы.
Конвейер
Значительное ускорение обработки документов было достигнуто благодаря организации нашей системы распознавания по принципу конвейера с минимизацией простоев, а также за счет распараллеливания вычислений в CPU и GPU и рационального использования памяти. Система развертывалась с помощью Docker и Kubernetes.
Организация системы OCR AI распознавания по принципу конвейера.
Длина прямоугольных блоков, описывающих процедуру обработки, схематично соответствует интервалу времени. Время выполнения каждой из процедур может различаться в зависимости от количества символов в документе.
Load Scan i — загрузка скана i-го документа,
Strokes Detection i — извлечение строк из i-го документа при помощи MSER,
Load Strokes i — OpenCV-предобработка и нормализация извлеченных строк i-го документа и загрузка на вход сети,
AI Recognition i — распознавание символов в строках i-го документа на основе построенной глубокой сети.
Для повышения качества MSER-детекции мы дополнительно применяли математические методы цифровой обработки изображений, которые в том числе исключали нежелательные шумы, естественно возникающие при сканировании бумажных документов. Обработка изображений и MSER-детекция слов и строк реализовывалась на языке Python с использованием библиотеки компьютерного зрения OpenCV.
Для повышения качества обучения, защиты от переобучения и последующего распознавания в нейронной сети AI мы применяли адаптивное обновление весов сети [5], dropout-прореживание [6] и батч-нормализацию [7]. Реализация нейронной сети глубокого обучения также была написана на Python c использованием фреймворка TensorFlow. Вычисления на GPU от Nvidia поддерживались благодаря внедрению технологий CUDA и cuDNN.
Дополнительного прироста производительности предполагается достичь при помощи технологии TensorRT [8], заточенной под оптимальное использование весов сети при вычислениях в GPU, производимых Nvidia (например, таких, как Tesla или k8). При этом веса обученных моделей преобразуются в более сжатый формат с плавающей точкой. Это позволяет более чем в 40 раз повысить скорость вычислений в GPU по сравнению с CPU без видимых потерь точности распознавания.
Что дальше?
Выделим несколько направлений развития нашей системы.