0: Всем привет и мы продолжаем наш 3 день. Сегодня на семинаре мы более подробно рассмотрим на практике темы агентского воркфлоу и наших мультиагентных систем. Мы разберём наш tau цикл посмотрим
1: Как выглядит реализация реакт агентов? Рассмотрим иерархическую мультиагентную систему и в конце добавим для неё критика. После этого сравним разные подходы, их плюсы, минусы. И как они будут у нас, рабо.
2: Работать на схожих примерах. С чего мы начнём это с настройки окружения настраиваем. Мы все аналогично прошлым семинарам, устанавливаем зависимости и проверяем, что мы можем
3: Выполнить запрос к указываем свой ключ, и, запустив этот блок, мы должны увидеть результат ответа в формате 1 слова ес, если мы получили ответ.
4: Все хорошо, мы можем работать дальше. Так, теперь давайте рассмотрим наши Тулы, с которыми мы будем работать внутри наших агентов. Они аналогичны тому,
5: Что мы уже использовали на предыдущих занятиях, и мы немного их расширим по самому составу источников данных, с которыми мы будем работать. У нас остаётся база наших.
6: Мы будем иметь 4 рейса, с которыми будут работать наши агенты, дальше идёт база с бронированием, и источник данных про политики авиакомпании это определённые правила.
7: Для кейсов, например, Репутина отмены и проезда с багажом.
8: После этого мы добавим все наши источники данных для работы и увидим полное количество того, что будет внутри них, чтобы проверить, что они проросли теперь.
9: Давайте перейдём к самим тулам, которые будем использовать. У нас будет тул для поиска рейсов, когда мы будем передавать на вход наш источник назначения место, откуда мы вылетаем, и дату
10: Дальше мы можем заполучить с помощью Тула Гетт флайд тейл более расширенную информацию о нашем Рейсе, передав на вход его номер. Следующий Туул это get букинг он принимает
11: На вход id бронирования и выдаёт нам информацию о самом бронировании. Следующий аналогичный get полайс передаём на вход сам тип политики и
12: Уже возвращаем конкретную информацию о ней и последний, более сложный Туул это обновить бронирование. Тут мы на вход передаём наше ди бронирования, наш рейс, на который мы хотим сменить и дату.
13: Рейса, на который мы планируем перенести наше бронирование. Дальше собираем из всех наших Тулов 1 единый список и можем приступать к реализации наших агент.
14: 1 агент, которого мы с вами реализуем, это простой одиночный агент в формате реакт. Как мы помним по лекции реакт агент чередует фот экшн обсервейшн вызывает Тулы и с
15: Этого уже получает финальный результат работы, который можно дать пользователю. Сначала зададим его системный пром. Как мы помним, стратегия реакт агентов по
16: Формату размышления задаётся именно на уровне проминка мы явно укажем нашему агенту, что он должен проанализировать, выполнить и вызвать ряд Тулов и после этого обработать финальный результат.
17: Понять, можем ли мы ответить на запрос пользователя. Также в промте мы укажем общие правила для работы нашего агента и перечислим список Тулов, чтобы он понимал, что в каких кейсах он мог
18: Вызывать. Теперь давайте перейдём к самой реализации агента. Реализуем функцию крик агент, которая будет принимать на вход список Тулов и наш системный пром.
19: Вначале проверим, что не список Тулов, если он у нас до этого не был определён, определяем его тулами, которые мы посмотрели до этого и задаём системный промт в формате системного
20: Та, который у нас был рассмотрен ранее. Теперь давайте проинициализируем саму м, с которой мы будем работать внутри нашего агента. Передадим сюда список Тулов и, кроме этого, зададим
21: Специальный флаг, отключение параллельной работы, чтобы более детально и наглядно посмотреть наш фото цикл. После этого мы реализуем ноды нашего агента. Основная Нода это агент нод, она принимается
22: Состояние, и в рамках него уже будем делать вызов наше м. Сначала мы должны будем составить само сообщение, с которого мы будем делать этот вызов. Для этого мы проверяем, если у нас уже
23: Наш системный фронт в рамках сообщений, если нет, мы его добавляем и обращаемся с сообщением клм, который мы инициализировали до этого. Теперь мы смотрим, если у нас какие-либо
24: В ответе от Алан вызовы Тулов. Если мы понимаем, что они есть для отображения нашего шага, фото мы сделаем небольшой
25: Haak для более наглядного отображения всего цикла, как мы уже с вами видели и обсуждали, что некоторые модели с встроенным фанкшн колином, они могут шаг фото пропускать. Для этого мы
26: Отдельно отследим вызов нашего Тула и попросим модель объяснить явно, почему в данном случае был выбран тот или иной инструмент. Также это добавим к
27: Нашему итоговому ответу и вернём результат. Следующая небольшая Нода. Это как раз шут континио, механизм, который нам будет нужен в случае обработки Тулов, если мы видим
28: Что последнее сообщение был вызов Тула, то мы возвращаем тул. Если же мы понимаем, что никакой тул уже не возвращался, значит, мы находимся на этапе, когда мы готовы дать финальный ответ, и мы возвращаем энд теперь.
29: Сам граф нашего агента дадим граф, зададим ноды, которые мы определили агентскую ноду, передадим Тулы и в рамках рёбер зададим как раз формат.
30: Который проговаривали при разборе реакт агента. Если у нас есть вызов Тулов, то мы их вызываем. Если нет, то будет возвращён энд, и мы совершим исполнение нашего агента.
31: По самой кор части реакт агента мы реализовали все, что нужно теперь мы можем вызвать саму функцию create react агент и получить агентом с которым мы уже дальше будем.
32: Работать. Так теперь давайте реализуем отдельную функцию, которая нам позволит запустить нашего агента и более детально вывести информацию о тау цикле.
33: В неё мы передаём агенту и запрос нашего пользователя, который хотим, чтобы наш агент обработал сам вызов агента. Мы поместим между блоком, который позволит нам замерить время и
34: На вход передаём квери параметр, который нам пришёл на вход нашей функции. После этого, по сути, сама часть с обработкой всего запроса закончена. Дальнейший код, который мы будем рассматривать, это более детальная
35: Визуализация того, что было в нашем тау цикле. Для этого мы пройдёмся как раз по тому, что у нас пришло внутри нашего месседжа. 1 блоком мы посмотрим, если наш месседж тайп является аи месседж, и при
36: При этом содержит тул коллс. Тогда мы понимаем, что начался новый цикл нашего тао цикла, и мы должны из сообщения получить наш
37: Вот шаг аналогично мы можем получить то, что у нас было в экшенах если же тип нашего сообщения это tool месседж, значит, мы уже перешли к шагу обсерв.
38: И можем получить на вывод конечный результат работы Тула если же мы понимаем, что Тулы не вызывались и при этом месседж тайп это i massage, значит, мы получили наш финальный.
39: Ответ и можем уже его так и отобразить по сути все дальше мы будем рассматривать наши кейсы по react агенту с помощью этой функции run н трейс давайте рассмотрим.
40: Сначала наиболее простой пример попросим рейсы, которые мы можем получить из Москвы в Париж, на определённую дату. Посмотрим, что вернул наш агент. Мы видим, что у нас
41: Прошёл только 1 step нашего тау цикла, и этого нам хватает. Мы видим явно, что агент рассуждает на тему того, что он должен сделать для решения задачи. Видим, что выбирает.
42: Верная функция для вызова Тула по получению рейсов. И видим, что у нас был получен нужный список наших рейсов. На основе этих данных. Наш агент как раз идеально и правильно нашёл все не
43: Необходимые данные. Тут react, агент нас полностью устраивает. Все хорошо, давайте теперь попробуем что-то более сложное, например, кейс, когда будем ожидать от агента несколько действий, но при этом
44: Не слишком его перенагружать и явно укажем по пунктам, что нам нужно сделать и что мы хотим увидеть. Теперь мы видим, что наш агент уже прошёл не 1.
45: 3 Стёпа тау циклу, и в каждом из этих Степов он аналогично получал нужную часть данных для решения финальной задачи и в конце.
46: Финальном ответе смог нам предоставить хороший финальный вариант, который нас также по качеству устраивает. Теперь давайте посмотрим, как бы наш реакт агент работал на ещё
47: Более сложном кейсе, когда мы ожидаем, что он выполнит несколько Шагов, но при этом явно не указываем ему какую-то последовательность, а только описываем какой-либо образ результата, что мы видим на этом?
48: Примере. У нас уже целых 4 Стёпа нашего тао цикла, и в каждом из Шагов агент, верно подобрал Тулы, верно подобрал параметры в целом, верно?
49: Для получения финального ответа обработал весь контекст, но в данном запросе, кроме самих финальных данных, мы просили ещё и сравнить стоимость, которая у нас будет.
50: Относительно различных политик, хоть наш агент эту информацию получил. То есть он видит, что разница 80%, информация эта, у него была, никакого информации о сравнении
51: Льном ответе он нам не предоставил чуть чуть он потерялся в контексте и сосредоточился на том, что у нас возвращали более поздние шаги, что мы видим на примере этого react агента мы видим, что
52: С какими-то более простыми задачами он справляется прекрасно. Все хорошо. Также можно обратить внимание на время исполнения самого агента. Это довольно быстро. Почему это быстро? Мы также ещё посмотрим.
53: На примере других агентов, которые будем рассматривать дальше. Тут основная мысль, которую стоит держать в голове, что если задача простая, хорошо идём в реакт агента и получаем быстрый результат с минимальными
54: С минимальными затратами по разработке. Но если мы хотим более сложные задачи, как в последнем кейсе, это мотивирует нас уже переходить к нашим мультиагентным системам. Теперь давайте рассмотрим нашу 2 часть
55: В теории на лекции мы уже более детально разобрали различные подходы, на практике же мы рассмотрим нашу иерархическую систему как самую популярную и посмотрим также принципы мультигенных систем.
56: Как они ложатся у нас уже в коде во время самой самого процесса разработки нашего агента. И прежде чем перейти к более детальному коду агента, давайте посмотрим небольшой код по
57: Потому что нам будет необходимо для работы с ним создадим базовые модели, такие как, например, модель с подзадачей, у которой будет задаваться имя агента, описание самой задачи.
58: И у задачи также мы будем уметь ставить приоритет. Следующая модель это модель уже для результата работы нашего планировщика. У нас будет поле ризонинг, в котором мы укажем
59: В целом, что мы хотим достичь и будет список наших подзадач, которые для этого нужно выполнить. Следующая моделька финальная. Это модель нашего агентского результата. Тут мы также указываем имя агента, который
60: У нас данный результат выдал. Выбираем 1 из статусов и в результате также добавляем финальный ответ и список Тулов, который был использован для примера.
61: Сама моделька планировщика выглядела бы примерно так. То есть мы задаём конкретно, что мы должны сделать и в формате уже не текста, а конкретных классов. В формате списка мы будем
62: Получать информацию о том, какой агент должен сделать, какую из под задач и с каким приоритетом. Давайте рассмотрим нашу реализацию уже самих агентов и начнём с агента специализации.
63: Нашего субагента, который будет выполнять наши подзадачи у него при его создании, мы укажем ему имя, передадим Тулы, с которыми он будет работать, и создадим для него граф в рамках графа. Мы также
64: Используем функцию, которая нам позволяет уже создавать и работать с react агентами. Теперь реализуем саму функцию вызова обработки нашего специализированного агента мы
65: Обращаемся к нашему графу и обращаемся к нему для выполнения запроса с передачей самой задачи, которую мы получили на вход функции процесса. После этого мы
66: Тулы, с которой у нас использовались. Опять же это нам нужно для более детальной отладки и понимания, что у нас произошло, и отдельно получаем наш финальный контент. Теперь все, что нужно.
67: Для передачи результата мы уже имеем и отдаём модельку нашего агентского результата. Также важно уточнить, что обязательно этот блок вызова агента нужно поворачивать трайкеч, так как лм. Опять же, могут часто падать.
68: Как обычные сетевые ошибки, так и по вопросам квоты, доступов и так далее. В случае ошибки мы результат возвращаем, но уже с другими параметрами. Теперь имея модельку,
69: И класс нашего агента специалиста создадим несколько шаблонных агентов, которые будут уметь работать со своей зоной ответственности. Видим, что в отличие от react агента мы уже не передаём полный список Толов, каждый агент.
70: Уметь работать со своим скопом задач и решать свои проблемы более точечно. Всех этих агентов для дальнейшей работы мы поместим на такую небольшую мапу.
71: И теперь давайте перейдём к новому отдельному типу агентов, которого мы также уже обсуждали в теории. Это агент, координатор, агент координатор у нас будет получать нашу
72: Агентов, специалистов, с которыми он будет дальше работать. Он отдельно будет иметь свою лмку. Также важно обратим внимание, что мы хотим, чтобы наш координатор возвращал результат свой
73: Работы в конкретном чётком формате, который мы как раз рассматривали до этого в моделях. Поэтому мы используем наш механизм тракт пута на практике для решения этой задачки. Кроме того, у самого координатора, как мы помним,
74: После работы всех наших субагентов будет этап, когда ему нужно подвести итоги, суммаризовал обработать все подшаги. Для этого нам какого-то конкретного и чёткого формата не нужно тут. Поэтому можем использовать обычное
75: Без ограничения по модели. Теперь давайте посмотрим сами функции нашего планировщика. Во первых, это, конечно, создание плана, что мы должны иметь на вход, чтобы создать
76: Это запрос пользователя и как результат работы данного метода. Это уже конкретная моделька плана. Тут все довольно просто. Мы обращаемся к нашей ллм, которая была создана отдельно.
77: Для планировщика и вызываем, передаём запрос нашего пользователя, при этом задаём наш системный промп, на основе которого мы уже хотим планировать и разбивать наши подзадачи. Следующая функция это исполнение.
78: Plan. Исполнение плана принимает модель, которую мы уже получили на уровне планирования и возвращает список результатов наших агентов. Тут также ещё заметим, что исполнение плана, оно
79: Glam, по сути, напрямую никак не обращается мы идём обычным циклом, обычным алгоритмом, который умеет работать с конкретной моделькой координации плана мы обращаемся к списку наших.
80: Задачи, которые нам нужно обработать. И уже для каждого агента запрашиваем реализацию каждой из этих подзадач. Когда каждый агент уже обработал задачу, мы собираем финальный лист.
81: Решение, которое каждый из них предоставил. И последняя наша функция это
82: Функция для синхронизации результата. Когда мы уже имеем и запрос пользователя, и результат всех под агентов, нам остаётся только правильно его обработать. На этом этапе мы обращаемся к
83: Которая умеет сделать нам вывод. То есть не та, которая вернёт модельку планировщика, а наша 2. И задаём системный промт. Плюс передаём на вход все нужные данные, которые мы собрали на предыдущих шагах. Теперь, да.
84: Давайте реализуем функцию, которая у нас позволит работать с нашим планировщиком и которая уже запустит полный процесс обработки задачи на вход. Она как раз принимает наш вопрос пользователя и 1 шаг.
85: Обработки нашего агента. Это будет планирование. Мы вызываем функцию создания плана, передаём запрос пользователя и на выход получаем то, что мы хотим сделать, и список
86: Задач. После этого мы уже идём на 2 шаг. Тут у нас будет исполнение плана, когда уже мы исполнили все по части нашего плана, мы запускаем наш финальный шаг. Это синхронизация. Передаём все нужные параметры и
87: И успешно получаем наш финальный ответ. Таким образом, мы реализовали нашего агента координатора, который собой представляет нашу мультиагентную систему и работает в иерархическом формате. Теперь
88: Давайте посмотрим, как у нас будет работать на практике. Давайте попробуем нашему агенту передать Ровно тот же пример, на котором мы остановились последним в реакт агенте. Мы видим, что 1 этап
89: Планирование проходит успешно, мы определяем, что конкретно мы хотим сделать для решения задачи, и, кроме этого, разбиваем эту более комплексную задачу на 5 небольших подтасов.
90: После того, как все эти подзадачи будут решены, мы получим финальный ответ. И вот можем обратить внимание на тот пункт, который нас чуть чуть смутил в нашем реакт агенте то, что
91: Данные мы все нужные получили, но какого-то сравнения финального нет. В агенте с мультиагентность мы это уже смогли получить более точный результат, который мы ожидали. Мы видим, что
92: То как раз стоимость поднимается на 80%, и нам данные не просто дали для финального представления результата, но и выполнили то, что мы изначально хотели от нашего агента. Теперь давайте ещё 1 небольшой пример.
93: Посмотрим на этом примере. Мы можем видеть, как агент работает с задачами, которые не связаны. Просто 2 разные параллельные задачи, но которые также нужно финально вместе решить. На 1 этапе у нас идёт
94: Аналогичное планирование. И потом мы каждую из этих 2 задач делегируем нашим отдельным агентам, которые являются специалистами в каждом из этих 2 вопросов, после чего видим, что наша мультиагентная система
95: В этом кейсе также хорошо справляется и выдаёт результат как по 1, так и 2 запросу что мы тут видим, мы видим, что в сравнении с react агентом нам уже получилось сделать.
96: Качество более точным и решить проблему, которая у нас возникала на 1 этапе. Кроме того, мы уже обращаем внимание на то, что сама разработка этого агента занимает чуть больше времени.
97: И время исполнения и решения аналогичной задачи также возрастает. Теперь давайте перейдём к нашей 3 части и дополним Прока.
98: Нашего агента с планировщиком, нашу мультиагентную систему, добавив в ней этап критика, как это будет происходить, мы получим аналогично результат по запросу пользователя, но теперь не сразу вы
99: Видим его, а передадим его на обработку. Ещё 1 агенту, критику этот агент примет решение, нужно ли его передавать по определённым критериям пользователю. Если да, все хорошо, мы его передаём. Если нет, то мы
100: Можем как-либо обрабатывать фулбеки, которые тут могут возникнуть. В нашем случае также рассмотрим 1 из реализаций таких сценариев и прежде чем перейти к самому слово. Также давайте
101: Смотрим, с какими модельками наш, то есть критик будет работать. Сейчас будем реализовывать самого критика, агента, модель, критик фидбэк, она как раз будет результатом работы по проверке. Во первых, мы должны пере,
102: Флаг мы передаём или не передаём вопрос пользователю. Дальше оценим наше качество ответа от нуля до 10. Если есть какие-то проблемы, также выведем это в формате строк.
103: Кроме самих проблем, предложим сразу варианты решения, которые могут нам помочь их поправить и отдельно выведем общий статус. Что у нас произошло и какой результат проверки, по сути, видим. Теперь давайте посмотрим самого
104: Агента передаём ему отдельно при создании ллм с Истра аутпут и создаём конкретную модель. После реализуем нашу функцию ревью, которая как раз будет запус
105: Для проверки ответов мы ей на вход будем давать наш пользовательский запрос и с помощью него и дополнительных данных по работе агента оценивать.
106: Как конкретно мы считаем на данном этапе, была ли задача полностью решена или нет? Как видим, агент критик не имеет какой-то сложной бизнес логики в плане алгоритма вся
107: Его основная задача и качество заключается в том, насколько грамотно мы подобрали на этом этапе сам промт проверки.
108: После мы с самой реализацией критика закончили и можем использовать его уже для нашего эксперимента с агентами, который мы продолжим. Теперь давайте реализуем отдельный класс, который нам как раз
109: Позволит обрабатывать задачи с помощью нашего критика функции. Процесс квери виз с критиком. Мы также передадим информацию о том, какой запрос пользователя мы хотим выполнить.
110: Теперь начинаем все аналогично нашей мультиагентной системы, которую мы смотрели до этого. Это этап планирования, этап делегирования работы наших агентов, специалистов, этап сбора синхронизации нашего результата.
111: И теперь, вместо того чтобы вернуть наш финальный результат, мы переходим к 4 шагу, а именно критику, мы получаем наш фидбэк.
112: С помощью результатов функции review. И уже смотрим на то, что нам пришло в данном фидбеке, если мы понимаем, что у нас была отклонён
113: Наш ответ по той или иной причине, и при этом количество попыток у нас ещё сохранилось. Также важно уточнить, что если вы делаете критика, всегда стоит позаботиться о том, чтобы ограничивать количество циклов.
114: Перепроверки, которые вы хотите делать, потому что на этом этапе также можно войти в бесконечный цикл и никогда не получить решение, которое будет полностью нас удовлетворять по качеству. Теперь что мы делаем?
115: Если мы готовы к этапу, когда мы можем как-то поработать с нашим фидбэком, соберём наш дополнительный промт, который будет учитывать всю информацию, которую нам хорошо собирает в своём.
116: Фидбеки, критик, мы учтём все ошибки, мы также предоставим для обработки наше предложение и попробуем обработать наш запрос.
117: Заново, после чего мы опять же в данном кейсе сделаем только 1 попытку перепланирования, но после неё мы для финальных результатов выберем, проверим через критика повторный.
118: Запрос ещё раз, когда мы уже получили проверенный и финальный результат, мы его можем возвращать нашему пользователю. Теперь давайте проверим, что у нас будет
119: Сходить, когда мы зададим более хитрый запрос для проверки нашего агента, мы спросим, какой из ближайших рейсов подходящий нам доступен для перепланирования, но не укажем явно, что нужно.
120: Сверить политику правил перебронирования, которая у нас внутри себя несёт 1 условие, которое отсеет часть запросов, а именно что можно перебронировать только на те рейсы.
121: Которые имеют 1 класс, то есть с эконома на эконом, а с эконома на бизнес уже у нас нет такой возможности перебронировать. Итак, попробуем посмотреть, что у нас происходит в итоге в этом кейсе, опять же.
122: Когда разрабатывала и тестировала данного агента, смотрела, что хотелось изначально продемонстрировать, как у нас будет идти повторный запрос на нашего критика, но столкнулась с
123: Довольно интересным кейсом, когда наш критик, при этом зная все правила, по которым ему нужно сравнить, сам не нашёл ошибки и выдал результат такой, что он считает, что все
124: Хорошо, при этом мы понимаем, что ошибка также оставалась, если рассмотреть ещё прогон аналогичных кейсов из точа, там на части моделей. Опять же, критика этот кейс улавливает. И когда мы дальше
125: Пробуем вызвать аналогичный кейс у того же самого критика ниже мы увидим, что на 2 попытке он уже его отловит. Это довольно забавный практический пример, который у вас, скорее всего, тоже
126: Возникать в практике конкретно. Тут причина в том, что мы используем модель джибики нано, которая не даёт довольно большого количества по приросту, ну которая сама не сможет
127: Достаточным качеством обработать нашу данную задачу. Поэтому, опять же, при разработке все эти нюансы стоит учитывать. Возможно, даже когда вы делаете все теоретически правильно. На практике могут быть самые разные кейсы и может быть множество параметров, которые
128: Будут влиять на финальный результат, что мы тут можем опять же подвести как итоги. Мы сейчас реализовали флоу критика, посмотрели, как мы можем дополнительно проверять наших агентов.
129: На качество. Также этот шаг мы понимаем, что он будет более долгий, но при этом в части кейсов он нас спасёт от более плохих ответов. Но как мы посмотрели на практике в части кейсов даже наличие критика на
130: Может не помочь. И теперь давайте более подробно сравним все наши подходы, которые мы сейчас с вами реализовали на части примеров и попробуем сделать выводы о том, когда и что нам может подойти.
131: И по реализации уже наших собственных агентских систем. Для этого реализуем наши бечмарки, соберём список вопросов, просто дадим им категорию для удобства. Будем дальше эту категорию использовать в
132: Визуальном отображении статистики и дополнительно передадим ещё список ожидаемых Тулов. То есть по каждому запросу мы знаем, по какому флоу может пойти агент. Конкретно у наших текущих агентов флоу простой идут какой-то вариации.
133: Где он может использовать тот или иной тул? Нет, поэтому мы можем явно задать ожидаемые Тулы, которые нам говорят о том, что агент действительно пошёл по верному пути и как минимум запросил все необходимые для решения ему данные и не галлюцинировал где-нибудь.
134: Теперь, после того, как сможем собрать все наши дополнительные данные, можем реализовать прогон наших агентов по самим Быч маркам, мы
135: Гоним, как? Ну да, мы, во первых, реализуем универсальную небольшую функцию, которая прогоняет наших агентов по тест кейсам, которые мы рассмотрели, и в итоге может дать нам
136: Финальные результаты по боч маркам, по прогону кейса и данную функцию заиспользуй уже для вызова на каждом из 3 подходов, какие мы рассмотрели.
137: Реализовали ранее, то есть наш реакт агент, одиночный агент, дальше наша иерархическая мультиагентная система, но без критика, и последний вариант мы уже проверим в вместе с критиком.
138: Итак, тут следующий шаг. Мы прогоняем самих наших агентов и подводим некую статистику на самом скрипте статистики. Детально останавливаться не будем. Мы, по сути, просто
139: Обрабатываем все результаты, которые прогонов и выводим их в структурированном формате. Тут давайте более детально лучше посмотрим на сам итог прогона и какие инсайды мы можем вынести, что мы видим какое-то
140: Среднее время выполнения каждого из агентов. Видим, что наш одиночный агент гораздо быстрее работает, чем наша мультиагентная система. Он использует меньше Тулов в части кейсов. Опять же, это
141: Скорее для нас тревожный звоночек, потому что мы понимаем, что где-то он не дозапросил Нужных данных, значит он точно не мог получить нашего финального, точно правильного ответа и аналогично по скору мы видим вот такую статистику, что средняя оценка для нашего
142: React агента 6 для мультиагентной системы без критика 9 и 3, что тоже достаточно неплохо и с критиком мы уже видим десяточку, теперь давайте посмотрим, что у нас было более детально по каждому из типов проверок.
143: Что мы видим на простых проверках? Тут каждый агент получил отличный скор, равный 10. Время, как мы видим, все равно всегда отличается. То есть для простых задач. В данном кейсе для нас наиболее приятно.
144: Выглядит наш обычный реакт агент, но когда мы переходим уже к более сложным задачам, мультидоменным, когда нам нужно работать с несколькими подзадачами внутри 1 запроса, тут мы видим другую.
145: Критик сразу нашёл ошибки в ответе нашего обычного реакт агента, и за счёт этого его скор получился вообще 2 балла мультиагент.
146: Система как с критиком, так и без справилась хорошо все нашли и полностью удовлетворяли условиям критика, также видим, что когда у нас нет перепрогон, время мультикино системы с критиком, ну плюс минус равно.
147: Мультиагентной системе. Что дальше? Следующий кейс самый интересный, это тот самый случай, когда мы рассматривали более сложный вопрос с подвохом.
148: На реализации нашего агента критика, что мы видим, у нас простой реакт агент тоже интересный момент, что он правильно распознал саму
149: Суть задачи вывел финальный результат, но, как мы видели, он все-таки потерялся в других контекстах и не вывел полное, более детальное описание всего, что мы от него ожидали, мультиагентная же система тут запуталась и не учла тот кейс, что
150: На бизнес мы перепрограммироваться не можем, и что мы видим, критик это отловил на уже проверке башмак и снизил ей скор, при этом сама мультиагентная система с критиком в этот раз отработала.
151: Десяточку и видим, что у нас был как раз повторный перепрогон. То есть наш критик отловил ошибку. Мы прогнали флоу во 2 раз. Вот как раз плюс - 2 раза отличается время, но мы
152: Получили полностью удовлетворяющий нас по качеству результат он и правильный, он и подробный, и все в целом нас устраивает, если акцентировать внимание на самих различиях этих прогонов.
153: То мы видим, что для нашего простого кейса по результатам качества все аналогично для всех 3 агентов, для уже задачки с более сложным сценарием мы видим
154: Что простой агент посыпался по качеству, к сожалению, вот если мы такие сценарии для себя считаем целевыми, тут он нам уже будет не подходить. При этом критик на этом этапе нам скорее, ну, не обязателен, это избыточно.
155: И нас устроит обычная мультиагентная система, но на самых сложных, более Хитрых сценариях мы можем видеть всю силу и полезность нашего критика, только он смог финально решить задачку.
156: Чтобы учесть все наши критерии, если подводить наши результаты, то мы можем сделать следующие выводы для каждой задачи стоит подбирать
157: Инструмент, который будет для вас наиболее актуален во время семинара мы более детально рассмотрели такие подходы как-то react, агент, мультиагентная система иерархическая.
158: Иммунная система, иерархическая с критиком. Если вы понимаете, что ваша задача максимально сложная и хочется отличное качество, то
159: Критиком стоит не пренебрегать. Если для нас качество не так критично, но при этом задачи более сложные, нам важно их качественно решать, то тут можно смотреть в сторону обычных мультиагентных систем, но при
160: Этом. Если наши задачи максимально простые, то можно остановиться на react агенте он классно и, что важнее всего, быстрее всего и дешевле всего это сделает и на
161: Это мы с вами завершаем наш сегодняшний день. Всем большое спасибо. Всем пока.