Подробное руководство по созданию AI Pipeline

искусственный интеллект

Шаг за шагом, от идеи к производству

Путь к полному конвейеру данных долог и тернист. Фото:Rodion KutsaevonUnsplash

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

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

план

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

План нашего процесса создания функций ИИ. Изображение предоставлено автором.

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

Затем дайджест используется как временныйанализироватьОснова свободного моделирования для проверки и доказательства ценности абстрактных идей. Электронных таблиц Jupyter и Excel предостаточно. На этом этапе ничего не высечено на камне и ничего не спроектировано должным образом, поскольку свобода — это ключ к инновациям при работе с ML.

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

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

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

Теперь давайте посмотрим, как этот процесс работает с новой функцией распознавания именованных объектов.

идея

Один из основных модулей нашей Dashboard —Аспектный анализ. Мы извлекаем представления из неструктурированного пользовательского текстового контентаатрибуты продукта или услугиобъекты, извлекать их относительную тональность из предложений и объединять их с помощью нашей пользовательской таксономии.

Аспектные термины «авария» и «видео» были извлечены как аспекты и затем классифицированы как отрицательные. Термины, связанные с проблемой, обычно отрицательные. Изображение предоставлено автором.

Этот тип анализа очень гранулирован: аспект обычно состоит из 1-3 маркеров. Мы не получаем полного контекста проблемы: мы извлекаем суть проблемы (авария) и корень причины (видео).

Таким образом, решение состоит в том, чтобы идентифицировать и извлечь все это за один раз.

Извлеките весь пункт. Изображение предоставлено автором.

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

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

Наши RFC имеют определенную структуру.

  • проблема, которую нужно решитьзадний план.
  • проблемаопределение.
  • Предлагаемые решенияс рекомендациями по схеме/модели**. **
  • решенных вопросовстоимость и выгода.
  • Определение успехаи описание артефактов, созданных после завершения реализации RFC.

(Очень) короткий RFC для этой конкретной идеи выглядит следующим образом.

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

Цель: извлечение вопросов из предложений (строки с несколькими маркерами, представляющие вопросы, возникающие у пользователей при использовании продукта).

возможные решения: используйте spacy | Tensorflow | PyTorch, gensim Phraser и классификаторы для пользовательского NER, чтобы найти корень проблемы с помощью синтаксического анализа.

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

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

стандарт проверки

С целями мы начинаем планировать, как их достичь. Как мы узнаем, что мы «достаточно хороши» на полпути к проекту? Или "дойти" действительно работает? Исследовательские задачи, подобные этой, могут занять месяцы постоянных взаимодействий, тестирования новых идей, поиска новых проблем и новых решений... внезапно вы застреваете в петле, где вы даже забываете о том, что представляет собой проект. это смысл.

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

Этап проверки является частью процесса создания RFC: прежде чем углубляться в детали модели машинного обучения, автор должен учитывать особенности проекта.срокиОпределение «Готово». Простые временные рамки помогут командам соответствующим образом планировать задачи, а определение результатов будет направлять вашу работу.

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

Ниже приведена ссылка на интересную статью об управлении проектами данных.Лучшие практики Scrumраздел содержит некоторую информацию о границах проекта.

Управление проектами по науке о данных в 2021 году [Новое руководство для команд машинного обучения] - neptune.ai

специальное моделирование

Моделирование вольным стилем: все, что вам нужно, это (ключевая) доска и мечта. рисунок:Jacob BentzingeronUnsplash

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

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

5 шагов жизненного цикла проекта по науке о данных

Давайте обсудим эти этапы в контексте нашего проекта.

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

Аннотатор именованных сущностей Prodigy. Обратите внимание на совпадение между сущностями: вопрос может касаться функции продукта. Изображение предоставлено автором.

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

Наш выбор исследовательских метрик. Обратите внимание, что задачи имеют большое количество токенов, в то время как сущности «Продавец» и «Человек» встречаются редко. Изображение предоставлено автором.

  • Модель: нам нужно использовать Named Entity Recognizer дляИзвлечение объектов вопросов с более чем 5 токенами. Для этого мы использовалиМодель spaCy EntityRecognizer, модель была обучена на данных, которые мы аннотировали ранее. Основой этого классификатора являетсяen_core_web_trfПредобученная модель, трансформатор на основе RoBERTa.

Просто введите данные в сценарий обучения и измените конфигурацию, чтобы обучить собственный конвейер spoCy.источник.

Как обучить spaCy автоматически обнаруживать новые объекты (NER) [полное руководство].

Анализ модели

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

О... немного низко, не так ли? Оценка F1 0,15 действительно разочаровывает. Изображение предоставлено автором.

Показатели ужасно низкие. Оценка отрицательно коррелирует со средним количеством токенов на класс сущностей. Вопросы и положительный опыт (POS_EXP) — это сущности с наибольшим количеством токенов и наименьшим количеством баллов.

Но мы видим интересные облака слов из результатов извлечения Issue. Понятно, что что-то извлекается, но наши метрики этого значения не воспринимают.

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

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

приговор. Ноутбук начал постоянно перезагружаться.
Комментарий: Начал постоянно перезагружаться.
Извлечение: продолжайте перезапускать

"продолжай перезапускать«Эта частица лежит в основе проблемы. Даже если у нас нет полного контекста этой сущности, мы все равно можем ее спасти! Мы будем знать, многие комментарии цитируются»перезагружать«Это ключевое слово помогает бренду, производящему этот конкретный ноутбук, определить проблему.

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

Сейчас дела обстоят намного лучше, с 0,15 до 0,40. Не лучший, но выполнимый

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

Иногда даже модель, которая считается _сломанной_, может принести большую пользу вашим клиентам.

Архитектурное планирование

Изображение предоставлено автором.

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

Архитектура новой функции должна соответствовать этим трем принципам.

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

По сути, это MLOps: набор хороших практик для управления моделями от концепции до производства.

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

Конвейер обработки данных AWS Lambda + Step Function. Изображение предоставлено автором.

В первом режиме используются AWS Lambdas и Step Functions, обрабатывающие большие объемы данных с помощью разнообразных функций, не требующих тяжелой техники. Функция Ignition извлекает данные из базы данных Athena и отправляет их в очередь. Эта очередь используется одношаговой функцией или службой Kubernetes, которая отправляет результаты в S3 через потоковую передачу Firehose со сжатием Parquet и соответствующим разделением Hive. Результаты можно изучить с помощью таблицы Athena. Лямбды жестко контролируются через журналы Cloudwatch, словари с отформатированной информацией о каждом выполнении лямбда/пошаговой функции.

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

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

Наш второй шаблон основан на пакетных заданиях AWS, запускаемых вставками файлов S3. Всякий раз, когда файл Parquet попадает в корзину S3, запускается пакетное задание для чтения файла и запуска некоторого типа линии обработки, многократно сохраняя результаты в потоке Firehose. Простота этого конвейера компенсируется сложностью сценария: пакетные задания должны быть должным образом многопроцессорными, чтобы использовать всю вычислительную мощность машины.

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

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

Интерфейсный прототип

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

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

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

Фокус команды по науке о данных смещается вместе с целями компании. Изображение предоставлено автором.

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

мы можем использоватьTableauСоздайте рабочий прототип, подключенный к нашей панели аналитики продукта. Подключить информационные панели Tableau к HTML-страницам очень просто.

Как встроить информационные панели Tableau в веб-страницы | Zuar

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

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

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

Мы надеемся, что это путешествие по нашей методологии поможет вам в вашем путешествии по данным!