Чему я научился, возглавляя команды специалистов по искусственному интеллекту в различных отраслях
Делиться
В настоящее время я работаю ведущим специалистом по анализу данных, работая в самых разных отраслях: от небольших стартапов до международных корпораций, от технологических компаний, ориентированных на ИИ, до строго регулируемых банков. За годы работы я видел множество успешных инициатив в области ИИ и машинного обучения, но также и удивительно большое количество провалов. Причины неудач зачастую мало связаны с алгоритмами. Корневая причина почти всегда кроется в том, как организации подходят к использованию ИИ.
Это не контрольный список, руководство или список непреложных правил. Это обзор наиболее распространённых ошибок, с которыми я столкнулся, и некоторые размышления о том, почему они происходят, и как, по моему мнению, их можно избежать.
1. Отсутствие надежной базы данных
В отсутствие качественных или скудных данных, зачастую из-за низкой технической зрелости, проекты ИИ/МО обречены на провал. Это часто происходит, когда организации формируют команды по цифровому анализу данных/МО, не освоив прочные навыки работы с данными.
Однажды один менеджер сказал мне: «Электронные таблицы не приносят денег». Однако в большинстве компаний всё наоборот: электронные таблицы — единственный инструмент, способный увеличить прибыль. Не сделав этого, вы поддадитесь классическому афоризму машинного обучения: «мусор на входе — мусор на выходе».
Раньше я работал в региональной компании по доставке еды. Команда DS возлагала на себя заоблачные надежды: рекомендательные системы с глубоким обучением, искусственный интеллект и так далее. Но данные были в плачевном состоянии: слишком много устаревшей архитектуры, поэтому сеансы и бронирования не могли быть надёжно связаны из-за отсутствия единого ключевого идентификатора; идентификаторы блюд в ресторане менялись каждые две недели, поэтому невозможно было с уверенностью предположить, что именно заказывают клиенты. Из-за этого и многих других проблем каждый проект на 70% состоял из обходных путей. Не хватало времени и ресурсов для создания элегантных решений. Однако для некоторых из них ни один проект не дал результатов в течение года, потому что они были задуманы на основе данных, которым нельзя было доверять.
Вывод: инвестируйте в разработку данных и мониторинг качества данных до перехода на машинное обучение. Будьте проще. Для быстрого успеха и решения простых задач не обязательно нужны высококачественные данные, но для ИИ они определённо необходимы.
2. Отсутствие четкого бизнес-кейса
Машинное обучение обычно применяется из-за моды, а не для решения реальной проблемы, особенно учитывая ажиотаж вокруг программ магистратуры права и агентного ИИ. Компании разрабатывают сценарии использования вокруг технологии, а не наоборот, что в итоге приводит к созданию слишком сложных или избыточных решений.
Представьте себе ИИ-помощника в приложении для оплаты счетов за коммунальные услуги, где клиенты нажимают всего три кнопки, или ИИ-переводчика информационных панелей, когда решение должно делать их понятными. Быстрый поиск в Google примеров неудачных ИИ-помощников выявит множество таких случаев.
Одним из таких примеров в моей профессиональной деятельности был проект по созданию помощника для приложения поиска и бронирования ресторанов (скажем, агрегатора ресторанов). Магистратура была в тренде, и наверху царил страх упустить что-то важное. Они решили разработать безопасный сервис с низким приоритетом и чат-помощником, взаимодействующим с пользователем. Помощник предлагал рестораны по запросам вроде «покажите мне хорошие места со скидками», «хочу шикарный ужин с девушкой» или «найдите места, где можно с домашними животными».
Команда потратила год на его разработку: были разработаны сотни сценариев, настроены защитные барьеры, бэкенд сделан пуленепробиваемым. Но суть заключалась в том, что этот помощник не решал ни одной реальной проблемы пользователей. Очень небольшой процент пользователей даже пытался им воспользоваться, и среди них лишь статистически незначительное количество сеансов завершилось бронированием. Проект был заброшен на ранней стадии и не масштабировался на другие сервисы. Если бы команда начала с подтверждения варианта использования, а не с функций помощника, такого результата можно было бы избежать.
Вывод: Всегда начинайте с проблемы. Глубоко поймите её суть, оцените её значение в цифрах и только потом приступайте к разработке.
3. Гонка за сложностью прежде, чем освоить основы
Большинство сообществ переходят на последнюю версию, не останавливаясь на том, чтобы проверить, подойдут ли более простые методы. Универсального подхода не существует. Постепенный подход, начинающийся с простого и увеличивающийся по мере необходимости, почти всегда приводит к большей окупаемости инвестиций. Зачем усложнять задачу сверх необходимого, если достаточно линейной регрессии, предобученных моделей или простых эвристических методов? Простое начало даёт понимание: вы узнаёте о проблеме, понимаете, почему не добились успеха, и получаете надёжную основу для последующих итераций.
Я реализовал проект по разработке виджета для главной страницы многофункционального приложения, включающего в себя функцию заказа поездок. Идея была проста: предсказать, запустил ли пользователь приложение, чтобы заказать поездку, и если да, то предсказать, куда она, скорее всего, приедет, чтобы пользователь мог заказать её одним касанием. Руководство постановило, что решением должна быть нейронная сеть и ничто другое. Спустя четыре месяца мучительных доработок мы обнаружили, что прогнозы срабатывали удивительно хорошо примерно для 10% пассажиров с богатой историей заказов поездок. Даже для них прогнозы были ужасными. И проблема была наконец решена за одну ночь с помощью набора бизнес-правил. Месяцев напрасных усилий можно было бы избежать, если бы компания начала консервативно.
Вывод: сначала пройдитесь, а потом бегите. Используйте сложность как последнее средство, а не как отправную точку.
4. Разрыв связи между командами машинного обучения и бизнесом
В большинстве организаций наука о данных — это остров. Команды создают технически ошеломляющие решения, которые так и не выходят на рынок, потому что не решают нужных задач или потому что им не доверяют заинтересованные стороны. Обратное не лучше: когда руководители бизнеса пытаются диктовать технологическую разработку в полном объёме, устанавливают недостижимые ожидания и продвигают неэффективные решения, которые никто не может защитить. Решение — в равновесии. МО процветает, когда оно представляет собой совместную работу экспертов в предметной области, инженеров и лиц, принимающих решения.
Чаще всего я сталкивался с этим в крупных компаниях, не специализирующихся на IT. Они понимают, что у ИИ/МО огромный потенциал, и создают «лаборатории ИИ» или центры передового опыта. Проблема в том, что эти лаборатории часто работают в полной изоляции от бизнеса, и их решения редко внедряются. Я работал в крупном банке, где была именно такая лаборатория. Там работали высококвалифицированные специалисты, но они никогда не встречались с представителями бизнеса. Хуже того, лаборатория была создана как отдельное дочернее предприятие, и обмен данными был невозможен. Компания не была особенно заинтересована в работе лаборатории, которая в конечном итоге превратилась в исследовательские работы для учёных, но не в реальные процессы компании.
Вывод: Поддерживай тесную координацию инициатив МО с потребностями бизнеса. Взаимодействуй с заинтересованными сторонами на ранних этапах, регулярно взаимодействуй и взаимодействуй с ними, даже если это замедляет разработку.
5. Игнорирование MLOps
Задания cron и громоздкие скрипты будут работать в небольших масштабах. Однако по мере роста компании это прямой путь к катастрофе. Без MLOps небольшие изменения требуют привлечения оригинальных разработчиков на каждом этапе, и системы приходится полностью переписывать снова и снова.
Ранние инвестиции в MLOps окупаются экспоненциально. Речь идёт не только о технологиях, но и о стабильной, масштабируемой и устойчивой культуре машинного обучения.
Ранние инвестиции в MLOps окупаются экспоненциально. Речь идёт не только о технологиях, но и о создании культуры надёжного, масштабируемого и удобного в обслуживании машинного обучения. Не позволяйте хаосу поглотить вас. Разработайте эффективные процессы, платформы и обучение до того, как проекты машинного обучения пойдут вразнос.
Я работал в дочерней телекоммуникационной компании, занимавшейся рекламными технологиями (AdTech). Платформа обслуживала интернет-рекламу и была крупнейшим источником дохода компании. Поскольку она была новой (всего год), решение для машинного обучения (ML) было крайне ненадёжным. Модели просто оборачивались в C++ и вставлялись в код продукта одним инженером. Интеграция выполнялась только в присутствии этого инженера, модели никогда не отслеживались, и после ухода автора никто не имел ни малейшего представления о том, как они работают. Если бы дежурный инженер тоже ушёл, вся платформа была бы безвозвратно закрыта. Подобных проблем можно было бы избежать, используя грамотные MLO-операторы.
6. Отсутствие A/B-тестирования
Некоторые компании избегают A/B-тестирования из-за его сложности и предпочитают бэктестинг или интуицию. Это позволяет плохим моделям попасть в продакшн. Без платформы для тестирования невозможно узнать, какие модели действительно работают. Для итеративного совершенствования, особенно в больших масштабах, необходимы надлежащие экспериментальные фреймворки.
Обычно сдерживает внедрение ощущение сложности. Однако простой и отлаженный процесс A/B-тестирования может эффективно работать на начальном этапе и не требует значительных первоначальных вложений. Согласованность действий и обучение — вот важнейшие факторы.
В моём случае, без надёжного способа измерения влияния на пользователей, всё зависит от того, насколько хорошо менеджер умеет его продавать. Удачные предложения получают финансирование, горячо защищаются и иногда остаются актуальными даже при снижении показателей. Метрики манипулируются простым сравнением показателей до и после запуска. Если они растут, то проект успешен, хотя, по иронии судьбы, это был общий восходящий тренд. В растущих компаниях миллионы неэффективных проектов скрываются за общим ростом, поскольку отсутствует A/B-тестирование, позволяющее постоянно отделять успехи от неудач.
Вывод: Создавайте возможности для экспериментов на ранних этапах. Необходимо тестировать крупные развёртывания и давать командам возможность правильно интерпретировать результаты.
7. Недостаточно подготовленный менеджмент
Недостаточно подготовленные руководители МО могут неверно интерпретировать метрики, результаты экспериментов и совершать стратегические ошибки. Обучение лиц, принимающих решения, так же важно, как и обучение инженерных команд.
Когда-то я работал с командой, у которой были все необходимые технологии, а также мощные многозадачные циклы (MLOps) и A/B-тестирование. Но менеджеры не знали, как ими пользоваться. Они использовали неправильные статистические тесты, прекращали эксперименты спустя день после достижения «статистической значимости» (обычно при слишком малом количестве наблюдений) и запускали функции без измеримого эффекта. В результате многие запуски имели отрицательный эффект. Сами менеджеры были не плохими людьми, они просто не понимали, как использовать свои инструменты.
8. Несоответствующие метрики
Хотя организации, занимающиеся МО/ЦР, должны быть ориентированы на бизнес, это не означает, что им необходимо обладать бизнес-интуицией. Специалисты по МО также будут ориентироваться на любые предоставленные им метрики, если считают их верными. Если цели МО не совпадают с целями компании, результат будет искаженным. Например, если компания стремится к прибыльности, а цель МО — максимизация конверсии новых пользователей, они будут максимизировать нерентабельный рост за счет привлечения пользователей с плохой юнит-экономикой, которые никогда не вернутся.
Это болевая точка для многих компаний. Компания по доставке еды стремилась к росту. Руководство заметило низкую конверсию новых пользователей, которая сдерживала рост выручки компании. Команде DS было поручено решить эту проблему с помощью персонализации и улучшения клиентского опыта. Настоящая проблема заключалась в удержании: конвертированные пользователи не возвращались. Вместо удержания команда сосредоточилась на конверсии, фактически наливая воду в протекающее ведро. Несмотря на то, что конверсия выросла, это не привело к устойчивому росту. Эти ошибки не привязаны к размеру бизнеса или отрасли — это универсальные ошибки.
Тем не менее, их можно предотвратить. ИИ и МО действительно работают, если они разработаны на основе разумных принципов, предназначены для решения реальных проблем и грамотно внедрены в бизнес. При наличии всех необходимых условий ИИ и МО превращаются в прорывные технологии, способные кардинально изменить целые компании.
Вывод: согласуйте показатели МО с реальными бизнес-целями. Боритесь с причинами, а не с симптомами. Цените долгосрочную эффективность, а не краткосрочные показатели.
Заключение
Путь к успеху в области искусственного интеллекта и машинного обучения (ИИ/МО) зависит не столько от передовых алгоритмов, сколько от организационной зрелости. Закономерности очевидны: неудачи возникают из-за поспешного внедрения сложных задач, несогласованности стимулов и игнорирования базовой инфраструктуры. Успех требует терпения, дисциплины и готовности начать с малого.
Хорошая новость заключается в том, что всех этих ошибок можно полностью избежать. Компании, которые сначала создают инфраструктуру данных, поддерживают тесное взаимодействие между техническими и бизнес-подразделениями и не отвлекаются на модные тенденции, обнаружат, что ИИ/МО выполняет именно то, что обещает. Технология действительно работает, но она должна иметь прочный фундамент.
Если и есть один принцип, объединяющий всё это, то он таков: ИИ/МО — это инструмент, а не конечный пункт. Начните с проблемы, определите потребность, развивайтесь итеративно и всегда измеряйте. Компании, которые подходят к этому с таким подходом, не только не терпят неудач. Напротив, они создают долгосрочные конкурентные преимущества, которые со временем только усугубляются.
Будущее принадлежит не компаниям с новейшими моделями, а компаниям, обладающим дисциплиной разумного их применения.
Источник: towardsdatascience.com
