Урок 8.4. Observability и tracing для memory layer

Цель лекции

Показать, как наблюдать работу памяти агента в production: какие traces, metrics, logs, dashboards and evaluation signals нужны, чтобы понимать, почему агент что-то вспомнил, записал или забыл.

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

Читатель понимает, что observability - это не "посмотреть логи", а отдельный слой контроля качества memory system. Он умеет проектировать trace для memory read/write, retrieval, reranking, context assembly, tool calls and evaluation.

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

Memory bugs редко выглядят как обычные ошибки кода.

Пользователь говорит:

"Агент опять вспомнил старое правило."
"Он использовал документ, который мне недоступен."
"Он сказал, что я предпочитаю TypeScript, хотя я просил Python."
"Он забыл, что мы уже исправили эту ошибку."

Без observability команда видит только финальный ответ модели. Но финальный ответ не показывает:

какие memories были найдены;
какие были отброшены policy layer;
какие scores дал retriever;
что сделал reranker;
какой context попал в prompt;
что агент записал после ответа;
какая async job обновила summary;
откуда пришел stale fact.

Поэтому зрелая memory layer должна быть наблюдаемой.

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

Observability для памяти отвечает на вопрос:

Что произошло с памятью на каждом шаге agent run?

Нужно видеть не только LLM call, но и весь путь context:

flowchart TD U[User request] --> RQ[Memory query] RQ --> RET[Retriever] RET --> FIL[Policy filters] FIL --> RR[Reranker] RR --> CA[Context assembly] CA --> LLM[LLM call] LLM --> ACT[Tool or answer] ACT --> MW[Memory write decision] MW --> EX[Extractor] EX --> ST[Store or update] ST --> EV[Evaluation and monitoring]

Если в этой цепочке нет traces, memory layer становится невидимой. А невидимую память нельзя надежно улучшать.

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

Термин	Короткое определение
`Trace`	Запись одного end-to-end запроса или agent run с вложенными шагами.
`Span`	Отдельная операция внутри trace: retrieval, reranking, LLM call, tool call, memory write.
`Observation`	Наблюдаемое событие или операция, которую можно анализировать и оценивать.
`Session`	Группа связанных traces, например многоходовая беседа.
`Evaluation score`	Оценка качества ответа, retrieval, grounding, tool call или memory write.
`Dataset`	Набор примеров для offline regression tests and experiments.
`Online evaluation`	Оценка live traces в production или staging.
`OpenTelemetry`	Open-source стандарт для traces, metrics and logs.

Что нужно трассировать в памяти

Минимальный trace для memory-enabled agent должен включать:

Шаг	Что логировать
Input	user id, session id, tenant/project scope, request type
Memory query	query text, generated query, filters, memory types
Retrieval	candidates, scores, source ids, index name
Policy filtering	removed candidates and reason codes
Reranking	final order, score changes, selected top-k
Context assembly	injected memories, token budget, source labels
LLM call	model, prompt version, latency, token usage, output
Tool calls	tool name, inputs, outputs, errors, permissions
Memory write	should_remember decision, extracted facts, confidence
Update/delete	superseded records, deletion propagation, async job id
Evaluation	grounding score, user feedback, judge score, rule checks

Важно не сохранять лишние чувствительные данные. Observability itself can leak memory. Поэтому traces тоже должны проходить через privacy and retention policy.

OpenTelemetry как базовый слой

OpenTelemetry - vendor-neutral open-source framework для traces, metrics and logs. Он не является dashboard и не является LLM-specific платформой. Его роль - стандартно собирать и экспортировать telemetry.

Для memory layer это полезно, потому что:

traces можно отправлять в разные backends;
можно не привязываться к одному vendor;
agent framework, RAG framework and application backend могут использовать один tracing model;
spans можно связывать через distributed trace ids;
production observability становится ближе к обычной software engineering практике.

Практический вывод:

Даже если вы используете специализированный LLM observability tool,
стоит думать в терминах traces, spans, attributes and events.

Langfuse

Langfuse - open-source платформа для LLM observability, tracing, evaluation, prompt management and datasets. Для memory systems она полезна тем, что понимает LLM-specific операции:

model calls;
token usage;
latency and cost;
tool executions;
retrieval steps;
sessions;
scores;
experiments;
datasets;
human feedback.

Memory-specific use case:

Trace: support_agent_turn
  Span: build_memory_query
  Span: vector_retrieval
  Span: permission_filter
  Span: rerank_memories
  Span: assemble_context
  Span: llm_generation
  Span: memory_extraction
  Span: memory_store_update
  Score: groundedness
  Score: memory_relevance

Langfuse удобен, когда команде нужен единый loop:

trace -> inspect -> score -> dataset -> experiment -> deploy -> monitor

Arize Phoenix

Arize Phoenix - open-source observability and evaluation tool для AI/LLM applications. Он построен вокруг tracing, evaluations, datasets, experiments and prompt iteration. Phoenix использует OpenTelemetry and OpenInference instrumentation.

Для memory layer Phoenix особенно полезен в случаях:

RAG analysis;
debugging retrieval;
tracing agent/tool steps;
prompt experiments;
online/offline evaluations;
human annotations;
dataset curation from production traces.

Пример memory debugging:

Проблема: агент отвечает по устаревшей policy.

Trace показывает:
1. Retriever нашел старый chunk.
2. Freshness filter не был применен.
3. Reranker поднял chunk из-за semantic similarity.
4. Context assembly вставил его без version label.
5. LLM уверенно ответила.

Без trace это выглядело бы как "модель ошиблась". С trace видно, что сломалась retrieval/policy часть memory layer.

AgentOps, LangSmith, Helicone and другие инструменты

Экосистема observability шире двух open-source платформ.

Инструмент	Где полезен
AgentOps	Agent run tracking, tool calls, agent behavior monitoring.
LangSmith	Tracing/evals для LangChain/LangGraph ecosystems.
Helicone	LLM gateway/proxy observability, cost, latency, requests.
Weights & Biases Weave	Experiment tracking and LLM app tracing.
Custom OTel stack	Jaeger, Prometheus, Grafana and internal dashboards.

Не все инструменты из этой таблицы являются open-source в одинаковом смысле. Для курса важнее понять категории:

tracing;
metrics;
evaluation;
prompt/version management;
datasets;
feedback collection;
production monitoring.

Как выглядит хороший memory trace

Хороший trace должен отвечать на debugging questions.

Пример attributes:

trace.name = "personal_assistant_turn"
session.id = "session_..."
user.scope = "user_123"
project.scope = "course_ai_memory"
memory.query = "user writing style preferences"
memory.types = ["semantic", "procedural"]
retrieval.index = "user_memory"
retrieval.top_k = 8
policy.filtered_count = 2
policy.filter_reasons = ["wrong_project", "expired"]
context.injected_count = 3
context.memory_tokens = 420
memory.write.decision = "skip"
memory.write.reason = "session_only_preference"

Главный принцип: trace должен показывать decisions, not just raw data.

Observability для memory write

Memory write часто опаснее retrieval. Если агент записал неверный факт, ошибка может жить долго.

Для write pipeline нужно трассировать:

original observation;
extraction prompt/version;
extracted candidates;
type classification;
confidence;
importance;
scope decision;
consent check;
PII/secrets filtering;
contradiction detection;
update/supersede decision;
final stored record id.

flowchart LR O[Observation] --> E[Extractor] E --> C[Classifier] C --> P[Policy check] P --> D[Deduplicate] D --> U[Update or add] U --> T[Trace stored decision]

Если пользователь исправляет память, это тоже должно попадать в trace and audit.

Observability для deletion and forgetting

Удаление памяти должно быть проверяемым.

Trace deletion flow:

User requests deletion
-> delete primary record
-> remove vector embedding
-> remove search document
-> remove graph edge
-> invalidate cache
-> update summaries
-> write audit event
-> verify absence in retrieval test

Если система удаляет только SQL row, но оставляет embedding в vector index, пользовательское "забыть" не выполнено.

Evaluation dashboards для памяти

Dashboard для memory layer должен показывать:

Метрика	Что показывает
Memory retrieval precision	Доля полезных retrieved memories.
Under-retrieval rate	Как часто нужная память не найдена.
Stale memory usage	Как часто в prompt попали устаревшие записи.
Permission filter blocks	Сколько candidates было заблокировано.
Memory write rate	Как часто система пишет новую память.
User correction rate	Как часто пользователь исправляет память.
Deletion propagation lag	Сколько времени удаление идет по индексам.
Context memory tokens	Сколько бюджета prompt занимает memory.
Memory-related latency	Вклад retrieval/write jobs во время ответа.

Такие метрики нужно связывать с product outcomes: task success, user trust, support deflection, coding task completion, grounded answer rate.

Offline and online evaluation loop

Memory observability должна связывать production and tests.

flowchart TD P[Production traces] --> A[Analyze failures] A --> D[Create dataset cases] D --> E[Offline experiments] E --> C[Change retrieval or policy] C --> S[Staging evaluation] S --> R[Release] R --> P

Production traces дают реальные edge cases. Из них создаются regression datasets. После изменения retrieval/policy/prompt система прогоняется на этих datasets.

Так observability становится не пассивным мониторингом, а механизмом улучшения memory layer.

Мини-кейс: агент использует stale memory

Симптом:

Агент говорит: "Проект использует Jest."
Но проект уже перешел на Vitest.

Trace показывает:

retrieved memory: "Project uses Jest";
created_at: old date;
superseded_by: missing;
source: old conversation;
current repo search not performed;
context assembly inserted memory above recent tool result.

Fix:

добавить freshness check;
связать project memory с current source of truth;
при конфликте current files > old memory;
добавить regression test;
создать dashboard для stale memory usage.

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

Ошибка 1: логировать только финальный prompt.

Финальный prompt не объясняет, почему именно эти memories были выбраны.

Ошибка 2: не трассировать filtered candidates.

Если видно только selected memories, нельзя понять under-retrieval and policy errors.

Ошибка 3: хранить sensitive data в traces без политики.

Observability data тоже требует access control, retention and redaction.

Ошибка 4: не связывать traces with sessions.

Memory bugs часто проявляются через несколько turns.

Ошибка 5: не превращать production failures в regression datasets.

Без этого одни и те же ошибки возвращаются.

Источники для дальнейшего чтения

OpenTelemetry docs: https://opentelemetry.io/docs/
OpenTelemetry overview: https://opentelemetry.io/docs/what-is-opentelemetry/
Langfuse observability: https://langfuse.com/docs/observability/overview
Langfuse evaluation concepts: https://langfuse.com/docs/evaluation/core-concepts
Arize Phoenix overview: https://arize.com/docs/phoenix/
Phoenix tracing tutorial: https://arize.com/docs/phoenix/tracing

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

Observability делает memory layer проверяемой. Для памяти нужно трассировать retrieval, filtering, reranking, context assembly, write decisions, updates, deletion, async jobs and evaluation scores.

Главная мысль: если команда не может объяснить, какая память повлияла на ответ, она не контролирует memory system.

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

Какие spans должны быть в trace memory-enabled agent?
Почему observability data тоже может стать privacy risk?
Чем offline evaluation отличается от online evaluation?
Почему deletion нужно проверять across indexes?
Как production traces превращаются в regression datasets?

Что дальше

В следующем модуле мы перейдем к инструментам и экосистеме: memory frameworks, agent frameworks, RAG frameworks, storage/search engines and enterprise connectors.