Библиотеки моделирования не имеют значения

Библиотекимоделированиянеимеютзначения

При создании первых конвейеров машинного обучения для моей компании я мучился над тем, какие библиотеки моделирования включить в наш стек. Что хотели бы использовать большинство разработчиков моделей? Я твердо относился к scikit-learn и PyTorch, но каковы будут последствия навязывания моего мнения о фреймворках машинного обучения инфраструктуре нашей компании? Какая библиотека моделирования «выиграет» в долгосрочной перспективе? Что, если бы я написал код моделирования в DSL, который устареет через несколько лет?

В 2016, я прошел вводный курс глубокого обучения с заданиями на Tensorflow; мой последний курс глубокого обучения полностью проводился в PyTorch. Четыре года спустя похоже, что все исследователи машинного обучения, которых я знаю, используют PyTorch . Те немногие, кто не использует PyTorch, используют TF 1.0 с мантрой «когда-нибудь я перейду на TF 2.0 или PyTorch». Что случилось?

За несколько месяцев я понял, что выбор библиотеки не имеет значения, поскольку моделирование – это всего лишь крошечный шаг в конвейере машинного обучения. Остальные шаги также, если не больше, сложно поддерживать: например, гораздо сложнее перенести код конвейера данных , чем переписать базовый код моделирования TF в PyTorch. Я писал модели на TensorFlow, PyTorch, XGBoost, scikit-learn и LightGBM для различных задач моей компании. Я даже писал на Scala модели, отличные от Python. Когда я повторяю конвейеры машинного обучения для задачи прогнозирования, я стараюсь максимально избегать изменения архитектур моделей, поскольку я бы предпочел изменить части конвейера, которые я понимаю лучше , например, прием данных и улучшенная функциональность. Запрос на вытягивание моей компании показывает, что люди почти не касаются своего кода моделирования по сравнению с кодом конвейера. Важно иметь инфраструктуру для «plug and play» инструкторов и предикторов моделей машинного обучения, поскольку почти никогда не бывает одной библиотеки программирования, которая бы удовлетворяла всем потребностям.

Некоторые указывают на тенденции исследователей, которые в подавляющем большинстве предпочитают PyTorch и JAX, и утверждают, что победитель здесь действительно имеет значение, потому что исследователи превращаются в специалистов по данным в компаниях, эти специалисты по данным строят модели, а модели будут производиться и использоваться «вечно». Но как отрасль мы все еще боремся с производством моделей, согласованием их результатов с человеческими стимулами, повторением этих систем и доверием этим конвейерам. Для любых практиков машинного обучения, не относящихся к «крупным технологиям», самые большие проблемы – это моделирование конвейеров и согласование ценностей между клиентами, самими собой и машинами. В конце концов, они необходимы для разработки продукта. Даже если мы построим фреймворки для этих центральных проблем, библиотека моделирования все равно не будет иметь значения, потому что несколько программных фреймворков для проблемы могут счастливо сосуществовать . Люди умны и могут легко изучить другой фреймворк – факт, что произошел такой большой и быстрый переход от TensorFlow к PyTorch в течение нескольких лет. доказывает, что разработчики найдут лучший инструмент для своей работы. Более важно то, что у них есть правильная основа для программного обеспечения, которое они создают.

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

Таким образом, скачки библиотек моделирования вводят в заблуждение, и самые сложные проблемы в «реальном» машинном обучении прямо сейчас вращаются вокруг бизнес-ценностей, производства, миниатюризации и конвейерной обработки для повторного обучения и вывода. Но поскольку языки программирования и инфраструктура стимулируют инновации в программном обеспечении , все же стоит подумать об эволюции библиотек моделирования. В The Mythical Man-Month: Essays on Software Engineering Фред Брукс представляет концепцию Эффект второй системы , чтобы быть «тенденцией небольших, элегантных и успешных систем быть замененными чрезмерно спроектированными, раздутыми системами из-за завышенных ожиданий и самоуверенности». Известные примеры включают IBM System / 700 операционная система (которая пришла на смену IBM / 7000 из серии 1950, и операционная система Multics (которая пришла на смену Compatible Time-Sharing System с недавнего времени s).

Я считаю TF 1.0 успешным: он ускорил многие исследования в области глубокого обучения, был довольно узким и продуманным по своему охвату и являлся лидером инноваций в аппаратной вертикали с компиляцией XLA, TPU и многим другим. Но со временем, когда сотни инженеров TensorFlow попытались устранить ограничения программного обеспечения и превратить TensorFlow в библиотеку машинного обучения для всех, он пострадал от эффекта второй системы и стал TF 2.0, библиотекой машинного обучения ни для кого (возможно, кроме Google ). Одна группа проблем, которую они пытались решить, – это «заставить модели работать в производственных условиях»: TFX – отличный пример переоцененного и недостаточно используемый инструмент TF 2.0. Сравните статистику PyPI с Kubeflow для контекста; TFX построил свой фреймворк так, чтобы он хорошо вписался в Kubeflow, а пользователи Kubeflow по-прежнему не хотят использовать TFX. Это не значит, что проблем с производственным машинным обучением не существует; скорее кажется, что TFX в настоящее время не решение многих из этих невероятно сложных проблем. Наличие руководств не помогает, если UX противоречит здравому смыслу и инженерам необходимо стать профессиональными парсерами журналов ошибок , чтобы освоить этот инструмент.

Учитывая мою критику в адрес TensorFlow UX, я на самом деле использую TF 2.0 на работе – в основном из-за лени. Конвейер модели Spark to TFRecord to TFData to TF частично задокументирован , тогда как Spark to TFRecord to something to PyTorch model pipeline только едва задокументировано . Но о DSL для моих моделей вряд ли я думаю каждый день, поскольку большинство моих проблем не в том, «как быстро я могу с нуля написать архитектуру преобразователя или свертка». Люди в этой индустрии редко создают что-то с нуля. Программные продукты построены на принципе инкрементальности ; код и функции накапливаются со временем.

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

Благодаря Риз Патхак , Джей Бхамбани и Дебнил Сур за отзывы о нескольких черновиках.