Записки из промышленности
У управления продуктами ML есть проблема с переводом
Местная проблема перевода, обнаруженная в продуктах Data/ML
Создавать продукты машинного обучения сложно.
Я испытал трудности роста с обеих сторон проблемы — как Data Scientist и как Product Manager.
Часто цитируемая цифра (настолько распространенная в рекламе ML/MLOPs, что кажется клише) заключается в том, что 85% проектов ИИ не приносят ожидаемых результатов для бизнеса.
Слоан отмечает, что даже при наличии правильных данных, талантов и корпоративной стратегии только 20% компаний добиваются финансовой окупаемости инвестиций от инициатив ИИ.
Несмотря на этот низкий показатель успеха, проекты AI/ML никуда не денутся — 91,5% компаний постоянно инвестируют в AI.
Причин провала проекта машинного обучения множество: от проблем с исходными данными до плохого мониторинга. В этой серии статей я расскажу о трех основных проблемах, с которыми сталкиваются продукты машинного обучения, с которыми я сталкивался на своем опыте. Наслаждаться!
Проблема перевода. Часто существует явное несоответствие между потребностями бизнеса и решениями для обработки данных.
Проблема перевода в дикой природе:
Вот два преувеличенных, но удивительно распространенных сценария, в которых компании пытаются или не могут запустить инициативы ML. Надеюсь, они не попали слишком близко к цели:
1. «Сделайте поиск лучше»
Приа, менеджер по продукту, проводит месяц или около того, опрашивая клиентов в поисках способов улучшить мобильное приложение своей компании. Проанализировав все свои разговоры, она приходит к выводу, что людям не нравится функция поиска, потому что они не могут найти новый и интересный контент для просмотра.
Приа заметила, что обычное поведение заключается в том, что клиенты посещают поиск, становятся недовольными результатами и закрывают приложение. На самом деле, некоторые люди даже перешли на приложение конкурента из-за того, насколько плохим был опыт.
У Прии есть момент озарения: Может быть, новый специалист по данным сможет улучшить поиск!
Приа быстро запланировала встречу с командой Data Science и поделилась своей идеей — «используйте Data Science и машинное обучение, чтобы сделать поиск лучше». Приа не имеет технического образования и не знает точно, чем может помочь DS/ML, но предполагает, что у них есть какие-то хитрости в рукаве.
Дейв, специалист по данным, очень рад получить проблему, ориентированную на клиента! Следующие несколько недель он проводит за чтением новых статей о рекомендательных системах, внедрением нескольких из них, которые кажутся многообещающими, и тестированием их в автономном режиме. Он использует лучшие 5 рекомендаций в качестве своей метрики и считает, что передовая модель глубокого обучения работает лучше всего. После нескольких спринтов он представляет свои результаты Приа…
…и быстро понимает, что это не то, чего хотела Прия.
В следующем A/B-тесте, сравнивающем модель Дейва с текущей системой, клиенты действительно чаще нажимают на рекомендации из модели Дейва… но уходят почти с той же скоростью.
Это приводит Дэйва в восторг, потому что его алгоритм рекомендаций явно превосходит существующий статус-кво с точки зрения рейтинга кликов, а Прию разочаровывает, потому что он не решает фактическую основную проблему удержания.
Это гипотетический сценарий, но модель Дейва может быть более эффективной с точки зрения CTR, но с более низким уровнем удержания, поскольку она рекомендует только наиболее популярный контент. эти рекомендации разочаровывают
Это может показаться проблемой, связанной с недопониманием (и так оно и есть), но распространенность продуктовых/бизнес-инициатив, не согласующихся с конечными результатами науки о данных, ясно говорит о том, что здесь происходит что-то большее.
Бизнес-цели и потребности часто неправильно преобразуются в показатели Data Science.
2. Ориентированность на данные и клиентоориентированность
Вышеупомянутое несоответствие не обязательно должно происходить из конвейера от продукта к науке о данных; это также может исходить от увлеченного (но наивного) стратегического руководства, пытающегося внедрить машинное обучение в каждое предприятие. Если ты слышишь вопрос,
«Какие проекты машинного обучения мы можем реализовать с имеющимися данными?»
Ваша команда скрывается в опасной близости от территории рассогласования.
Существует бесчисленное количество проектов, связанных с машинным обучением, которые специалист по данным может придумать с помощью надежного набора данных… но на сколько из этих проектов можно положиться, чтобы обеспечить рентабельность инвестиций? Сколько из этих проектов могут оказать прямое и положительное влияние на текущие проблемы клиентов?
Меньше, чем вы можете себе представить.
Проекты по науке о данных без четкой структуры или связи с конкретной проблемой клиента часто не приносят пользы для бизнеса.
Определение проблемы
Постановка задачи. Как команда по разработке продукта, мы хотим, чтобы все в команде были на одной волне, чтобы мы могли быстро двигаться и правильно создавать наш продукт. Однако часто существует разрыв между бизнес-языком и языком данных. Нам нужно вместе решить,«какую именно проблему мы изучаем и пытаемся решить?» и «можем ли мы количественно определить критерии успеха?»
- Это нигде не задокументировано и вызывает огромную боль со стороны Data Science, поскольку DS часто приходится делать большие скачки и делать предположения, чтобы добраться до бизнеса.
- Это может быть неявно из-за того, какие карты JIRA выдвигаются
Масштабируемые решения
Наиболее важной частью решения проблемы перевода является ее признание и подготовка к ней.
Ниже приведены 2 прикладные стратегии, которые сработали для меня в прошлом. Не думайте, что это единственные пути продвижения вперед, а скорее предложения, которые могут вписаться в текущий процесс поиска продукта вашей командой.
1. Сервировка стола
Сервировка стола просто означает убедиться, что с самого начала достигнуто полное согласие. Многие из них кажутся очевидными, но наличие четкого письменного документа, в котором излагаются ответы на следующие важные вопросы и который получит одобрение со стороны как технических специалистов, так и заинтересованных сторон, связанных с продуктом, значительно повысит ваши шансы на создание ценности.
Несколько основных вопросов, на которые нужно ответить вместе:
Какую проблему клиента мы решаем? Размещение этого в верхней части документа гарантирует, что все предположения/решения, сделанные группой обработки данных, направлены на решение этой конкретной проблемы, а не на множество другие возможные проблемы там.
Как оценить успех эксперимента офлайн? Количественная оценка успеха продукта или потребности бизнеса — нетривиальная задача. Честно говоря, это основной навык сильного Data Scientist. Но сделать это правильно и добиться того, чтобы все с этим согласились, — основа повышения ценности продуктов машинного обучения.
Как количественно оценить успех онлайн-эксперимента? То же, что и выше, но это относится к тому, что мы ищем в A/B-тестировании — каким должен быть результат нашей системы? Некоторые показатели, такие как удержание клиентов, нельзя зафиксировать в офлайн-экспериментах.
Есть ли какие-либо блокираторы данных или моделей для решения этой проблемы клиента? Ожидается, что этот раздел будет часто обновляться на протяжении всего процесса обнаружения, а не только в начале. Наука о данных — это итеративный процесс. И команда данных столкнется с проблемами данных — это неизбежно. Наличие места для их документирования может раскрепостить как специалистов по данным, так и продуктовых групп, поскольку делает причины задержек приемлемыми, а уроки, извлеченные из неудач, очевидными. (Подробнее об этом в следующей записи блога!)
Все это можно упаковать во что-то вроде этого:
Это не обязательно делать на собрании, но это, безусловно, совместный опыт.
Хотя эта структура полезна, когда менеджер по продукту знает, как может помочь наука о данных (например, в сценарии № 1), мы можем расширить ее, чтобы она также поддерживала решения, основанные на данных (например, сценарий № 2).
Это может быть просто предоставление команде по науке о данных ранжированного списка (таблица Excel или что-то еще) со всеми выявленными проблемами клиентов и способами их решения. Это дает команде данных четкую основу для начала исследования данных и POC, а также гарантирует, что все разговоры связаны с проблемами клиентов.
Вы даже можете создать пространство, где люди могут добавлять комментарии, блокираторы и предложения POC под проблемами клиентов, обеспечивая более полную ясность по этим вопросам:
2. Детские шаги
Это может показаться небольшим изменением, но оно очень важно: ML не должен быть первой версией, которую вы тестируете, даже если ML — это именно та технология, которая вам нужна.
ML — это мощный инструмент, но с этой силой приходит сложность. Сохраняйте его как можно более простым как можно дольше.
В качестве менеджера по продукту: Попробуйте версию Волшебника страны Оз с реальными людьми, дающими ответы, чтобы увидеть, реагируют ли ваши клиенты на более персонализированный/кураторский ответ. Если они это сделают, обратитесь к машинному обучению, чтобы масштабировать свой эксперимент с Волшебником страны Оз. Если WOZ не обсуждается, посмотрите, может ли подход, основанный на правилах, быть достаточным, или, по крайней мере, посмотрите, насколько он эффективен.
Как специалист по данным: Всегда начинайте с фиктивной модели в качестве основы и убедитесь, что команда разработчиков продукта согласна со схемой проверки автономного эксперимента. Чрезвычайно полезно для вас и вашей команды контекстуализировать оценку точности по сравнению с простой для понимания моделью. Если ваша модель имеет точность тестирования 89 %, каждый может понять, что это впечатляющий прирост по сравнению с фиктивным достижением. Точность 51%… и не так уж впечатляет по сравнению с манекеном, достигающим точности 87%.
Мне, как специалисту по данным, трудно принять этот совет: Не используйте причудливую передовую модель машинного обучения с глубоким обучением, если у вас нет других вариантов. Они могут быть неинтересными, но регрессионные модели помогут вам решить 80% практически любой бизнес-проблемы. Только после того, как вы сделали несколько успешных итераций в продакшене, вы можете даже подумать о более глубокой архитектуре.
Заключение
Если вы испытываете эту боль, как PM или DS, я глубоко сочувствую и сожалею о вашей борьбе. Эта боль была настолько острой, что я руководил ML в старом проекте, и я даже думал о создании программного обеспечения, которое лучше всего справится с этой проблемой (отсюда скриншот Figma ранее в этом посте).
Я понял, что это не проблема технологии, а проблема организации и процесса, которую очень сложно решить с помощью новой технологии.
Вашей компании нужен кто-то (читай: ВЫ), который занял бы внутреннюю позицию по проблеме перевода и начал знакомить вашу группу по исследованию продукта с обновленным процессом.
В противном случае ваша команда останется с остальными 85% компаний, которые изо всех сил пытаются извлечь выгоду из машинного обучения.
Надеюсь, это было информативно и полезно!
