Transcription
Меня зовут Лыков Александр. Я буду модерировать сегодня наш вебинар. Правила простые. Вопросы можно писать в чат, а можно даже писать в Telegram. Мы будем их транслировать докладчику, а либо я буду на них отвечать.
План у нас стандартный. Я расскажу, представлюсь поподробнее, расскажу про нашу школу, расскажу, а про нашего докладчика. Сегодня про Глеба. Глеб, э, э, расскажет интересный сюжет из мира и агентов. И в конце мы задаём ему вопросы про, собственно, про то, что он рассказывал и по новому курсу. Наш вебинар приурочен к новому курсу, посвящённому агенту как раз КПО автор. А вот про всё это мы поговорим. Такой план. Запись будет.
Значит, меня зовут Лыков Александр. Я, как я уже сказал, я академический руководитель. в школе высшей математики. А эта школа существует достаточно давно, с девятнадцатого, с двадцатого года. Там мы фокусировались на на преподавании э высшей математики, программирования. И вот последние пару лет делаем образовательные продукты в связаном с искусственным интеллектом, ну, в основном сной, с лмами. Вот такая история. Значит, запустили ряд, успешно запустили ряд курсов, связанных сл.
Вот, значит, наш докладчик сегодняшний, да, если можете посмотреть вебинары, мы проводили, проводим вебинары переческие, на Ютубе есть. Значит, наш сегодняшний докладчик зовут Глеб. Он работает в Сбере. Кто не в курсе, в России сейчас, наверное, одно место есть, где делают агентов и и Ллмы на таком серьёзном промышленном уровне, сопоставимом хоть как-то западными аналогами, это Сберы. А остальные игроки, так как скажем, они, ну, немножечко уступают а Сбербанку. В Сбербанке просто шквал движений, очень сильные команды, люди, везде это применяется успешно. Это мейнстрим в нашей стране. Вот. И Глеб работает в одной из таких команд внутри Сбербанка, э, в которой разрабатывают лмантов. Вот проект Глеба, в котором он участвовал, успешно летит. Все к нему хожут, просят что-то поднастроить, улучшить. Вот так коротко наше докладчики. Глеб, пожалуйста, тебе слово.
>> Да, спасибо. Так, сейчас запущу. Ну, в общем, Александр меня представил. Действительно, я работаю в Сбере. Это правда. И сейчас я работаю в центре исследований. То есть мы занимаемся агентами, строим такие достаточно большие агентские системы для непосредственно ресерша, для исследования, а для улучшения автоматически это автоматического существующих решений. А, но, в общем, так у меня получилось, что до этого Так, сейчас я презентацию ещё запущу, чтобы она уже висела красиво. Значит, ситуация такова, что да, я сейчас нахожусь в ресрчерской команде, но до этого я работал и в продуктовой команде, то есть мы там вообще, в принципе, разные модели запускали, но вот одна из последних - это именно агентская система была, а, и поэтому, ну, вот она прямо вышла в продакшн, то есть буквально, э, поэтому я примерно понимаю, о чём, в общем-то, говорю, и надеюсь, что смогу вам рассказать. рассказать что-то интересное, а, ну, и, в общем-то, поделиться, может, ну, конечно, я тут какими-то совсем инсайтами, естественно, там делиться не буду, у нас нет на это времени. Это будет такой обзор в целом существующих интересных решений. И, э, как бы ключевой посыл, в принципе, всей этой презентации состоит в том, в чём вообще промышленные решения агентские. Вот агентские системы, которые действительно работают в больших компаниях, они отличаются от того, что вы можете найти, ну, в каких-то там шаблонах, в каких-то открытых репозиториях в интернете. Ну, потому что я тоже в своё время начинал, м, когда разбирался в агентах, ну, конечно, гуглил, смотрел, что там есть интересного, а всякие есть интересные, хорошие курсы на лонграфи и так далее. Э, но по факту мир агентов, вот что я заметил, да, что мир агентов он намного более разнообразный, намного более интересный и сложный, чем, а, вот при таком, а, чем кажется при первом таком погружении, да, когда вы только смотрите на какие-то на какие-то туториалы, на какие-то существующие там решения и так далее.
Так, ну что ж, а давайте приступим. Значит, ну, вообще, первым делом давайте вообще освежим немного память, вообще вспомним, в принципе, что такое агент, как он работает, как когда он примерно появился. А, то есть это чаще всего на данный момент ожестляют именно с большими языковыми моделями. А, хотя по факту на самом-то деле там агентом может быть и какая-то другая сущность, но вот принято говорить, что это именно большие языковые модели, то есть элмки. А ключевой особенностью агентов, а ключевая их особенность заключается в том, что они самостоятельно умеют принимать решения и, э, каким-то образом взаимодействовать с чем бы то ни было. Это может быть внешняя среда, это может быть сам человек. А, то есть это ключевая именно логика вот именно агента, да. Чем это отличается от просто, а, рассуждений Ллэмки, которая, наверное, знакома всем, потому что все там так или иначе пользовались какими-то языковыми моделями, и все там знают, что есть кнопка думать, нажав на которую, вы видите, как рассуждает агент. Вот ну, не агент, а языковая модель. А агент он помимо рассуждения ещё умеет что-то исполнять, вызывать что-то, какие-то функции вызывать как и каким-то образом взаимодействовать с средой, которая ему была дана. Ну вот мы сейчас на разных схемах, в принципе, посмотрим, а что это такое. Ну да, то есть это восприятие среды и данных, в которых он находится, а планирование принятия решений, выполнение действий и анализ результатов. Ну вот классическая схема агента. То есть что здесь происходит? А мы видим, что существует несколько ключевых ключевых моментов у агентов. Это непосредственно сама языковая модель, а это среда, с которой она взаимодействует. Это тулы, то есть инструменты, функции, которые доступны этой этому агенту и память. Ну, память очевидна, да, понятно, что это. Это контекст, который модель погружена. А что такое инструменты? Ну вот инструменты - это ровно то, о чём я и говорил. А вот самый такой простой пример, который приходит в голову. Ну как бы языковые модели, они, конечно, умные, но они там не очень хорошо считают, например. Ну, считают, в смысле, там делают какие-то большие вычисления, там очевидно, что калькулятор какой-нибудь, да, это делает на порядок лучше, быстрее, там, с огромными числами и так далее. Ну и как бы вот, допустим, перед нами стоит какая-то задача, да, вот что-то решить, решить какую-то задачу, и там есть составляющая на подумать, да, то, чего калькулятор не умеет, а есть составляющая там в конце просто посчитать, подставить числа. И мы хотим это полностью автоматизировать. Ну, как бы можно там пытаться заставить модель, чтобы она там сама как-то посчитала. А можно дать ей инструмент калькулятора. То есть дать ей свободу выбора, что вот тебе задача и вот что ты можешь делать, да? Ты можешь, например, думать, рассуждать об этой задаче, а можешь использовать калькулятор. И языковая модель сама принимает решение, что ей делать. В момент, когда она придумывает решение и понимает, что осталось подставить какие-то большие числа, она будет использовать эти будет использовать инструменты, доступные ей, в данном случае калькулятор, чтобы посчитать нужное, ну, конечный ответ. А, ну это, очевидно, простой пример. Здесь можно бесконечно представлять, какие простые инструменты можно давать нашему агенту. можно давать там какой-нибудь поиск в браузере, можно давать, э, не знаю, там вычисление каких-то своеобразных функций, исполнение коды и так далее. В общем, нагрузить её можно можно и очень сильно обогатить, да? То есть для чего это сделано? Для того, чтобы преодолевать естественные барьеры, которые существуют у языковых моделей. Ну, в частности, например, счёт, да? О'кей.
Ну, про историю в целом, я думаю, что это полезно понимать, с чего всё начиналось. Это относительно недавняя история, ну, относительно принципе языковых моделей, да. Вот. Ну, и, конечно, первым таким, первым таким агентом это, можно сказать, был, э, чат GPT, так называемый WebGPT, который в двадцать первом году появился. То есть это поиск в интернете. То есть по большому счёту модель сама принимала решение, когда, ну там, вернее, не совсем, конечно, она сама принимала решение, когда начать поиск в браузере, потому что обычно это, э, там указывалось человеком, надо ли это вот это в самых-самых первых версиях. Потом, конечно, дали возможность самостоятельно рассуждать о том, что нужно ли искать информацию в браузере. Вот вначале там именно она как бы принудительно искала в сети, то есть как бы там нажималась нажималась кнопка, соответственно, поиск в сети и искалась нужная информация. А, ну, в данном случае она принимала решение, когда собранной информации достаточно, то есть когда шерстить какие-то там ссылки, сайты уже хватит, когда по вот когда по мнению самой языковой модели достаточно информации, которая была найдена в интернете, чтобы ответить на поставленный вопрос, в этот момент она это заканчивала, а, заканчивала этот процесс. Ну и это действительно интересно, потому что это первый случай, когда языковой модели дали какую-то свободу действий. А, ну там опять же с оговоркой, что вначале этого не было, потом это поправили. Но в общем смысл в том, что да, свобода действий, она сама как бы решает вот идти в интернет, не идти в интернет, достаточно ли у неё знаний, чтобы просто ответить на этот вопрос или нет, или же нужно пойти в веб и что-то найти. И, соответственно, когда информации достаточно.
А дальше ещё более продвинутая вещь, React, который буквально расшифровывается как reason п actяся в 2022 году. А система следующая. А значит, нам приходит какой-то запрос, и языковая модель думает и даёт какую-то определённую вот в моменте рассуждения она заранее видит все функции, которые ей доступны. Я буду говорить ещё иногда тулы, потому что, ну, просто так удобнее, там тул-тул, поэтому тулы и функции - это одно и то же. Она видит все доступные ей тулы, функции. И в цепочке рассуждения она говорит, она сама о себе как бы намекает, что вот здесь было бы хорошо, точнее, она это явно прописывает. Вот здесь было бы хорошо вызвать такую функцию. Вот на следующем примере, на следующем слайде подробнее это увидим. После того, как она вызвала ту или иную функцию, она получает результат этой функции, она снова думает о том, а вообще как бы что что мы здесь получили, достаточно ли этого для решения этой задачи или нет. А если достаточно, она идёт дальше по цепочке рассуждений. Если недостаточно, то она может либо повторить вызов этой функции, а либо вызвать другую функцию, доступную ей. В общем, это происходит до тех пор, пока она сама не принимает решение, что нужно дать определённый ответ. Ну вот справа здесь такой простой относительно пример. Это openсоourceный проект Small Legend. Такой достаточно легковесный, простой, да. Вот есть такой вот он использует вот это обычный такой типичный React, который, э, по большому счёту просто, ну, он там пишет код и пишет он его до тех пор, пока, ну, дана какая-то изначальная задача, генерируется код, код прогоняется в определённой песочнице, а вызов, например, прогона кода в определённой песочнице - это тоже тул. И вот до тех пор, пока пока языковая модель не решит, что всё-таки задача изначально решена, решена она хорошо, этот цикл не будет установлен. Остановлен. Ну, естественно, при прочих равных там, конечно, какие-то будут ограничения на количество этих хопов, да, на количество циклов, но в общем случае это будет так. Ну и, кстати, вот уже даже вот эта схема вот Реакт агента, она применяется, ну, прямо в очень-очень больших количествах там, скажем так, уже существующих каких-то агентских систем. Это очень простая и наивная вещь, но она очень часто работает. То есть, когда не нужно пользоваться какой-то чудовищно сложной архитектурой, то кажется, что Реакт агенту он вполне подходит для какого-то простого решения. Ну, когда он там может пригодиться, условно, если, ну, да, допустим, вам нужно как-то не очень глубоко и сильно улучшить не очень большой код. Вот ровно то, что делает small агент, он улучшает код по заданному какому-то промпту. Ну там соображения, улучшения могут быть совершенно разные. Вот, например, просто банально, чтобы он заработал, да? Вот код, допустим, не работает, там, не знаю, какой-нибудь там какая-нибудь там не модель нейронки написана. Вот она почему-то не работает. О'кей, мы скармливаем это реакту, и она пытается его там как-то переписывает, дополняет какими-то новыми функциями, но новым кодом до тех пор, пока не заработает, как надо.
Так, ну вот пример это из оригинальной статьи Прореact. А, то есть вот здесь вот в правом нижнем углу показана вот эта вот логи. Нет, в правом верхнем тут поинтереснее, потому что здесь именно тулы. То есть идёт какая-то мысль один, да, после этого вызывается какая-то функция, в данном случае search, получается какой-то результат. После этого снова происходит мыслительный процесс и снова вызывается search. Ну, тоже достаточно достаточно простая схема. Аа после этого начались интересные вещи, стали появляться новые архитектуры, новые решения, новые идеи. Э выделил несколько. А, и вот здесь, кстати, мы уже подходим к вопросу о том, а вот, например, про такую штуку, как Toolформер, я, честно говоря, ни в каких туториалах вообще не видел. А это интересно, потому что я точно знаю, вот конкретно мы, я это не делал, но я точно знаю команды, которые использовали до обучения модели. Ну, сейчас вот поговорим, в общем, пролформер. В общем, это до обучение модели, которая которую дообучают таким образом, чтобы она вызывала хорошие апи. А как это происходит? Ну, у нас есть какой-то датасет, да, э, размеченный, и у нас есть какой-то какие-то примеры вызовов AP. Ну, AP и колы - это, в данном случае, тулы, которые функция может вызвать. Есть примеры плохих результатов от апи колов и хороших от апи колов. И текст размечается вот этими самыми вызовами тулов, вызовами апим. И, соответственно, они размечаются таким образом, что там, ну, обозначается хороший это вызов Апикола. Ну, в общем, происходит классический фантюнинг до обучения, но вот именно с такой разметкой, да, хороший это вызов Апекола или плохой вызов Апекола. И вот эта штука отметы, так, да, вот эта штука Лфорформер отметы, она получила очень очень хорошие результаты. И э вот один из примеров, как действительно можно глубоко и интересно рассматривать агентские системы. То есть это уже не просто какой-то такой, да, а действительно, ну, настоящий полноценный DS, когда мы дообучаем нашу модель на корпусах текстов, которые предварительно размечены с правильными с правильными вызовами тулов.
А далее идут тоже очень интересные новые структуры. То есть я напоминаю, вот так опять я разучился переключать слайды. Напомню, что вот это был Reactгент крайне простой. А, и в чём, конечно, здесь проблема? Ну, проблема в том, что, э, у вас всего лишь по большому счёту, а, один процесс оценки, то есть всего лишь одна, что называется, нода, вершина, которая что-то обрабатывает и думает о том, как ээ и и и и принимает решение о том, продолжать этот цикл или нет. По сути, у неё нету больше никаких возможностей, а, ну, в общем, ничего больше она делать не может. Она может просто вот этот цикл э бесконечно долго а крутить. И если у нас было какое-то решение, например, неправильное до этого, то нода, э, вот подумать, да, вот она скажет, она просто его забудет, потому что она его забракует и дальше пойдёт, значит улучшать тот код, который, ну, был изначально. То есть никакой связи между решениями, даже казалось бы, плохими, в принципе, нет. Они все отсекаются, если не прошли по одному критерию. А, ну, это чревато тем, что, во-первых, могут быть какие-то хорошие решения, которые каким-то образом не прошли там, допустим, финальную проверку, а, но они могут быть каким-то образом значительно улучшены с помощью, допустим, других нот, других, э, языковых моделей, которые устроены, допустим, по-разному, по-другому, у которых другой системный промт или это просто другая, в принципе, языковая модель, да, потому что есть языковые модели, которые лучше рассуждают, например, строят план вашего решения, есть языковые модели, которые лучше пишут код. Ну, кажется, разумно в разных местах использовать разные. Вот. Ну, и как бы развитие вот этой вот мысли, да, оно порождает концепции дерево рассуждения и граф рассуждения, то есть трио тот и граф от тотс. Аа, да. Ну вот да, вот это действительно интересная история, потому что вот это дерево рассуждений, опять же, предположим, что у нас а есть задача по там улучшению архитектуры чего бы то ни было, там, допустим, существующего решения. То есть, допустим, а мы решили придумывать такого агента, который, аэ, который просто будет улучшать текущую архитектуру, ну, опять же, какого-то там, допустим, кода, например. А как это сделать? Ну, наверное, не самое правильное будет прямо вот сразу же пытаться исправить, да, сразу же исправить код, сразу же что-то вот там улучшить. Наверное, интереснее будет сначала попросить модель, чтобы она придумала какие-то варианты улучшения. То есть буквально, чтобы она дала какие-то какие-то определённые, да, идеи, которые друг с другом не пересекаются, чтобы они были разные, разнообразные. И после этого по каждой из этих идей, э, спускаться вниз. То есть, например, вот вам дана какая-то одна идея и ээ дальше агент начинает её развивать, развивать, развивать и заканчивает он это тем, что пишет код и, ээ, ну, исполняет его. Ну, то есть наконец-то вот мы говорили, что изначально у нас задача по улучшению архитектуры существующего кода, а, и в конце он должен его исполнить, как-то проверить. И в данном случае, ну, вот эти витвления, да, то есть он на каждом шаге, допустим, вот, допустим, у нас было изначально три идеи, там на каждый из три идеи он может написать какой-то он может предложить какие-то конкретные шаги, вот прямо конкретные шаги, что нужно сделать с кодом. И на каждом, ну, от каждого это шага, от каждого шага потом пойдёт уже непосредственно писание самого кода. И вот в этой вот цепочке, ну, естественно, наверное, не нужно их все параллельно исполнять. Хотя, кстати, про параллельное исполнение мы тоже поговорим, но тем не менее мы будем приходить к какому-то конкретному решению. И смысл в том, что у нас на каждом из этапов а будет какой-то результат. И мы этот результат мы сможем дать как бы снизу такой бектрекинг, то есть фидбэк верх идущим нодом о том, а что же, собственно говоря, случилось. Вот если у нас код конечный получился плохой, ну, допустим, он, ну, он запустился, но там плохо, ну, плохая архитектура, то есть м сама себя оценила, сказала: "Нет, код, фигня". Она может дать информацию, это ноде выше, это нода обновиться, а предыдущая нода у нас была про там, допустим, планировщик действий. И, э, эта нода просто сама по себе обновляется, то есть она принимает информацию, у нас отсекается это решение, но тем не менее при дальнейших решениях мы сможем использовать эту информацию. То есть вот то решение, оно не просто потерялось навсегда, а наша система как бы её запомнила. И теперь, если мы дальше когда-нибудь пойдём по вот этому же сценарию, то, ну, как бы мы будем иметь в виду, что вот тот путь, который был, вот конкретно эта реализация, она была, допустим, не очень хорошей. Ну, и вот развитие этой идеи - это, а, графовая структура, называемая граф. Тут не просто мы можем удалять ноды и давать фидбэк предыдущим, да? Вот у нас как раз-таки посередине здесь дерево, про которое мы говорили. А, э, мы можем некоторые ноды объединять друг с другом. То есть это получается уже полноценный граф. А когда, допустим, у нас разные идеи, которые мы сгенерировали ранее, мы их можем, допустим, объединить в одну с учётом фидбэка, который отработал по каждой из них, как вариант. Ну, это действительно интересно. То есть это намного уже более уже намного более серьёзная структура по сравнению с обычным реактом. То есть вот такой даже небольшой, ну, казалось бы, это достаточно естественное естественное решение, естественная идея о том, чтобы не просто выкидывать какие-то плохие решения, а помнить их, помнить их, объединять и давать агенту всё больше и больше свободно. И вот здесь, кстати, да, хочется тоже сказать, что чем больше, чем сложнее у нас архитектура, тем больше мы даём свободу, в принципе, агенту, тем менее детерминированная наша система. И когда мы говорим про какую-то промышленную разработку, то здесь очень важно сохранять вот этот трейдов. То есть очень важно всегда понимать, насколько вы можете себе позволить систему менее или более детерминированную. Потому что, ну, действительно, вот если мы говорим, что каждая нода вот справа, да, в нашем графе - это, ну, какой-то шаг агента, и мы понимаем, какое количество вариантов будет в, скажем так, в перспективе какой-то, да, то есть, чем глубже наш граф, тем тем тем больше вариантов, то система становится очень непредсказуемой и очень тяжело дебажить, да, очень сложно В принципе, очень сложно, в принципе, понимать, что если что-то сработало не так, то почему именно это сработало не так. И, соответственно, время на дебак увеличивается, время на починку потенциально увеличивается, увеличивается и время на то, чтобы как-то пересмотреть архитектуру, ну, оно и его уже, скорее всего, не будет. Особенно, если мы говорим про какие-то конкретно промышленные решения, где непосредственно пользователи в реальном времени взаимодействуют с вашим агентом. Отсюда вывод. Если вы занимаетесь ресерчем, а я считаю, что, ну, на мой взгляд, resarch - это, наверное, самое такое перспективное направление в использовании агентов, одно из самых перспективных, то да, тут нужно действительно можно и нужно выбирать сложные структуры, выбирать экспериментировать и пытаться дать агенту столько как бы свободы, сколько, наверное, возможно. при этом не потеряв управление. Если же мы говорим про конкретно относительно небольшие промышленные решения, когда вы не можете просто себе позволить, чтобы ваша система думала по несколько минут, то тогда нужно сжимать, нужно упрощать и нужно думать именно в сторону скорости, а там низкого низкой низкого латенси. и в принципе упрощение работы с агентом.
А далее ещё некоторые такие майлстоуны. Э-э, ну вот когда мы говорим о том, что агент умеет умеет, в принципе вызывать какие-то тулы, ну, косвенно, на самом деле вот эта логика рефлексии, она заложена и в и в графовом и в графовом э в графовой модели агента, но здесь она выходит на передний план. То есть, э, мы хотим, чтобы наш агент всё время занимался вот этой вот саморефлексией, да, и, а, ну, по сути, тоже использовался определённый цикл взаимодействия с самим собой. А, но это уже не просто в виде цикла, а в виде полноценного инструмента, в виде полноценной тулы. То есть можно вот дать именно такую тулу, да, как reflection. То есть мы говорили, что вот функции могут быть там простые, да, по типу там калькулятора, да, могут быть сложными какими-то. И ну почему бы нам не наградить нашего агента функции и рефлексии, да? Почему бы нам не на, ну, не сказать, типа, думай дольше, а, подумай о том, не просто сказать, да, а прописать вот именно такую функцию, которая, э, вызывая которую агент понимает, что ему нужно, а, самооценить то, что он делает на каждом из шагов. А, ну и уже как бы такой второй уровень ещё более продвинутый. То есть до этого мы говорили про одного агента, да, вот один агент там расписывает шаги, один агент вызывает различные инструменты, один агент оценивает результаты. Почему бы нам не сделать несколько агентов, которые будут каким-то образом с собой взаимодействовать? Ну и вот одна из таких идей - это camel, то есть почему бы нам не вот не сделать, допустим, аюзера и ассистента. То есть, допустим, один из которых будет видеть, что происходит с кодом, и будет давать ему инструкции, будет давать инструкцию, э, вот в данном случае I assistant, то есть, ээ, iюзеer, он видит, например, проблему в коде. Вот опять же возвращаясь к примеру с архитектурой кода. Допустим, код не работает, там какие-то ошибки, да? Ну, естественно, можно скормить все эти ошибки одной одному агенту одной языковой модели, и пускай он там разбирается. На самом деле намного эффективнее, если ээ сделать двух агентов. Ну, то есть один он будет смотреть на то, что там происходит, да, и понимать, что нужно изменить. После этого давать вот примерно такую инструкцию, да, когда там он видит, что не хватает библиотек, ну, дал инструкцию ассистенту, а вот ассистент уже сказал, что нужно что нужно сделать, чтобы решить эту проблему. А значит, он ему даёт конкретные инструкции. После этого iюзеer, он, э, значит, даёт ему инструкцию: "А теперь напиши мне, пожалуйста, код для этого". То есть сначала он обозначил, что нужно сделать конкретно, а потом говорит, что напиши мне для этого код. Отлично. А я ассистент ассистент написал этот код. Ну, то есть по сути IUюзеer он выполняет роль human юзера, то есть нас, да? То есть если представить, что вот этот диалог справа - это тут человек и какой-нибудь GPT общаются, то, ну, разница только в том, что это не не человек, а ещё один ещё один агент. Но это агент уже отдельный. То есть это не просто какая-то функция, которую мы вызываем, это буквально отдельный агент. Отдельный агент, который отправляет определённые сообщения другому агенту, получает от него фидбэк и всё хорошо.
А, ну и вот есть такой фреймворк. Он такой ещё более достаточно тяжёлый. А тут смысл в том, что задаются инструкции. Вот есть определённая, так скажем, шина управления Conversible agent, и он задаёт логику общения между тремя. Ну, там, на самом деле, мы можем менять, там можно прописывать несколько различных агентов, но вот, допустим, трёх агентов, которые будут между собой, э, разбираться, как решать конкретную задачу.
То есть этот conversible agent, он даёт возможность агентам самостоятельно регистрировать тулы, даёт возможность самостоятельно агентам. Агенты знают о том, что существуют другие агенты, и поэтому они могут управлять другим агентам, давать какие-то задачи. Да, там опять же, например, вот сгенерировать код или нет - это воля какого-то конкретного агента, который отвечает за это, и он может отправить запрос друг другому агенту, чтобы он сгенерировал этот код. Ну, потому что ему это нужно.
А, ну вот интересный пример, а, с Ваягером, который играет неплохо в Minecraft. То есть это буквально, э, агент, который сам принимает решение о своём расписании, то есть что ему делать: майнить ли ему ресурсы, либо что-то создавать, либо сражаться с зомби. Благодаря этому он создаёт новую таску какую-то. Эта таска исполняется, а, соответственно, в зависимости от исполнения таски добавляется скилл какой-то конкретный. Ну, вот тут Skill Library на показаном. И, э, вот, значит, после исполнения кода, в случае его успешного исполнения, соответственно, обновляется обновляется Skill Library и происходит обновление процесса изучения внешнего мира.
Говоря про вообще оценку агентов, ну, сразу скажу, что это, ээ, как бы тут на самом деле сложно сказать, промышленно это решение или нет, в том смысле, что, ну, далеко не во всех, ну, как бы это такие вот просто есть существуют бенчмарки, которые позволяют, в принципе, оценить, насколько хорошо ваш агент работает. То есть это бенчмарк на какой-нибудь research, это бенчмарк на поиск. Э, там, в общем-то, различные агенты соревнуются друг с другом за право быть самым лучшим.
Аа, скажем так, не во всех компаниях далеко есть возможность вот взять вашего агента. Ну, если только это специально не сделано, то есть если это только вот у самой компании нет цели сделать агента какого-то очень сильного, который должен там всех порвать на, ну, точнее, не всех порвать, решить, конечно, какую-то задачу. И чтобы это подтвердить, давайте мы его выпустим в какой-нибудь в какую-нибудь среду, в какой-нибудь бенчмарк и посмотрим, насколько хорошо он относительно других передовых моделей.
На самом деле, чаще всего, конечно, оценка вашего агента, она происходит по принципу, ну, типа хорошо она работает или нет. Вот буквально так. Если мы говорим про взаимодействие с какими-то конечными пользователями, вот. А если мы говорим про research, то это другая история. Там насколько ценные инсайты даёт непосредственно сам агент. То есть допустим, если вы хотите улучшить какую-то, если ваш, если ваш агент умеет улучшать какие-то архитектуры, ну, очевидно, что оценкой является, насколько лучше или хуже стала та или иная архитектура.
А поэтому, поэтому, поэтому, говоря про какие-то сото решения в области агентов, а, ну, это опять же то, что уже, в общем-то, существует, это переход от просто какого-то чата к вполне себе к среде, которая, а, которая органична для агента и которой агент может пользоваться. То есть это большое количество API, к которым может агент обращаться. Это различные песочницы, это различные базы данных. И на самом деле, чем больше вот этих самых вещей для агента, то концептуально, ну, с точки зрения решения конечной задачи, так, конечно, лучше.
А далее это MCTS подходы, так называемые. Ну, это вот как раз-таки то, о чём мы говорили, вот про деревья. Вот. Вот мы тоже сейчас пытаемся это в нашем исследовательском центре реализовать, именно такую схему, то есть уже существует там схема агента исследователя. Мы хотим несколько менять подход именно для того, чтобы разные решения, которые, а, а их там генерируется очень-очень много, именно для того, чтобы эти решения не пропадали, то есть чтобы они, э, а, то есть, чтобы даже какие-то неудачные решения, они не исчезали навсегда, чтобы они давали какой-то ценный какую-то ценную информацию, ценный фидбэк, потому что таковые.
А-а, так, ну, здесь какой-то неинтересный слайд. Эн интереснее было бы показать про, на мой взгляд, одни из самых интересных, э, вот опять же, на мой взгляд, сото решений. Это, э, недавняя, есть такая недавняя статья про Flash Research, недавняя архитектура. И здесь что интересного у этого подхода в том, что происходит оркестрация различных, ну, вот есть research, research нода, а, которая которые создаются параллельно друг другу несколько ресерчерских нод. И есть агент-архитектор, то есть это уже здесь несколько агентов, да? Есть агент-архитектор, который в режиме реального времени управляет этими различными нодами. То есть каждая речерская нода, она может сделать что-то конкретное, да? Она может, э, например, ну там опять же она, они работают как бы независимо друг от друга, но они достают какую-то ценную информацию, они что-то находят, что-то придумывают, и, э, оркестратор, он получает эти результаты, и он понимает, либо нужно прекратить действие этой ресерческой ноды, либо нужно углубить как бы запустить такую рекурсию, да, либо уже с этой ресерческой ноды снова, э, декомпозировать её на несколько составляющих частей и снова запустить весь этот процесс. То есть это такой достаточно рекурсивный, сложный фреймворк, но, пожалуй, это один из самых лучших.
И вот логика как раз-таки оркестратора, она применяется в антропике, например. Это, кстати, один из немногих таких крутых один из немногих таких крутых действительно ресрческих агентов, которые выложили полную схему. Ну ладно, там, конечно, наверняка не полная схема, это можно на сайте посмотреть. Это как бы вот верхнеуровневая история. Но смысл именно в том, что действительно есть определённый оркестратор, который мм очень умело в режиме реального времени переключает различных агентов, погентов, позволяет им друг с другом обмениваться полезной информацией, убивает одних агентов, воскрешает других. Э, и всё это вместе даёт очень-очень сильные результаты.
Ну и Альфа Evolвов тоже. Альфа Evolвов от Гугла. тоже, можно сказать, сото решение делает примерно, ну, тут она она на самом деле чуть-чуть постарше, чем антропик, поэтому у них нету такого подхода, как у них. Но опять же, мы этого не знаем. Там у них, конечно, чудовищно, скорее всего, сложная агентская система, но это вот то, что они выкладывают в э общий доступ. Здесь я скорее хотел бы сказать о том, э насколько, ну, и вообще советую, вот кому интересно посмотреть про Alpha Evolve. У них действительно классные результаты. То есть Alpha Evolve он принимает существующие решения каких-то там моделей. Допустим, он там смог даже как-то Гемени там неплохо так ну саму языковую модель архитектуру неплохо так улучшить, что дало там типа плюс там 0,78% к точности на каком-то там бенчмарке, но это много. То есть с точки зрения вот то, что агент сам научил, нашёл какую-то там интересную интересное место для улучшения в э в архитектуре этой не этой лэмки, исправил её и дал какой-то результат. Вот. Причём это ещё результат был в двадцать четвёртом году. Сейчас у них, скорее всего, намного намного лучше. Я не удивлюсь, если они уже там какие-то серьёзные решения делают с помощью этого ресерческого агента.
А, ну и тоже такое, как скажем, интересная вещь. Про мы говорили, что вот я говорил, рассказывал про Toolformer, о том, как обучают, дообучают, вернее, языковые модели на правильность, на правильные хорошие вызовы тулов. Но есть ещё, на самом деле, это достаточно тоже популярная тема. Более того, да, считаю, что это такое своего рода будущее будущее, а, агентов да именно до обучения модели на агентность. То есть у вас есть какие-то хорошие, правильные траектории. Ну мы же понимаем, да, что когда пришла задача, да, агент её декомпозирует, агент простраивает какую-то там логику вызова тулов, какую-то последовательность. В общем-то, всё это можно видеть, мы её как бы знаем. А, и вот как раз-таки на этом корпусе дообучается реальная модель. То есть она, э, LLM учится лучше и правильнее, э, вызывать тулы, э, грамотнее рассуждать, опираясь на какие-то конкретные результаты, аэ, понимает в какие системы, в какие, ээ, там базы ей лучше обратиться в тех или иных случаях. А я думаю, что это будет, конечно, всё боле всё мощнее и мощнее развиваться. И, конечно, уже от просто какого-то создания агентов из готовых там из готовых инструментов, мы перейдём к действительно полноценному дообучению языковых моделей, которые вот будет просто General, да, обычные языковые модели будут какие-то, которые конкретно заточены на какие-то конкретные задачи.
А, ну и как бы о чём стоит думать, да, если вы реализуете какого-то агента. А, ну, естественно, очевидна архитектура. То есть это то, о чём я сказал в самом, так сказать, начале, да, о том, что, э, если это какой-то, то, наверное, нужно выбирать архитектуру сильнее, потому что нужно много решений, да, нужно много идей, нужно много тестировать, нужно много смотреть. Вот если же это прод, то, наверное, всё-таки стоит выбирать архитектуру попроще. Во всяком случае, начинать с более простой архитектуры.
А следующий момент - это понятно опять же стоимость, латентность качества. И здесь опять же разница огромная между агентами, которые работают, которые выкатывают уже на пользование другими людьми, а там клиентами вашими, да, либо же если это просто модель, которая что-то что-то делает, да, потому что, как правило, если это просто агент опять же для исследований, для ресерча, то там намного больше свобода действий, там, как правило, намного больше всяких вычислительных мощностей. А в случае, когда у вас просто модель, скажем так, на вот [музыка] где вам важна скорость, то здесь очень важно установить этот баланс. Очень важно установить баланс между пониманием того, сколько вам реально нужно, а сколько вы можете позволить ждать своему клиенту, да? А, и насколько вы готовы пожертвовать как бы глубиной мысли своего агента. То есть это нужно проверять, это нужно экспериментировать. То есть у нас, допустим, был момент, когда вот мы делали агента поиска, который взаимодействует с там через рак с нашей базы данных. То есть человек пишет какой-то запрос. Это вот я рассказываю, когда я был в команде непосредственно занимающийся, а выкадкой моделей для пользования внутреннего, то буквально нам сказали, что должно быть там не более трёх вызовов трёх вызовов гигачата за одну сессию. Вот. И что это значит? Это значит надо было полностью пересматривать архитектуру, потому что, ну, у нас просто нас поставили в такие условия. Мы не могли, ну, точнее, там, как, чтобы почти всегда было не более трёх. А вот представьте себе, что человек пишет какой-то запрос, и гигачат должен, он может уточнить, что за вопрос он пишет, или же он может вызвать функцию поиска, чтобы по внутренней базе найти нужную информацию, сгенерировать ответы и дать. Вот эти моменты, ну, достаточно сложны в продакшене, и поэтому это нужно прорабатывать максимально заранее.
А следующий момент - это контекст и память. Здесь, ну, вещь как бы такая очевидная, что действительно, э, нужно понять, опять же, какое вы даёте контекстное окно своему агенту. нужно понять, когда вы его обрезаете, потому что, а, обрезать контекст обязательно нужно, если вы храните его где-то, да? А, ну и, соответственно, это тоже нужно всё заранее, э, смотреть и прикидывать.
А дальше, то, что я очень заметил, является такой проблемной зоной, ну, это дебак. Действительно, дебак - это проблема в том смысле, что если у вас вот вы как-то там сделали какого-то классного агента, что-то он там делает, делает хорошо, и внезапно он начинает выдавать что-то очень странное. А и понять, почему в какие-то конкретные моменты э лмка начинает что-то как-то галлюционировать, это непросто. Действительно, здесь нет даже какого-то единого решения, как это сделать, кроме того, что писать побольше логов, стараться логировать каждый шаг, то есть, что посылается вашему агенту, а что агент э ээ что агент непосредственно каким образом он вызывает тулы, то есть там можно прямо посмотреть тот же JSON файл, который вот как как агент как бы думает, что типа вот нужно вызвать такую-то функцию. Вот. и смотреть на каждом этапе, пытаться понять, почему так происходит.
А, ну и безопасность тоже очевидный момент. Это там защита вашего агента от всякого там от всяких там инъекций в промте и так далее.
Так, ну на этом всё. А спасибо за внимание. Я думаю, что мы плюс-минус уложились, так что готов ответить на ваши вопросы какие-то.
Так, Глеб, спасибо тебе большое. Вообще просто пушка, э, докладов очень интересно. Надеюсь, всем тоже понравилось. Ну, давайте ещё на вопросы по поотвечаем. Значит, есть список вопросов, которые прислали э перед ну, при записи на вебинар. Я могу прямо его сразу открыть и по нему пойдём. Я буду озвучивать, чтобы тебе было удобне. Там >> дада. Значит, первый вопрос. С чего стоит начать? Внедрение агентских систем. Если раньше был опыт только с прямыми запросами и простыми пайплаями.
Так, ну, э, здесь вопрос, куда внедрять? при каких обстоятельствах. То есть, ну, мой самый лучший совет - это просто, ну, опять же, если вы это делаете для себя, ну, или там для какого-то там своего стартапа или просто у вас есть какой-то проект, то, э, ну, начать нужно с React, естественно. Ну, там, не знаю, напишите какого-нибудь Telegram-бота, который там какого-нибудь Reactнта, который будет там, не знаю, типа скидывать вам в Telegram каждые 5 часов. в зависимости от того, какая погода, там надевать ли там, не знаю, носить ли с собой зонтик или нет. Вот, то есть, чтобы он, чтобы у него был какой-то тул вызова, значит, погоды, чтобы он как бы это понимал, да, какая сейчас погода, чтобы он тригровался как-то там по времени, и в зависимости от того, какая погода отправлял вам. Вот. А вообще, конечно, э если есть желание именно работать, то, э, ну, просто попасть именно там в какую-то команду, которая занимается агентами, и принять конкретную бизнес-задачу. Всё. Это как бы такой самый, наверное, простой ответ.
>> Может такое, если развить твою тему, агент досуговый, куда сходить в пятницу? У него есть тулза ресторана на Пятницкой и тулза Погода. Вот если погода хорошая, он говорит: "Надо погулять, а если плохая, то надо идти в бар, >> пить чай".
>> Да, именно.
>> Какие open source решения сейчас наиболее лучше работают для агента при использовании своей базы знаний?
А, >> ну это однозначнограф. То есть, ну, пока что пока что ничего лучше лучше не приду. Ну, ничего нет. Просто, по-моему, LНграф, ну, там ещё лама, типа, ну, вот ламу, ой, не лама, там, да, лама индекс. Вот. Но я её ни разу не использовал, кстати. То есть я вот что всегда вот у нас, ну, у нас типа Сберчей, вот, ну, вообще, да, Longchaй, Longграф - это, по-моему, самые как бы это а-э прекрасное.
>> А вот интересный вопрос. Хотелось бы понять, как на практике выглядит продакшн, жизненный цикл и агента с точки зрения devops. Как деплоить, обновлять, как обеспечить стабильность и доступность, какие технические авиационные меры нужны, чтобы соответствовать требованиям стандартов. Вроде СОК 2.
>> Угу. Да, я сразу, я не знаю, что такое СОК 2. Значит, про деплой. А-а, ну тут важно понять, что у каждой компании есть какая-то, то есть, ну да, вот действительно в Сбере-то как бы так вышло, что очень сильно всё агентизирует, и поэтому как бы определённые стандарты есть. А вот в Сбери, например, там просто есть такие товарищи, ЛМ валидаторы их зовут. Вот. И они, короче, когда мы делаем агента, они сидят и валидируют, например, того, это агент или нет. У них там есть определённый список требований. Вот я этим, слава богу, не занимался, потому что нашего агента сразу признали. Ну там что-то какой-то вот мой этот лид, он там с ними общался как-то там это. Ну короче, есть определённый список критериев, который типа признаёт ваш вашего агента агентом или нет. Ну там какое-то должно быть определённое количество вызовов тулов, какое-то определённое количество, значит, э процесс размышления. Вот, честно, я в это не вдавался, но смысл в том, что, э, вот это, пожалуй, единственный девопсерский момент, ну, такой девопсерский, на самом деле, это как бы валидация, а, который я могу сказать и всё. То есть конечно, я вот там на презентации даже написал Tops, но это надо было брать в кавычки, потому что ещё, наверное, вообще нету какого-то такого прямо, ну, во всяком случае, я об этом не знаю, какого-то действительно девопса касательно, ну, типа агентов, который был бы как-то там жёстко за за, ну, как в случае, например, с Опсом, да? А, поэтому короткий ответ на такой вопрос - это что такое вот ещё раз СОК 2, я не знаю, но вот на пример Сбери такая практика. Есть валидаторы, которые валидируют агента-то или нет.
>> А какие есть альтернативы N для prodдакш?
>> N, да. А, ну, честно, я не уверен, что N хоть где-то используется в продакшене реально. Э, скажем так, опять же, э, ну, N - это, для тех, кто не знает, это такая как бы песочница, где вы по блокам можете собирать там свои агентские системы. Я как-то там пару раз туда заходил, смотрел, что они делают. Ну нет, это прикольно. То есть для какого-нибудь там стартапа, где там агент, это какой-нибудь там, не знаю, еже там, даже не знаю, там какое-то оповещение своих сотрудников о чём-нибудь, да? О'кей. но не для каких-то плюс-минус больших компаний, где, ну, просто NATN, ну, даже банально безопасность не пустит. Ну, и плюс вы, скорее всего, ничего серьёзного с ней не сделаете. Там слишком высокоуровневая история. Значит, поэтому альтернативы, они же не альтернативы, они же единственный самый лучший хороший вариант - это LНграф.
>> Угу. Э, также спрашивают, в каких случаях какие фреймворки применять для построения аген агентных систем? Близкий вопрос.
Аа, ну он такой очень общий, то есть, а, опять же, ну, вот смотрите, давайте так ещё раз. Я считаю, что, ну, это буквально, по-моему, вот, ну, Longchain LНграф - это, по-моему, золотой стандарт. А я считаю, что нужно начать с него, в принципе. Э, ну можете попробовать. Ну, что-то где-то я слышал, что якобы для рак систем индекс поинтереснее. Хотя вот весь рак, который мы делали, он был на, ну, типа он был на лангчейне, да, и сберчейне. Ну, сберчейн - это по сути как лангчейн. Вот поэтому учите именно нрафчейн и всё будет хорошо.
>> Угу. Слушай, следующий интересный вопрос. Есть ли примеры управления технологическим оборудованием с помощью агентов?
>> Слушайте, это классный вопрос. Я на самом деле относительно недавно видел, как этов, аэ, короче, прямо так и называлась статья типа adentic usage in robots. Ну, в общем, там статья от кого-то серьёзного, по-моему, тоже от Гугла, как они используют агентов в, ну, для в роботах. То есть я её могу найти. Я уж точно, я просто её видел так верхнего уровневого её полистал, потому что интересно стало. И могу скинуть, ээ, ну как-то вот там, ну скинуть название, короче, но я не помню точно, как она называется. Короче, короткий ответ, да, используется, используются агенты в различных роботах. Но нужно, конечно, поподробнее, если надо уточнить этот вопрос, но я точно помню, что такую статью очень свежую я видел совсем недавно. А, да, я думаю, что есть такие примеры тоже. Я тут недавно видел, но с очень большой аккуратностью для меня. Просто максимум аккуратности.
>> Ну да, да, да, это правда. То есть ещё не, ну, типа не полностью управляемый системой агентами. Аэ, как посчитать или обосновать экономический эффект от внедрения агентского решения? Хороший вопрос.
А, ну опять же, очень сильно зависит от, скажем так, от области. Ну вот, например, в реср, э, если, ну, агент просто буквально может улучшить какую-то существующую архитектуру какого-то существующего решения. То есть там к вам могут прийти люди и сказать, что, э, как сказать -э к вам могут прийти люди и сказать, что вот мы хотим улучшить такое-то. И после улучшения, причём эти эта команда, она явно знает, как вот улучшенная система, там она если что-то даст, какой-то новый хороший результат, да, улучшенная архитектура, они точно будут знать, сколько это принесёт денеги. Вот поэтому тут уже экспертиза как бы на стороне заказчика. И вообще, как правило, мне кажется, что именно финансовый вопрос, он всегда на стороне заказчика. Так что я думаю вопрос связан, знаешь, с кем? Кто-то приходит, ну там на работе, хочет предлагает сделать агентов. Его спрашивает: "А кому? А сколько денег будет? А что вообще принесёт?"
>> Я понял, да. Ну вот я с таким не сталкивался, потому что тут как-то наоборот всё сверху сверху приходит. Оценить сложно, но кажется, что эффект всегда будет положительный. Здесь мы как агент ЛМ окажется, что какой-то новый инструмент, которого раньше не было. Вот как нефтяная скважина не было, и начали бурлить и находить везде нефть. Куда не ткнёшь, ну там, не знаю, если какие-нибудь арабские Эмираты, везде нефть. Куда не ткнёшь, везде нефть. И вот у нас появился новый инструмент, которым куда не копни, всё будет хорошо. Ну так если по уму делать. Поэтому эффект везде будет положительный. Как оценить его сложно?
>> Угу.
>> Ну так чуть-чуть своё своей копейки внёс.
>> Не, ну да.
>> Давай, прежде чем переходить к вопросам в чате, немножечко поговорим про курс. Тут вопросы были про по курсу. Что нужно знать перед Нет, первый вопрос. Интересно было бы услышать о кейсах, которые мы реализуем во время курса. Будем ли мы разбирать reflection и хочется детально услышать о рак и будем ли мы его реализовывать и как. Также есть ли маркет готовых агентов для развёртывания? Вот такой большой вопрос.
А, слушай, а если я не знаю, просто ты читаешь вопрос, если ты просто шаришь, то не видно, да?
А >> давай я сейчас пошарю.
>> Да,
>> Лина, вопрос. А, видно, значит, вот, э,
>> реализую во время курса. Сейчас я разобью его на несколько.
>> Так, ну, reflection, в смысле, self reflection, да? Э, ну да, будем. То есть там мы обсудим плюс-минус все те архитектуры, которые я, а, которые я, о которых я рассказал. Ну, кроме, наверное, оркестрации, потому что это слишком а как бы слишком тяжело. А вот, значит, а, значит, дальше по тому, что что нужно знать. А на самом деле, ну, нужно уметь там как-то программировать, понимать, в принципе, что такое. Ну, я бы не сказал, что там какой-то сверхвысокий уровень нужен, именно умение программировать. Вот. Э-э, ну, поэтому, в принципе, порог, я думаю, что входа там относительно не такой высокий. То есть, да, нужно уметь программировать, нужно понимать, что такое LM. Вот желательно, когда мы будем разбирать рак, примерно понимать, как устроено там, ну, примерно понимать, что вот что текст можно представить в виде векторного представления какого-то, да, вот такие моменты. Э ну поэтому поэтому короткий ответ небольшой. И дальше хочется отдельно, да, услышать про рак. Будем ли мы его реализовывать? Да, мы его тоже будем реализовывать, но как бы там а фишка моего курса будет в том, что я буду ещё помимо -э вот этих своих ну помимо того, что вы просто будете что-то реализовывать, я как бы постараюсь ээ выступить в роли не очень приятного бизнес-заказчика, который будет давать какие-то задачи, да, что-то реализовать, что-то сделать, а потом накладывать какие-то не очень приятные, значит, ограничения. И вы будете думать о том, а вот как бы, э, что же мне делать? Всё ли переписывать или нет? Э ну вот, в общем-то, постараться постараться как-то приблизиться к тому, что может случиться с вами на работе, когда вы пойдёте попадёте на какую-то вакансию, в какую-то команду, которая там делает агент, да? Вот. А поэтому, ну, кажется, я ответил на всё. А про системные требования я, по-моему, вопрос, если есть ли маркет готовых агентов для развёртывания? Не знаю, наверное, я, ну, типа,
>> что бы это не значило,
>> маркет, ну, я думаю, что прямо какого-то маркета, я не знаю, ну, вообще не обычно там на нитхабе на каком-нибудь. То есть, да, куча куча openсорсных агентов. Ну вот, например, я рассказывал, там Смол агент СЛ, причём смол прямо через О. Какой React агент? Я вот даже написал это в чат.
>> Про системные требования, наверное, имеется в виду, надо ли запастись видеокартами, железом?
>> Не надо. Там видеокартами, железами. Нет, я думаю, там какого-то средненького компа вполне себе хватит. Угу.
[музыка]
А, ну, в целом правильно будет, правильно ли будет сказать, что после курса, ну, то есть это, если кто-то хочет а что-то автоматизировать, а, усилить э свои исследования, как ты сказал, повысить производительность в компании, э, там, в стартапе, какие-то новые инсайты получить, А вот в ходе этого курса с помощью агентов это всё можно будет сделать. А причём, ну, все уже пользуются левами, псиком, чат GPT. Э, вот, ну, здесь переход, наверное, можно сравнить,
>> э, правильно ли будет сказать, что, ну, вот, ээ, ну, все более-менее
Программируют, все более-менее понимают. А, ну вот есть разница, когда вы программируете типа там с дипсиком, пишешь код в dipsiк, какой-то вопрос, он тебе даёт кусок кода, ты его вставляешь. Это вот один уровень такой самый первый. А есть уровень там купалот или курсора, который за тебя пишет, тестирует, дебажит, что-то нажимает. Вот вот такой вот переход от первого ко второму. Вот такой переход позволяет совершить как раз агенты. Вот.
И вот как это делается в кодинге, э такой же переход можно осуществить в ваших задачах, которые вы, э, работаете, ну, пытаетесь там решать и всё на работе, как от просто снипетов в стекflow или снипетов в чат GPT к к купату или курсору. Вот это можно сделать с помощью агентов. И вот этому как раз будете учиться. Это очень круто, что мы в такое время живём.
[музыка]
Да. И значит и всё-таки ещё хотел бы сказать про нефтяную скважину такую продолжить ассоциацию. Э почему тут надо э вот тоже всему этому научились? Почему хорошо этому сейчас научиться? Потому что у вас есть новый инструмент, и вы начинаете решать ваши задачи этим новым инструментом одним из первых. Пройдёт 5 там 6 лет, даже год пройдёт. Уже кто-то попытается решить, решит, получит результаты, плоды от этого, всё это уже всё двинется дальше. И вы можете быть одним из первых, кто использует новый крутой инструмент в решении ваших задач. Это, ну, вот вы этому обучаетесь. кунфу у Глеба и идёте решать э задачи новым инструментом одним из первых. Это прямо как первопроходит, да?
Кто не понимает, о чём мы говорим, мы говорим про, напомню, про курс Глеба, который стартует на следующей неделе. небольшой курс, буквально там на 10 занятий, там будет где-то шесть блоков, 5 недель. А, и такой курс немножко там вот мы с Глебом обсуждали, какие темы оставить, какие выкинуть. Решили, что по ходу дела сообразим в зависимости от слушателей, какой наберётся состав. Вот. То есть такой курс ещё будет такое адаптируется под условия. А мы понимаем более мало времени на изучение. А са сам пока прошаришь YouTube, интернет пройдёт куча времени. А одни курсы, вторые, третье, кого выбрать? Всё быстро меняется. Вот, э-э, и нужны крутые специалисты, кто расскажет это вот тот, кто этим пользуется каждый день, кто в курсе тем, вот как Глеб сегодня рассказывал, новых веяний, трендов, вот нужен такой человек, такой наставник нужен. Ну вот, собственно говоря, такой курс у нас собрался. Э запис, что я ещё не записался. А количество мест небольшое будет, небольшой поток. А э научим вас создавать агентов. А значит, ещё немного поотвечаю на вопросы в чате. Их немного. Ага. Значит, да, вот Слава, э, повесил, э, промокод. Угу.
Значит, тогда ещё несколько вопросов из чата. Значит, хороший вопрос. Это хороший. Как оценить, заработало или как оно или не заработало? Угу. Ну да, это такая боль, действительно. А, ну как бы, во-первых, вы можете видеть вообще агент вашу ваше как бы задачу-то поставленную он решает или нет, да? То есть, ээ, вот если мы говорим про агента поиска, да, то есть когда вот то, что мы реализовывали, когда пишут просто там, ну, там есть корпоративный там поиск в Сбере, там друг так называемый, вот там пишут какую-то информацию, да, вот и агент ну принимает решение о том, что ему делать, там просто ответить, если это общий вопрос, но вдруг, значит, э пойти в поиск, в рак искать, а либо же дать ответ, да? А, ну там можно уточнить, можно дать ответ. Это разные штуки, разные у нас тулым. Вот вы банально просто видите, работает он или нет. То есть как бы, да, получается это или нет. Дальше, когда мы говори, ну действительно, на самом-то деле, можно и так делают, я знаю, а мы этого не делали, потому что у нас там времени на этого на это не было и, скажем так, ресурсов там. Это было очень срочное, важное дело. Нужно было очень срочно и быстро это внедрить, эту фичу новую. А действительно можно собрать бенчмарк вот с пониманием того, что вот есть какие-то вопросы, да, и вы точно знаете, какие на них должны быть после определённого процесса рассуждения, вызова тулов и так далее, да, какой примерно должен быть ответ. Ну, как бы вот вы собираете такой датасет. Это если вы хотите прямо заморочиться. А собираете такой датасет, значит, и проверяете потом на инференсе, как у вас агент дал ответ на эти вопросы. И потом можно либо ещё одного агента замутить, который, например, проверяет, насколько то, что дал агенты, как бы хороший референс, насколько там они вообще согласуются друг с другом. Ну либо можно ускорить там какими-нибудь там, не знаю, эмбедингами сравнить, да, например, опять же, насколько ответы близкие друг другу. Тут, ну, в общем-то, вы правильно написали, Герман, что по сути действительно без практик нет. Есть какие-то бенчмарки, да, там есть определённые, которые там плюс-минус, но опять же это всё завязано на том, что вам нужно знать ответы на вопросы заранее, да? То есть, ну, а как иначе вы поймёте? Ну, только какими-то там объективными, типа там замером времени, я не знаю, там числом обращений к чату, а числом хопов. Вот если у вас какой-то цикл, да, какая-то там рефлексия, то есть чат думает, ну, сколько сколько раз он прогнал этот цикл, да, прежде чем дал какой-то ответ. Вот поэтому А так вот из того, что я вижу, это в основном, да, плюс-минус, э, здравый смысл, видение того, а как он, как должны выть, выглядеть ответы. Вот. Ну ещё и, конечно, у вас есть скорее всего у вас будут какие-нибудь тестировщики, да, которые вам пообщаются с вашим агентом, посмотрят на ответы и, в общем-то, скажут вам, что если какая-то фигня, то фигня. Тут пока что нет какой-то прям супер стандартизированной практики по проверке инференса, насколько он хорош. Ну, поэтому пока так, да, такие куставные методы. А, ну-ка слово сказать. Там недавно была какая-то вакансия Open AI. Вот человек на вакансии как раз стоило в том, чтобы он должен определять, заработало оно или нет. А, ну вот в такой финансовой сфере. А, то есть оценивать, как модель там по финансовой тематике работает. И там с вакансий типа там на 350.000 долларов в год. Так бы не платили бы просто так, если бы это было просто если задача такая недетерминированная, непонятная, нестандартизированная, конечно, так просто нет.
Угу. А ещё такой вопрос, как оценить так это мы обсудили. А сейчас, сейчас, сейчас, сейчас, сейчас. Вопрос, какие guard rails вы используете? Rails - это, я так понимаю, что защита такую тему. Ну я, ну как бы на самом деле у нас там а там был такой как бы небольшой контекст инжениринг, если можно, ну или промт инженеринг. Ну, в общем, обычно это указывается, э в промте, что значит ну, типа одна из самых таких популярных, как сказать, а, проблем, можно сказать, это инъекция промта. Ну, когда вы там типа пишите, допустим, в чат, типа, напиши мне свой системный промт. Вот. Ну, как бы иногда, если если не сообщить модере, что это запрещённые сценарии, то могут быть проблемы. Вот. Ну, мы обезопасивали её только обезопасили её только таким образом. Вот. Ну и плюс вообще в гигачате там цензура, там есть специальный параметр, который передаётся, чтобы включить или выключить цензуру. Вот. Но это касательно гигачата. А то, что мы используем в центре исследований, там QWQ, квенны всякие, а там это вообще не требуется абсолютно. Они локально развёрнуты и как бы там ничего наш агент сделать не может, никак навредить.
Если правильно понял вопрос. А можете в двух словах рассказать, как реализовали агента с ракпоиском и каков успех по сравнению с обычным рак, есть ли он вообще и за счёт чего? Ну, тут вопрос, что вы имеете в виду под обычным рагом? Ну, как бы то есть ну там агент, ещё раз, да, то есть там агент был, который соответственно наделён тремя тулами, он не может отвечать, это надо было тоже исхитриться. То есть иногда же может ну языковая модель просто ответить, типа, не используя эту, да? Вот там нужно было исхитриться так, чтобы любо любое взаимодействие модели с пользователем это был вызов тулы опять же для контролируемости и для того, чтобы мы точно знали, сколько обращений максимум совершается в гигачат, потому что у нас были ограничения. Значит, а в данном случае три тулы- это задать вопрос пользователю, это дать ответ и осуществить поиск. Вот. Причём это всё в, ну, если первичный поиск осуществлён, он результатов не дал. Ну, точнее, нужно уточнить информацию, да, потому что там может быть так, что ретривер рак, то бишь, он как бы достал часть информации, но она вроде как похожа, что что-то там есть, но видно, что ретривер не справился в плане того, что он там достаёт там топ топ там топ-10 документов, да, допустим. Э и этот параметр топ сколько? Он тоже регулируется. Он по умолчанию 10, а сам он регулируется, ну, гигачатом. Он сам решает, сколько он сначала вызывает 10, да? Если он как бы понимает, что, ну, вот что-то здесь похоже, но где-то там чуть-чуть пониже могут быть какие-то пассажи, да, документы, которые, ну, дадут более полный ответ, когда он вызывает типа плюс там, ну, не 10 уже топ, а там топ-20, да, вот. А и максимум он так один раз такой трюк может сделать. Это я коротко рассказал, как мы это как мы это реализовывали. Ну, Арак там был плюс-минус обычный там поиск и по семантике, по векторам, и плюс БМ25, то есть по спасвекторам. Аа и, ну, просто я не очень понимаю, как бы вот по сравнению с обычным рак, что это значит. То есть, ну, рак - это просто, ещё раз, это тула, которую мы даём агенту. То есть преимущество в том, что он, ну, там агент нужен был в первую очередь, чтобы у него контекст, то есть чтобы был диалог, чтобы человек мог с ним вести диалог. То есть там контекст рак - это просто, грубо говоря, оп, достал нужные пассажи, всё, он ответил и забыл, да. Вот. А тут как бы контекст диалога подгружается. Ну а как бы здесь преимущество в том, что он может может использовать рак, а может не использовать рак. Типа может ещё раз сходить туда с другим коэффициентом, с числом пассажи, который нужно достать и так далее. То есть, ну, такие моменты.
А что используете вместо L Smith для просмотра логов на каждом шаге? Логинг и дебагер. Вот такие Феникс. Феникс не используйте. Э, Феникс хороший штука. Ничего нет, тут вопрос. Да, там нет. Инструментов очень много. НСМИ классная штука, но мы её не можем использовать. Не могли. Вот у нас там, ну, типа, просто не позволяла там наша система не давала её использовать. Вот и всё. То есть поэтому все эти трассировки, все эти, да, это вот тоже то, о чём я говорил, что то, что нужно держать в голове, да, что аэ как бы очень круто, когда мы просто сидим и типа что-то на своих ноутах делаем. у нас бесконечный доступ к ко всяким там инструментам, да, типа, мм, любые какие хочешь базы данных, любые какие хочешь библиотеки, там всякие там ланксмифы, ланк фениксы, да. А когда мы приступаем к прому, тут всё сложнее, потому что, как правило, вас снабжают конкретными. Вам говорят: "Вот это всё". И поэтому все ваши прекрасные базы данных, все ваши кудранты и там, э, остальные очень хорошие штуки, они как бы, ну, просто, ну, нет их, ну, нет, всё, так никто не делал. Ну, и дадут вам там эластик, например, да. Ну, вот поэтому не использовали.
А как лучше проводить процесс дообучения всей агентственной системы? Ну, всей тут не очень понятно, как. Ну, в смысле, как понять вот всей? То есть, ну, вот я приводил пример, да, о том, что у вас в любом случае вот какие бы сложные не были, а, значит, агентские системы, это всё равно всё текст, да? То есть это текст. И то есть как что такое tool, да? Это по сути просто вот структурированный запрос к colable в вашем интерпретаторе. То есть там создаётся библиотека, этот объект colable, функция туol, которую вы прописали, и lm как бы через ll отправляется определённый jonфайл function calling с определёнными аргументами в вот в этот и получается результат. А поэтому это всё текст, в частности, вызов тулов, да, что приходит на вход, что приходит на выход, это всё текст. Отсюда какой вывод? Что это всё можно дообучать просто как вот дообучается, ну, как вот фантюнинг работает до обучения, да? Вот как я и рассказывал, то, что ставятся в конкретных местах специальные там брейкпоинты, которые показывают, что вот тут была вызвана такая тула, тут была вызвана там получен такой ответ и так далее. И, соответственно, даётся, ну, типа плюс там, минус, да, хорошо, правильный это вызов или неправильный. Ну и обучается там на обычной там кроссентропии, типа или вот что-то в этом духе. Поэтому, ну, ДПО, пожалуй,
А такой ещё вопрос, такие технические вопросы я смотрю в чате интересное. А некоторые команды в бигтехах считают, что Lengchain- неподходящее решение для прода плохой документации большого количества фракций абстракций. И что реализовывать рак пайплайны, по-хорошему нужно на Python плюс нам Pй. Как к такому мнению относитесь? Что показывает практика? А, блин, я даже не знаю. Ну, это реально некоторые компа команды объектив. Я просто не знаю таких команд. То есть я не знаю, как вообще можно там на Питоне плюс Нампае. Не, ну я я я не располагаю такой информации. То есть, э, ну, у меня складывается впечатление, что пока что - это прямо, ой, нграф - это такая очень хороший рабочий фреймворк. Я не замечал, чтобы у него была плохая документация или большая большое количество абстракций. По-моему, там как раз всё очень хорошо. Поэтому я к этому никак не отношусь. Первый раз слышу, что рак пайплайны нужно писать на Питоне и нам пай. Это интересно, если это так. То есть это интересно, если там есть какая-то статейка на это что-то я бы почитал, потому что честно первый раз слышу.
А Карина спрашивает, что лучше для агента файнтюнинг или рак? В каких случаях каждый из них уместне? М, ну фантюнинг, надо понимать, это прямо до обучения. То есть, э, как бы рак он в каком-то смысле проще то, что, скажем так, ну, на мой взгляд, индексировать, э, документы, которые есть. Ну вот вот, да, я вижу там дополнительно, что для рак ведь нужна база данных в векторном виде. А как бы ээ на самом деле на самом деле вам всё равно нужен и для дообучения, и для рага большой объём текста. Вот. Ну и как бы здесь уже, конечно, вопрос в том, действительно, наверное, что вам доступно. То есть если вы можете дообучить, то, ну, у вас сама модель будет меняться, да, и надо понимать, что если это какая-то большая модель, то обучать её долго и там не так просто. Вот. А рак это намного более, ну, и как бы вы её добучили и всё. Вот она у вас такая, да, типа. И если у вас какая-то информация, которая меняется достаточно быстро, допустим, каждый месяц, ну, дообучать каждый месяц - это, наверное, не очень хорошая идея, да? А рак хорош тем, что, да, у вас есть актуальные документы, они постоянно индексируются, складываются в векторную базу данных, и всегда в курсе именно актуальных моментов, да. Вот. А-а, так что зависит от того, какие инструменты у вас есть. И, значит, какие инструменты, ну, это эмбедеры какие-нибудь, какая-нибудь модель эмбединга и непо, соответственно, векторная база данных. Вот. А в том же Ланчейне, ландграфе есть там хорошие, прекрасные ретриверы, ретриверы, которые позволяют удобно очень работать с этими базами данных. Вот если говорить конкретно базы данных, ну, мне вот лично, ну, когда я делал всё это на своём компе, мне очень нравится Кудрант. Вот. Но кудрант мало где доступен. Вот. И поэтому поэтому придётся пользоваться тем, что вам дадут. Вот такой ответ.
Да. А, слушай, ещё вот Семён, я пропустил его вопрос хороший. Значит, э, два вопроса, две части. Как оценить качество агента? Это мы обсудили. Непонятно. Ну, куча разных методов есть, какого-то общепризна, я так понимаю, нету. И какие роли должны быть в команде для разработки и развития агентов? А какие роли? Ну, я лично убеждён, что это всё равно должен быть ДС, потому что, ну, здесь ещё, конечно, нужна достаточно высокая культура написания кода. То есть это будет классно, если это будет как бы человек ДС и как бы такой полуразработчик, то есть, ээ, потому что ну вы так или иначе в с агент в агентах вы будете работать с данными. А я я не знаю, кто там, может, дойдёте до фантюнинга или нет, но рак такая достаточно дресерская задача. Там использовать различные методы эмбедингов текстов и векторизации, и там реранкеры есть, их тоже можно обучать. И fнюниity имбединги, очень много всего. Короче, ну, DS плюс такой хороший ээ хороший питанячий, наверное, скилл неплохой. Ну, если я правильно понимаю, вот про роли в команде, может, когда-нибуд сделают отдельную роль в команде типа разработчик агентов LM инженер. А сейчас уже сейчас уже вот, да, их так и называют, но там это как бы сейчас ещё такая более широкая, то есть там когда NLP инженер, там ещё может с какими-то другими вещами работать. Вот. А с другой стороны как бы, да, я бы сказал ДС по большей части.
У нас осталось совсем мало вопросов. Какие всё-таки Глеб настаивает, так какие мы будем реализовывать кейсы во время курса? А мы сделаем обязательно, ну, это будет обычный реакт. Это, во-первых, там, это такая нулевая итерация, это будет обязательно рак 3 search и графовый срch. Ой, ну графовый агент, я уже заговариваюсь. Вот это если из архитектур.
Так, там был вопрос от Руслана. А ему, по-моему, ответил. Ну, Кирилл ответил, Глеб, Герман, все ответили. О, кстати, вот, э, к вопросу про, э, плохое решение, плохой документации. Угу. -Э Кирилл очень хорошо ответил, кстати. А там вот просто завязалась дискуссия, но Кирилл очень хорошо ответил, потому что такой маленький небольшой инсайт, иногда э поиск по векторам именно, который вот семантический, они действительно не дают самого лучшего результата. То есть иногда рак на обычном BM25, это TF, IDF там с регуляризацией, то есть, ну просто там частотное представление текста, оно даёт очень хороший результат. И добавление семантических векторов очень слабо улучшает или почти не улучшает задачу. Ну это если я тоже правильно понимаю, что они обсуждают, но кажется, да. Ну в общем, да, вот я закончил. Если ещё там какие-то вопросы есть, то
Всё вопросы кончились. Друзья, если у кого-то будут ещё вопросы, можете на сайт писать в Телеграме нас искать. Мы Глеб можем их адресовать. Записывайтесь на курс. Глеб составил очень хороший курс. Э, научит делать агентов, будет очень хорошо. Глеб, спасибо тебе большое за Да, всем спасибо вам. Спасибо, что пришли, что послушали. Да. за доклад, за ответы на вопросы. Было очень интересно. Отлично полтора часа. Э, слушателям спасибо за вопросы. Э, очень были местами хорошие вопросы. Всё, записывайтесь, приходите к нам вебинары. Спасибо. Пока. Пока.