TL;DR
PACMI — это схема управления долгой памятью агента. Каждая запись получает статус годности (актуальна / требует проверки / только история / заменена). Записи связаны рёбрами зависимости («на этом факте основан вывод, на выводе — решение»). Когда приходит новый факт, он помечает старую запись заменённой, а статус «протухания» каскадом переходит на всё, что от неё зависит. Старые записи не удаляются, а остаются для вопросов про прошлое.
Главная находка — две частые ошибки агентской памяти. Первая: агент подтягивает устаревший факт, потому что он похож на запрос по смыслу, хотя давно заменён. Вопрос вида «а почему мы делаем X?», где X уже неверно, агент принимает как есть и продолжает. Вторая: если переписывать память «на месте», вопросы про прошлое ломаются. Точность на исторических вопросах падает до 0,42, потому что старое значение стёрто.
Два защитных приёма дали самый большой эффект. Первый — не стирать, а помечать. Второй — проверять предпосылку вопроса: если вопрос опирается на устаревший факт, в промпт ответа добавляют пару «было — стало». Сам каскад по зависимостям улучшил корректность статусов, но на итоговые ответы повлиял статистически незначимо.
Схема метода
ШАГ 1: Новый факт приходит → ищем записи, которых он касается (по смыслу, словам, «слотам»: город, цена, срок)
ШАГ 2: Для каждой записи LLM определяет отношение: дубль / уточнение / ОБНОВЛЕНИЕ / противоречие / совместимо / не связано
ШАГ 3: Прямые цели (обновление или противоречие) → статус «заменена»
ШАГ 4: Каскад по рёбрам зависимости:
«опирается на» → «требует проверки»
«использовано в» → «только история»
(если путей несколько — побеждает более сильный статус)
ШАГ 5: Поиск с поправкой на статус: на текущие вопросы — актуальные вверх, замененные вниз; на исторические — наоборот
ШАГ 6: Проверка предпосылки: вопрос исходит из устаревшего факта? → в промпт ответа добавить «было X, стало Y»
Всё это в статье реализовано кодом, а не одним промптом.
Пример применения
Задача: Продавец на Ozon ведёт агента-помощника с памятью. В памяти лежит цепочка. Поставщик отдаёт товар по 1 200 ₽. Из этого посчитана маржа 40% при цене на маркетплейсе 2 490 ₽. Из маржи принято решение о рекламном бюджете 80 000 ₽ в месяц. Приходит письмо: закупка теперь 1 500 ₽. Через неделю продавец спрашивает: «Почему мы держим цену 2 490 ₽ при марже 40%?»
Промпт (логика PACMI, собранная в обычном чате; шаблон ниже):
Ты ведёшь реестр памяти с цепочкой зависимостей.
ЗАПИСИ:
M1: Закупка у поставщика — 1 200 ₽ за шт. [статус: active]
M2: Маржа 40% при цене 2 490 ₽ (опирается на M1) [active]
M3: Рекламный бюджет 80 000 ₽/мес (использует M2) [active]
M4: Поставщик отгружает за 5 дней [active]
M5: Конкурент продаёт аналог за 2 390 ₽ [active]
НОВЫЙ ФАКТ: Поставщик сообщил, что закупка теперь 1 500 ₽ за шт.
ЗАДАЧА 1: Определи отношение нового факта к каждой записи
(дубль / уточнение / обновление / противоречие / совместимо / не связано).
Обновление и противоречие — прямые цели.
ЗАДАЧА 2: Прямым целям поставь статус superseded.
Пройди по зависимостям: «опирается на» → needs-verification, «использовано в» → historical-only.
Записи, не связанные зависимостью, остаются active, даже если похожи по теме.
Ничего не удаляй.
ВОПРОС: Почему мы держим цену 2 490 ₽ при марже 40%?
ЗАДАЧА 3: Проверь, не опирается ли вопрос на устаревший факт.
Если да — сначала напиши «было / стало», потом отвечай по актуальным данным.
Результат: Модель выдаст таблицу статусов: M1 заменена, M2 «требует проверки», M3 «только история». M4 и M5 останутся активными, хотя M5 близка по теме к ценовой цепочке. Затем модель заметит, что вопрос исходит из устаревшей маржи. Она покажет пару «было 1 200 / стало 1 500» и ответит по обновлённым данным, не принимая 40% как факт.
Почему это работает
Слабость LLM и простой памяти. Поиск по смыслу не знает, что запись устарела. Старая запись остаётся «релевантной», поэтому её достают и используют. Если же переписать память на месте, пропадёт история. Любой вопрос «а сколько было раньше?» остаётся без ответа.
Сильная сторона LLM. Модель хорошо решает локальную задачу: «как этот новый факт соотносится с этой записью — обновление, уточнение, совместимо?». Ей не нужно держать в голове всю структуру зависимостей.
Как метод это использует. Он разделяет работу. Модель судит локально, по одной паре. Распространение статуса по цепочке идёт по жёстким правилам, без «рассуждений». Пометка вместо удаления сохраняет историю. Проверка предпосылки вытаскивает неявную ошибку в вопросе наружу.
Рычаги управления: - Набор статусов → для простых задач хватит двух («актуально» / «история»). - Карта переходов (опирается на → «требует проверки», использовано в → «история») → меняй под свои типы связей. - Правило «побеждает более сильный статус» → избавляет от конфликтов, когда запись затронута несколькими путями. - Блок «было / стало» → переносится прямо в промпт ответа как исправление вопроса.
Шаблон промпта
В статье нет готовых промптов (приложения не приведены). Шаблон ниже — это логика PACMI, записанная как промпт, а не авторский текст.
Ты — менеджер памяти. Ты не удаляешь записи, а меняешь их статус.
active — поддерживает текущие решения
needs-verification — зависит от изменившегося факта; использовать с осторожностью
historical-only — оставить для вопросов про прошлое
superseded — старое значение, которое заменил новый факт
Порядок силы: active < needs-verification < historical-only < superseded
{записи с id, например: M1: ...; M2: ... (опирается на M1); M3: ... (использует M2)}
{новый факт}
1. Для каждой записи определи отношение к новому факту:
duplicate / refine / update / contradict / temporally-compatible / unrelated.
Дай краткую причину.
2. Прямые цели — только update и contradict. Они получают superseded.
Запись, которая сама опирается на другую запись, прямой целью не считается.
3. Каскад по зависимостям от каждой прямой цели:
«опирается на» → needs-verification
«использовано в» → historical-only
Если путей несколько — оставь более сильный статус.
4. Записи без зависимости от затронутых остаются active,
даже если они близки по теме.
5. Выведи таблицу: id | статус | почему.
6. Ничего не удаляй и не переписывай.
{вопрос пользователя}
Опирается ли вопрос на запись со статусом superseded как на текущую?
Если да:
- напиши «Было: ... / Стало: ...»
- ответь по active и новому факту
Если вопрос о прошлом — используй historical-only и superseded и прямо скажи, что это история.
Плейсхолдеры: {записи} — факты с номерами и связями («опирается на», «использует»), {новый факт} — что изменилось, {вопрос} — что спрашивает пользователь.
🚀 Быстрый старт — вставь в чат:
Вот шаблон PACMI-реестра памяти. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие факты у тебя в памяти, что на чём основано и какой факт изменился. Без цепочки зависимостей каскад не сработает. Она подставит твои данные в структуру
Ограничения
⚠️ Нужен код для автоматической работы: в статье это конвейер с графом, ранжированием и обходом. В чат переносится только логика, и то для небольшого числа записей.
⚠️ Зависимости заданы вручную: авторы не проверяли, как их автоматически строить из сырого текста памяти. В реальной жизни это самое слабое место.
⚠️ Синтетический бенчмарк: шесть записей на случай, один новый факт, цепочка из двух связей. Авторы сами называют его диагностическим, а не реалистичным. Нет данных о больших хранилищах и длинных цепочках.
⚠️ Каскад — не главная причина выигрыша: без него ошибок 11 вместо 3, но разница статистически незначима. Основной эффект дали пометка вместо удаления и проверка предпосылки.
⚠️ Идеальная проверка предпосылки — только в лабораторных условиях: точность 100% получена, когда факты уже разложены по устаревшим и актуальным. Это не доказывает безошибочность в длинном свободном контексте.
⚠️ Платишь охватом: PACMI подтягивает меньше устаревшего, но и меньше нужного актуального контекста, чем сильный конкурент (0,83 против 0,88).
Как исследовали
Авторы собрали 100 случаев и 300 вопросов из пяти областей. В каждом случае шесть записей памяти, один новый факт и три вопроса: про текущее состояние, про устаревшую предпосылку («почему мы делаем X?», где X уже неверно) и про прошлое. В цепочке две связи, плюс похожая, но независимая запись и посторонняя. Их нужно оставить нетронутыми: так проверяют, что инвалидация идёт по зависимости, а не по сходству слов.
Сравнивали с обычным векторным поиском, поиском с учётом новизны, переписыванием памяти через LLM «на месте» и двумя методами, основанными на связях. Все используют одну модель ответа, а судит ответы одна модель с нулевой температурой.
PACMI дал точность 0,99 против 0,90 у сильнейшего конкурента, то есть 3 ошибки против 29. Разрыв целиком в вопросах с устаревшей предпосылкой. Самым вредным оказалось переписывание на месте: точность на исторических вопросах упала до 0,42.
Абляции показали: без проверки предпосылки ошибок на этих вопросах 50 вместо 3. Без сохранения истории точность на «прошлых» вопросах падает с 1,00 до 0,36. Без каскада эффект есть, но он на грани значимости. Авторы честно объясняют почему: контекст из пяти записей и так почти всегда содержит новый факт.
Адаптации и экстраполяции
🔧 Техника: убрать каскад, оставить два приёма → простой вариант для чата или CLAUDE.md
Раз основной эффект дали «не стирать» и «проверять предпосылку», достаточно двух правил:
Правила памяти:
1. Не перезаписывай и не удаляй старые факты. При изменении пометь старый как «устарело (с {дата})» и добавь новый.
2. Перед ответом проверь: не исходит ли вопрос из устаревшего факта?
Если да — сначала напиши «Было / Стало», потом отвечай.
Это моя адаптация: для неё в статье есть данные (удаление и проверка предпосылки дали основной эффект), но сам вариант для CLAUDE.md авторы не проверяли.
Ресурсы
- PACMI: Provenance-Aware Cascading Memory Invalidation for Long-Term LLM Agents
- Авторы: Yiqi Wang, Jiaqi Liu, Jiaqi Zhang, Zhangkai Wu, Yiqun Duan, Mingkai Zheng, Taotao Cai
- Университеты: University of Southern Queensland, Southern University of Science and Technology, Jiangsu University, The University of Sydney, Uploading Inc.
- Связанные работы: STALE (Chao et al. 2026), MemConflict (Tao et al. 2026), A-MEM (Xu et al. 2025), Mem0, MemGPT, Zep; классика: JTMS (Doyle 1979), ATMS (de Kleer 1986). Код и данные обещаны публично.