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

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

Каждая система отличается

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

  • Компонент персонализированных рекомендаций для службы потоковой передачи музыки может развернуть модель как часть микрослужбы более крупной системы, состоящей из множества компонентов, не связанных с машинным обучением. Действия пользователей в сервисе предоставляют множество данных для обучения модели и наблюдения за тем, насколько хорошо рекомендации удерживают пользователей. Чтобы обслуживать большое количество запросов рекомендаций с разумным временем отклика, каждый из которых относительно дешев для вычислений, службы рекомендаций могут размещаться во многих экземплярах в некоторой облачной инфраструктуре. Сама модель рекомендаций будет регулярно обновляться без участия человека. Нахождение в онлайн-среде с миллионами пользователей позволяет легко экспериментировать с различными моделями. Если компонент рекомендации дает сбой, его легко вместо этого предоставить в качестве резервной копии кэшированных предыдущих рекомендаций или неперсонализированных глобальных 10 лучших рекомендаций.
  • Служба транскрипции из введения также будет размещена в облачной среде. Каждый пользователь лишь изредка взаимодействует с системой через нерегулярные промежутки времени, загружая аудиофайлы по мере необходимости. Здесь используемая модель велика, а вывод модели для фактической расшифровки аудио требует больших вычислительных ресурсов, но не очень чувствителен ко времени — рабочая очередь, вероятно, лучше подходит, чем попытка вернуть результаты сразу после загрузки аудиофайлов. Обновления модели происходят не так часто, поэтому действия человека и ручное тестирование в процессе обновления и развертывания могут быть приемлемыми, если предусмотрены меры защиты от ошибок.
  • В беспилотном автомобиле обычно используются десятки моделей, которые должны работать на бортовых компьютерах в режиме реального времени. Локально доступное аппаратное обеспечение устанавливает жесткие ограничения на то, что возможно с вычислительной точки зрения. Ошибки могут быть фатальными, поэтому компоненты, не относящиеся к машинному обучению, будут обеспечивать значительную логику для обеспечения безопасности, тесно взаимодействуя с компонентами машинного обучения. Хотя обновления моделей возможны, их развертывание, скорее всего, будет медленным и непоследовательным для всего парка автомобилей. Экспериментирование с различными версиями модели на практике ограничено соображениями безопасности, но можно собрать много данных для последующего анализа и обучения в будущем — на самом деле так много данных, что сбор и обработка данных может стать проблемой.
  • Ориентированная на конфиденциальность умная клавиатура на мобильном телефоне может постоянно обучать модель автозаполнению и автоисправлению локально на телефоне. Здесь не только вывод, но и обработка данных и обучение происходит локально на устройстве с батарейным питанием, возможно, с использованием новых объединенных алгоритмов машинного обучения. При сборе данных телеметрии для отслеживания того, приводят ли обновления к более точным прогнозам, разработчики должны принимать взвешенные решения о том, какие данные собирать и публиковать.

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

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

Общие компоненты в системах с поддержкой машинного обучения

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

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

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

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

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

Источники данных

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

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

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

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

Автоматизированный конвейер машинного обучения

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

Мы обсудим выбор, особенно в отношении автоматизации конвейера машинного обучения, в главе «Автоматизация конвейера машинного обучения».

Вывод модели

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

Мы обсудим различные варианты дизайна и компромиссы, связанные с развертыванием служб вывода моделей, в главе «Развертывание модели».

Магазин функций

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

Мы обсудим хранилища функций в рамках главы «Развертывание модели».

Управление данными

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

В главе «Масштабирование системы» обсуждаются основные строительные блоки для распределенного хранения и обработки данных.

Компоненты без машинного обучения

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

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

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

Общие общесистемные проблемы при разработке систем с поддержкой машинного обучения

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

Следующие соображения по проектированию будут представлены в следующих главах:

  • Разделение проблем и понимание взаимозависимостей. Различные компоненты ML и не ML в системе взаимодействуют друг с другом, часто тонким образом. Например, прогнозы модели используются в бизнес-логике, не относящейся к ML, влияя на взаимодействие с пользователем, производя данные телеметрии, которые можно использовать для мониторинга и обновления моделей. Кроме того, локальные проектные решения в отдельных компонентах влияют на другие компоненты, такие как достаточно маленькая обученная модель, обеспечивающая другие варианты развертывания, чем большая модель. Разработчикам необходимо спланировать, как компоненты машинного обучения используются в системе другими компонентами, например, чтобы понять и ограничить последствия неверных прогнозов. Важно отметить, что потребности и взаимозависимости могут меняться со временем по мере развития системных требований и понимания того, что технически осуществимо. Разработчикам необходимо распределить обязанности и понять взаимозависимости, обычно путем выявления, документирования, мониторинга и обеспечения соблюдения потоков данных и качества на интерфейсах между компонентами.
  • Облегчение экспериментов и обновлений с уверенностью: дизайнеры должны преодолевать противоречия между разработкой исследовательской модели и надежным развертыванием. Многие системы с поддержкой ML ожидают частых обновлений компонентов ML и других компонентов. Подготовка к экспериментам и обновлениям может дать ключевые преимущества, но при этом больше внимания уделяется строгому проектированию, обеспечению качества и практике эксплуатации. Обычно это связано со значительными инвестициями в инфраструктуру для создания надежных, автоматизированных и модульных конвейеров машинного обучения и инфраструктуры для проведения экспериментов и мониторинга результатов в производстве.
  • Разделение обучения и логического вывода и замыкание цикла. Большинство систем намеренно отделяют обучение модели от логического вывода, управляя кодом разработки общих функций. Кроме того, предполагается, что многие современные системы с поддержкой машинного обучения постоянно обучаются и непрерывно собирают данные, часто в результате взаимодействия с пользователем в системе, которую модели с машинным обучением помогают формировать. При работе в постоянно развивающейся системе автоматизация и наблюдаемость становятся важными: разработчикам необходимо сосредоточиться на разработке телеметрии и автоматизировать весь конвейер машинного обучения для непрерывного сбора данных, постоянного обновления моделей и постоянного наблюдения за тем, работает ли система так, как задумано.
  • Обучайтесь, обслуживайте и наблюдайте в масштабе или с ограничениями ресурсов. Многие системы с поддержкой машинного обучения работают с очень большими объемами данных и должны развертываться в массовом масштабе в облаке, в то время как другие могут быть развернуты на встроенных устройства с ограниченными ресурсами. В первом случае распространены масштабируемые конструкции с использованием распределенных систем, чтобы сбалансировать задержку, пропускную способность и отказоустойчивость. В последнем случае могут потребоваться творческие решения для работы с небольшими ресурсами и, возможно, даже полностью в автономном режиме.

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

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

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

  • Конкретный пример архитектуры чат-бота, включающей как ML, так и другие компоненты: Yokoyama, Haruki. «Архитектурный шаблон системы машинного обучения для повышения операционной стабильности». В Международной конференции IEEE по компаньону архитектуры программного обеспечения (ICSA-C) 2019 г., стр. 267–274. ИИЭР, 2019.
  • Исследование с интервью о проблемах качества данных в системах с поддержкой ML, включая проблемы со стимулами и процессами, с обширным соответствующим разделом работы, указывающим также на другую работу в этой области: Sambasivan, Nithya, Shivani Kapania, Hannah Highfill, Diana Akrong, Praveen Paritosh и Лора М. Аройо. «Каждый хочет работать с моделью, а не с данными: каскады данных в ИИ с высокими ставками»». В Материалы конференции CHI 2021 года по человеческому фактору в вычислительных системах, стр. 1–15. 2021.
  • Интервью с архитекторами программного обеспечения в системах с поддержкой машинного обучения, описывающих общие проблемы, с которыми они сталкиваются: Сербан, Алекс и Йост Виссер. Эмпирическое исследование архитектуры программного обеспечения для машинного обучения. В Материалы Международной конференции по анализу, эволюции и реинжинирингу программного обеспечения (SANER), 2022 г.
  • Интервью-исследование, в котором обсуждаются огромные различия между различными производственными системными проектами с поддержкой ML и участвующими командами, подчеркивая, что многие проблемы часто возникают на интерфейсах между компонентами: Нахар, Надя, Шуруи Чжоу, Грейс Льюис и Кристиан Кестнер. «Проблемы совместной работы при создании систем с поддержкой машинного обучения: общение, документация, разработка и процесс.» В Материалы 44-й Международной конференции по программной инженерии (ICSE), 2022 г.

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