Retrieval, memory, and state

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

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

Правильное разведение даёт каждому слою свою политику: retrieval — индексация и поиск по запросу; память — явные правила записи и перечитывание при старте сессии; состояние — компактный структурированный блок, обновляемый каждый ход. Дальше разберём каждый слой отдельно, с конкретными техниками и цифрами.

Чисто векторный поиск — плохой дефолт. Эмбеддинги ловят смысловую близость, но промахиваются на точных идентификаторах: код ошибки TS-2345, артикул, имя функции. Поэтому продакшен-стандарт — гибрид: BM25 по ключевым словам плюс векторный поиск, результаты сливаются и переранжируются. Вторая проблема — чанки теряют контекст: фрагмент «выручка выросла на 3%» бесполезен, если непонятно, чья выручка и за какой квартал.

Contextual retrieval от Anthropic решает это так: перед индексацией каждому чанку моделью дописывается короткая справка на 50–100 токенов — из какого документа фрагмент и что он описывает. По измерениям Anthropic, контекстные эмбеддинги вместе с контекстным BM25 сокращают долю неудачных извлечений на 49%, а с добавлением реранкинга — на 67%. Дешевизну обеспечивает prompt caching: документ кладётся в кэш один раз, а справки для всех его чанков генерируются чтениями из кэша.

Третий подход — агентный поиск: модель сама ищет через инструменты (grep, glob, чтение файла по пути), как это делает Claude Code. Он медленнее и жжёт токены на навигацию, зато не требует индекса, не протухает и точен для кода. Практичная стратегия — комбинировать: быстрый семантический поиск для «куда смотреть», агентное дочитывание для «что там точно написано».

Идею памяти как «подкачки» популяризировал MemGPT: у агента есть основной контекст (окно) и внешнее хранилище, а перенос между ними — явные операции, как paging в операционной системе. На практике самая живучая реализация — обычные файлы: MEMORY.md или каталог заметок, которые агент читает при старте сессии и пополняет по ходу работы. Файлы прозрачны, версионируются в git и не требуют инфраструктуры.

Главный вопрос памяти — не «как хранить», а «что писать». Хорошо переживают сессию: принятые решения с обоснованием («выбрали Fastify, потому что…»), инварианты проекта («порт 8788, не 3000»), предпочтения пользователя, повторяющиеся грабли. Плохо: сырые логи, полные транскрипты диалогов, всё, что можно заново получить retrieval-ом. Память — это дистиллят, а не архив.

Второе правило — политика обновления. Append-only память быстро зарастает противоречиями: старая запись говорит «используем Postgres», новая — «мигрировали на Mongo». Рабочая схема: короткий индекс-файл с указателями плюс тематические заметки, которые перезаписываются целиком при изменении факта. И помните про кэш: если память входит в начало запроса, каждое её обновление инвалидирует префикс — обновляйте память в конце сессии, а не посреди неё.

Историю диалога часто используют как носитель состояния: «модель же видела, что мы сделали». Это ненадёжно: важные факты тонут в середине окна, а после компакции могут исчезнуть. Надёжнее вести состояние явно — компактным структурированным блоком, который пересобирается и подставляется в конец контекста на каждом ходу:

{
  "goal": "мигрировать платежи на новый API",
  "done": ["изучены эндпоинты", "написан адаптер"],
  "in_progress": "интеграционные тесты",
  "blocked": [],
  "invariants": ["не трогать ветку main", "тесты зелёные перед коммитом"]
}

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

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