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

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

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

Вопрос 1: Может ли команда быстро выполнять итерации?

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

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

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

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

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

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

Q1.1: Распространенные проблемы машинного обучения в производственной среде

  • Дрейф данных и концепций.

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

  • Требования к дополнительным функциям

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

  • Изменения в обработке данных и моделировании

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

  • Непредвиденные проблемы

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

  • Низкая производительность при развертывании

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

Объем работы и затраты, необходимые для решения этих производственных проблем, следует учитывать заранее!

Q1.2: Заблаговременное решение производственных проблем

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

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

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

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

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

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

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

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

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

Заключительный вопрос 1:

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

Вопрос 2: Насколько хорошо должна работать модель, чтобы быть ценной?

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

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

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

  • Базовая человеческая производительность / производительность там, где она считается ценной
  • Цена отказа
  • Зрелость технологии

Упрощенный пример 2 разных секторов:

  1. Компания, занимающаяся беспилотным транспортом, требует, чтобы модель классификации дорожных знаков достигала точности 99,9999 %. Если точность ниже, это не будет соответствовать требованиям безопасности и не может использоваться в реальном развертывании. Цена отказа потенциально может быть гибелью жизней. Чтобы обучить классификационную модель до производительности 99%, инженеры машинного обучения смогли сделать это за несколько месяцев, но технический долг на самом деле огромен; для перехода с 99 на 99,9999% точности требуются огромные усилия.
  2. Производственная компания требует, чтобы модель классификации брака продукта достигла точности 99%, чтобы быть ценной. Если точность ниже, будет лучше нанять несколько ручных рабочих для выявления бракованных изделий. Цена ошибки будет заключаться в доставке дефектных продуктов клиентам. Обучить классификационную модель до производительности 99 % инженерам машинного обучения удалось за несколько месяцев.

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

Команда машинного обучения также могла серьезно недооценить сложность перехода от 99 к 99,9999% точности (от PoC до требования развертываемой метрики). Это упрощенный пример, реальные проблемы намного сложнее и не могут быть определены одной метрикой модели. Однако цель этого сравнения не в том, чтобы понять фактические базовые требования и технологический стек беспилотного вождения, а в том, чтобы указать на важность надлежащего определения масштабов проекта заранее. Если вас действительно интересуют требования к беспилотному вождению, стоит прочитать эту статью О формальной модели безопасных и масштабируемых беспилотных автомобилей. Цитата из бумаги:

«Сначала учтите, что вероятность смертельного исхода в результате несчастного случая на один час (человека) за рулем, как известно, равна 10^-6. Разумно предположить, что для того, чтобы общество приняло машины для замены людей в задаче вождения, уровень смертности должен быть снижен на три порядка, а именно вероятность 10^-9 в час».

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

Для обоих этих примеров проблему можно упростить, если держать людей в курсе, перейдя от полного самостоятельного вождения к автоматизированному вождению с участием водителя (от L5 до L3) или перейдя от полного обнаружения дефектов к обнаружению дефектов с участием рабочих. петля для работы с неопределенными прогнозами.

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

Заинтересованные стороны должны быть осведомлены о зрелости технологии и требуемой производительности, чтобы считаться ценной. Без планирования и изучения этого вы можете просто в конечном итоге построить или инвестировать в систему Proof of Concept ML без производственной ценности и получить большой технический долг, который никогда не будет погашен.

Заключительный вопрос 2:

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

Заключение

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

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

Свяжитесь со мной в LinkedIn, с удовольствием пообщаюсь и поработаю над будущими проектами! Я ищу людей со схожими интересами в области ML, MLOps, автономных транспортных средств и предпринимательства.