tl;dr

CICD относится к набору методологий разработки программного обеспечения, направленных на увеличение частоты итераций в разработке программного обеспечения. CICD был одним из основных факторов повышения производительности при разработке программного обеспечения за последние 20–30 лет. Разработка приложений машинного обучения также выигрывает от CICD, но внедрение происходит относительно медленно. Адаптация CICD к разработке приложений машинного обучения может оказаться сложной задачей, но организации должны упорствовать, потому что вознаграждение велико.

Старые добрые времена

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

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

Парадигмы

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

Итак, что такое CICD?

Основная идея CICD состоит в том, чтобы: а) сделать изменения настолько управляемыми и б) инфраструктура тестирования настолько хороша, чтобы тестирование и выпуск программного обеспечения могли происходить автоматически без больших церемоний, таких как разработка плана тестирования или обсуждение результатов тестирования. Скорее, выпуск изменения в программном обеспечении должен быть простым нажатием кнопки. Если изменение хорошее, оно автоматически развертывается. Если изменение плохое, автоматические тесты его обнаружат, и развертывание будет прервано.

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

Почему CICD так важен?

Центральным и наиболее важным нововведением, произошедшим за последние 20–30 лет разработки программного обеспечения, стала идея частых итераций. Книга Accelerate резюмирует этот момент в краткой таблице:

tl;dr: команды, которые часто внедряют изменения, продуктивны, а команды, которые этого не делают, — нет.

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

Тот же принцип был выделен как ключевой фактор в разработке продукта и бизнеса (минимально жизнеспособный продукт, бережливый стартап и т. д.). Джефф Безос отметил этот принцип в своей цитате:

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

Почему частые повторения так важны?

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

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

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

МЛ отстает

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

В «исследовании» цель состоит в том, чтобы найти новое знание. Автоматизация тестов (CICD) не так естественна, потому что ожидается, что каждый элемент знаний будет новым — и, следовательно, требует нового теста.

Тесно связанная концепция «Разработка через тестирование (TDD)» также осталась вне фокуса, возможно, потому, что ожидается, что «исследование» будет «открытым» — то есть, что мы должны открывать новые вопросы по ходу, а не знать, что спросить заранее.

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

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

Большая часть разработки ML на самом деле является разработкой, а не исследованием

Хотя очевидно, что есть место для исследований ML, большая часть разработки ML на самом деле является в основном «разработкой», а не исследованиями.

Разница между исследованиями и разработками заключается в следующем:
— Исследования успешны, когда получено новое знание
— Разработка успешна, когда решение решает проблему

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

Преимущества развития от CICD

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

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

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

Как сделать CICD с приложениями ML

Как и в обычных системах, важнейшим компонентом CICD для приложений машинного обучения является тестирование. Среди них наиболее важным является так называемый «онлайн-тест» или «A/B-тест», в ходе которого приложение машинного обучения развертывается в реальном мире и проверяется на соответствие существующему решению.

Во многих организациях с A/B-тестированием связана большая суета — подобно тому, как тестирование программного обеспечения было суетой в 2000-х. Разрабатывается подробный план A/B-тестирования, и часто пишется специальное программное обеспечение для анализа. Подверженная ошибкам ручная работа может привести к ошибкам, для устранения которых необходимо перезапустить A/B-тесты. Вся эта сложность приводит к тому, что A/B-тесты обходятся дорого и проводятся редко (например, раз в 6 месяцев). Если ваши A/B-тесты звучат так, это будет первая проблема, которую нужно решить.

Вместо этого вы хотите, чтобы A/B-тесты были максимально автоматизированы. Простое нажатие кнопки должно запускать A/B-тест, отслеживать его, и отчет должен автоматически генерироваться после завершения теста. Часть кода должна автоматически проверять, должна ли быть выпущена новая версия программного обеспечения, и выпускать программное обеспечение.

История повторяется

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

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

Самым сложным элементом может быть перевод бизнес-целей в измеримые критерии успеха (особенно определение общей оценочной метрики). Однако ощущение неосуществимости в первую очередь связано с пробелом в ноу-хау — определить успех заранее сложно в приложениях ML, но обычно это вполне возможно.

Заключение

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