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

Давайте попробуем нарисовать картину технологических трендов последних нескольких десятилетий.

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

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

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

В центре этой истории — профессия инженера.

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

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

То же самое относится и к машинному обучению.

Чтобы упростить (значительно), машинное обучение направлено на выделение полезных черных ящиков; черный ящик для предсказания кошек, еще один для выявления метастазов опухоли по рентгеновским снимкам, следующее слово в предложении, вероятность того, что вы нажмете на рекламу и т. д. Есть вход и выход; модель максимально точно определяет взаимосвязь между одним и другим. Придумать новый «черный ящик» или способы обучения «черного ящика» — вот суть многих исследований, проведенных в этой области.

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

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

Ну, не точно.

Выпейте пива с коллегами-инженерами по машинному обучению и спросите их: «Инженеры машинного обучения тратят свое время на разработку и обучение новых моделей, верно?». Если вы ничего не знаете, зайдите в Twitter и выполните быстрый поиск, вы поймете, что я имею в виду.

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

Но это не новость.

Лучшие данные приводят к лучшим моделям.

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

Так почему же мы все не приветствуем обработку данных, создание инструментов, которые делают нас смехотворно эффективными при выявлении режимов сбоев, создании соответствующих данных и сокращении цикла итерации данных?

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

Я тоже считаю, что особо винить некого.

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

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

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

  • Место хранения
  • Доступ и запросы
  • Воспроизводимое преобразование данных
  • Аннотация, курирование, краудсорсинг
  • Управление и управление версиями
  • Качество и анализ
  • Список можно продолжить.

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

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

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

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

Но я думаю, что мы можем добиться большего успеха.

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

  1. Чувство нехватки возможностей для моделирования и отставания в исследованиях;
  2. Готов искать любые признаки того, что система может извлечь выгоду из последней модели; (знаком с термином моделирование? Это заразная болезнь, которая заставляет вас хотеть попробовать новейший подход, прежде чем понять режимы сбоев и крайние случаи существующей системы.
  3. Слепой или не желающий заниматься низко висящими плодами, ориентированными на данные; (внутри вашей компании подсчитайте, сколько инженеров машинного обучения вызвались: «Эй, я просто проведу анализ, выясню, где модель дает сбой, пометит некоторые данные и повторит. Посмотрим, что произойдет, что может пойти не так?»)

Что мы можем сделать?

Что ж, если мы действительно серьезно относимся к тому, что 80 процентов работы инженера по машинному обучению связано с данными, единственный логический следующий шаг — делать то, что инженеры делают лучше всего: создавать лучшие инструменты и платформы!

Вы начинаете видеть, как эта идея проявляется в различных сквозных решениях (например, Ludwig.ai, Snorkel.ai). Мой опыт подсказывает мне, что мы не обязательно находимся на этапе, когда нестандартные решения обязательно являются недостающей частью.

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

Вот мои простые 5 шагов к (возможно) успеху:

  1. Определите, кто в вашей организации обладает знаниями о проблемной области и заинтересован в улучшении системы.
  2. Запишите все шаги, которые они в настоящее время должны предпринять, чтобы улучшить (хотя бы немного) систему, добавив 100 новых точек данных. Это может быть выявление ошибок, генерация данных, добавление в существующий пул, переобучение и т. д.
  3. Определите, какой шаг, вероятно, принесет наибольшую отдачу по любой метрике, релевантной для этой итерации (время, усилия, % точности и т. д.).
  4. Работайте с этим человеком, чтобы создать версию v1 чего-то, что поможет решить эту конкретную проблему.
  5. Используйте это обучение и повторите 2–5

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

  • Скорость итерации
  • Время развертывания
  • Время до новой функции
  • Стоимость сбора данных
  • Стоимость обслуживания данных

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

С нетерпением жду, чтобы увидеть, что вы строите!

Несколько вещей, которые стоит прочитать, если вы еще этого не сделали