Проблема: память есть, а ошибку найти сложно
Постоянная память считается одной из важнейших частей LLM-агента: именно она позволяет ему работать между сессиями, вспоминать контекст, корректировать свои представления и адаптироваться к пользователю. Однако реальная система памяти — это не один компонент, а целый конвейер из нескольких стадий: приём данных, поиск нужных фрагментов, фильтрация и, наконец, использование при генерации ответа. Когда результат оказывается неверным, сквозные метрики лишь констатируют факт провала. Они не объясняют, на каком этапе что-то пошло не так — и это превращает доработку памяти в слепое подбирание параметров.
Существующие подходы к оценке усугубляют проблему. Обычно они сообщают среднюю точность по набору тестов, но умалчивают о статистической значимости изменений, не проверяют, не стало ли лучше на одних срезах за счёт регрессий на других, и не оставляют после себя диагностических следов, по которым можно было бы восстановить ход рассуждений. В итоге команда может потратить недели на эксперименты, но так и не узнать, какое именно вмешательство привело к улучшению и не сломалось ли что-то ещё.
Протокол D²ACCI
Чтобы справиться с этой проблемой, исследователи предложили D²ACCI — двухконтурный протокол итеративной разработки памяти. Его идея в том, что любое изменение в системе должно проходить через внешний диагностический «гейт»: он продвигает изменение, помечает его как экспериментальное или полностью отклоняет — на основе парных свидетельств, мониторинга защищённых срезов и трасс, позволяющих локализовать сбой на уровне конкретного этапа.
Ключевая новинка протокола — метрика DCR, которая измеряет «градуированную наблюдаемость»: степень, в которой ошибки остаются локализуемыми по имеющимся данным. То есть оценивается не только качество ответа, но и то, можно ли по записям эксперимента понять, где именно возникла проблема. Для воспроизводимости есть и артефакт D²ACCI-Eval, который позволяет повторно запускать гейт на тех же данных и сверять результаты.
Как это работает на практике
Протокол был применён в системе памяти MemStack. Её оценивали сразу на трёх публичных бенчмарках: точность составила 93.59% на LoCoMo, 90.93% на LongMemEval и 57.20% на PersonaMem-V2. Но гораздо интереснее не сами цифры, а то, что удалось выяснить благодаря парным абляциям.
Пять экспериментов показали, что три компонента — supplement extraction, session-memory retrieval и Forget Guard — дают статистически значимый прирост от +1.9 до +3.7 процентных пункта (во всех случаях p ≤ .003). Остальные изменения оказались неразличимы на агрегированной метрике. Например, выбор между BM25 и RRF был сохранён как управляемый feature flag — и это различие попросту не видно при обычной оценке, зато оно становится заметным на уровне трасс.
Почему это меняет подход к разработке
Отдельно авторы провели диагностический аудит: сравнили согласие экспертов по корневой причине сбоя при переразметке только по результатам и при использовании обогащённых трасс. Второй вариант значительно улучшил согласованность выводов. А вот DCR@3 продемонстрировал разительную разницу: диагностические артефакты достигли 98–100% локализуемости, тогда как журналы только с результатами — 0%.
Вывод достаточно прозрачный: чтобы надёжно улучшать системы памяти, нужны свидетельства, которые можно проследить, статистически обосновать и проверить на регрессии. Без этого невозможно отличить настоящее улучшение от случайной удачи, а удачную правку — от проблемы, «переехавшей» из одного этапа конвейера в другой. D²ACCI — это попытка превратить такую диагностику из ручного трудоёмкого процесса в стандартную часть цикла разработки.
