Уроки из создания платформы ML в Mailchimp

Мастер-класс по созданию платформы ML в Mailchimp

Эта статья изначально была эпизодом ML Platform Podcast, шоу, в котором Пётр Недвежывж и Ауримас Гричюнас вместе с профессионалами ML-платформы обсуждают проектирование, лучшие практики, примеры стеков инструментов и практический опыт от лучших профессионалов ML-платформы.

В этом эпизоде Микико Бейзли делитесь своими знаниями от построения ML-платформы в Mailchimp.

Вы можете посмотреть его на YouTube:

Или послушать в виде подкаста:

Но если вы предпочитаете письменную версию, вот она!

В этом эпизоде вы узнаете о:

1 ML-платформе в Mailchimp и использовании генеративного искусственного интеллекта
2 Проблемах генеративного искусственного интеллекта в Mailchimp и мониторинге обратной связи
3 Приближении к бизнесу в роли инженера MLOps
4 Успешных историях возможностей ML-платформы в Mailchimp
5 Золотых путях в Mailchimp

Кто такая Микико Бейзли

Ауримас: Привет всем и добро пожаловать в подкаст Machine Learning Platform. Сегодня я ведущий, Ауримас, и со мной есть со-ведущий Пётр Недвежывж, сооснователь и исполнительный директор neptune.ai.

Сегодня в гостях у нас Микико Бейзли. Микико – очень известная фигура в сообществе данных. В настоящее время она является руководителем MLOps в FeatureForm, виртуальном хранилище признаков. Ранее она занималась разработкой платформ машинного обучения в MailChimp.

Рады видеть тебя здесь, Мики. Расскажи нам что-нибудь о себе?

Микико Бейзли: Ваши детали абсолютно верные. Я присоединилась к FeatureForm в октябре прошлого года, а до этого я работала над платформой машинного обучения в Mailchimp. Я была там до и после огромного поглощения на 14 миллиардов долларов компанией Intuit – так что я была там во время передачи. Довольно интересно, иногда хаотично.

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

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

Как перейти от аналитики данных к инженерии MLOps

Пётр: Мики, вы были ученым-исследователем данных, верно? А позже, инженер MLOps. Я знаю, что вы не являетесь поклонником титулов; вы предпочитаете говорить о том, что вы действительно умеете делать. Но могу сказать, что то, чем вы занимаетесь, не является обычным сочетанием.

Как вам удалось перейти от аналитической, научной роли к более инженерной?

Микико Бейзли: Большинство людей действительно удивляется, когда узнают, что моим учебным фоном в университете не была информатика. Я начала изучать Python примерно за год до того, как перешла на роль ученого-исследователя данных.

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

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

На тот момент у меня не было навыков программирования.

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

Мой первый поворот был в область операций по росту и хакинга продаж – в то время это называлось ростовым хакингом в Силиконовой долине. И потом я разработал схему, как делать эти переходы. Таким образом, я смог перейти от ростового хакинга к аналитике данных, затем от аналитики данных к науке о данных, а затем от науки о данных к MLOps.

Я думаю, ключевыми элементами для перехода от науки о данных к инженеру MLOps были:

Иметь искреннее желание решать и работать над теми видами проблем, которые я хочу решать. Вот как всегда ориентировался на свою карьеру я – «Над чем я хочу работать сегодня?» и «Думаю ли я, что это будет интересно через год или два?»

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

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

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

Я из Польши и помню, когда у меня появилось предложение от Google стать обычным инженером-программистом. Ежемесячная зарплата была больше, чем я тратил в год. В два или три раза больше.

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

Я всегда задаю себе такой вопрос, когда принимается решение: «Что случится, если через год это будет неудачей и я не буду счастлив? Могу ли я вернуться и выбрать другой вариант?» И обычно ответ: «да, можно».

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

Ресурсы, которые могут помочь преодолеть техническую пропасть

Aurimas: У меня также очень похожий опыт. Я перешел от аналитики к науке о данных, затем к машинному обучению, затем к инженерии данных, а затем к MLOps.

У меня это заняло немного больше времени, потому что между ними у меня была инженерия данных, облачная инженерия и инженерия DevOps.

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

Mikiko Bazeley: Да, конечно. Это была часть работы в стартапе в области недвижимости на начальном этапе. Я огромный поклонник буткемпов. Когда я окончила колледж, у меня был очень низкий GPA – очень, очень низкий.

Я не знаю, как оценивают оценки в Европе, но, например, в США обычно используется система оценки от 0 до 4, и у меня было 2.4, что по большинству американских стандартов считается очень плохо. Так что у меня не было возможности поступить в аспирантуру или магистратуру.

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

У меня были люди уровня C, которые говорили: «Эй, мы напишем вам письма, чтобы вас приняли в аспирантуру».

И программы выпускников были как: “Извините, нет! Вам нужно вернуться в колледж, чтобы пересдать GPA”. А я такой: “Мне уже за 20. Знания дорогие, я не собираюсь это делать”.

Поэтому я большой поклонник буткемпов.

То, что помогло мне как в переходе к роли data scientist, так и в роли MLOps engineer, было сочетание буткемпов. Когда я переходил к роли MLOps engineer, я также проходил эту известную сессию под названием Full Stack Deep Learning. Его ведут Димитрий и Джош Тобин, которые ушли, чтобы создать Gantry. Мне очень понравилось.

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

То, что помогло мне в обоих этих переходах, – это настоящее вложение в мои наставнические отношения. Например, когда я впервые переключился с аналитики данных на data science, моим наставником в то время был Раджив Шах, который сейчас является пропагандистом разработчика в Hugging Face.

Я был наставником на буткемпах с тех пор – на нескольких из них. Часто студенты обращаются ко мне с просьбой “Оцени мой проект, каков был мой код?”

И это не может полноценно использовать потенциал промышленного наставника, особенно если у него есть такие достижения, как у Раджива Шаха.

Обучаясь на курсе Full Stack Deep Learning, там были некоторые прекрасные ассистенты. Я показывал им мой проект для оценки. Но, например, переходя в роль data scientist, я спросил у Раджива Шаха следующее:

Как реализовать интерпретируемость модели, если маркетинговый директор требует от меня создать прогноз и предсказать результаты?
Как запустить эту модель в производство?
Как получить поддержку для этих проектов в области data science?
Как использовать свои сильные стороны?

И я сочетал это с развитием технических навыков, которые разрабатывал.

Я сделал то же самое в роли специалиста по ML-платформе. Я задал следующие вопросы:

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

Думаю, я развивал свои навыки благодаря сочетанию разных вещей.

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

Поиск наставников в буткемпах

Piotr: Когда вы упомянули наставников, вы находили их во время буткемпов или у вас были другие способы? Как это работает?

Mikiko Bazeley: В большинстве буткемпов это сводится к выбору правильного. В моем случае,

, я выбрала Springboard для перехода в data science, а затем немного воспользовалась их услугами для перехода в роль MLOps, но больше полагалась на курс Full Stack Deep Learning – и сильно уделяла внимание самостоятельному изучению и работе.

Я не закончила курс Springboard для MLOps, потому что к тому моменту я уже получила несколько предложений о работе от четырех или пяти разных компаний на роль инженера MLOps.

Поиск работы после буткемпа и присутствие в социальных сетях

Piotr: И это было из-за буткемпа? Ведь вы сказали, что многие люди используют буткемпы для поиска работы. Как это сработало в вашем случае?

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

Я точно не считаю себя инфлюенсером. Во-первых, у меня нет такой аудитории. Я стараюсь делать то же самое, что делают многие участники этого подкаста, – попытаться поделиться своими знаниями с людьми. Я пытаюсь взять свой опыт и представить его так: “Хорошо, да, такие вещи могут происходить, но вот как с ними можно справиться”.

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

Вы видите их постоянно с таким заголовком: “наука о данных, машинное обучение, Java, Python, SQL или блокчейн, компьютерное зрение.”

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

Но, что еще важнее, они на самом деле не делают самого важного, что можно сделать с социальными сетями – нужно общаться с людьми. Нужно делиться с людьми. Нужно делиться своими знаниями.

Так я делал, когда проходил боевые сборы. Как только я узнавал что-то новое и работал над проектами, я объединял это с моими опытами и просто делился этим публично.

Я попытался быть действительно – я не хочу сказать “аутентичным”, это немного избитый термин – но есть такое выражение: “Интересные люди интересуются”. Вы должны быть заинтересованы в проблемах, людях и решениях вокруг вас. Люди могут связаться с вами по этому поводу. Если вы притворяетесь, как многие делают в Chat GPT и Gen AI – притворяетесь без существа – люди не могут подключиться.

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

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

Микико Бейзли: Синдром самозванца.

Пётр: Да. Мне нужно от него избавиться.

Микико Бейзли: Ауримас, ты чувствуешь, что ты когда-то избавился от синдрома самозванца?

Ауримас: Нет, никогда.

Микико Бейзли: Я то же самое. Я просто нахожу способы обойти это.

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

Микико Бейзли: Это почти как сражение с вашими худшими качествами. Все ваши неуверенности – вам просто нужно обмануть себя как с хорошей диетой и тренировками.

Что такое FeatureForm и разные типы других хранилищ функций

Ауримас: Давайте поговорим немного о вашей текущей работе, Мики. Вы являетесь руководителем MLOps в FeatureForm. Однажды мне посчастливилось поговорить с генеральным директором FeatureForm, и он оставил у меня хорошее впечатление о продукте.

Что такое FeatureForm? Чем FeatureForm отличается от других участников рынка хранилищ функций сегодня?

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

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

Три типа:

1 Неявное,
2 Физическое,
3 Виртуальное.

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

Например, Feast. Feast – это буквальное хранилище функций. Оно очень легковесное решение, которое можно легко реализовать, что означает низкий риск реализации. Фактически никаких преобразований, оркестрации или вычислений не происходит.

Пётр: Мики, если можно, почему он легковесный? Я понимаю, что буквальное хранилище функций хранит функции. В некотором смысле оно заменяет ваше хранилище, верно?

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

У физического хранилища функций есть все:

Оно хранит функции,
Оно обслуживает функции,
Оно оркестрирует функции,
Оно выполняет преобразования.

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

Пётр: И на спектре, физическое хранилище функций – самое тяжелое?

И в случае буквального хранилища функций, преобразования реализуются где-то еще и затем сохраняются?

Микико Бейзли: Да.

Ауримас: И само хранилище функций – это просто библиотека, которая в основном выполняет действия над хранилищем? Верно?

Микико Бейзли: Да, это почти деталь реализации. Но да, в основном так. Feast, например, является библиотекой. Она поставляется с разными поставщиками, поэтому у вас есть выбор.

Ауримас: Вы можете настроить его на работу с S3, DynamoDB или Redis, например. Тяжесть, я думаю, заключается в том, что это всего лишь тонкая библиотека поверх этого хранилища, и вы сами управляете хранилищем.

Микико Бейзли: Именно так.

Пётр: Так что здесь нет бэкэнда? Нет компонента, хранящего метаданные об этом хранилище функций?

Микико Бейзли: В случае буквального хранилища функций оно просто хранит функции и метаданные. Оно фактически не выполняет никаких сложных преобразований или оркестрации.

Пётр: Итак, что такое виртуальное хранилище функций? Физическое хранилище функций понятно, но мне интересно, что представляет собой виртуальное хранилище функций.

Микико Бейзли: Да, виртуальное хранилище функций пытается взять лучшее из обоих миров.

У разных типов хранилищ функций есть свои использования. Физические хранилища функций возникли у компаний, таких как Uber, Twitter, Airbnb и других. Они решали действительно сложные задачи по обработке огромных объемов данных в потоковом режиме.

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

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

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

Например, FeatureForm делает это потому, что мы являемся нативными для Kubernetes. Мы предполагаем, что большинство специалистов по обработке данных не хотят писать преобразования в другом месте. Мы предполагаем, что они хотят делать то, что обычно делают с помощью Python, SQL и PySpark, с использованием data frames.

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

Идея в том, что у вас есть новый ученый-исследователь данных, который присоединяется к команде…

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

Вы собираете данные. Оказывается, запросы сломаны, и вы думаете: “Что они думали?”.

Затем к вам приходит руководитель и говорит: “О да, кстати, числа неверные. Вы дали мне эти цифры, и они изменились”. И вы говорите: “О блин! Теперь мне нужна прослеживаемость. Боже, мне нужно отслеживать”.

Часть, которая действительно причиняет много проблем предприятиям сейчас, – это регулирование. Любая компания, занимающаяся бизнесом в Европе, должна соблюдать GDPR, это большая проблема. Но многие медицинские компании в США, например, подпадают под HIPAA, которая предназначена для медицинских и здравоохранения компаний. Поэтому для многих из них юристы активно участвуют в процессе машинного обучения. Большинство людей не осознают этого.

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

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

Виртуальное хранилище функций в контексте более широкой архитектуры

Петр: Так, Мики, когда мы смотрим на это с двух точек зрения. С точки зрения администратора. Допустим, мы собираемся развернуть виртуальное хранилище функций как часть нашего технического стека, мне нужно иметь хранение, такое как S3 или BigQuery. Мне нужно иметь инфраструктуру для выполнения вычислений. Это может быть кластер, управляемый Kubernetes, или что-то еще. А затем, виртуальное хранилище функций является абстракцией над хранилищем и вычислительным компонентом.

Микико Безли: Да, мы фактически провели доклад на Data Council. Мы опубликовали то, что мы называем “картой рынка”, но это не совсем верно. Мы опубликовали диаграмму того, как мы считаем, что должна выглядеть архитектура стека машинного обучения.

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

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

Под этим можно также иметь Kubernetes, верно? Потому что это также может управлять оркестровкой всей компании. Итак, виртуальное хранилище функций находится выше вашего Spark, Inray и вашего Databricks, например.

Теперь, выше этого, и мы это наблюдаем сейчас среди, например, среднего размера пространства, есть много людей, которые публикуют удивительные описания своих ML-систем. Например, Shopify опубликовал блог-пост о Merlin. Есть еще несколько других компаний, я думаю, DoorDash также опубликовал некоторую очень хорошую информацию.

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

Виртуальные хранилища функций с точки зрения конечного пользователя

Петр: Все это было с архитектурной точки зрения. А что насчет точки зрения конечного пользователя? Предполагаю, что по крайней мере одним из пользователей хранилища функций будет дата-ученый. Как дата-ученый будет взаимодействовать с виртуальным хранилищем функций?

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

Что-то, что я узнал, когда работал в Mailchimp у ведущего инженера нашей команды, это предполагать положительные намерения, что, на мой взгляд, прекрасный принцип руководства. Я думаю, что очень часто возникает какое-то странное противостояние между инженерами по ML/MLOps, программистами и дата-учеными, где говорят: “О, дата-ученые просто ужасны в программировании. Они ужасные люди. Как они ужасны?”

В то же время дата-ученые смотрят на инженеров DevOps или платформенных инженеров и говорят: «Почему вы постоянно создаете очень плохие абстракции и утечки API, которые усложняют нашу работу?» Большинству дата-ученых не интересна инфраструктура.

И если им интересна инфраструктура, то они просто являются инженерами MLOps в обучении. Они на пути к новому путешествию.

Каждый инженер MLOps может рассказать историю стиля «О Боже, я пытался отлаживать или устранять неполадки в конвейере», или «О Боже, у меня был блокнот Jupyter или представленная модель, и в моей компании не было инфраструктуры для развертывания». Я думаю, что это история происхождения каждого инженера MLOps с плащом.

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

Но все, что им нужно сделать, это получить информацию о учетных данных, поместить ее в файл конфигурации. На этом этапе мы используем термин “регистрация” в FeatureForm, но по сути это в основном делается с помощью декораторов. Им просто необходимо пометить вещи вроде “Привет, кстати, мы используем эти источники данных. Мы создаем эти функции. Мы создаем эти обучающие наборы данных.” Поскольку мы предлагаем версионность и говорим о том, что функции – это элемент или сущность первого класса, им также предоставляется номер версии, и им никогда не придется беспокоиться о перезаписи функций или наличии функций с одинаковыми именами.

Предположим, что у вас работают два дата-ученых над одной задачей.

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

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

Версионность набора данных и функций

Петр: Мики, вопрос, потому что вы использовали термин “декоратор”. Единственный декоратор, который приходит мне в голову, это декоратор Python. Разве мы говорим о Python здесь?

Микико Бейзли: Да!

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

Mikiko Bazeley: Да!

Piotr: Так что связывает версионные функции? Как можно представить набор данных?

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

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

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

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

Будете ли вы делать это так или есть еще какие-нибудь способы подхода к этому?

Mikiko Bazeley: Позвольте мне повторить ваш вопрос:

В основном, вы спрашиваете, можем ли мы воспроизвести точные результаты? И как мы это делаем?

Aurimas: Для обучения, да.

Mikiko Bazeley: Хорошо. Это возвращается к заявлению, которое я сделал ранее. Мы не версионируем набор данных или ввод данных. Мы версионируем преобразования. Что касается самой логики, люди могут регистрировать индивидуальные функции, но они также могут объединять эти функции с меткой.

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

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

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

Что касается идентификатора сущности: Мы получаем идентификатор сущности, например, от команды фронтенда в виде вызова API. Пока идентификатор сущности совпадает с версией функции или функций, которые они запрашивают, они должны получить тот же вывод.

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

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

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

Ценность хранилищ функций

Piotr: Подведем итог, вы согласны с тем, что хранилище функций вносит вклад в технологическую структуру команды машинного обучения, обеспечивая версионирование логики инжиниринга функций?

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

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

Микико Бейзли: Я бы сказала, что три или четыре основных аспекта предложения cтоит отметить, это, безусловно, версионирование логики. Вторая часть – это документация, и она играет огромную роль. Думаю, у всех был опыт, когда они смотрят на проект и не понимают, почему кто-то выбрал такую логику. Например, логика представления клиента или контрактной стоимости в воронке продаж.

Итак, версионирование, документация, преобразование и оркестрация. Мы говорим “запиши один раз, выполни дважды”. Мы предлагаем такую гарантию. И, кроме аспекта оркестрации, есть также такие вещи, как планирование. Но это три основных аспекта:

Версионирование,
Документация,
Минимизация искажений в процессе обучения путем трансформации.

Это три основных момента, о которых нас часто спрашивают.

Документация функций в FeatureForm

Петр: Как работает документация?

Микико Бейзли: Существуют два типа документации. Есть некая случайная документация, но также есть документация через код и вспомогательная документация.

Например, вспомогательная документация – это, например, строки документирования. Вы можете объяснить: “Это логика функции, это означают термины, и т. д.”. Мы предлагаем это.

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

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

Платформа машинного обучения в Mailchimp и примеры использования генеративного искусственного интеллекта

Ауримас: Прежде чем стать руководителем MLOps в FeatureForm, вы были инженером по операционной работе с машинным обучением в Mailchimp, и вы помогали строить платформу МО там, верно? С какими проблемами сталкивались ученые-исследователи и инженеры по машинному обучению в Mailchimp?

Микико Бейзли: Было несколько вещей. Когда я присоединилась к Mailchimp, там уже была команда платформы. Это была очень интересная ситуация, когда вопросы MLOps и ML Platform были разделены между тремя командами.

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

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

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

Aurimas: Это был контент-генератор?

Mikiko Bazeley: О да, конечно. Это полезно понять, для чего предназначен Mailchimp, для дополнительного контекста.

Mailchimp – компания старше 20 лет. Она базируется в Атланте, штат Джорджия. Одной из причин, почему ее выкупили за такие большие деньги, является то, что она также является самым… Я не хочу сказать поставщиком. У них самый крупный список электронной почты в США, потому что они начинали как решение по электронному маркетингу. Но то, о чем большинство людей, я думаю, не осознают, это то, что в последние несколько лет они делают крупные шаги, чтобы стать своего рода всё в одном магазином для малого бизнеса и бизнеса среднего размера, которые хотят заниматься электронной торговлей.

Все еще есть электронный маркетинг. Это огромная часть их деятельности, поэтому NLP там очень важна, очевидно. Но они также предлагают такие вещи, как создание контента для социальных сетей, виртуальные цифровые веб-сайты для электронной коммерции и т.д. Они по сути пытались расположить себя как передний ряд CRM для малых и средних предприятий. Их купили Intuit, чтобы они стали передней частью операций Intuit внутри предприятия, таких как QuickBooks и TurboTax.

В этом контексте цель Mailchimp – предоставить маркетинговые инструменты. Другими словами, все то, что малым единоличным предприятиям нужно делать. Mailchimp стремится упростить и автоматизировать это.

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

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

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

Тогда Лесли говорит: “Хорошо, теперь дайте мне несколько шаблонов

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

Затем Лесли говорит: “Хорошо, теперь дайте мне некоторые шаблоны, напишите мое праздничное письмо, но с моим брендом в виду”, то есть со своим тоном и стилем общения. Затем перечисляются другие детали о ее магазине. Затем, конечно же, будут сгенерированы тексты электронных писем. Затем Лесли говорит: “Хорошо, мне нужно несколько разных версий этого, чтобы я мог провести тестирование А/В”. И это будет сделано …

Причина, по которой я считаю, что это такой сильный деловой случай, заключается в том, что Mailchimp является крупнейшим поставщиком. Я намеренно не говорю поставщиком электронной почты, потому что они не предоставляют электронную почту, они –

Piotr: … отправитель?

Mikiko Bazeley: Да, они являются самым крупным безопасным бизнесом для электронной почты. Итак, у Лесли уже есть список адресов электронной почты, который она создала. У нее есть несколько вариантов. Ее список адресов электронной почты разделен – это также то, что Mailchimp предлагает. Mailchimp позволяет пользователям создавать кампании на основе определенных триггеров, которые они могут настроить по своему усмотрению. У них отличный пользовательский интерфейс для этого. Итак, у Лесли есть три списка адресов электронной почты. У нее есть высокорасходные, VoAGI, имеющие низкие расходы.

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

Для них способности генеративного искусственного интеллекта, которые они предлагают, прямо соответствуют их миссии. Но это не продукт. Продукт заключается в том, что мы “сделаем вашу жизнь очень простой для владельца малого или среднего бизнеса, который, возможно, уже имеет список из 10 000 адресов электронной почты и взаимодействует со своим веб-сайтом и магазином”. Теперь они также предлагают возможности сегментации и автоматизации – обычно для этого нужно обратиться к Zapier или другим поставщикам.

Я думаю, что Mailchimp просто выигрывает от новой волны. Я не могу сказать то же самое о многих других компаниях. Это было очень захватывающе для меня, как ML-инженера платформы, потому что это также рано показало мне некоторые проблемы работы не только с многомодельными ансамблями конвейеров, которые у нас точно были, но и с тестированием и проверкой генеративного ИИ или LLM.

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

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

Микико Бейзли: Но они персонализированы. Они персонализированы под вашу персону.

Связанный подкаст

Развертывание разговорных продуктов с искусственным интеллектом в производстве с Джейсоном Флаксом

Узнайте больше

Проблемы генеративного ИИ в Mailchimp и контроль обратной связи

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

Можешь ли ты рассказать нам, как это делалось в Mailchimp? Какова была это за обратная связь и что делали ваши команды? Как это работало?

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

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

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

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

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

Инженеры данных в организации по науке о данных и машинному обучению в основном занимались переносом данных и копированием данных из устаревшей системы в GCP, где мы находились. Набор программных инструментов для ученых по данным и машинному обучению на GCP включал BigQuery, Spanner, Dataflow и AI Platform Notebooks, который сейчас – Vertex. Мы также использовали Jenkins, Airflow, Terraform и другие инструменты.

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

На этом этапе было очень сложно делать что-либо. Мы могли создавать модели для живых сервисов – это был очень распространенный шаблон – но многие модели приходилось обучать в автономном режиме. Мы создали живой сервис из них, открыли API-интерфейс и всё такое. Но была задержка примерно в один-два дня.

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

Одна из обратных связей, которую получили, была о создании кампаний – то, что мы называем «строителем путешествий». Многие владельцы небольших и средних предприятий – это генеральные директоры, финансовые директоры, маркетинговые директоры – они делают всё сами. Они говорят: «На самом деле это сложно. Можете ли вы подсказать, как нам создавать кампании?» Это была обратная связь, которая пришла через продукт.

Ученый по данному проекту сказал: «Я собираюсь создать модель, которая даст рекомендации для следующих трех шагов или следующих трех действий, которые владелец может предпринять в своей кампании». Затем мы все работали с инженерами по данным и говорили: «А можно ли получить эти данные?»

Тут снова вступает в игру юридическое лицо и говорит: «Есть ли какие-либо юридические ограничения?» А затем по существу включают эти данные в наборы данных, которые могут использоваться в моделях.

Piotr: Эта обратная связь не является данными, но скорее качественной обратной связью относительно потребностей пользователей, так?

Mikiko Bazeley: Но я думаю, что нужно и то, и другое.

Aurimas: Вы правы.

Mikiko Bazeley: Я думаю, что необходимо иметь обратную связь данных, не обходя команды продукта и интерфейса пользователя. Например, очень распространенное место для получения обратной связи – это когда вы предлагаете рекомендацию, верно? Или, например, реклама в Twitter.

Вы можете спросить: «Является ли эта реклама для вас релевантной?» Да или нет. Это делает очень простым предложение такой опции в интерфейсе пользователя. И я думаю, что многие люди считают, что внедрение обратной связи данных очень просто. Когда я говорю «простое», я не означаю, что оно не требует твердого понимания дизайна эксперимента. Но предполагая, что у вас есть это, есть много инструментов, таких как A/B-тесты, предсказания и модели. Затем вы можете просто записать результаты в таблицу. Всё это на самом деле несложно. Но то, что часто сложно, это заставить различные инженерные команды принять это и быть готовыми настроить всё это.

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

Например, когда я был на Data Council на прошлой неделе, там была панель по генеративному искусственному интеллекту. Из этого обсуждения я понял, что скучные данные и инфраструктура машинного обучения имеют большое значение. Они имеют еще большее значение сейчас.

Многие из этих инфраструктур MLOps не исчезнут. На самом деле, они становятся важнее. Большим вопросом там было то, что у нас заканчиваются публичные корпусы данных для обучения и доводки. И под этим имеется в виду, что нам не хватает качественных академических наборов данных на английском языке для использования с нашими моделями. Поэтому люди говорят: “Что будет, если у нас закончатся наборы данных в Интернете?” И ответ заключается в использовании данных первой стороны – используя данные, которыми вы, как бизнес, фактически владеете и можете контролировать.

То же самое произошло, когда Google сказал: “Мы уберем возможность отслеживать данные третьих лиц”. Многие люди были в панике. Если вы создадите сбор обратной связи данных и согласуете его с усилиями по машинному обучению, вам не придется беспокоиться. Но если вы компания, которая сводится лишь к оберточке вокруг чего-то вроде API OpenAI, тогда вам следует беспокоиться, потому что вы не предлагаете ценности, которую никто другой не может предложить.

То же самое с инфраструктурой машинного обучения, верно?

Приближение к бизнесу как инженер MLOps

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

Микико Бейсли: Да, на 100%. И на самом деле здесь я думаю MLOps и инженеры по данным слишком много думают как инженеры…

Пиотр: Можете это подробнее объяснить?

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

Я думаю, многие инженеры по данным и инженеры MLOps не справляются с этим. Я думаю, ученые по данным зачастую делают это лучше.

Пиотр: Потому что им чаще приходится работать с бизнесом, верно?

Микико Бейсли: Да!

Ауримас: И разработчики не непосредственно приносят ценность…

Микико Бейсли: Это похоже на общественное здравоохранение, верно? Все недооценивают общественное здоровье, пока не оказываются перед проблемами, связанными с загрязнением воды. Это очень важно, но люди не всегда показывают насколько. Более того, они подходят к этому с точки зрения “это лучшее техническое решение”, а не “это принесет огромную ценность компании”. Компании действительно интересуют только две-три вещи:

1 Генерирование большего дохода или прибыли
2 Снижение затрат или их оптимизация
3 Комбинация первых двух вариантов.

Если инженеры MLOps и инженеры по данным смогут объединить свои усилия, особенно в создании стека инструментов для машинного обучения, бизнес-человек или даже руководитель инженерии задумается: “Зачем нам нужен этот инструмент? Это просто еще одна вещь, которую люди здесь не будут использовать”.

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

Что я заметила у экстремально успешных команд разработчиков платформы для ML – это обратное тому, о чем говорят истории. Многие истории о создании платформ для машинного обучения звучат так: “Мы создали новую вещь, затем привлекли этот инструмент для ее использования. И тогда люди просто начали его использовать и полюбили”. Это просто другая версия “если построите, они придут”, и это не так происходит.

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

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

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

Если вы идете к бизнес-лицу или своему генеральному директору и говорите: “У нас уже есть 100 ученых по данным, которые пытаются разрабатывать модели. Сколько времени это занимает. Мы можем сократить это время вдвое и сделать это таким образом, чтобы они были счастливы и не увольнялись. И это принесет еще больше ценности, потому что это инициативы, которые мы хотим продвигать. Нам потребуется около шести месяцев, чтобы сделать это, но мы можем убедиться, что мы сможем сократить сроки до трех месяцев”. Тогда вы можете показать эти показатели и измерения, а также предложить план обслуживания.

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

Успешные истории о возможностях платформы машинного обучения в Mailchimp

Ауримас: У вас есть какие-то успешные истории от Mailchimp? Какие практики вы бы порекомендовали в общении с командами машинного обучения? Как вы получаете от них обратную связь?

Микико Бэйзли: Да, конечно. У нас было несколько успешных моментов. Начну с Autodesk для контекста.

Когда я работала в Autodesk, я занимала гибридную роль дата-сайентиста и аналитика данных. Autodesk – это компания ориентированная на дизайн. Они заставляют вас проходить множество курсов, таких как мышление дизайнера и о том, как собирать пользовательские истории. Я также изучала это во время своего обучения в области антропологии: как создавать то, что они называют этнографиями, то есть, “как выходить к людям, изучать их практики, понимать то, что им важно, говорить на их языке”.

Это было первым делом, которое я выполнила в команде. Я пришла туда и подумала: “Вау, у нас здесь столько тикетов в Jira. У нас есть так много вещей, над которыми можно работать.” Команда работала в разных направлениях, и я подумала: “Хорошо, прежде всего, давайте убедимся, что у нас есть единая базовая информация о том, что действительно важно”.

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

Одной из вещей, которую мы выяснили, было то, что использование шаблонов было немного запутанным. Более того, это произошло примерно в то время, когда вышел M1 Mac, который сломал некоторые вещи для Docker. Часть инструмента работы с шаблонами заключалась в создании Docker-образа и заполнении его конфигурациями, основываясь на типе связанного с ним проекта машинного обучения. Мы хотели избавиться от локальной разработки.

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

Вы могли создать шаблон в GCP, который затем можно было загрузить в GitHub, что вызывало запуск CI/CD-процесса, а затем запуск процесса развертывания. Это был проект, над которым я работала. И, похоже, он помог. Я работала над его первой версией, а затем другие люди взяли его и довели его до более совершенного состояния. Теперь, идеально, дата-сайентисты больше не должны заниматься этим странным процессом перемещения кода из удаленного репозитория на локальную машину во время разработки.

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

Книга, которую я недавно читала и которая мне очень понравилась, называется “Kill It With Fire” Марианны Беллотти. Она рассказывает о том, как обновлять устаревшие системы, как модернизировать их, не выбрасывая их. Это была большая часть моей работы в Mailchimp.

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

Например, в Mailchimp мы не могли использовать GitHub Actions. Было бы здорово, но у нас не было такой возможности. У нас был существующий инструмент работы с шаблонами и процесс, который уже использовали данные ученые. Он существовал, но был не оптимальным. Каким образом мы могли бы оптимизировать предложение так, чтобы они были готовы его использовать? Я много узнала из этого, но темп работы в предприятии намного медленнее, чем вы могли бы сделать это в стартапе или даже как консультант. Так что вот один недостаток. Часто число проектов, над которыми можно работать, составляет примерно треть от того, что вы могли бы сделать где-то ещё, но это было очень увлекательно.

Связанный пост

Создание платформы машинного обучения [Окончательное руководство]

Структура команды в Mailchimp

Ауримас: Меня очень интересует, использовали ли у вас data scientist’ы вашу платформу непосредственно или также привлекались инженеры машинного обучения в какой-то степени, возможно, встроенные в команды продукта?

Микико Бейзли: На этот вопрос можно дать два ответа. В Mailchimp царила культура дизайна и инженерии. Многие data scientist’ы, которые работали там, особенно самые успешные, имели опыт в качестве разработчиков программного обеспечения. Даже если процесс был немного сложным, часто они находили способы с ним справиться.

Но за последние два-три года Mailchimp начал привлекать data scientist’ов, которые больше были ориентированы на продукт и бизнес. У них не было опыта в разработке программного обеспечения. Это означало, что им нужна была некоторая помощь. Поэтому каждая команда, которая принимала участие в MLOps или инициативах по созданию платформы машинного обучения, имела то, что мы называли “встроенными инженерами MLOps”.

Они были что-то вроде ML-инженеров, но не совсем. Например, они не создавали модели для data scientist’ов. Они в буквальном смысле только помогали в последнем этапе перехода к производству. Обычно я представляю ML-инженера как полноценного data scientist’а-разработчика. Это означает, что они разрабатывают функции и модели. У нас были люди, которые просто помогали data scientist’ам пройти процесс, но не создавали модели.

Наши основные пользователи были data scientist’ы, и только они. У нас были люди, которые помогали им с вопросами, вопросами в Slack и помогали определить приоритеты ошибок. Затем это передавалось инженерам, которые работали над ними. У каждой команды было такое сочетание людей, которые fокусировались на разработке новых функций и инструментов и людей, которые тратили около 50% своего времени на помощь data scientist’ам.

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

Пётр: Так что у вас не было централизованной команды платформы машинного обучения?

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

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

Микико Бейзли: Да, да.

Пётр: Делали ли вы общую технологическую базу и процессы, или каждая команда data scientist’ов и специалистов поддержки имела свою собственную область, свой набор инструментов, свои процессы. Или у вас были инициативы, например, вы упомянули использование шаблонов между командами.

Микико Бейзли: Большая часть стека была общей. Я думаю, что способ описания команд в организациях, предложенный топологией команд, действительно фантастичен. Это замечательный способ описания. Потому что было четыре команды, верно? Это сгруппированные команды, в данном случае – команды data science и продукта. У нас были сложные подсистемные команды, такие как команда Terraform или Kubernetes, например. А также команды поддержки и платформы.

Каждая команда была комбинацией платформы и поддержки. Например, ресурсы, которыми мы делились, были BigQuery, Spanner и Airflow. Но различие в том, и я думаю, что это то, чего многим командам платформы на самом деле не хватает: цель команды платформы не всегда заключается во владении конкретным инструментом или слоем стека. Очень часто, если вы настолько большие, что у вас есть такие специализации, цель команды платформы – собрать не только имеющийся инструмент, но иногда и новые инструменты в единый опыт для вашего конечного пользователя – в нашем случае для data scientist’ов. Хотя у нас были общие BigQuery, Airflow и все эти великолепные инструменты, их также использовали другие команды. Однако они могли не быть заинтересованы, например, в развертывании моделей машинного обучения в производстве. Возможно, они вообще не были вовлечены в этот аспект.

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

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

Клиентская часть службы была тонким Python-клиентом, который принимал контейнеры Docker или образы, используемые для моделей. Затем она отображалась на конечной точке API, чтобы команды впереди могли направлять любые запросы для получения предсказаний от моделей.

Стек пайплайна

Петр: Использовали ли вы какие-либо инструменты для пайплайна? Например, чтобы обеспечить автоматическую или полуавтоматическую переобучение моделей. Или ученые-исследователи просто обучали модель, упаковывали ее в Docker-образ и затем закрывали?

Микико Бейзли: У нас были проекты в различных стадиях автоматизации. Airflow был большим инструментом, который мы использовали. Это был инструмент, который все в компании использовали во всех проектах. Взаимодействие с Airflow происходило следующим образом: часто приходилось создавать свой DAG и настраивать его. Однако это тоже можно автоматизировать, особенно если это просто запуск того же типа пайплайна машинного обучения, который был встроен в cookiecutter-шаблон. Мы говорили: «Когда вы создаете свой проект, вы проходите через серию интервью. Вам нужен Airflow? Да или нет?» Если они сказали «да», то соответствующая часть была заполнена для них информацией о проекте и всей остальной информацией. Затем автоматически подставлялись учетные данные.

Петр: Как они знали, нужно ли им это или нет?

Микико Бейзли: Это на самом деле было частью работы по оптимизации cookiecutter-шаблона. Когда я только пришла сюда, ученым-исследователям приходилось заполнять много таких вопросов. Мне нужен Airflow? Мне нужно XYZ? И в большинстве случаев им приходилось спрашивать у инженеров поддержки: “Эй, что мне делать?”

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

Было неудобно, когда они создавали проект, а затем мы смотрели на него и говорили: “Нет, это не так. Вам на самом деле нужно сделать это”. Им приходилось перезапускать создание проекта. Одним из этапов оптимизации было то, что мы говорили: «Просто выберите шаблон, и мы заполним все конфигурации для вас». Большинство из них могли легко разобраться. Например, “Будет ли это пакетная задача предсказания, где мне просто нужно скопировать значения? Будет ли это модель для работы в реальном времени?” Эти два шаблона для них были довольно простыми, чтобы они смогли сказать: “Это то, что я хочу”. Они могли просто использовать образ, предназначенный для конкретной задачи.

Процесс создания шаблона запускался, а затем они могли его заполнить: “Ах, это имя проекта, и так далее…” Они не должны были указывать версию Python. Мы автоматически устанавливали самую стабильную и актуальную версию, но если им была нужна версия 3.2, а последняя версия Python была 3.11, они могли указать ее. Кроме этого, в идеале они должны были выполнять свою работу по созданию функций и разработке моделей.

Еще одним интересным моментом было то, что мы изучали возможность предоставления им поддержки для Streamlit. Также это была часть того процесса. Ученые-исследователи создавали первоначальные модели. А затем они создавали панель управления Streamlit. Они показывали ее команде продукта, и затем команда продукта использовала ее для принятия решений «да» или «нет», чтобы ученые-исследователи могли продолжить проект.

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

Ауримас: Это звучит как среда UAT, верно? Пользовательские проверки на предпроизводстве.

Пётр: Может, больше похоже на “технический стек по требованию”? Как будто вы указываете, какой у вас проект, и вы получаете стек технологий и настройку. Пример того, как выполнялись похожие проекты с таким же настроем.

Микико Бейзли: Да, это похоже на то, что должно быть для ученых-исследователей данных, верно?

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

Размер организации машинного обучения в Mailchimp

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

Пётр: Какая была у этой команды? И сколько моделей машинного обучения у вас было?

Микико Бейзли: Команда по науке о данных состояла из примерно 20-25 человек, я думаю. Что касается инженерной стороны, у нас было шесть человек в моей команде, может быть также шесть человек в команде обслуживания, и еще шесть человек в команде интеграции данных и мониторинга. И затем у нас была еще одна команда, которая была командой платформы данных. Их очень тесно связывали с тем, что вы бы подразумевали под инженерией данных, верно?

Они помогали поддерживать и осуществляли копирование данных с Mailchimp’s легаси стека в BigQuery и Spanner. У них было еще несколько задач, но это была основная. Также они обеспечивали доступность данных для аналитических случаев использования.

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

Ауримас: Я правильно понимаю, что у вас было 18 человек в различных командах платформы для 25 ученых-исследователей данных? Вы сказали, что на каждой команде было по шести человек.

Микико Бейзли: Третья команда была распределена по нескольким проектам – мониторинг был самым последним из них. Они не присоединились к инициативам платформы машинного обучения до примерно трех месяцев до моего ухода из Mailchimp.

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

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

Пётр: Мики, ты помнишь, сколько моделей машинного обучения было у вас в продакшне, когда ты работала там?

Микико Бейзли: Я думаю, что минимум был от 25 до 30. Но они определенно создавали гораздо больше. И некоторые из этих моделей были ансамблевыми моделями, ансамблевыми конвейерами. Это было довольно значительное количество.

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

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

Пётр: Ты помнишь, сколько времени обычно занимало переход от идеи решения проблемы с помощью машинного обучения до наличия модели машинного обучения в продакшне? Каково было медианное или среднее время?

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

Петр: Проверка логики? Что бы это значило?

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

Петр: Я собирался спросить о ключевых факторах. Что заняло больше всего времени?

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

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

Другая часть, с которой мы столкнулись, – это стратегическая дорожная карта. Например, когда я пришел туда, разные люди работали над совершенно разными проектами, и иногда даже не было видно, какими были эти проекты. Иногда проект шел не столько о “насколько полезен он для ученых данных”, сколько о “хотел ли инженер этого проекта работать над ним?” или “Является ли это его личным проектом?” Было много таких случаев.

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

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

Петр: Это называется страсть *смеется*

Микико Бейзли: Это как-бы, “Подожди, почему сначала мы не создали внутренний период тестирования”. И потом, вы знаете, теперь мы должны помочь ученым данным, потому что они сталкиваются с проблемами, связанными с этими инструментами личных проектов.

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

Многие раз на это смотрели ученые данных и говорили: “Да, мы не будем использовать это, мы просто продолжим делать то, что мы делаем, потому что, даже если это неоптимально, оно хотя бы не сломано”.

Похожий пост

Роли в команде МО и как они сотрудничают друг с другом

Golden paths в Mailchimp

Ауримас: Был ли случай, когда что-то, созданное внутри команды, было настолько хорошо, что вам захотелось добавить это в платформу в качестве возможности?

Mikiko Bazeley: Это очень хороший вопрос. Я так не делаю. Я так не думаю, но часто ученые-аналитики, особенно те, кто занимает высокие позиции и отлично разбирается, пробуют различные инструменты, затем возвращаются в команду и говорят: “Это выглядит очень интересно”. Я думаю, вот как это примерно произошло, когда они изучали WhyLabs, например.

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

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

Золотой путь был лучше всего поддерживаемым. “Если у вас возникают проблемы с этим, это то, что мы поддерживаем, это то, что мы поддерживаем. Если у вас возникают проблемы с этим, мы дадим приоритет этой ошибке, мы ее исправим”. И это работало около 85% случаев использования, 85-90%.

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

Затем возникает вопрос: “где мы тратим инженерные ресурсы?”. Вот, например, проекты типа Creative Studio. Они очень инновационны, но их было очень сложно поддерживать. Но MailChimp сказал: “Мы должны это предложить, нам нужно использовать генеративный ИИ для оптимизации нашего продукта для пользователей”. Тогда возникает вопрос: “Сколько времени наших инженеров мы можем освободить для работы над этой системой?”

Даже тогда, с этими проектами, разница в необходимой инфраструктурной поддержке не так велика, как могло бы показаться. Я думаю, особенно с генеративным ИИ и LLM, где наибольшее влияние на инфраструктуру и эксплуатацию оказывает задержка, это очень важно. Второй аспект – защита данных, это действительно очень важно. А третий – это мониторинг и оценка. Но для большинства других вещей… Вниз по течению, все еще соответствует, например, системе рекомендации на основе NLP. Это не изменится значительно, пока у вас не будет правильных поставщиков, соответствующих потребностям.

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

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

Piotr: И это кажется ситуацией, когда вступает ваше образование!

Заключительные замечания

Aurimas: Мы уже на 19 минут вышли за пределы оговоренного времени. Поэтому, прежде чем закончить эпизод, может быть у вас есть мысли, которые вы хотите оставить нашим слушателям? Может быть, вы хотите сказать, где они могут найти вас в Интернете.

Mikiko Bazeley: Да, конечно. Люди могут найти меня на LinkedIn и Twitter. У меня есть Substack, который я немного запустила, но я собираюсь возродить его. Так что люди могут найти меня на Substack. У меня также есть канал на YouTube, который я также возрождаю, так что люди могут найти меня там.

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

Пиотр: Ты имеешь в виду модели фундамента?

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

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

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

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

Ауримас: Спасибо за ваши мысли и время, которое вы посвятили разговору с нами. Это было действительно потрясающе. И спасибо всем, кто слушал. Увидимся в следующей серии!

MLOps