Автоматизация конвейера обработки данных с помощью связанных функций Azure

Это сообщение и его код написаны в соавторстве с Codeprincess.

Машинное обучение - это все о данных ... и алгоритмах. Но в первую очередь и самое главное - это данные. И это не просто данные, нам нужно достаточное, высокое качество и (и во многих случаях) «очищенные» данные. Когда мы говорим об очистке данных, мы обычно используем слово «споры». Пререкания похожи на стирку одежды: ваши грязные данные входят, а чистые, аккуратно отглаженные и сложенные данные выходят. Из опыта и исследований мы знаем, что специалисты по обработке данных тратят 80% своего времени на обработку (= очистку) данных - неудивительно, что люди время от времени называют их «уборщиками данных»!

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

Неудивительно, что люди время от времени называют специалистов по обработке данных «уборщиками данных»!

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

Автоматизация процесса согласования данных
Чтобы ускорить процесс согласования, с одной стороны, и сделать его менее болезненным, с другой стороны, мы можем автоматизировать этот процесс. Отличная технология для использования - Функции Azure. Функции Azure - это краткосрочные фрагменты кода без сохранения состояния и без сервера. Вы можете писать их на многих языках, в этой ситуации мы использовали C # и JavaScript. Каждый шаг в процессе согласования переходит в свою собственную функцию Azure, которая затем будет связана друг с другом, чтобы сформировать конвейер, в который поступают грязные данные, а чистые данные выходят.

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

Прекрасный клиент Microsoft Италия хочет получить определенную информацию из распечатанных квитанций, такую ​​как общая цена, отправитель и получатель. Звучит достаточно просто, правда? Ну подумай еще раз. Квитанции бывают разных форм и размеров. Некоторые из них похожи на квитанции такси или те маленькие квитанции, которые вы получаете от парковочных автоматов или портативных платежных терминалов. Другие могут быть тщательно разработанными счетами в гостиницах или даже занимать несколько страниц. Другими словами, рассматриваемые квитанции почти не имеют ничего общего. Но что у них было общего, так это то, что они были сохранены в формате PDF.

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

Имея представление о том, что ключевое слово указывает, где, вероятно, находится наша информация, мы начали просматривать различные службы, которые могут предоставить нам информацию о местоположении текста в документе. Однако поиск был довольно коротким, потому что мы вспомнили, что Набор инструментов Cognitive Services имеет здесь кое-что полезное: Computer Vision OCR API. Он возвращает текст с оптическим распознаванием текста с изображения и предоставляет дополнительную информацию о расположении текста.

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

Итак, нашим первым шагом было преобразование наших входных квитанций PDF в изображения, потому что наш API OCR Computer Vision просто принимает изображения в качестве входных данных. Затем эти изображения были просканированы службой на предмет текста и возвращены с метаданными местоположения в формате JSON (вспомните трио «регион-линия-слово»). См. Изображение выше для примера результата OCR API.

Для дальнейшего анализа формат JSON пока не был практичным. Вот почему мы решили его сгладить. Мы вычистили подробную информацию о регионах и просто упаковали весь текст в одном регионе в одну строку. Преимущество этого было в том, чтобы легко сканировать строки на предмет ключевых слов. Представьте, что вы просматриваете строки по ключевому слову «Totale» и, если оно подходит, ищите число в той же строке. Ключевое слово «Totale» и, если оно подходит, ищите число в той же строке. Тогда весьма высока вероятность того, что мы нашли общую сумму квитанции. Победа!

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

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

- Функции Azure

- Хранилище BLOB-объектов Azure

Для каждого шага обработки мы создали функцию Azure для размещения и запуска логики. И было создано хранилище BLOB-объектов, чтобы сохранять результат каждого логического шага. Чтобы завершить работу, мы начинаем конвейер с хранилища BLOB-объектов, потому что все PDF-файлы квитанций были сохранены в хранилище BLOB-объектов. Когда новый PDF-файл загружается в это хранилище BLOB-объектов, конвейер запускается и обрабатывает PDF-файл.

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

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

- Внезапно! Появляется дикий документ!

- Документ сохраняется в хранилище BLOB-объектов, скажем, в папке «документы».

- Первая функция Azure (называемая PdfToPng, написанная на C #) запускается. Это хранилище BLOB-объектов запускается и преобразует PDF-файл в PNG, чтобы сохранить его в папке хранилища BLOB-объектов images. Эта функция зависит от GhostScript для выполнения преобразования. Взгляните на этот пост, чтобы узнать, как настроить зависимости.

- Создание этого PNG-файла запускает следующую функцию Azure (называемую PngToOcr, написанную на C #). Эта функция передает изображение через службу OCR, чтобы сохранить результат JSON в папке хранилища BLOB-объектов «json».

- К настоящему времени неудивительно, что затем запускается другая функция Azure (называемая OcrToFlat, написанная на Node.js). Он берет данные JSON и просто создает одну строку из всего текста в одной обнаруженной области OCR, чтобы сохранить ее в папке хранилища BLOB-объектов «flatjson».

Сделанный! И что удивительно, функции Azure работают «без сервера», что означает, что у нас не было дополнительных затрат на их настройку. Все, что мы сделали, это «просто» поместили в них наш код, определили триггер и куда должны идти выходные данные. Мы даже смешивали и сопоставляли языки программирования, используя все, что лучше всего подходит для этого шага и / или по выбору разработчика. Создана наша сеть! Еще одним большим преимуществом является то, что функции выполняются параллельно - или, лучше сказать, «масштабирование», что экономит нам много времени. Цепочка запускается для каждого документа индивидуально, который помещается в папку «документы». Таким образом, нет фактического времени ожидания для обработки каждого документа.

На иллюстрации у нас есть еще один дополнительный компонент, о котором пока не упоминалось, - это LUIS. LUIS - это Служба понимания языка из того же набора инструментов, который мы уже используем для Computer Vision OCR API. Но кроме OCR API, LUIS не обнаруживает текст на изображениях, он обнаруживает намерение и значение в тексте. Это отлично подходит для нашего набора данных, потому что с LUIS мы можем узнать, что такое плоская строка, которую мы создаем на последнем этапе нашей цепочки. Таким образом, в дополнение к простому сопоставлению ключевых слов мы можем использовать этот интеллектуальный сервис, чтобы получить более высокие показатели поиска при поиске нужной нам информации из наших рецептов.

Код
Весь код доступен в этом репозитории Github.

Согласитесь - это немного круто :) А технологии просто потрясающие: D Как вы думаете?

(Больше сообщений смотрите в моем блоге Dutch Data Dude)