Устранение разрыва в статистике с критериями приемлемости для науки о данных

История двух рекомендательных систем

Вот два знакомых продукта:

  1. TripAdvisor, веб-сайт, объединяющий информацию о путешествиях и бронировании жилья. Здесь я остановлюсь на бронировании номера в отеле.
  2. Stitch Fix, служба подписки, которая отправляет участникам несколько предметов одежды. Члены платят только за то, что оставляют.

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

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

Когда вы ищете отель на TripAdvisor, вы обычно хорошо представляете, что ищете («4-звездочный отель в центре Бостона»). Итак, вы выбираете между довольно похожими вариантами. И если все пойдет хорошо, вы забронируете ровно одну гостиницу.

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

Кроме того, Stitch Fix отправляет вам ровно пять элементов. Если предмет, занявший шестое место, был вашим любимым, не повезло. Вы никогда этого не увидите и никогда не купите.

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

Разрыв в статистике

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

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

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

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

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

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

Критерии приема: издание для науки о данных

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

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

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

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

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

Вот как это выглядит:

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

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

От бизнес-метрик к метрикам моделирования

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

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

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

  • Если система одобряет недействительную апелляцию, город теряет доход от парковочного талона. Показатель - это количество одобренных недействительных апелляций. Мы можем точно выразить это в долларовом выражении: в Нью-Йорке каждый билет стоит 65 долларов.
  • Если система передает действительную апелляцию агенту, город несет расходы на дополнительную заработную плату агента. Таким образом, показатель - это количество действительных апелляций, рассмотренных агентом. Чтобы выразить это в долларах, вам нужно будет вычислить стоимость обработки апелляции, что было бы неплохо.

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

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

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

Бизнес-цели определяют цели моделирования

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

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

Следует ли строить консервативную модель или разрешительную модель? Это не вопрос науки о данных. Это деловой вопрос.

Таким образом, менеджер по продукту должен определить бизнес-цели. Затем бизнес-цели преобразуются в цели моделирования. Вот некоторые примеры:

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

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

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

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

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

Бизнес-цель №3: сократить время выполнения работ при большой загрузке дел
Что делать, если агенты получают зарплату и объединяются в профсоюзы, чтобы их нельзя было уволить? Город не собирается экономить на снижении загруженности. Таким образом, для системы не имеет смысла одобрять слишком много дел, пока агенты просто сидят без дела. Но город может по-прежнему использовать систему для сокращения времени обработки, когда количество апелляций очень велико.

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

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

Нижняя линия

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

Чтобы устранить пробел в статистике, адаптируйте концепцию критериев приемлемости к задачам Data Science. Менеджер по продукту определяет бизнес-метрики и бизнес-цели. Затем специалисты по обработке данных переводят их в моделирование показателей и целей моделирования. Это итеративный процесс, который следует повторять для каждой итерации моделирования.

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

PS: Как на самом деле Нью-Йорк решает проблему парковочных талонов

На самом деле, если вы подаете апелляцию на штраф за парковку в Нью-Йорке, в большинстве случаев вам автоматически предлагается скидка около 30%, если вы просто оплатите билет. Если вы решите оспорить его, в конечном итоге вам придется заплатить больше в суде.

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

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