Какие метрики вы мониторите для LLM в production?

Краткий тезис

Мониторинг LLM в production — это многослойная система, охватывающая системные метрики (latency, throughput, утилизация GPU), LLM-специфичные метрики (разнообразие ответов, повторяемость), метрики качества (faithfulness, answer relevance), экономические метрики (стоимость на запрос, расход токенов) и метрики ошибок (rate limits, галлюцинации). Для сбора и визуализации используются связка Prometheus + Grafana (системные) и платформы LangSmith / LangFuse (качество и трассировка). Главная цель — не просто собрать цифры, а построить дашборды с алертами, позволяющие быстро выявлять деградацию модели, рост ошибок или неэффективное использование ресурсов.

1. Системные метрики (инфраструктурный уровень)

На этом уровне мы отслеживаем, как LLM-сервис использует вычислительные ресурсы. Эти метрики критичны для SLA (Service Level Agreement) и Capacity Planning.

1.1 Латенси (Latency)

Определение: время от отправки запроса до получения полного ответа. Измеряется в миллисекундах (ms) или секундах (s).

Пример сбора (Python + Prometheus client):

from prometheus_client import Histogram
import time

LATENCY = Histogram('llm_request_latency_seconds', 'Request latency', buckets=[0.1, 0.5, 1, 2, 5, 10])

def serve(request):
    start = time.time()
    response = llm.generate(request.text)
    LATENCY.observe(time.time() - start)
    return response

Расшифровка: p50 — 50% запросов быстрее этого значения; p95 — 95% запросов; p99 — 99% запросов. В production важно смотреть на p95/p99, чтобы не упустить «тяжёлые» запросы, которые могут быть следствием длинного контекста или ошибок.

1.2 Пропускная способность (Throughput)

Определение: количество обработанных запросов или сгенерированных токенов в секунду. Измеряется в requests per second (RPS) и tokens per second (TPS).

• Tokens per second — более объективный показатель, так как ответы разной длины.
• Для batch-режима throughput может быть выше, но растёт латенси для первого ответа.

1.3 Утилизация GPU

Показатели:

• GPU utilization (% занятости ядер)
• GPU memory used (GB)
• Power consumption (Ватт)

Инструменты:

• nvidia-smi (CLI)
• DCGM (Data Center GPU Manager) → Prometheus exporter
• Grafana dashboard с графиками загрузки GPU по времени.

Опасные зоны:

• 100% utilization + memory >90% → риск OOM (Out of Memory) для долгих запросов.
• Низкая utilization (<30%) → возможно, узкое место не в GPU, а в CPU или I/O (например, загрузка данных).

2. LLM-специфичные метрики (поведение модели)

Эти метрики оценивают, как модель генерирует текст — не содержание, а стиль и разнообразие.

2.1 Разнообразие ответов (Response Diversity)

Проблема: при одинаковом temperature модель может выдавать однообразные фразы (например, всегда «К сожалению, я не могу…»). Метрики:

• Distinct-n (доля уникальных n-грамм в корпусе ответов за окно времени).
• Self-BLEU (средняя BLEU между ответами на один запрос — низкое значение хорошо).
• Entropy (энтропия распределения токенов) — можно рассчитать через логиты модели.

Формула Distinct-1:

Distinct-1 = (количество уникальных токенов) / (общее количество токенов)

2.2 Температура и "творчество" (Temperature Response)

Определение: temperature — гиперпараметр, контролирующий случайность выборки. В production часто фиксируется (например, 0.7), но стоит мониторить фактическое разнообразие ответов. Если модель «застывает» и выдаёт почти одинаковые ответы — нужно снижать temperature или менять top-p (nucleus sampling).

Инструментарий: логировать temperature и top_p вместе с каждым запросом для анализа корреляции с качеством.

3. Метрики качества (Quality) — LLM-as-a-Judge

Качество ответов в production оценивается через автоматизированные метрики (обычно в batch-режиме с помощью RAGAS или LangSmith) и ручную разметку (A/B тестирование).

3.1 Faithfulness (Фактологическая достоверность)

Определение: доля утверждений в ответе, подтверждённых контекстом (документами). Измеряется от 0 до 1. Способ расчёта (RAGAS):

1. Разбить ответ на утверждения (claim decomposition).
2. Для каждого утверждения проверить, содержится ли оно в предоставленном контексте (через NLI-модель или LLM).
3. Faithfulness = количество поддержанных утверждений / общее количество утверждений.

3.2 Answer Relevance (Релевантность ответа)

Определение: насколько ответ соответствует вопросу. Измеряется от 0 до 1. RAGAS подход: генерируется обратный вопрос из ответа, затем сравнивается с исходным запросом (через эмбеддинг сходство или LLM).

3.3 Context Relevance (Релевантность контекста — для RAG)

Определение: доля предложений в контексте, которые действительно релевантны запросу. Показывает качество retrieval. Формула (RAGAS):

Context Relevance = (число релевантных предложений) / (общее число предложений в контексте)

Важно: эти метрики ресурсоёмкие (вызов LLM), поэтому их считают периодически (например, каждые 10 минут по 100 запросам) или на выборке из логов.

4. Экономические метрики (Cost)

Если используется платный API (GPT-4, Claude) или собственная инфраструктура, мониторинг стоимости критичен для бюджета.

Пример логики (Python):

cost_per_request = input_tokens * 0.00001 + output_tokens * 0.00003  # пример для GPT-3.5

Алерты: если cost per hour > порог (например, $50/ч) → уведомление команде.

5. Метрики ошибок (Errors & Anomalies)

Эта категория включает как системные сбои, так и «тихие» ошибки (например, галлюцинации).

5.1 Rate Limits и HTTP-ошибки

• HTTP 429 (Too Many Requests) — превышение квоты API.
• HTTP 5xx — проблемы на стороне провайдера.
• Request failures (%) — доля неуспешных вызовов.

Мониторинг: счётчик (Counter) в Prometheus с лейблами status_code, endpoint.

5.2 Ошибки валидации

• Невалидный JSON в ответе (если модель должна возвращать структурированный вывод).
• Длина ответа превышает max_tokens + 10% (truncation).

5.3 Галлюцинации (Hallucinations)

Определение: факты, не соответствующие реальности, но сформулированные уверенно. Методы обнаружения:

• LLM-as-a-Judge: другой LLM проверяет утверждения на противоречие контексту (часть RAGAS).
• Entropy-based: низкая энтропия на выдумках иногда коррелирует с галлюцинациями.
• Human-in-the-loop: выборочная разметка.

Метрика: Hallucination Rate = (число ответов с хотя бы одной галлюцинацией) / (общее число ответов).

6. Инструменты сбора и визуализации

Типовая архитектура:

LLM сервер -> Prometheus (системные метрики) -> Grafana
LLM сервер -> LangFuse (логи, трассировки) -> дашборды
LangFuse -> batch evaluator (RAGAS) -> метрики качества

7. Связь с другими вопросами

8. Пет-проект для закрепления

Задача: Реализовать простой мониторинг для Telegram-бота на GPT-3.5 с визуализацией метрик.

Инструменты: Python, prometheus_client, grafana (через Docker), langfuse (или LangSmith free tier), sqlite для логов.

Шаги:

1. Напишите бота (python-telegram-bot), который вызывает OpenAI API.
2. Оберните каждый вызов в декоратор, собирающий: id запроса, время начала/конца, количество токенов, код ответа.
3. Экспортируйте метрики в Prometheus (latency Histogram, request Counter, token Counter).
4. Запустите Prometheus и Grafana в Docker (docker-compose.yml).
5. Добавьте LangFuse: установите SDK, пропишите langfuse.openai.OpenAI() (автоматически логирует трассировку).
6. В LangFuse настройте Evaluation (например, на 10% запросов запускать RAGAS faithfulness).
7. Создайте в Grafana дашборд: граф latency, heatmap по часам, панель "Total cost" из логов.

Ожидаемый результат: После 100+ диалогов вы увидите:

• Пики latency в часы пик.
• В LangFuse — ответы с низкой faithfulness (например, модель выдумывает факты).
• Алерт в Telegram, если ошибки >5% за 5 минут.

9. Навигация

• Предыдущий: 61
• Следующий: 63
• Индекс: 00. Индекс разборов

Навигация

• Предыдущий: 61
• Следующий: 63
• Индекс: 00. Индекс разборов