Системы машинного обучения

Перенос модели машинного обучения в реальный мир

Несколько с трудом заработанных уроков для практикующего

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

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

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

Строить или покупать?

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

Стоит ли тренировать свою собственную модель GPT-3?

Ну нет! GPT-3 - это модель со 175 миллиардами параметров, которая требует ресурсов, которые большинству компаний, помимо Google и Microsoft, будет сложно разработать. Поскольку OpenAI тестирует бета-версию своего API GPT-3, было бы разумнее попробовать ее и посмотреть, решает ли модель ваш вариант использования, а API масштабируется в соответствии с вашим вариантом использования.

Итак, покупать (больше похоже на аренду) или строить? Это зависит.

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

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

Разве этот вариант использования не является основной компетенцией? Достаточно ли общего для существующего / потенциального предложения AWS¹?

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

Доступны ли ресурсы помимо данных? Например, талант и инфраструктура?

По сути, создание и развертывание надежной системы машинного обучения по-прежнему в основном разрабатывается программным обеспечением, но с дополнительным поворотом: управлением данными. Если у команды нет опыта построения моделей в виде сервисных API со сбором, очисткой, маркировкой и хранением данных, то необходимое время может быть непомерно высоким, скажем, от 1 до 2 лет (или даже больше). Вместо этого развертывание стороннего решения может занять от 3 до 6 месяцев, поскольку в основном речь идет об интеграции решения в продукт. Владельцы бизнеса сочли бы такую ​​экономию времени и затрат чрезвычайно привлекательной.

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

Просто помни

Все, что имеет значение для владельца бизнеса, это: как результаты вашей модели будут полезны в контексте бизнеса?

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

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

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

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

Все начинается с истоков

Рассмотрим результаты поиска для пользователя, который искал фотографии щенков. Здесь у нас есть пример от Unsplash, один от Shutterstock и, наконец, один от EyeEm, на этот раз на мобильном устройстве.

Мы видим, что в то время как каждый пользовательский интерфейс (UI) отображает изображения в большом количестве. Предположим, мы хотим использовать щелчки по изображению для обучения модели, которая дает лучшие результаты поиска.

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

В примере Shutterstock вы сначала можете нарисовать щенка в правой части окна, но в примере EyeEm это может быть изображение в центре.

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

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

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

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

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

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

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

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

Сбор данных по-прежнему затруднен

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

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

Если есть что-то, что нужно помнить о данных, так это то, что

Данные - это побочный продукт измерения

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

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

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

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

Как недавно сказал мне бывший специалист по обработке данных Dropbox

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

Проверьте свои предположения о данных

Вот одна история, которую я испытал на собственном опыте из окопов.

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

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

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

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

Что случилось?

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

Излишне говорить, что мы ошибались в своем предположении.

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

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

Примеры других предположений, которые необходимо проверить:

  1. появление дрейфа концепций, при котором происходит значительный сдвиг в распределении данных (совсем недавний пример - вспышка COVID-19, искажающая модели прогнозирования),
  2. предсказательная сила функций , входящих в модель, поскольку предсказательная сила некоторых характеристик со временем снижается, и
  3. прекращение поддержки продукта, в результате чего функции исчезают.

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

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

Завершая все это

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

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

Мне еще есть что сказать по этой теме, но пока этого достаточно.

[1] Замените на своего любимого облачного провайдера.

[2] Торстен Иоахимс, Лаура Гранка, Бинг Пэн, Хелен Хембрук и Джери Гей, Точная интерпретация данных переходов по ссылкам как неявная обратная связь, In Proc. 28-й Ежегодной Международной конференции ACM SIGIR по исследованиям и разработкам в области информационного поиска (SIGIR), стр. 154–161 (2005).

[3] Исон Юэ, Раджан Патель и Хайн Рериг, За пределами предвзятости позиции: изучение привлекательности результата как источника предвзятости представления в данных по переходам, In Proc. 19-й Международной конференции по всемирной паутине (WWW), стр. 1011–1018 (2010).

[4] Сандип Тата, Александрин Попескул, Марк Наджорк, Майк Колагроссо, Джулиан Гиббонс, Алан Грин, Александр Ма, Майкл Смит, Диваншу Гарг, Кайден Мейер, Рубен Кан, Быстрый доступ: создание интеллектуального опыта для Google Диска, KDD '17: Материалы 23-й Международной конференции ACM SIGKDD по открытию знаний и интеллектуальному анализу данных, стр. 1643–1651 (2017)