И что вы можете сделать, чтобы предотвратить это

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

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

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

Хорошая новость в том, что это не обязательно так.

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

Понять бизнес-проблему

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

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

Спросите, как они собираются использовать решение

Когда проблема будет четко определена, вы можете спросить, как бизнес планирует использовать то, что вы предоставите. Бывает - гораздо чаще, чем вы думаете, - бизнес-команды интересуются, как машинное обучение может помочь им решить проблему, но не задумываются о том, как они будут использовать результаты модели на практике. Ничего страшного, если они об этом не подумали; вот где вы вступаете в игру. Углубляйтесь в детали, чтобы помочь превратить то, что, вероятно, все еще является беспорядочной идеей в их головах, в продукт. Это не та возвышенность, на которой вы хотите, чтобы ваш проект Data Science умер; очень важно понять это правильно.

Определите результат

Мы надеемся, что точное знание того, как люди будут использовать результаты вашей модели, поможет вам определить результат. Слово результат происходит от разработки программного обеспечения и обычно относится к части программного обеспечения или приложения. Но это также относится к проектам Data Science. Результат проекта, будь то объект модели или приборная панель, должен быть ощутимым и измеримым. Таким образом, это требует тщательного определения.

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

Убедитесь, что то, что вам нужно, доступно

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

Какие данные нужны вашему проекту?

  • У вас уже есть эти данные или вам нужно их собрать? В зависимости от ответа расчетное время и требования могут сильно отличаться. Если вам нужно собрать деньги, вам нужно будет учесть это в своем предложении. Это может быть что-то столь же простое, как очистка веб-сайта, или столь же сложное, как разработка целого эксперимента.
  • Предположим, у вас уже есть данные. Это где-то доступно для вас? Это в пригодной для использования форме? Если ваши данные необработанные и хранятся где-то в озере данных, на приведение их в надлежащее состояние могут потребоваться недели или месяцы.
  • Даже если ваши данные находятся в приличной форме, достаточно ли у вас объема? Возможно, вам понадобятся данные из функции, которая была выпущена всего несколько месяцев назад. Сколько у вас данных? Насколько это представительно? Как долго вам нужно ждать, чтобы набралось достаточно?

Какие технологии нужны вашему проекту?

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

Напишите предложение об исследовании

Или план. Или кратко. Вы можете называть это как хотите, но записать все на бумаге. Наличие письменного резюме того, что вы обязуетесь сделать, - это победа для обеих сторон. Это выгодно для бизнес-команды, потому что им будет к чему обратиться (если вы сделаете это в течение 4–6 недель, каковы шансы, что они запомнят детали того, что вы обсуждали сегодня?). Но в основном это пойдет на пользу научному коллективу.

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

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

Объявить следующие шаги

Если ваш проект требует дополнительных шагов после завершения перед развертыванием, подумайте о том, чтобы перечислить их заранее. Например, вы должны объявить любой тест в предложении в этом разделе. Возможно, вам придется объяснить, почему эти шаги необходимы, прежде чем развертывать модель, но если вы сделаете это в начале, это сэкономит время в будущем. Кроме того, если потребуются какие-либо технологические изменения, у инженеров / команд бизнес-аналитики будет больше времени для их внедрения. Замкните их с самого начала, а не сбросьте на них бомбу в последнюю минуту. Все дело в планировании. И еще это вежливо.

Поддерживать связь

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

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

Наконец, если вы будете вовлекать их во все этапы проекта, это повысит вовлеченность и завоюет ваше доверие.

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