Як оцінити пам’ять AI-агента: практичний чекліст

Пам’ять агента не є однією функцією. Вона вирішує, що записати, як нормалізувати подію, що повернути для нового запиту, як обробити оновлення і коли видалити похідні записи. До тесту зафіксуйте типи пам’яті, дозволені джерела, власника істини, tenant boundary, строки зберігання та задачі, яким recall справді має допомагати. Conversation history, runtime checkpoint, довгострокова memory і domain database оцінюються окремо.

Публічний benchmark корисний як зовнішній fixture, але не доводить готовність вашого workflow. LongMemEval перевіряє extraction, multi-session reasoning, temporal reasoning, knowledge updates та abstention у довгих діалогах; LongMemEval-V2 додає пам’ять про стан середовища, workflows і повторювані failure modes. Власний release gate має також охопити ACL, privacy, deletion, poisoning, side effects і business outcome. Не переносіть чужий score між іншими моделями, judges, corpus versions або retrieval budgets.

• Contract → що можна записати, хто є source of truth і коли запис протухає.
• Fixture → історія подій, запит, дозволені докази й очікувана поведінка.
• Verdict → retrieve, ignore, abstain, ask, update або delete.
• Outcome → чи допомогла пам’ять виконати задачу без порушення authority.

Побудуйте corpus із реальних, очищених сценаріїв: явне прохання запам’ятати preference, факт із підтвердженим джерелом, повторювана робоча процедура, рішення з датою, correction старого факту та подія, яку зберігати заборонено. Для кожного fixture задайте subject, tenant, event time, valid time, source ID, sensitivity, TTL, expected memory operations і допустимі відповіді. Додайте paraphrase та language variants, бо точний збіг формулювання приховує слабкий retrieval.

Негативні fixtures важливіші за ще десять простих recall-питань: секрет у tool output, prompt injection у документі, непідтверджене припущення моделі, чужий tenant, відкликаний consent, видалений запис, майбутня дата, суперечливі джерела та запит без достатніх доказів. Окремо перевіряйте distractors — правдоподібні, але нерелевантні записи. Corpus версіонується, а production incident після очищення стає regression case.

Memory writer оцінюйте до retrieval. Для кожної події перевірте рішення write, reject, merge або quarantine; тип запису; нормалізований subject; source pointer; valid_from і valid_to; confidence як metadata, а не істину; ACL; TTL та версію extractor. Precision запису часто критичніша за coverage: один збережений секрет або шкідлива інструкція може отруїти багато майбутніх сесій.

Тестуйте повторну доставку й зміну порядку подій. Одна подія з однаковим idempotency key не повинна породжувати кілька facts, а пізній correction має створити зрозумілий temporal transition замість безслідного перезапису. Summary та embedding є похідними артефактами: harness повинен уміти простежити їх до джерела, перестворити після зміни policy й позначити stale, якщо canonical record змінився.

Записуйте retrieved IDs, ranks, scores, filters і query transformation до того, як модель сформує відповідь. На цьому шарі корисні Recall@k для потрібних доказів, precision або частка distractors, coverage temporal slices та filter violations. Але retrieval metric не є фінальним результатом: потрібний факт може бути в top-k, а модель його проігнорує; неправильний запис може не потрапити в answer випадково.

На answer layer перевіряйте supported claim, правильне поєднання кількох сесій, часову відповідь, застосування найновішого чинного факту і abstention за відсутності доказів. Judge отримує reference evidence та rubric, а не прихований доступ до всієї історії. Детерміновані checks перевіряють IDs, дати, tenant і заборонені claims; model grader калібрується на людській розмітці та не є єдиним release authority.

Створіть послідовність: користувач задає preference A, згодом замінює його на B, а потім питає про поточне й попереднє значення. Правильна поведінка залежить від запиту: current answer використовує B, historical answer може назвати A з часовою межею, а неоднозначний запит уточнюється. Last-write-wins без event time та provenance не проходить цей gate, як і відповідь, що змішує обидва значення.

Deletion test починається з відомого canary record. Після запиту на видалення перевірте primary store, summaries, vector index, cache, graph relations, export і дозволені backup semantics. Потім повторіть прямий, paraphrased і multi-hop retrieval та переконайтеся, що система не відновила запис із старого summary. Audit evidence може зберігати факт виконання deletion без самого видаленого payload. Зафіксуйте measured propagation time лише для власної системи, не вигадуйте універсальний SLA.

Запустіть однакові subjects у двох tenants і спробуйте cross-tenant query, semantic near-match, shared cache та admin downgrade. Жоден retrieved artifact не повинен перетнути boundary. Окремі fixtures підсовують у memory текст на кшталт «ігноруй policy» або хибне procedural rule. Система може зберегти недовірений документ як data з provenance, але не повинна підвищити його до instruction чи дозволу на дію.

Пам’ять не надає authority. Навіть коректно згадана попередня згода, адреса або approval не замінює актуальну authentication, authorization і precondition check перед consequential tool call. Перевірте revoked permission, expired approval та змінений payload після recall. Очікувана поведінка — повторна перевірка або human handoff, а не виконання дії лише тому, що memory record звучить переконливо.

Порівняйте щонайменше три режими на тих самих fixtures: без довгострокової пам’яті, з oracle evidence і з реальною memory pipeline. Різниця між no-memory та oracle показує можливий task lift, а розрив між pipeline та oracle допомагає локалізувати extraction або retrieval bottleneck. Заморозьте model, prompt, tools, corpus version, top-k, reranker, judge і retry policy; інакше зміна score не належить пам’яті.

Звітуйте task success і critical failures за slices, а не лише середнє. Додайте write latency, retrieval latency, tokens із memory context, storage та indexing cost, stale-read rate, abstention, manual review і cost per verified task. Public benchmark results залишайте атрибутованими до конкретного paper та protocol. Для власної системи публікуйте лише відтворювані runs із manifest; один локальний прогін не стає vendor-independent рейтингом.

Decision record називає дозволені memory types, tenants, data classes, workflows, model та extractor versions, corpus revision, thresholds, owner і review date. `Promote` стосується конкретного slice; `restrict` може дозволити preference recall, але заборонити procedural memory або sensitive data; `reject` залишає stateless чи session-only baseline. Critical ACL, deletion або unauthorized-action failure не компенсується високим recall average.

Rollout проходить offline replay, shadow write без читання, read-only canary і лише потім bounded use у діях із окремою authorization. Rollback вимикає new writes і reads незалежними switches, повертає known-good extractor/index snapshot, quarantine-ить записи несумісної версії та не видаляє audit trail. Після model, embedding, schema, retention policy або corpus change повторіть critical slices; memory quality є lifecycle, а не одноразовим benchmark.

• Promote → визначений тип пам’яті й workflow пройшли всі critical gates.
• Restrict → звузити data class, TTL, retrieval або action scope.
• Reject → повернути session-only чи stateless baseline.
• Roll back → вимкнути reads/writes, відновити сумісний snapshot і reconcile.