За прошедшие годы сообщество разработчиков программного обеспечения пришло к общему мнению о том, что программное обеспечение следует разрабатывать с итеративным жизненным циклом. Преобладающие методологии, такие как Scrum (Agile) и Lean, поддерживают эту концепцию. Суть итеративного жизненного цикла:

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

Прежде чем прийти к такому консенсусу, многие команды разработчиков программного обеспечения совершали такие ошибки, как:

  1. Внедрял систему в течение нескольких месяцев и удивлялся, что пользователь не находит многие функции полезными - требования не были четко определены.
  2. Значительно превышение требуемой масштабируемости системы.

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

Почему итеративный жизненный цикл?

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

Итерационный процесс разработки можно адаптировать к A.I. разработка с использованием структуры, описанной на рисунке ниже. В этой и следующих публикациях я подробно остановлюсь на каждом из следующих блоков, составляющих жизненный цикл, а также на стандартах, которые я рекомендую применять в каждом из этих блоков. .

Важность стандартов для итеративности в искусственном интеллекте.

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

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

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

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

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

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

Как четко сформулировал Мартин Фаулер в своем недавнем сообщении в блоге: Стоит ли высокое качество программного обеспечения своих затрат?:

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

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

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

Цитируемое сообщение в блоге посвящено аспектам «внутреннего качества» программной инженерии.

То же понятие и важность «внутреннего качества» применимо ко многим другим аспектам проекта машинного обучения. В качестве примеров:

  1. Команды машинного обучения очень часто не документируют точные данные (или код подготовки данных), которые использовались для достижения результатов, которые были развернуты в предыдущих итерациях.
  2. Очень часто не документируют точный код \ гиперпараметры, которые использовались для обучения модели, развернутой в производственной среде.
  3. И даже стандарты программной инженерии - не менее важны для проектов машинного обучения, чем в «традиционном программном обеспечении». Проекты машинного обучения часто содержат значительные части дублированного кода, жестко запрограммированных значений, мертвых флагов и т. Д. Они были помещены туда, чтобы оптимизировать время, необходимое для завершения текущей итерации исследования (что во многих случаях может быть допустимым подходом), но люди переходили к следующей исследовательской задаче, не выплачивая долга.

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

  1. Метод подготовки данных изобретен заново (пример 1), или -
  2. Недели работы посвящены повторному открытию гиперпараметров, которые использовались для создания модели из данных (пример 2), или -
  3. Две недели безрезультатной работы потрачены на то, чтобы обнаружить, что жестко запрограммированное значение все провалило (пример 3).

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

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

Соавтором этой серии публикаций является Идан Басюк.