Эта статья начиналась как шутка и не слишком далеко зашла в пространстве состояний. Это остроумная и не очень строгая попытка продемонстрировать важность времени в проектах машинного обучения, которая вызовет раздражение большинства математиков и оттолкнет некоторых физиков. В этом есть доля правды… просто ее очень трудно найти. Наслаждаться! 💡

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

В Google есть поговорка о разработке программного обеспечения (сокращенно SWE), которая звучит примерно так (Winters, Manshreck & Wright, 2020):

«Разработка программного обеспечения — это программирование, интегрированное во времени».

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

Мы можем представить приведенное выше утверждение красивым и компактным способом, используя простую формулу

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

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

Если и есть один ключевой вывод, который мы можем извлечь из всего этого, так это то, что SWE — это больше, чем просто написание кода — речь идет о сопровождении этого кода с течением времени.

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

В этом смысле проектирование можно описать как функционал (высокоуровневый оператор в терминах CS), который интегрирует все, что вы строите с течением времени.

Используя постфиксную нотацию, это можно представить как fE, так что SWE на самом деле просто E[SW].

"Хорошо" Я слышу, как вы говорите "Эти формулы классные и все такое" (если вы работаете математиком, вы, вероятно, кричите на экран и дергаете свои собственные волосы в этот момент) «Но почему мы так суетимся из-за времени? Что делает его таким важным?»

Что ж, я рад, что вы спросили!

Если вы не заметили, время меняет все ⌛ (Просто прочтите Озимандиас Перси Биши Шелли!)

В мире разработки ПО последствия течения времени особенно ужасны:

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

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

Те, кто этого не делает, те, кто выбирает легкий путь, самую пройденную дорогу, начинают накапливать долги… технические.

Дорогой читатель, тебе не нравятся хорошие экономические метафоры? 📈

В отличие от греберовского понимания долга как извращения обещания (Graeber, 2011), технический долг не подлежит обсуждению. Если проект намерен сохранить пресловутый свет, он должен быть погашен… в полном объеме (*). Это влечет за собой выполнение всех обещаний, данных PM заинтересованным сторонам при написании устава проекта и инженеров ПО при документировании их кода.

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

Время в машинном обучении

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

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

В документе, представленном на NeurIPS, с провокационным названием «Скрытый технический долг в системах машинного обучения» (также известном как «Машинное обучение: высокая процентная кредитная карта технического долга»💳), Скалли и др. (2015) утверждал, что в реальных системах машинного обучения нет быстрых побед и бесплатно.

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

Он иллюстрирует два очень важных, но часто игнорируемых факта о реальном машинном обучении:

1/ Насколько сложной может быть разработка машинного обучения и

2/ Насколько малы «крутые вещи» (код машинного обучения) по сравнению со всем остальным, также известным как «сантехника» (данные, инфраструктура и т. д.).

Неспособность признать 1 или 2 и их последствия приведет к тому, что любая многообещающая попытка машинного обучения выйдет из-под контроля и потерпит крах. Согласно недавнему отчету Gartner, около 90% всех проектов ИИ и машинного обучения терпят неудачу (!), и только половина из них доводится до стадии производства (!!!).

Можем ли мы обратить эту тенденцию вспять? Что-то нужно изменить… но что?

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

Начнем с основ…

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

Это часто означает что-то вроде

или, ориентируясь только на часть ML

Их часто обозначают аббревиатурой

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

Лучшая альтернатива, предложенная Мартином Фаулером в статье Continuous Delivery for ML (CD4ML), включает понятие 3 оси изменений.

который можно обобщить как

Вы, наверное, понимаете, к чему я клоню, верно?

Давайте применим инженерный оператор (E) к нашему новому определению

Мы можем перевести это во что-то более читаемое

MLE — это просто набор вещей, собранных вместе, интегрированных с течением времени.

Звучит угрожающе, не так ли? Жаль, что это неправильно!

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

Интеграл суммы есть сумма интегралов

Итак, говоря простым языком, наша формула просто говорит нам, что

Если мы приравняем Код к Программированию (что, конечно, спорно, но давайте пока остановимся на этом), то мы в основном говорим, что

MLE — это просто старый добрый SWE, инженерия данных и то, что мы еще не знаем, что называть или как обрабатывать, суммируя вместе

что является грубым упрощением.

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

Схематически это можно представить как

Если бы это было не так, то каждый из этих «терминов», по крайней мере, в.р.т. время, было бы тривиальным вопросом, чтобы решить.

Так что же не так с этой линией рассуждений? И как, если вообще, мы можем это исправить?

Есть две основные проблемы с нашим первоначальным подходом.

Во-первых, приведенные выше определения на самом деле не учитывают тесную зависимость между 3-мя осями изменений.

Модель в значительной степени зависит от качества данных, используемых для обучения, проверки и тестирования — старый метод «Мусор на входе, мусор на выходе» (GIGO) изречение.

С другой стороны, код должен адаптироваться как к модели (или моделям), используемой для логического вывода, так и к данным. strong> то, что в него вложено.

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

Вопрос о том, зависит ли Модель явно от времени, является предметом философских дебатов.

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

1/ Как данные меняются со временем?

И, если вы чувствуете себя фантастично, если (X, y) представляет собой набор данных, содержащий входные переменные X и целевые значения y, как мы можем отличить дрейф данных (изменения X) от дрейфа концепции (изменения X → y) в ложном исчислении. рамки?

2/ Есть ли эффективный способ справиться с дрейфом модели?

3/ Можно ли отделить код от изменений модели?

Наконец, есть (ошибочное) предположение, что мы можем просто подвести итоги и на этом закончить.

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

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

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

Функция L в основном зависит от проблемы и системы, и ее фактическая форма обычно неизвестна, а иногда даже непознаваема.

Вывод, если он есть, заключается в том, что динамика применения инженерных принципов к системам машинного обучения любого типа — это нечто действительно сложное (Paleyes, Urma & Lawrence, 2020), с которым нельзя шутить.

Имейте в виду, что у некоторых проблем есть решения (Lakshmanan, Robinson & Munn, 2021), но они охватывают только крайние случаи и требуют прочтения множества книг O RLY.

Если вы такой же заядлый физик, как и я, вы, наверное, заметили, что я назвал эту функцию L (*подтолкнуть *подтолкнуть *подмигнуть *подмигнуть).

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

в котором говорится, что в некотором смысле природа всегда находит «оптимальный путь», и MLE

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

Как писал Витгенштейн в своем Логико-философском трактате (1921):

«Wovon man nicht sprechen kann, darüber muss man schweigen»
(О чем нельзя говорить, о том следует молчать)

Продолжение следует… или нет (как угодно)

Ссылки

Ссылки

Статьи

Книги