Урок 8.1. Метрики memory layer

Цель лекции

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

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

Читатель понимает, какие сигналы показывают качество и цену памяти: retrieval precision, retrieval recall, context density, answer grounding, freshness, conflict rate, hallucination rate, latency overhead, cost overhead и user correction rate.

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

Если агент с памятью отвечает плохо, легко сказать: "модель ошиблась". Но часто проблема не в модели, а в memory layer.

Примеры:

• нужная запись не была извлечена;
• извлечена похожая, но бесполезная память;
• в prompt попала устаревшая preference;
• source attribution потерялся;
• context window перегружен;
• пользователь исправляет одни и те же facts;
• память добавляет 3 секунды latency ради слабой пользы.

Качество памяти нужно измерять отдельно от общего качества ответа. Иначе команда не поймет, что улучшать: модель, retrieval, context assembly, write policy, update policy или privacy controls.

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

Memory layer нужно оценивать по тому, насколько он достает актуальные, полезные и безопасные воспоминания в нужный момент.

Хорошая память должна быть:

• релевантной;
• полной там, где это нужно;
• компактной;
• свежей;
• grounded;
• scoped;
• безопасной;
• недорогой по latency и cost;
• исправляемой пользователем.

Одна метрика не покажет всю картину. Нужна группа сигналов, которые покрывают read path, write path, context assembly, answer quality, safety и economics.

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

Карта метрик

Метрики нужно читать вместе. Например, высокий recall при низкой precision может означать over-retrieval: агент достает нужное, но вместе с кучей шума.

Retrieval precision

Retrieval precision отвечает:

Из того, что memory layer достал, сколько реально полезно?

Пример:

Retrieved 10 memories.
Useful for task: 4.
Precision = 4 / 10 = 40%.

Низкая precision означает retrieval noise.

Причины:

• слишком широкий query;
• top-k слишком высокий;
• нет scope filter;
• semantic similarity без reranking;
• stale records не снижены;
• weak memories не отфильтрованы.

Как улучшать:

• better query construction;
• hybrid retrieval;
• metadata filters;
• reranking;
• context budget;
• negative retrieval.

Precision особенно важна, потому что каждая лишняя запись занимает context window и внимание модели.

Retrieval recall

Retrieval recall отвечает:

Нашлась ли нужная память?

Пример:

Для задачи нужны 3 записи:
- project source of truth
- writing workflow
- user final-answer preference

Retrieved:
- project source of truth
- writing workflow

Recall = 2 / 3

Низкий recall означает under-retrieval.

Причины:

• запись не сохранена;
• запись не индексирована;
• query construction слабый;
• неправильный scope;
• нет keyword/entity index;
• read policy не искала нужный memory type.

Recall трудно измерять без golden datasets или human labels. Но для важных сценариев это нужно делать.

Precision vs recall

Precision и recall часто конфликтуют.

Зрелая система не выбирает одно навсегда. Она меняет стратегию по task type:

• для high-risk answers нужна высокая precision;
• для exploratory research допустим broader recall;
• для security/privacy лучше strict scope filters;
• для debugging важны exact keyword и entity recall.

Context density

Context density - доля полезного текста в context block.

Пример:

Memory block: 1200 tokens
Useful tokens: about 350
Context density: low

Низкая density означает, что memory layer тратит prompt на шум.

Сигналы низкой density:

• длинные raw logs;
• repeated facts;
• outdated summaries;
• unrelated memories;
• verbose source snippets;
• several versions of same fact;
• unresolved conflicts.

Как улучшать:

• compact memories;
• summarize episodes;
• deduplicate;
• group by type;
• include only active view;
• use source snippets, not full docs;
• measure token waste.

Context density связана с quality и cost одновременно.

Answer grounding

Answer grounding показывает, опирается ли ответ на правильные memories или sources.

Вопросы:

• использовал ли агент retrieved memory;
• использовал ли он правильную memory;
• есть ли source attribution;
• не исказил ли он source;
• не сослался ли на память, которой не было;
• не проигнорировал ли более authoritative source.

Пример плохого grounding:

Agent says project uses Jest because old memory said so,
although current package.json shows Vitest.

Пример хорошего grounding:

Agent says project uses Vitest and cites package.json/current project source.

Grounding можно оценивать human review, automated citation checks, answer-source consistency checks.

Memory freshness

Memory freshness оценивает актуальность записи.

Сигналы:

• last_confirmed_at;
• source updated_at;
• valid_from/valid_until;
• staleness risk;
• current source conflict;
• frequency of change in domain;
• time since last use.

Примеры:

Метрика:

stale_memory_usage_rate =
answers using stale memory / answers using memory

Нужно не просто иметь fresh records, а не inject stale records в active context.

Conflict rate

Conflict rate показывает, как часто active memory содержит противоречия.

Примеры conflicts:

• project uses Jest vs Vitest;
• user prefers short vs detailed answers;
• policy allows vs forbids action;
• two agents recorded different task status;
• summary contradicts raw event.

Метрики:

active_conflict_count
conflicted_records / active_records
conflict_resolution_time
conflicts_injected_to_prompt

Особенно важна метрика conflicts_injected_to_prompt. Конфликт в store еще можно обработать. Конфликт в prompt уже влияет на модель.

Hallucination rate при использовании памяти

Память должна снижать hallucinations, но иногда делает их убедительнее.

Примеры:

• модель неправильно обобщает retrieved memory;
• old memory подталкивает к неверному answer;
• source snippet вырван из контекста;
• agent смешивает facts из разных scopes;
• retrieved hypothesis используется как fact.

Метрика:

hallucination_rate_with_memory
vs
hallucination_rate_without_memory

Если память повышает hallucination rate, значит retrieval/context assembly вредят.

Важно разделять:

• model hallucination без memory;
• hallucination caused by bad memory;
• hallucination caused by bad interpretation of good memory.

Latency overhead

Latency overhead показывает, сколько времени добавляет memory layer.

Компоненты:

• read policy;
• query construction;
• vector search;
• keyword search;
• graph traversal;
• reranking;
• permission checks;
• context assembly;
• synchronous write;
• indexing.

Метрики:

p50 / p95 / p99 memory retrieval latency
total response latency with memory
memory overhead percentage
timeout rate

Иногда улучшение answer quality стоит extra latency. Иногда memory retrieval ради слабой пользы не оправдан.

Cost overhead

Cost overhead включает:

• token cost от injected memory;
• embedding cost;
• storage cost;
• vector/search/graph query cost;
• reranking cost;
• background jobs;
• audit logs;
• human review.

Важно считать не только storage.

Пример:

Memory storage costs little,
but injecting 3000 unnecessary tokens into every request is expensive.

Cost-aware memory design измеряет:

• average memory tokens per request;
• cost per successful memory-assisted task;
• cost of background consolidation;
• index growth;
• archive growth.

User correction rate

User correction rate показывает, как часто пользователь исправляет память или ответы, основанные на памяти.

Примеры corrections:

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

Метрика:

memory_corrections / memory-assisted interactions

Высокий correction rate может означать:

• over-personalization;
• stale memory;
• poor scope;
• bad extraction;
• invisible memory;
• missing user controls.

Correction rate - ценный продуктовый сигнал, не только технический.

Composite dashboard

Пример dashboard:

Retrieval:
- precision@5
- recall@5
- no-result rate
- scope filter violations

Context:
- average memory tokens
- context density
- conflict injection rate

Quality:
- grounded answer rate
- memory-caused hallucination rate
- task success with memory

Freshness:
- stale memory usage rate
- average last_confirmed age

Safety:
- PII write blocks
- unauthorized retrieval attempts
- deletion propagation success

Cost:
- p95 memory latency
- memory token cost/request
- embedding/indexing cost

User:
- correction rate
- opt-out rate
- memory acceptance rate

Dashboard не заменяет human evaluation, но помогает видеть системные деградации.

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

Для агента, который пишет курс, метрики могут быть такими:

• retrieval recall: нашел ли target lesson plan и content plan;
• retrieval precision: не подтянул ли unrelated module;
• context density: сколько injected context реально влияет на лекцию;
• freshness: использует ли актуальный план;
• correction rate: просит ли пользователь исправлять структуру;
• latency overhead: сколько времени добавляет чтение соседних файлов;
• grounding: соответствует ли лекция плану.

Пример failure:

Agent writes lesson 8.1 but не читает план lesson_08_01.

Это не writing failure в чистом виде. Это retrieval/read-policy failure.

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

Support agent memory metrics:

• account-scope retrieval accuracy;
• current CRM fact freshness;
• docs grounding;
• cross-tenant violation count;
• stale ticket usage;
• customer correction rate;
• p95 retrieval latency;
• internal-note reveal incidents.

Здесь precision важнее broad recall: лучше не использовать похожий ticket, чем случайно раскрыть чужой account.

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

Ошибка 1: оценивать только финальный ответ.

Нужно отдельно измерять retrieval, context assembly и memory update.

Ошибка 2: гнаться за recall без precision.

Много retrieved memory может ухудшить prompt.

Ошибка 3: не измерять freshness.

Старые facts могут выглядеть как успешный retrieval.

Ошибка 4: считать latency неважной.

Медленная память ухудшает продукт даже при хорошем качестве.

Ошибка 5: не связывать user corrections с memory records.

Correction должна показывать, какая запись была неверной.

Ошибка 6: не измерять safety metrics.

Для enterprise memory quality без privacy/isolation metrics неполна.

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

Метрики memory layer должны оценивать не только финальный ответ, но и работу памяти как системы: retrieval precision/recall, context density, answer grounding, freshness, conflict rate, hallucination rate, latency, cost и user correction rate.

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

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

1. Почему качество памяти нужно измерять отдельно от качества LLM?
2. Чем retrieval precision отличается от retrieval recall?
3. Что показывает context density?
4. Почему stale memory usage rate важнее, чем просто количество stale records?
5. Как user correction rate помогает улучшать memory layer?

Что дальше

В следующей лекции мы разберем практики тестирования памяти: unit tests, golden datasets, synthetic conversations, regression tests, adversarial tests, multi-session и time-travel scenarios, A/B experiments и observability.