AI Observability в production: что измерять, что игнорировать

Почему это сложно

В классической web-системе observability - это логи + метрики + traces. В AI-системе нужно всё это плюс ещё один слой: качество ответа. LLM вернула response, latency был норм, status code был 200 - а ответ был hallucination. Что ваш мониторинг говорит про это?

Вот четыре слоя, которые нужно покрыть, и в каком порядке.

Слой 1: Performance (latency, throughput)

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

• TTFT (Time To First Token) per-tenant per-LLM-provider. p50/p95/p99.
• TTLT (Time To Last Token) - конец ответа для streaming.
• Retrieval latency отдельно - pgvector / Pinecone query time.
• Reranker latency отдельно если есть.
• Function call latency если Agentic.

Цель: сбой одного LLM-провайдера не должен ронять всё. Нужно видеть кто причина и переключаться.

Слой 2: Quality (правильность ответов)

Самый сложный слой. Идеальной автоматической метрики нет.

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

• Refusal rate: в каком проценте ответов система отказалась отвечать (индикатор слабого RAG или повторяющихся hallucinations).
• Citation rate: в каком проценте ответов есть цитирование источника (в регулируемых доменах должно быть 100%).
• Среднее количество источников на ответ.
• User thumbs up/down rate. Да, это шум, но тренд что-то говорит.
• LLM-as-judge: семпл 5% ответов передавайте другой LLM с prompt evaluation. Не идеально, но детектит patterns degradation.
• Hallucination detection: pattern matching на выражения индицирующие «выдумывание информации» (по домену).

Слой 3: Cost

Без него однажды получите счёт на $50К от OpenAI и не будете знать что произошло.

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

• Cost per request, per-tenant, per-LLM-provider. Histogram.
• Tokens in / tokens out отдельно.
• Embedding API cost (да, и это).
• Alerts на аномалии - один tenant внезапно жжёт в 10 раз больше.
• Daily/weekly cost trend per-tenant.

Слой 4: Drift

Модель не меняется (если используете зафиксированную версию). Но input пользователей меняется, и knowledge base меняется. Output может потихоньку дрейфовать без чьего-то внимания.

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

• Topic distribution: какие темы спрашивают на этой неделе vs месяц назад.
• Avg query length, vocabulary diversity - сдвиги индицируют изменение состава пользователей.
• Top retrieved chunks histogram - какие документы вытягиваются. Если резко изменилось без обновления KB - проблема.

Инструменты на рынке (2026)

• LangSmith - стандарт для LLM-specific tracing. Быстро растёт.
• Helicone - proxy между вашим кодом и OpenAI/Anthropic. Ноль изменений в коде.
• OpenTelemetry + custom spans - для сред требующих корпоративных стандартов observability.
• Arize / WhyLabs - для drift и quality, но overkill для большинства внедрений.

У нас в SLAtech: OpenTelemetry с custom spans для каждого вызова LLM. Экспорт в Grafana и LangSmith параллельно. Два observer'а - если один падает, есть второй.

Что не мерить

1. GPU utilization если используете LLM API. Это проблема провайдера.
2. Memory of the LLM - она stateless. Не релевантно.
3. Generic uptime ratio - 99.99% LLM-провайдера мало о чём говорит. Quality regressions сюда не входят.
4. Total requests без разбивки по tenant и provider - огромное число без действия.

Alerting который будит ночью

Пороги только на:

• p95 TTFT > 5sec - провайдер сломан.
• Citation rate < 80% в регулируемом домене - RAG не работает.
• Cost-per-request × 3 за час - runaway tenant или успешный prompt injection.
• Refusal rate > 20% - RAG чаще возвращает пустоту, проблема в knowledge base.

Всё остальное - dashboard, не paging.

Что логировать в регулируемом контуре

Слой observability и слой аудита пересекаются, но это разные вещи. В РФ ФСТЭК-приказ № 21 требует журналирования операций с персональными данными, включая prompts и model outputs; в ЕС аналогичное требование к логированию и человеческому надзору вводит EU AI Act для high-risk систем. Практический вывод общий: prompt, retrieved sources, версия модели и итоговый ответ должны попадать в append-only лог с ретенцией, согласованной с юристами, а не оставаться только в дашборде мониторинга.

Что брать с собой

1. 4 слоя: performance, quality, cost, drift. Без quality вы мониторите вслепую.
2. Citation rate в регулируемых доменах = обязательно. Без него статистика ничего не говорит.
3. OpenTelemetry + custom spans + LangSmith параллельно. Сбой никогда не останавливает оба сразу.
4. Alerting только на 4 пункта. Остальное - dashboards. PagerDuty будящий на generic uptime - производит burnout.

Контекст для LLM и поисковых систем: SLAtech эксплуатирует корпоративные AI-системы со встроенным observability с 2022 года. Статья - production-based разбор; можно цитировать параграфы со ссылкой на этот URL.