80% проектов машинного обучения терпят неудачу из-за неправильной формулировки проблемы, а не из-за плохих моделей. Пятишаговый протокол для определения правильной проблемы перед написанием кода для обучения.
Делиться
Сейчас 23:14 среды. Вы уже три недели работаете над моделью прогнозирования оттока клиентов, склонившись над ноутбуком, и наблюдаете, как байесовский оптимизационный процесс медленно продвигается к своему 200-му испытанию. Показатель AUC на валидационной выборке колеблется от 0,847 до 0,849. Вы делаете скриншот. Вы публикуете его в Slack. Ваш менеджер реагирует одобрительным жестом.
Вы чувствуете себя продуктивным. На самом деле это не так.
Если вы когда-либо тратили дни на то, чтобы выжать из метрики машинного обучения доли процента, в то время как тихий голос в глубине души шептал: «А имеет ли это вообще какое-либо значение?», вы уже чувствуете проблему. Этот голос прав. И заглушить его с помощью очередного поиска по сетке — одна из самых дорогостоящих привычек в профессии.
Вот неприятная статистика: согласно исследованию корпорации RAND, опубликованному в 2024 году, более 80% проектов в области искусственного интеллекта (ИИ) терпят неудачу. Главная причина — не плохие модели. Недостаток данных. Непонимание (или некорректная передача) того, какую проблему нужно решить . Не ошибка моделирования. Ошибка в формулировке.
В этой статье представлен конкретный протокол для обнаружения этой ошибки до того, как вы напишете хотя бы одну строку кода для обучения. Пять шагов. Каждый из них требует отдельного диалога, а не кластера графических процессоров.
«Весь этот прогресс в алгоритмах означает, что настало время уделять больше времени данным». Эндрю Нг не сказал, что нужно уделять больше времени модели. Он сказал прямо противоположное.
Ловушка продуктивной прокрастинации
Настройка гиперпараметров напоминает инженерную работу. У вас есть пространство поиска. У вас есть целевая функция. Вы итеративно выполняете итерации, измеряете, улучшаете. Обратная связь работает быстро (от минут до часов), прогресс виден (показатели растут), и результаты работы понятны вашей команде («Я улучшил AUC на 2 пункта»).
Формулировка проблемы воспринимается как затягивание процесса. Вы сидите в комнате с заинтересованными сторонами из бизнеса, которые используют неточные формулировки. Вы задаете вопросы, на которые нет однозначных ответов. Нет никаких показателей, демонстрирующих рост. Нет скриншота из Slack, чтобы опубликовать. Ваш менеджер спрашивает, что вы делали сегодня, и вы отвечаете: «Я потратил четыре часа, пытаясь понять, следует ли нам прогнозировать отток клиентов или вероятность их повторной активации». Этот ответ не звучит как прогресс.
Но важен только прогресс.
Изображение предоставлено автором.
Причина структурная. Настройка работает в рамках определенной проблемы. Если проблема определена неправильно, настройка оптимизирует функцию, которая не соответствует бизнес-ценности. В результате вы получаете прекрасную модель, которая решает не ту задачу. И никакое количество итераций Optuna не сможет исправить целевую переменную, которой не должно существовать.
Компания Zillow поставила 500 миллионов долларов на неправильную проблему.
В 2021 году компания Zillow закрыла свое подразделение по покупке жилья, Zillow Offers, после того, как понесла убытки в размере более 500 миллионов долларов. Компания приобрела около 7000 домов в 25 крупных городах, постоянно переплачивая, поскольку ее алгоритм ценообразования (Zestimate) не адаптировался к охлаждению рынка.
Анализ причин неудач был сосредоточен на отклонении от первоначальной концепции. Модель, обученная на данных с «горячего» рынка, не справлялась с замедлением спроса. Нехватка подрядчиков во время COVID-19 задержала ремонт. Обратная связь между покупкой и перепродажей была слишком медленной, чтобы выявить ошибку.
Но более серьезная проблема возникла еще до того, как была обучена какая-либо модель.
Компания Zillow сформулировала задачу следующим образом: имея характеристики дома, предсказать его рыночную стоимость. Эта формулировка предполагала стабильную взаимосвязь между характеристиками и ценой. Она предполагала, что Zillow сможет ремонтировать и перепродавать недвижимость достаточно быстро, чтобы окно прогнозирования оставалось коротким. Она предполагала, что распределение ошибок модели симметрично (переплата и недоплата одинаково вероятны). Ни одно из этих предположений не подтвердилось.
Конкуренты Opendoor и Offerpad пережили аналогичные рыночные изменения. Их модели выявили охлаждение рынка и скорректировали цены. Разница заключалась не в алгоритмической сложности, а в том, как каждая компания сформулировала задачи, которые должна выполнять ее модель, и как быстро она обновила эту формулировку.
Компания Zillow потеряла 500 миллионов долларов не из-за плохой модели. Она потеряла их потому, что никогда не задавалась вопросом, является ли задача «прогнозирование стоимости жилья» подходящей для решения с учетом скорости ее работы.
Когда искусственный интеллект научился распознавать линейки вместо рака
Исследовательская группа разработала нейронную сеть для классификации кожных поражений как доброкачественных или злокачественных. Модель достигла точности, сопоставимой с точностью сертифицированных дерматологов. Впечатляющие результаты. Четкие кривые валидации.
Затем кто-то изучил, чему на самом деле научилась модель.
Модель обнаруживала линейки. Когда дерматологи подозревают, что поражение может быть злокачественным, они прикладывают к нему линейку, чтобы измерить его размер. Таким образом, в обучающих данных изображения, содержащие линейки, коррелировали со злокачественностью. Модель нашла упрощенный способ: наличие линейки = вероятно, рак. Отсутствие линейки = вероятно, доброкачественное образование.
Точность была реальной. Обучение было ужасным. И никакая настройка гиперпараметров не смогла бы это обнаружить, потому что модель работала точно так, как было указано, на данных, точно так, как они были предоставлены. Сбой произошел на более раннем этапе: никто не спросил: «На что должна обращать внимание модель, чтобы принять это решение?», прежде чем измерить, насколько хорошо она приняла это решение.
Это так называемый метод «быстрого обучения», и он встречается повсюду. Модели учатся использовать корреляции в ваших данных, которые не будут работать в реальных условиях. Единственная защита — это четкое определение того, что модель должна и не должна использовать в качестве сигнала, и это определение исходит из формулировки задачи, а не из настройки.
Почему ошибки в оформлении текста сохраняются так долго?
Если неправильная формулировка проблемы настолько разрушительна, почему умные команды продолжают её игнорировать?
Три взаимоусиливающих фактора обеспечивают устойчивость этого явления.
Во-первых, асимметрия обратной связи. Когда вы настраиваете гиперпараметр, результат виден за считанные минуты. Когда вы переформулируете проблему, отдача будет незаметна в течение нескольких недель. Человеческий мозг недооценивает отложенные вознаграждения. Поэтому команды тяготеют к быстрой обратной связи при настройке, даже когда медленная работа по переформулированию приносит в 10 раз большую отдачу.
Во-вторых, предвзятость, связанная с читаемостью. «Я повысил точность с 84,7% до 84,9%» — это четкое и обоснованное заявление на совещании. «Вчера я потратил время на то, чтобы убедить команду разработчиков, что мы оптимизируем неправильный показатель» звучит так, будто вы ничего не добились. Организации поощряют видимые результаты. Формулировка проблемы не приводит к видимым результатам, пока не предотвратит катастрофу, о которой никто не знал.
В-третьих, идентичность. Специалистов по анализу данных обучают построению моделей. Инструменты, курсы, таблицы лидеров Kaggle, вопросы на собеседованиях — все это сосредоточено на моделировании. Формулирование проблемы воспринимается как чья-то чужая работа (продуктовая, бизнес- или стратегическая). Заявлять об этом означает выходить за рамки своей технической идентичности, а это вызывает дискомфорт.
Эндрю Нг дал название этой модели, когда в 2021 году представил концепцию искусственного интеллекта (ИИ), ориентированного на данные. Он определил её как «дисциплину систематического проектирования данных, необходимых для построения успешной системы ИИ». Его аргумент: сообщество машинного обучения потратило десятилетие на одержимость архитектурой моделей, рассматривая данные (и, как следствие, определение проблемы) как чью-то чужую работу. Результаты от улучшения архитектуры достигли плато. Результаты от улучшения определения проблемы практически не были использованы.
Мастер по настройке стальных деталей
Прежде чем продолжить: настройка гиперпараметров не бесполезна. Бывают ситуации, когда это совершенно правильное решение.
Если вы уже убедились, что ваша целевая переменная напрямую связана с бизнес-решением. Если распределение данных в рабочей среде соответствует обучающей выборке. Если вы подтвердили, что ваши признаки улавливают сигнал, важный для бизнеса (и только этот сигнал). Если все это верно, то настройка мощности модели, регуляризации и скорости обучения является законной оптимизацией.
Утверждение не в том, что «никогда не нужно настраивать». Утверждение в другом: большинство команд начинают настройку еще до того, как заслужат на это право. Они пропускают этап определения того, будет ли настройка вообще иметь значение. А когда настройка дает лишь незначительные улучшения при неправильно сформулированной проблеме, эти улучшения оказываются иллюзорными.
Исследования в области анализа данных наглядно демонстрируют эту закономерность: как только вы достигли 95% возможной производительности при базовой конфигурации, затраты времени на извлечение еще 0,5% редко оправдывают вычислительные издержки. Ситуация усугубляется, когда 95% измеряются по неверному критерию.
Пятишаговый протокол формулирования проблемы
Этот протокол выполняется до начала любого моделирования. В зависимости от доступности заинтересованных сторон, он занимает от 2 до 5 дней. На каждом этапе создается письменный документ, на который ваша команда может ссылаться и который может оспаривать. Пропуск шага означает, что ваши предположения неверны. Большинство из них неверны.
Шаг 1: Назовите решение (а не прогноз).
Кто: Руководитель направления анализа данных + заинтересованная сторона из бизнеса, которая будет действовать на основе результатов работы модели.
Когда: Первая встреча. До начала анализа данных.
Как это сделать: Задайте этот вопрос и запишите ответ дословно:
«Когда эта модель выдает результат, какое конкретное решение меняется? Кто принимает это решение и что они делают по-другому?»
Пример (хороший): «Команда по удержанию клиентов еженедельно обзванивает 200 наиболее уязвимых клиентов, вместо того чтобы рассылать электронные письма всем 5000. Модель ранжирует клиентов по вероятности повторной активации, поэтому команда знает, кому звонить в первую очередь».
Пример (неудачный): «Мы хотим спрогнозировать отток клиентов». (Решение не указано. Действующее лицо не определено. Действие не указано.)
Тревожный сигнал: если заинтересованная сторона не может назвать конкретное решение, у проекта пока нет практического применения. Сделайте паузу. Не переходите к анализу данных. Модель без решения — это отчет, который никто не читает.
Шаг 2: Определение асимметрии стоимости ошибки
Кто: Руководитель направления анализа данных + представитель бизнеса + финансовый отдел (при наличии).
Когда: В тот же день или на следующий день.
Как: Спросите:
«Что хуже: ложноположительный или ложноотрицательный результат? Насколько?»
Пример: Для модели обнаружения мошенничества ложноотрицательный результат (пропущенное мошенничество) обходится компании в среднем в 4200 долларов за инцидент. Ложноположительный результат (блокировка законной транзакции) обходится в 12 долларов в виде времени обслуживания клиентов плюс 3% вероятности потери клиента (ожидаемая стоимость 180 долларов). Соотношение составляет примерно 23:1. Это означает, что модель следует настраивать на полноту, а не на точность, и пороговое значение для принятия решения следует установить значительно ниже 0,5.
Почему это важно: стандартные метрики машинного обучения (точность, F1) предполагают симметричные издержки ошибок. В реальных бизнес-задачах симметричные издержки ошибок практически никогда не встречаются. Если вы оптимизируете F1, когда фактическое соотношение издержек составляет 23:1, вы построите модель, которая хорошо работает на бумаге, но плохо в производственной среде. Zillow Zestimate рассматривал завышенные и заниженные оценки как одинаково плохие. Это не так. Переплата за дом, который вы не сможете перепродать в течение нескольких месяцев, катастрофически хуже, чем занижение цены и потеря сделки.
Шаг 3: Проверка целевой переменной
Кто: Ведущий специалист в области анализа данных + эксперт в данной сфере.
Когда: После того, как шаги 1-2 задокументированы. До начала разработки новых функций.
Как: Ответьте на эти четыре вопроса в письменной форме:
- Действительно ли эта целевая переменная отражает то, что важно для бизнеса? «Отток» может означать «отмену подписки» в ваших данных, но «прекращение использования продукта» в понимании заинтересованных сторон. Это разные группы населения. Уточните, какая из них соответствует решению, принятому на шаге 1.
- Когда наблюдается целевой показатель относительно момента, когда модели необходимо вмешаться? Если вы прогнозируете отток клиентов за 30 дней, но команде по удержанию клиентов требуется 14 дней для вмешательства, ваш прогнозный период неверен. Модель должна прогнозировать отток клиентов как минимум за 14 дней до того, как он произойдет.
- Не искажена ли целевая переменная в результате вмешательства, которое вы пытаетесь оптимизировать? Если предыдущие усилия по удержанию клиентов уже снизили отток некоторых из них, ваши обучающие данные недооценивают их истинный риск оттока. Модель учится на утверждении «эти клиенты не уходят», тогда как на самом деле «эти клиенты не уходят, потому что мы вмешались». Это ловушка причинно-следственного вывода, и она незаметна при стандартном разделении на обучающую и тестовую выборки.
- Сможет ли модель научиться распознавать правильный сигнал или найдет обходные пути? Проблема, подобная проблеме линейки в дерматологии. Перечислите признаки. Для каждого из них задайте себе вопрос: «Использовал бы эксперт в данной области этот признак для принятия такого решения?» Если нет, то это может быть косвенный признак, который не будет иметь обобщающего эффекта.
Шаг 4: Моделирование решения о развертывании
Кто: Вся проектная команда (DS, инженеры, специалист по продукту, представители бизнеса).
Когда: После того, как шаги 1-3 задокументированы. До начала моделирования.
Как это сделать: Проведите настольное упражнение. Предоставьте команде 10 результатов работы синтетической модели (смесь правильных прогнозов, ложноположительных и ложноотрицательных результатов) и задайте вопрос:
- «Учитывая полученные результаты, какие действия предпримет компания?»
- «Правилен ли этот шаг, учитывая реальное положение дел?»
- «Сколько стоит каждый тип ошибки?»
- «При каком пороге доверия компания перестает доверять модели?»
Это упражнение выявляет несоответствия, которые не могут быть обнаружены ни одной метрикой. Вы можете обнаружить, что бизнесу на самом деле нужен рейтинг (а не бинарная классификация). Или что заинтересованная сторона не будет действовать на основе прогнозов с уровнем достоверности ниже 90%, а это значит, что половина результатов вашей модели будет проигнорирована. Или что для «действия» требуется информация, которую модель не предоставляет (например, почему клиент находится в группе риска).
Артефакт: Спецификация развертывания на одной странице, содержащая информацию о том, кто использует выходные данные, в каком формате, с какой частотой, с каким порогом достоверности и что происходит, когда модель дает неверные результаты.
Шаг 5: Напишите антицель
Кто: Ведущий специалист по анализу данных.
Когда: После шагов 1-4. Последняя проверка перед началом моделирования.
Как это сделать: Напишите один абзац, ответив на следующий вопрос:
«Если этот проект преуспевает по всем определенным нами показателям, но все равно терпит неудачу в производстве, что пошло не так?»
Пример 1: «Модель оттока клиентов показывает AUC 0,91 на тестовом наборе данных, но команда по удержанию клиентов игнорирует это, потому что прогнозы поступают через 48 часов после их еженедельного совещания по планированию. Модель точна, но бесполезна в практическом плане, потому что мы не согласовали периодичность прогнозирования с периодичностью принятия решений».
Пример 2: «Модель выявления мошенничества обнаруживает 15% транзакций, что перегружает группу проверки. Они начинают автоматически одобрять запросы, чтобы очистить очередь. Технически модель выявляет мошенничество; на практике же люди, участвующие в процессе, научились его игнорировать».
Антицель — это инверсия: вместо определения успеха, определите наиболее вероятный провал. Если вы можете сформулировать яркую антицель, вы часто можете предотвратить её. Если вы не можете её сформулировать, значит, вы недостаточно тщательно продумали процесс внедрения.
Это проблема настройки или проблема позиционирования?
Не каждый застопорившийся проект нуждается в переформулировании. Иногда проблема сформулирована правильно, и вам действительно необходимо улучшить производительность модели. Используйте этот диагностический инструмент, чтобы определить разницу.
Что меняется, когда команды сначала формируют кадр?
Переход от модельно-ориентированного подхода к проблемно-ориентированному — это не просто избегание ошибок. Он меняет само понятие «старший специалист» в области науки о данных.
Начинающие специалисты по анализу данных ценятся за навыки моделирования: умеют ли они обучать, настраивать и развертывать модели? Опытные специалисты по анализу данных должны цениться за умение формулировать задачи: могут ли они превратить неоднозначную бизнес-ситуацию в четко сформулированную задачу прогнозирования с правильной целевой переменной, правильными признаками и правильными критериями успеха?
Отрасль постепенно догоняет. Одним из сигналов является стремление Эндрю Нга к созданию ИИ, ориентированного на данные. Другой сигнал – отчет корпорации RAND за 2024 год о негативных тенденциях в ИИ: их главная рекомендация заключается в том, что руководители должны убедиться, что технический персонал понимает цель и контекст проекта до его начала. В анализе неудач в области машинного обучения, проведенном QCon в 2024 году, наиболее распространенной ловушкой названы «несоответствие целей».
Закономерность очевидна. Узким местом в машинном обучении являются не алгоритмы, а соответствие между целью модели и реальными потребностями бизнеса. И это соответствие — результат человеческого диалога, а не вычислительных процессов.
Узким местом в машинном обучении являются не вычислительные ресурсы или алгоритмы, а взаимодействие между человеком, создающим модель, и человеком, использующим её результаты.
Для организаций это означает, что формулирование проблемы должно быть первостепенной задачей, требующей выделения времени, определения результатов и проведения анализа. Не прелюдией к «настоящей работе». А настоящей работой.
Для отдельных специалистов по анализу данных это означает, что самый быстрый способ повысить свою эффективность — это не изучение нового фреймворка или освоение распределенного обучения. Это умение задавать более качественные вопросы, прежде чем открывать блокнот.
Сейчас 23:14 среды. Вы работаете над проектом уже три недели. Показатели валидации растут. Вы собираетесь запустить очередной этап проверки.
Останавливаться.
Откройте пустой документ. Напишите одно предложение: «Решение, которое меняется в зависимости от результатов этой модели, — это ___». Если вы не можете заполнить пробел, не позвонив заинтересованной стороне, вы только что нашли наиболее выгодное занятие на завтрашнее утро. Это не будет ощущаться как прогресс. Это не приведет к созданию скриншота, достойного публикации в Slack. Но это единственная работа, от которой зависит, будут ли вообще следующие три недели иметь значение.
Ссылки
- Корпорация RAND, «Первопричины неудач проектов в области искусственного интеллекта и пути к их успеху», Джеймс Райсефф, Брэндон Де Брюль, Сидни Дж. Ньюберри, 2024.
- Институт Слоуна при Массачусетском технологическом институте, «Почему настало время для „искусственного интеллекта, ориентированного на данные“», Сара Браун, июнь 2022 г.
- insideAI News, «Провал Zillow Offers на сумму более 500 миллионов долларов: что пошло не так с моделями ИИ?», декабрь 2021 г.
- Стэнфордская высшая школа бизнеса, «Переворот: почему алгоритмическая система покупки жилья Zillow потерпела крах».
- Diagnostics (MDPI), «Выявление и корректировка ошибок обучения в моделях машинного обучения для диагностики рака кожи», 2022.
- VentureBeat, «Когда ИИ указывает на линейку, а не на опухоль».
- InfoQ, «QCon SF 2024: Почему проекты машинного обучения не доходят до стадии внедрения в производство», ноябрь 2024 г.
- Анализ чисел: «8 идей по настройке гиперпараметров, подкрепленных анализом данных».
Каушик Раджан Посмотреть все материалы от Каушика Раджана
Источник: towardsdatascience.com
