Stateless или память: как выбрать архитектуру LLM-агента

OpenAI в феврале 2024 года включила память в ChatGPT, Anthropic добавила проекты и память в Claude в 2024–2025 годах. С этого момента спор «нужна ли агенту долгая память» перестал быть теоретическим: у продуктовых команд появился выбор между двумя архитектурами, и у каждой своя цена — в деньгах, задержке и рисках приватности.

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

Что значит stateless на практике

Классический пример stateless — вызов API вроде chat.completions без сохранения истории на стороне сервера. Вы сами решаете, что положить в контекст: если ничего не кладёте, модель не знает ни о прошлом диалоге, ни о том, кто вы. Каждый запрос независим и воспроизводим.

Это удобно для задач без предыстории: классификация текста, извлечение сущностей, перевод, генерация по чёткому промпту. Здесь память не нужна, а её отсутствие даёт три выигрыша: предсказуемая стоимость, простое горизонтальное масштабирование (любой запрос можно отправить на любой инстанс) и минимум рисков с данными — хранить нечего.

Где stateless ломается

Проблема появляется, когда пользователь ждёт непрерывности. Диалог из десяти реплик в stateless-режиме означает, что на десятой реплике вы заново отправляете все предыдущие девять в контекст. Контекст растёт линейно, стоимость входных токенов — вместе с ним. На длинных сессиях это дороже, чем разовое сохранение фактов.

Агент с долгой памятью

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

Типичный конвейер выглядит так:

1. После сессии агент извлекает из диалога устойчивые факты («пользователь работает в PostgreSQL», «предпочитает краткие ответы») и записывает их в память.
2. При новом запросе система ищет релевантные фрагменты памяти (retrieval) и добавляет только их в контекст, а не всю историю.
3. Старые диалоги сжимаются в конспекты, чтобы не хранить сырой текст бесконечно.

Выигрыш — персонализация и экономия на длинной дистанции: вместо повторной отправки всей истории вы подтягиваете десяток релевантных строк. Плата — сложность. Появляются вопросы: что считать «важным» фактом, как обновлять устаревшее (пользователь сменил стек), как не смешать данные двух пользователей.

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

Сравнение по ключевым осям

Как выбрать под задачу

Ориентируйтесь не на моду, а на характер задачи. Три ситуации, где stateless почти всегда правильный выбор:

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

Три ситуации, где память оправдана:

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

Гибрид как компромисс

На практике многие продукты не выбирают крайность. Внутри одной сессии агент stateful (держит контекст диалога), между сессиями — сохраняет только сжатую выжимку и явные факты, а по умолчанию работает как stateless. Это ограничивает объём хранимого и упрощает удаление: пользователь очистил профиль — вы стёрли одну запись, а не разбираете тысячи сырых сообщений.

Что учесть по данным и приватности

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

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

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