Шаблоны оценки памяти для агентных систем¶

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

Поэтому слой памяти полезно оценивать отдельно, а не надеяться, что он “как-нибудь попадет” в общий набор оценок.

1. Почему оценки памяти нужны отдельно¶

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

профиль заполняется лишними или рискованными фактами;
устаревшее предпочтение продолжает влиять на ответы;
система запоминает не то, что нужно;
нужный факт не извлекается в длинной сессии;
фоновое уплотнение искажает смысл записи.

Именно поэтому слой памяти требует собственной проверочной логики.

2. Какие типы ошибок стоит ловить¶

Минимальный набор оценок памяти обычно должен покрывать:

Канонические сценарии оценки памяти

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

неверная запись;
пропущенная запись;
небезопасная запись;
устаревший поиск;
ложное извлечение;
противоречие профиля;
избыточное хранение;
отказ удаления.

Этот набор уже полезен даже без сложного эталонного теста.

3. Что оценивать в краткосрочной памяти¶

Краткосрочную память чаще всего проверяют на:

удержание критичного контекста в пределах диалога;
отсутствие лишнего переноса в следующий ход;
устойчивость к шумным пользовательским ходам;
корректность переспрашивания при неоднозначности.

Здесь проблема обычно не в самом хранилище, а в том, как среда исполнения решает, что именно стоит переносить дальше.

4. Что оценивать в профильной и долгосрочной памяти¶

Профильная и долгосрочная память требуют более строгих проверок:

был ли факт вообще достоин записи;
был ли факт записан в правильный класс памяти;
можно ли объяснить происхождение;
можно ли безопасно удалить или обновить запись;
не влияет ли устаревшая запись на текущий путь ответа.

Здесь особенно важны оценки противоречий и гигиены хранения.

5. Длинную память нужно проверять на сериях запусков¶

Один из самых частых промахов такой: качество памяти проверяют на одной изолированной инструкции.

Но реальные проблемы обычно проявляются на сериях:

предпочтение записали в запуске 1;
неверно извлекли в запуске 4;
обновили конфликтующим фактом в запуске 6;
устаревший профиль продолжил влиять в запуске 9.

Поэтому полезно строить оценки памяти как многозапусковые сценарии, а не только как проверки одного хода.

6. Какие поля полезно фиксировать в сценарии оценки памяти¶

Минимально полезная запись оценки часто включает:

memory_class
write_expected
retrieval_expected
allowed_to_persist
expected_provenance
revision_behavior
deletion_behavior

Это помогает отделять “ответ плохой” от “семантика памяти нарушена”.

7. Что особенно важно для безопасности¶

Оценки памяти полезны не только для персонализации. Они важны и для безопасности:

не пишет ли система чувствительные данные без права;
не удерживает ли слишком долго рискованное состояние;
не путает ли пользовательские данные;
можно ли быстро прекратить вредный путь памяти;
можно ли доказать происхождение устойчивых записей.

Если этого слоя нет, инциденты памяти будут выглядеть как “странное поведение модели”, хотя проблема уже в жизненном цикле записи.

8. Как оценки памяти связаны с обычным оценочным контуром¶

Оценки памяти не живут отдельно от главы про оценки. Они просто добавляют отдельную плоскость:

обычные офлайн-оценки проверяют успешность задачи;
оценки памяти проверяют качество состояния между запусками;
онлайн-сигналы помогают ловить дрейф;
инциденты и разборы инцидентов обновляют сценарии, специфичные для памяти.

То есть слой памяти должен входить в регрессионную дисциплину так же явно, как инструменты или политика.

9. Что сделать сразу¶

Сначала пройди по короткому списку и отдельно отметь все ответы «нет»:

Есть ли отдельные сценарии для решений записывать или не записывать?
Проверяется ли поиск на длинных сериях запусков?
Есть ли сценарии на устаревший профиль и противоречия?
Оценивается ли происхождение устойчивых записей?
Есть ли сценарии удаления и ревизии?
Возвращаются ли инциденты памяти в набор оценок?