0: Добро пожаловать. В 4 день нашего интенсива. Меня зовут Сергей Купцов. Я работаю в алисе и в алисе. Мы делаем агентов, агентов, мы делаем полностью на нашей инфраструктуре.

1: И я отвечаю за то, чтобы командам было удобно собирать классных, полезных и качественных агентов, и как раз сегодня и поговорим о качестве в широком смысле в этой части интенсива стоит

2: Отметить, что рассказ будет более применим, если у вас уже есть готовый запущенный агент, который вы собирали вместе с моими коллегами на предыдущих частях. Он работает. У вас появляется важная задача систематической оценки качества.

3: Которой вы доверяете. И мы вводим такое понятие, как eval, которое выделяется на самом деле в отдельную дисциплину. И про это и пойдёт речь в данной части интенсива. Перед этим давайте сначала введём. Поня?

4: Евала эвалуэйшн и расскажем, что это такое. В общем, если попробовать как-то формальное определение ввести, то эвалуэйшн евал это систематическая проверка вашей системы. Мы подаём на вход задачу получа

5: Результат работы системы и применяем логику оценки, чтобы измерить успешность этой работы. В этом курсе, мы в основном сфокусируемся на автоматизированных евала, которые можно запускать в процессе разработки. Не привлёк.

6: К этому систематически людей 3 ключевых свойства он систематический повторяемый процесс, а не ручная разовая проверка, он автоматизирован, он работает в ci ни у кого какого-то разработчика на локальном

7: Буки, и он выдаёт некоторое число набор чисел, что говорит о том, что этот прогресс измерим регрессии, детектируемые и так далее. Давайте рассмотрим некоторую эволюцию усложнения систем евала вместе.

8: С усложнением самих систем берём простой запрос ллм. У нас есть 1 промт, 1 ответ и какая-то простая метрика. Они на самом деле не такие простые, но тем не менее, давайте на примере такой эволюции их

9: Смотрим, у нас есть single. 'turn дальше мы усложняем я, у нас есть мультитерм ллм, у нас уже появляется многошаговость, в этом случае у нас уже добавляется диалог с каким-то состоянием, да, состоя.

10: В течение диалога какое-то имеет значение, что мы измеряем. Мы на самом деле, помимо того, что мы измеряем 1 ответ, ещё следование контексту, ещё насколько мы следуем инструкциям и так далее. И мы уже

11: Применяем какие-то диалоговые метрики. Здесь мы уже, конечно должны вести человеческие оценки и рассмотрим следующую эволюцию, на которой мы сейчас сфокусированы. Это агентские системы, которые на самом деле устро

12: Как некоторый такой цикл, ризонинг понимания, что нужно делать действия, понимание, что мы сделали. Вызов каких-то Тулов, изменение состояния системы переменных системы. И у нас появля,

13: Целая траектория, которую нужно измерить. И как мы видим, что агентские системы это некоторый другой уровень, и мы уже типичный ивал, уже верхний уровень выглядит как набор таких код Чеков.

14: Джеджей, на которых мы сфокусируемся впоследствии в лекции и вокруг которой будет практика и людей человеческой оценки. Давайте разберём сложность евала таким ещё раз.

15: Сами себе проговорим, что такое агент и почему мы выделяем в целую дисциплину его анализ его качества, просто повторим с предыдущих частей интенсива ая агент это система на базе больших языковых моделей.

16: Которая автономно планирует и выполняет задачи с помощью внешних инструментов. В отличие от м приложений с личным ответом агенты работают. Вот в цикле в таком придумал, сделал, написал ответ, ещё раз подумал, поэтому при тест

17: Тестирование. Очень важно анализировать не только итоговый ответ, но и сам процесс принятия решений. Какие инструменты агент выбрал, какие параметры передал и как обрабатывал результаты. В общем, ключевой вывод. Давайте здесь договоримся на этом слайде, что мы

18: Должны оценивать вообще всю цепочку, а не только финальный текст. Финальный ответ, финальное решение. Зачем вообще нам? Давайте зададимся таким вопросом наивным. Зачем вообще это делать? Почему это важно на самом деле в реальных продакшн системах? 1.

19: Давайте такие рассмотрим. Значит, надёжность и безопасность. Агенты должны корректно работать в непредсказуемых условиях, без хорошей оценки легко попасть в цикл, когда баги замечаются очень поздно. А на самом деле это

20: Агенты, которым разрешаются выполнять какие-то действия во внешнем мире. И мы должны уметь ловить их до того, как они попали в руки, в использование реальных пользователей. 2, давайте поговорим про понимание поведения 1 финального ответа. Не

21: Достаточно. В общем, важно понимать, почему агент принял то или иное решение. Это позволяет находить ошибки внутри, в логике стратегии и как-то ввести его. В общем, понимать, как его лучше вести к ожидаемому полезному конеч.

22: Действию, прогресс и деградация на самом деле такой инструмент, когда вы постоянно такой аспект, вы постоянно развиваете агента, пишите новую версию промта, меняете модель или модель summer меняется, если вы уходите

23: Внешний айпиай, обновляются инструменты и вам нужна система, которая обеспечивает вам регресс. То есть вы новую систему запускаете с большей долей вероятности того, что она не станет хуже, чем текущая версия. Эффективность опера.

24: Это примерно туда же хорошо поставленный вал превращает развитие агента управляемый процесс. И такой важный момент, что у нас появляется некоторая в результате евала некоторая, как я выше говорил, численная оценка качества.

25: И она не в единственном числе. И у нас появляется некоторая объективная коммуникация, некоторый язык, на котором мы можем говорить, что этот агент стал лучше или хуже по таким-то параметрам, что он может стать хуже, но дешевле мы можем играть уже этими параметрами.

26: Звучит как понятные довольно пункты. Давайте расскажем, явно проговорим, почему это так сложно в плане оценки именно агентских систем. 1 это то, что ошибки.

27: У нас каскадно накапливаются, ошибка на каком-то шаге может повлиять на все следующие, если говорим про single 'turn то системах, то там ошибка локализована в 1 в 1 ответе в агентской она распространяется.

28: 2 сложность. На самом деле агент вполне может прийти к успешному результату разными путями. Например, был такой классический пример, что Таубен, про который уже мои коллеги говорили, был run модели опус 4 5, и он

29: На самом деле нашёл лазейку в политике, выполнил задание, но оценку он не прошёл. То есть сама система оценки была невалидная, задача была выполнена, потому что он нашёл такой хитрый путь, и ему это было на самом деле.

30: В том мире, который был описан, ему это было разрешено, но система оценки евала в этом случае дала сбой стохастичность. Мы про неё на самом деле много будем говорить и оцен.

31: На самом деле состоит из множества узлов со стохастическими свойствами, что на самом деле мы не можем просто написать цикл, который проверяет ожидаемый результат. Мы должны учитывать это, эту сложность.

32: Эту особенность построения системы ювала, скрытые ошибки. На самом деле агент может ошибиться в параметре, вообще не вызвать Тулу, но при этом сказать, что он справился, поэтому

33: Здесь есть такая сложность, что мы должны смотреть внутрь, в детали и побочные эффекты. Это немножко связано с предыдущим пунктом. Действительно ли агент выполнил то, что он планировал, значит,

34: А это тест всей цепочки. Давайте ещё раз проговорим, подытожим эту секцию. Значит, мы должны анализировать не просто ответы, а весь трейс. Какие шаги предпринимались, какие были действия и как принимались решения техничес?

35: Эффекты, логические эффекты и, в общем, важен тест всей цепочки ризонту экшн, а не просто финального текста. Это был вводная часть, в которой мы рассказали, почему это сложно, а дальше мы

36: В течение лекции по шагам рассмотрим, каким именно образом можно построить систему оценки, и прежде чем идти дальше, давайте зафиксируем словарь терминов. На самом деле в индустрии используется как английская терминология.

37: Так, я буду говорить какие-то русские термины, которые приняты у нас в компании, и попробую рассказать и попробую показать на примере терминов, как мы внутри называем. Не уверен, что это индустриальный какой-то

38: Стандарт, но, тем не менее, я просто буду говорить, какие взаимоисключающие слова взаимозначимости. Я буду термины говорить. Значит, какие мы термины будем использовать. Погнали, эволюшн сьют, мы называем

39: Корзинка это вот как раз коллекция задачек, которые мы хотим задать во время тестирования агента. Задача это 1 тестовый пример с определёнными входами, критериями успеха. Таск, задачи 1 прогон.

40: Trial это вот 1 попытка полностью прогнать вот эту задачу и естественно что мы должны прогонять несколько раз. Мы об этом будем говорить. Траектория уже упоминалась здесь такой же англоязычном и в русском это полная запись прогона мы записываем

41: Те. Все части, все входы и выходы каждого этапа выполнения агента для того, чтобы его оценить ауткам или финальное состояние среды по окончанию прогода это не текст ответа, это реальный эффект, который был вызван

42: Оценщик, судья грейдер это как раз логика, которая оценивает непосредственно спектр работы агента и eval харнесс это инфраструктура запуска, то есть вот это вот инже.

43: Нервная часть, которая запускает весь процесс и в конце его оценивает. Давайте посмотрим теперь, как это все складывается в единый пайплайн. Пайплайн состоит из 4 компонентов. Каждый

44: Компонент необходим на самом деле. И важно такое понимание, что слабость в 1 из них на самом деле обесценивает остальные. Давайте разберём структуру этого пайплайна. Это эта же структура является структурой нашей лекции и

45: Мы же её же повторим на практике пайплайн состоит, он логический. Это не технический пайплайн из 4 компонентов. 1 начинаем с корзины задач. Это репрезентативный набор задач. 2, инфраструктура его

46: Харнесс состоит из раннера, который запускает агента в изолированной какой-то среде и все логирует все этапы. Критерии это правила, по которым мы формулируем, что такое

47: Агента и грейдинг это как раз применение система, которая применяет и анализирует и выдаёт ответ. Какие же критерии, какие значения эти критерии приобрели. Здесь важно сказать, что у меня здесь нарисовано, это как последовательные шаги.

48: Но на самом деле это цикл, результаты грейдинга влияют на все предыдущие стадии. Обнаруженные ошибки это новые задачи в корзину, какие-то нестабильные оценки, которые мы в конце видим в результате анализа грейдинга.

49: Идут в пересмотр критериев и инфраструктурные артефакты. На самом деле могут поруна всю нашу систему оценки. Вот как я уже сказал, каждая часть важна и должна быть по отдельности эффективна для того, чтобы мы доверяли всему.

50: Дальше мы последовательно разберём каждый компонент и начнём с корзины задач самого на самом деле ценного артефакта, потому что он стоит в самом начале цепочки. Корзина эволюшн сьют, таск, сьют.

51: Это репрезентативный набор задачек, на которых системно мы измеряем работу агента. Хорошо собранная корзина самый ценный артефакт о процессе, потому что он представляет собой

52: Ровно то, что мы собираемся оценивать, тестировать, измерять. Если он не резати. Если он недостаточно сложный, то мы измеряем совершенно не то, что с чем взаимодействуют пользователи. Давайте начнём с такого как бы

53: Практического примера. Мне кажется, что лучше всего посмотрим, с чего начать. На данном слайде примерно промышленный стандарт. По крайней мере, как мы внутри себя используем. У нас есть версионирование корзинок, важно начинать

54: Очень рано для того, чтобы настраивать весь пайплайн, мы берём 5, 10 задач из ручного анализа, буквально собираем руками то, что агент должен делать. Вот мы придумали то, что он должен делать. Значит, у нас есть какие-то примеры, задачек для него

55: Дальше мы запускаем агента, видим ошибки. Очень важно запускать и смотреть, что на самом деле как выглядит траектория, что на выходе и добавляем какие-то корнеры, потому что мы видим, что он, ну просто вот мысль движется, мы

56: Добавляем, понимаем с чем он может не справиться. Добавляем дальше 2 версия это уже мы её начинаем масштабировать мы добавляем различные категории, баланс каких-то измерений, баланс классов менее

57: Задачи, чтобы набрать какую-то большую полноту, разнообразие, версия 3. Это мы фиксируем какой-то результативный сет из этого, как регрессе сьют, запускаем там на каждый этап, либо

58: Там производство либо выкатки на реальных пользователей и, в общем, так до бесконечности, потому что когда система работает в реальном мире, мы 1, что делаем, наблюдаем, мы наблюдаем, что там есть баги, мы их добавляем для того, чтобы

59: В регрессии наблюдать, что мы те же самые ошибки не делаем, у нас появляется различная обратная польская связь, помимо багов, и на самом деле агент сам себе эволюционирует, у него добавляются новые свойства. Означает, что корзинка расширяется. В общем,

60: Давайте ещё раз проговорим, что хороший собранный датасет задачи это на самом деле не финальная точка, это постоянный процесс, и он очень важен, потому что все остальные компоненты ивала, критерии грейдеры Ван зависят от него.

61: Откуда можно брать задачи для корзинки? 1, как я уже говорил, это ручной анализ того, что мы придумали буквально с про постановки. 2, наверное,

62: Самое лучшее представление реального распределения это когда уже агент запущен, это production, логи, бак, трекер, спорт. Это все, что мы собираем от обратной связи. Да, система без обратной связи абсолютно бесполезна. Это публичный бичмарк.

63: Мы на самом деле в конце лекции на них посмотрим более детально. Это некоторые публичные корзинки задач типичных и ллм. Генерация это, в общем, для масштабирования некоторая матрица из функций.

64: Сценарий и person, которую мы автоматически генерируем. Большое количество задач. Вот давайте на примере рассмотрим сбор задач из лм, масштабирование вот в этом примере.

65: У меня будет несколько в лекции таких вещей, в котором мы просто показываем, как бы это можно было сделать. Вот здесь сейчас, Ханзон. В этом примере мы предположили, что задачи неплохо было бы генерировать по матрице из 3 осей. У нас есть фичи.

66: Что должен уметь агент? Давайте здесь. И далее. Я буду использовать тот же самый пример, который использовали мои коллеги. У нас есть некоторый эрлайн агент, который умеет для пользователя. Какие

67: Делать манипуляции с билетами, поиск и так далее мы говорим, что у нас есть фичи это 1 измерение поиск, изменение, отмена и запрос информации у нас есть сценарии или ситуации какие-то hk? Нет, нет ответов.

68: Неоднозначные запросы, ошибки в системе. И у нас есть персоны. Это вот типы пользователей, с которыми агент столкнётся в реальной жизни. Предположим, у нас есть новичок, у нас есть раздражённые пользователи и у нас есть нечёткий пользовател

69: Есть пример такого наивного промта сгенерировать запрос пользователя к авиаагента, функция изменения бронирования, сценарий там некорректные данные и вот персона.

70: Использует короткие фразы. Это такой пример промта, с помощью которого мы генерим большое количество задач, потому что мы знаем, что примерно такие задачи мы хотим, чтобы агент решал. Хочется отметить такой факт.

71: Что на каждую сгенерированную такую задачу нужно посмотреть вручную тем или иным способом. Однозначна ли задача вообще, решаема она или нет, потому что ллм может на самом деле тоже сгенерить задачу, которую мы бы даже не хотели, чтобы агент реша

72: Поэтому относится ли она к этому вообще домену и к этому агенту? Кроме того, есть несколько хороших Приёмов, в котором просто подсвечу 1 приём тегируйте, ваши задачи различны.

73: Набором тегов, например, сложность помечаете категория и так далее. Почему это важно? Это на самом деле может быть полезно в будущем, когда вы разделяете эти корзинки и вы можете балансом вот эти категории

74: На самом деле, управлять, допустим, для регресса. Вы хотите, чтобы у вас были распределение было по этим категориям? Тегам больше похоже на продакшн. Дальше вы хотите, чтобы агент развивался и у вас, например, есть отдельная корзинка с очень сложными запросами?

75: Да, если у вас корзинка очень простая, то задача у агента очень простая, и вал, по сути, не нужен. Мы ставим всем, но стоит отметить, что задача это не только текст запроса, это ещё и давайте разберём полную структуру. Это

76: Ещё и состояние, состояние системы, запрос пользователя, что он хочет начальное состояние среды. Это может быть что угодно. Это может быть база, это может быть политики, кото

77: Которое нужно использовать при работе агента и ожидаемое конечное состояние как система, ну, под системой здесь появляется, допустим, вот у вас есть билет, и он там забронирован или отменён. Вот, и как это состояние должно быть?

78: Выглядеть после корректного выполнения, то есть это все части корзины. То есть мы немножко помогаем части грейдинга на этапе составления корзины. Если мы это способны сделать, нужно максимально стараться это делать. И давайте посмотрим на

79: Конкретном примере это некоторый пересобранный пример задачи из реального бенчмарка тау, что мы видим, у нас есть запрос пользователя, у нас есть начальное состояние.

80: Среды, какие-то полёты какие-то уже из них рейсы зарезервированы. У нас есть политики, по которым нужно взаимодействовать. И у нас есть собственно ожидаемое состояние среды пользователь

81: Говорит, перебронирую. Рейс абц 123 на завтра, только если он дешевле и из состояния среды мы на самом деле можем уже задать ожидаемое, что появился такой букинг абц 123 полёт и

82: Что его статус изменён. Давайте, наверное, подытожу тем, что приведу такой слайд, на котором мы говорим о том, какие свойства хорошей корзины для задачи в целом, как себя проверять значит,

83: 1, это недвусмысленность. 2 эксперта должны сойтись во мнении, проходят тест или нет, если расходятся, если невозможно несколько людей посадить, чтобы они сказали, что

84: Делили одинаково, что агент выполнил свою задачу или нет, то, по сути, задача требует переработки, и с ней и агент не справится. Вернее, он справится, но мы не сможем однозначно его оценить. Состояние среды это объективная проверка ауткам, а не то

85: Только текста, баланс классов различных классов. Если у вас корзинка слишком Лёгкая, то её очень просто пройти, но при этом баланс должен быть репрезентативен тому распределению, который у вас есть на продакшене, есть.

86: Есть некоторая референс солюшн. Для каждой задачи есть решение, доказывающее её решаемость. Его лидирующие грейдеры, так называемая двунаправленность. У вас в корзинке должны быть задачи, когда

87: Агент должен действовать, и когда он на самом деле не должен. То есть вы обязательно в корзине агента, поскольку это все бейст, а, м, так обучаются, что они, ну, не, м, скорее, система поверх лм, что они способствуют

88: Пользователю максимально помогающие, то вы должны проверять, что агент отказывается действовать, если это не соответствует его задаче. Воспроизводимость. Такое сложное, важное свойство, что на самом деле

89: Задачу можно выполнить после некоторого резета сиай без внешнего состояния, без какой-то накопленной истории. Вот есть какой-то сброс, мы его выполнили, и мы можем выполнить много много раз. И получив 1 и тот g1 и то же, как бы

90: Состояние работы и теги, про которые я говорил, они по сложности, по типу навыку и так далее. Это, в общем, позволяет делать некоторый регрессионный анализ по категориям и переходим ко 2 компоненту.

91: Этого пайплайна к инфраструктуре прокачки или eval инфраструктур евал это не только задачи и критерии, но и инженерная система, обеспечивающая воспроизводимость, изоляцию и

92: Этих прогонов хорошая футура. Прокачки это, в общем, довольно сложный инженерный процесс, но давайте начнём, наверное, с самого такого главного принципа. Агент в евале должен быть тем же самым агентом, что и в продакшене.

93: Тот же код, тот же пром, те же Тулы. Если мы для ивала создаём некоторую упрощённую версию агента, то, очевидно, мы тестируем не то, чем будут пользоваться реальные пользователи различия только в окружении.

94: То есть eval харнесс должен предоставлять, и это 1 из инженерных сложностей этой системы, что она должна предоставлять тестовую среду вместо продакшн среды, тестовую базу данных вместо боевой, потому что если мы говорим про

95: Классных полезных агентов, то они вообще изменяют внешний мир, но мы в прогонах себе не можем это позволить. Поэтому здесь очень тонкий баланс между тем, что агент на самом деле такой же, но среда у него Мокова. Давайте разберём из

96: Каких принципиально компонентов стоит? Состоит инфраструктура? Она состоит из раннера. Это запуск агента на корзине задач к нему. Какие требования он должен уметь запускаться параллельно он

97: Должен уметь доводить результат через таймауты, ретрай и так далее. То есть мы хотим за достаточно короткое время прокачать очень много запросов. Такое часто бывает, что количество нагрузка на систему его

98: Больше, чем в реальной жизни, потому что мы хотим результат получить быстрее. То есть, если наивную инфраструктуру построить, то можно несколько суток ждать, потому что хорошие корзинки, это которым можно доверять, это 300, 500 задач и можно

99: Представить, что если агент работает несколько минут, то, естественно, мы хотим, чтобы эти задачи прокачивались параллельно. Энвайрмент это та самая изолированная среда для каждого прогона, чистый стейт при каждом запуске.

100: Трейсер это такой важный компонент, я его выделяю, потому что очень важно фиксировать полную траекторию на каждом шаге. Ризонинг, запрос Тулу, ответ от Тулы рассуждения, запрос пользователя, ответ финальный.

101: И так далее. Железный пользователь Арен юзер. Мы о нём поговорим подробнее чуть позже. Это замена реальному пользователю, потому что агентские системы мультитерм очень часто они не могут быть в принципе.

102: Задачи, которые решать могут, в принципе, решены за 1 шаг. Сторедж это такая штука, которая хранит все прогоны, траектории, метрики. На самом деле оно должно быть быстрое, дешёвое, и поверх него можно сделать компоратор.

103: Компоратор это на самом деле такой компонент уже очень серьёзных зрелых инфраструктур, в котором мы можем сравнить различные прогоны, потому что у тебя может быть, несмотря на то, что у нас есть там, грубо говоря, 1 числовое значе,

104: По которой 1 агент хуже другого или лучше на самом деле нужно уметь смотреть, а в чем же именно и в чем же детали. И для этого нам на помощь могут прийти такие системы, которые умеют строить дифф между разными прогонами буквально по задачам и

105: Давайте остановимся на компоненте более внимательно с энвайрментом. Как я уже говорил, это важная инженерная задача и 1 из ключевых решений, которое нужно принять, это как организовать вот эту среду. Значит есть

106: Здесь такая табличка, где в левой части у нас полный мог, это быстро, это дёшево, это детерминировано, что очень важно для прогонов, когда следует применять, когда у нас ранняя разработка, когда у нас

107: Тесты каких-то отдельных компонентов не целиком, но при этом у нас, естественно, есть риски. Так называемый мог дрифт, что мог на самом деле расходится с реальным. Айпиай, у него ненастоящие данные, у него буквально

108: У тебя случилось, был, было начало месяца, сейчас другой месяц, и он, допустим, не умеет эту, эту вещь считать. Или вот очень сложно иногда бывает поддержать переход между годами, какой сейчас год и посчитать корректно.

109: Там расстояние во времени с переходом через новый год. Вот, значит, в правой части у нас полный продакшн. Все, все реальное, все вызовы реальные. Это на самом деле медленно.

110: Это очень дорого. И иногда это в принципе невозможно. Если мы говорим о том, что мы у нас агент сайдэффектом, то, в принципе, чаще всего невозможно. В жизни рекомендуется использовать некоторый гибрид, что мы на самом

111: Деле, например, используем какой-то снэпшот реальной базы данных и обращаемся к ней, меняем её. При этом мы можем использовать какие-то реальные ручки, которые работают на ретрив, на поиск информации.

112: Но рекомендуется все-таки делать это не на тех же инстансах, на которых живут пользователи, а это некоторая копия этого инстанса, но код там такой же, и смотрит он на ту же самую базу. В общем, ключевой принцип в целом, что данные должны быть реалистичны.

113: Нет какого-то единого подхода. Каким образом это делать? Это очень индивидуальная штука. От неё, только от домена агента, но ещё от конкретной конкретной области конкретной компании, конкретной конкретных данных.

114: С которыми он работает. Ещё стоит отметить, что политики это тоже на самом деле часть среды под полисы с политикой называют. Часто её ещё называют бизнес логикой, потому что на самом деле ещё очень

115: Очень важно то, каким образом 1 и ту же задачу агент выстраивает с пользователем. Ну, например, агент должен запросить билеты, и он должен запросить в политике написано подтверждение перед этим пользователем, а не

116: За него, да, а в политике, например, агента, который за тебя, допустим, не знаю, сортирует почту. Он, наверное, в политике не должен содержать такой шаг. Идём дальше, дальше. Отдельные важные компоненты инфраструктуры, как я уже говорил, это

117: Iron юзер железный юзер железный пользователь почему он вообще нужен? Потому что многие агентные задачи диалоговые агент задаёт вопрос как в случае с подтверждением билетов, если с другой 100

118: Стороны нет компонента, который скажет и подтвердит это действие, то мы не сможем прокачать весь диалог и мы не сможем оценить его успешность. Вот поэтому для как раз симуляции этого пользователя применяет

119: Подход железным пользователям это ллм бейст система, и у него есть определённые свойства. Это отдельный компонент, у которого есть фиксированная цель. Юзеру написано, что он должен

120: Хотеть и что? В рамках какого сценария он должен действовать. 2, он должен быть очень естественным. То есть если мы симулируем пользователя, давайте этот железный пользователь будет себя вести как реальный человек, он не должен выдавать данные.

121: Хотя он видит настройку свою, и он должен вести себя согласно некоторому сценарию и не галлюцинировать аарон юзер это классная штука, но у него тоже есть свои определённые проблемы.

122: Problems на английском для нас на русском это задачи значит и какие у него есть задачи, которые нужно обязательно учесть. Симулятор сам по себе не детерминирован. Аарон юзер это тоже ллм, а значит, его ответы тоже варьируются.

123: Между прогонами один и тот же сценарий может приводить к разным диалогам. Это на самом деле такой и минус, и плюс симулятор может галлюционировать. Это система стахастический сценарии данных, которые

124: Нет, и на самом деле ломать вам оценку агента симулятор может помогать агенту. Реальный пользователь может быть нечётким вернуться через много времени, быть раздражённым алм симуляторы.

125: Как я уже выше говорил, то, как их стараются обучать, он слишком бывает, что называется, кооперативный, он помогает агенту, и он ему, в общем, старается помочь. Это вот буквально, очень забавно наблюдать в реальных прокачках и

126: Не стоит недооценивать в связи в связи с этим же фактором риск бесконечного цикла если в агенте есть какая-то ошибка и агент задаёт один и тот же вопрос пользователю железный пользователь его на него.

127: Реагирует однообразным. И мы снова приводим к ошибке, то очень часто наивные. Система железным пользователем приводит к бесконечному циклу. И здесь, в общем, есть ряд простых Шагов, которые могут этот риск

128: Убрать. Просто ставьте ограничения по количеству Шагов. Мы понимаем, что агент, если мы говорим про агента ассистента, что он не должен там больше 30 раз обратиться к пользователю, это уже совсем очень надоедливый агент. И давайте рассмотрим.

129: Проблемы. И рассмотрим, как тау бенч решает в своём бенчмарке проблему качества симулятора пользователя. Там применяется несколько стратегий. В общем, впоследствии на слайдах можете посмотреть, но, например, 1 из интересных стратегия верифай, что

130: После генерации есть ещё 1 лмка, которая проверяет, насколько валидный был ответ железного пользователя. Если он не валидный, то его там пробует ещё раз до 3 раз его сгенерировать, ну и так далее. Другие, другие, разные.

131: Полезные приёмы, которые вы можете применить в основном сейчас на рынке невозможно взять готовый ива харнесс инфраструктуру, которую вы можете поместить у себя внутри компании. И если вы собираете

132: Сами то давайте просто посмотрим на некоторый чек лист минимальных требований к вашему хармсу. Просто для самопроверки. Значит, 1 запускается на общей виртуалке, а не ноутбуке разработчика.

133: 2 стабильная работа, что у нас есть retry при таймаутах, у нас есть graceful shutdown, грейсфул ли, ошибок и так далее автоматическая выгрузка результатов в хранилище после каждого прогона звучит очень понятно.

134: Очень часто этот шаг забывается или ещё очень часто эти результаты прогонов ещё пишутся в 1 и ту же табличку и перетираются. Вот это реальные реальные случаи. Дальше параллельный запуск задач, иначе прокачка будет длиться.

135: Очень, очень долго возможность сравнить результаты между версиями хотя бы там в csv и изоляция чистое состояние среды, которое должно быть установлено перед стартом прокачки и

136: Никак. Артефакты предыдущих не должны влиять на прогон, но также есть готовые инструменты на самом деле, которые помогают есть набор библиотек, есть набор платформ. Подробно не буду останавливаться, но просто для

137: Того, что как это делается в индустрии, покажу несколько платформ, покажу интерфейс смиса. Здесь мы видим 1 строчка. Это 1. 1 задача. Она была прокачена сверху, выделена красной

138: Рамки это как раз взгляд на критерии и оценка. Очень полезно посмотреть по каждой задаче, почему какой-то критерий не был выполнен. Классная штука, про которую я говорил. Компонент у ребят есть это как раз

139: Сравнение 2 прогонов в данном случае видно, каким образом 1 и та же задача в 2 версиях в 2 прогонах отличается и можно посмотреть на дифф по метрике также у паная есть тоже система, у на walls задача там заводится код бейст.

140: Примерно выглядит точно так же. У нас есть корзинка запросов. У нас есть, значит, наглядное представление, какой был запрос, какой был ответ. И у нас есть значение метрики. Мы переходим к критериям, если перейти к

141: Самой оценки не определив критерии, мы можем получить какие-то числа, которые не объясняют на самом деле реальное поведение. И главный вопрос этого блока по каким правилам определить, что агент справился с задачей, начнём

142: Давайте с такого, что делает критерий. Критерий. Вот давайте для примера того, что понятно. Допустим, у нас есть критерий, справился ли агент с задачей. И вот что такой критерий, его именно формальная постановка делает его хорошим.

143: Значит, хороший критерий, что он соответствует цели агента, а не какая-то прокси метрика он лайн. 2, что он должен быть прост в проверке и его можно было бы автоматизировать 3.

144: Что on human readable, что когда ты говоришь вот как я рассказал, что в целом другому человеку, даже не индустрии, понятно без объяснений, что это за критерий дискриминативная, что сразу было бы понятно в идеале какую часть системы.

145: Нужно чинить. То есть, если у нас есть, к примеру, возьмём, значит, плохой критерий, классный агент или не классный, мы, допустим, оцениваем по шкале от 1 до 10, то если мы поставим агенту 3, то непонятно, какую из деталей агента нужно

146: Чинить. Нужно всего чинить этот критерий плохой, и очень часто его не используют именно в автоматизированных проверках. Да, его можно использовать, допустим, перед релизом на какой-то небольшой корзинке задач, но для автоматиз

147: Системы, он не подходит. И последний критерий это то, что нужно быть стабильный, он не зависит от интерпретации и не дрейфует между прогонами. В общем, самое главное правило провероч.

148: Такое, если возьмём 2 эксперта, покажем им критерий, покажем ответ агента если они не могут договориться и сказать одинаковое мнение, что агент прошёл этот критерий успешно, неуспешно, то критерий требует

149: Вот он просто не годится в целом критерии делятся примерно на 2 группы out бейст, который проверяет свойства конечного результата агент вернул ответ в ожидаемом формате был вызван.

150: Правильный тул. Состояние среды изменилось, и поведенческие, которые оценивают именно путь к результату. Траектория бейст логична ли цепочка действий, сохранялась ли цель задачи на протяжении траектории были

151: Лишние шаги неэффективные. Обоснованны ли ризонинг, не потеряли ли мы где-то контекст, да просто инженерно потеряли контекст или начали решать какую-то другую задачу или задачу без контекста первые можно реализовать в большей сте.

152: Степени, как какие-то конкретные ассерты, юниттесты, чеки, вторые уже проверки критериев уже нужно реализовать как джадж сравнительным каким-то способом ещё

153: Поговорю, что важно. Важны, во первых, обе группы оценок, и мы должны оценивать пропуски, пропуски, ошибки, нарушения политики. В общем, все вместе.

154: Давайте приведём пример из реальной жизни. Вот я приведу некоторый список универсальных критериев, который мог быть применим к ассистентским агентам. Агенты, которые выполняют какие-то действия для пользователя и

155: Просто рассмотрим их на примере. 1 полезность. Решил ли агент задачу пользователя? Тип бейст в качестве грейдера? Может быть, на самом деле состояние проверка состояния системы. 2, корректность. Были ли ошибки exception.

156: Невалидные вызовы тоже убей. И тоже можно написать Стрик чек грейдером очень часто на самом деле люди забывают, что забывают корректность добавить.

157: Вот в знаменатель тех или в числитель тех ошибок, которые были совершены агентом привале. Мы оцениваем всю систему, давайте ошибки тоже оценивать следующий обоснованность или подтвержденность, что на самом деле здесь мы проверяем, что те

158: Например, те параметры, которые агент подставил в Тулу, например, соответствовали диалогу. Это уже траектория бейст. Здесь уже каким-то простым треком не обойтись. Мы уже говорим, что грейдером здесь лм. Судья следующая эффективность на

159: Сколько много могли ли мы сделать меньше Шагов? Могли ли мы потратить меньше токенов и так далее? Это тоже траекторный в том смысле, что мы проверяем вот стиль, стиль работы, а не финальный ответ. Вот здесь можем

160: Использовать count bass, здесь можем использовать Джаджа стабильность на самом деле мы говорим, что агент статистическая система, поэтому мы хотим замерять, насколько агент стабильно решает 1 и ту же задачу.

161: На следующем слайде мы чуть подробнее поговорим про эти метрики. И последний критерий. Это безопасность или то, что мы называем этика, о том, что агент общался согласно политике.

162: Что он не не был спровоцирован, разговаривать на неэтичные темы, что он не выдаёт какие-то данные, которые он должен пользователю не должен говорить и так далее. Это тоже

163: Уже аутпут бест. И здесь в качестве грейдера может быть какой-то классификатор, который по ответу оценивает, насколько он соответствует этому критерию и, как я уже сказал выше, давайте рассмотрим поподроб.

164: Не критерий стабильности. Поведение агента детерминировано и 1, и тот же пром, собственно, приводит к разным результатам. Вот поэтому выделяются такие 2 метрики. Пас эткей это

165: Вероятность того, что хотя бы 1 из прогонов успешен, вот он выделен синеньким. Видно, что он с количеством попыток, естественно, растёт, потому что нам нужен хотя бы 1. Несмотря на то, что кажется, довольно странный критерий, он на самом деле

166: Полезен, например, для вещей, в которых мы можем повторить несколько попыток, пока не достигнем конечного результата. Например, генерация кода. Да, эта метрика нам говорит, сколько нам нужно сделать попыток. В среднем и следующая метрика больше применима к нашему эрлайн. Примеру

167: Это вероятность того, что все-ка прогоны были успешны. То есть если у нас вот здесь мы берём, смотрим на оранжевенькие столбики и что у нас есть вероятность 75% достижения 1 результата, мы их все перемножаем и видим, как

168: Метрика успешности с количеством прогонов очень сильно падает. И эта метрика, как я говорил, критически важна для агентов, которых, которые ассистентские. И впоследствии мы посмотрим на реальные промышленные значения агентов бенч. Чуть

169: Позже и мы переходим к заключительной части пайплайна, к самому грейдингу. Грейдинг оценка это как раз процесс применения вот наших критериев к конкретному прогону агента и

170: Давайте разберём на следующем слайде 3 фундаментальных типа грейдеров, которые на самом деле используются в комбинации. Разберём плюсы и минусы каждого. Грейдер 1 это код бейст, это какие-то регэкспы, какие-то матчи, ассерты.

171: Проверили состояние плюсы быстрые, дешёвые, очень объективные и воспроизводимые из минусов, что они, конечно, очень хрупкие к различным вариациям и не могут уловить там траекторные или вот тому смысловые

172: И так далее. Следующий это human грейдер это человек или в некоторых областях, это эксперт, который оценивает результат агента и на самом деле собирает такую очень важную штуку, как

173: Оценки нас. Нам просто больше не с чем сравниваться для того, чтобы построить идеального ллм судью. Ну, если мы говорим про критерии, которые вот нельзя проверить предыдущим коде гребером, значит,

174: Минусов это очень медленно, это очень дорого и это не масштабируется, но он собирает полезные свойства для следующего типа грейдера джадж, который как раз

175: Оценивает результат работы агента, который предыдущие по разным причинам не могут или дорого. Значит он масштабируемый, он очень гибкий, он улавливает нюансы, он может обрабатывать какие-то задачи опен ендед, ну и

176: Минусов, что это на самом деле сложная система, которая тоже требует калибровки. Она сильно, сильно дороже кода и бывает такое, что она дороже даже, чем работа всех ваших пользователей с вашего

177: Зелёный период, и он, конечно, не детерминирован. Как измерять. Насколько хорошо работает грейдер. Рассмотрим. М судью вводится такая

178: Метрика, которая говорит, насколько 2 грейдера между собой сведены. Это могут быть 1 человек и другой человек для того, чтобы проверить, насколько у нас адекватные критерии, и это могут быть человек.

179: И. M. Судья, если просто посчитать процент совпадения по какому-то критерию, ну, берём каждый критерий, считаем процент совпадения, потом складываем, получаем некоторую общую метрику сведенности. Мы это внутри называем, то

180: Мы на самом деле, если мы будем считать просто долю, то мы не будем учитывать такую штуку, как просто случайное совпадение, что на самом деле мы совпали не потому, что мы согласны с критериями, а потому что мы склонны так ставить. Вот есть такая

181: Метрика, как капа Коина, которая на самом деле пытается вычесть вот это вот случайное совпадение. Формулу. Видите, в левой части слайда хорошим стандартом считается, что если это значение больше 0 6, она прыгает

182: От минус единицы до единицы, то в целом мы можем доверять этой системе подробно, как они это делают. Можно почитать, не буду об этом подробно останавливаться для того, чтобы, в общем, продвинуться.

183: Дальше. Но штука вообще интересная, и чаще всего применяют её. Также можно отметить, что на самом деле в реальных системах грейдеры комбинируются на 1 задачу. Может быть, несколько грейдеров у нас есть стоит

184: У нас есть, м, проверка, и какие здесь могут быть стратегии, чтобы прийти вот к какому-то вот 1 числу, да, которое мы говорим, что вот у нас релиз такой-то этого агента и его некоторая успешность

185: На x в целом применяется некоторый гибрид, в котором мы складываем обязательное прохождение каких-то критических грейдеров например, грейдер этичности неважно, насколько хорошо агент справляется, если мы не проходим.

186: Тичный грейдер, то мы дальше не идём. Если мы, значит, не проходим стейт чек. Ну, выше какого-то определённого порога мы дальше не идём, и метрика равна нулю. Если мы все эти чеки бинарные прошли, то мы добавляем некоторые

187: Взвешенную сумму наших вот критериев на примере, который мы рассматриваем, допустим, полезность, корректность и так далее. На этом мы рассмотрели некоторую, в общем, теоретическую часть по поводу грейдеров и переходим к нашему блоку ллм.

188: Построение лм. Судьи, поверх которого будет построена практика, и рассмотрим некоторый путь улучшения его метрики, его метрика, качества самого лм. Судьи это сведенность и рассмотрим не

189: Некоторый цикл построения его мы начинаем с ручной разметки экспертной 30 100 запросов дальше, значит, если мы между группой людей экспертов считаем

190: Определили критерии, прокачали, смотрим на ответы, показываем их независимо с пересечением задач разным экспертам и считаем между ними капу Коина и, если, значит, мы свелись, переходим на следующий шаг.

191: В котором мы пишем промт для лм. Судьи, значит лм. Судья прогоняется на небольшом количестве примеров новых, которых не было в оценке, считаем, смотрим на то, как он те же самые задачи разметил.

192: Проверяем его сведение с людьми, смотрим, где, в каких компонентах он разошёлся. И у нас вот такой цикл, пока мы не достигнем значения, там условно больше 0 6. В этот момент мы начинаем доверять судье.

193: И какое-то время доверяем этой системе, пока у нас не появятся изменения корзины. К примеру. Давайте рассмотрим какой-то наивный промт и перед этим рассмотрим из чего, собственно, про

194: Вот этого Джаджа состоит, что он видит для оценки. 1, это контекст задачи. Он, конечно, должен видеть цель, он должен понимать ограничения и саму задачу. Данные агента после про

195: То есть он, поскольку он оценивает всю работу целиком и траекторию бейст и bass, то ему, естественно, вход подаются все детали как работал агент, у него есть инструкция оценки, это как раз формализованный.

196: Наших критериев пишется такой документ, в котором определяется, что же такое хорошо по этому критерию, что плохо какие-то подсвечиваются нюансы, конкретные кейсы. За что мы какую оценку ставим, что называется, фью шот и

197: Этот документ на самом деле читают как люди, так и джаджи, и на основании них принимают решения. 1 инструкция и некоторый формат ответа для того, чтобы мы могли распарсить его ответ. Давайте рассмотрим какой-то наивный подход.

198: В виде 1 промта, где все критерии сразу без определений. Че мы говорим? Наивный подход. Оцени работу агента. У нас выделяются 3 критерия. У нас шкала гуд соу соу бэд и ответь.

199: Собственно, значение в виде джейсона, да какие здесь могут быть проблемы?

200: Во первых, ллм. Склонен, они склонны вообще помогать людям, и они склонны также и помогать лмка, и они завышают эти оценки, они стараются поставить good, а поскольку в системе, в нашем промте не определено, что такое good просто.

201: Тем он поставит гуд. Вот следующий в данном промте все критерии вместе, и у нас появляется такой халл эффект, где 1 критерий влияет на другой. Если мы 1 критерию поставили гуд, то лм склонен.

202: И следующий критерий также оценить хорошо и, естественно, некомпетентность. При повторном запуске. Ответ может быть другой, и оценки могут сильно отличаться. Рассмотрим 5 Приёмов повышения качества судьи. 1.

203: Это то, что 1 критерий это 1 про 1 запрос к. М. Да, мы убираем связанность между критериями в рамках 1 запроса. 2 это ризонинг четот. Мы просим ллм порассуждать и вывести

204: Рассуждения. Часто это приводит к лучшему эффекту. 3 это, наверное, самое важное, что нужно сделать на шаге после наивного подхода. Это мы вот тот в том документе определяем конкретные рамки, что мы понимаем

205: Когда этот критерий хороший или плохой 4 это такая штука под названием escape hatch это позволить лмке сказать что она не знает что она, что она не справилась что она не понимает что ей недостаточно данны.

206: Это очень важно, потому что иначе она просто выдумает оценку, и 5 пример это fushou, это буквально в промте указываются примеры задач и примеры оценок, так называемый golden сен.

207: Которыми, по которым эксперты сошлись во мнении, что нужно оценивать именно так. Хочу ещё отметить такой факт, что мы в основном в этой части интенсива фокусировались на определённом типе.

208: Агента это помощник по работе с билетами, но на самом деле есть разные типы агентов. Они все называются агентскими системами, и они немножко отличаются по тому, как их оценивать. И рассмотрим 4

209: Типа конверсейшен кодинг ресерч компьютер юс и посмотрим на какие-то референсные на текущий момент индустриальные бенчмарки и кто там лидирует. Начнём с нашего агента, который мы рассматривали на

210: Его конверсейшен, это мультите диалоги, уколы, управление состоянием. Значит, особенность, что качество взаимодействия это на самом деле часть того, что мы оцениваем, нужна 2 лм для симуляции пользователя. Железный пользователь у нас

211: Некоторая многомерность успеха. У нас есть чеки, у нас есть эффективность, что мы уложились там меньше чем в 10 Ходов. И что мы там в правильном тоне пообщались с пользователем, оцениваем, значит, мы

212: Состояние оцениваем мы то как агент себя вёл и так далее. Набор есть текущих стандартных бенчмарков, это та бенч или та 2 бенч это

213: Из домена элайна 50 заданий, из домена ритейла, 115. И ещё недавно добавился домен телеком. Вот он, в том числе измеряет метрику стабильности. То, насколько мы метрика падает от

214: Гоннов и посмотрим на лидерборд обратите внимание, что path Ван для домена ниже 50% большинства моделей за пределами лидерборда ниже 60.

215: Пас 4 падает для всех моделей. Парк устроен так, что там есть определённый тип агентов и там подменяется модель. Вот среди лидеров у нас на текущий момент это просто очень быстро меняется, поэтому я

216: Такую оговорку. Квен 3, Максимкин gpt 5 и на 3 месте клор 7. Санет. Идём дальше. Кодин agents это на самом деле на текущий момент в индустрии самые классные прокаченные агенты. Это уже. Они уже ворвались в наш мир.

217: И вполне себе приносит измеряемую пользу ключевое преимущество, что код можно проверить объективно, можно запустить тесты, можно запустить программу и проверить, как она работает. И тут, по сути, джадж.

218: Для Колы не нужен. Тут есть определённые специфики, что задача может затрагивать там несколько файлов репозитории, что мы можем проверять, что тесты, которые раньше проходили, не должны сломаться. Значит, эталонный

219: Это св. Бенч верифайд это 500 задач взятых из гитхаба, из питон, репозитория и eval там просто проверка Тестов, которые до этого патча не падали до этого патча падали после должны.

220: Пройти. Вот мы здесь на самом деле наблюдаем очень быстрый прогресс, там от там 4%, там успешности в 24 году до выше 80, в 25 году самый быстро улучшающийся

221: Марк, агентов. Посмотрим сейчас на зебор хьюман бейзлайн, эксперт, разработчик порядка 86%. Вот видите, на экране, значит, кто? Лидеры клод? 4 5, наверное.

222: Сейчас стоит уже говорить о 4 6 gemini 3 снова ворвался в лидеры и а клопп клод опс даже пониже в общем клод допс 4 5, харизм повыше и ещё есть ряд тоже.

223: Таких фреймворков, которые бенчмарков, которые можно так стабильно проверять, ещё стоит упомянуть терминал бенч, который вы можете почитать. Так, дальше. Ресерч агенты это такой самый субъективный тип агент.

224: Чем они занимаются? Они занимаются веб серчем синтезом информации из интернета, генерацией отчётов и построение какой-то вот структурированного ответа по задачам. В общем, они из себя представляют довольно

225: Уникальную доменную область в плане, в плане оценки, какие там можно шаги известные проверять, можно проверять утверждение, что утверждение, которое делает в выводе агент, что они

226: Имеет какой-то источник, да, что он не сам выдумал, что ключевые можно проверять ключевые факты, отдельно можно проверять качество источников и здесь на самом деле очень сильно, в большей степени вовлечены

227: Грейдеры потому что здесь, во первых, сложная доменная область бывает, и тебе нужен эксперт, который умеет оценивать, составлять те самые голден семплы, значит, из таких популярных текущего

228: Момент бенчмарков бройс комп и Гая бенчмарк, дженерал ассистент. Очень часто такие агенты называют универсальными, потому что он, по сути, должен уметь все для решения своей задачи. Значит,

229: Давайте посмотрим на на лидерборд. Эти фреймворки немножко отличаются. Если мы на Гая говорим, что human бейзлайн 92%, то есть то сколько живой человек убивает, а броском значительно сложнее там

230: В районе 10%. Посмотрите на деборд. Заметьте, что на самом деле у каждого бенчмарка свой победитель, потому что все измеряют разные аспекты и, в общем, разные системы. Или, что мы говорим, в данном случае разные.

231: Агентские системы, которые используют м, являются лидерами в своих бенчмарках, и последний тип агента это компьютер юз, agents, компьютер, юз. Agents это такие агенты, которые в качестве Тулов.

232: Используют те же самые Тулы, которые есть там у человека. Это работа с браузером, работа мышкой, работа клавиатурой. Это, в общем, принципиально другой тип задач. Здесь агент чаще всего

233: Видит картинку на вход не обязательно, но, в общем, чаще всего лм. Судья здесь тоже не часто применяется. Можно проверять состояние системы, которое агент изменил в ходе своей работы здесь из специфики. Что

234: Нам нужен очень такой инженерный классный санбокс гуин. Нам нужны, нам нужен ряд село сайтов или каких-то систем, которые в саноксе могут крутиться. Вот агенты.

235: В этом, в этом домене делают очень, очень много Шагов для того, чтобы выполнить действие. Вот. И в этом смысле здесь человек очень быстро справляется из таких классных бичмарк.

236: Выделяют веб арена. Это порядка 800 задач на се хост сайтах и os world. Это порядка там 400 задач в операционных системах, где нужно что-то поделать внутри системы. Значит, лидеры

237: На веб арене дип сик человек справляется где-то 78% на vs world у нас разрыв сокращается нас world у нас человек порядка 72%.

238: Центов убивает. И лидеры здесь, как мы видим, не те, не те модели в большинстве случаев, которые победители предыдущих, а в компьютер Юзе. Если мы говорим про сайты, то там вообще довольно специализированные модели, потому чт

239: Они должны принимать на вход картинку. Давайте пойдём дальше, вернёмся к основному пайплайн нашей лекции. И хочется отметить, что помимо качества в продакшн на самом деле важны и другие.

240: Метрики и эти метрики это летенси. Насколько долго ваш агент работает в сравнении между версиями? На самом деле, типа мы отдаём предпочтение агенту, который просто быстрее работает, если мы говорим, ну, для некоторых

241: Агентов, допустим, которые выполняют задачу. Мы должны сопоставимое время с пользователем сопоставим время с пользователем, выполнять задачу, иначе мы не проходим по этой метрике стоимость это запросы и токены.

242: Как я уже выше говорил, евал, может быть, или чаще всего на старте ещё дороже, чем сам продакшн, чем та нагрузка, которую делают пользователи, и r right это те ошибки, ошибки.

243: Как инфраструктуры, так и ошибки Тулов, которые вызывает модель. Вот, и в общем то подбор вот этого вот баланса между эффективностью

244: Сведенность оценки и стоимостью. На самом деле это тоже такая метрика, которая есть как у агента, так и у вашей ева системы, а дальше хочется перейти от теории практики.

245: Здесь написан анонс того, что мы будем делать. Мы пройдём все 4 части нашего пайплайна. На примере нашего любимого ран агента в 1 части. Мы построим небольшой пример такого агента во вто.

246: 2 части мы соберём критерии и код грейды и дальше мы подключим к этой системе железного юзера, сделаем какую-то свою прокачку в коде и

247: Попробуем улучшить нашего лмм Джаджа, пройдём итерации по улучшению, которые вторят тому, что мы рассказали в лекции, переходим к практике.