Что такое ocr в управлении

Update

Медиа о технологиях в бизнесе

Что такое OCR и как оно помогает ускорить бизнес-процессы

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

Как компьютер распознает текст

OCR (англ. optical character recognition) — технология автоматического анализа текста и превращения его в данные, которые может обработать компьютер. Человек распознает символы с помощью глаз и мозга. Компьютер использует камеру сканера, которая создает графическое изображение текстовой страницы. Для компьютера нет разницы между сканом текстового документа и фотографией: и то, и другое — набор пикселей.

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

Метод распознавания паттерна

В 1968 году компания American Type Founders, которая с конца 19 века занималась созданием печатных шрифтов, придумала шрифт OCR-A с буквами одинаковой ширины. В основном шрифт использовали в банковских чеках, а для его чтения компьютером было создано специальное программное обеспечение.

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

Выявление признаков

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

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

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

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

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

Шаги распознавания текста

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

Сначала OCR-программа объединяет пиксели в буквы, а буквы — в вероятные комбинации, затем система сопоставляет их со словарем. Если комбинация букв находится, то она отмечается как распознанное слово. Если нет — программа подставляет наиболее вероятный вариант.

Чему еще можно обучить OCR-систему

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

Например, сервис «Цифровой бэк-офис» от МегаФона может собирать типовую документацию с помощью конструктора, выделять нужную информацию из первичной документации и генерировать ответы на запросы госорганов. Процесс идентичен тому, что происходит в обычном офисе юриста, только вместо живого человека — чат-бот, который собирает информацию и выдает готовый документ. Главные преимущества — отсутствие ошибок «человеческого фактора» и скорость подготовки документов: время сокращается с привычных 30 до 5 минут.

Также функция по распознаванию первичной документации может быстро перенести нужную информацию из актов и счетов-фактур в учетные системы. OCR-система получает типовой документ на входе и генерирует ответ в нужной форме. Например, «Судебная платформа» в «Цифровом бэк-офисе» МегаФона может работать в таком режиме с запросами от госорганов, претензиями и судебными исками. На подготовку отзыва системе понадобится всего около 20 секунд.

Источник

Помогите прочитать, что здесь написано? (OCR)

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

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

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

Для преобразования различных типов документов (отсканированные документы, PDF-файлы или фото с цифровой камеры) в редактируемые форматы с возможностью поиска мы используем технологию оптического распознавания символов – Optical Character Recognition (OCR).

Работа со стандартными документами: постановка задачи

Заказ SIM-карты для пользователя выглядит так:

пользователь решает заказать SIM-карту;

фотографирует удостоверение личности для автоматического заполнения анкеты;

курьер доставляет SIM-карту.

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

Цель проекта OCR: построить быструю и точную кросc-платформенную модель, занимающую небольшой объем памяти на устройстве.

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

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

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

Post-processing: модель вычищает предсказанный текст.

Локализация границ документа

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

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

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

Так выглядит подбор подходящей маски

исправляется перспектива изображения;

определяется тип документа;

изображение обрезается по найденной маске c удалением фона.

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

Следующий этап — распознавание текста. Но перед этим расскажу, как происходит сбор данных для обучения модели.

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

Данные для обучения

Мы подготавливаем данные для обучения одним из следующих способов.

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

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

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

Примеры 2D-трансформаций

Показательный пример 2D-трансформации представлен в библиотеке для Python Text-Image-Augmentation-python. На вход подается произвольное изображение (слева), к которому могут применяться разные виды искажений.

Применяем разные виды искажений Дисторсия, перспектива и растяжение изображения с помощью библиотеки Text-Image-Augmentation-python

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

Пример изображений в сформированной нами обучающей выборке на основе применения аугментации

Так можно создать обучающую выборку.

Обучающая выборка

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

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

Посимвольное распознавание текста

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

Предсказывание локального текста без сегментации (end-2-end-решение)

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

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

Отличие результатов распознавания реальной и идеальной модели

Чтобы обойти проблему дублирования символов, добавим спецсимвол, например «-», в словарь. На этапе обучения каждое текстовое представление кодируется по следующим правилам декодировки:

два и более повторяющихся символа, встретившиеся до следующего спецсимвола, удаляются, остается только один;

повторение спецсимвола удаляется.

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

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

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

Мы попробовали обучить модель на разных архитектурах нейросетей с использованием и без использования рекуррентных слоев по схеме, описанной выше. В итоге остановились на варианте без использования рекуррентных слоев. Также для придания ускорения inference части, мы использовали идеи сетей MobileNet разных версий. Граф нашей модели выглядел так:

Схема итоговой модели

Методы декодирования

Хочу выделить два наиболее распространенных метода декодирования: CTC_Greedy_Decoder и Beam_Search.

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

Метод «Beam_Search» — лучевой алгоритм, в основании которого лежит принцип: следующий предсказанный символ зависит от предыдущего предсказанного символа. Условные вероятности совстречаемости символов максимизируются и выводится итоговый текст.

Post-processing

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

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

Оптимизация модели

Техники оптимизации

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

В этом нам помогли следующие техники:

Квантование модели, при котором вычисления вещественных чисел переводятся в более быстрые целочисленные вычисления.

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

Для увеличения скорости распознавания текста используются мобильные версии архитектур нейросеток, например, MobileNetV1 или MobileNetV2.

Так, в результате оптимизации мы получили снижение качества всего на 0,5 %, при этом скорость работы увеличилась в 6 раз, а размер модели снизился до 60 килобайт.

Вывод модели в продуктив

Процесс вывода модели в продуктив выглядит так:



Мы создаем 32-битную TensorFlow модель, замораживаем ее и сохраняем с дополнительными оптимизациями типа weight или unit pruning. Проводим дополнительное 8-битное квантование. После чего компилируем модель в Android- или iOS-библиотеку и деплоим ее в основной проект.

Рекомендации

На этапе развертывания задавайте статическое выделение тензоров в графе модели. Например, в нашем случае скорость увеличилась в два раза после указания фиксированного размера пакета (Batch size).

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

Аккуратно подбирайте шрифты для обучающей выборки. Подготовьте для вашего словаря набор шрифтов, допустимых для отрисовки интересующих символов. Например, шрифт OCR B Regular не подходит для кириллического словаря.

Пробуйте тренировать собственные модели, поскольку не все opensource-библиотеки могут подойти. Перед тем как тренировать собственные модели, мы пробовали Tesseract и ряд других решений. Так как мы планировали развертывать библиотеку на Android и iOS, их размер был слишком большим. Кроме того, качество распознавания этих библиотек было недостаточным.

Источник

Сложности применения технологий 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 в компании максимально эффективной и снизит до минимума утечки конфиденциальной информации через графические изображения.

Никита Игонькин, ведущий инженер сервиса компании «Ростелеком-Солар»

Источник