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

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

Процесс обработки данных

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

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

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

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

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

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

Вычислительные ноутбуки для исследований

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

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

Блокноты хорошо поддерживают итерацию и исследование во многих отношениях:

  • Они обеспечивают быструю обратную связь, позволяя пользователям постепенно писать и выполнять короткие фрагменты кода, подобно интерфейсам REPL для быстрого прототипирования на языках программирования.
  • Они обеспечивают инкрементные вычисления, когда пользователи могут изменять и повторно выполнять ячейки, не запуская всю записную книжку, что позволяет пользователям быстро исследовать альтернативы.
  • Они быстрые и простые в использовании. Легко копировать ячейки для сравнения альтернатив без необходимости вкладывать средства в предварительную абстракцию.
  • Они интегрируют визуальную обратную связь, показывая полученные цифры и таблицы непосредственно в блокноте во время разработки.
  • Интеграция результатов с кодом и документацией упрощает обмен кодом и результатами.

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

Траектории науки о данных

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

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

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

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

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

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

Процесс разработки программного обеспечения

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

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

Точно так же процесс включает в себя множество других действий, не связанных с кодированием, в проекте, которые полезны для своевременного выпуска качественного продукта в рамках бюджета, включая такие действия, как (1) проверка проектов и кода, (2) ведение списка известные проблемы в системе отслеживания проблем, (3) использование контроля версий, (4) планирование и мониторинг хода выполнения различных частей проекта и (5) ежедневные совещания по статусу и прогрессу. Хотя многие из этих действий требуют некоторых предварительных инвестиций, их использование обещает избежать последующих затрат, таких как отсутствие долго не обнаруженных проблем проектирования, выпуск программного обеспечения с забытыми ошибками, невозможность восстановить прошлые версии при необходимости отката изменений, обнаружение позднего обнаружения задержек. к проекту, а члены команды случайно выполняют лишнюю или конкурирующую работу. Отсутствие процесса может привести к тому, что разработчики впадут в режим выживания, когда что-то пойдет не так, когда они сосредотачиваются на своих собственных результатах, но игнорируют работу по интеграции и взаимодействие с другими, что приводит к еще большему количеству проблем в будущем.

Модели процессов: между планированием и итерацией

Водопадная модель. Самой ранней попыткой структурировать разработку и поощрить ранний акцент на требованиях и дизайне была водопадная модель, описывающая разработку как очевидную последовательность шагов (мало чем отличающуюся от конвейерных моделей в науке о данных). . Ключевой вывод заключался в том, что некоторая строгость в процессе полезна — например, обеспечение того, чтобы требования были установлены до написания кода, чтобы дизайн соответствовал требованиям и чтобы тестирование выполнялось перед выпуском. Даже первые версии модели водопада в оригинальной статье Ройса 1970 года Управление разработкой больших программных систем предполагали некоторые циклы обратной связи и итерации, когда при необходимости можно было вернуться от проектирования к требованиям, и, возможно, нужно было пройти через водопад дважды, один раз для прототипа и один раз для реальной системы. Несмотря на то, что в наши дни его часто считают устаревшим и слишком негибким, чтобы справляться с изменяющимися требованиями во многих проектах, ключевой посыл думать и планировать, прежде чем внедрять сохранился.

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

Методы Agile. Еще один фактор, который заставляет настаивать на повторении, — это осознание того, что требования едва ли фиксированы и полностью известны заранее. Клиенты могут не знать, чего они хотят, пока не увидят первый прототип, а к моменту завершения проекта у клиентов уже могут быть другие потребности. Гибкие методы подталкивают к частым итерациям и перепланированию самоорганизующимися командами, которые тесно сотрудничают с клиентами. Обратите внимание, что гибкие методы не отказываются от разработки требований и проектирования, но интегрируют их в постоянный итеративный цикл разработки с постоянным планированием и перепланированием. Например, типичным темпом является разработка добавочных прототипов программного обеспечения за 2-недельные или 30-дневные спринты, ежедневная синхронизация между всеми членами команды на собраниях и возвращение к планированию после каждого спринта. В процессе работа расширяется и изменяется по мере необходимости по мере добавления дополнительных функций или изменения требований.

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

Напряженность между наукой о данных и процессами разработки программного обеспечения

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

Хотя итеративный процесс обработки данных может на первый взгляд показаться похожим на итерацию в более итеративных процессах разработки, они принципиально отличаются:

  • Итерация в спиральной модели процесса направлена ​​на раннее определение осуществимости путем разработки сначала наиболее рискованной части, прежде чем приступать к менее рискованным частям. При разработке моделей машинного обучения работу обычно нелегко разделить на опасные и менее рискованные части. Можно попытаться установить осуществимость на раннем этапе, но часто неясно, достижим ли желаемый уровень точности для задачи прогнозирования в рамках проекта с ограниченным объемом.
  • Итерация в гибкой разработке отчасти направлена ​​на то, чтобы быть гибким, чтобы прояснить изначально расплывчатые требования и реагировать на меняющиеся требования. При разработке моделей машинного обучения общая цель модели обычно ясна и не сильно меняется, но необходима итерация, чтобы определить, как достичь этой цели. Если первоначальная цель не может быть достигнута или обнаруживаются новые возможности, требования к системе и модели могут со временем измениться.
  • В программной инженерии проблема обычно декомпозируется, чтобы обеспечить возможность стратегии «разделяй и властвуй» для независимого прогресса в различных частях проблемы, часто обеспечивая параллельную разработку с участием нескольких членов команды. Проблемы машинного обучения обычно сложнее разложить на задачи, которые можно решить самостоятельно.
  • Итерации в разработке моделей машинного обучения носят исследовательский характер, и многие итерации приводят к тупикам. За пределами экспериментальных проектов тупики менее распространены в традиционной разработке программного обеспечения. Экспериментирование в поисках решения не является чем-то необычным, но в большинстве случаев это не основная причина итераций.

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

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

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

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

Интегрированные процессы для систем с поддержкой ИИ

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

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

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

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

Разработка «сначала модель» и «сначала система»

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

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

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

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

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

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

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

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

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

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

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

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

Примеры

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

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

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

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

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

Краткое содержание

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

Дальнейшие чтения

Как и все главы, этот текст выпущен под лицензией Creative Commons 4.0 BY-SA.