Source: https://sozai.app/transcript/youtube-video-transcript-89/

Дмитрий Березинский рассказывает о важности роутинга и управления контекстом для оптимизации работы агентов на базе языковых моделей.

## Key Takeaways

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

## What the video covers

- Стоимость запросов к фронтир модели может быть очень высокой, что требует оптимизации.
- Интеллект агента заключается не только в модели, но и в инфраструктуре вокруг неё: роутинг, ретривол и управление контекстом.
- Роутинг позволяет выбирать между дорогими и дешевыми моделями, снижая затраты при сохранении качества.
- Классификатор запросов решает, какую модель вызвать, что помогает экономить и улучшать качество.
- Важно учитывать особенности кэша при переключении моделей, чтобы не потерять эффективность.
- Наблюдаемость и метрики необходимы для контроля качества роутинга и затрат.
- Модель без актуальных знаний ограничена датой обучения, поэтому нужны внешние источники данных.
- Retrieval-Augmented Generation (RAG) — подход с использованием векторных баз для подстановки релевантных фрагментов в контекст.
- Альтернативный подход — использование очень больших контекстных окон для загрузки всей информации напрямую.
- Выбор между RAG и длинным контекстом зависит от сложности задачи и технических возможностей.

Answers

## Questions about this video

Почему важно использовать роутинг моделей в агенте?

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

Что такое Retrieval-Augmented Generation (RAG) и зачем он нужен?

RAG — это метод, при котором документы разбиваются на фрагменты, преобразуются в векторы и хранятся в базе для поиска релевантных частей, которые подставляются в контекст модели для улучшения качества ответов.

Какие проблемы возникают при переключении моделей в диалоге?

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

## Full Transcript — Download SRT & Markdown

00:00

Speaker A

3 доллара, столько стоит одна задача, и я агент, если отправлять каждый запрос на фронтир модель с полным контекстом.

00:07

Speaker A

3 доллара, кажется, мелочь, агент делает 10 вызовов за задачу, 1000 задач в день.

00:12

Speaker A

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

00:24

Speaker A

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

00:41

Speaker A

Всем привет, меня зовут Дмитрий Березинский, и это вторая часть серии Анатомия агентов, первый мы вскрыли скелет, пайплайн, контекст, циклы, инструменты, сегодня мозг.

00:51

Speaker A

Ну что, поехали?

00:55

Speaker A

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

01:06

Speaker A

Сейчас же разберёмся, почему, и начнём мы с вами с роутинга.

01:10

Speaker A

Сколько моделей доступно на рынке?

01:15

Speaker A

Десятки, сотни, и каждый месяц появляются новые.

01:20

Speaker A

А цены отличаются не на проценты, в разы, дешёвая модель и дорогая, разница может быть в 30, 50, 100 раз за один и тот же запрос.

01:29

Speaker A

И какой же выбрать?

01:34

Speaker A

Кажется, что ответ подороже, чтобы она точно работала и хорошо отвечала.

01:40

Speaker A

И шлём мы туда все запросы подряд.

01:44

Speaker A

Сколько сахара добавить в кофе?

01:47

Speaker A

Отправляем дорогую модель.

01:48

Speaker A

Рефакторинг архитектуры?

01:50

Speaker A

Тоже отправляем дорогую модель.

01:52

Speaker A

Вернёмся к нашему примеру бариста, который у нас проходит через серию всех наших видео.

01:58

Speaker A

Сколько стоит латте?

02:01

Speaker A

Это обычный лукап, и дешёвая модель ответит быстро и качественно.

02:05

Speaker A

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

02:13

Speaker A

Вот это уже сложный запрос, и возможно, его стоит отправить фронтир модели.

02:17

Speaker A

Зачем же за них платить одинаково?

02:19

Speaker A

Идея простая: маленький классификатор смотрит на запрос и решает.

02:23

Speaker A

Отправить на дорогую модель или на дешёвую.

02:27

Speaker A

Это как сортировщик на почте.

02:31

Speaker A

Взвесил, посмотрел адрес и отправил уже в нужное окно.

02:35

Speaker A

Исследователи из Беркли формализовали это в роутер LLM, это Open Source Framework.

02:43

Speaker A

Результат - снижение стоимости более чем вдвое при сохранении 95% качества.

02:49

Speaker A

И здесь можно задуматься, ну ладно, роутинг - это понятно.

02:55

Speaker A

Но дешёвая же модель, она глупее, и качество у нас очень сильно упадёт, и эти 5% для нас важны.

03:02

Speaker A

Но здесь нам надо уже понимать, что для нас важно.

03:08

Speaker A

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

03:14

Speaker A

И казалось бы, что такого сложного в роутинге?

03:18

Speaker A

Давайте разбираться.

03:20

Speaker A

Как его реализовать для нашего с вами агента?

03:25

Speaker A

Итак, у нас есть с вами наш запрос.

03:28

Speaker A

Какие же дальше у нас с ним будут происходить шаги?

03:32

Speaker A

Давайте посмотрим, что нам надо сделать первым.

03:38

Speaker A

На этом этапе мы смотрим на тип входящих данных, что же к нам приходит: картинки, аудио или просто текст.

03:46

Speaker A

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

03:52

Speaker A

Дальше, шаг второй.

03:57

Speaker A

Шаг второй - модель классификатор.

04:03

Speaker A

Здесь у нас может быть с вами небольшая модель или модель подороже, или вообще мы можем с вами оттюнить модель на наших данных.

04:10

Speaker A

Всё зависит от того, что мы можем туда поставить.

04:13

Speaker A

Основная её цель - это возвращать ту, какую модель дальше вызвать.

04:20

Speaker A

Ну и шаг третий.

04:24

Speaker A

Это будет фулбек.

04:25

Speaker A

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

04:33

Speaker A

То здесь мы можем с вами сделать простые правила по ключевым словам.

04:37

Speaker A

Это как запасной генератор: не очень красиво, шумно, но свет есть.

04:43

Speaker A

Также мы можем сюда поставить просто выбор модели по умолчанию.

04:49

Speaker A

И как мы видим, у нас есть две детерминированные части.

04:57

Speaker A

И одна недетерминированная - наш классифаер.

05:00

Speaker A

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

05:07

Speaker A

Поэтому на основе входящего запроса наш классифаер должен определить, какая же модель для него подходит.

05:15

Speaker A

И качество описания этих моделей, оно напрямую влияет на качество нашего с вами роутинга.

05:23

Speaker A

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

05:30

Speaker A

Но если мы с вами приходим к каким-то сложным агентам, у нас могут быть специализированные модели под определённые задачи.

05:40

Speaker A

Может, мы сделали файн-тюнинг или определили, что разные модели по-разному работают.

05:46

Speaker A

С определёнными запросами, и как раз-таки в этом случае наш классифаер даст нам не только экономию.

05:53

Speaker A

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

05:59

Speaker A

Но есть один нюанс, который часто не рассматривают.

06:02

Speaker A

Когда думают о том, что будут использовать роутер.

06:06

Speaker A

И это самый настоящий подводный камень.

06:09

Speaker A

Когда наш роутер переключает наши модели, то нам надо с вами понимать.

06:16

Speaker A

А есть ли у нас с вами сейчас кэш?

06:19

Speaker A

Может быть, у нас идёт довольно-таки длинный диалог с пользователем, и сейчас мы кэш очень эффективно используем.

06:26

Speaker A

И наши запросы уже экономически эффективны.

06:29

Speaker A

Так вот, у разных провайдеров это может работать по-разному.

06:34

Speaker A

Где-то этот кэш автоматически, где-то его надо включить через API и платить за это.

06:39

Speaker A

И время жизни при этом у кэша разное.

06:42

Speaker A

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

06:49

Speaker A

А может, переключение на более дешёвую модель с учётом кэша дорогой теперь стоит дороже.

06:56

Speaker A

И это значит, не делать роутер.

07:01

Speaker A

Это значит, что вам надо считать и смотреть, как и когда вы можете переключать.

07:07

Speaker A

И здесь есть пересечение с первой частью.

07:12

Speaker A

Помните, мы закончили на наблюдаемости.

07:14

Speaker A

Без неё наш роутинг слепой.

07:20

Speaker A

И вы не знаете, правильно ли наш классификатор выбрал модель?

07:25

Speaker A

Сколько стоит средний запрос на каждую модель?

07:29

Speaker A

Сколько мы теряем на переключениях кэша?

07:33

Speaker A

Роутинг без метрик - это надежда, но не инженерия.

07:38

Speaker A

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

07:44

Speaker A

Без этого будет тяжело добиться хорошего качества.

07:47

Speaker A

Роутинг выбирает модель.

07:50

Speaker A

Но модель без знаний - это как у нас врач без карты пациента.

07:55

Speaker A

Он, скорее всего, умный.

07:58

Speaker A

Очень хочется в это верить.

08:00

Speaker A

Но каждый раз, когда вы с ним общаетесь, он не знает, что же у вас там было.

08:05

Speaker A

Так вот, откуда наш агент берёт знания?

08:11

Speaker A

Давайте вспомним, что наши языковые модели, они заморожены во времени.

08:15

Speaker A

Они знают всё о мире до даты обучения, и ничего о том, что произошло недавно.

08:21

Speaker A

Ничего о ваших внутренних документах, вашей кодовой базе, ваших клиентах.

08:26

Speaker A

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

08:32

Speaker A

И здесь вопрос: как?

08:34

Speaker A

Здесь у нас есть с вами несколько интересных мнений.

08:38

Speaker A

И первое - это рак.

08:40

Speaker A

Retrieval-Augmented Generation.

08:43

Speaker A

Это инженерный подход, когда мы нарезаем документы на фрагменты, превращаем векторы, складываем в базу.

08:51

Speaker A

И когда пользователь спрашивает, ищем релевантные фрагменты и подставляем в контекст.

08:57

Speaker A

Модель видит не всё, только то, что мы с вами нашли.

09:01

Speaker A

И второй подход - это длинные контексты.

09:05

Speaker A

Берём документы и запихиваем целиком в контекстное окно.

09:10

Speaker A

Без базы, без эмбедингов, без поисков.

09:14

Speaker A

Просто модель сама разбирается.

09:18

Speaker A

У неё же миллионы токенов.

09:20

Speaker A

Она же справится.

09:21

Speaker A

И это тот выбор, перед которым мы часто с вами стоим.

09:25

Speaker A

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

09:31

Speaker A

С чего же начались все эти обсуждения?

09:36

Speaker A

А с того, что сейчас контекстные окна стали огромными.

09:40

Speaker A

Мы можем с вами засовывать туда миллион токенов.

09:43

Speaker A

Это 700.000 слов.

09:45

Speaker A

То есть туда влезает вся серия томов Властелин колец, и ещё хоббит к ней в придачу, и останется место.

09:53

Speaker A

И зачем же тогда нам нужен весь этот рак стек?

09:57

Speaker A

Все эти чанки, эмбединги, векторные базы, различные подходы, технологии для того, чтобы всё это качественно выбирать, тестировать, смотреть.

10:05

Speaker A

Это невероятно сложно.

10:06

Speaker A

Если же мы можем просто запихнуть всё в контекстное окно.

10:10

Speaker A

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

10:15

Speaker A

И давайте подойдём к этому инженерно.

10:20

Speaker A

Рассмотрим плюсы, минусы разных подходов, поймём, какие у нас есть трейдофы и там, и там, и что же мы можем с вами использовать.

10:28

Speaker A

И первое, почему мы будем оценивать - это простота.

10:31

Speaker A

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

10:39

Speaker A

Выбрать стратегии того, как же мы будем нарезать эти данные.

10:43

Speaker A

Понять, какие модели для эмбедингов подходят, может быть, нам надо их тюнить.

10:49

Speaker A

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

10:56

Speaker A

И это очень много различных движущихся частей.

11:00

Speaker A

Много мест, где что-то может сломаться.

11:05

Speaker A

А с точки зрения контекста, наш длинный контекст взял документ, положил в промт.

11:10

Speaker A

И всё.

11:11

Speaker A

Нету ни стека, ни поломок.

11:16

Speaker A

Нам не надо всё это разворачивать.

11:20

Speaker A

Мы просто работаем с контекстом.

11:24

Speaker A

И второе - это полнота предоставляемых данных.

11:27

Speaker A

Рак у нас ищет по математическим представлениям текста.

11:31

Speaker A

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

11:39

Speaker A

И здесь мы с вами даже не узнаем о том, что мы не поместили в контекст то, что у нас есть.

11:45

Speaker A

С длинным же контекстом всё наоборот.

11:48

Speaker A

Модель видит всё, и ей негде промахнуться.

11:53

Speaker A

Третий, который вытекает отсюда же.

11:57

Speaker A

Это у нас есть с вами иногда задачи, где нам нужна полная картина.

12:01

Speaker A

Допустим, у нас есть документ с требованиями и документ с релизными заметками.

12:07

Speaker A

И был вопрос: какие требования по безопасности пропущены в релизе?

12:12

Speaker A

Рак может найти фрагменты по безопасности в документах, но при этом он может что-то пропустить.

12:19

Speaker A

Для того, чтобы модель увидела всё, ей надо два документа целиком.

12:26

Speaker A

Поэтому в рак у нас возможен пропуск.

12:29

Speaker A

А контекст у нас с вами видит всё.

12:31

Speaker A

И это у нас довольно сильные аргументы в пользу контекста.

12:35

Speaker A

Если на этом остановиться, то можно вообще выкинуть рак и больше никогда его не использовать.

12:40

Speaker A

Но давайте посмотрим на экономику.

12:42

Speaker A

У нас есть с вами плата за перечитывание.

12:45

Speaker A

И это деньги.

12:47

Speaker A

Длинный контекст означает, что модель будет перечитывать все наши документы при каждом запросе.

12:55

Speaker A

И нам придётся платить за этот документ много раз: сегодня, завтра, послезавтра.

13:02

Speaker A

Всегда, когда мы будем использовать этот документ и помещать его в контекст.

13:08

Speaker A

Нам придётся платить за то, что модель будет его читать.

13:12

Speaker A

При этом рак платит за обработку документа один раз, в момент, когда мы его загрузили.

13:18

Speaker A

Да, вы скажете, кэширование документов снимает эту проблему.

13:21

Speaker A

Но это только для одной конкретной сессии.

13:25

Speaker A

Ведь эти документы мы будем использовать не один раз.

13:28

Speaker A

А множество сессий, множество запросов.

13:30

Speaker A

А значит, и кэш нам здесь с вами не помогает.

13:34

Speaker A

Следующий пункт назовём его игла в стоге сена.

13:36

Speaker A

И она нам говорит про качество на длинных контекстах.

13:40

Speaker A

Помните про Lost in the Middle из Стэнфорда?

13:44

Speaker A

Когда контекст растёт до сотен тысяч токенов, внимание модели размывается.

13:50

Speaker A

А это значит, что какой-то конкретный параграф в середине 2.000-страничного документа модель может его даже не заметить или начать галлюцинировать детали из окружающего текста.

13:59

Speaker A

Раньше в этом плане убирает стог сена и даёт модели только иголки.

14:05

Speaker A

А это значит, что здесь будет намного меньше шума и точнее ответ.

14:08

Speaker A

Да, новые модели значительно снизили выраженность этого эффекта, но его полностью пока не устранили.

14:15

Speaker A

А это значит, что нам надо с вами об этом продолжать думать.

14:20

Speaker A

И последнее, что мы с вами разберём - это масштаб.

14:22

Speaker A

Миллион токенов звучит впечатляюще.

14:24

Speaker A

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

14:32

Speaker A

И это у нас с вами может не получиться.

14:35

Speaker A

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

14:42

Speaker A

А это именно то, что делает наш с вами рак.

14:47

Speaker A

А это значит, для рага подходит, что мы можем сюда запихнуть любой объём нашей базы знаний.

14:52

Speaker A

При этом, когда у нас длинное контекстное окно, мы не можем сюда добавить всю нашу базу знаний.

15:00

Speaker A

Так что же нам с вами выбрать?

15:03

Speaker A

Рак или длинное контекстное окно?

15:06

Speaker A

Если у нас с вами ограниченный выбор документов и задача на глобальное рассуждение.

15:12

Speaker A

То это будет длинный контекст.

15:15

Speaker A

Если же у нас гигантская корпоративная база знаний, у нас тысячи документов, у нас динамические данные.

15:24

Speaker A

И у нас есть способность развернуть и поддерживать рак качественно.

15:30

Speaker A

То однозначно мы с вами выберем рак.

15:33

Speaker A

Но в реальности сейчас чаще всего мы объединяем и рак, и длинное контекстное окно.

15:40

Speaker A

Рак у нас с вами находит релевантное.

15:44

Speaker A

Длинное контекстное окно позволяет положить достаточно для рассуждений.

15:49

Speaker A

Поэтому в зависимости от ситуации, в которой мы находимся, мы можем выбирать одно, другое.

15:55

Speaker A

Или и то, и другое.

15:57

Speaker A

Мы можем взять лучшее из обоих миров.

16:00

Speaker A

И на этот счёт уже есть исследования, когда в контекстное окно запихивают всё, что только возможно.

16:08

Speaker A

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

16:13

Speaker A

Тем самым контекстное окно уменьшается в этих исследованиях в четыре раза с рагом.

16:18

Speaker A

И как результат, 90% снижение задержки.

16:21

Speaker A

С 70 секунд с полным контекстным окном до полутора.

16:28

Speaker A

Но что же с качеством?

16:30

Speaker A

Авторы нам пишут: полный контекст даёт небольшое преимущество в точности.

16:34

Speaker A

Но при этом рак даёт нам конкурентное качество при меньших затратах и большей скорости.

16:39

Speaker A

Поэтому нам с вами надо будет взвешивать, что же для нас с вами важнее.

16:43

Speaker A

Из тех инструментов, которые мы можем использовать.

16:48

Speaker A

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

16:57

Speaker A

Ссылка будет в описании.

16:59

Speaker A

Здесь мы не будем повторяться и смотреть уже на конкретные техники.

17:03

Speaker A

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

17:11

Speaker A

И первое - это обогащение запроса пользователя.

17:15

Speaker A

Если пользователь напишет нашему с вами баристе: а покрепче.

17:21

Speaker A

Это всего лишь два слова и никакого контекста.

17:24

Speaker A

Если мы с вами отправим этот запрос в наш рак, то, скорее всего, мы получим какой-то мусор.

17:29

Speaker A

Но если перед фазой рага мы поставим обогащение нашего запроса и посмотрим контекст предыдущего сообщения.

17:39

Speaker A

Или о чём вообще наш пользователь до этого общался.

17:42

Speaker A

То мы можем получить запрос.

17:46

Speaker A

Пользователь хочет более крепкий кофе.

17:50

Speaker A

Предыдущий заказ был капучино.

17:52

Speaker A

И теперь наш рак найдёт всё правильно.

17:55

Speaker A

И второй, не менее важный - это фидбек луп.

18:00

Speaker A

Это то, что делает рак живым.

18:03

Speaker A

То есть рак даёт нам с вами ответ.

18:06

Speaker A

Мы смотрим за реакцией пользователя.

18:10

Speaker A

И на основе реакции обновляем наши базы.

18:15

Speaker A

И это нам помогает давать более точный ответ в следующий раз.

18:18

Speaker A

Как на примере нашего бариста.

18:22

Speaker A

Если пользователь одобрил заказ, то вес предпочтения растёт.

18:27

Speaker A

Если же пользователь отклонил, то вес падает.

18:30

Speaker A

А если пользователь написал: я теперь предпочитаю чай.

18:34

Speaker A

То это у нас будет новая запись.

18:36

Speaker A

Но как же это реализовать?

18:38

Speaker A

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

18:43

Speaker A

Здесь главное - не блокировать нашего пользователя при работе с основным потоком.

18:48

Speaker A

Поэтому помните, что рак без обратной связи - это отличная база.

18:53

Speaker A

Рак с обратной связью - это уже обучающая система.

18:56

Speaker A

Но здесь возникает вопрос: рак даёт нам знания.

18:59

Speaker A

Но знания - это очень общее слово.

19:03

Speaker A

Какие именно?

19:05

Speaker A

Когда нам надо работать с этой реакцией?

19:07

Speaker A

Что вообще мы можем здесь делать?

19:09

Speaker A

Потому что предпочтения пользователей - это одно.

19:13

Speaker A

Уроки из прошлых ошибок - это другое.

19:16

Speaker A

Текущий контекст задачи - это третье.

19:19

Speaker A

У агента не одна память, их четыре.

19:22

Speaker A

Почему и какие они?

19:24

Speaker A

Давайте продолжать.

19:28

Speaker A

У нашего с вами агента есть память.

19:34

Speaker A

Отлично.

19:35

Speaker A

Но какая?

19:37

Speaker A

Ну, Memory.

19:38

Speaker A

Но какая конкретная?

19:40

Speaker A

Это как сказать, у компьютера есть хранилище.

19:46

Speaker A

Регистры процессора, оперативная память, SSD, облачный архив.

19:50

Speaker A

Четыре абсолютно разных типа с разным временем жизни и назначением.

19:55

Speaker A

У агента тоже четыре.

19:57

Speaker A

Эту классификацию формализовали исследователи из Принстона в фреймворке COALA Cognitive Architecture for Language Agents.

20:05

Speaker A

Сегодня её используют все основные фреймворки.

20:08

Speaker A

И каждый тип решает свою задачу.

20:10

Speaker A

Давайте разберём.

20:11

Speaker A

И первое у нас будет процедурная.

20:16

Speaker A

Процедурная память - это то, как делать.

20:20

Speaker A

Здесь будет наш системный промт плюс описание инструментов.

20:24

Speaker A

Это не база знаний, это инструкция.

20:28

Speaker A

Как должностная инструкция у нас с вами на работе.

20:31

Speaker A

И её обновляют осознанно между сессиями, не на лету.

20:36

Speaker A

Внутри сессии она стабильна.

20:42

Speaker A

Итак, инструкция у нас с вами есть.

20:46

Speaker A

Но откуда агент знает факт, кто что любит, что написано в документации?

20:52

Speaker A

Какая у клиента политика возврата?

20:55

Speaker A

И это будет семантическая память.

21:00

Speaker A

И это то, что знает наш агент.

21:02

Speaker A

Здесь как раз-таки и будет наш с вами рак.

21:04

Speaker A

Это долгосрочные знания, которые обновляются по мере поступления новых.

21:09

Speaker A

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

21:16

Speaker A

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

21:23

Speaker A

Как аналог - это справочник.

21:26

Speaker A

И он не статичный, он живой, который постоянно пополняется и корректируется.

21:33

Speaker A

Факты у нас теперь с вами есть.

21:35

Speaker A

Давайте вернёмся к нашему агенту баристе и подумаем, а кто же учит нашего агента на ошибках?

21:41

Speaker A

Справочник нам говорит, что Костя любит латте.

21:44

Speaker A

А кто помнит, что в прошлый вторник забыли его аллергию на орехи?

21:50

Speaker A

И у нас был с вами инцидент.

21:53

Speaker A

И в этом нам с вами поможет эпизодическая память.

21:59

Speaker A

Это то, что было, это конкретные эпизоды с результатами.

22:02

Speaker A

И это самый недооценённый тип.

22:06

Speaker A

В индустрии очень часто его игнорируют.

22:09

Speaker A

Как пример, LangChain.

22:11

Speaker A

Они именно так и пишут: единственный тип памяти из COALA, который у нас отсутствует - это эпизодик.

22:16

Speaker A

И поэтому большинство продакшн систем.

22:18

Speaker A

Особенно, которые работают на LangChain, они его не реализуют.

22:21

Speaker A

А зря.

22:22

Speaker A

Как наш пример.

22:24

Speaker A

Наш бариста забыл про аллергию.

22:27

Speaker A

У нас произошёл инцидент.

22:29

Speaker A

Была жалоба.

22:30

Speaker A

Может быть, мы потеряли репутацию или деньги.

22:33

Speaker A

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

22:41

Speaker A

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

22:45

Speaker A

И этот подход сработал.

22:47

Speaker A

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

22:52

Speaker A

Поэтому это у нас как дневник с уроками.

22:58

Speaker A

Как мы с вами это можем реализовать?

23:00

Speaker A

У нас есть с вами различные записи.

23:04

Speaker A

В них есть действие, контекст, результат и урок.

23:07

Speaker A

И перед действием, которое хочет совершить агент, он спрашивает наше хранилище.

23:13

Speaker A

Были ли проблемы с похожими действиями раньше?

23:17

Speaker A

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

23:23

Speaker A

Ну и, соответственно, после следующего действия мы опять записываем результат.

23:26

Speaker A

То есть у нас с вами появляется два дополнительных действия.

23:29

Speaker A

Каждый раз чтение перед действием и запись после.

23:32

Speaker A

Понятно, что здесь у нас будет с вами накапливаться знания.

23:34

Speaker A

И нам надо будет реализовать забывание.

23:37

Speaker A

Здесь ровно так же, как проблема работы с кэшом.

23:40

Speaker A

Когда же нам его инвадировать?

23:41

Speaker A

И здесь мы можем проставлять веса нашим знаниям или придумывать другие алгоритмы вытеснения.

23:46

Speaker A

Поэтому, чтобы каждый день у нас не было одних и тех же ошибок.

23:51

Speaker A

Чтобы мы не начинали с чистого листа.

23:54

Speaker A

Мы используем этот тип памяти.

23:56

Speaker A

А это значит, что теперь все уроки у нас будут запомнены.

23:59

Speaker A

Но что агент знает прямо сейчас?

24:03

Speaker A

В конкретной задаче, в конкретном диалоге.

24:06

Speaker A

И для этого нам с вами поможет рабочая память.

24:11

Speaker A

И это то, что прямо сейчас.

24:14

Speaker A

Контекст текущей задачи.

24:16

Speaker A

Возвращаемся к нашему баристе.

24:19

Speaker A

Пять человек, ретро через час, стресс после хотфикса.

24:24

Speaker A

Минус 15 у нас на улице.

24:27

Speaker A

И эта память живёт, пока задача активна.

24:30

Speaker A

Потом она нам не нужна.

24:32

Speaker A

Она уничтожается.

24:34

Speaker A

То есть это у нас будет как оперативная память.

24:37

Speaker A

И она у нас с вами временная.

24:42

Speaker A

Итак, у нас с вами есть четыре типа.

24:46

Speaker A

Это четыре жизненных цикла.

24:48

Speaker A

Процедурная, она у нас меняется редко между сессиями.

24:53

Speaker A

Семантическая обновляется по мере поступления новых данных.

24:57

Speaker A

Эпизодическая содержит инсайты из того, что мы с вами делали.

25:01

Speaker A

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

25:05

Speaker A

Выглядит как очень красивая модель.

25:09

Speaker A

Но строит ли кто-то так в реальности?

25:13

Speaker A

Или это просто академическая классификация из научных работ?

25:16

Speaker A

И это всё очень избыточно для нашего продакшена, для наших агентов.

25:20

Speaker A

Так вот, ответ на этот вопрос пришёл буквально вчера.

25:24

Speaker A

31 марта этого года Anthropic выпускает очередную версию Claude Code, и это был их рутинный релиз.

25:32

Speaker A

Кто-то забыл добавить одну строчку в конфигурации сборки, одну, и весь исходный код стал доступен.

25:39

Speaker A

500.000 строчек кода, и там было всё.

25:43

Speaker A

Система инструментов, оркестрация, промты, и самое для нас интересное в разрезе нашего сегодняшнего диалога.

25:49

Speaker A

Полная архитектура памяти.

25:51

Speaker A

Да, Anthropic через час нашёл эту проблему, через три на GitHub зеркала с этой утечкой уже набирали десятки тысяч звёзд.

25:57

Speaker A

При этом Anthropic подтвердил, что это ошибка упаковки, не взлом.

26:01

Speaker A

Я подробно изучил их архитектуру, чтобы понять, как устроены продакшн системы лидеров рынка.

26:08

Speaker A

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

26:13

Speaker A

Но архитектурные решения, давайте разберём.

26:16

Speaker A

Потому что это продукт с выручкой.

26:20

Speaker A

2,5 млрд долларов в год.

26:23

Speaker A

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

26:28

Speaker A

Многие издания написали, что это трёхслойная архитектура памяти.

26:32

Speaker A

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

26:40

Speaker A

Давайте посмотрим на карту целиком.

26:42

Speaker A

Проведём через него запрос пользователя и посмотрим, что происходит в памяти.

26:48

Speaker A

А для этого нам надо посмотреть, что попадает в контекстное окно.

26:51

Speaker A

Что увидит модель?

26:55

Speaker A

И наша с вами задача будет понять, как память попадает внутрь.

26:59

Speaker A

И здесь у нас контекстное окно разделено на две зоны.

27:02

Speaker A

Статическая.

27:04

Speaker A

В ней у нас будут правила поведения, стиль, инструкции по инструментам.

27:08

Speaker A

Она будет одинакова для всех наших запросов.

27:11

Speaker A

И она кэшируется глобально.

27:16

Speaker A

И вторая часть - динамическая.

27:19

Speaker A

И здесь у нас будет память, окружение, язык.

27:22

Speaker A

И у каждого это будет своя.

27:24

Speaker A

Зачем так надо?

27:26

Speaker A

Сейчас мы с вами разберём.

27:28

Speaker A

Но мы можем запомнить, что Memory MD живёт именно здесь, в динамической части.

27:36

Speaker A

Следующая часть динамической памяти.

27:39

Speaker A

Всем нам с вами знакомый файл.

27:41

Speaker A

Claude MD.

27:44

Speaker A

И здесь у нас с вами будут инструкции нашего проекта.

27:47

Speaker A

И метасообщения перед историей.

27:52

Speaker A

Дальше, если наш контекст раздулся и произошёл компакшн.

27:56

Speaker A

То здесь будет компакт саммари.

28:00

Speaker A

Который будет заменять собой все наши старые сообщения.

28:03

Speaker A

Это сжатие нашего контекста.

28:05

Speaker A

Дальше у нас с вами пойдёт история разговора.

28:08

Speaker A

И результаты работы инструментов.

28:12

Speaker A

И в самом низу у нас будет Memory Attachments.

28:15

Speaker A

Это файлы, которые дешёвая модель выбрала в фоне для того, чтобы наполнить наш контекст дополнительной информацией.

28:23

Speaker A

Заметьте порядок.

28:25

Speaker A

Статическая инструкция самого верха.

28:29

Speaker A

Динамическая память внизу.

28:31

Speaker A

Помните Lost in the Middle?

28:32

Speaker A

Самое важное в начале и в конце.

28:35

Speaker A

Середина - это история и результаты инструментов.

28:38

Speaker A

Это не случайно.

28:39

Speaker A

Это попытка максимально эффективно использовать те модели, которые доступны прямо сейчас.

28:43

Speaker A

Теперь давайте посмотрим, что происходит, когда пользователь отправляет запрос Claude.

28:49

Speaker A

И три вещи происходят параллельно.

28:51

Speaker A

Первые две - это Memory MD и Claude MD.

28:55

Speaker A

Они уже загружены при старте нашей сессии.

28:59

Speaker A

И тут мы с вами ничего не ждём.

29:00

Speaker A

Но есть ещё третье.

29:02

Speaker A

О которой мы сказали вот здесь вот, когда говорили про Memory Prefetch.

29:08

Speaker A

И что же происходит интересного в этой фазе?

29:11

Speaker A

А тут у нас с вами дешёвая модель, для Claude - это будет Sonnet, она в фоне выбирает до пяти релевантных файлов.

29:19

Speaker A

При этом это не блокирующая операция.

29:22

Speaker A

Если вдруг он не успел их подобрать, значит, ответ произойдёт без него.

29:26

Speaker A

Если успел, то информация помещается в контекст.

29:31

Speaker A

И вот мы отправили всё это в нашу модель.

29:33

Speaker A

И она дала нам ответ.

29:36

Speaker A

И после ответа Claude в фоне запускает три процесса.

29:42

Speaker A

Первый - это агент записывает уроки.

29:46

Speaker A

Второй - это Session Memory.

29:48

Speaker A

Он обновляет заметки текущей сессии.

29:52

Speaker A

И последнее - это Team Memory.

29:54

Speaker A

Синхронизация с нашей командой, если мы работаем как команда с Claude Code.

29:59

Speaker A

И всё это происходит в фоне.

30:01

Speaker A

Поэтому пользователь уже видит ответ.

30:05

Speaker A

Но Claude Code делает что-то интересное с памятью.

30:08

Speaker A

И если посмотреть на всю архитектуру внимательно, то память никогда не стоит на пути ответа.

30:13

Speaker A

И сейчас мы с вами пройдёмся по каждому блоку по отдельности.

30:19

Speaker A

Итак, что же есть в нашей процедурной памяти?

30:23

Speaker A

Здесь у нас есть с вами наш Claude MD.

30:27

Speaker A

И это инструкция нашего проекта.

30:30

Speaker A

Но это не один файл, это четыре разных уровня.

30:34

Speaker A

Глобальный, пользовательский, проектный, локальный.

30:36

Speaker A

И ближе к рабочей директории, выше приоритет.

30:40

Speaker A

То есть проектный файл загружается последним.

30:44

Speaker A

Значит, он ближе к концу нашего сообщения.

30:47

Speaker A

Значит, модель уделяет ему больше внимания.

30:50

Speaker A

И получается, что здесь приоритет реализован не через условия в коде.

30:53

Speaker A

А через позицию в контекстном окне.

30:58

Speaker A

И это всё загружается один раз за сессию.

31:00

Speaker A

И результат кэшируется.

31:02

Speaker A

И у него есть лимит: 40.000 символов, 25 КБ.

31:07

Speaker A

Каждая строка - это ссылка на топик файл с описанием в одну фразу.

31:14

Speaker A

То есть здесь содержится не данные.

31:16

Speaker A

Здесь содержатся адреса данных.

31:18

Speaker A

Так вот, теперь, как же агент выбирает, какие файлы памяти нужны прямо сейчас?

31:23

Speaker A

При каждом сообщении пользователя в фоне запускается отдельный вызов.

31:27

Speaker A

Не основной модели, а дешёвой.

31:30

Speaker A

И для Claude - это у нас Sonnet.

31:33

Speaker A

Даже если пользователь работает с Opus, зачем тратить дорогую модель для того, чтобы просмотреть наш манифест?

31:39

Speaker A

Так вот, эта модель получает текст запроса, манифест всех файлов памяти и одна строка на файл.

31:46

Speaker A

Только метаданные.

31:48

Speaker A

И список инструментов, которые агент уже использует.

31:51

Speaker A

Содержимое файлов он не видит.

31:53

Speaker A

И принимает решение только по описаниям.

31:57

Speaker A

И тут промт оптимизирован на точность, а не на полноту.

32:00

Speaker A

И там есть инструкции: только если уверен, если сомневаешься, не включай.

32:05

Speaker A

Можешь вернуть пустой список.

32:07

Speaker A

Философия простая: лучше не вспомнить, чем засорить контекст.

32:09

Speaker A

И эта выборка точечная.

32:12

Speaker A

Не все там 200 файлов мы засунем в контекст, а только те, которые нужны.

32:18

Speaker A

И выбираем их по описаниям того, что здесь есть.

32:21

Speaker A

И опять же, как я говорил ранее, этот префеч не блокирует ответ.

32:24

Speaker A

Если вдруг он не успел или что-то пошло не так, то у нас запрос идёт без дополнительной памяти.

32:29

Speaker A

Итак, наш семантик: данные, которые у нас уже существуют.

32:32

Speaker A

И префеч их находит и подставляет.

32:35

Speaker A

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

32:40

Speaker A

И кто решает, что вот этот кусок разговора стоит запомнить, а вот это мусор, он нам не нужен?

32:46

Speaker A

Так вот, помните, эпизодик Memory, о которой мы сказали, что это самый недооценённый тип.

32:50

Speaker A

Claude Code это подтверждает.

32:52

Speaker A

Они построили отдельного агента только для этого.

32:55

Speaker A

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

33:02

Speaker A

Отдельный процесс с ограниченными правилами.

33:06

Speaker A

Он видит весь разговор, полный контекст, включая System Prompt, инструкции, историю.

33:10

Speaker A

Но промт говорит ему: обрати внимание на последние N сообщений.

33:13

Speaker A

Только те, что появились после прошлого извлечения.

33:16

Speaker A

Зачем нам весь контекст, если мы смотрим только новое?

33:18

Speaker A

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

33:25

Speaker A

Но здесь есть ограничения.

33:27

Speaker A

Максимум пять итераций, чтобы фоновый агент не ушёл в бесконечный цикл.

33:32

Speaker A

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

33:36

Speaker A

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

33:42

Speaker A

Также есть интересный момент - курсор.

33:45

Speaker A

Каждая успешная экстракция сдвигает курсор.

33:50

Speaker A

Идентификатор последнего обработанного сообщения.

33:54

Speaker A

Следующая экстракция начинается именно с этого места.

33:56

Speaker A

И если вдруг что-то не получилось, то курсор у нас не двигается.

34:00

Speaker A

И эти сообщения будут рассмотрены снова.

34:02

Speaker A

И ничего не потеряется.

34:04

Speaker A

Это тот же принцип at least once.

34:07

Speaker A

Что в любой очереди сообщений.

34:10

Speaker A

И Anthropic перенесли его в архитектуру памяти агента.

34:14

Speaker A

Помните нашу схему: действие, контекст, результат, урок.

34:17

Speaker A

Это именно она уже в продакшене.

34:19

Speaker A

Только вместо простой структуры фоновый агент с ограниченными правами, жёсткими лимитами итерациями и курсорами.

34:25

Speaker A

Который не пропускает неудачи.

34:27

Speaker A

Принципы абсолютно те же.

34:30

Speaker A

Следующая подсистема - это Session Memory.

34:32

Speaker A

Отдельный файл заметок на каждую сессию.

34:35

Speaker A

Решения, изменённые файлы, замеченные паттерны.

34:39

Speaker A

И это не логирование, это как рефлексия.

34:41

Speaker A

Данные собираются.

34:43

Speaker A

Данные извлекаются.

34:44

Speaker A

И данные записываются в фоне.

34:46

Speaker A

И кажется, что Claude собирает столько всего.

34:50

Speaker A

Как же он сделает так, чтобы наше контекстное окно с вами не лопнуло?

34:55

Speaker A

Кто же следит за тем, чтобы вся память не съела весь бюджет?

35:01

Speaker A

И тут нам надо посмотреть, как устроена рабочая память.

35:04

Speaker A

То, что мы используем здесь сейчас.

35:08

Speaker A

И у Claude реализовано пять уровней сжатия контекста.

35:13

Speaker A

И на первом уровне сжатия контекста мы пропускаем уже сумаризированные сообщения.

35:18

Speaker A

А это значит, что нам здесь делать ничего не надо.

35:20

Speaker A

Второй - это бюджет на результаты инструментов.

35:24

Speaker A

И он установлен в 200.000 символов на сообщение.

35:27

Speaker A

Если вдруг превысили, то самые крупные результаты уходят на диск.

35:33

Speaker A

Модель видит первые 2 КБ плюс путь к полному файлу.

35:37

Speaker A

И вот дальше решение: заменить или вставить.

35:40

Speaker A

Замораживается навсегда.

35:42

Speaker A

Потому что мутировать уже отправленное, значит, убить наш KV кэш.

35:47

Speaker A

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

35:50

Speaker A

Вот тут вот у нас есть реализация.

35:52

Speaker A

Третья часть - это удалить самые старые сообщения.

35:56

Speaker A

Четвёртый - это микрокомпакт.

36:00

Speaker A

И тут у нас есть два пути.

36:02

Speaker A

И они зависят от состояния кэша.

36:04

Speaker A

Если кэш протух, то можно мутировать прямо: заменяем старые результаты на заглушку.

36:09

Speaker A

Ни одного вызова модели не происходит.

36:12

Speaker A

Если же кэш живой, то мутировать нельзя.

36:15

Speaker A

Вместо этого через API отправляем инструкцию.

36:19

Speaker A

Удалить содержимое вот этих результатов из кэша.

36:22

Speaker A

И сервер удаляет данные, не инвадируя весь кэш.

36:25

Speaker A

И у обоих этих путей одна цель.

36:28

Speaker A

Защитить KV кэш.

36:31

Speaker A

И это как сквозной принцип.

36:33

Speaker A

И пятое - это автокомпакт.

36:37

Speaker A

Это очень тяжёлая операция.

36:39

Speaker A

Здесь фоновый агент сумаризирует всё.

36:43

Speaker A

И в нём есть предохранитель.

36:46

Speaker A

Три неудачных сжатия подряд, и система останавливается.

36:50

Speaker A

И это ограничители в коде, а не в промте.

36:52

Speaker A

Также есть резерв на сумаризацию.

36:54

Speaker A

20.000 токенов.

36:56

Speaker A

Если мы посмотрим на эти типы сжатия, то это очень похоже на наш пайплайн.

37:00

Speaker A

Сначала у нас идут дешёвые операции.

37:04

Speaker A

И каждая последующая операция дороже.

37:07

Speaker A

То есть мы с вами максимально оптимизируемся по деньгам.

37:13

Speaker A

Что же мы с вами видим на примере Claude?

37:16

Speaker A

И здесь интеллект агента не в модели, и не в технологии хранения, а в архитектуре.

37:22

Speaker A

Что запоминать, когда доставлять, сколько тратить.

37:26

Speaker A

И когда остановиться.

37:28

Speaker A

Вот Claude Code - это 2,5 млрд выручки.

37:31

Speaker A

11 подсистем памяти, файлы с грепом.

37:35

Speaker A

Потому что правильная архитектура памяти важнее стека.

37:39

Speaker A

Но также красивая архитектура без защиты может быть дырявой.

37:43

Speaker A

Без отказоустойчивости.

37:45

Speaker A

Один сбой API, и всё мертво.

37:49

Speaker A

Без наблюдаемости мы летим вслепую и не знаем, куда деваются наши деньги.

37:54

Speaker A

И что вообще происходит с агентом.

37:56

Speaker A

В третьей части будет продакшн: безопасность, отказоустойчивость.

38:00

Speaker A

И многое другое.

38:01

Speaker A

Ссылка на первую часть в описании.

38:03

Speaker A

До встречи в финале.

Topics: агенты языковые модели роутинг управление контекстом RAG кэширование оптимизация затрат классификатор запросов длинный контекст инфраструктура ИИ

Учить по этому видео

- [Карточки по этому видео](https://sozai.app/ru/tools/ai-flashcard-generator/?from=transcript&id=18318)
- [Тест по этому видео](https://sozai.app/ru/tools/quiz-generator/?from=transcript&id=18318)

Бесплатно, составлено ИИ по этой расшифровке. Без регистрации.


---
This is the markdown twin of https://sozai.app/transcript/youtube-video-transcript-89/ — the same content, without the markup.
Published by SozAI (https://sozai.app). Reuse and quotation are allowed with attribution and a link back.
Machine-readable index: https://sozai.app/llms.txt · data API: https://sozai.app/api/