Observability AI-пайплайнов: логи, трейсы, HITL, SLA

Observability AI-пайплайна в production — это связка session/trace ID, структурированных логов tool-calling, метрик качества и cost, human-in-the-loop на риск-зонах и алертов по error budget; без этого «агент в проде» остаётся демо с красивым UI.

Я не начинаю с выбора APM-бренда. Сначала фиксирую: что такое успешная сессия, какие side-effects допустимы, кого будить и за сколько минут. Ниже — рабочий каркас логов, трейсов, HITL и SLA, который я закладываю до масштабирования трафика.

---

Что именно нужно видеть (и в каком порядке)

Классические три столпа (logs / metrics / traces) для LLM-агентов недостаточны без eval-сигнала и политики.

Слой	Вопрос	Минимальный сигнал
Trace	Как прошла сессия end-to-end?	trace_id, spans: router → retrieve → reason → tool → guard → respond
Logs	Что решили и почему?	intent, policy_version, tool args/result (redacted), stop_reason
Metrics	Система здорова?	latency p95, error rate, token/session, queue lag
Quality	Ответы полезны?	auto-resolve %, re-open, thumbs, sample score
HITL	Где человек обязателен?	hitl_rate, wait_time, override_reason
Cost/SLA	Держим договорённость?	$/100 sessions, error budget burn

Обязательные поля события (чеклист)

• timestamp, env, service_version
• session_id, trace_id, span_id, parent_span_id
• channel, tenant_id (если multi-tenant)
• role / agent_name, model, prompt_version, policy_version
• tool_name, latency, status, error_code
• handoff_from / handoff_to, reason_code
• redaction flag для PII

Без версий промпта и policy разбор «почему вчера ок, сегодня нет» превращается в гадание.

---

Логи и трейсы: как не утонуть

Трейс одной боевой сессии (скелет)

1. ingress — webhook/UI, auth
2. route — intent + confidence
3. retrieve — KB/CRM read
4. plan — (опционально) список шагов
5. tool.* — каждый вызов отдельно
6. guard — policy check
7. generate — финальный ответ
8. egress — send + delivery status
9. hitl — если была пауза на человека

Антипаттерн	Почему больно	Замена
Один blob «llm_output»	нельзя фильтровать	structured JSON events
Логировать сырые карты/паспорта	комплаенс	mask/hash, token vault
Только success-path	инциденты невидимы	errors + retries + degrade
Трейс без tool I/O summary	«модель виновата» всегда	args hash + result code
100% debug в prod	cost и шум	sample debug, full on error

Я храню полный payload tool на ошибках и на sample 1–5% success; на остальном — метаданные и хэши. Иначе бюджет на storage съест выгоду автоматизации.

---

Human-in-the-loop как часть observability

HITL — не «костыль», а наблюдаемый контрольный контур.

Триггер HITL	Пример	Метрика
Low confidence	intent < порога	% escalated_by_confidence
Money / legal / med	скидка, договор, диагноз	% policy_hitl
Guard block	PII/jailbreak/stop-list	false_block rate
Tool failure cascade	3× 5xx CRM	degrade_to_human
Customer request	«позовите человека»	% explicit_human
Random QA sample	2–5% диалогов	reviewer_sla

Что логировать в HITL-span

• Почему остановили агента (reason_code)
• Что увидел оператор (контекст-пакет, не сырой dump)
• Решение: approve / edit / reject / take over
• Время ожидания в очереди и time-to-first-human
• Вернулся ли поток в агента после решения

Если HITL не измеряется, команда либо перегружает людей «на всякий случай», либо отпускает риск в автопилот.

---

Алерты и SLA для AI в проде

SLA агента я отделяю от SLA канала.

Класс	Пример целевого SLA	Алерт (идея)
Availability	успешный ingress ≥99.5% / мес	5xx spike 5 мин
Latency	first token / first useful reply p95	p95 > budget 10 мин
Tool health	CRM tool success ≥99%	error rate >2% 5 мин
Quality proxy	re-open < X%, guard miss = 0 critical/неделя	дневной burn quality budget
HITL	wait p95 < N мин в рабочее время	queue depth + oldest wait
Cost	$/session < cap	+40% rolling 1h vs baseline
Safety	0 немаркированных high-risk write	любой unguarded write

Error budget простыми словами

Допускаю, например, 0.5% «плохих» сессий в scope за месяц. Если burn rate высокий в начале недели — freeze релизов промптов/tools, не «подкрутим temperature».

Правила алертов, чтобы не выгореть

1. Алерт = действие (runbook ссылкой), не «интересный график».
2. Симптомы (user-facing) важнее причин (GPU util).
3. Дедуп и suppress на known degrade mode.
4. Ночные page — только safety, money write fail, полный down.
5. Quality-алерты — в рабочее время + on-call chat, пока нет доказанного user harm.

---

Минимальный дашборд на первую боевую неделю

• Sessions / hour, error %, p95 latency
• Top intents + % unknown
• Tool success heatmap
• HITL queue: depth, wait p95
• Tokens and $ / 100 sessions
• Auto-resolve in scope vs baseline
• Handoff hop-count outliers
• Версии: model / prompt / policy (annotation на графике релизов)

Чеклист «можно ли масштабировать трафик»

• Любой инцидент находится по session_id < 5 минут
• Есть shadow/canary и rollback промпта
• PII redaction проверен на sample
• Runbook на top-5 failure modes
• SLA и error budget согласованы с бизнесом письменно
• HITL не является единственной «метрикой качества»

---

Часто задаваемые вопросы

Чем observability агента отличается от мониторинга обычного API?

Добавляются стохастика модели, версии промпта/policy, качество ответа и HITL. HTTP 200 при токсичном или пустом смысле — всё ещё инцидент.

Нужен ли OpenTelemetry обязателен?

Не бренд, а контракт идентификаторов и spans. OTel удобен, если уже есть стек; JSON-логи + trace_id в ClickHouse тоже живут. Главное — сквозной ID.

Как алертить на «глупые» ответы, а не только на 500?

Прокси: spike re-open, падение auto-resolve, рост hitl_rate, LLM-judge на sample, anomaly по длине/отказу tools. Чистый semantic alert без выборки — шумный.

Сколько логов хранить?

Метаданные сессий — дольше (разбор споров, комплаенс); полные generation dumps — короче и/или sample. Срок — от отрасли и договора, не «как получится на диске».

---

Читайте также

• 7 ошибок production AI-агентов и handoff
• Оркестрация tool calling, SOP и audit AI-агента
• TCO AI-агента: KPI и стоимость владения 30–90 дней
• AI-агент: tools, память, HITL и запуск

---

Нужен аудит observability вашего AI-контура и нормальный SLA до масштабирования — raisovich.ru

Какие идентификаторы обязательны в логах AI-сессии?

session_id, trace_id, span/parent, model и prompt/policy_version, tool name/status и stop_reason — без сквозного ID разбор инцидента дольше пяти минут и observability формальная.

Как связать HITL с SLA агента, а не только канала?

Отдельно меряю hitl_rate, wait p95 очереди и override_reason; HITL — часть error budget и quality proxy, а не «единственная метрика качества» вместо auto-resolve и re-open.

Что должно быть на дашборде в первую боевую неделю?

Sessions/hour, error % и p95, tool success, HITL queue, $/100 sessions, auto-resolve vs baseline и аннотации релизов model/prompt/policy — без этого масштабировать трафик рано.