Всем привет. Рад всех видеть. Меня зовут Антон. Я представляю здесь не только
Яндекс .Рекламу, но и программный комитет конференции.
Хочу поделиться с вами своим видением того, как вообще в связи со стремительным
развитием искусственного интеллекта сейчас меняется бэкэнд -разработка. И лично
меня здесь впечатляет не только то, как меняется наша профессия, как мы
буквально код пишем, но и то, как меняется архитектура самих систем благодаря
развитию нейросетей, и то, какие буквально новые классы, задач возникают здесь.
Начнем, конечно, с того, как мы пишем код. Уверен, что большинство из вас код
уже руками не пишет и отличает, наверняка, вайп -кодинг от агентной разработки.
Как раз про некоторые интересные и сложные тренды агентной разработки немного
поговорим.
Вот вы наверняка пишете тесты, я уверен, да? И хочется, чтобы в продакшен код
попадал в хорошем состоянии, баги не произвязали.
А что, если мы будем говорить не про конкретный код, который в продакшене
работает, а про ваши агентные пайплайны? Вот, например, хочется ревьюить код
тоже с помощью агентов. И вы собираете такой pipeline -агентного кода review, у
вас там есть некоторая базовая модель, какие -то скиллы, какие -то критики. А
что, если вы захотите поменять базовую модель на какую -то более продвинутую?
Или если вы захотите добавить код на новую критику? Как вы помните, стало лучше
или хуже? Вообще -то тоже нужна некоторая приемка. Нужны какие -то выборки
типичных полуреквестов. На этих полуреквестах нужно запустить предыдущую версию,
новую версию, как -то их сравнить. Вообще -то сделать так, чтобы эти агенты не
подглядывали друг к другу и во внешний мир. Короче, вообще -то, нетривиальная
бэкэнтерская задача, ну, этот подход обычно называется эвалы, вот, из МЛ мира
термин. И в как раз больших командах, больших пейплайнах это все очень
актуально, иначе просто непонятно, как полагаться на то, что агенты вам говорят.
Мы начали говорить про тесты. И сами по себе тесты становятся очень важны. На
них просто давление возрастает. не только физическое, но и психологическое,
потому что полуреквестов становится больше. Я уверен, что команды, которые очень
активно агенты используют, это все наблюдают у себя очень ярко. Вообще -то, сами
тесты становятся больше на критическом пути, потому что код теперь писать проще
и быстрее. Ну и агенты сами на тесты полагаются в значительной степени.
Соответственно, если тесты флапают, то агент примет какое -то совершенно
небесказуемое решение. Поэтому нужно тесты делать быстрыми, стабильными,
нужно уметь хорошо масштабировать по железу вашу вся инфраструктуру,
ну и вообще -то как следствие, вообще говоря, оптимизируя всю СРЕшную нагрузку и
делать автоприемку. И это само по себе отдельная интересная задача, которая
раньше в таком масштабе не стояла.
Мы вот у себя тоже цель на флаг взяли и обнаружили внезапно, что те тесты,
которые раньше были супер долгими, сложными, когда, знаете, в изолидном
окружении поднимается практически интеграционный тест на слепке продакшн базы,
обстреливается слепком продакшн запросов. Классный, но тяжелый тест. Эти тесты
оказались сейчас уже быстрее, чем весь слепок вроде бы более простых
тестов, я имею в виду юниты какие -то функциональные, потому что в
монорепозитории все сервисы быстро обрастают лишними зависимостими и по этим
зависимостим притягивается сильно больше тестов, чем хотелось бы. И с одной
стороны, получается, в первую очередь, надо эти зависимости поспиливать. С
другой стороны, есть действительно файлы, у которых слишком много зависимости,
например, какие -то базовые протобув -схемы, и в этом случае нужно умно
понимать, какие тесты запустить, а не просто все подряд, которые вроде бы
формально от этого файла зависят. И это вообще -то непростая бакондирская
задача.
Не всем, конечно, хочется оптимизировать тесты, как будто есть много других
интересных задач на свете,
Хорошо, что это можно поручить агенту, но в этой ситуации вы, конечно, уже
агенту будете формулировать не тикет, видимо, вот тикет, иди и сделай, а вы
будете давать ему метрику целевую, которую нужно ему оптимизировать, давать ему
бенчмарк, и чтобы он дальше погибел какие -то гипотезы, на бенчмарке попроверял,
насколько они выстрелили.
И за несколько итераций, не знаю, на выходные можно его оставить, в понедельник
утром прийти посмотреть, что получилось. Здесь тоже есть, конечно, подстава. Ну,
этот подход, вообще, изначально был описан Карпатом в контексте обучения LLM.
Потом его подхватили и популяризовали тоже разные компании, например, Shopify,
как раз в контексте оптимизации CI -пайплайнов про авторесерчи рассказывал.
Мы у себя тоже его применяем и столкнулись с интересным эффектом.
Очень велик соблазн, взять какую -то существующую библиотечную функцию, которая
светится на Flame -графах по всей компании. Ну, вот мы рассказываем про
перфоратор периодически. Это помогает понять по всей компании, какие функции
чаще всего используются. Такие функции берешь в виде шага. Бенчмарк там 10 лет
назад написан. Давайте -ка агенту скормим и, скажем, пооптимизируем, посмотрим,
что получится. К сожалению, эти бенчмарки часто оказываются нерепрезентативны.
Агенты эти бенчмарки хакуют, и бенчмарки проходятся лучше, а в продакшене в
итоге получается фигня. Какой -то эффект есть, но не такой большой, как хотелось
бы. Бенчмарки супер важны. И вот как раз, вспоминая предыдущий слайд, когда я
говорил про сложный тест, слепок продавшим базы, слепок запросов. Вот на таких
нагрузочных тестах как раз хорошо строят такие агентные циклы и мы таким образом
уже несколько тысяч CPU сэкономили. Короче, классная тема, только с бенчмарками
нас запарит.
Ну ладно, я вообще -то не хотел слишком много говорить про агентную разработку у
нас в этой конференции. Не совсем про это.
На примере рекомендательных систем расскажу немного о том, как меняется сама
архитектура таких систем.
Вообще рекомендательные модели довольно давно развиваются, Поэтому чуть -чуть по
истории пройдусь, самые простые рекомендательные модели, которые наверняка вы в
своих системах использовали, это градиентный буштинг, наверняка слышали про
MatrixNet или CatBoost. И эти модели, с которыми супер легко работать, я даже
обучал такие и сам, собственно, даже переписывал в библиотеку, по -моему,
который с ними работает,
берете, вычисляете факторы, которые нужно подставить, берете библиотечную
функцию и перейдете туда, это самый, ну, буквально, бинарный файл, Запускайте,
получайте score, score – передайте в аранжирование, всё, ни о чём думать не
нужно, красота.
Дальше модели активно развивались, появились нейросети. И, в частности, очень
популярны в рекомендациях моделях двухбашенные нейросети.
История такая, вот у вас есть, допустим, пользователь и документ. И вы хотите
оценить вероятность, например, с какой вероятностью этому пользователю этот
документ полезен. Или есть пользователь и товар, с какой вероятностью этот
пользователь этот товар купит. Ну опять же, какой -то score для некоторого
аранжирования нужно посчитать. Как это делается, в случае двухбашной нейросети,
есть у нее практически независимые части. Одна часть смотрит на факторы
пользователя и вычисляет некоторый вектор эмбединг пользователя, другая часть
вычисляет эмбединг документа, они друг другом никак не связаны, и в самый
последний момент эти векторы перемножаются и получается итоговый скор.
Почему я вам бэкендером показываю архитектуру нейросети? потому что, если бы это
был просто черный ящик, то вам нужно было бы для каждой пары пользоваться
документом, запускать офигенно тяжелую нейросетку, и это было бы просто очень
долго, ни в какие сотни миллисекунд это не пролезет. А когда у нее такая
архитектура, можно запустить верхнюю часть, первую башню один раз на запрос,
вторую часть запустить буквально при обновлении базы один раз на документ, и
в самый тяжелый момент, в самой критической секции, просто эти векторы не
слишком большой размерности перемножить. что это уже операция, которая легко
оптимизируется, бочуется и так далее.
Ну вот, видите, бэкэндерам здесь пришлось это учитывать. Ну ладно, это как бы
уже пять лет назад, этим было никого не удивить. Что же происходит сейчас?
Сейчас большие языковые модели часто построены на архитектуре трансформеров и
умеют хорошо работать с последовательностью объектов. Ну вы знаете про токены,
да? С последовательством токенов они работают, умеют в частности предсказывать
следующий токен. Где же это полезно в рекомендациях? Давайте представим
пользователя не как набор численных факторов, А как набор действий, которые он
совершал? Вот он что -то поискал, куда -то кликнул, с каким -то еще объектом как
-то повзаимодействовал.
Вопрос к нейросети — а что же он сделает дальше? Вот так и получаются
рекомендации в такой архитектуре нейросетей. Но опять же, хочется это делать
эффективно, при этом запуская нейросеть несколько раз на одной и той же довольно
длинной истории пользователя. Соответственно, придется погрузиться в кишки и
понять, что там с этой историей происходит. Один из ключевых элементов
трансформера это attention, внимание, еще сегодня про это поговорим.
И attention для этой самой истории вычисляет keys и values, k и v. И
соответственно, если вы хотите что -то закэшировать, то именно k и v вам нужно
закэшировать. Поэтому есть термин kv -кэши, про который вы тоже, возможно,
слышали. И в контексте закэвых моделей, и в контексте рекомендаций тоже он
становится важным. И здесь, правда, приходится думать, а этот, конечно, должен
быть в оффлайне или в онлайне. Это правда, если от того, как у вас рекомендации
устроены, в общем, бэкэндерам все глубже приходится погружаться и перестраивать
архитектуру своих систем под современные рекомендательные модели.
Еще один тренд в рекомендациях неожиданно связан с монолитизацией. Кто из вас
хоть раз оспиливал монолит на микросервисы?
Больше половины зала, мне кажется. Ну, конференция про бэкэнд. Нормально, похоже
на правду. Иначе вы туда попали. Понимаете, в чем профит. У вас
сервисы становятся меньше, энтропии уменьшаются, релизы можно катать чаще, time
-to -market фич улучшается. С другой стороны, контекст, который надо понимать в
контексте каждой фичи, контексте каждого сервиса, тоже уменьшается.
Соответственно, разработчику проще новому погружаться, а агенту проще в этой
системе что -то менять. Более того, у меня год назад был проект -доклад на этой
конференции. Если вы не слишком много CPU потеряете на передаче данных между
микросервисами, на осилизацию запросов, десилизацию ответов, тогда вы можете еще
и CPU сэкономить за счет улучшения локальности по коду и по данным. У вас
буквально процессные инструкции будут лучше попадать в каши процессора, и данные
можно лучше покашировать. Ну, в общем, ладно, что я вам рассказываю, значит
распиливать модели это ценно. Но в контексте рекомендательных систем, а
конкретно в контексте кандидата генерации, это стадия, после которой
поплевываются кандидаты, которые дальше в аранжирование попадают. Там возникает
обратный тренд. А именно инженеры из одного экстренистского биктеха в своей
статье Silver Torch описали, как они в стадии кандидата генерации,
буквально векторный поиск, поиск ближайших соседей в том самом пространстве
векторов имбендингов с предыдущего слайда, фильтрацию этих кандидатов в
переранжирование перекладывают на GPU. Почему это ценно? Потому что эти стадии
работают с одним и тем же большим массивом кандидатов И связанными с ними
тензорами совершенно не хочется это передавать по сети и как -то перекладывать
из памяти в память. Поэтому эти стадии все переписали на GPU.
INN -поиск стал буквально GPU -native PyTorch -модулем. Фильтрация теперь
стала делаться не инвертиранными индексами, как все привыкли делать,
а Bloom -индексом GPU -friendly, буквально набором Bloom -фильтров. Ну и в итоге
получился PyTorch -граф, который, во -первых, инженер может оптимизировать как
цельный граф между стадиями. И, во -вторых, GPU -компилятор может фьюзить
некоторые операции и уменьшать перекладывание промежуточных тензоров.
Ну, вы не думаете, конечно, что когда возникает GPU, сразу же микросервисы
больше не нужны. Естественно, когда мы inference делаем,
мы inference выселяем в отдельный микросервис. Но конкретно в той ситуации,
когда вы работаете с большим набором объектов, и он же воспроизведет между
несколькими статями, конечно же, имеет смысл это все побендлить и объединить в
один Pytorch Graph, например.
Так, довольно про рекомендательные системы. Я обещал про новые классы задач,
которые возникают в нашем чудесном мире.
Ну, смотрите, что мы знаем про новые продукты, которые в мире возникают.
Агентные системы просто, и ассистент. У вас есть LLM -ка, в пользу от нее подает
запрос, ожидать получить какой -то ответ. Вроде бы легко.
Ну и изначально буквально и ассистенты так и выглядели. Там сложность была
только в том, чтобы эффективный инференс этой большой нейросети выполнить, но
там КВКши может какие -то сохранить. Тем не менее, пока вроде бы легко. Но
вообще -то современные агентные системы сильны именно своей агентностью, то есть
тем, что они могут запускать какие -то тулы, какой -то код могут написать. Меня
это в свое время очень впечатлило, что нейросетка не полагается на то, что она
может сама числа сложить, она лучше питонский код напишет, который складывает
числа и выдаст мне ответ оттуда. Ну, соответственно, мы должны быть готовы к
тому, что выполнение польского запроса пойдет по какому -то непредсказуемому
сценарию. И граф, вообще говоря, будет динамичен. Там может быть роутер в этой
схеме, может его не быть. Может быть, LM -ка будет сама решать, что ей надо
сейчас вызвать какие -то тулы, а потом еще какие -то тулы вызвать, а потом
вызвать другую LM -ку, которая хорошо обрабатывает другой сценарий. Получается
какой -то граф, по которому запрос ходит совершенно непредсказуемым образом, и
это становится абсолютным кошмаром SRG -шника, который пытается такую систему
поддерживать. Более того, какие -то ветки этого графа могут выполняться часами.
Ну, потому что это может быть какой -то сложный агентный сценарий разработчика.
Или, может быть, агент пытается дозвониться до каких -то ресторанов и там что
-то забронировать.
Понятно, что очень тяжело поддерживать систему, которая может работать секунды,
а может работать часы. И, конечно, в такой случае надо думать про надежность.
Надо рассматривать сценарий, когда у вас порвалось часть соединения, вам нужно
откатиться назад, попробовать снова, вам нужно уметь засейвиться, подняться с
чекпоинта, снова продолжить выполнение, и при этом, если у вас есть побочные
эффекты какие -то в процессе, нужно их не повторить, то есть надо подумать про
idempotentность.
Конечно, если мы говорим про выполнение кода,
надо уметь поднимать какие -то изолированные среды и в них выполнять этот код. И
отдельная интересная часть — это стриминг. Вы как пользователь ожидаете, что вы
не будете штырить в белый экран на протяжении несколько часов, пока неросетка
вам что -то отдаст. Вы хотите видеть, как она думает, на чем она сейчас думает.
Если она уже пишет ответ, вы хотите видеть, как она этот ответ пишет. Это уже
такая важная продуктовая фича. С одной стороны, с другой стороны, когда есть
некоторый аркестратор, который понимает, что сейчас надо вызвать такой татул с
такими -то аргументами, то же, чем раньше он про это узнал, из ответа неросетки
тем лучше. Поэтому вот на всех этапах в этом графе важен стриминг. Ну и понятно,
надо следить за эффективностью всей этой системы, как -то оно балансировать.
Нужен какой -то observability -слой, чтобы смотреть на тресы и дебазы, что же
там происходило. Короче,
вы не фоткайте, там сейчас доклад про это будет в этом же зале.
Про изоляцию сейчас еще немножко поразгоняю. Изоляция в продакшене это вообще
-то не что -то новое. Ну, мы как минимум все в облаках живем, практически, И
понятно, что нужна изоляция, нужно уметь селить несколько сервисов на одну
машину.
Но одно дело изоляция в продакшене. Другое дело, когда изоляция, ну и вот все
эти внешние интеграции, какие -то дерганьеапишек, когда они возникают в тестах.
Никто не любит делать интеграционные тесты. Но если кто -то любит, поднимите
руку, интересно с вами познакомиться.
О, ну 10 человек, нормально, все похоже на правду.
И потому что моки нужны какие -то, какие -то тестовые стенды. Ну, в общем,
неприятно. Но это ладно, в общем, сейчас будет хуже. Дело в том, что, когда
обучается сложная модель с агентным поведением, там есть очень важная стадия
обучения с подкреплением. Рефорс Метленнинг. И в процессе такого обучения нужно
запускать эту самую модель, на каких -то входных примерах, давать этой модели
пройти свои траектории, подергать тулы, поменять состояние мира, как говорят
люди, которые это делают.
И по итогу вычитается некоторый реворд. как бы модель, выдаются награды, или не
выдаются. И он обратно подается в процесс обучения. То есть, у вас есть
GPU -шка, дорогущий кусок кремния, который обучает модель, перемножает матрицы,
и вам суперважно следить за его утилизацией. А параллельно с ним сожительство,
не сам приедет сожительство, должен сказать, вот эта штука, которая поднимает
изолированные среды в огромном темпе. И если она будет подтормаживать, тогда у
вас GPU -шка будет недоутилизирована, и дорогой железу будет простаивать. Вообще
-то очень неприятно,
и в современных агентных системах речь идет уже о сотнях поднимаемых сред в
секунду и об SLA в сотни миллисекунд на выдачу очередной среды
из некоторого горячего пула. Кто бы мне пять лет назад сказал, что нужно с таким
SLA поднимать изолированный контейнер, я бы не поверил. Сказал бы, зачем это
нужно вообще. А тут, когда GPUшка возникает, которая параллельно об это все
блокируется, Ну, деваться некуда, приходится такую проблему тоже решать, и мы ее
тоже решаем.
Как видите,
мы сейчас закольцовываемся с первой темой. Я в самом начале тоже рассказывал про
агентные pipeline, про оценку качества, про то, что нужно агентам не
подглядывать в то, что делают соседние агенты. В общем, правда, темы очень
плотно друг к другу связаны. Вы наверняка уже поняли, насколько меня
вдохновляет, решая задачи, которые до этого почти никто не решал. Уверен, что у
вас тоже. Потому что конференция у нас как раз про это. Какое совпадение.
Так что, если вы еще не изучили нашу программу, обязательно изучайте. Очень
советую выбирать те темы, которые вызывают у вас удивление. Это же ценнее, да,
сходить на доклад, про который вы ничего не понимаете.
Так что, слушайте спикеров, общайтесь и со спикерами, и друг с другом тоже.
Вдохновляйтесь, и продуктивного всем дня.
Антон, спасибо большое за доклад. У нас конкретно докладу
Антона вопросов сейчас не будет, поэтому Антона можно поймать в течение
всего сегодняшнего дня на стендах у вопрос -ответ или просто где
-нибудь на территории. Сейчас у нас 10 -минутный перерыв до 12 .30.
Соответственно, в 12 .30 на разных треках начнется свои
доклады. А у нас через 10 минут здесь будет доклад Алексея
Логинову из команды ALICE про то, как строить надежную агентскую
платформу. До встречи через 10 минут.