Дашборды: latency, cost,
error rate, quality

Зачем дашборд, если есть трейсы и логи

Трейс отвечает на «что случилось в этом запросе», лог — «найди события по фильтру». Но ни то, ни другое не отвечает на главный операционный вопрос: «с системой сейчас всё в порядке?» Чтобы ответить, нужно агрегировать тысячи запросов в несколько чисел и графиков во времени. Это метрики — третий столп observability (после traces и logs из прошлых уроков).

Дашборд — это витрина метрик: набор панелей, где одним взглядом видно тренды и аномалии. Его задача — заметить проблему раньше пользователя и дать понять, где копать (а детали уже смотришь в трейсах по trace_id).

Четыре ключевые метрики агента

У LLM-агента здоровье описывают четыре измерения. Первые два — классика любого сервиса, вторые два — специфика LLM, и именно их чаще всего забывают.

Разберём по одной:

⏱ Latency — скорость

Сколько пользователь ждёт ответа. У агентов латентность высокая и составная: сумма LLM-вызовов, инструментов, retrieval. На дашборде полезны разбивка по этапам (где узкое место) и — при стриминге — TTFT (time to first token): пользователю важно, как быстро начался ответ, а не только когда закончился.

💰 Cost — деньги

LLM-специфика №1. Каждый токен стоит денег, и на объёме это ощутимо. Метрики: $/день, $/запрос, токены in/out, разбивка по модели/фиче/пользователю. Отдельно — cache hit rate (сколько сэкономил prompt caching). Именно cost-дашборд ловит «внезапно кто-то зациклил агента, и он сжёг месячный бюджет за ночь».

🚨 Error rate — надёжность

Доля неуспешных запросов и её структура: ошибки провайдера (5xx), таймауты, падения инструментов, rate limits (429). Полезно видеть отдельно retry rate и fallback rate — система может «держать» error rate низким за счёт ретраев, но рост ретраев сам по себе сигнал.

✅ Quality — польза

LLM-специфика №2 и самая коварная. Технически всё зелёное — быстро, дёшево, без ошибок, — а агент выдаёт неправильные ответы. Технические метрики этого не видят. Прокси качества на дашборде: LLM-as-judge score на сэмпле прода, пользовательский фидбек (👍/👎), task success rate, доля fallback. Ключевое — ловить регрессию качества после изменения промпта/модели.

Перцентили, а не среднее

Критично важный принцип, на котором ломается большинство новичков: среднее (average) по латентности бесполезно и обманчиво. Среднее прячет хвост — а именно в хвосте живут страдающие пользователи.

1000 запросов: 950 быстрых (200ms) + 50 медленных (8000ms)

СРЕДНЕЕ = ~590ms   → «вроде норм»           ❌ прячет проблему
p50 (медиана) = 200ms  → половине быстро
p95 = ~8000ms      → каждый 20-й ждёт 8 секунд!  ✅ виден хвост
p99 = ~8000ms      → 1% совсем плохо

Вывод: 5% пользователей мучаются, а среднее это скрыло.

Перцентиль pN — значение, ниже которого лежит N% запросов. p95 = «95% быстрее этого, 5% медленнее». Смотри на p50/p95/p99, а не на average: медиана показывает типичный опыт, а p95/p99 — насколько плохо худшим. Для агентов с их «толстым хвостом» латентности (какой-то запрос ушёл в 10 итераций) это особенно важно.

Как собрать дашборд: RED-метод

Чтобы не тонуть в бесконечных панелях, используй проверенный каркас. RED-метод (Rate, Errors, Duration) — минимальный стандартный набор для любого сервиса, к которому у агента добавляются Cost и Quality:

Источники метрик у тебя уже есть из прошлых уроков: latency и токены — из трейсов/OTel spans (там же gen_ai.usage.*_tokens → стоимость), error rate и события — из structured-логов, quality — из оценщиков LangSmith/Langfuse. Дашборд — это витрина поверх уже собранных сигналов. Строят их обычно в Grafana (по метрикам из Prometheus/Loki), в Datadog или прямо в UI Langfuse/LangSmith.

from prometheus_client import Counter, Histogram

# метрики агента, которые соберёт Prometheus и покажет Grafana
REQUESTS = Counter("agent_requests_total", "Запросы", ["status"])
LATENCY  = Histogram("agent_latency_seconds", "Латентность")   # даёт перцентили
COST     = Counter("agent_cost_usd_total", "Стоимость", ["model"])

def handle(question: str):
    with LATENCY.time():                       # автоматически меряет длительность
        try:
            answer, usage = run_agent(question)
            REQUESTS.labels(status="ok").inc()
            COST.labels(model="gpt-4o").inc(usage.cost)   # копим стоимость
            return answer
        except Exception:
            REQUESTS.labels(status="error").inc()          # error rate
            raise
# Grafana поверх: p95 от agent_latency_seconds, rate(agent_requests_total{status="error"}),
#                 sum(agent_cost_usd_total) — панели дашборда

SLO и алерты

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

• SLO (Service Level Objective) — целевая планка: «p95 latency < 3s», «error rate < 1%», «uptime 99.9%». Это обещание о качестве сервиса, по которому меряют здоровье.
• Alert — правило, которое срабатывает при нарушении порога («error rate > 2% за 5 минут → позвать дежурного»). Алерт должен вести к действию, а не быть фоновым шумом.

Для LLM-агента типичный минимум алертов: error rate > порога, p95 latency > SLO, дневной cost > бюджета (защита от «зациклился и сжёг деньги»), падение quality-score ниже базовой линии (ловит регрессию промпта).

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

Шпаргалка

МЕТРИКА = число во времени (агрегат) — 3-й столп observability (traces/logs/METRICS)
  дашборд замечает аномалию → трейс/логи объясняют причину («что» vs «почему»)

4 КЛЮЧЕВЫЕ МЕТРИКИ АГЕНТА:
  ⏱ LATENCY  — скорость: p50/p95/p99 + TTFT + разбивка LLM/tools/retrieval  [классика]
  💰 COST    — токены=деньги: $/день, $/запрос, in/out, cache hit rate       [LLM!]
  🚨 ERRORS  — надёжность: % ошибок по типам + retry/fallback rate + 429     [классика]
  ✅ QUALITY — польза: LLM-as-judge, 👍/👎, task success, регрессия промпта  [LLM! критично]
  latency+errors = «работает ли» · cost+quality = «выгодно и полезно ли»

ПЕРЦЕНТИЛИ, НЕ СРЕДНЕЕ:
  average прячет хвост! p95=«5% медленнее этого» → видит страдающих
  SLO/алерты ТОЛЬКО по перцентилям (p95<3s), не по average

RED-МЕТОД (+ Cost/Quality для LLM):
  Rate (нагрузка) · Errors (% ошибок) · Duration (latency p*) · +Cost · +Quality
  источники: latency/токены←OTel spans · errors←логи · quality←LangSmith/Langfuse
  строят: Grafana/Prometheus · Datadog · UI Langfuse/LangSmith

SLO = целевая планка (p95<3s, errors<1%) · ALERT = правило при нарушении → ДЕЙСТВИЕ
  минимум алертов LLM: error rate · p95 latency · дневной cost(!) · падение quality
  ⚠️ alert fatigue: алертуй только на требующее вмешательства, остальное — на дашборд

ГРАБЛИ: среднее вместо p* · без cost/quality · метрики без связи с трейсами · алерты на всё

Практическое задание

Что дальше

Раздел Observability и мониторинг закрыт: ты умеешь трейсить (LangSmith, Langfuse, OTel), логировать и строить дашборды с алертами. Quality-метрика на дашборде — лишь верхушка: как именно измерять качество LLM-систем строго и повторяемо, разбирает следующий раздел — «Оценка качества LLM-систем», начиная с offline-метрик и кастомных scorers.