Transcription
Спасибо всем, что пришли. Для начала, вы знаете, что-то, что мы слышим довольно часто, мы говорим о MLOps в течение последних нескольких лет на GTC, это то, что MLOps сбивает с толку. И это может быть потому, что первое знакомство многих людей с MLOps — это такие архитектурные слайды, где вы видите все эти различные компоненты и знаете, как они взаимодействуют друг с другом, и это дает вам ощущение, что вам нужно построить свою MLOps или AI платформу, используя точно такие же компоненты. Но проблема с этим, конечно, заключается в том, что некоторые из этих представлений созданы конкретными организациями или компаниями, которые могут пытаться продать вам именно те компоненты, которые у них есть. Другая проблема с этим заключается в том, что, давайте посмотрим, да, еще одна проблема — это архитектурные слайды, которые чрезвычайно детализированы, которые показывают вам каждый шаг в процессе, и, возможно, они сосредоточены только на одном конкретном типе ML-проблемы. Они могут стать очень подробными, могут показаться подавляющими. И что еще более подавляет, это когда вы смотрите на ландшафт всех видов решений, которые заявляют, что они являются частью экосистемы MLOps, и некоторые из них пересекаются друг с другом, некоторые из них делают больше, чем другие, некоторые из них только как бы косвенно поддерживают MLOps. Так что легко потеряться в этом пространстве, и это часто может ощущаться как аллегория слепых монахов, исследующих слона и пытающихся описать, что такое слон. Поэтому мы постараемся избежать этого в этом докладе, и я надеюсь, что к концу доклада у вас сложится хорошее представление о том, что такое MLOps на самом деле и в чем его суть. Итак, мы начнем с того, каков процесс построения ML, и одна вещь, которую нужно иметь в виду, когда мы говорим о MLOps, это то, что это сочетание науки и инженерии. Из научного метода мы должны применять его, мы должны проверять наши предположения, мы хотим следовать строгому процессу, чтобы прийти к истине для конкретной проблемы, которую мы решаем. А затем с инженерной точки зрения недостаточно прийти к истине, потому что мы должны развернуть что-то, что работает в реальном мире, и могут быть предположения, которые оспариваются, как только мы фактически развернемся в этом реальном мире. Поэтому мы должны также спроектировать решение эффективным образом, чтобы оно соответствовало этим вызовам. К концу этого доклада мы пройдемся по компонентам, которые следует учитывать, если вы строите ML-платформу, и они будут разбиты на этот научный способ мышления и инженерный способ мышления. И это представлено здесь на нашей диаграмме учеными, такими как специалисты по данным, бизнес-аналитики, и инженерами, инженерами данных, ML-инженерами, SRE и разработчиками приложений. Самое первое, с чего вам нужно начать, это какова проблема и каковы, особенно если мы следуем строгому подходу, мы хотим проверить наши предположения, мы хотим установить определенные метрики, которых мы пытаемся достичь, а не обманывать себя позже, когда мы строим наши модели, что мы создали что-то действительно великое. Так что создайте то, что мы пытаемся, критерии успеха, которых мы пытаемся достичь, в основном в начале. А затем мы начнем исследовать все данные, которые у нас есть, чтобы сформулировать проблему. Затем мы фактически, особенно если это команда, решающая проблему, мы захотим федерализовать данные, чтобы мы могли получить к ним доступ из нескольких мест. Мы захотим очистить их, и мы тратим много времени на это, и мы в конечном итоге маркируем их, пытаясь получить эталонный набор данных, который мы можем использовать, особенно для процесса валидации. Затем мы наконец-то находимся на этом этапе процесса, на котором, я думаю, многие люди сосредоточены, а именно на построении модели. Так что проходя через процесс, где мы смотрим на данные, исследуем определенные признаки данных и выбираем, какие использовать, какие наиболее перспективны для использования, чтобы фактически обучить конкретную модель. Мы также хотим выбрать конкретную модель, протестировать ее, настроить и в конечном итоге валидировать и симулировать ее. И мы можем проводить валидацию и симуляцию во многих различных типах сред. Особенно если мы занимаемся чем-то вроде создания модели автономного транспортного средства, недостаточно просто построить модель. Нам нужно будет построить вокруг нее целую систему. Нам нужно будет ее развернуть. Мы хотим убедиться, что, поскольку это может повлиять на человеческие жизни, нам нужно протестировать ее множеством различных способов. А затем мы развернем нашу AI-систему, и на этом мы не закончим, потому что хорошая система будет постоянно отслеживать и валидировать, что развернутая система работает так, как мы хотим. Это изображено как последовательный процесс, но просто помните, что вы делаете это правильно, если вы возвращаетесь к предыдущим этапам процесса. И поэтому это своего рода циклично, кругово, потому что вы обнаруживаете, что есть какая-то новая информация, которую вы получаете в производственной среде, которую вам нужно учесть в вашей модели. Так что вам нужно переобучить вашу модель, или вам может понадобиться выбрать совершенно другую модель, или вам может понадобиться собрать больше данных. Так что вам нужно пересмотреть этот процесс по мере продвижения. Так что есть много уроков, которые мы можем извлечь об системах машинного обучения и моделях машинного обучения, если мы посмотрим на историю науки. И я думаю, что веселее начать с истории псевдонауки. Так что давайте посмотрим на это. Первый пример псевдонаучного явления из истории — это идея испытания ордалиями. И это когда у нас есть кто-то, обвиняемый в преступлении, и его помещают в опасную ситуацию с предположением, что если они невиновны, они получат божественное вмешательство, а если они виновны, то нет. Это был когда-то очень распространенный подход к уголовному правосудию, но он был также гораздо более эффективным, чем вы могли бы подумать. И интригующая недавняя теория предполагает, что испытание ордалиями было на самом деле очень эффективным, потому что все участники верили, что испытание ордалиями было эффективным. Так что, если вас обвинили в преступлении, и вы были виновны, вы абсолютно не позволили бы себе окунуться в кипящую воду или что-то в этом роде, вы бы просто признали себя виновным в менее тяжком наказании. Если вы были невиновны, вы бы верили, что вас спасет божественное вмешательство, и поэтому вы бы прошли испытание. И человек, проводящий испытание, знал, что только те, кто действительно согласился на это, были невиновны. Так что это действительно сработало. В наших системах машинного обучения мы часто можем быть правы по неправильным причинам. Будь то тестирование несбалансированного классификатора путем тестирования его только на обычном случае или других примерах, которые мы увидим позже. Второй вид псевдонаучного явления, вероятно, близко к сердцу многих практиков машинного обучения, потому что он включает в себя прогнозирование будущего. Успешные гороскопы часто полны расплывчатых банальностей и полагаются на предвзятость подтверждения у людей, которые их слышат. Если вы слышите что-то расплывчатое и позитивное, и оно оказывается применимым, вы это запомните. Если вы слышите что-то расплывчатое и позитивное, и оно оказывается неприменимым, вы скажете: "Ах, может быть, мы еще просто не видели этого". Аналогично, опытный предсказатель часто будет задавать много наводящих вопросов своему субъекту, чтобы собрать информацию о субъекте, которую он иначе не получил бы, что может заставить его казаться обладающим информацией, которой у него обычно не было бы. Это очень похоже на явление утечки целевой переменной в машинном обучении, когда мы случайно обучаем модель на информации, которой у нее не будет при прогнозировании. Третье псевдонаучное занятие, которое мы рассмотрим, — это идея лозоходства для поиска воды. Это использование специальной палки или раздвоенной ветки, которая должна вибрировать, когда под землей есть вода. И это еще один научный вызов, который мы видим при построении систем машинного обучения, — ошибка базовой ставки. Во многих районах, где лозоходство оказалось популярным, было довольно много подземных вод. Так что, возможно, если бы вы провели контролируемый эксперимент, вы бы узнали, что использование этой раздвоенной ветки на самом деле не лучше, чем просто копать воду в случайном месте, или у вас не было бы контролируемого эксперимента для сравнения двух разных методов лозоходства. Мы видим суеверия и псевдонауку в машинном обучении тоже. Сколько раз вы изучали новую технику, глядя в документацию? Скажем, мы смотрим на интерфейс классификатора scikit-learn для XGBoost. И у него тонна документации. Если я запущу help в блокноте, я получу много страниц документации, первая половина которых — параметры по умолчанию. В идеале мы бы поняли, что это за параметры и как они влияют на модель. Но реально мы этого не делаем. Мы как бы обучаем модель, просто используя эти значения по умолчанию для параметров. Теперь это плохо по нескольким причинам. Одна из них заключается в том, что новая версия библиотеки может иметь другие значения по умолчанию для параметров. Но мы также на самом деле не провели контролируемый эксперимент, чтобы проверить, что это правильно. Более недавний пример, с которым, возможно, столкнулись некоторые из вас, — это идея шаблонов подсказок для работы с LLM. И если вы подумаете о людях, которые говорили о том, как они добились успеха, используя LLM, у них часто есть эта библиотека волшебных фраз. И в 2024 году сказать "Давайте подумаем шаг за шагом" было как чит-код, чтобы получить лучший ответ от LLM. Но сегодня модель будет думать шаг за шагом, независимо от того, просите вы ее об этом или нет. Мы используем модели рассуждений сегодня, и просьба думать шаг за шагом — это просто пустая трата токенов. Так что еще одна вещь, о которой стоит подумать, когда мы рассматриваем историю науки и думаем о том, как это связано с машинным обучением, — это то, какие объяснения предоставляет наука. И я хочу противопоставить два разных типа объяснений. Слева у нас телеологическое объяснение. Что что-то делает? Делает ли оно то, что должно делать хорошо, или нет? Мы связываем этот тип объяснения с натурфилософией Аристотеля и других философов, когда философия была гораздо более широкой областью, чем сегодня. Но этот тип телеологического объяснения по-прежнему полезен в инженерии, медицине и системах машинного обучения даже сегодня. С другой стороны, мы думаем о механистических объяснениях, которые мы склонны ассоциировать с научной революцией, примером которой является Ньютон здесь справа. И идея заключается в том, что мы хотим определить, как что-то работает и почему оно ведет себя так, а не просто делает ли оно то, что должно делать хорошо. Часто телеологические объяснения необходимы при построении систем машинного обучения. Если я оцениваю эту систему, скриншот которой я только что показал здесь, и не ищите эти кофейни, их не существует, но если вы хотите оценить эту систему, у вас нет способа узнать, являются ли это хорошими рекомендациями кофе в целом или для конкретного пользователя. Но у вас есть способ узнать, как пользователь реагирует на эти рекомендации, и у вас есть способ узнать, продолжает ли пользователь использовать систему. Нам может понадобиться рассмотреть модель в контексте общей системы. Напротив, иногда нам нужны механистические объяснения, чтобы понять, где что-то идет не так. Отличный урок из классификаторов изображений заключается в том, что иногда классификатор изображений фокусируется на чем-то, на что вы не ожидали бы, что он будет реагировать. Например, у нас есть классификатор здесь, который различает беговые кроссовки и туфли, беговые кроссовки в верхнем ряду, туфли в нижнем ряду. Но если мы дадим ему этот пример человека, носящего вингтипы на беговой дорожке, он идентифицирует его как беговые кроссовки. Почему он это сделал? Если мы посмотрим на то, на что модель на самом деле реагирует, мы можем увидеть, что модель ищет наличие беговой дорожки, чтобы идентифицировать что-то как беговые кроссовки. Так что часто мы получаем эти ML-суеверия просто путем повторного использования советов или методов, которые хорошо работали в одном контексте, не задумываясь о том, почему они работали. И процесс углубления и определения того, почему эти вещи работают, включает механистические объяснения и инженерную дисциплину. Так что я передам слово Майклу. Спасибо, Уилл. Да. Так что обратная сторона научного мышления — это инженерное мышление в этом, и мы проиллюстрируем это на некоторых примерах неудач, которые стали инженерным фольклором. Например, Ariane 5 Flight 501. Это ракета, которая стартовала в 1996 году и через 37 секунд взорвалась, и причина этого в том, что было некоторое программное обеспечение для расчета полета, которое было повторно использовано из Ariane 4 и было перепрофилировано для этой новой версии ракеты, и оно работало с данными от датчиков, которые были гораздо более ограниченными, чем у новой ракеты. И когда эти более экстремальные значения были обнаружены, резервная система, горячий запас, отреагировала переполнением и вышла из строя. Вскоре после этого основная система столкнулась с теми же данными и тоже вышла из строя. После того, как она вышла из строя, она искала резервную систему, чтобы увидеть, могу ли я передать управление резервной системе? Она не смогла, ее не существовало. Так что в этот момент она загрузила отладочный вывод на главный бортовой компьютер, и бортовой компьютер, к сожалению, посмотрел на все отладочные данные и интерпретировал их как команды и самоуничтожился. Так что мы можем из этого извлечь? Программный модуль, который был использован, старый, на самом деле работал в пределах своих границ. Он не был некорректным, так сказать. Но общая система не учитывала, что существуют более экстремальные значения, которые нуждались в обновлении либо в базовом компоненте, либо требовалось изменение на уровне системы. Похожий пример — Mars Climate Orbiter, или MCO для краткости. Это отличный пример того, где система двигателей в MCO, когда она направлялась к Марсу, ожидала измерения силы в фунт-футах в секунду, но на самом деле это было в ньютон-метрах в секунду или что-то в этом роде. Так что метрическая против имперской системы преобразования. И это привело к вычислениям, которые были далеко за пределами допустимых значений, и MCO в результате промахнулся, и мы потеряли с ним связь. Так что похожий пример, и я думаю, эти два примера иллюстрируют важный момент с контрактными интерфейсами. С ML-системами недостаточно иметь модель, которая технически корректна, или некоторое программное обеспечение, которое технически корректно. Мы должны думать о каждом аспекте большей общей AI-системы, которую мы внедряем. Так что мы должны учитывать, поскольку многие из этих операций являются матричными умножениями различных значений, но мы должны проверять наши предположения о том, есть ли у нас экстремальные значения, которые мы не учли, находятся ли они в пределах диапазона, и, по сути, для каждого компонента в ML-системе, каков контракт, которому придерживается каждый компонент, как система работает в целом. Еще один отличный пример инженерных неудач — это Миллениумский мост. В 2000 году Лондон отмечал совершенно новый мост, который был очень тщательно спроектирован для вертикальных нагрузок, но не для боковых. И интересное, что произошло в результате, это то, что когда мост был открыт для публики и люди начали ходить по мосту, мост начал раскачиваться в стороны. И это создало очень интересный синхронизирующий эффект, когда люди начали маршировать в одном ритме с этим боковым раскачиванием, что на самом деле усугубляло боковое раскачивание, и возникла целая петля обратной связи, которая привела к катастрофическому отказу моста. Так что это нам напоминает? Это как бы напоминает мне о петлях обратной связи с алгоритмами, которые у нас есть онлайн. Очень часто можно попасть в пузырь, где, если вам нравятся одни вещи, а другие не нравятся, вы можете начать видеть все более и более экстремальные версии того, что вам нравится или не нравится. И поэтому у нас есть этическая ответственность с инженерной точки зрения и практическая, что когда мы развертываем модель или развертываем систему в производстве, мы должны тщательно рассматривать и отслеживать эту систему в производственной среде и убедиться, что только потому, что система хорошо работала в один момент времени, это не означает, что она будет хорошо работать в будущем, это не означает, что взаимодействие пользователей с этой системой не будет развиваться и накапливаться со временем. Последний пример в области инженерии. Knight Capital была торговой фирмой. Они создавали программное обеспечение для автоматизированной торговли, и в 2012 году они начали вручную обновлять некоторые узлы новой версией своего торгового программного обеспечения. Они пропустили пару узлов, и интересное, что произошло, это то, что старое программное обеспечение получало все те же ордера на покупку, что и новое программное обеспечение, но оно пыталось связаться с остальным новым программным обеспечением, чтобы сказать: "Эй, мне все еще нужно купить эту конкретную акцию?" И поскольку оно не могло связаться, оно просто восприняло это как сигнал, что ему нужно покупать все больше и больше акций, и это привело к еще одному катастрофическому сбою, в результате которого было потеряно 440 миллионов долларов. Так что интересно в этом, это действительно наличие хорошего DevOps-процесса, dev, staging, prod, наличие способа, по сути, развертывать программные системы, потому что AI-система — это просто еще одна программная система. И наличие контроля версий, наличие способа тестировать все, это по-прежнему чрезвычайно важно в наши дни. Так что теперь мы рассмотрим тематическое исследование и увидим, как наука и инженерия объединяются в конкретной области применения. Держу пари, вы уже сегодня взаимодействовали с рекомендательной системой. Какие ставки на то, сколько вы взаимодействовали? Просто поднимите пальцы. По крайней мере, один. Так что, если вы пользовались социальными сетями, потоковым медиа, поиском, если вы покупали что-то онлайн, вы взаимодействовали с рекомендательной системой. Мы сосредоточимся на розничной торговле и посмотрим, как существует элегантное понимание этой проблемы, которое превращается в модель, а затем как внедрение этого в систему выявляет некоторые проблемы, которые мы хотим решить с помощью лучшей модели и лучшей системы. Итак, основная идея заключается в том, что у нас может быть десятки или сотни миллионов пользователей и, возможно, миллионы продуктов, но мы можем осмысленно группировать пользователей и продукты по сходству и находить пользователей со схожими вкусами или находить продукты, которые ценятся похожими пользователями. Итак, здесь мы кодируем привязанность пользователя к продукту как матрицу. В строке у вас есть оценки пользователя, а в столбце — все оценки, которые каждый пользователь сделал для конкретного продукта. И большинство пользователей не оценивают большинство вещей, поэтому это разреженная матрица. Если пользователь кликает на продукт, мы можем найти все похожие продукты, находя векторы, похожие на столбец этого продукта. Теперь, чтобы посмотреть, что включает в себя решение этой проблемы, давайте посмотрим на матрицу, которая помещается на слайде. Это изображение Луи Дагера в низком разрешении, который изобрел первый фотографический процесс, и это матрица размером 160 на 125 элементов, 20 000 значений. Если бы мы хотели найти столбец, наиболее похожий на вектор из 160 элементов, своего рода поиск продуктов, похожих на продукт, нам пришлось бы выполнить около 40 000 арифметических операций. Сложность этого порядка количества элементов в матрице. Теперь интересно то, что если у нас есть много избыточности в этой матрице, мы можем разложить ее на множители меньшего ранга, которые при умножении друг на друга дают приближенную версию матрицы. Это здорово, потому что это экономит нам место при хранении матрицы. Но настоящее преимущество в том, что мы можем выполнять поиск сходства и в этом низкоразмерном пространстве. Таким образом, мы сэкономили около трех четвертей пространства и около трех четвертей вычислительных ресурсов, если мы выполняем поиск сходства по этому сжатому представлению. И если мы можем справиться с еще большей ошибкой, что мы часто можем, мы можем сэкономить еще больше времени. Теперь я бы не стал размещать ни одно из этих изображений в своем профиле LinkedIn, но они, очевидно, все еще Луи Дагер. И в рекомендательных приложениях направленно правильное часто достаточно. Но мы также имеем дело с гораздо большими матрицами, чем эти крошечные, которые мы можем поместить на слайд, и мы имеем дело с относительно меньшими разложениями, чем эти, на которые мы смотрим здесь. Так что вместо экономии 75 или 90 процентов, мы часто экономим 99,9 процента или более времени и пространства, необходимых. И мы можем использовать это, чтобы ответить на вопрос: учитывая, что вы купили эту вещь синего цвета, что еще вам может понравиться, вещи оранжевого цвета. Однако у этой модели есть некоторые проблемы. И первое — это то, что нам нужна явная или неявная обратная связь от пользователя, чтобы вообще делать рекомендации. И когда вы в последний раз оценивали что-либо онлайн? Мы можем несправедливо сместить предпочтения в сторону продуктов, которые оценили многие люди, или давать бесполезные рекомендации просто потому, что продукты имеют схожие профили. Сколько раз вы покупали стол, а затем получали рекламу другого стола? Сколько столов вам нужно? Но я думаю, самая большая проблема в том, что эта система действительно зависит от большого количества данных. И вы не можете делать прогнозы вообще без большого количества данных. И если у вас есть новый продукт или новый пользователь, вам нужно встроить некоторую дополнительную сложность в систему, чтобы вообще справиться с этими случаями. Так что лучший подход — моделирование поведения пользователя как последовательности и использование трансформера, чтобы сказать: учитывая, что пользователь совершил эти действия, просмотрел эти продукты, положил эти вещи в корзину, что он будет делать дальше? И мы можем обучить модель обучения последовательностей на основе пользовательских сессий, чтобы предсказывать наиболее вероятные следующие действия и то, что будет актуально для того, что пользователь только что сделал, что он будет делать дальше. Первая часть этого — прогнозирование следующих условных вероятностей того, что пользователь делает дальше. И это важная часть создания рекомендаций, но это действительно только часть рекомендательной системы. И поэтому мы позаимствуем некоторую терминологию у команды NVIDIA Merlin и скажем, что первый шаг — это действительно просто извлечение релевантных вещей на основе того, что пользователь уже сделал. Следующий шаг — отфильтровать то, что мы не хотим показывать пользователю. Я не хочу, чтобы пользователь знал, что он может купить что-то, чего нет в наличии, это просто расстроит его. Я не хочу, чтобы пользователь знал, что он может купить что-то, что я не могу отправить в его страну или штат. Учитывая вещи, которые мы хотим, чтобы появились в окончательной рекомендации, у нас есть другая модель, которая предсказывает, насколько вероятно, что пользователь выберет одно из этих действий. И, наконец, у нас есть другая система, основанная на правилах, которая упорядочивает их на основе бизнес-критериев, скажем, ставя что-то с высокой маржой первым, или если у пользователя уже есть пять товаров в корзине из одного склада, мы хотим рекомендовать что-то еще из этого склада и отправить все в одной коробке. Так что у нас есть начало системы машинного обучения здесь с агрегированием поведения пользователя, прогнозированием на основе последовательности действий, которые пользователь уже совершил. Но в производстве весь этот конвейер становится подсистемой, состоящей из компонентов. И все эти компоненты — это программное обеспечение. Мы версионируем их всех независимо. Мы разрабатываем их всех независимо. Но, как мы видели на примере ракеты Ariane 5 и Knight Capital, мы действительно хотим развертывать все это синхронно. Так что, если я обновлю кучу компонентов до версии два, а что-то все еще будет на версии один, моя система, вероятно, будет работать неправильно. Так что нам действительно нужен способ управлять версионированием этих систем, и нам нужен способ убедиться, что наши развертывания автоматизированы и дисциплинированы и происходят одновременно или не происходят вообще. Второе, что нам нужно сделать, — это отслеживать, насколько хорошо работают отдельные версии системы. Так что, если мы знаем, какие компоненты мы используем, и мы знаем, насколько хорошо работает система, мы можем сказать, учитывая эти ограничения, насколько хорошо мы работаем по сравнению с тем, насколько хорошо мы работали месяц назад с другой моделью. Мы будем поддерживать два отдельных конвейера обучения для двух моделей, которые мы используем в этой рекомендательной системе. И нам потребуются исторические данные, доступные в масштабе, чтобы сделать это. Но мы, вероятно, не обучаем модель на необработанных исторических данных. Мы, вероятно, трансформируем и токенизируем их каким-то образом. И мы можем принимать разные подходы со временем. Так что просто возможность сказать, что это текущая версия наших исторических данных, не так полезна, как возможность сказать, что мы можем вернуться к предыдущему конвейеру, который мы использовали для обучения предыдущей версии модели. Это действительно важно, если мы хотим проводить контролируемые эксперименты с течением времени и видеть, как модель улучшилась или нет с течением времени. Так что возможность вернуться к предыдущей версии. Другая забота — мы хотим поддерживать специалистов по данным. Мы хотим поддерживать людей, которые работают над этим подходом к моделированию. И это означает, что мы должны предоставить им вычислительные ресурсы по требованию в контролируемой среде, чтобы они могли воспроизводить свою работу и делиться ею и сотрудничать со своими коллегами. Нам нужно упростить им отслеживание их работы с помощью контроля версий. И часто мы стоим на плечах гигантов, когда занимаемся наукой о данных. Мы хотим сделать возможным понимание и аудит библиотек с открытым исходным кодом, которые они используют в этой работе. Наконец, мы хотим взять все эти детали о том, что вошло в обучение модели, версию кода, версию данных, версию зависимых библиотек и любые гиперпараметры, которые мы использовали при обучении модели, и мы хотим хранить их в базе данных вместе с результатами этой модели из валидации. Так что мы можем провести контролируемый эксперимент и сказать, что из этих вещей лучше работает для нашей проблемы в изоляции, а затем отслеживать эти вещи в реальной системе. Мы будем собирать обратную связь из реальной системы, что позволит нам иметь больше обучающих данных для нашей модели в будущем, а также видеть, как все идет. И мы начинаем получать картину сложной системы. У нас много программных компонентов, работающих вместе. Каждая из этих стрелок выполняет тяжелую работу, и это место, где что-то может пойти не так. И мы действительно хотим иметь способ убедиться, что это остается в рабочем состоянии без большого вмешательства человека, и мы хотим получать оповещения, когда что-то идет не так. Так что это действительно простая картина, но вы начинаете получать представление обо всех видах вещей, которые могут пойти не так в системе машинного обучения. Так что я передам слово Майклу, который расскажет о том, как увидеть пространство, которое делает это управляемым. Да. Итак, давайте вернемся к MLOps и нашему определению MLOps. Вы узнаете процесс и людей, но какие компоненты должны быть здесь задействованы и как они обеспечивают научную часть процесса и инженерную часть процесса, которые, как вы можете узнать, верхние компоненты не зависят от инфраструктуры, следуют научному методу, и интересно, что нижние части зависят от инфраструктуры, потому что они нацелены на инженерный аспект процесса. Итак, начиная с одного компонента, особенно если мы думаем о совместной работе команд и наличии инструментов в их распоряжении, очень важная часть процесса, на которую тратится много времени, — это обработка данных, аналитика, маркировка. Так что наличие инструментов, которые фактически облегчают это, очень полезно для MLOps, для процесса разработки ML. Для маркировки, например, вы можете подумать об инструментах, где есть человеческие аудиторы, которые фактически маркируют данные. Так что критически важная часть здесь. Интерактивная разработка, Уилл говорил об этом, очень важна для того, чтобы, когда вы исследуете научный подход и научный метод, тестировать гипотезы. И своего рода стандартом сегодня является наличие Jupyter Notebook с ресурсом, с которым вы можете экспериментировать с данными, экспериментировать с моделью и интерактивно разрабатывать. Уилл также говорил об управлении экспериментами, что очень важно. Вы можете думать об этом как о системе контроля версий в центре того, как вы пробуете разные эксперименты, но как вы также отслеживаете все перестановки различных вещей, которые вы делаете, и приходите к своего рода аудиторскому журналу того, какие эксперименты сработали, а какие нет, а также данные, которые вы используете в процессе, и программные компоненты. AutoML — это просто расширение этого. Если вы думаете об алгоритмах, которые выполняют множество различных перестановок и следуют определенному алгоритму, это просто управление экспериментами плюс алгоритм. Затем внизу у нас управление данными, критически важное для практически каждого аспекта жизненного цикла разработки ML, и вам также нужен контроль версий здесь. Если вы храните данные, данные будут меняться. Вы маркируете их, маркировка может иметь проблемы. Могут быть дополнительные версии различных меток для одних и тех же данных, и вы хотите отслеживать все это. И если вы не отслеживаете данные, вы также не отслеживаете версии вещей. Управление признаками и управление конвейерами. Когда вы разрабатываете различные признаки, вы хотите предоставлять их и использовать их как часть жизненного цикла обучения. Так что полезно иметь программное обеспечение и инструменты, которые облегчают это. И управление конвейерами, вы можете думать о запуске различных задач или различных аспектов этого процесса в автоматизированном режиме. Так что возможность сказать: возьмите определенные признаки, обучите модель, разверните эту модель или оберните эту модель в общую программную систему, а затем разверните ее в автоматизированном режиме, это все управление конвейерами. Затем ModelOps, на самом деле вы можете думать об этом как о предоставлении модели и мониторинге модели в производстве. Особенно с GenAI это очень популярная область, потому что вы можете просто брать модели с полки, дорабатывать их и развертывать очень быстро, но по-прежнему очень важно отслеживать и видеть, как они работают. И, наконец, недооцененный герой во многих MLOps — это управление инфраструктурой и планирование. Безусловно, это имеет огромное значение в NVIDIA, потому что вы хотите убедиться, что вы используете ресурсы наиболее эффективным образом в вашем распоряжении. Эффективно ли вы используете GPU? Эффективно ли вы используете другое оборудование? Как вы планируете все рабочие нагрузки? Особенно если это большая команда и много ресурсов, или это огромная проблема масштабирования, это становится все более и более важным. Так что все эти компоненты действительно обобщены, и у нас есть рекомендации для каждого, которые мы давали в предыдущие годы, но это может быть немного подавляющим. Я думаю, если вы просто пытаетесь начать, просто знайте, что существует множество комплексных ML-платформ, которые используют многие из этих компонентов. Так что, если вы обратитесь к CSP, у вас есть AWS SageMaker, Google Vertex AI, Microsoft Azure ML, все они предлагают довольно приличные решения для начала работы. Если вы хотите повысить свой уровень, вы можете посмотреть в этом пространстве только на управление экспериментами, ModelOps и управление инфраструктурой и планирование, и вы можете построить более сложную систему, я бы сказал. Теперь я передам слово Уиллу, который попытается убедить вас, что, по сути, в эту новую эру LLM и генеративного ИИ это то же самое изображение. Да. Так что для тех из вас, кто думает, что сейчас 2026 год, почему вы говорите о классическом ML, это ваша часть доклада. Однако существует много сходств между системами генеративного ИИ и классическими ML-системами. Важное отличие, однако, заключается в том, что вы обычно не обучаете свою собственную базовую модель. Я имею в виду, если вы это делаете, поговорите с нами, мы хотим услышать о том, что вы делаете. Но многие из этих частей процесса по-прежнему действительно важны, особенно наличие хороших оценок для вашей проблемы. Действительно ли вы решаете то, что хотите решить? Мы увидим аналогию с классическими ML-системами в этом примере LLM. LLM впечатляют прямо из коробки, но сама по себе модель недостаточна для решения проблемы. LLM может показаться гораздо более мощным и интересным, чем поиск матриц низкого ранга, который мы выполняли, но сама по себе она может отвечать только на вопросы, на которые она была настроена с использованием данных из ее точки отсечения знаний. Так что я могу получить лимерик о галках. Я не могу получить лимерик о галке с чем-то, что произошло сегодня, или с чем-то, что находится в моих личных данных. Так что нам нужен способ решить эту проблему, чтобы поместить эту модель в систему, и нам нужен способ идентифицировать документы, которые похожи на запрос пользователя, ранжировать их и фильтровать, а затем объединить их с запросом пользователя, чтобы дать полезный ответ. И если это звучит знакомо, то это потому, что мы говорили об очень похожей системе, которая делает очень похожие вещи ранее в сессии. Так что генерация, дополненная поиском, — это шаблон для дополнения LLM релевантным контекстом, и оказывается, что это также сложная система машинного обучения, где мы выдаем запрос, который зависит от наличия этих вложений, которые мы можем использовать для поиска документа, и запрос вызывает ряд взаимодействий между различными моделями, которые у нас есть, и LLM. И, наконец, мы хотим иметь защитные механизмы, чтобы убедиться, что запрос является надлежащим, что мы не просим чат-бота поддержки помочь нам с домашним заданием, и что ответы основаны на правде и являются надлежащими. Так что здесь действительно много сходств, но мы также видим важные тонкие различия с системами LLM и системами генеративного ИИ. И мы видим, что многие из этих похожих мест имеют дополнительные обязанности и дополнительные вещи, которые нас волнуют в этих случаях. Многие проблемы становятся больше. Так что есть несколько вещей, которые мы хотим, чтобы вы вынесли из этого. И первое — это то, что системные проблемы имеют значение, независимо от того, решаете ли вы большие проблемы или маленькие. Я видел, что генерация, дополненная поиском, которая является довольно сложной вещью для предприятий в 2026 году, имеет много проблем. Но даже если вы обучаете модель линейной регрессии для прогнозирования стоимости недвижимости на основе площади, что-то, что любой может сделать с помощью алгебры средней школы и карандаша и бумаги, вам нужно подумать о том, применима ли модель за пределами ее обучающего набора. Вы не хотите продавать квартиру за отрицательные доллары в месяц. Системные проблемы также имеют значение при каждом масштабе развертывания. Если у нас есть 10 000 узлов, и каждый из них может выйти из строя в среднем раз в 10 000 часов, мы будем видеть сбой каждый час. Как вы справляетесь с этим сбоем? Как быстро вы можете восстановиться после этого сбоя? Мы видели в примере Knight Capital, что если у вас есть восемь серверов, и один из них не работает с правильной версией программного обеспечения, у вас будет очень сложный сбой. Можем ли мы справиться с этим случаем также более автоматизированным способом? Но даже в малом масштабе вы можете запускать много сред машинного обучения на своем локальном компьютере, чтобы позволить агенту взаимодействовать с вашим кодом. Предоставили ли вы агенту доступ к правильным вещам и не предоставили ли вы доступ к неправильным вещам? Это отличный вопрос. Итак, мы начали с того, что рассмотрели, как многие люди имеют идиосинкратические взгляды на MLOps и фокусируются только на части проблемы. Мы действительно хотели дать широкий обзор, и мы увидели, что мы можем извлечь выгоду из примеров науки и инженерии на протяжении всей истории, будь то поиск воды на полях в Западной Европе в 18 веке или поиск воды в атмосфере Марса. Мы видели, как наука и инженерия объединяются, как модели превращаются в системы машинного обучения. И мы рассмотрели таксономию того, как разобраться в этом пространстве и построить платформу, которая работает для вашей организации. У нас нет времени для вопросов прямо сейчас. Мы ответим на некоторые из них в коридоре, но у нас есть отличные возможности для вас, чтобы узнать больше. Сразу после этой сессии состоится MLOps 201, а завтра днем — MLOps 202. Если вы посетите все три эти сессии, вы будете очень хорошо подготовлены к продолжению вашего пути в MLOps. У нас также есть особая возможность для вопросов в 16:00 в среду, где у нас будет сессия "Общайтесь с экспертами". Майкл и я будем там вместе с множеством других сотрудников NVIDIA, чтобы поговорить с вами о ваших проблемах и идеях в этой области. И это был очень полезный опыт для нас, когда мы делали это в прошлом. Было здорово провести время с вами сегодня днем. Приятного остатка GTC.