Пайплайн «сновидінь» розробника запускається двічі на день, стискаючи необроблений журнал подій LLM-агента в компактне, перевірене сховище пам'яті та суттєво скорочуючи витрати токенів. Це критично важливо, оскільки більшість систем агентів перевантажують свою робочу пам'ять кожною дрібницею, яку вони бачать, що швидко призводить до суперечностей, втрати контексту та стрімкого зростання витрат на API.

Чому пам'ять важлива для LLM-агентів

LLM-агенти сприймають кожен запит користувача, виклик інструменту або внутрішнє спостереження як нову «подію». Наївний підхід полягає в тому, щоб додавати кожну подію до промпту, який керує наступним рішенням. На практиці це наповнює промпт шумом, змушує модель повторно оцінювати застарілі факти та виштовхує використання токенів у найвищий ціновий рівень. Результат: більше помилок і прихований рахунок, який зростає з кожною взаємодією.

Як працюють нічні «сновидіння»

Система розділяє шлях запису (живий журнал агента) та шлях роботи (процес прийняття рішень моделлю). Двічі на день фонове завдання — назване «сном» — обробляє накопичені події через три етапи:

  • Reflect (Рефлексія) — LLM сканує кластери пов'язаних подій, пропонує стислі факти та фіксує, які саме події підтверджують кожну пропозицію.
  • Score (Оцінювання) — пайплайн перевіряє, чи має факт достатню кількість підтверджуючих подій і чи достатньо вони розподілені в часі, щоб бути надійними.
  • Judge (Вердикт) — дві перевірки на логічність підтверджують, що новий факт не суперечить жодній існуючій пам'яті та не є дублікатом.

Факти, що пройшли всі перевірки, стають постійною пам'яттю. Ті, що не пройшли, потрапляють у чергу перевірки, де оператор-людина одним натисканням клавіші може схвалити або відхилити їх. Кожне схвалення створює коміт у стилі git, забезпечуючи повний аудиторський слід того, що і коли змінилося в пам'яті.

Ключові інженерні висновки

  • Розділяйте запис і роботу. Дозвольте агентам скидати кожне спостереження в журнал; нехай спеціалізований процес вирішує, що залишиться.
  • Фокусуйтеся на відхиленні, а не на генерації. Генерувати ідеї дешево; запобігання забрудненню пам'яті — це складна частина.
  • Людський контроль на найдешевшому етапі. Автоматичне створення чернеток з наступним швидким ручним підтвердженням виграє у повної автономії за вартістю та безпекою.
  • Обмежуйте витрати токенів за цикл. Жорсткий ліміт токенів на один запуск «снів» зупиняє неконтрольовані витрати.
  • Перевіряйте на наявність прихованих помилок. Якщо один етап застосовує інші правила, ніж наступний, дані можуть непомітно зникнути; явні перевірки допоможуть виявити таку невідповідність.

Потенційні недоліки

Проведення консолідації в офлайн-режимі створює затримку: агент не побачить нові перевірені факти до наступного циклу «снів». У швидкозмінних застосунках, що потребують миттєвого навчання, ця затримка може бути недоліком. Система також покладається на одного рецензента-людину; масштабування черги перевірки без збільшення витрат на працю залишається відкритим питанням.

На що звернути увагу далі

Розробникам, які експериментують з LLM-агентами, варто стежити за рахунками за токени та журналами помилок на предмет ознак «забруднення пам'яті» — повторюваних або суперечливих тверджень, що виникають через накопичення необроблених подій. Додавання пайплайну «сновидінь» дає конкретний важіль для зниження цих витрат, одночасно забезпечуючи можливість аудиту історії пам'яті. Оскільки все більше команд переходить на модель розділених журналів, ймовірно з'являться інструменти, що автоматизують етапи reflect-score-judge та інтегруються з системами перевірки у стилі контролю версій, роблячи цей підхід менш індивідуальним і більш готовим до використання (plug-and-play). Компроміс між миттєвістю та чистотою даних визначатиме, наскільки широко «нічний сон» стане стандартною частиною архітектури LLM-агентів.