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

Две недели назад я посетил первую MLOps: Production and Engineering World, двухдневную виртуальную конференцию, организованную Обществом машинного обучения Торонто, на которой исследуются передовые практики, методологии и принципы эффективных MLOps. В этом посте я хотел бы поделиться содержанием выступлений, которые я посетил во время этой конференции.

Пост состоит из 5 частей:

  1. Управление проектами машинного обучения
  2. Метрики машинного обучения
  3. ML Исследования
  4. Примеры использования ML
  5. Инструменты ML

1 - Управление проектом

В своем докладе «Что можно и чего нельзя делать при реализации проектов ИИ» Ян Завадски поделился своими практическими советами по разработке, оценке и анализу проектов ИИ.

В то время как традиционные проекты чаще всего оказываются успешными, проекты ИИ часто терпят неудачу. Это потому, что довольно сложно определить, что делает хорошие проекты ИИ. Это также первый шаг в потоке создания ценности ИИ, который включает: (1) определение проекта, (2) модель прототипа, (3) модель производства и (4) оценку результатов.

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

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

Вначале мы хотели бы создать как можно больше идей для проектов ИИ, а затем мы сможем их оценить и оценить. Чтобы обнаружить идеи, Ян предложил такие инструменты, как AI The Game или Design Thinking, которые могут помочь нам в разработке проектов с твердым стартом или расчетом ставок.

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

Чтобы оценить эти идеи, Ян предложил метод RICE:

  • Охват. Сколько клиентов получат выгоду от решения?
  • Воздействие. Насколько эта функция способствует достижению наших текущих целей?
  • Уверенность: насколько вы уверены, что сможете реализовать проект AI?
  • Усилия: сколько времени нужно на реализацию проекта AI?
  • Окончательная оценка RICE рассчитывается как (R x I x C) / E

В занимательной беседе Создайте гармонию между инженерами машинного обучения и исследователями машинного обучения Луна Фэн обсудила проблемы внедрения решения машинного обучения в производство в связи с сотрудничеством между инженерами машинного обучения и исследователями. Что касается контекста, она была инженером и исследователем в Thomson Reuters Center for AI and Cognitive Computing в течение последних лет в разные периоды.

Она отправила опрос внутренней команде своей компании, состоящей из 7 исследователей и 8 инженеров, а затем проанализировала данные, чтобы прийти к заключению.

  • Коллективные навыки, которые совпадают между обеими ролями, - это Python, Java и контроль версий.
  • В повседневные задачи инженеров входят: работа над системным дизайном и интеграцией моделей, построение инфраструктуры модели, исправление ошибок, разработка / интеграция новых функций и моделей.
  • Ежедневные задачи исследователей включают чтение / написание статей, предварительную обработку данных, проведение экспериментов, реализацию идей, исправление ошибок.
  • Обычные задачи, которые являются общими для них, включают обзор кода, рефакторинг кода, интеграцию функций, модульные тесты, отладку.
  • Сотрудничество чаще всего происходит на этапе развертывания модели.

Она обсудила навыки, которые инженеры и исследователи ожидают друг от друга:

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

Она также рассмотрела проблемы, возникающие во время сотрудничества:

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

Она предложила полезные методы повышения эффективности работы между двумя функциями:

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

2 - Показатели

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

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

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

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

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

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

  • Он должен быть сопоставимым по моделям.
  • Это должно быть просто и понятно.
  • Его можно собирать в режиме реального времени.
  • Это позволяет оперативно предупреждать о проблемах.

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

  • Рекомендации создаются из последовательности конфигураций с помощью модели и правил фильтрации.
  • Затем реализация была выполнена с использованием простых показателей хороших и плохих ответов.
  • Оповещение запускается пороговым значением для каждого варианта использования.
  • Для анализа полезны более длинные временные диапазоны.
  • Предупреждения о качестве могут использоваться во время развертывания для обнаружения ошибок в новой версии стека (путем измерения распределения различий между старым и новым стеками).

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

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

Итак, когда нам следует измерять показатели?

  • Об обучении: получение показателей в процессе обучения может иметь решающее значение, когда у нас есть две или более моделей в производстве.
  • Регулярно: это просто означает получение показателей через определенные промежутки времени (каждый день, еженедельно, раз в две недели и т. Д.)
  • Live: Хорошая практика - измерять метрики сразу после запуска шага вывода.

И где нам следует измерять показатели?

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

Наконец, вот важные аспекты, на которые она рекомендовала обратить внимание:

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

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

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

  • Шаг 1 - собрать входные и выходные данные моделей.
  • Шаг 2 - создание показателей путем измерения статистики с течением времени. Для входных данных это распределения значений характеристик, таких как среднее значение, стандартное отклонение, межквартильный диапазон, количество, процентили, гистограмма и т. Д. Для выходных данных это распределения предсказанных классов, уверенность победившего класса, матрица путаницы и т. д.
  • Шаг 3 - отслеживать показатели на предмет неожиданных изменений. Простые информационные панели не масштабируются с миллионами моделей, развернутых в производстве. Таким образом, Айра предлагает использовать автоматическое обнаружение аномалий временных рядов для отслеживания этих показателей.

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

3 - Исследования

В статье «Машинное обучение с сохранением конфиденциальности» Патрисия Тейн представила практические примеры, показывающие, как стратегически подходить к проблемам конфиденциальности. Вообще говоря, четыре столпа машинного обучения с полным сохранением конфиденциальности включают (1) конфиденциальность обучающих данных, (2) конфиденциальность входных данных, (3) конфиденциальность весовых коэффициентов модели и (4) конфиденциальность выходных данных.

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

Существуют различные практические применения этих инструментов:

  • Гомоморфное шифрование широко используется для анализа геномных данных.
  • Безопасные многосторонние вычисления использовались для распознавания лиц и отпечатков пальцев.
  • Дифференциальная конфиденциальность использовалась в предсказаниях Apple QuickType и Google GBoard для рандомизации ответов.
  • Анонимизация и псевдонимизация использовались для деидентификации наборов клинических данных для защиты личности клиента.
  • Синтез данных использовался для создания синтетических структурированных данных о здравоохранении.

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

4 - Примеры из практики

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

Для контекста, основным продуктом Mist является Беспроводная локальная сеть на базе искусственного интеллекта (WLAN), которая делает Wi-Fi предсказуемым, надежным и измеримым, а также обеспечивает масштабируемые услуги определения местоположения внутри помещений, такие как поиск пути, сообщения о близости и видимость активов. Эта система состоит из множества различных компонентов, включая беспроводной сегмент, проводной сегмент, межсетевой экран, интернет-сегмент и инфраструктуру центра обработки данных. В частности, они используют распределенную облачную архитектуру программного обеспечения с четырьмя уровнями:

  1. Уровень данных: этот уровень включает статистику временных рядов / события / конфигурацию / журналы, поступающие от пользователя / приложения / сетевых устройств.
  2. Уровень событий. Этот уровень включает мониторинг и определение базовых показателей модели, обнаружение аномалий, происшествий и событий, связанных с состоянием здоровья.
  3. Уровень диагностики. Этот уровень включает пространственный и объемный анализ, временные события, корреляцию между объектами.
  4. Уровень действий. Этот уровень включает автоматические и рекомендуемые действия, а также помощник по устранению неполадок.

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

Команда Mist рассмотрела различные типы моделей: начиная с эвристических подходов, затем с окнами скользящего среднего, затем с онлайн-ARIMA и, наконец, заканчивая нейронными сетями LSTM. Этот последний тип модели представляет собой двунаправленный LSTM со 100 скрытыми узлами и 27000 параметрами, который использует большой объем данных по многочисленным измерениям для выявления тенденций и выявления аномалий в тысячах сетей Wi-Fi и решения проблем. в реальном времени. Кроме того, для решения проблем, связанных со стохастической природой неконтролируемого обнаружения аномалий в конвейере рабочего процесса, они также разработали новые статистические модели для рабочего процесса обучения, чтобы использовать исторические данные.

Чтобы управлять десятками тысяч моделей обнаружения аномалий, они построили облачный и масштабируемый конвейер обучения машинного обучения, который автоматизирует все этапы операций машинного обучения, включая сбор данных, обучение модели, проверку модели, развертывание модели и контроль версий. Здесь служба обнаружения аномалий происходит ежечасно, а задания по обучению - еженедельно. Рабочий процесс вывода отделен от процесса обучения, чтобы повысить гибкость и минимизировать задержку обслуживания модели. В конвейере рабочего процесса используются различные технологии, включая сервис Secor, сервис Amazon S3, задания Apache Spark в кластере Amazon EMR, ввод Apache Kafka, планировщик Airflow и базу данных ElasticSearch.

В статье Масштабные MLOps: прогнозирование времени отправления автобусов с использованием 18 000 моделей машинного обучения Хуберт Дуан и Алиса Гиббонс обсуждали уникальный случай, над которым Microsoft работала с TransLink, Metro Транспортное агентство Ванкувера. Компания TransLink нуждалась в более точных и надежных оценках отправления автобусов, чтобы повысить удовлетворенность пассажиров. Для этого они создали Систему прогнозирования отправления автобусов: крупномасштабное комплексное решение Azure, в котором используется более 18 000 моделей машинного обучения, чтобы предсказать, когда следующий автобус отправится с каждой остановки.

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

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

  • В масштабах всей архитектуры мы начинаем с источников данных, которые затем передаются в фабрику данных, которая переходит в службы данных Azure, которая переходит в Azure Infrastructure-as-a-Service для обучения, которая переходит в Azure Machine Learning Model Management, и, наконец, попадает в производственную среду заказчика.
  • В частности, прием данных, преобразование данных, повторное обучение модели и развертывание модели полностью автоматизированы.

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

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

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

  • Уровень 1 означает развертывание вручную. Это работает, когда модели не меняются, и легко начать работу, не беспокоясь о конвейере.
  • Уровень 2 означает автоматизацию частей конвейера. При этом используются принципы CI / CD, которые сокращают время развертывания и снижают подверженность ошибкам.
  • Уровень 3 включает в себя CI и CD, включая разработку, экспериментирование и мониторинг моделей машинного обучения.

Вот шесть анти-паттернов, о которых идет речь:

  1. Жертвовать повторяемостью в пользу быстрой доставки. В действительности конвейеры машинного обучения требуют быстрой итерации, поскольку обычно развертывается несколько моделей в день. Таким образом, трудоемкие этапы, такие как конфигурация модели, модульное / интеграционное тестирование, проверка модели, должны быть автоматизированы.
  2. Воспроизведение реального мира в вашем конвейере сохранит точность моделей. Это применимо только в таких настройках, как Industrial AI. Вместо того, чтобы пытаться добиться высокой точности моделей в производственной среде, вам следует сосредоточиться на инфраструктуре, которая позволяет быстро переобучать модели. На этапе проверки модели, особенно в динамических средах, нет необходимости воспроизводить реальные настройки.
  3. Расхождения в обучении и обслуживании можно устранить, сосредоточив внимание на согласованности между обучением и обслуживающей инфраструктурой. На самом деле, задержка при переработке имеет гораздо большее значение!
  4. Внедрение новой технологии требует для бизнеса неоправданных затрат. В Petuum Apache Spark не был решением всех проблем. Саранян упомянул, что Apache Flink - лучшее решение для управления состоянием и хорошо работает с проблемами Интернета вещей.
  5. Инфраструктура потоковой передачи в реальном времени и пакетной потоковой передачи должна отличаться. В действительности, поддержка в реальном времени должна масштабироваться с пиковой нагрузкой и более высокими вычислительными ресурсами, в то время как пакетная потоковая передача требует более низких эксплуатационных требований.
  6. Машинное обучение - это сложная часть. Что ж, есть и другие проблемы: отсутствие управления жизненным циклом, обработка автономных пакетов, полная оркестровка, которая должна выполняться в уникальных последовательностях, и т. Д.

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

  1. Тщательно продумайте повторяемость.
  2. Не бойтесь неопределенности.
  3. Отслеживание задержки может иметь жизненно важное значение для устранения перекоса производительности.
  4. Упростите внедрение и замену инструментов и фреймворков.
  5. Избегайте избыточности инфраструктуры.
  6. Обратите внимание на весь жизненный цикл модели.

5 - Инструменты

Трубопроводная задолженность - это техническая задолженность по конвейерам данных, которые не документированы, непроверены и нестабильны. В системе машинного обучения непогашенная задолженность может легко привести к распространению непредвиденных последствий и экспоненциальному росту нагрузки на техническое обслуживание. В статье Борьба с трубопроводным долгом с большими ожиданиями Абэ Гон представляет Большие надежды - ведущий проект с открытым исходным кодом для борьбы с трубопроводным долгом. Основываясь на концепции ожиданий (утверждений о данных), он предоставляет гибкие инструменты для проверки данных на соответствие ожиданиям, компиляции ожиданий в удобочитаемую документацию и генерирования ожиданий путем профилирования выборочных данных. Загляните на сайт и примите участие в его растущем сообществе разработчиков ПО с открытым исходным кодом!

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

  1. Система управления версиями, такая как Github и Gitlab, не всегда может отслеживать изменения в наборе данных.
  2. Модели обучения не похожи на создание программного обеспечения.
  3. Оценивать показатели намного сложнее.

В статье Адаптация непрерывной интеграции и непрерывной доставки для машинного обучения Эль О'Брайен представляет DVC, инструмент с открытым исходным кодом, расширяющий возможности CI / CD с разработка программного обеспечения для машинного обучения. В целом, вот 3 наиболее значительных преимущества, которые DVC может дать рабочему процессу машинного обучения:

  1. Он предоставляет обратную связь в виде отчетов о показателях. Когда вы делаете запрос на перенос, вы получаете отчет, который по своей сути является настраиваемым документом уценки.
  2. Он поддерживает версии данных как код. DVC расширяет возможности управления версиями Git на наборы данных и модели с помощью GitHub Actions.
  3. Это позволяет системе CI выделять облачные ресурсы для обучения моделей. Вы никогда не забудете снова выключить облачный графический процессор!

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

Если вы хотите следить за моей работой в области систем рекомендаций, глубокого обучения, MLOps и журналистики в области науки о данных, вы можете ознакомиться с моими Medium и GitHub, а также другими проектами на Https://jameskle.com/. Вы также можете написать мне в Твиттере, написать мне по электронной почте или найти меня в LinkedIn. Или присоединяйтесь к моей рассылке, чтобы получать мои последние мысли прямо на ваш почтовый ящик!