Еще одно решение для мониторинга машинного обучения?

В сегодняшнем «Вторнике новых инструментов» есть что-то особенное. Мой старый босс и основатель сообщества MLOps Люк Марсден - соавтор.

На выходных я поговорил с Люком об этом инструменте и о том, почему они его создали. Однако, прежде чем мы поговорили об этом инструменте, первое, что он сказал мне, было Я видел ваш« пост на LinkedIn … да, извините за это» 😆

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

«У BasisAI есть продукт под названием Bedrock, который представляет собой платформу MLOps. В нем есть компонент мониторинга - чтобы создать бокскайт, мы извлекли код с проприетарной платформы и открыли его исходный код ».

Звучит немного как жульничество, продолжайте.

«Под капотом это простая библиотека Python, в которую вы передаете свои обучающие данные, обучающие метки, производственные данные и производственные метки, и она автоматически создает из них гистограммы Prometheus. Вы отправляете гистограмму времени обучения вместе с моделью и передаете ее обратно в компонент boxkite, который работает в производственной среде, затем boxkite знает, как сравнить гистограмму времени обучения с тем, что он видит в производственной среде, и предоставляет конечную точку Prometheus ».

Хорошо, хорошо. Но я все еще не уверен. Похоже, я могу просто сделать это с Прометеем и графаной. Зачем мне нужен бокскайт?

«Одной из самых сложных частей было выяснить, как показать разницу между распределениями в Гранфане - обычно для сравнения двух распределений используется метод, называемый дивергенцией Кульбака – Лейблера или, для краткости, дивергенцией KL. В Python существует множество реализаций дивергенции KL. Одна из действительно умных вещей, которые сделала команда BasisAI, - это перенести дивергенцию KL на Grafana.

Итак, на панели управления Grafana прячется очень странное выражение PromQL, которое показывает расхождение KL исключительно в Prometheus и Grafana.

Ни один из инструментов мониторинга машинного обучения, который мы видели, изначально не работал с Prometheus & Grafana. Мы не считаем, что вам следует использовать один стек для мониторинга машинного обучения, а другой - для мониторинга программного обеспечения. Между командами MLOps и DevOps должно быть объединение - и использование одних и тех же инструментов является ключевой частью разрушения этой стены ».

Интересный момент. MLOps и DevOps работают вместе в едином стеке.

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

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

Реквизиты команде BasisAI за то, что они сделали что-то действительно довольно сложное, кажутся довольно простыми ».

Люк установил демо, чтобы проверить это и надеть колеса, если вам так хочется. Ознакомьтесь с Boxkite.ml

Гипервекторы для гиперпространства

Интерфейс прикладного программирования

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

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

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

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

Инженеры любят проверять эквивалентность и согласованность - снова и снова с каждым постепенным изменением. Я помню, как меня спросили после того, как я предложил улучшить модель: «Откуда мы знаем, что она делает то, что делала раньше, а также немного лучше?». Мой ответ объяснял бы цикл поезд-тест-проверка, различные метрики выбора модели, которые мы использовали для принятия решения о выпуске улучшения, и я мог бы открыть блокнот Jupyter, чтобы показать некоторые графики (и, вероятно, помахал своим рук много).

Теперь я понимаю, что это не совсем так. Вопрос был больше похож на «Откуда МЫ (инженеры) знают, что он делает то, что делал раньше, плюс немного лучше?». Почему мы не можем запустить тест для каждой сборки этого проекта, чтобы убедиться, что даже кажущиеся несвязанными изменения каким-то образом не повредили небольшую, но важную часть выходных данных модели?

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

Hypervector пытается помочь в этой области, предоставляя набор инструментов, к которым вы можете получить доступ через Python (или REST, если хотите). Эти инструменты позволяют централизованно определять ресурсы тестирования для таких сценариев.

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

Мудрецы и святые

Sagify

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

Решение. Идея была проста, и некоторые даже смеялись над его наивностью. Обучать и развертывать модели, реализуя 2 функции на AWS? «Это кощунственно!» Они ответили и даже создали нестандартные смайлики, чтобы позвать его. Тем не менее Павлос упорствовал. Обучение () и прогноз (), обучение () и прогноз (), обучение () и прогноз (). Две функции - это все, что ему нужно.

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

Рождение Sagify: после бесчисленных бессонных ночей и бесчисленных поражений Павлос восстал как феникс из пепла с простым в использовании инструментом CLI MLOps в руке. Sagify предназначен для всех тех специалистов по обработке данных, которые чувствуют, что их голос не слышен. Для тех специалистов по данным, которые хотят сосредоточиться только на машинном обучении на 100%; просто обучение, настройка и развертывание моделей. Для тех, кто уже работает на AWS, рождается звезда, которая может использовать Sagemaker в качестве бэкэнд-движка машинного обучения, чтобы они могли работать умнее, а не усерднее.

Ознакомьтесь с Sagify здесь

* Это основано на реальных событиях, некоторые творческие вольности были взяты ради развлечения. :)

Дикембе Мутомбо

Одна заповедь

Я любитель хорошо названных продуктов. Когда @Miguel Jaques упомянул, что создал новый инструмент под названием Nimbo, я ничего не мог с собой поделать. Мне пришлось погрузиться глубже в это дополнение «Вторник с новыми инструментами».

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

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

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

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

Ребята решили работать исключительно на стороне клиента, что означает, что код работает на ваших экземплярах EC2, а данные хранятся в ваших корзинах S3.

«У нас нет сервера; вся оркестровка инфраструктуры происходит в пакете Nimbo ».

Принцип работы: Nimbo использует интерфейс командной строки и SDK AWS для автоматизации многих этапов выполнения заданий на AWS.

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

Вы можете использовать одну команду (nimbo pull results), чтобы перенести результаты на свой компьютер. Одна из самых неприятных частей работы с AWS - это управление и разрешения IAM. Мигель и Юозас решили автоматизировать и это, потому что никто не должен страдать из-за этого неохотно.

С нетерпением ждем: ребята планируют добавить поддержку докеров, развертывание с помощью одной команды и поддержку GCP. Кто знает, может быть, они даже поболтают с Павлосом и ребятами из Sagify, поскольку, похоже, они пытаются решить некоторые из тех же проблем.

Посмотрите Nimbo здесь

Лужи и пруды

Пропуск рок на K8S

Puntastic: Мой человек @Bogdan State из Новой Зеландии прошел через слабость сообщества и произвел настоящий фурор о своем новом инструменте Walden. Что это? Это должно быть «прудом данных», работающим на Kubernetes. Пруд данных? мы вернемся к этому через минуту. Этот выпуск нового инструмента во вторник должен был быть в информационном бюллетене на прошлой неделе, но в итоге я оказался полностью под водой, и мне пришлось отложить его до сих пор. В любом случае, я догнал самого киви, чтобы получить краткое изложение, он надеется, что этот инструмент может стать большой рыбой в… Право, я ничего не мог с собой поделать.

Предыстория: Богдан некоторое время стажировался в Facebook в 2013 году, когда впервые столкнулся с системой обработки данных под названием Presto / Trino. Из-за его невероятной скорости он стал широко полагаться на него как на специалиста по данным при обработке очень больших объемов табличных данных.

После того, как он начал свою собственную консалтинговую компанию по науке о данных, scie.nz, одним из первых пунктов бизнес-задачи было получение работающей установки Presto / Trino. Это оказалось больше работы, чем ожидалось, в частности, из-за требования, чтобы любая созданная ими установка работала на Kubernetes. После нескольких месяцев непрерывной разработки, чтения руководств и отладки кроличьих нор, его команда наконец получила рабочую установку, состоящую из Min.IO, Trino и Hive Metastore. Именно здесь г-н Стейт понял, что в процессе этого он построил небольшое озеро данных - пруд данных, если хотите.

Название: Так как этот тип развертывания предназначен для использования в небольшой команде, просто пытающейся начать работу с Presto / Trino, и не имеет отношения к таким корпоративным вещам, как разрешения и аудит, Богдан и его команда назвала его Уолденом. Это дань уважения американскому писателю Генри Дэвиду Торо, который превозносил самодостаточность, уединение и созерцание у пруда Уолден, на берегу которого он жил в одиночестве два года. Как оказалось, Торо получил некоторую помощь от своей матери, которая стирала его и приносила ему еду. Урок в том, что самодостаточность на бумаге выглядит легко и романтично, но создает множество непредвиденных проблем! В этом случае киви, тем не менее, считает, что создание собственного мини-озера данных может быть полезным (и недорогим) способом начать анализ больших данных, и надеется, что другие сочтут эту работу полезной и будут строить ее на этом!

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

Сообщество MLOps - это место, куда любой может прийти и получить представление о текущей экосистеме. Чтобы узнать больше, зайдите на Slack, youtube или подкасты и присоединитесь к беседе.