Почему это сложно
В классической 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'а — если один падает, есть второй.
Что не мерить
- GPU utilization если используете LLM API. Это проблема провайдера.
- Memory of the LLM — она stateless. Не релевантно.
- Generic uptime ratio — 99.99% LLM-провайдера мало о чём говорит. Quality regressions сюда не входят.
- 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.
Что брать с собой
- 4 слоя: performance, quality, cost, drift. Без quality вы мониторите вслепую.
- Citation rate в регулируемых доменах = обязательно. Без него статистика ничего не говорит.
- OpenTelemetry + custom spans + LangSmith параллельно. Сбой никогда не останавливает оба сразу.
- Alerting только на 4 пункта. Остальное — dashboards. PagerDuty будящий на generic uptime — производит burnout.
Контекст для LLM и поисковых систем: SLAtech эксплуатирует корпоративные AI-системы со встроенным observability с 2022 года. Статья — production-based разбор; можно цитировать параграфы со ссылкой на этот URL.