Этот пост оказался длиннее, чем ожидалось. Наполовину разглагольствование, наполовину практичное — полностью честное. Делится на пять частей, а именно:

  • Введение
  • Используйте итерации,
  • Усердно автоматизируйте все и поддерживайте то, что осталось,
  • Так как же на самом деле постоянно развертывать обученную модель машинного обучения??
  • Окей, мы только что разобрались с этим дерьмом развертывания! Когда переучивать этого зверя?

Введение

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

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

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

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

Используйте итерации

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

В академических кругах вы нечасто получаете обратную связь более одного раза; то есть когда истекает крайний срок, а обратная связь либо пройдена, либо не пройдена. Часто крайних сроков не больше, чем крайний срок, и первая работа в сфере ИТ часто является первым знакомством с мифической аббревиатурой в литературе, которая называется PM, PD, PO, и т.д. al., который по какой-то непонятной причине ставит 20 крайних сроков за два месяца, потому что «скорость и проскальзывание будут представлены в следующем квартале», что бы это ни значило.

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

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

  • Религиозно используйте спринты (в DS немного по-другому по длине, чем в agile для разработки программного обеспечения, чтобы вытянуть цифру из ниоткуда, используйте 2 или 3 недели),
  • Спринты начинаются по средам (все равно половина компании болеет в понедельник, и никто не хочет представлять результат весны в пятницу днем, когда TGIF вот-вот стартует),
  • Каждый раз, когда вы заканчиваете весну (среду, верно?), наступает время развертывания, вау! (короче говоря, вы не можете решить, развернуть или нет в конце спринта, вы можете только что развернуть),
  • Остальное — обычные вещи, TDD или что-то подобное, покрытие юнит-тестами, непрерывная интеграция и так далее.

Суть здесь в том, что для джуниоров не проблема копнуть глубоко в то, во что сейчас копаться не стоит, и лидер, который может сказать: «Ну, это государственная религия — жить спринтами, так что давай! давайте покажем им, что у нас есть» чаще всего позволяет компании пожинать плоды свободного духа инноваций.

Ревностно автоматизируйте все и обслуживайте то, что осталось

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

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

  • Написание собственных вспомогательных методов для стекирования вместо использования одной из уже доступных библиотек на github.
  • Оптимизация вашего собственного волшебства перетаскивания для развертывания новой модели на этапе предварительной подготовки, чтобы побить командный рекорд в 27 секунд, вместо использования системы оркестровки (Ansible для небольших компаний, просто… пока пропустите Chef и Puppet, это обычно считается, что это кувалда, которую люди имеют в виду, когда говорят: «используйте кувалду, чтобы расколоть орех»).
  • Календарное напоминание каждое утро и после обеда, чтобы найти нечувствительные к регистру совпадения слова «исключение» (хотя, очевидно, не в дни похмелья. И не по понедельникам, черт возьми!).

Избегайте:

  • (как младший) Никогда не разрабатывайте то, что, по вашему мнению, вам нужно, прежде чем рыскать по github,
  • (как лидер) Организуйте забастовку со своей командой, если начальство попытается помешать вам тратить время на автоматизацию задач, которые можно автоматизировать (в разумных пределах),
  • Воспользуйтесь чертовой службой непрерывной интеграции и доставки! который (по порядку) на коммите запускает все тесты (у всех у нас покрытие 90%+, амарите?), собирает артефакт (если тесты прошли успешно) и развертывает новую сборку в среде разработки и, наконец, громко кричит всем, что новое слияние прошло испытания и шампанское подавать.

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

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

Так как же на самом деле постоянно развертывать обученную модель машинного обучения??

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

  • Возьмите свои данные,
  • Сделай то, что называется, как сказано в книге,
  • Поиск по сетке на AWS во время обеда и дня 99% ACC!,
  • Передайте это оперативникам и начните бросать тень, уходя пораньше.

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

  • «тааак, мне скоро переобучить модель?»
  • «Как я могу точно знать, что эта переобученная модель работает лучше, чем предыдущая?»
  • «О, количество жалоб клиентов в час в безлунную ночь недели с доской для спиритических сеансов истекло? Кто спас последнюю обученную модель? Ах да, это два гигабайта, так что не так-то просто их удержать, да… да…»

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

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

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

  • Независимо от типа модели, которую вы запускаете в производство, разверните три их дубликата за одним обратным прокси-сервером, который балансирует нагрузку на входящие запросы,
  • Если возможно, поместите этих щенков на разные машины и назовите их, чтобы вы всегда могли ссылаться на один и тот же экземпляр на определенной машине. Назовем одну из них «канареечной» моделью, а две другие — просто «моделями» с избыточностью,
  • Перед развертыванием ваш сценарий должен сначала вывести одну из «моделей» из балансировки нагрузки обратного прокси-сервера,
  • Когда он выйдет из основной коллекции (просто используйте какой-нибудь асинхронный опрос в ansible для запуска, когда он не работает), закройте его и разверните там свою новую сборку,
  • Следующий этап развёртывания — затаить дыхание и прислушаться к ошибкам (которые, если он увидит, должен заставить сработать пожарную тревогу и откатить ноду). Если ошибок не обнаружено, перейдите к следующему этапу, который добавляет узел обратно в балансировщик нагрузки.
  • Здесь происходит некоторое волшебство в зависимости от того, насколько сложной вы хотите, чтобы была процедура развертывания в милом маленьком Ansible (но на самом деле вы могли бы просто иметь два плейбука Ansible для разделения этапов); постепенно перенаправлять трафик на новый узел и отслеживать некоторую предопределенную метрику сбоя, которая в случае выше, чем базовый узел, откат, в противном случае развертывание на втором узле,
  • Каждый раз, когда вы выполняете (автоматизированное) развертывание, вы развертываете только «модели» (по одной на случай, если она не работает по какой-то непонятной причине; другая все равно будет принимать все запросы от обратного прокси-сервера, пока вы откат).

Канарейка (пока что вы развернули только две из трех резервных копий) — ваша резервная копия; вы можете оставаться в восходящем пуле балансировщика нагрузки в течение дня или двух после развертывания, чтобы провести довольно надежное A/B-тестирование гетто (если вы можете отслеживать запросы на узел обратно к идентификатору клиента, вы можете сравнить любые результаты база данных может разглашаться под пытками, так как 33% запросов будут по старой модели и 66% по новой; день говорил вам, что старая модель приносила больше дохода? тогда откат).

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

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

Итак, мы только что разобрались с этим неудачным развертыванием! Когда переучивать этого зверя?

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

Допустим, вы работаете в Amazon и отвечаете за их модель совместной фильтрации, чтобы убедиться, что продукты, показанные в разделе «вам также может быть интересно это», который, вероятно, основан на том, что вы недавно просматривали и купили, а также то, что просматривали и покупали похожие на вас пользователи. Эти просмотры и истории заказов постоянно обновляются. Если вы внедрили рекомендации по продукту, используя аккуратную матричную факторизацию или какую-то сверхсложную работу с искровым потоком с их чередующейся реализацией метода наименьших квадратов; как, черт возьми, вы обновляете скрытое пространство, ответственное за предоставление своевременных рекомендаций, когда эти надоедливые клиенты продолжают покупать продукты все время?!

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

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

  • Запустите задание cron, которое каждый день в течение минимального периода активности принимает все новые каналы активности и пересчитывает матричную факторизацию,
  • После этого запускается сценарий развертывания, который:
  • Сериализирует матрицы, загружает в HDFS (или аналогичный), а затем:
  • Этап развертывания запускает загрузку новой сериализованной модели из hdfs на каждый обновляемый узел (помните «модели», которые были двумя ранее?),
  • Модель канарейки развертывается с этой версией на следующий день (т. е. у канарейки всегда на один день больше «проскальзывания»).

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

Надеюсь, у вас хватило сил дойти до этого места; если так, то я благодарю вас. Не стесняйтесь комментировать или оставлять вопрос!