Post #224

Практика Наша задача построить агента, который может запоминать происходящее в рамках сессии и переживать рестарт, возвращаясь к сессии. 1. Как обычно копируем и запускаем поэтапно ноутбук, в котором уже все готово. Как всегда, нужно настроить GOOGLE_API. После чего можно прокликать первую секцию ноутбука — там устанавливается ADK и написаны разные вспомогательные функции. Дальше интересное. Раньше мы уже импортировали google.adk.sessions.InMemorySessionService и google.adk.runners.Runner , но сегодня мы делаем это осознанно ☕️ InMemorySessionService — управляет данными в рамках сессии. В ADK несколько вариантов этих сервисов. Runner — оркестратор, который управляет потоком данных между агентом и юзером и собственно занимается инжинирингом контекста. 2. Запускаем секции 2.4 и 2.5. Там демонстрируется работа обычного InMemorySessionService. Подается два сообщения по порядку. В первом юзер представляется. А во втором спрашивает агента, как его зовут — агент корректно отвечает, потому что InMemorySessionService сохранил сообщение юзера в стейте. Чтобы увидеть, как работает память внутри сессии (и не работает за ее пределами) можно запустить секцию 2.6 сразу — агент снова скажет как зовут юзера. Но если вы перезапустите ноутбук и пропустите запуск сессии, то естессно голая LLM не скажет как зовут юзера. 3. Переходим к примеру постоянных сессий с использованием баз данных: google.adk.sessions.DatabaseSessionService . Так воспоминания переживут перезапуск, тк агент сохранит память в БД (тут — в SQLite). В секции 3 запускаем такого агента. Все благодаря двум строчкам, которые определяют в рамках сессии БД: session_service = DatabaseSessionService(db_url=db_url) Тут БДшка создается сама, но в реальной жизни вам придется ее развернуть своими руками. Запускаем ячейку 3.2 — агент с БД создан. Тестируем: запускаем ячейку 3.3 — юзер снова представился агенту, это все записалось в сессии под именем "test-db-session-01" в БД. Вы можете полностью выключить ноутбук и снова его прокликать, но пропустить шаг 3.3 — и запустить сразу 3.4, где у агента снова спрашивают как зовут юзера и дают указание на сессию "test-db-session-01" — агент успешно вытаскивает имя пользователя из БД. Вот в этом сила сохранения в БД! Соответсвенно, если поменять имя сессии — то агент ничего не вспомнит. А в ячейке 3.6 можете посмотреть, как данные хранятся в БД. 4. Когда сообщений в БД накапливается слишком много (а происходит это быстро) — мы начинаем сжимать воспоминания. Делаем это банально с помощью суммаризации. В ADK для этого есть отдельный механизм внутри приложения, в котором находится агент: google.adk.apps.app.EventsCompactionConfig В ячейке 4.1 показано как создается такой конфиг. Прокликайте до 4.3 включительно: там вы увидите в каком виде саммари создается и заменяет в контексте агента суммаризованную информацию. Вы можете настраивать как часто запускать суммаризацию (каждые N запусков/токенов и тд). В документации ADK описано детальнее как еще можно управлять суммаризацией. Смысл везде будет схожий. 5. В секции 5 демонстрируется, как управлять внутри сессии стейтом (state). Для этого используется объект google.adk.tools.tool_context.ToolContext . С помощью функции save_userinfo в него записывается инфа, а с помощью функции retrieve_userinfo она достается. Соответсвенно в ячейке 5.2 создается агент, которому в качестве тулов передаются эти две фнукции. И теперь агент может сам решать, когда записывать инфу, например имя и страну пользователя, а когда ее доставать. Потестить это можно в ячейках 5.3-5.5. А еще можно шарить state между сессиями в рамках одного юзера и аппки. Это показано в ячейке 5.6. Ну что, вы пережили прямо таки глубокое погружение в агентов — так держать! А в следующей серии разберем долгосрочную память. Stay tuned 😎 #ИИученьесвет Заместители