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

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

Это, безусловно, далеко от реальности в нашей области. Напротив, даже в средах «глубоких технологий», с которыми я сталкивался, производительность функций ML в значительной степени зависела от таких вещей, как дизайн продукта, UX, межфункциональное сотрудничество, одержимость клиентов и бизнеса…

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

Исследования и огромные возможности B2B далеки от нормы

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

  • "Ориентировано на использование" и "Ориентировано на восприятие пользователей": вы не спрашиваете пользователей YouTube, довольны ли они новейшим алгоритмом. Вы просто следите за тем, чтобы использование и связанная с ним реклама улучшались. С другой стороны, компания B2B должна убедиться, что люди, отвечающие за оплату счетов, будут счастливы это сделать.
  • «Одержимость ключевыми показателями эффективности» и «одержимость клиентами». В исследовательском мире многие команды часто соревнуются на одном и том же наборе данных, чтобы построить модель с самым высоким KPI (например, модели языкового перевода). Таким образом, оценка модели сводится к нескольким KPI. Это может произойти в частном секторе (например, оценка эффективности YouTube может полностью определяться LifetimeValue его пользователей), но очень редко: у большинства реальных функций нет KPI, которые могли бы полностью измерить удовлетворенность их пользователей. Поэтому необходимо инвестировать в понимание ваших клиентов и убедиться, что любая новая модель действительно улучшит ситуацию.
  • Фокус «средняя эффективность» вместо «эффективность для всех»: нам не нужно, чтобы каждый пользователь YouTube был на высоте. В основном мы оптимизируем наш глобальный KPI (который обычно коррелирует с доходом)... С другой стороны, в контексте B2B вы, как правило, хотите обеспечить «достаточно хороший» опыт для всех, что означает сосредоточение внимания на недовольных клиентах. , а не просто улучшать средние показатели эффективности.
  • Стратегия «чисто количественной» обратной связи для обеспечения качества по сравнению с «качественной + количественной» обратной связью. Если у вас есть огромное количество данных об использовании и вы заинтересованы только в оптимизации нескольких ключевых показателей эффективности, то вы можете поставить большую часть своей стратегии качества на повторное обучение на основе отзывов об использовании (скажем, наблюдая, нажимают ли люди на следующее видео на YouTube или нет). С остальным миром все сложнее. Помимо того факта, что у вас, вероятно, не будет достаточного количества пользователей для улучшения сложных алгоритмов в сложных сценариях использования, вам необходимо узнать мнение ваших клиентов, чтобы обогатить свой анализ качественными отзывами. Вы должны убедиться, что любые новые модели или итерации действительно улучшают ситуацию (модель с улучшенными внутренними KPI может считаться клиентами хуже).

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

ML Quality — это межфункциональный процесс

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

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

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

Детали модели имеют решающее значение в дизайне продукта

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

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

  1. С чего начинают многие команды:

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

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

2. Во что это превращается перед лицом реальности:

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

3. Что полезнее для ускорения доставки продуктов ИИ:

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

  • Эксперты по машинному обучению должны быть вовлечены в процесс создания продукта как можно раньше: анализ потребностей должен быть взвешен с реальным потенциалом машинного обучения, и большая часть работы по машинному обучению должна быть выполнена до начала создания продукта.
  • Построение обширной оценки реального поведения в различных ситуациях (с разными категориями пользователей, ситуаций и использования продукта) имеет основополагающее значение для проверки любого проекта. Такая оценка может быть выполнена после развертывания путем анализа обратной связи, но не только. По моему опыту, создание POC ML с реалистичными данными на этапе проектирования и итерация с каждым дизайном продукта. это очень мощный подход. Это дешевле, чем кажется, и на порядки дешевле, чем создание реального промышленного масштабируемого продукта.
  • В конечном счете, цель состоит в том, чтобы итерировать дизайн, а не производственный код, который оптимизирован для обеспечения стабильности. Цикл обратной связи также является частью дизайна. Однако он находится ниже по течению процесса и не может «спасти» функцию от неоптимального дизайна UX/продукта.

…

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