«Память — это отдельный слой»: AWS показала свой memory-провайдер для NVIDIA NeMo Agent Toolkit на Amazon S3 Vectors

Что такое NVIDIA NeMo Agent Toolkit

NVIDIA NeMo Agent Toolkit (NAT) — открытый фреймворк для сборки, профилирования и оптимизации ИИ-агентов, не привязанный к одному стеку: он работает со Strands Agents, LangChain, LlamaIndex, CrewAI и собственными реализациями. AWS перечисляет четыре возможности, важные для продакшена: оркестрацию агентов как композируемых рабочих процессов с настраиваемыми LLM, инструментами и промптами (запуск локально через nat run или как постоянный сервис через nat serve), профилирование расхода токенов, задержек, пропускной способности и времени выполнения отдельных инструментов, встроенные оценщики точности ответа, релевантности контекста, обоснованности и траектории агента, а также автоматическую подстройку гиперпараметров — temperature, top_p и max_tokens.

Отдельный модуль памяти в NAT хранит историю диалогов, пользовательские предпочтения и долговременные знания между вызовами агента. Он расширяемый: свой бэкенд пишется через плагинный интерфейс. Ключевые части — абстрактный интерфейс MemoryEditor с тремя методами add_items(), search() и remove_items(); модель данных MemoryItem с полями для истории диалога, тегов, метаданных, user_id и необязательной текстовой строки памяти; базовый Pydantic-класс MemoryBaseConfig, от которого наследуются конфигурации провайдеров (NAT находит их по полю _type в YAML-конфиге); и обёртка auto_memory_agent, которая автоматически захватывает и подмешивает память, не заставляя модель явно вызывать инструменты памяти. Из коробки NAT умеет работать с Mem0, MemMachine, Redis и Zep.

Почему именно Amazon S3 Vectors

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

Масштаб заявлен как до двух миллиардов векторов на индекс без планирования ёмкости, а оплата — только за хранение, записи и запросы, без простаивающих вычислений. Доступ разграничивается политиками AWS Identity and Access Management на уровне бакета и индекса, при этом отдельные индексы на арендатора дают жёсткую изоляцию. Индекс в примере создаётся с 1024 измерениями под выход модели Amazon Titan Text Embeddings V2, типом float32, косинусной метрикой и пометкой большого поля content как нефильтруемого метаданными.

Три шага реализации

Реализация разбита на три шага: создать инфраструктуру S3 Vectors, написать собственный плагин MemoryEditor и настроить рабочий процесс агента. На первом шаге скрипт создаёт векторный бакет и индекс agent-long-term-memory в регионе us-west-2. На втором — провайдер строит эмбеддинги, сохраняет каждую память как вектор с ограниченными по области метаданными и переводит фильтры поиска в запросы к S3 Vectors. В примере фильтры собираются по полям agent_id, memory_type, ticker, team_id, user_id, а также по булеву признаку is_shared, а удаление выполняется через delete_vectors по переданным ключам. Провайдер регистрируется декоратором register_memory с типом конфигурации, после чего NAT находит его по имени в конфиге.

На третьем шаге провайдер прописывается в YAML-конфиге NAT и подключается к рабочему процессу. Используется обёртка workflow с типом auto_memory_agent, где заданы внутренний агент, имя памяти и LLM, а флаги save_user_messages_to_memory, retrieve_memory_for_every_response и save_ai_messages_to_memory включают автоматический захват сообщений пользователя и ответов агента и подмешивание релевантного контекста перед каждым вызовом. В качестве модели в примере указан bedrock с моделью anthropic.claude-sonnet-4-20250514 и temperature 0.3.

Координация агентов и консолидация памяти

Сквозной сценарий — инвестиционное исследование силами трёх специализированных агентов: Research собирает рыночные данные, отчёты о прибылях и новости, Analysis занимается количественным анализом и поиском закономерностей, Synthesis готовит отчёты, объединяющие находки обоих. С постоянной памятью каждый агент опирается на предыдущую работу: Research вспоминает уже собранные данные и не делает лишних вызовов API, Analysis продолжает с паттернами прошлых сессий, а Synthesis получает накопленные результаты и строит всё более полные отчёты.

Все агенты используют один индекс S3 Vectors, но пишут каждый со своим agent_id в метаданных, а общие знания достают фильтрами: Analysis запрашивает находки Research по полю team_id со значением investment-research и признаку is_shared, а Synthesis — всю командную базу по тому же team_id с большим top_k. Встроенная мультитенантная изоляция NAT ограничивает память по user_id, а поле team_id даёт дополнительное измерение группировки внутри одного индекса.

Со временем эпизодических записей становится слишком много, поэтому AWS описывает консолидацию: эпизодические памяти дистиллируются в обобщённые семантические знания через LLM по расписанию, по порогу числа векторов или по сигналу агента после заданного числа исследовательских циклов. В примере консолидации агент забирает до пятидесяти эпизодов по тикеру, просит модель выделить устойчивые закономерности и вернуть JSON-массив выводов без конкретных дат и разовых событий, а затем сохраняет каждый вывод как семантическую память с признаком is_shared и confidence 0.9.

Развёртывание на Amazon EKS и честная оценка эффекта

Amazon EKS выбран сознательно — там команда получает полный операционный контроль над масштабированием, сетью и жизненным циклом агентов и нативно интегрируется с IAM для доступа к S3 Vectors; для тех, кому нужен полностью управляемый рантайм, AWS напоминает об альтернативе в лице Amazon Bedrock AgentCore. Агенты NAT работают как контейнерные сервисы через nat serve, каждый тип агента — это Kubernetes Deployment, а доступ к AWS выдаётся через IAM Roles for Service Accounts. В примере развёртывания у Research-агента две реплики, порт 8000, запросы 500m CPU и 1 GiB памяти при лимитах 2000m и 4 GiB, а HorizontalPodAutoscaler держит от одной до десяти реплик с целью по загрузке CPU в 70 %. Политика IAM в примере разрешает ровно четыре действия — s3vectors:PutVectors, QueryVectors, GetVectors и DeleteVectors — и только на ресурсы конкретного векторного бакета.

Для повторения нужны аккаунт AWS с правами на S3 Vectors и EKS, существующий кластер EKS, установленный NVIDIA NeMo Agent Toolkit (проверялась версия 1.6), Python 3.11 или 3.12 (NAT требует не ниже 3.11 и ниже 3.14), модель эмбеддингов вроде Amazon Titan Text Embeddings V2, а также kubectl и Docker. Сильная согласованность записи S3 Vectors означает, что поды сразу видят памяти, записанные другими подами, без инвалидации кэша, а все реплики ходят в один индекс через IRSA.

Эффект памяти AWS предлагает измерять штатным оценочным контуром nat eval, прогнав один и тот же датасет дважды — с памятью и без неё — по метрикам accuracy, groundedness, token_usage и latency. При этом автор прямо оговаривает, что ожидаемые результаты — обоснованность ответов растёт, расход токенов падает, задержка умеренно увеличивается на доли секунды за счёт запроса к S3 Vectors, а доля дублирующей работы снижается — это направленные ожидания, а не измеренные бенчмарки, и их величина зависит от рабочей нагрузки, числа агентов и бюджета top_k. Отдельный раздел посвящён ответственной работе с данными: нужна политика хранения памяти, не стоит класть персональные данные в метаданные, чувствительные поля лучше редактировать или токенизировать, а доступ ограничивать индексами на арендатора и политиками наименьших привилегий.