Урок 8.3. Бенчмарки и исследовательские направления

Цель лекции

Дать обзор классов бенчмарков и направлений развития memory systems.

Ожидаемый результат

Читатель понимает, какие исследования релевантны памяти агентов, какие аспекты memory layer можно оценивать с помощью benchmarks и почему их нужно дополнять production-метриками.

Зачем это нужно

Когда появляется новая memory architecture, почти сразу возникает вопрос:

Она лучше старой или просто выглядит убедительнее в demo?

Бенчмарки помогают ответить на этот вопрос более системно. Они задают фиксированные задачи, данные, expected behavior и метрики. Благодаря этому можно сравнить:

• long context против retrieval memory;
• vector search против graph memory;
• raw episodic logs против summaries;
• разные chunking и reranking strategies;
• memory-enabled agent против stateless agent;
• personalization strategy A против strategy B.

Но у бенчмарков есть ограничение: они измеряют только то, что в них заложено. Production memory должна быть не только "умной", но и актуальной, безопасной, объяснимой, дешевой, быстрой и управляемой пользователем.

Поэтому benchmarks - это не финальный судья, а один слой evidence.

Основная идея

Бенчмарки помогают сравнивать подходы, но production-память требует дополнительных проверок на безопасность, актуальность и пользовательскую полезность.

Для memory layer важно различать:

• academic benchmark performance;
• internal offline evaluation;
• online product metrics;
• safety and privacy checks;
• human evaluation;
• operational reliability.

Хорошая команда не спрашивает только "какой score?". Она спрашивает:

• какой memory behavior проверяет этот benchmark;
• похож ли benchmark на наш продукт;
• есть ли multi-session pressure;
• есть ли fact updates and conflicts;
• проверяется ли deletion;
• есть ли adversarial input;
• учитываются ли cost и latency;
• можно ли объяснить, почему memory помогла или навредила.

Ключевые термины

Карта benchmark landscape

Эта карта показывает важный принцип: memory evaluation не сводится к одному benchmark. Разные классы тестов отвечают на разные вопросы.

Long-context benchmarks

Long-context benchmarks проверяют, насколько модель умеет работать с большим количеством текста внутри одного prompt.

Они обычно измеряют:

• поиск факта в длинном документе;
• answer over long document;
• устойчивость к distractors;
• multi-hop reasoning across long input;
• сохранение инструкции в начале длинного контекста;
• обработку документов, логов, писем или кодовой базы.

Чем они полезны для memory layer:

• помогают понять, когда можно обойтись без external memory;
• показывают, насколько модель справляется с большим injected context;
• проверяют качество context packing;
• выявляют потерю внимания к середине или началу контекста.

Но long-context benchmark не равен long-term memory.

Если вся информация находится в одном prompt, это еще не persistent memory. Там нет write policy, TTL, deletion, cross-session retrieval, user correction и evolution of facts.

Пример различия:

Long context решает часть проблемы памяти, но не заменяет memory architecture.

Long-term conversation benchmarks

Long-term conversation benchmarks проверяют, как агент помнит информацию внутри длинного диалога.

Они могут включать:

• facts introduced early in conversation;
• user preferences;
• plans and commitments;
• unresolved tasks;
• contradictions;
• delayed questions;
• summaries of previous turns;
• style consistency.

Пример сценария:

Turn 3:
User says the project deadline is September 15.

Turn 80:
User asks, "How much time do we have before the deadline?"

Expected:
Agent uses September 15, not a guessed date.

Такие benchmarks полезны, потому что они проверяют pressure на context management. Модель или агент должны решить, что сохранить, что сжать, что retrieve и как не потерять важное.

Но здесь тоже есть ограничения. Long conversation внутри одной evaluation session может не проверять:

• real session boundaries;
• asynchronous writes;
• stale facts after days or weeks;
• user-requested deletion;
• permissions and tenant boundaries;
• memory conflicts across projects.

Поэтому long-term conversation benchmarks - хороший старт, но не полный тест production memory.

Multi-session memory benchmarks

Multi-session benchmarks ближе к реальным агентам. Они проверяют, что информация переносится между отдельными interaction episodes.

Типовые проверки:

• пользователь сообщил preference в одной сессии, агент применил его в другой;
• агент продолжил незавершенную задачу;
• project-specific memory не вытекла в другой project;
• temporary instruction не стала permanent memory;
• old fact был обновлен после correction;
• deletion сохранился между сессиями;
• summary не исказил важный факт.

Пример:

Session 1:
User: "For this course, keep lectures conceptual and in Russian."

Session 2:
User: "Write the next lesson."

Expected:
Agent writes a conceptual Russian lecture.

Контрпример:

Session 1:
User: "Today, answer only in bullet points."

Session 2:
User: "Explain semantic memory."

Expected:
Agent does not treat today's style as a permanent preference.

Главная ценность multi-session benchmarks в том, что они проверяют persistence и scope. Именно там часто ломается memory layer.

Agent task benchmarks

Agent task benchmarks оценивают не только answer quality, но и выполнение задач.

Агент может:

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

Для memory layer такие benchmarks особенно важны, потому что память нужна не ради красивой цитаты, а ради лучшего действия.

Примеры задач:

• coding agent помнит архитектурное решение и применяет его в новом файле;
• research agent помнит уже просмотренные источники и не повторяет поиск;
• support agent помнит customer context и не задает один и тот же вопрос;
• writing agent помнит стиль курса и структуру лекций;
• data agent помнит transformation pipeline и воспроизводит его на новом dataset.

Что измерять:

Agent benchmarks полезны, но часто трудно понять, почему агент победил или проиграл. Поэтому их нужно дополнять traces: what was retrieved, what was injected, what was written and why.

Retrieval and grounding benchmarks

Retrieval benchmarks оценивают поиск релевантной информации.

Они отвечают на вопросы:

• нашел ли system нужный memory record;
• не принес ли слишком много мусора;
• поднял ли важные records в top-k;
• правильно ли применил filters;
• сохранил ли tenant/project boundaries;
• не использовал ли stale data.

Grounding benchmarks идут дальше. Они проверяют, опирается ли final answer на retrieved evidence.

Пример:

Question:
"Какой формат финального отчета предпочитает пользователь?"

Retrieved:
- User prefers concise final reports.
- User likes detailed lectures.

Expected answer:
"Финальные отчеты должны быть краткими."

Bad answer:

"Пользователь всегда предпочитает краткие ответы."

Retrieval сработал, но grounding и scope reasoning сломались.

Полезные метрики:

• precision@k;
• recall@k;
• MRR;
• nDCG;
• source attribution rate;
• unsupported claim rate;
• stale evidence rate;
• irrelevant context tokens;
• unauthorized retrieval count.

Для memory layer retrieval benchmark должен оценивать не только relevance, но и safety filters.

Evaluation of personalization

Personalization кажется простой: агент помнит предпочтения пользователя. На практике это одна из самых тонких частей memory layer.

Что нужно проверять:

• preference применен в правильной ситуации;
• preference не применен за пределами scope;
• current explicit instruction wins over old preference;
• preference не конфликтует с policy;
• sensitive inference не превращается в profile fact;
• пользователь может увидеть, исправить и удалить preference;
• personalization улучшает task outcome, а не просто делает ответ "похожим".

Пример хорошей персонализации:

Memory:
User prefers concise final summaries after code edits.

Task:
Agent edits three Markdown lessons.

Good behavior:
Final response briefly lists changed files and checks.

Пример плохой персонализации:

Memory:
User prefers concise final summaries after code edits.

Task:
User asks for a deep explanation of graph memory.

Bad behavior:
Agent gives a shallow answer because it over-applies concise preference.

Для personalization evaluation нужны не только labels "remembered/not remembered". Нужны labels "applied correctly", "over-applied", "under-applied", "unsafe", "outdated".

Evaluation of procedural learning

Procedural memory хранит способы выполнения задач: workflows, conventions, playbooks, repeatable decisions.

Для procedural learning важно проверять:

• агент выучил правильный process;
• process применен в похожей задаче;
• process не применен в неподходящем context;
• new correction обновила workflow;
• unsafe или accidental behavior не стал procedure;
• procedure не конфликтует с repo/project instructions.

Пример:

Episode:
User repeatedly asks to write lectures with:
- title
- goal
- expected result
- key terms
- diagram/table
- mistakes
- summary
- self-check questions

Future task:
"Write the next lecture."

Expected:
Agent follows the learned lecture-writing procedure.

Что измерять:

Procedural benchmarks пока сложнее стандартных retrieval tests, потому что expected result часто структурный, а не один факт.

Benchmarks для graph memory

Graph memory представляет память как entities and relationships.

Пример:

User -> works_on -> Project A
Project A -> uses -> Vector DB
Vector DB -> has_issue -> high latency
Project A -> replaced -> old search stack

Graph memory benchmarks проверяют:

• entity resolution;
• relation extraction;
• temporal edges;
• conflict handling;
• multi-hop reasoning;
• provenance;
• graph updates;
• deletion of nodes and edges;
• permission-aware traversal.

Пример вопроса:

"Почему мы заменили старый search stack в Project A?"

Expected path:

Project A -> old search stack -> high latency -> replaced by Vector DB

Graph memory полезна, когда много сущностей и связей: enterprise knowledge, CRM, research maps, long projects, multi-agent coordination.

Ограничение: высокий graph score не гарантирует хороший product behavior. Агент может правильно пройти по graph, но неправильно объяснить uncertainty, использовать stale edge или раскрыть private relation.

Ограничения академических бенчмарков

Академические benchmarks дают ясность, но production reality шире.

Частые ограничения:

• static datasets instead of evolving memory;
• мало или нет deletion tests;
• слабое покрытие privacy;
• мало adversarial poisoning;
• нет реальных latency/cost constraints;
• упрощенные user preferences;
• мало multi-tenant scenarios;
• labels не отражают subjective usefulness;
• evaluation не видит operational failures;
• memory write quality смешана с answer quality.

Пример:

Benchmark:
Agent recalls user's favorite city after 50 turns.

Production issue:
User later says the old preference is outdated.
Agent must update or stop using it.

Benchmark может дать высокий score, но не проверить update semantics.

Еще один пример:

Benchmark:
Top-5 retrieval contains relevant record.

Production issue:
Top-5 also contains private data from another tenant.

Retrieval metric выглядит хорошо, но system unsafe.

Как читать benchmark results

Когда вы видите claim "our memory system beats baseline", полезно задать вопросы:

1. Что именно было baseline?
2. Была ли memory persistent или только context-based?
3. Проверялись ли multiple sessions?
4. Были ли fact updates and conflicts?
5. Были ли deletion and user control?
6. Измерялись ли safety failures?
7. Были ли cost и latency?
8. Есть ли traces или только final score?
9. Похожи ли задачи на наш продукт?
10. Что происходит при noisy, partial или adversarial data?

Эти вопросы не обесценивают benchmark. Они помогают понять его область применимости.

Production evaluation как дополнение

Production evaluation должна связывать benchmark world с реальным продуктом.

Минимальный набор:

Production evaluation отвечает на вопрос:

Улучшает ли память пользовательский результат без неприемлемых рисков?

Это более важный вопрос, чем "какой benchmark score?".

Мини-кейс: personal assistant

Personal assistant может хорошо проходить benchmark на recall preferences:

User likes morning summaries.
Agent remembers morning summaries.

Но production evaluation должна проверить:

• remembered preference still valid;
• user explicitly consented;
• preference не применяется к sensitive contexts;
• assistant умеет объяснить and edit memory;
• morning summary не раскрывает private data на shared device;
• temporary preference не стала permanent.

Для personal assistant главные research questions:

• как сочетать personalization и privacy;
• как делать memory visible and editable;
• как предотвращать over-personalization;
• как учитывать changing identity and preferences.

Мини-кейс: coding agent

Coding agent benchmark может проверять, помнит ли агент convention:

Project uses pnpm and Vitest.
Agent runs correct commands.

Production evaluation должна добавить:

• current repo files override old memory;
• agent не применяет convention другого repo;
• failed command не становится permanent procedure;
• project instruction beats old preference;
• agent can explain why it selected command;
• memory does not store secrets from logs.

Для coding agents особенно важны procedural memory, project-scoped memory и source freshness.

Мини-кейс: enterprise knowledge agent

Enterprise agent может хорошо отвечать на retrieval benchmark, но провалиться на access control.

Production checks:

• tenant isolation;
• department permissions;
• source-level citations;
• retention rules;
• stale policy documents;
• conflicting documents;
• audit trail;
• deletion and legal holds;
• safe handling of employee/customer data.

Для enterprise memory score без governance почти ничего не значит. Память должна быть полезной и управляемой.

Исследовательское направление: persistent agents

Persistent agents - это агенты, которые существуют дольше одного запроса или одной сессии.

Они имеют:

• identity;
• long-term goals;
• memory state;
• tools;
• routines;
• user preferences;
• environment history;
• ability to resume work.

Главные вопросы:

• как хранить evolving goals;
• как отделять stable preference от temporary instruction;
• как забывать безопасно;
• как проверять memory integrity;
• как предотвращать drift;
• как делать agent behavior predictable.

Persistent agents требуют evaluation over time. Нельзя понять их качество по single-turn score.

Исследовательское направление: AgentOS

Идея AgentOS - представить agent runtime как слой, который управляет памятью, tools, permissions, identity, state и execution.

В таком подходе memory layer становится не локальной деталью prompt, а частью agent operating environment.

Возможные функции:

• unified memory API;
• policy engine;
• identity and permission model;
• tool registry;
• event log;
• memory lifecycle;
• observability;
• sandboxing;
• cross-agent coordination;
• user control surface.

Evaluation для AgentOS должна проверять не только model quality, но и system properties:

• isolation;
• reproducibility;
• auditability;
• rollback;
• deletion propagation;
• compatibility across tools;
• security boundaries.

Это направление важно, потому что память агента все чаще похожа на системный ресурс, а не на feature внутри одного prompt.

Исследовательское направление: decentralized memory protocols

Decentralized memory protocols - это идея, что memory может быть переносимой между приложениями, агентами или средами, при контроле пользователя.

Возможный сценарий:

User has a personal memory store.
Different agents request scoped access.
User grants or revokes permissions.
Memory records carry provenance and policy.

Потенциальные преимущества:

• user owns memory;
• less vendor lock-in;
• easier cross-agent continuity;
• explicit permissions;
• portable preferences;
• reusable knowledge across tools.

Сложности:

• trust between agents;
• consent UX;
• record format standards;
• revocation;
• encryption;
• provenance;
• conflict resolution;
• preventing poisoned shared memory;
• avoiding surveillance-like profiles.

Evaluation здесь должна включать security, privacy, interoperability and user agency. Обычные benchmarks retrieval quality этого не покрывают.

Будущие вопросы для исследований

Открытые вопросы memory research:

• как измерять usefulness памяти, а не только recall;
• как тестировать memory over months;
• как строить transparent memory for users;
• как делать safe forgetting;
• как оценивать procedural learning;
• как обнаруживать memory poisoning;
• как решать conflicts without overconfidence;
• как сочетать graph memory, vector memory и symbolic policies;
• как делать shared memory между агентами без leakage;
• как уменьшать cost and latency;
• как создавать benchmark datasets с realistic privacy constraints.

Memory systems пока находятся между research и engineering. Лучшие решения будут появляться на пересечении benchmarks, product telemetry, UX, security and operations.

Практическая рамка выбора benchmark

Перед выбором benchmark полезно заполнить простую таблицу.

Если benchmark не покрывает важный для продукта риск, его нужно дополнить своими tests.

Типичные ошибки

Ошибка 1: считать benchmark score доказательством production readiness.

Высокий score не проверяет privacy, deletion, cost и real user usefulness.

Ошибка 2: путать long context с long-term memory.

Большой prompt не решает persistence, update, forgetting и user control.

Ошибка 3: оценивать retrieval без grounding.

Найти правильную memory недостаточно. Агент должен корректно использовать ее в answer/action.

Ошибка 4: игнорировать negative cases.

Memory system должна знать, когда не использовать память.

Ошибка 5: не тестировать personalization scope.

Preference полезна только в правильном context.

Ошибка 6: переносить academic labels в продукт без адаптации.

Пользовательская полезность часто отличается от формальной relevance.

Ошибка 7: забывать operational metrics.

Index lag, cache bugs и async failures могут испортить memory behavior при хорошем benchmark score.

Краткое резюме

Бенчмарки нужны, чтобы сравнивать memory approaches, но они покрывают только часть картины. Для агентной памяти важны long-context, long-term conversation, multi-session, agent task, retrieval, grounding, personalization, procedural learning и graph memory evaluations.

Главная мысль: benchmark score должен быть одним сигналом, а не заменой production evaluation. Реальная memory layer должна быть полезной, актуальной, безопасной, управляемой и наблюдаемой.

Вопросы для самопроверки

1. Чем long-context benchmark отличается от проверки long-term memory?
2. Почему retrieval benchmark нужно дополнять grounding evaluation?
3. Какие ошибки personalization evaluation должна уметь ловить?
4. Почему procedural memory сложнее оценивать, чем simple fact recall?
5. Какие production checks обычно отсутствуют в академических benchmarks?

Что дальше

В следующей лекции мы перейдем от benchmark thinking к production observability: как трассировать memory read/write, retrieval, context assembly, deletion and online evaluation.