0: Всем привет, я Даня Артамонов и в яндексе я руковожу командой, которая разрабатывает платформу для и агентов и разрабатывает иа инструменты для айти команды в яндексе сего.

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

2: И поговорим о том, нужно ли строить платформу и когда её нужно строить. Начнём с 1 акта. Мы поставим 7 проблем. Эти 7 проблем вас ждут, как только вы начнёте масштабировать агента, либо по пользователям, либо ваша команда разработки.

3: Будет расти, либо у вас будет расти количество агентов. Так или иначе, хотя бы несколько из этих проблем вас ждут. И давайте начинать с 1, с чего хочется начать. Это с вашей стартовой точки. Вы собрали какого-то агента, он

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

5: 1 проблема. Вы столкнётесь с проблемой медленной работы, потому что ллм это очень долгая и дорогая операция, и агент, который очень сильно опирается на ллм, будет медленно работать. Почему это плохо?

6: Просто потому, что пользователь за долгие годы работы с гуглом и прочими продуктами привык выполнять то, что ему нужно за 200 миллисекунд, а если ему вместо 3 кликов нужно будет ожидать крутилку 20:30 секунд, может быть, даже минуту, он явно не захочет пользоваться каким

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

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

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

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

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

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

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

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

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

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

17: Ограничения это системный промт. Обязательно кто-то попробует это сделать. У него обязательно получится финальная проблема. В целом. Пройдя весь этот путь, вы собрали 1 агента, и даже если он полетит, обязательно захочется.

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

19: Придумывать, как посчитать качество. Вам заново придётся придумывать, какие паттерны использовать, заново, собирать всю систему обзервере и так далее и так далее. Мы поставили 7 проблем. Все эти проблемы решаемы. И как раз-таки в следующем

20: Акте. Мы поговорим с вами о том, как эти проблемы решать. Начнём, пожалуй, с самого важного. Это наблюдаемость. Как только мы запускаем что-то в production, мы не можем без хорошей системы наблюдаемости вообще понимать

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

22: Про зевали. Тут не всегда подойдёт подход, как с другими микросервисами. Агент отличается, например, тем, что он ходит опять же в ллм, он тратит какое-то количество денег, а в сервисах принято считать, что траты фикси

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

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

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

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

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

28: Логов о том, что tool вызвался успешным такой подход разваливается вы просто не можете разобрать а что же происходило в запросе конкретного пользователя в конкретный момент времени тут на помощь приходят более прокаченные инструменты логирования на

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

30: Всю цепочку Логов в момент работы над каким-то конкретным запросом. Вот, например справа есть несколько мёт полей, которые можно прокидывать в каждый лог. Они позволят вам затем при разборе

31: И Логов прода увидеть, что конкретно происходило в момент обработки конкретного запроса конкретного пользователя. Это какая-то база, над которой точно стоит поработать. В 1 очередь, например, стоит точно залоги.

32: Каждый вызов ллм, успешный он или неуспешный, стоит залогировать каждый вызов Тула, например, должны за этим наблюдать. Просто потому, что если мы говорим про стабильность, мы говорим про зависимости, если вы зависите от какого-то

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

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

35: И так или иначе, от исключений никто не защищён. И самое простое, что можно сделать, это наблюдать за всеми исключениями, про которые вы не подумали. Если за ними планомерно наблюдать, то в какой-то момент их станет 0, но на старте вряд ли их будет 0. Итак, после того,

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

37: На май в Стамбул. В этом случае мы можем залогировать, что пользователь спросил, потом мы можем залогировать, что агент подумал, потом можем залогировать, что агент пошёл в тул.

38: Поиска авиабилетов с такими-то такими то параметрами мы можем залогировать ответ инструмента. Дальше что мы хотим залогировать? Мы, наверное хотим залогировать ответ агента пользователю и на самом деле вот всю эту цепочку

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

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

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

42: В 1 трейс для того, чтобы в едином месте можно было очень быстро найти абсолютно все логи, которые мы писали про конкретный запрос пользователя. Как это можно сделать? Давайте объединим их в трейсы трейс. Это тоже

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

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

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

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

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

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

49: Сложно разбираться с трессами в отрыве от общего контекста диалога агента с пользователем. Для этого мы вводим понятие сессии и объединяем трессы с идентификатором какой-то сессии. Это какая-то базовая

50: Необходимая инфраструктурная настройка, без которой мы не сможем двинуться дальше. А где она поможет? Давайте разбираться. 1, где эта штука поможет, она поможет вообще посчитать, наверное, 7.

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

52: Агент выполняет перед тем, как вернуть ответ. 3. Мы должны по хорошему считать, сколько токенов мы сжигаем на каждый запрос 4. Мы должны считать, как хорошо и качественно мы ходим в инструменты. То есть мы должны считать некий сакссес рейд.

53: Походы во внешние инструменты. 5 это какая-нибудь походы во внешние модели. 6, наверное, это вообще в целом успех обработки запроса. Мы должны в реальном времени наблюдать, как много у нас задач, которые ставят агент пользователь.

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

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

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

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

58: Понять, а в каком месте, что идёт не так? Итак, мы собрали метрики, мы собрали логи. Остаётся где-то это все добро посмотреть и можно на самом деле, на этом этапе собрать dashboard и на дешборде в целом будут видны графики с метриками в

59: По системе мониторинга, которую вы выберете под свой проект, можно будет увидеть логи, но, к сожалению, мы не можем наблюдать за дажбордами 24 на 7. Нам нужно выкатывать фичи в продакшн и не смотреть на графики для этого.

60: Системы аллертинга эти системы умеют реагировать на некие аномалии в метриках и автоматически отправлять уведомления, например, в slack, telegram ватсап любой мессенджер, который вы подключите к этим системам.

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

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

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

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

65: Можно построить систему с нуля под всю, про которую я говорил, поэтому в есусе можно посмотреть на 2, наверное, самых популярных и простых решения. 1 это long fuse, это система для того, чтобы смотреть трейсы, логи агентов.

66: A2 система это графана плюс prometheus grafana это система для того, чтобы отображать дашборды с вашими метриками. А прометеус это система для того, чтобы настраивать алертинг метрик, которые вы нарисовали в графане по

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

68: Того, чтобы вы запомнили 1 простую вещь. Перед тем, как что-либо делать в продакшене, стоит покрыться метриками. Совершенно небезопасно вообще трогать агента, запущенного в продакшн без Логов или качественных метрик.

69: Потому что вы совершенно не понимаете, что вы делаете. Просто потому, что вы не видите, что вы делаете. А когда мы говорим про системы, которые работают на большое количество пользователей, цена ошибки гораздо, гораздо выше, чем

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

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

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

73: Качество. Я здесь хочу подвести небольшую черту и поговорить про то, как автоматизировать процесс работы с качеством чуть чуть, чтобы упростить свою жизнь. Давайте представим такой пример. Мы каким-то образом смогли все-таки

74: Достать метрики. Мы смогли получить цифру 62% качества. Это довольно неплохие цифры, но в целом после этого мы сталкиваемся с проблемой белого листа. Мы вряд ли понимаем, а в какую сторону нам как раз-таки копать для того,

75: Чтобы разобраться с проблемой ну, например, можно начать с 1, с категоризации вам нужно разобраться проблема в промте или проблема в instrumental, или проблема вообще в целом то?

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

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

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

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

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

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

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

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

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

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

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

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

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

89: Описывать промт мы можем почти автоматически. В этом нам помогает инструмент. Называется он диспей. Он разработан в стэнфорде. Давай посмотрим, что он умеет. Наверное, стоит вообще подумать, что из себя

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

91: Какой-то чёрный ящик этот вход обрабатывает и получает выход. Вот в случае работы с ллм сама ллм становится этим черным ящиком и, как правило, при классических подходах в мэле вы как раз

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

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

94: Вот в такой концепции как раз думает диспей, можно перейти по QR-коду, почитать подробнее, что он из себя представляет, как им пользоваться и так далее мы в лекции все-таки посмотрим на то, как им пользоваться более.

95: Если мы говорим про диспа, у него есть н важных компонент, мы должны самому фреймворку объяснить ту, какую задачу мы в итоге хотим решить. Ну, например, мы хотим сказать, что сейчас мы Прока,

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

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

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

99: Несколько раз и верни результат. Остаётся придумать метрику, по которой мы будем оценивать, а насколько хорош промт, и подобрать датасет, на котором мы будем обучать этот prompt. И 3, и 4. Вы уже смотрели, как

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

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

102: Пром должен делать. Она видит несколько Десятков, а может быть, и сотен примеров, как мы хотели, чтобы эта модель отвечала. И последнее. Она может оценивать ответы, модели по какой-то

103: Метрики, которые мы заранее ей задали. Мы запускаем некий цикл обучения до тех пор, пока абсолютно все примеры из golden сета не будут зелёные, и на выходе мы получаем какой-то промт, например, по заверениям самих.

104: Ребята из dpi, они в некоторых примерах добивались роста качества и на 30% самое простое из опыта, что даёт диспей, он качественно составляет fushou примеры для какой-то модели это самый.

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

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

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

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

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

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

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

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

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

114: Про то, как важно собирать метрики с production, про то, как это можно делать. Мы поговорили даже про то, как ими пользоваться в случае прокачки качества и как важно автоматизировать те вещи, которые вы можете автоматизировать. Теперь мы поговорим немножко про

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

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

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

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

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

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

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

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

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

124: Смотрим вообще, как можно думать про то, а за что мы платим деньги, и тут надо разделить стоимость классического железа это cpu базы и так далее, и стоимость видеокарт, видеокарты, дороги.

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

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

127: А чем меньше мы утилизируем классического железа, тем больше запросов пользователей мы можем обработать 3. Это важно. Поставить лимиты. Вы так или иначе не сможете посчитать на все случаи жизни, сколько вам нужно тех или иных ресурсов. И вам

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

129: На даунтайме, чем вы бы потратили на разработку лимитов. И, наверное, последнее, стоит подумать, а как ваша система будет сама масштабироваться, исходя, опять же, из тех метрик, про которые мы Говор

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

131: На агента. Дальше мы с вами поговорим про каждый чуть чуть подробнее. Как я говорил раньше, наверное стоит немножко посчитать. Перед тем, как мы что-то выкатываем, на какие показатели стоит смотреть. Вам точно стоит прикинуть.

132: Сколько пользователей и как часто они будут пользоваться агентом? Это можно свести к метрике. Количество запросов в день. Вам точно стоит посчитать, сколько раз мы ходим, например, в ллм или сколько Шагов вообще в целом.

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

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

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

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

137: И вот в этот момент начинается оптимизация. Итак, давайте поговорим про рост контекста. Если мы говорим про самого большого потребителя токенов, а значит и потребителя наших денег, мы говорим про context, это то

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

139: Пользователь может делать референсы предыдущим вопросам или модель может делать в рамках своих размышлений референс к предыдущим запросам, но, к сожалению, из за того, что мы должны держать в голове всю цепочку контекстов, базу

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

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

142: Попытаться использовать скользящее окно, можно пытаться суммаризировать контекст ближе к концу контекстного окна. Можно пытаться, например, сбрасывать контекст после обработки каждого запроса и вычищать из него ненужное да.

143: Давайте поедем дальше. Тут хочется поговорить про следующие 4 уровня оптимизации. 1 паттерн модул роутера. Этот паттерн позволяет выбирать под конкретный запрос пользователя. Какую модель?

144: Использовать и как раз-таки за счёт этого не отправлять лёгкие запросы в сложные модели или не отправлять сложные запросы в лёгкие модели. И хороший модул роутер помогает экономить до 70%.

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

146: Ллм. Мы занимаем ресурсы сервиса простым ожиданием и не можем обработать следующий запрос пользователя. А собственно, чем быстрее мы проходим и обрабатываем запрос пользователя, тем больше запросов мы можем вместить в себя в 1

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

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

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

150: И так далее, и 4. Это стоит подумать о масштабировании. Давайте представим, что ваша система полетит и из текущего состояния вы довольно быстро прилетите в состояние, когда

151: У вас в 2 раза больше запросов. И вот по хорошему стоит иногда проводить такую эвристику и думать, а что будет, если на мою систему в какой-то момент времени придёт в 2 раза больше запросов и ответ?

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

153: Роутер, давайте представим, что у нас 70% вопросов нашего агента. Это простые, часто задаваемые вопросы вида. Какая погода сейчас в Шанхае? Сколько билетов?

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

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

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

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

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

159: Если мы говорим про категорию, например, часто задаваемых вопросов, у каждой компании наверняка будет целая база знаний про то, какие вопросы чаще всего задаются? Ну вот давайте эту базу знаний, попытаемся простой

160: Семантической схожестью с вопросом пользователей проверять. И если мы попадаем в базу часто задаваемых вопросов, мы идём в простую модель. Наверное, что дальше стоит делать? И для сценариев сложнее. Это поду.

161: Над классификацией запросов в определённые кластера. Но вот мы до этого поставили 3 кластера. 1 кластер это часто задаваемые вопросы. 2 это запросы средней сложности, где нужно несколько раз будет

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

163: Давайте попробуем разделить всю базу пользовательских вопросов, которую мы до этого собрали на эти 3 категории и попытаемся классифицировать каждый запрос в 1 из этих 3 категорий. Мы

164: Можем тут воспользоваться классическим эмэлем или воспользоваться ллм как роутером отличие 1 ллм. Как роутер сделать хорошо, гораздо сложнее, чем сделать хороший классификатор классической модели.

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

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

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

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

169: Платить за простой ресурсов железных. Например, если мы можем обрабатывать запросы за 200 миллисекунд, мы сможем обрабатывать миллионы запросов в минуту, в секунду, если мы не можем обраа.

170: Пользовательский запрос, и за 1 минуту мы не сможем просто обработать миллионы пользовательских запросов. Мы свалимся, и никто не будет этому радоваться. Можно использовать для ускорения 3 первона.

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

172: Параллельно, значит, мы ускоряемся. Если мы сможем подобрать хороший промт для ризениха или хороший промт для сложной модели. Вероятнее всего, она потратит сильно меньше Шагов на

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

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

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

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

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

178: В 95 перцентиле агент отвечает пользователю в приемлемые 5 10 секунд. Давайте дальше как раз-таки посмотрим, а что будет, если мы не поставим лимиты? Ну, наверное, если мы не поставим совершенно

179: Никаких лимитов. Будем принимать любые запросы пользователей и будем позволять ллм ходить в циклы, входить в циклы ризонинг, там на 10 или там 20, 15 повторений в лучшем.

180: Случае мы съедим сильно больше токенов, чем нужно. На обработку пользовательского запроса. Не сможем никак это проконтролировать. В худшем случае, на самом деле мы испортим пользовательский опыт. А ещё

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

182: Система будет справляться с большой нагрузкой, потому что у нас очень много ресурсов будет простаивать в ожидании ответа от большой думающей модели. Давайте попробуем просто поставить жёсткий лимит сначала на количество Шагов в

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

184: Следующему шагу, тому шагу, который уже принимает решение в ответ на ризонинг, нам стоит, наверное, жёстко поставить таймауты на ответ. 1, потому что пользователю не очень приятно ожидать.

185: Очень долго ответа. 2. Если мы не справляемся в эслэй, нам стоит самим сбросить задачу. Вероятно, она зависла или что-то другое пошло не так. И, наверное, последнее, что стоит сделать, и это как что-то

186: Среднее между тем, чтобы вообще ничего не делать и внедрять жёсткие лимиты. Это, например, научиться следить внутри модели, что она не сваливается в цикличные походы в какой-то

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

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

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

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

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

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

193: Хочу поговорить с вами о следующей концепции, это какая-то очередь и пул воркеров если говорить об этой концепции, стоит начать с 1 важной мысли, если мы попадаем в ssl по скорости ответа.

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

195: И выдерживает гораздо более высокие нагрузки. Как правило, это работает следующим образом. У вас стоит какая-то очередь и 1 делом любой запрос пользователя попадает в эту очередь и ждёт, пока его кто-то пойдёт.

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

197: И затем брать следующую этих воркеров. Может быть бесконечное количество. Думайте о них как как раз-таки об лимите по количеству задач, которые сервис может обработать в 1 момент времени. Последнее, что

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

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

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

201: Как он ответил, если мы можем найти в нашем кэше ответ на похожий вопрос пользователей ну давайте не запускать агентский цикл, давайте вернём то, что агент уже ответил. Если, например, мы не нашли там какого-то ответа на свой вопрос.

202: Мы можем внедрить ещё 2 кэша, мы можем на самом деле кэшировать походы в инструменты и тут ускоряться на самом деле, но не очень сильно. Тут скорее растёт. Мы экономим нагрузку на системы, которые являются для нас внешними, и

203: 3. Мы можем внедрить кэширование на запросы в ллм. Вот эта вещь примерно похожа по своей полезности с семантическим кэшом, потому что нам не нужно ходить в ллм, если мы понимаем, что в течение

204: Последних 5 минут назад мы уже в неё ходили и какой-то ответ получили. Ну давайте не ходить в неё ещё раз. Давайте использовать этот же ответ. Опять же, мы, с 1 стороны, будем отвечать пользователям гораздо быстрее, а с другой стороны, мы не будем тратить наши ресурсы. Но что важно понять про кэш,

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

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

207: Они обучены отвечать пользователю позитивно, отвечать положительно и как можно больше вкладываться в решение задачи. И, например, если в процессе агентского цикла что-то идёт не так, модель очень просто берет и выдумывает ответ.

208: Пользователю. С 1 стороны, как бы она с задачей справилась. С другой стороны, мы не очень понимаем, как это работает. Мы можем начать с того, что мы будем внедрять гардрейл, как раз-таки и prompt, которые запрещают модели выдум.

209: Опять же мы их внедрим и помним, что никогда стопроцентной гарантии, что модель не проигнорирует этот prompt, у нас не будет хорошая штука, которая помогает, это на самом деле все тот же старый добрый structure аутпут, о нём можно думать как.

210: О каком-то количестве попыток спросить у модели, что мы хотим, и подогнать ответ под ту схему, которую мы ожидаем на выходе, опять же не всегда есть какие-то гарантии исполнения этого контракта.

211: Потому что не все провайдеры модели справляются с этой схемой на текущий момент, но она хотя бы постарается. И последнее, наверное, да, и самое простое для разработчика, но самое плохое.

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

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

214: Попробуем посчитать, сколько денег мы на это все-таки тратим через пару метрик. Нам, наверное, стоит следить за стоимостью обработки каждого конкретного запроса. И если в высоких пресенти ях стоимость очень высокая, это повод.

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

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

217: Мы будем сильно подвержены каким-то пикам и мы будем реагировать на ежемоментное всплески нагрузки, а не чинить проблему системно. Поэтому и та, и другая метрика также важны. Теперь самое интересное это безопасность. И как делать агентов

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

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

220: К данным, которые вы бы не хотели отправлять пользователю, обязательно получится у кого-то сходить с неправильными параметрами в базу данных, например, авиабилетов, и достать авиабилеты вообще другого человека и

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

222: И мало безопасными. Если модель может ими воспользоваться, ей обязательно кто-то воспользуется. Например, можно подумать, а почему нам нужно ограничивать именно инструментами? Ведь есть гардрейл и есть промт, но мы возвращаемся.

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

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

225: Работать с секретными данными. Мы будем работать с данными пользователей и персональными данными. Даже не отдавать их в модель. Это нам поможет не отвечать злоумышленникам персональными данными пользователей и их

226: Идентификаторами. Перед тем, как посмотреть на пару примеров, подведём итог. Вот на эти 2 принципа мы не можем доверять вообще модели и мы не можем доверять контексту, который лежит внутри модели. Мы

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

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

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

230: Давайте поглядим на пару примеров. Самый, наверное, популярный инструмент сейчас в индустрии это open кло это просто волшебная палочка, которая умеет делать все и даже больше. А ещё она умеет хранить в своём маркетплейсе Скилов 8.

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

232: Гайду на вайб кодили себе виртуальный инстанс этого open кло, и все это как раз-таки из за того, что модели дали слишком большой контекст, ей разрешили слишком много, и, конечно же, нашлись злоумышленники, которые смогли этой уязвимость.

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

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

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

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

237: Давайте посмотрим на 3 уровня защиты, тогда как с этим бороться. 1 это инструменты. Если мы говорим про определение инструментов, агент должен видеть строго ограниченный список возможных, инструменты должны иметь строгое

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

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

240: Рассмотрим какой-то игрушечный пример например, наш злоумышленник пытается в плохо написанном Туле, в котором разработчик оставил аргумент user id это какой-то идентификатор пользователя, возможно, там токен.

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

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

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

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

245: Нет возможности подставить в контекст вызова инструмента другой идентификатор.

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

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

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

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

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

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

252: На агента бронирования авиабилетов поверх какого-то сервиса бронирования авиабилетов вы используете всю готовую инфраструктуру, скорее всего и все сервисы умеют авторизовываться через оаус или какую-то подобную систему аутентификации и наверное,

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

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

255: И с безопасностью. Давайте, наверное, завершать. Мы придвинулись к 3 акту. Мы на протяжении 4 дней и 2 актов диалог со мной разобрались сначала как собрать

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

257: Возникает следующая задача, о которой я говорил в самом начале. Радостный бизнес говорит, а давайте мы будем бронировать визы, давайте мы будем покупать страховки, и давайте мы будем закрывать полностью весь цикл авиаперевозок человека. А почему бы и нет? Вот

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

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

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

261: Завершалась быстрее и так далее. Давайте подумаем, как вообще принять решение, нужно ли выделять платформенную команду и вообще, какой профит она будет нам приносить. Можно пользоваться правилом 3, если

262: Вам нужно довольно часто повторять один и тот же путь, решать 1 и ту же задачу в 3 и более местах. В этот момент выделить хотя бы 1 разработчика на технические, инфраструктурные задачи. Имеет смысл просто

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

264: Платформу, скорее всего, вы не напишите 1 агента, а если вы попытаетесь написать 2 агента по тем же рельсам, у вас это получится быстрее, просто потому, что вы многому научились, пока делали.

265: 1 и в этот момент все ещё не нужно делать платформу, потому что эта инвестиция будет довольно сомнительная. Вам не нужно будет решать эти задачи довольно часто, поэтому зачем это обобщать? Но, допустим, окей, нам нужно

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

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

268: Нам, наверное, нужно подумать про систему оценки качества и какую-то тоже систему оценки качества написать. Вот задачи, которые можно отнести к инфраструктурным, можно решить 1 раз и решить хорошо, и эти задачи не нужно решать.

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

270: Логикой. Это какая-то бизнесовая логика самого агента, например, его промпт, например, то, как построен, че сот, например, там последовательность нот в графе Ланграф. Вот подобные вещи можно считать бизнес логикой.

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

272: Получится довольно Нестройная система, которая не разграничивает зоны ответственности разных компонент прозрачно какая-то компонента почему-то переиспользует промт с другой компонентой, и если этот prompt.

273: Написать плохо, сломаются обе компоненты, но могла ведь и не сломаться компонента номер 2. Поэтому тут опять же важно думать о балансе. Не стоит утаскивать абсолютно все в обобщённый слой. Там стоит хранить только

274: Инфраструктуру. Давайте подумаем, как может выглядеть наша тревел платформа, исходя из того, что я вам рассказал. Сейчас мы можем написать 4 агентов, у которых будет свой уникальный пром, свой уникальный цикл обрабо,

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

276: Данных и так далее, и так далее. Эвал и в общем, много, много инфраструктурных Кубиков. Стоит это писать 1 раз. Это потратит какое-то время на старте, но значительно вас ускорит на каждом последующем агенте и, например,

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

278: Хочу вот на что разработка каждого агента и каждого по делится на 3 стадии. Вам обязательно всегда нужно собрать какой-то прототип и хотя бы попробовать решить эту задачу. Вы обязательно в какой-то момент

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

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

281: Напишите платформу, но нельзя, наверное, мешать эти стадии. Нельзя сразу писать хорошо, потому что вы просто не успеете написать и конкуренты напишут что-то быстрее, а также нельзя вообще.

282: Совсем забивать и не писать платформу и не думать о стабильности своего продукта просто потому, что пользователи разбегутся и не смогут пользоваться качественным продуктом. Давайте с вами подводить итоги, о чем мы сегодня с вами поговорили, мы поставили

283: Самом начале лекции 7 проблем. Эти 7 проблем будут ждать вас на пути доведения продукта до продакшена. Мы попытались подумать о том, как правильно бороться с каждой из этих проблем. Выстроили, как мне кажется.

284: Встроенный подход к борьбе с стабильностью, борьбе с потреблением денег, лмками и так далее. Ну а в конце обсудили, а когда стоит делать платформу, если

285: Её делать то как сделать хорошо на этом спасибо всем. Я с вами прощаюсь.