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

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

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

Вместо вступления пару слов про отличия

На самом деле основная специфика ML разработки заключается в том, что здесь рулит не код, а данные. Есть конечно еще специфика, что алгоритмы ML мы не пишем, а только используем (обучаем), но это опять же во многом про данные. А данные у нас что? Правильно - данные это в первую очередь стратегический актив предприятия. И по большому счету ML - это ни что иное как процесс монетизации этого самого стратегического актива. А многие ли готовы отдать монетизацию своего актива “на сторону”? 

Пришла в голову забавная аналогия ... есть известная фраза - "Данные это нефть 21 века". Так если продолжать эту аналогию, то ML - это нефтеперерабатывающий завод. И конечно можно найти нефтедобытчиков, которые продают сырую нефть, но большая часть все-таки ее перерабатывает и продает уже переработанный продукт.

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

И может показаться, что при таких ограничениях остается только воскликнуть “ну тогда да, конечно, только инхаус!”. И многие так и поступают. Но этот вариант достаточно скучный и давайте думать, что в жизни всегда есть место подвигу, а в ML - аутсорсингу. Осталось определить где, как и когда.

Вариант 1 - когда ничего нет

Итак, с чего начинается ML в бизнесе, где его никогда не было? Бывает, что с картинки почти что в букваре, но чаще всего с гипотезы или идеи, которую кто-то подсказал. И в этот момент времени, по большому счету, без разницы кто докажет эту гипотезу - кто-то внутренний или внешний. Ведь речь пока идет только о том, чтобы доказать теорему, так что ничего не мешает привлечь варягов для доказательства. Оно даже будет быстрее и логичнее, главное не ошибиться с "варягами" (но подробнее о выборе подрядчика ниже).

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

Так что место номер раз для аутсорсинга - это первые шаги ML в конкретной компании. Проверка гипотезы или можно обобщить и сказать по-умному - стадия PoC (Proof of Concept). В этом сценарии разделение ответственности в работе над моделью может быть следующим (практически раскрашиваем CRISP-DM):

• Этап 0 - Идея или гипотеза. В идеальной картине мира она возникает у бизнеса. В утопичной - еще и с критериями успеха.

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

• Этап 2 - Обучение модели. Основная работа подрядчика. На самом деле это цикл работ по формированию признаков, обучению и тестированию модели. Итерации идут до тех пор пока целевая точность модели не будет достигнута.

• Этап 3 - бизнес тестирование модели и оценка результатов. Проводится совместно бизнес-заказчиком и подрядчиком. Если к этому моменту уже есть собственная экспертиза в ML, то оценка идет “на троих”.

• Этап 4 - адаптация и внедрение модели в продуктив. Вот на этом этапе ключевая развилка:

  • Либо к этому моменту появляется собственная ML экспертиза и тогда процесс в ее зоне ответственности

  • Либо модель поставляется как сервис и работоспособность обеспечивает подрядчик.

И в зависимости от выбранного пути определяется дальнейшая судьба аутсорса - если собственной экспертизы по ML не появилось и бизнес пошел по пути DSaaS (DataScience as a Service), то дальнейшее место аутсорса совершенно понятно. Скажу честно - на мой взгляд сценарий возможен только в случае если применение машинного обучения в компании ограничено и не имеет перспектив за пределами одного-двух кейсов. Ну а данные … наверное данные в такой компании не слишком уж дорогой или не слишком стратегический актив.

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

Вариант 2 - когда уже что-то есть

Поехали дальше. Если экспертиза по ML уже есть, то осталось ли место аутсорсу? Мой ответ - однозначно да. И место ему в сложных кейсах, когда все “быстрые победы” уже достигнуты, а все остальное требует серьезной экспертизы. Причем кейсы могут быть сложные не обязательно с точки зрения математики (хотя не без этого), сколько с точки зрения именно бизнеса. Кстати если кто считает, что внедрение ML модели в жизнь это просто - значит вам везло. Это ни разу не просто и к внедрению любой модели лучше относится как к отдельному проекту. Но подробнее об этом я лучше порассуждаю потом, благодарная тема. Так вот когда нужно создать новый бизнес-процесс, частью которого будет новая модель, или требуется модернизировать существующие процессы, чтобы модель была максимально эффективной, то зачастую проще и правильнее привлечь внешнего подрядчика, который сможет:

• Показать потенциальный эффект от комплексного подхода

• Поделиться примерами подобных внедрений и эффектов (в идеале организовать референс визит)

• Создать модель

• Разработать, описать и помочь внедрить целевой бизнес-процесс

• Поставить правильные метрики контроля и наладить мониторинг

• Оценить полученный эффект

Соответственно в части ML разделение зон ответственности будет примерно тем же самым, что и в первом случае. Но поскольку создание модели это далеко не самая сложная часть, то самое интересное и основное отличие - это бизнес-экспертиза и проектный подход.

И лирическое отступление

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

И на нем наглядно видно, что подрядчиков можно поделить условно на:

• Тех кто не представляет интереса - ни математики ни бизнеса, зачем такие нужны?

• Математики-Академики - полезны, для специфических задач

• Бизнес-консультанты - могут быть полезны, при условии, что с математикой вы их подстрахуете (или сделаете за них)

• ТОП-экспертиза - это, конечно, классно и универсально, но очень дорого. 

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

• ТОП-чик это дорого. Окупит ли ожидаемый эффект привлечение компанию такого уровня?

• Недостающую часть экспертизы (бизнес или математическую) вам придется закрывать собой, выбирайте что у вас сильнее развито.

• Но не питайте иллюзий - недостающую бизнес-экспертизу для случая внедрения нового бизнес-процесса вы скорее всего не закроете. Иначе зачем вам помощники?

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

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

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

Выводы

В общем в сухом остатке, традиционно варианта три - два крайних и смешанный:

1. Полностью инхаус - традиционный путь, с известными плюсами и минусами. Но в части ML стоит оценить - а не упускаете ли вы сложные сценарии из рассмотрения просто потому, что текущая команда не знает “что так можно было”.

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

3. Смешанные сценарии, в частности:

   1. Для первых шагов с ML, когда работа подрядчика закроет почти полный цикл разработки

   2. В дальнейшем - PoC силами аутсорса, адаптация и поддержка успешных кейсов - своими силами

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