Speaker A
3 доллара, столько стоит одна задача, и я агент, если отправлять каждый запрос на фронтир модель с полным контекстом.
Дмитрий Березинский рассказывает о важности роутинга и управления контекстом для оптимизации работы агентов на базе языковых моделей.
Key Takeaways
- Роутинг моделей позволяет существенно снизить стоимость запросов без значительной потери качества.
- Управление контекстом и правильный выбор модели важнее, чем использование только самой дорогой фронтир модели.
- Кэширование и наблюдаемость критичны для эффективной работы агентов и контроля затрат.
- Для актуализации знаний модели необходимы внешние источники данных, такие как RAG или большие контекстные окна.
- Инженерный подход к выбору между RAG и длинным контекстом зависит от конкретных требований и ресурсов.
Summary
- Стоимость запросов к фронтир модели может быть очень высокой, что требует оптимизации.
- Интеллект агента заключается не только в модели, но и в инфраструктуре вокруг неё: роутинг, ретривол и управление контекстом.
- Роутинг позволяет выбирать между дорогими и дешевыми моделями, снижая затраты при сохранении качества.
- Классификатор запросов решает, какую модель вызвать, что помогает экономить и улучшать качество.
- Важно учитывать особенности кэша при переключении моделей, чтобы не потерять эффективность.
- Наблюдаемость и метрики необходимы для контроля качества роутинга и затрат.
- Модель без актуальных знаний ограничена датой обучения, поэтому нужны внешние источники данных.
- Retrieval-Augmented Generation (RAG) — подход с использованием векторных баз для подстановки релевантных фрагментов в контекст.
- Альтернативный подход — использование очень больших контекстных окон для загрузки всей информации напрямую.
- Выбор между RAG и длинным контекстом зависит от сложности задачи и технических возможностей.
Full Transcript — Download SRT & Markdown
Speaker A
3 доллара, кажется, мелочь, агент делает 10 вызовов за задачу, 1000 задач в день.
Speaker A
90.000 в месяц, и мы с вами платим за каждый токен, за каждый кусок текста, который запихнули в контекстное окно, за каждую итерацию цикла, где это контекстное окно пересчитывается заново.
Speaker A
А значит, нам критически важно понимать, что именно помещать в это окно, какую модель вызывать, дорогую или дешёвую, что достать из памяти, всё или только нужное, как не раздуть контекст до потолка, и когда агенту стоит думать глубоко, а когда хватит быстрого ответа.
Speaker A
Всем привет, меня зовут Дмитрий Березинский, и это вторая часть серии Анатомия агентов, первый мы вскрыли скелет, пайплайн, контекст, циклы, инструменты, сегодня мозг.
Speaker A
Ну что, поехали?
Speaker A
Ключевой тезис этой части: интеллект агента не в модели, а в инфраструктуре вокруг модели, правильный роутинг, точечный ретривол и управление контекстом, и это важнее, чем фронтир модель.
Speaker A
Сейчас же разберёмся, почему, и начнём мы с вами с роутинга.
Speaker A
Сколько моделей доступно на рынке?
Speaker A
Десятки, сотни, и каждый месяц появляются новые.
Speaker A
А цены отличаются не на проценты, в разы, дешёвая модель и дорогая, разница может быть в 30, 50, 100 раз за один и тот же запрос.
Speaker A
И какой же выбрать?
Speaker A
Кажется, что ответ подороже, чтобы она точно работала и хорошо отвечала.
Speaker A
И шлём мы туда все запросы подряд.
Speaker A
Сколько сахара добавить в кофе?
Speaker A
Отправляем дорогую модель.
Speaker A
Рефакторинг архитектуры?
Speaker A
Тоже отправляем дорогую модель.
Speaker A
Вернёмся к нашему примеру бариста, который у нас проходит через серию всех наших видео.
Speaker A
Сколько стоит латте?
Speaker A
Это обычный лукап, и дешёвая модель ответит быстро и качественно.
Speaker A
А вот проанализируй предпочтения команды за 3 месяца, составь заказ на ретро с учётом аллергии, бюджета и погоды.
Speaker A
Вот это уже сложный запрос, и возможно, его стоит отправить фронтир модели.
Speaker A
Зачем же за них платить одинаково?
Speaker A
Идея простая: маленький классификатор смотрит на запрос и решает.
Speaker A
Отправить на дорогую модель или на дешёвую.
Speaker A
Это как сортировщик на почте.
Speaker A
Взвесил, посмотрел адрес и отправил уже в нужное окно.
Speaker A
Исследователи из Беркли формализовали это в роутер LLM, это Open Source Framework.
Speaker A
Результат - снижение стоимости более чем вдвое при сохранении 95% качества.
Speaker A
И здесь можно задуматься, ну ладно, роутинг - это понятно.
Speaker A
Но дешёвая же модель, она глупее, и качество у нас очень сильно упадёт, и эти 5% для нас важны.
Speaker A
Но здесь нам надо уже понимать, что для нас важно.
Speaker A
Дать вот это максимальное качество или, возможно, всё-таки попасть в нужный бюджет и сэкономить деньги.
Speaker A
И казалось бы, что такого сложного в роутинге?
Speaker A
Давайте разбираться.
Speaker A
Как его реализовать для нашего с вами агента?
Speaker A
Итак, у нас есть с вами наш запрос.
Speaker A
Какие же дальше у нас с ним будут происходить шаги?
Speaker A
Давайте посмотрим, что нам надо сделать первым.
Speaker A
На этом этапе мы смотрим на тип входящих данных, что же к нам приходит: картинки, аудио или просто текст.
Speaker A
И на основе этого мы сразу же можем отсеять часть моделей, либо включить те, которые смогут работать с этим типом контента.
Speaker A
Дальше, шаг второй.
Speaker A
Шаг второй - модель классификатор.
Speaker A
Здесь у нас может быть с вами небольшая модель или модель подороже, или вообще мы можем с вами оттюнить модель на наших данных.
Speaker A
Всё зависит от того, что мы можем туда поставить.
Speaker A
Основная её цель - это возвращать ту, какую модель дальше вызвать.
Speaker A
Ну и шаг третий.
Speaker A
Это будет фулбек.
Speaker A
Если что-то не так произошло на втором шаге, у нас модель не уложилась по времени, или вернула какой-то непонятный ответ, или не смогла определиться.
Speaker A
То здесь мы можем с вами сделать простые правила по ключевым словам.
Speaker A
Это как запасной генератор: не очень красиво, шумно, но свет есть.
Speaker A
Также мы можем сюда поставить просто выбор модели по умолчанию.
Speaker A
И как мы видим, у нас есть две детерминированные части.
Speaker A
И одна недетерминированная - наш классифаер.
Speaker A
И для него мы как раз-таки должны дать описание всех тех моделей, на которые он будет смотреть и выбирать.
Speaker A
Поэтому на основе входящего запроса наш классифаер должен определить, какая же модель для него подходит.
Speaker A
И качество описания этих моделей, оно напрямую влияет на качество нашего с вами роутинга.
Speaker A
И казалось бы, этот роутинг нужен для того, чтобы экономить, выбирать дорогую или более дешёвую модель.
Speaker A
Но если мы с вами приходим к каким-то сложным агентам, у нас могут быть специализированные модели под определённые задачи.
Speaker A
Может, мы сделали файн-тюнинг или определили, что разные модели по-разному работают.
Speaker A
С определёнными запросами, и как раз-таки в этом случае наш классифаер даст нам не только экономию.
Speaker A
Ну и, возможно, увеличение качества за счёт выбора правильной модели под конкретный запрос.
Speaker A
Но есть один нюанс, который часто не рассматривают.
Speaker A
Когда думают о том, что будут использовать роутер.
Speaker A
И это самый настоящий подводный камень.
Speaker A
Когда наш роутер переключает наши модели, то нам надо с вами понимать.
Speaker A
А есть ли у нас с вами сейчас кэш?
Speaker A
Может быть, у нас идёт довольно-таки длинный диалог с пользователем, и сейчас мы кэш очень эффективно используем.
Speaker A
И наши запросы уже экономически эффективны.
Speaker A
Так вот, у разных провайдеров это может работать по-разному.
Speaker A
Где-то этот кэш автоматически, где-то его надо включить через API и платить за это.
Speaker A
И время жизни при этом у кэша разное.
Speaker A
Но принцип здесь один: если вы переключили модель посреди диалога, кэш предыдущий может быть потерян.
Speaker A
А может, переключение на более дешёвую модель с учётом кэша дорогой теперь стоит дороже.
Speaker A
И это значит, не делать роутер.
Speaker A
Это значит, что вам надо считать и смотреть, как и когда вы можете переключать.
Speaker A
И здесь есть пересечение с первой частью.
Speaker A
Помните, мы закончили на наблюдаемости.
Speaker A
Без неё наш роутинг слепой.
Speaker A
И вы не знаете, правильно ли наш классификатор выбрал модель?
Speaker A
Сколько стоит средний запрос на каждую модель?
Speaker A
Сколько мы теряем на переключениях кэша?
Speaker A
Роутинг без метрик - это надежда, но не инженерия.
Speaker A
Поэтому наблюдайте за каждым выбором: какая модель, почему, сколько стоило, попали ли в кэш?
Speaker A
Без этого будет тяжело добиться хорошего качества.
Speaker A
Роутинг выбирает модель.
Speaker A
Но модель без знаний - это как у нас врач без карты пациента.
Speaker A
Он, скорее всего, умный.
Speaker A
Очень хочется в это верить.
Speaker A
Но каждый раз, когда вы с ним общаетесь, он не знает, что же у вас там было.
Speaker A
Так вот, откуда наш агент берёт знания?
Speaker A
Давайте вспомним, что наши языковые модели, они заморожены во времени.
Speaker A
Они знают всё о мире до даты обучения, и ничего о том, что произошло недавно.
Speaker A
Ничего о ваших внутренних документах, вашей кодовой базе, ваших клиентах.
Speaker A
И если вы хотите, чтобы агент знал что-то конкретное, вам нужно эти знания до него доставить.
Speaker A
И здесь вопрос: как?
Speaker A
Здесь у нас есть с вами несколько интересных мнений.
Speaker A
И первое - это рак.
Speaker A
Retrieval-Augmented Generation.
Speaker A
Это инженерный подход, когда мы нарезаем документы на фрагменты, превращаем векторы, складываем в базу.
Speaker A
И когда пользователь спрашивает, ищем релевантные фрагменты и подставляем в контекст.
Speaker A
Модель видит не всё, только то, что мы с вами нашли.
Speaker A
И второй подход - это длинные контексты.
Speaker A
Берём документы и запихиваем целиком в контекстное окно.
Speaker A
Без базы, без эмбедингов, без поисков.
Speaker A
Просто модель сама разбирается.
Speaker A
У неё же миллионы токенов.
Speaker A
Она же справится.
Speaker A
И это тот выбор, перед которым мы часто с вами стоим.
Speaker A
Давайте разберёмся, нужен ли нам с вами рак или всё-таки длинный контекст сейчас решает все проблемы.
Speaker A
С чего же начались все эти обсуждения?
Speaker A
А с того, что сейчас контекстные окна стали огромными.
Speaker A
Мы можем с вами засовывать туда миллион токенов.
Speaker A
Это 700.000 слов.
Speaker A
То есть туда влезает вся серия томов Властелин колец, и ещё хоббит к ней в придачу, и останется место.
Speaker A
И зачем же тогда нам нужен весь этот рак стек?
Speaker A
Все эти чанки, эмбединги, векторные базы, различные подходы, технологии для того, чтобы всё это качественно выбирать, тестировать, смотреть.
Speaker A
Это невероятно сложно.
Speaker A
Если же мы можем просто запихнуть всё в контекстное окно.
Speaker A
И это очень интересный вопрос, над которым стоит задуматься.
Speaker A
И давайте подойдём к этому инженерно.
Speaker A
Рассмотрим плюсы, минусы разных подходов, поймём, какие у нас есть трейдофы и там, и там, и что же мы можем с вами использовать.
Speaker A
И первое, почему мы будем оценивать - это простота.
Speaker A
Итак, рак с точки зрения простоты, он невероятно сложен, потому что нам надо с вами развернуть специализированные базы данных.
Speaker A
Выбрать стратегии того, как же мы будем нарезать эти данные.
Speaker A
Понять, какие модели для эмбедингов подходят, может быть, нам надо их тюнить.
Speaker A
Потом сделать ранжирование, делать синхронизации, потом мы должны разобраться, как же нам получать максимально эффективно нужные данные из рага.
Speaker A
И это очень много различных движущихся частей.
Speaker A
Много мест, где что-то может сломаться.
Speaker A
А с точки зрения контекста, наш длинный контекст взял документ, положил в промт.
Speaker A
И всё.
Speaker A
Нету ни стека, ни поломок.
Speaker A
Нам не надо всё это разворачивать.
Speaker A
Мы просто работаем с контекстом.
Speaker A
И второе - это полнота предоставляемых данных.
Speaker A
Рак у нас ищет по математическим представлениям текста.
Speaker A
Иногда он может не находить, ответ у нас с вами был в данных, но модель его не увидела, потому что поиск наш промахнулся.
Speaker A
И здесь мы с вами даже не узнаем о том, что мы не поместили в контекст то, что у нас есть.
Speaker A
С длинным же контекстом всё наоборот.
Speaker A
Модель видит всё, и ей негде промахнуться.
Speaker A
Третий, который вытекает отсюда же.
Speaker A
Это у нас есть с вами иногда задачи, где нам нужна полная картина.
Speaker A
Допустим, у нас есть документ с требованиями и документ с релизными заметками.
Speaker A
И был вопрос: какие требования по безопасности пропущены в релизе?
Speaker A
Рак может найти фрагменты по безопасности в документах, но при этом он может что-то пропустить.
Speaker A
Для того, чтобы модель увидела всё, ей надо два документа целиком.
Speaker A
Поэтому в рак у нас возможен пропуск.
Speaker A
А контекст у нас с вами видит всё.
Speaker A
И это у нас довольно сильные аргументы в пользу контекста.
Speaker A
Если на этом остановиться, то можно вообще выкинуть рак и больше никогда его не использовать.
Speaker A
Но давайте посмотрим на экономику.
Speaker A
У нас есть с вами плата за перечитывание.
Speaker A
И это деньги.
Speaker A
Длинный контекст означает, что модель будет перечитывать все наши документы при каждом запросе.
Speaker A
И нам придётся платить за этот документ много раз: сегодня, завтра, послезавтра.
Speaker A
Всегда, когда мы будем использовать этот документ и помещать его в контекст.
Speaker A
Нам придётся платить за то, что модель будет его читать.
Speaker A
При этом рак платит за обработку документа один раз, в момент, когда мы его загрузили.
Speaker A
Да, вы скажете, кэширование документов снимает эту проблему.
Speaker A
Но это только для одной конкретной сессии.
Speaker A
Ведь эти документы мы будем использовать не один раз.
Speaker A
А множество сессий, множество запросов.
Speaker A
А значит, и кэш нам здесь с вами не помогает.
Speaker A
Следующий пункт назовём его игла в стоге сена.
Speaker A
И она нам говорит про качество на длинных контекстах.
Speaker A
Помните про Lost in the Middle из Стэнфорда?
Speaker A
Когда контекст растёт до сотен тысяч токенов, внимание модели размывается.
Speaker A
А это значит, что какой-то конкретный параграф в середине 2.000-страничного документа модель может его даже не заметить или начать галлюцинировать детали из окружающего текста.
Speaker A
Раньше в этом плане убирает стог сена и даёт модели только иголки.
Speaker A
А это значит, что здесь будет намного меньше шума и точнее ответ.
Speaker A
Да, новые модели значительно снизили выраженность этого эффекта, но его полностью пока не устранили.
Speaker A
А это значит, что нам надо с вами об этом продолжать думать.
Speaker A
И последнее, что мы с вами разберём - это масштаб.
Speaker A
Миллион токенов звучит впечатляюще.
Speaker A
Но если ваша база знаний гигантская, это может быть терабайты, гигабайты, то попробуйте запихнуть её в это контекстное окно.
Speaker A
И это у нас с вами может не получиться.
Speaker A
Поэтому нам с вами нужен какой-то поисковый слой, который отфильтрует ненужное и оставит только то, что нам надо для конкретного запроса.
Speaker A
А это именно то, что делает наш с вами рак.
Speaker A
А это значит, для рага подходит, что мы можем сюда запихнуть любой объём нашей базы знаний.
Speaker A
При этом, когда у нас длинное контекстное окно, мы не можем сюда добавить всю нашу базу знаний.
Speaker A
Так что же нам с вами выбрать?
Speaker A
Рак или длинное контекстное окно?
Speaker A
Если у нас с вами ограниченный выбор документов и задача на глобальное рассуждение.
Speaker A
То это будет длинный контекст.
Speaker A
Если же у нас гигантская корпоративная база знаний, у нас тысячи документов, у нас динамические данные.
Speaker A
И у нас есть способность развернуть и поддерживать рак качественно.
Speaker A
То однозначно мы с вами выберем рак.
Speaker A
Но в реальности сейчас чаще всего мы объединяем и рак, и длинное контекстное окно.
Speaker A
Рак у нас с вами находит релевантное.
Speaker A
Длинное контекстное окно позволяет положить достаточно для рассуждений.
Speaker A
Поэтому в зависимости от ситуации, в которой мы находимся, мы можем выбирать одно, другое.
Speaker A
Или и то, и другое.
Speaker A
Мы можем взять лучшее из обоих миров.
Speaker A
И на этот счёт уже есть исследования, когда в контекстное окно запихивают всё, что только возможно.
Speaker A
Или добавляют туда нужные кусочки при помощи рага.
Speaker A
Тем самым контекстное окно уменьшается в этих исследованиях в четыре раза с рагом.
Speaker A
И как результат, 90% снижение задержки.
Speaker A
С 70 секунд с полным контекстным окном до полутора.
Speaker A
Но что же с качеством?
Speaker A
Авторы нам пишут: полный контекст даёт небольшое преимущество в точности.
Speaker A
Но при этом рак даёт нам конкурентное качество при меньших затратах и большей скорости.
Speaker A
Поэтому нам с вами надо будет взвешивать, что же для нас с вами важнее.
Speaker A
Из тех инструментов, которые мы можем использовать.
Speaker A
По поводу того, как устроен рак пайплайн, нарезка документов, эмбединги, векторные базы, поиск, я уже подробно разбирал в отдельном видео.
Speaker A
Ссылка будет в описании.
Speaker A
Здесь мы не будем повторяться и смотреть уже на конкретные техники.
Speaker A
Но есть и моменты, которые мы разбирали немного в прошлом видео, и те, которые часто забываются, когда мы используем с вами рак.
Speaker A
И первое - это обогащение запроса пользователя.
Speaker A
Если пользователь напишет нашему с вами баристе: а покрепче.
Speaker A
Это всего лишь два слова и никакого контекста.
Speaker A
Если мы с вами отправим этот запрос в наш рак, то, скорее всего, мы получим какой-то мусор.
Speaker A
Но если перед фазой рага мы поставим обогащение нашего запроса и посмотрим контекст предыдущего сообщения.
Speaker A
Или о чём вообще наш пользователь до этого общался.
Speaker A
То мы можем получить запрос.
Speaker A
Пользователь хочет более крепкий кофе.
Speaker A
Предыдущий заказ был капучино.
Speaker A
И теперь наш рак найдёт всё правильно.
Speaker A
И второй, не менее важный - это фидбек луп.
Speaker A
Это то, что делает рак живым.
Speaker A
То есть рак даёт нам с вами ответ.
Speaker A
Мы смотрим за реакцией пользователя.
Speaker A
И на основе реакции обновляем наши базы.
Speaker A
И это нам помогает давать более точный ответ в следующий раз.
Speaker A
Как на примере нашего бариста.
Speaker A
Если пользователь одобрил заказ, то вес предпочтения растёт.
Speaker A
Если же пользователь отклонил, то вес падает.
Speaker A
А если пользователь написал: я теперь предпочитаю чай.
Speaker A
То это у нас будет новая запись.
Speaker A
Но как же это реализовать?
Speaker A
И вот эта реакция пользователя, она у нас может идти как фоновый процесс, который обновляет наши базы.
Speaker A
Здесь главное - не блокировать нашего пользователя при работе с основным потоком.
Speaker A
Поэтому помните, что рак без обратной связи - это отличная база.
Speaker A
Рак с обратной связью - это уже обучающая система.
Speaker A
Но здесь возникает вопрос: рак даёт нам знания.
Speaker A
Но знания - это очень общее слово.
Speaker A
Какие именно?
Speaker A
Когда нам надо работать с этой реакцией?
Speaker A
Что вообще мы можем здесь делать?
Speaker A
Потому что предпочтения пользователей - это одно.
Speaker A
Уроки из прошлых ошибок - это другое.
Speaker A
Текущий контекст задачи - это третье.
Speaker A
У агента не одна память, их четыре.
Speaker A
Почему и какие они?
Speaker A
Давайте продолжать.
Speaker A
У нашего с вами агента есть память.
Speaker A
Отлично.
Speaker A
Но какая?
Speaker A
Ну, Memory.
Speaker A
Но какая конкретная?
Speaker A
Это как сказать, у компьютера есть хранилище.
Speaker A
Регистры процессора, оперативная память, SSD, облачный архив.
Speaker A
Четыре абсолютно разных типа с разным временем жизни и назначением.
Speaker A
У агента тоже четыре.
Speaker A
Эту классификацию формализовали исследователи из Принстона в фреймворке COALA Cognitive Architecture for Language Agents.
Speaker A
Сегодня её используют все основные фреймворки.
Speaker A
И каждый тип решает свою задачу.
Speaker A
Давайте разберём.
Speaker A
И первое у нас будет процедурная.
Speaker A
Процедурная память - это то, как делать.
Speaker A
Здесь будет наш системный промт плюс описание инструментов.
Speaker A
Это не база знаний, это инструкция.
Speaker A
Как должностная инструкция у нас с вами на работе.
Speaker A
И её обновляют осознанно между сессиями, не на лету.
Speaker A
Внутри сессии она стабильна.
Speaker A
Итак, инструкция у нас с вами есть.
Speaker A
Но откуда агент знает факт, кто что любит, что написано в документации?
Speaker A
Какая у клиента политика возврата?
Speaker A
И это будет семантическая память.
Speaker A
И это то, что знает наш агент.
Speaker A
Здесь как раз-таки и будет наш с вами рак.
Speaker A
Это долгосрочные знания, которые обновляются по мере поступления новых.
Speaker A
Поэтому для нашего агента баристы то, что кто-то любит капучино, кто-то любит на овсяном молоке, а кто-то пьёт чай.
Speaker A
Или для нашей разработки у нас может быть прописано, что микросервис платежей у нас написан на чистой архитектуре, на стеке Go с использованием определённых баз данных.
Speaker A
Как аналог - это справочник.
Speaker A
И он не статичный, он живой, который постоянно пополняется и корректируется.
Speaker A
Факты у нас теперь с вами есть.
Speaker A
Давайте вернёмся к нашему агенту баристе и подумаем, а кто же учит нашего агента на ошибках?
Speaker A
Справочник нам говорит, что Костя любит латте.
Speaker A
А кто помнит, что в прошлый вторник забыли его аллергию на орехи?
Speaker A
И у нас был с вами инцидент.
Speaker A
И в этом нам с вами поможет эпизодическая память.
Speaker A
Это то, что было, это конкретные эпизоды с результатами.
Speaker A
И это самый недооценённый тип.
Speaker A
В индустрии очень часто его игнорируют.
Speaker A
Как пример, LangChain.
Speaker A
Они именно так и пишут: единственный тип памяти из COALA, который у нас отсутствует - это эпизодик.
Speaker A
И поэтому большинство продакшн систем.
Speaker A
Особенно, которые работают на LangChain, они его не реализуют.
Speaker A
А зря.
Speaker A
Как наш пример.
Speaker A
Наш бариста забыл про аллергию.
Speaker A
У нас произошёл инцидент.
Speaker A
Была жалоба.
Speaker A
Может быть, мы потеряли репутацию или деньги.
Speaker A
А может быть, ваш кодинг агент, который проводил рефакторинг всего модуля, всё сделал неправильно, откатил, что-то сломал.
Speaker A
И после этого вы ему сказали: блин, ну ты же должен был всё делать через интерфейсы.
Speaker A
И этот подход сработал.
Speaker A
Так вот, чтобы в следующий раз он тоже сработал, у него должно быть знание об этом.
Speaker A
Поэтому это у нас как дневник с уроками.
Speaker A
Как мы с вами это можем реализовать?
Speaker A
У нас есть с вами различные записи.
Speaker A
В них есть действие, контекст, результат и урок.
Speaker A
И перед действием, которое хочет совершить агент, он спрашивает наше хранилище.
Speaker A
Были ли проблемы с похожими действиями раньше?
Speaker A
И если мы нашли негативный эпизод, то мы добавляем его в контекст как предупреждение.
Speaker A
Ну и, соответственно, после следующего действия мы опять записываем результат.
Speaker A
То есть у нас с вами появляется два дополнительных действия.
Speaker A
Каждый раз чтение перед действием и запись после.
Speaker A
Понятно, что здесь у нас будет с вами накапливаться знания.
Speaker A
И нам надо будет реализовать забывание.
Speaker A
Здесь ровно так же, как проблема работы с кэшом.
Speaker A
Когда же нам его инвадировать?
Speaker A
И здесь мы можем проставлять веса нашим знаниям или придумывать другие алгоритмы вытеснения.
Speaker A
Поэтому, чтобы каждый день у нас не было одних и тех же ошибок.
Speaker A
Чтобы мы не начинали с чистого листа.
Speaker A
Мы используем этот тип памяти.
Speaker A
А это значит, что теперь все уроки у нас будут запомнены.
Speaker A
Но что агент знает прямо сейчас?
Speaker A
В конкретной задаче, в конкретном диалоге.
Speaker A
И для этого нам с вами поможет рабочая память.
Speaker A
И это то, что прямо сейчас.
Speaker A
Контекст текущей задачи.
Speaker A
Возвращаемся к нашему баристе.
Speaker A
Пять человек, ретро через час, стресс после хотфикса.
Speaker A
Минус 15 у нас на улице.
Speaker A
И эта память живёт, пока задача активна.
Speaker A
Потом она нам не нужна.
Speaker A
Она уничтожается.
Speaker A
То есть это у нас будет как оперативная память.
Speaker A
И она у нас с вами временная.
Speaker A
Итак, у нас с вами есть четыре типа.
Speaker A
Это четыре жизненных цикла.
Speaker A
Процедурная, она у нас меняется редко между сессиями.
Speaker A
Семантическая обновляется по мере поступления новых данных.
Speaker A
Эпизодическая содержит инсайты из того, что мы с вами делали.
Speaker A
И рабочая, она у нас живёт, пока жива наша задача, которую мы выполняем.
Speaker A
Выглядит как очень красивая модель.
Speaker A
Но строит ли кто-то так в реальности?
Speaker A
Или это просто академическая классификация из научных работ?
Speaker A
И это всё очень избыточно для нашего продакшена, для наших агентов.
Speaker A
Так вот, ответ на этот вопрос пришёл буквально вчера.
Speaker A
31 марта этого года Anthropic выпускает очередную версию Claude Code, и это был их рутинный релиз.
Speaker A
Кто-то забыл добавить одну строчку в конфигурации сборки, одну, и весь исходный код стал доступен.
Speaker A
500.000 строчек кода, и там было всё.
Speaker A
Система инструментов, оркестрация, промты, и самое для нас интересное в разрезе нашего сегодняшнего диалога.
Speaker A
Полная архитектура памяти.
Speaker A
Да, Anthropic через час нашёл эту проблему, через три на GitHub зеркала с этой утечкой уже набирали десятки тысяч звёзд.
Speaker A
При этом Anthropic подтвердил, что это ошибка упаковки, не взлом.
Speaker A
Я подробно изучил их архитектуру, чтобы понять, как устроены продакшн системы лидеров рынка.
Speaker A
Конечно, мы не будем показывать код, потому что это интеллектуальная собственность Anthropic.
Speaker A
Но архитектурные решения, давайте разберём.
Speaker A
Потому что это продукт с выручкой.
Speaker A
2,5 млрд долларов в год.
Speaker A
Это не прототип, не демо, это система, которой пользуются миллионы разработчиков.
Speaker A
Многие издания написали, что это трёхслойная архитектура памяти.
Speaker A
В реальности, когда я посмотрел на код, я обнаружил, что там 11 подсистем, 11, и они идеально ложатся на нашу модель из четырёх типов.
Speaker A
Давайте посмотрим на карту целиком.
Speaker A
Проведём через него запрос пользователя и посмотрим, что происходит в памяти.
Speaker A
А для этого нам надо посмотреть, что попадает в контекстное окно.
Speaker A
Что увидит модель?
Speaker A
И наша с вами задача будет понять, как память попадает внутрь.
Speaker A
И здесь у нас контекстное окно разделено на две зоны.
Speaker A
Статическая.
Speaker A
В ней у нас будут правила поведения, стиль, инструкции по инструментам.
Speaker A
Она будет одинакова для всех наших запросов.
Speaker A
И она кэшируется глобально.
Speaker A
И вторая часть - динамическая.
Speaker A
И здесь у нас будет память, окружение, язык.
Speaker A
И у каждого это будет своя.
Speaker A
Зачем так надо?
Speaker A
Сейчас мы с вами разберём.
Speaker A
Но мы можем запомнить, что Memory MD живёт именно здесь, в динамической части.
Speaker A
Следующая часть динамической памяти.
Speaker A
Всем нам с вами знакомый файл.
Speaker A
Claude MD.
Speaker A
И здесь у нас с вами будут инструкции нашего проекта.
Speaker A
И метасообщения перед историей.
Speaker A
Дальше, если наш контекст раздулся и произошёл компакшн.
Speaker A
То здесь будет компакт саммари.
Speaker A
Который будет заменять собой все наши старые сообщения.
Speaker A
Это сжатие нашего контекста.
Speaker A
Дальше у нас с вами пойдёт история разговора.
Speaker A
И результаты работы инструментов.
Speaker A
И в самом низу у нас будет Memory Attachments.
Speaker A
Это файлы, которые дешёвая модель выбрала в фоне для того, чтобы наполнить наш контекст дополнительной информацией.
Speaker A
Заметьте порядок.
Speaker A
Статическая инструкция самого верха.
Speaker A
Динамическая память внизу.
Speaker A
Помните Lost in the Middle?
Speaker A
Самое важное в начале и в конце.
Speaker A
Середина - это история и результаты инструментов.
Speaker A
Это не случайно.
Speaker A
Это попытка максимально эффективно использовать те модели, которые доступны прямо сейчас.
Speaker A
Теперь давайте посмотрим, что происходит, когда пользователь отправляет запрос Claude.
Speaker A
И три вещи происходят параллельно.
Speaker A
Первые две - это Memory MD и Claude MD.
Speaker A
Они уже загружены при старте нашей сессии.
Speaker A
И тут мы с вами ничего не ждём.
Speaker A
Но есть ещё третье.
Speaker A
О которой мы сказали вот здесь вот, когда говорили про Memory Prefetch.
Speaker A
И что же происходит интересного в этой фазе?
Speaker A
А тут у нас с вами дешёвая модель, для Claude - это будет Sonnet, она в фоне выбирает до пяти релевантных файлов.
Speaker A
При этом это не блокирующая операция.
Speaker A
Если вдруг он не успел их подобрать, значит, ответ произойдёт без него.
Speaker A
Если успел, то информация помещается в контекст.
Speaker A
И вот мы отправили всё это в нашу модель.
Speaker A
И она дала нам ответ.
Speaker A
И после ответа Claude в фоне запускает три процесса.
Speaker A
Первый - это агент записывает уроки.
Speaker A
Второй - это Session Memory.
Speaker A
Он обновляет заметки текущей сессии.
Speaker A
И последнее - это Team Memory.
Speaker A
Синхронизация с нашей командой, если мы работаем как команда с Claude Code.
Speaker A
И всё это происходит в фоне.
Speaker A
Поэтому пользователь уже видит ответ.
Speaker A
Но Claude Code делает что-то интересное с памятью.
Speaker A
И если посмотреть на всю архитектуру внимательно, то память никогда не стоит на пути ответа.
Speaker A
И сейчас мы с вами пройдёмся по каждому блоку по отдельности.
Speaker A
Итак, что же есть в нашей процедурной памяти?
Speaker A
Здесь у нас есть с вами наш Claude MD.
Speaker A
И это инструкция нашего проекта.
Speaker A
Но это не один файл, это четыре разных уровня.
Speaker A
Глобальный, пользовательский, проектный, локальный.
Speaker A
И ближе к рабочей директории, выше приоритет.
Speaker A
То есть проектный файл загружается последним.
Speaker A
Значит, он ближе к концу нашего сообщения.
Speaker A
Значит, модель уделяет ему больше внимания.
Speaker A
И получается, что здесь приоритет реализован не через условия в коде.
Speaker A
А через позицию в контекстном окне.
Speaker A
И это всё загружается один раз за сессию.
Speaker A
И результат кэшируется.
Speaker A
И у него есть лимит: 40.000 символов, 25 КБ.
Speaker A
Каждая строка - это ссылка на топик файл с описанием в одну фразу.
Speaker A
То есть здесь содержится не данные.
Speaker A
Здесь содержатся адреса данных.
Speaker A
Так вот, теперь, как же агент выбирает, какие файлы памяти нужны прямо сейчас?
Speaker A
При каждом сообщении пользователя в фоне запускается отдельный вызов.
Speaker A
Не основной модели, а дешёвой.
Speaker A
И для Claude - это у нас Sonnet.
Speaker A
Даже если пользователь работает с Opus, зачем тратить дорогую модель для того, чтобы просмотреть наш манифест?
Speaker A
Так вот, эта модель получает текст запроса, манифест всех файлов памяти и одна строка на файл.
Speaker A
Только метаданные.
Speaker A
И список инструментов, которые агент уже использует.
Speaker A
Содержимое файлов он не видит.
Speaker A
И принимает решение только по описаниям.
Speaker A
И тут промт оптимизирован на точность, а не на полноту.
Speaker A
И там есть инструкции: только если уверен, если сомневаешься, не включай.
Speaker A
Можешь вернуть пустой список.
Speaker A
Философия простая: лучше не вспомнить, чем засорить контекст.
Speaker A
И эта выборка точечная.
Speaker A
Не все там 200 файлов мы засунем в контекст, а только те, которые нужны.
Speaker A
И выбираем их по описаниям того, что здесь есть.
Speaker A
И опять же, как я говорил ранее, этот префеч не блокирует ответ.
Speaker A
Если вдруг он не успел или что-то пошло не так, то у нас запрос идёт без дополнительной памяти.
Speaker A
Итак, наш семантик: данные, которые у нас уже существуют.
Speaker A
И префеч их находит и подставляет.
Speaker A
Но кто-то же должен создать эти данные, кто-то должен положить их туда для того, чтобы мы их могли проанализировать.
Speaker A
И кто решает, что вот этот кусок разговора стоит запомнить, а вот это мусор, он нам не нужен?
Speaker A
Так вот, помните, эпизодик Memory, о которой мы сказали, что это самый недооценённый тип.
Speaker A
Claude Code это подтверждает.
Speaker A
Они построили отдельного агента только для этого.
Speaker A
После каждого финального ответа, когда модель закончила и нет никаких ожидающих вызовов, инструмент запускает фоновый агент.
Speaker A
Отдельный процесс с ограниченными правилами.
Speaker A
Он видит весь разговор, полный контекст, включая System Prompt, инструкции, историю.
Speaker A
Но промт говорит ему: обрати внимание на последние N сообщений.
Speaker A
Только те, что появились после прошлого извлечения.
Speaker A
Зачем нам весь контекст, если мы смотрим только новое?
Speaker A
Потому что, чтобы решить, стоит ли запомнить, что кто-то у нас аллергик или что-то произошло, нам надо знать информацию по всему диалогу, по контексту.
Speaker A
Но здесь есть ограничения.
Speaker A
Максимум пять итераций, чтобы фоновый агент не ушёл в бесконечный цикл.
Speaker A
Также ограниченные права: может читать код, но писать может только в директорию памяти.
Speaker A
И последнее: если основной агент уже записал что-то в память на этом ходу, фоновый не запускается.
Speaker A
Также есть интересный момент - курсор.
Speaker A
Каждая успешная экстракция сдвигает курсор.
Speaker A
Идентификатор последнего обработанного сообщения.
Speaker A
Следующая экстракция начинается именно с этого места.
Speaker A
И если вдруг что-то не получилось, то курсор у нас не двигается.
Speaker A
И эти сообщения будут рассмотрены снова.
Speaker A
И ничего не потеряется.
Speaker A
Это тот же принцип at least once.
Speaker A
Что в любой очереди сообщений.
Speaker A
И Anthropic перенесли его в архитектуру памяти агента.
Speaker A
Помните нашу схему: действие, контекст, результат, урок.
Speaker A
Это именно она уже в продакшене.
Speaker A
Только вместо простой структуры фоновый агент с ограниченными правами, жёсткими лимитами итерациями и курсорами.
Speaker A
Который не пропускает неудачи.
Speaker A
Принципы абсолютно те же.
Speaker A
Следующая подсистема - это Session Memory.
Speaker A
Отдельный файл заметок на каждую сессию.
Speaker A
Решения, изменённые файлы, замеченные паттерны.
Speaker A
И это не логирование, это как рефлексия.
Speaker A
Данные собираются.
Speaker A
Данные извлекаются.
Speaker A
И данные записываются в фоне.
Speaker A
И кажется, что Claude собирает столько всего.
Speaker A
Как же он сделает так, чтобы наше контекстное окно с вами не лопнуло?
Speaker A
Кто же следит за тем, чтобы вся память не съела весь бюджет?
Speaker A
И тут нам надо посмотреть, как устроена рабочая память.
Speaker A
То, что мы используем здесь сейчас.
Speaker A
И у Claude реализовано пять уровней сжатия контекста.
Speaker A
И на первом уровне сжатия контекста мы пропускаем уже сумаризированные сообщения.
Speaker A
А это значит, что нам здесь делать ничего не надо.
Speaker A
Второй - это бюджет на результаты инструментов.
Speaker A
И он установлен в 200.000 символов на сообщение.
Speaker A
Если вдруг превысили, то самые крупные результаты уходят на диск.
Speaker A
Модель видит первые 2 КБ плюс путь к полному файлу.
Speaker A
И вот дальше решение: заменить или вставить.
Speaker A
Замораживается навсегда.
Speaker A
Потому что мутировать уже отправленное, значит, убить наш KV кэш.
Speaker A
Помните из первой части: каждая мутация середины - это потерянные деньги.
Speaker A
Вот тут вот у нас есть реализация.
Speaker A
Третья часть - это удалить самые старые сообщения.
Speaker A
Четвёртый - это микрокомпакт.
Speaker A
И тут у нас есть два пути.
Speaker A
И они зависят от состояния кэша.
Speaker A
Если кэш протух, то можно мутировать прямо: заменяем старые результаты на заглушку.
Speaker A
Ни одного вызова модели не происходит.
Speaker A
Если же кэш живой, то мутировать нельзя.
Speaker A
Вместо этого через API отправляем инструкцию.
Speaker A
Удалить содержимое вот этих результатов из кэша.
Speaker A
И сервер удаляет данные, не инвадируя весь кэш.
Speaker A
И у обоих этих путей одна цель.
Speaker A
Защитить KV кэш.
Speaker A
И это как сквозной принцип.
Speaker A
И пятое - это автокомпакт.
Speaker A
Это очень тяжёлая операция.
Speaker A
Здесь фоновый агент сумаризирует всё.
Speaker A
И в нём есть предохранитель.
Speaker A
Три неудачных сжатия подряд, и система останавливается.
Speaker A
И это ограничители в коде, а не в промте.
Speaker A
Также есть резерв на сумаризацию.
Speaker A
20.000 токенов.
Speaker A
Если мы посмотрим на эти типы сжатия, то это очень похоже на наш пайплайн.
Speaker A
Сначала у нас идут дешёвые операции.
Speaker A
И каждая последующая операция дороже.
Speaker A
То есть мы с вами максимально оптимизируемся по деньгам.
Speaker A
Что же мы с вами видим на примере Claude?
Speaker A
И здесь интеллект агента не в модели, и не в технологии хранения, а в архитектуре.
Speaker A
Что запоминать, когда доставлять, сколько тратить.
Speaker A
И когда остановиться.
Speaker A
Вот Claude Code - это 2,5 млрд выручки.
Speaker A
11 подсистем памяти, файлы с грепом.
Speaker A
Потому что правильная архитектура памяти важнее стека.
Speaker A
Но также красивая архитектура без защиты может быть дырявой.
Speaker A
Без отказоустойчивости.
Speaker A
Один сбой API, и всё мертво.
Speaker A
Без наблюдаемости мы летим вслепую и не знаем, куда деваются наши деньги.
Speaker A
И что вообще происходит с агентом.
Speaker A
В третьей части будет продакшн: безопасность, отказоустойчивость.
Speaker A
И многое другое.
Speaker A
Ссылка на первую часть в описании.
Speaker A
До встречи в финале.
Topics:агентыязыковые моделироутингуправление контекстомRAGкэшированиеоптимизация затратклассификатор запросовдлинный контекстинфраструктура ИИ
