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

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

Таким образом, процесс обучения модели в основном находится в автономном режиме. Обучение модели в основном выполняется специалистами по анализу данных и статистиками. Эти люди записывают требования, собирают данные, выполняя различные SQL-запросы к базам данных, а затем приступают к очистке данных и процессу выбора функций. После подготовки данных они обучают модель, подходящую для конкретного варианта использования или бизнес-требований, проводят валидацию и тестирование. И, наконец, у вас есть модель, которую нужно внедрить в производство. Модель предоставляется разработчикам в различных форматах в зависимости от библиотек / языка, используемых для обучения модели, например, в виде файла pickle, файла PMML или любого другого формата.

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

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

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

  1. Клиент
  2. Служба предварительной обработки
  3. Служба вычислений / развертывания
  4. Служба постпроцессора

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

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

В. Зачем нам это, если у нас есть модель с точностью, скажем, 99%?

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

В. Как это работает?

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

Наконец, давайте рассмотрим все четыре компонента, упомянутых выше

Часть 1: Клиент

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

Часть 2: услуга предварительной обработки

У нас есть связь службы препроцессора с кешем, базами данных, и она может подписаться на несколько тем Kafka. У Kafka будет несколько производителей, и он будет предоставлять нам данные в режиме реального времени, мы также можем вставлять данные аналитики в поток в соответствии с требованиями модели. Клиент также может загрузить данные в базу данных или, скажем, в S3, которые позже могут быть сохранены в кеше, например, Redis, но эти данные будут в основном статичными, например, история пользователя, как упомянуто в Части-1. И, в конце концов, вся логика, необходимая для преобразования необработанных входных данных и данных во входные данные, которые требуются модели, будет находиться только в этой службе. Например, если нам нужно нормализовать некоторые параметры или масштаб и т. Д.

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

Часть 3. Вычислительная служба

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

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

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

Теперь один из примеров онлайн-обучения: скажем, мы проводим тест, в котором модель решает рекомендовать продукт X конкретному покупателю или нет. Итак, давайте возьмем трех клиентов, которые скажут P, Q и R.

Модель решила рекомендовать продукт X; P и Q, но не R.

И в итоге произошло следующее:

  • Продукт X был рекомендован P, и он купил это
  • Продукт X был рекомендован Q, но он не купил его
  • Продукт X не был рекомендован R, но он в конечном итоге покупает его, ища то же самое.

Мы смогли убедиться в этом, проверив запись в нашей базе данных бронирования, и все было сделано без какого-либо вмешательства человека. В ходе всего этого анализа мы доработали модель, чтобы в следующий раз она рекомендовала продукт X и продукт, аналогичный X, для R и не рекомендовала такой продукт Q. И вот как наша модель в конечном итоге исправляет себя, допуская ошибки в прошлое.

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

Часть 4. Служба постпроцессора

Эта служба отображает выходные данные модели так, как ожидают клиенты. Скажем, если модель выводит вероятность выше 0,5, клиенты хотят истины, а если она ниже 0,5, клиент требует ложь или говорит, что наша модель дает оценку рекомендации для некоторых продуктов, и нам нужно объединить эту оценку с другими параметрами и, наконец, предоставить лучшие результаты k для клиент; вся эта логика выполняется через этот сервис.

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

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

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

Спасибо ……… до скорой встречи.