Как 94% точности модели привели к провалу бизнеса

Когда модель-центричная разработка подводит

Традиционная разработка ML-систем концентрируется исключительно на самой модели. Команды тратят месяцы на совершенствование алгоритмов, настройку гиперпараметров и улучшение метрик точности. Стандартный рабочий процесс выглядит так: собрали данные, обучили модель, оценили производительность, запустили в продакшн.

Успех измеряется техническими показателями вроде F1-score (комбинация точности и полноты) и AUC (площадь под кривой). Именно так работали мы. Все, включая руководство, фокусировались на том, насколько хорошей мы можем сделать рекомендательную систему с точки зрения метрик точности, которые мы считали отражением качества рекомендаций для клиентов.

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

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

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

Для практических рекомендаций по построению ML-систем, ориентированных на бизнес-результат, посетите AI Projects.

Продуктовое мышление переворачивает подход

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

Эта смена парадигмы меняет все в подходе к ML-разработке. Ваши главные вопросы становятся такими:

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

Возьмем пример системы рекомендаций контента. Модель-центричный подход фокусируется на показателях кликабельности и точности рекомендаций.

Продукт-центричный подход задает более глубокие вопросы:

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

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

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

Полный жизненный цикл продукта

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

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

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

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

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

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

Измерение успеха за пределами точности

Разница была поразительной. Удержание клиентов выросло на 15%, фронтлайн-команды сообщили о большей уверенности в использовании системы, а внедрение взлетело, потому что инструмент решал правильные проблемы.

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

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

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

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

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

Непрерывная итерация и обратная связь

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

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

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

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

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

Узнайте больше о построении пользователь-ориентированных ML-систем на AI Projects.

Построение кросс-функциональных команд

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

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

Каждый приносит важные перспективы, которые упускают чисто технические команды.

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

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

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

Практические шаги внедрения

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

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

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

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

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

Выводы

Переход от модель-центричного к продукт-центричному мышлению - это не просто изменение процессов. Это фундаментальное переосмысление того, что значит строить успешные ML-системы. Когда вы воспринимаете свои модели как продукты, вы создаете системы, которые приносят реальную ценность людям, которые их используют.

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