0: Привет, меня зовут Кирилл Власов, и я работаю в ияй студио яндекс облако, и я отвечаю за развитие платформы инференса моделей. Сегодня мы с вами продолжим разговаривать про то, как
1: Внедрять ай агентов в продакшн. И на самом деле сегодня мы формализуем все, что было сказано, и сделаем какие-то чёткие дисижен 3 для того, чтобы мы понимали, по какому флоу идти при создании ай агента. Давайте
2: Представим ситуацию в бар заходит мле и backend developer, а там их уже ждёт наш замечательный пиэм и говорит нам срочно нужен эйай агент, и, собственно, ваши действия. И на самом то деле.
3: Мы на прошлом занятии как раз уже много обсуждали, что спектр решений, он обычно должен состоять от простого к сложному сначала мы делаем что-то на каких-то простых правилах, с face, текстом на одиночных м вызовах и уже.
4: Последним шагом мы подключаем агентов, и на самом деле каждый шаг правее. Он работает медленнее, обходится дороже и вообще становится менее надёжной системой. И агент в этом случае как раз-таки крайний случай. Прежде всего нужно задать вопрос.
5: А нужен ли вообще агент? И если ответ на все 3 вопроса, которые сейчас вы видите на слайде, если этот ответ нет, то на самом деле агента строить совершенно не нужно, и мы не устанем.
6: Повторять на самом деле 1 шагом, что нужно вообще понять, и исходя из знаний, которые были получены на предыдущих днях интенсива, что агенты это не классическая разработка программного обеспечения в понятном для нас смысле, во первых,
7: Агенты не детерминированы, если в классической разработке мы обычно на одинаковый инпут ожидаем какой-то одинаковый аутпут, то в агентах такого часто не бывает, потому что один и тот же выход один и тот же вход даёт.
8: Разный ответ. Тесты также недетерминированные. И если в классической разработке они бинарные, мы просто принимаем упал тест или он прошёл, то в агентах мы скорее приходим к понятию.
9: Тического тестинга, когда мы можем оценить как-то вероятность нашей метрики, да, то есть мы обычно говорим, что success rate у агента, там 94%. Более того, в классической разработке мы знаем, что баги воспроизводимы и на самом деле
10: Есть очень чётко понятный flow их отработки потому что есть exception есть трейсы, есть алерты и в конечном итоге вы все знаете что сломалось в агентах эта ошибка может и вообще не воспроизводиться более того может.
11: Не быть ошибкой вовсе, потому что это просто правдоподобно выдуманный ответ. И у агентов есть такие ошибки, которых нет вообще, в принципе, в классической разработке, потому что они не падают, они деградируют, врут и каскадируют.
12: Эти ошибки классическая разработка также предполагает, что у нас довольно понятный flow, понятный процесс, мы написали какой-то код, он работает, мы провели тесты и задеплоили в агентах же напротив.
13: Мы сначала написали промт, он работает в каких-то 70 процентах, случаях, потом проводим процесс валидации, запускаем мониторинг, потом начинаем это все контролировать в продакшене и возвращаемся на 1 этап. И у нас цикл замыкается.
14: Более того, если копнуть совсем поглубже, то в конечном итоге инженер в классической разработке программирует поведение. В случае разработки агентов он проектирует среду, и того ваш агент не упадёт, он
15: И важно понимать, что это не какой-то софт с багами, а это эмэль система с backend инфраструктурой и агент это принципиально другой класс систем, и важно, что нужно относиться к ней соответственно, итого агенты
16: Это сумма 2 навыков эмэль и бэкэнда. И на самом деле мы с вами, как разработчики агентов, должны взять все самые лучшие подходы и оттуда, и оттуда, и, соответственно, если вы проектируете агента, как
17: Обычный сервис, то, скорее всего, вы проиграли, поэтому 1 этапом, что нужно сделать, нужно формализовать задачу. Нужно чётко убедиться, что приходит на вход, текст, голос, документы, структурированные данные, как они выглядят, и прочее. Нам нужно формализовать выход.
18: Который мы ожидаем от агента, что мы будем ждать ответ, действие, какой-то документ, какой-то структурированный вывод. Кроме того, полезно и важно сразу огородить скоуп работы агента, что
19: Собственно, агент делает, и чего он не делает, более того, то, что он не делает, то бишь граница для него при разработке агентов намного важнее, чем-то, что агент должен.
20: Делать кроме этого, на этапе формализации мы должны выделить некоторые критерии успеха, чтобы мы в дальнейшем смогли понять, что наш агент работает, и metric вроде окей.
21: В данном случае не подходит, потому что мы уже на этом этапе должны продумывать метрики, метрики, оценки, качества, а также начинать собирать корзинки с нашими задачами для того, чтобы мы могли их оценить, их работу.
22: Конечно же, в самом начале лучше сразу же оценить и подумать про age кейсы какие-то что мы будем делать, что будет делать наш агент в случае, если input или пришёл некорректный, или что если tool, который мы пытаемся вызвать?
23: Вдруг станет недоступен, потому что агент может получать ошибки, интерпретировать их по своему, для того, чтобы решить задачу. Но часто это может быть, например, какая-то галлюцинация, которая на самом деле, так как у нас мульти.
24: Система может стать неприятностью для 1 шага, но при этом этот, эта галлюцинация является входом для следующего шага, и тогда это уже катастрофа. Очень важно также сразу определить границы работы.
25: Агента и определить точку некоторого фолбэка, да, то есть точку когда нужно эскалировать и когда передать управление уже непосредственно человеку
26: И прежде чем мы начнём писать первые строчки кода, тестить лмки, стоит задуматься ещё об 1 очень важном вопросе это экономика. Почему же экономика агентов так важна? Потому что та экономии
27: Saas систем, к которому мы привыкли за многие годы разработки программного обеспечения, когда стоимость обслуживания энного пользователя стремится к нулю, и каждый новый пользователь это почти чистая прибыль, то в агентных система.
28: Каждый запрос стоит денег, и если юнит экономика не работает на 10 пользователях, то она не заработает и на 100 пользователях, поэтому здесь на 1 место выходит себестоимость проданных товаров или или услуг так называемый кокс.
29: Он снова начинает иметь значение, и это довольно принципиальное отличие от классических сас систем. На 2 шаге мы должны посчитать косты и оценить их. На самом деле существует 3 уровня Костов ай агента с 1.
30: Стороны это инфиренс кост. Те самые цена за токены, которые мы обсуждали с вами на прошлом занятии. Вот. Но важно отметить, что на 1 запрос агента не обязательно будет всего лишь 1 вызов. Это может быть 3 или 15 вызовов лм плюс.
31: Какие-то инструменты, кроме этого, нельзя опускать инфраструктурные расходы, это и компьют, и хранение нашей векторной базы, и хранение эмбеддингов, и прочее. Более того, очень часто люди забывают учесть
32: Что есть какие-то скрытые расходы, например, это затраты на верификацию и на человеческую оценку наших работы нашего агента. Давайте посмотрим на пример расчёта цены за сессию.
33: И вот здесь, в нашем примере, мы видим, что при разработке кастом саппорт агента мы видим, что стоимость 1 сессии 30 центов. При этом, если сравнить с человеком, который закрывает ту же самую сессию за 2 тире 6 $, то мы видим
34: Что агент в 13 раз дешевле, но на самом то деле это только для тех запросов, которые агент решает правильно, потому что если 30 ответов неправильные и требуют какой-то реработать, экономика будет меняться.
35: И, конечно же, очень важно оценивать не просто цену за сессию, но цену за успешную сессию. На самом деле, при разных вот сексес рейтах у нас цена будет сильно меняться и возможно,
36: Агент перестанет окупаться, если success рейд будет слишком низкий или если объём задач слишком маленький, при этом, если задачи слишком разнообразные, это тоже будет плохо работать с точки зрения экономики в прошлый.
37: Лекциях мы уже обсуждали то, как подходить к оценке качества работы реагентов. Давайте сейчас попробуем собрать в общую кучку и формализовать. У нас есть на самом деле 3 важных столпа, на которых стоит подход.
38: Под стоят подходы оценки качества. 1 это промт, инжиниринг. На самом деле промт, инжиниринг это не какое-то искусство, это не магия, это система. Во первых, малейшее изменение формулировки промта может драматически изменить поведение.
39: Модели. Более того, хорошие промты повышают точность, снижают галлюцинации, делают поведение более детерминированным. Более того, зачастую написание хорошего промта приводит более к лучшим результатам, чем даже до обучения модели, но
40: Без системного подхода к подбору Пронтов и вообще работы с пронта. И очень сложно масштабировать использование лмок. Более того, нужно помнить, что трансформер модели часто страдают от так назы,
41: Attention диккей это означает, что чем длиннее контекст, тем меньше будет вес у нашего системного промта, то есть на 50 ходу диалога ваш агент может просто вообще забыть кто он и какую задачу он должен решать.
42: Поэтому промты и пайплайны должны развиваться как программный код с версиями, тестами, сиаем и, конечно же, очень правильно сразу использовать, например, гид для версионирования или любое
43: Хранилище любой или любой инструмент, специально созданный собственно для версионирования Промтов, и, конечно же, промты должны проходить через классическую ветку Тестов и на самом деле очень сильно помогает при работе с промтами.
44: Написание Промтов не в виде спагетти текста, а с помощью какого-то декларативного подхода, который, например, предлагается в библиотеке диспа, которую мы обсуждали на прошлом занятии. 2 важный момент в оценке качества это
45: Валидация. И на самом деле это 1 из важнейших Шагов, и о нём нужно подумать ещё в самом начале проектирования нашей системы. Про него мы тоже говорили на прошлом занятии, что обычно валидационный пайплайн выглядит следующим образом, что
46: У нас есть какая-то корзинка наших задач, мы прогоняем модельку и потом каким-то образом оцениваем работу нашего агента, но у этого, к сожалению, есть определённый набор проблем. Во первых, это переобучение, переобучение к валу.
47: Когда у нас агент идеально решает каких-то 100 наших тестовых задач, но ломается на какой-то 101, потому что prompt оптимизирован под эвал, а не под реальность, более того, бенчмарки показывают.
48: Качество сегодня, а завтра модель обновилась, данные изменились или вообще среда как-то поменялась и у нас все ломается в продакшене. Это означает, что это все работает на известных задачах, но продакшн это бесконечное множество Неизвестных задач.
49: На валидации мы проверяем финальный ответ, но финальный ответ это не траектория, потому что агент может дать правильный ответ, но при этом вызвать 15 Тулов вместо 3. А это дорого, медленно, хрупко, потому что когда агент получает правильное,
50: Ответ неправильным путём, то это бомба замедленного действия. Сегодня этот путь сработал, завтра не сработал, и поэтому на самом деле нашим нашими глазами и памятью является трейсинг и логирование. И это 3 столб.
51: Подхода к оценке качества в пайплайне могут быть десятки промежуточных Шагов, вызовы, функции фильтрации, роутинги, цепочки рассуждений, а без трассировки не будет. Возможно понять, где произошёл сбой, как сравнить старую версию пайплайн.
52: С новой как вообще объяснить поведение модели заказчику? И обычно в валидации траектории оценивают следующие вещи во первых, это количество Шагов, то есть наша оценка нашей эффек.
53: Активности работы агента, потому что 3 шага вместо 10. Очевидно, что это дешевле, быстрее и надёжнее. Кроме этого, мы должны оценивать правильность выбора Тулов. Был ли вызван нужный тул, не были ли вызваны лишние
54: Конечно же, промежуточные мысли агентов тоже имеют смысл, поэтому очень важно оценивать качество рассуждений, что агент действительно дошёл до правильного ответа или он просто его угадал. И, конечно же, нужно обязательно логировать
55: Все ошибки, адекватность реакции агентов на возвращение, допустим, ответов из инструментов и так далее. Кроме этого, конечно же, нужно трёкать используемые токены и так далее.
56: Вообще, на самом деле, на этом этапе, чем больше информации вы соберёте, тем лучше вам будет дальше дебажить нашего агента, итого путь к зрелой, управляемой, предсказуемой.
57: Инфраструктуре, это 3 основных вещи, это системный подход к валидации, логированию и промт, оптимизация. Но здесь важно отметить ещё 1 момент, что на офлайн валидации вы контроли,
58: Обычно инпут. И знаете, какой-то ожидаемый аутпут запускаете на какой-то корзинке задач. И это на самом деле версионное тестирование, но на реальном трафике вы не знаете ожидаемые выходы. И тут не очень понятно, как оценивать при
59: Валидации можно использовать разные подходы. Например, можно использовать джадж для того, чтобы на случайной выборке реальных Разговоров отдельной моделью оценить качество, корректность, безопасность и другие какие-то параметры.
60: Очень полезно использовать пользовательские сигналы. Это какие-то пальцы вверх, пальцы вниз, опять же повторное обращение, уровень эскалации. Ну, собственно, когда у нас агент передаёт управление человеку очень
61: Важно следить за какими-то прокси метриками, например raid хорошо выполненных задач, временно временно резолюшн, какой-то проблемы пользователя и так далее и
62: Опять же, косты на сессию. Более того, здесь также, как и в классической разработке, работает б тестирование, когда мы берём новый промт, сравниваем со старым и, например, делаем это на 5 про
63: Трафика и сравниваем наши метрики, при этом не забывайте, что можно, например, новый пайплайн включать в shadow mode, когда мы используем старый пайплайн, но параллельно.
64: Прогоняем ещё и новый. Итого агент умеет решать какие-то задачи. Это не равно и не эквивалент тому, что агент решает эти, решает задачи реальных пользователей, поэтому очень важно оценивать траектории.
65: А не только финальные ответы. И вообще подход к оценке качества это непрерывный процесс, это не какой-то чек лист и является очень важной составляющей при разработке нашего агента для того, чтобы, собственно,
66: Хорошо работать с промтами, проводить оценки качества и оценку траектории агентов. Удобно использовать различные инструменты, такие, как, например,
67: Который мы обсуждали в прошлом занятии. И такие инструменты позволяют логировать каждый шаг, промты, ответы, метаданные оценки качества, время отклика и вообще все что угодно. Здесь, на слайде представлено сравнение таких фреймворков.
68: Decision trees для этого довольно простой, соответственно, если уже используем Ланк чейн для построения агентов, то вполне себе адекватным решением будет продолжать использовать экосистему данного провайдера и, например, внедрять у себя.
69: Lang смит, если нужен селхоз, то, конечно же learn фьюз идеальный кандидат для этого, потому что у нас, собственно, опенсорсное решение. Брейн траст, например, предлагает эвал в сиайсиди, процессе. А если мы хотим какой-нибудь прям быстрый старт и нам
70: Важнее быстрее запуститься, то отличным подспорьем. Для начала может быть продукт под названием хеликон. Давайте сейчас перейдём к инженерным компромиссам. Важно понимать, что у нас на самом деле 3 рычага это летенси качество.
71: И цена, и в я агентах применимо правило, что любые 2 из них оптимизируются за счёт 3, и это такой трейдов между 3 рычагами, потому что если у нас хочется
72: Быстрое и дешёвое решение, то, скорее всего, мы жертвуем качеством. Если мы хотим быстро и качественно, то мы получаем удорожание работы агента. Если мы хотим качественно и дёшево, то, конечно же, мы получаем
73: Медленное решение. Здесь много. Можно использовать каких-то практических Шагов. Для этого, например, роутить модель по сложности запроса. Когда мы на каким-то классификатором на входе определяем
74: А какую модель использовать подороже и побольше или, наоборот, лёгкую и быструю? Конечно же, очень полезно использовать одинаковые system промты, потому что cash помогает экономить и
75: И кроме этого, например, есть различные астинг режимы работы с моделями, когда мы, когда, допустим, нам не очень важна летенси, и, но мы можем ожидать ответ долго, когда он
76: У нас, например, кейс, что раз в когда-то, раз, раз в сутки мы, допустим, анализируем отзывы пользователей на сайте, тогда мы можем действительно запускать такой расчет там ночью и собирать его уже
77: Когда моделька посмотрела все отзывы, это собирается, например, какие-то бачи и у многих провайдеров, у моделей на bach апи есть хорошая скидка, так же как и на асинк режимы и в качестве итога.
78: Того, что мы говорили до этого, можно посмотреть на пример того, как вообще может выглядеть пайплайн приёмки. Итак, у нас есть оффлайн, валидация, какая-то корзинка задач. Мы прогоняем любые наши изменения по ней, если мы видим, что
79: Мы его прошли тогда мы в shadow mode запускаем реальный трафик на какое-то количество процентов, но при этом ответы реальным пользователям не отправляем, смотрим на наши метрики, если все окей, то тогда мы начинаем канареечное тестировании.
80: Deploy и там запускаем на ещё 5% трафика наших пользователей. Если мы видим, что деградации нет, то тогда, собственно, происходит роллаут на всех 100% пользователей, но при
81: Этом пайплайн приёмки не оканчивается, потому что мы продолжаем валить в онлайне и навешиваем как можно больше алертов на каждом этапе, потому что каждый такой этап может заблокировать переход на
82: Следующий. А теперь давайте перейдём к следующей части нашего занятия. Поговорим про архитектуру и паттерны наших систем. На самом деле можно выделить 6 слоёв наших
83: Агентов есть уровень 0. Это собственно инфраструктура, это все, что связано с компьютером, сетью, мониторингами. На следующем слое у нас уже сами модельки инференс роутинг и кэш.
84: На слое выше у нас есть память, какие-то состояния, контексты, рагги и прочие подходы на слое выше. У нас собственно инструменты какие-то интеграции с мцп.
85: Которые мы тоже обсуждали. Апишки, походы в базу данных и прочие связи на слое выше. Есть оркестрация. Это, собственно, то, как у нас координируются агенты и шаги между ними.
86: И вишенкой на торте нашего слоистого пирога. Это, собственно, юикс и пользовательское доверие. То есть то, что видит пользователь. И на самом деле про пункты про инфраструктуру, память и модели мы обсуждали
87: Поэтому сейчас мы перейдём на слои выше. На самом деле здесь есть довольно прикольный инсайд про то, что большинство команд вообще тратят 90% времени на нижние слои нашего пирога и лишь 10%.
88: Процентов на те, которые выше, хотя при этом в продакшене 90% проблем связаны с оркестрацией и с ux, например, я очень часто вижу такие кейсы, что люди
89: Жалуются на медленную, на медленную генерацию, на through путы и так далее. А все может решиться, например, просто включением стриминга на на иксе для пользователя, потому что скорость чтения пользователем не
90: Всегда быстрее, чем скорость генерации текста моделью. На самом деле, когда мы говорим про архитектуру, можно провести аналогию, например, для кубернетиса. У нас есть контрол плейн, это система, которая управляет кластером.
91: И на самом деле нельзя опускать тот факт, что агентам, а тем более многоагентным системам, тоже нужен свой аналог контрол плейна, и он может состоять из нескольких компонентов. Во первых, это реджестри агентов, собственно,
92: Какие агенты у нас существуют? Какие Тулы у каждого из них, какие доступы у этих агентов есть? Это должен быть компонент, который отвечает за роутинг. Собственно, какой агент обрабатывает? Какой запрос у нас должен
93: Быть компонент, который отвечает за лимиты, за бюджеты и tha прочее, связанное с инференсом, есть компоненты, которые мы вот до этого подробно обсудили, это связанные с обсервабилити трейсинги, логи, метрики и все прочее.
94: И есть ещё 1 важный компонент, который очень важен для продакшена. Это так называемый гаверненс, это, собственно, аудит трейлы, это какие-то проверки гардрейл и проверки на соответствие комплаенсу и прочим другим.
95: Риском, раз мы с вами начали говорить про то, что у нас есть какие-то модули и компоненты. Важно понимать, что при разработке агентов используются те же самые принципы, что и в разработке программного обеспечения. Поэтому при декомпозиции
96: Следовать тем же правилам во первых, модули должны иметь высокую сопряжённость это означает, что каждый сфокусирован на решении 1 проблемы или функции, и его следствие это принцип единственной ответственности, и отсюда можно
97: Сделать вывод, что если у нас есть 1 домен, то там должен быть 1 агент. Если у задачи есть общий контекст, то 1 агент будет работать лучше, чем 2. И так как у нас модули
98: В соответствии с принципами разработки поо должны быть независимы и слабо связаны друг с другом, а это называется принципом слабой связанности, то буквально это означает то, что при изменении 1 модуля не придётся править.
99: Или эти изменения будут минимальными и для агентов это также валидное правило, потому что они должны быть связаны через интерфейсы, а не через их внутреннее состояние. При этом каждый агент должен быть тестируемым.
100: Изолированно друг от друга. Я на самом деле вам предлагаю самостоятельно подумать о том, какие другие базовые принципы из разработки по применяются в агентах. Например, возьмите прям тот же самый солит и посмотрите, как каждый из этих пунктов трансформируется и при
101: Меняется в агентах, и раз уж есть декомпозиция, то пора поговорить о том, как вообще должно быть организовано взаимодействие агентов. И ранее мы уже упоминали паттерны. Давайте попробуем их тоже формализовать. И на самом деле сейчас
102: Есть 2 основных паттерна. 1 паттерн это паттерн от антропиха, и он формулирует свои паттерны от простого к сложному. 1 это цепочки. То есть, когда у нас шаги заранее известны, и это довольно понятный и
103: Самый базовый паттерн, когда выход 1 агента используется в качестве входа для другого агента, но когда типы запросов отличаются, например, как в задачах кастомер супорта, то нам на помощь приходит паттерн роутинг. Это так называемая маршрутизация.
104: Когда у нас есть специальный агент, у него есть заранее понятное количество опций, и он, классифицируя запрос пользователя, роутит его в соответствующего агента, который отвечает за конкретный кусочек пайплайна.
105: Но бывает так, что у нас эти подзадачи могут выполняться независимо, и тогда мы их можем выполнять параллельно, и для этого есть паттерн параллелизации. Бывают случаи, когда мы не знаем сколько
106: Вот таких параллельных вызовов нам потребуется, тогда применяется паттерн оркестратор, и в данном случае оркестратор сам решит, сколько воркеров ему надо, и обратится к нужному количеству агентов. Кроме того, мы изначально можем иметь чёткий
107: Критерии качества и соответствия ответ сгенерированного модели нашим политикам, компании тону и прочим каким-то параметрам. И мы на самом деле можем начать генерировать ответ.
108: Пока не будем им соответствовать этим правилам, и тогда применяется паттерн, эвалюатор и оптимайзер. Собственно, мы будем находиться в цикле до тех пор, пока не пройдём наши проверочки. На самом деле вот такие паттерны.
109: Позволяют нам построить любую логику и цепочку взаимодействий, и их довольно понятно, как комбинировать для того, чтобы решить практически любую задачку. И если антропин, рассматривая свои паттерны, предлагает
110: Их архитектуру с фокусом на выстраивание флоу данных, то, например, google, напротив, рассматривает агентов с фокусом на представление их как отдельных компонентов там на самом деле.
111: 12 паттернов. Мы оставим вам ссылочки. Эти 12 паттернов живут в 4 классах, и, собственно, они могут быть детерминированными, динамическими, итеративными и даже специальными. Вот мы не будем сейчас их подробно обсуждать, но здесь
112: Мы расскажем про google, адк и google адк это фреймворк для того, чтобы, собственно, реализовывать работу агентных систем, и google адк предлагает 3 механизма взаимодействия между агентами.
113: 1 механизм называется session state, это пассивная коммуникация, когда у нас агент 1 агент пишет какой-то, какой-то стейт в отдельное хранилище, а другой агент его читает, и это на самом деле главный способ для того,
114: Чтобы реализовывать какие-то последовательности, цепочки и циклы, другой механизм, который предлагает нам google дк это lm driving delegation то есть это координатор, который сам решает, кому отдавать задачу, то есть не нужно писать никакие там.
115: Eels, мы просто даём координатору список субагентов и их описания и ллм на основе каких-то описаний решает, кому именно делегировать задачу и 3 механизм, который нам предоставляет google dc.
116: Это эксплисит, агент тул, основная концепция паттернов гугла, что агент az атул, то есть мы явно оборачиваем каждого из наших агентов как инструмент для другого.
117: Пример координатор вызывает субагента как обычную функцию и ключевая идея здесь это инкапсуляция, то есть агент б вызывается агентом, а как обычный инструмент, но при этом, а не знает, что внутри б отдельно.
118: Лмка с рагом, рассуждениями и так далее. И на самом деле приводит нас к тому, что у нас появляется такая микросервисная архитектура для, а раз уж мы заговорили про
119: Google адк, то давайте отметим, что на самом деле сейчас существуют и другие фреймворки для разработки агентов, давайте их обсудим и разберёмся в ландшафте на самом деле важно признать, что на текущий момент
120: В мире адк происходит какой-то буквально дикий запад, их уже десятки. И пока нельзя однозначно сказать, что какой фреймворк лучше. На самом деле вопрос не в том, какой фреймворк лучше, а то, какой подходит именно вам, потому что
121: Они разные, потому что они имеют фундаментально разные подходы к тому, как могут быть устроены агенты, и то, как они взаимодействуют друг с другом, и 1 из таких фундаментальных подходов.
122: Это, собственно, представление работы агентов в виде графа. То есть у нас буквально есть узлы и переходы между этими узлами, где мы мы можем прям буквально нарисовать
123: Такой, такую цепочку взаимодействия агентов, это позволяет нам обеспечить максимальный контроль над ними. И на самом деле вот такой подход пропагандирует фо. Он самый зрелый среди всех.
124: Он уже несколько лет в продакшене, там безумное количество звёзд на гитхабе. 2 подход это иерархия, это вот те самые паттерны, которые мы только что обсуждали. Их пропагандирует гуугл дк и
125: Dk. Агентский от openai, то есть буквально когда у нас есть какие какой-то координатор, который делегирует различным агентам специалистам разные задачи. 3 подход, когда у нас есть буквально разговор.
126: И это crew, ai и автоген от майкрософт мы в таком подходе собираем команду с ролями, они между собой общаются интуитивно и непредсказуемо есть.
127: Всем ортогональный подход это подход собственно от cloud agent сдк от компании тропик, когда, когда он основан на компьютере, то есть мы буквально даём моделькам баш файлы какие-то мцп Тулы.
128: И она уже сама решает, че, че вообще с этим делать, как к этой задаче подходить. Сама пишет код. И на самом деле клауд код работает именно вот поверх этого фреймворка есть ещё 1 подход, и он такой, можно его
129: Назвать мцп нейтив это фреймворк, тренс от amazon. И основная концепция такая, что давайте все делать через мцп буквально. То есть у нас есть Тулы интеграции и вообще другие агенты.
130: И это, и он будет использовать 1 протокол для всего. На самом деле. Вот фреймворк от амазона самый молодой среди всех упомянутых мы уже касались на самом деле, вот протоколов общения между агентами и
131: Мцп и agents to agents. Давайте ещё раз проговорим и формализуем, чтобы это финально застолбить. Во первых, мцп это способ взаимодействия агентов и Тулов. Это условно как
132: Юэсби, когда у нас есть 1 разъём и 1000 компонентов для него. А agents to agents это, собственно, протокол взаимодействия между 2 агентами, когда 1 агент вызывает другого через какой-то стандартный контракт взаимодействия между ними. Почему для
133: Это важно, на самом деле важно, потому что выбор фреймворка не навсегда. Выбор фреймворка зависит от того, как в конкретном случае решать текущую задачу. А вот способы взаимодействия
134: То и с миром, и друг с другом. Это уже, собственно, основа и некоторый стандарт. И главное правило на самом деле, при этом, которое у нас повторяет каждый из вендоров адкак
135: И антропки, и google, и open eye, что нужно начинать с самого простого решения простым кодом мы перестали справляться, тогда мы уже подключаем фреймворки, вот, соответственно, тот же самый подход от простого к сложному в заключении давайте поговорим.
136: О том, куда же все это развивается и куда несётся 1, что нужно признать, что модели становятся коммодити, что это буквально означает, что за последние 2 года инференс подешевел больше, чем
137: В 2 раза. И вот тут можно отследить, что за последний год только стоимость инференса моделей упала на 78%, и на самом деле сейчас ценность уже не в модели, как изначально было, и даже не в модели и промте, а ценность в системе вокруг этой модели.
138: И сейчас очень важно отвечать на вопрос не то, какая модель, а то, какая система построена вокруг модели, потому что модели становятся взаимозаменяемы и ценность как раз-таки в оркестрации тулах и ux, и если
139: Раньше мы ставили себе задачу, как напиши хороший промт, то сейчас промт это 20% поведения, а все остальные 80 это Тулы, данные, гардрейл, какие-то фидбэк, лупы и прочее.
140: Ещё 1 важный сдвиг, который мы увидели за последние годы, что мцп и agent т agents превращают агентов действительно в микросервисы, и более того, на рынке труда появляются новые Роли это и.
141: Агентские архитекторы и инженеры по ивалу, агент опсы и, более того, компании уже нанимают на эти позиции можно спрогнозировать, что модели дальше будут становиться только лучше, быстрее, выше, сильнее.
142: Их инференс будет удешевляться и становиться более доступным, но цениться все больше будут инженеры, которые умеют проектировать системы вокруг этих моделей и вокруг агентов. Поздравляю, вы почти приблизились к этому.
143: В рамках нашего интенсива. И спасибо, что были с нами.