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

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

Почему дизайн Zero-stack ML?

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

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

Фонды

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

80/20: при решении проблем мы знаем, что 20 % усилий обычно приносят 80 % ценности. Это также применимо к дизайну ML. Не сосредотачивайтесь на создании 100% идеального конвейера моделирования… это то, что называется низкоуровневой оптимизацией:прежде чем вкладывать значительные средства в оптимизацию вашей модели до степени детализации +-1% — что может быть действительно важно стоит сделать позже, в зависимости от вашей проблемы и вашего масштаба — вы хотите убедиться, что вы идете в правильном направлении (например: это правильная функция потерь для оптимизации?).

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

Время выхода на рынок. Время — деньги… и, хотите верьте, хотите нет, лучший способ проверить, работает ли продукт машинного обучения, — это… бросить его клиентам! Это называется соответствие продукта/рынка и… это также справедливо для продуктов машинного обучения! Вы должны сосредоточиться на создании минимально жизнеспособного продукта, который может продемонстрировать ценность для клиентов и представить его как можно быстрее. А потом? Повторить. В этом сила философии Agile (быстрые циклы итераций). Как правило, исследование реального мира реальными клиентами, скорее всего, является лучшим способом узнать, услуга машинного обучения двигает иглу (т. е. влияет на желаемые ключевые показатели эффективности бизнеса). … или нет. Также полезно узнать, как и где вы можете это улучшить (например, выявить сегмент клиентов, в котором ожидаемого эффекта не происходит).

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

Настройка и настройки. По моему опыту, команды разработчиков машинного обучения могут вести очень эзотерические споры при обсуждении дизайна нового сервиса машинного обучения: типы нейронных сетей, механизмы регуляризации, необходимость перехода на новые технологии (например: этот экстрактор действительно отстой и нуждается в рефакторинге; что нам действительно нужно, так это POC [случайная новая горячая технология XYZ]). Учтите, что это могут быть правильные точки зрения… но они часто упускают из виду общую картину. Почему? Потому что на данном этапе речь идет о разработке сквозной настройки для вашего решения… а не о конкретных настройках. Подходя к такой проблеме, предположим итерация по умолчанию:версию, которую вы запустите первой, нужно будет пересматривать снова, и снова, и снова. Когда вы впервые запускаете службу машинного обучения, вы, по сути,…собираете данные обратной связи о ее производительности. Вы хотите, чтобы этот MVP не был оптимизирован… почему? ну, это будет означать, что это, вероятно, что-то более простое… и что-то простое легче отладить, чем что-то сложное. Хорошо определите свою настройку и проверьте ее. Если это правильно, оптимизировать его станет намного проще в будущем.

Компромиссы.Дизайн продукта — это игра компромиссов. Ваш выбор будет направлен на то, чтобы сделать продукт проще и/или быстрее в разработке… но взамен что-то будет потеряно (например, прогностическая сила в глобальном масштабе или для ниши клиентов). Объявите свои компромиссы вслух и держите их на виду… чтобы все знали: что важно прямо сейчас… а что может подождать.

Если у вашего бизнеса нет масштабов для предоставления услуг машинного обучения… зачем вам вообще беспокоиться?

Избегайте машинного обучения.Продукты машинного обучения дороги как в создании, так и в обслуживании. Они, как правило, жадны до среды, богатой данными + настоящего таланта + качественных данных в масштабе. Это вещи, которые нелегко получить и/или поддерживать. Если у вашего бизнеса нет масштабов для предоставления услуг машинного обучения… зачем вам вообще беспокоиться? Просто полностью избегайте машинного обучения. Помимо предиктивной и предписывающей аналитики, существуют десятки других способов монетизации данных. Более того, вы можете добиться персонализации, заставив людей создавать и итеративно настраивать простые системы показателей на основе правил (то есть модели, не основанные на ML) с помощью Анализа решений по множеству критериев (см. пример здесь). Если они работают... почему бы и нет?

Проектирование системы Zero-Stack ML в шести строительных блоках

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

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

Чтобы решить эту (или любую) проблему проектирования системы машинного обучения, вы можете использовать следующую структуру zero-stack:

  • Область действия.Если внимательно посмотреть на наш пример, можно отобразить много информации. Тем не менее, вы по-прежнему упускаете много вещей (например, масштаб, количественную оценку успеха и т. д.). Заранее прояснить вашу проблему крайне важно, чтобы держать вас и ваших заинтересованных лиц на одной странице.
  • Формулировка проблемы: Хорошо, у нас есть область нашей бизнес-проблемы. Как нам преобразовать ее в математическую задачу, которую можно решить с помощью компьютерной программы, если и когда ей будут предоставлены данные?
  • Методология:Хорошо, у нас есть математическая задача.как мы можем разработать компьютерную программу для решения нашей задачи?
  • Оценка в автономном режиме. Хорошо, у нас есть компьютерный метод решения математической задачи. Что означает успех для такого метода? Как мы можем предсказать успех перед выходом в эфир?
  • Производство: Хорошо, наш компьютерный метод, похоже, хорошо работает в нашей задаче.Как мы можем преобразовать наш компьютерный метод в систему, способную обслуживать реальных клиентов в реальном мире?
  • Оценка в реальном времени: Хорошо, мы в прямом эфире. Ура! Как мы можем отслеживать производительность этой системы в реальном мире и убедиться, что она двигается вперед?

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