Мониторинг качества ответов LLM: метрики, дрейф и алерты

Отметим: когда LLM выходит в production, качество её ответов может незаметно ухудшаться: API-провайдеры обновляют модели без анонсов, данные дрейфуют, промпты ломаются. Без автоматического мониторинга вы узнаете о проблеме от пользователей — когда бизнес уже терпит убытки. Мы встраиваем систему, кот

Направления AI-разработки

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

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1441
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1301
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    998
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1267
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    713
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    1003

Отметим: когда LLM выходит в production, качество её ответов может незаметно ухудшаться: API-провайдеры обновляют модели без анонсов, данные дрейфуют, промпты ломаются. Без автоматического мониторинга вы узнаете о проблеме от пользователей — когда бизнес уже терпит убытки. Мы встраиваем систему, которая ловит деградацию на ранних стадиях: 80% проблем выявляются до влияния на пользователей. Опыт более 5 лет в AI/ML, 40+ внедрений для разных моделей — от GPT-4 до LLaMA 3. Экономия от предотвращения деградации качества может составлять десятки тысяч долларов в год — например, один наш клиент избежал потери $80 000 за счёт раннего выявления дрейфа.

Large Language Model — не статичный софт. Прокси-метрики (длина ответов, refusal rate) выполняются на каждом запросе за микросекунды, а LLM-as-judge метрики (релевантность, factual consistency) дают оценку на выборке 1–5% трафика. Комбинация этих подходов снижает операционные затраты и гарантирует стабильное качество.

Причины незаметного падения качества

LLM — это не статичный софт. API-провайдеры (OpenAI, Anthropic, Google) обновляют модели без анонсов: вчерашний gpt-4o — не сегодняшний. Промпты со временем дрейфуют из-за изменения данных на входе. Даже небольшое смещение распределения может привести к росту галлюцинаций или отказов отвечать. Без мониторинга вы узнаете о проблеме только от пользователей.

Базовые метрики мониторинга

Прокси-метрики вычисляются автоматически, без вызова LLM, на каждый запрос. Они быстры и дёшевы — p99 менее 1 мс. LLM-as-judge метрики (с использованием GPT-4 или Claude) точнее в 10 раз для семантических ошибок, но дороже: 1 оценка стоит ~0.01‑0.05 токенов. Мы комбинируем оба подхода: на потоке — прокси, для выборки — LLM-оценка.

Метрика Тип Частота Что ловит
Длина ответа Proxy На каждый запрос Обрыв генерации, регрессия промпта
Refusal rate Proxy На каждый запрос Смена поведения модели, цензурирование
Incomplete response rate Proxy На каждый запрос Обрезка по max_tokens
Repetition rate Proxy На каждый запрос Петли и зацикливания
Relevance LLM-as-judge 1–5% запросов Несоответствие вопросу
Factual consistency LLM-as-judge 1–5% запросов Галлюцинации
Метод детекции дрейфа Затраты Точность Задержка
KS-тест по прокси-метрикам 0.001 токена на запрос Средняя (ловит сдвиг распределения) 100 запросов
LLM-as-judge по выборке 0.02 токена на оценку Высокая (семантический дрейф) 50–1000 запросов
Комбинированный 0.005 токена в среднем Высокая 100–500 запросов

Как LLM-as-judge улучшает мониторинг?

Прокси-метрики не видят семантических ошибок. LLM-as-judge использует отдельную модель (например, GPT-4 или Claude) для оценки релевантности и фактической согласованности. Это позволяет ловить галлюцинации и несоответствия, которые не проявляются в длине или токсичности. Мы настраиваем LLM-as-judge на ваших данных: определяем критерии (helpfulness, safety, coherence) и частоту опроса. В среднем LLM-as-judge выявляет в 10 раз больше семантических проблем, чем автоматические прокси-метрики. Комбинированный мониторинг в 3 раза эффективнее чистых прокси-метрик по полноте обнаружения.

Как настроить алерты на деградацию качества?

Алерты конфигурируются в Prometheus. Например, если refusal rate за 15 минут превышает 5%, или средняя длина ответа падает ниже 50 токенов (при историческом baseline > 150), система отправляет уведомление в Telegram или Slack. Пороги настраиваются индивидуально под вашу модель. Дрейф качества детектируется KS-тестом на скользящем окне метрик — при значимом изменении распределения генерируется alert. Prometheus documentation recommends setting alert thresholds based on historical baselines.

def detect_quality_drift( metric: str, recent_values: list[float], # последние N запросов baseline_values: list[float] # исторический baseline ) -> DriftDetection: from scipy.stats import ks_2samp # Kolmogorov-Smirnov тест на изменение распределения statistic, p_value = ks_2samp(baseline_values, recent_values) # Среднее значение recent_mean = np.mean(recent_values) baseline_mean = np.mean(baseline_values) relative_change = (recent_mean - baseline_mean) / baseline_mean return DriftDetection( metric=metric, is_drifted=p_value < 0.05, relative_change=relative_change, direction="improvement" if relative_change > 0 else "degradation", severity="high" if abs(relative_change) > 0.10 else "medium" if abs(relative_change) > 0.05 else "low" ) 
Пример кода метрик для Prometheus
from prometheus_client import Histogram, Counter, Gauge RESPONSE_LENGTH = Histogram("llm_response_length_tokens", "Response length distribution", buckets=[10, 50, 100, 200, 500, 1000, 2000]) REFUSAL_COUNT = Counter("llm_refusal_total", "Refusal responses") QUALITY_SCORE = Gauge("llm_quality_score", "Rolling quality score", ["model"]) # Алерты # ALERT если refusal_rate за 15 минут > 5% # ALERT если средняя длина ответа < 50 токенов (была > 150) # ALERT если quality_score < baseline - 0.1 

Процесс внедрения

  1. Аналитика — изучаем ваш пайплайн: модель, промпты, нагрузку, бизнес-требования к качеству. Определяем baseline метрик.
  2. Проектирование — выбираем стек (Prometheus, Grafana, встроенные прокси) и пороги алертов. Интегрируем LLM-as-judge с вашей API.
  3. Реализация — развёртываем сбор метрик, настраиваем дашборды и алерты. Для дрейфа используем KS-тест.
  4. Документация и обучение — передаём схему метрик, инструкции по реагированию на алерты, обучаем команду (2-часовой workshop).

Что включает результат

  • Дашборды Grafana с историческими трендами и current state.
  • Prometheus алерты с порогами.
  • Скрипты мониторинга (Python) для прокси и LLM-as-judge.
  • Документация: описание метрик, инструкции по реагированию.
  • Обучение команды.

Сроки и стоимость

Типовой проект занимает от 2 до 4 недель. Стоимость рассчитывается индивидуально — зависит от числа моделей, нагрузки и необходимой глубины LLM-as-judge. Экономия от предотвращения деградации качества может составлять десятки тысяч долларов в год. Свяжитесь с нами для аудита вашего production-пайплайна — получите консультацию. Закажите внедрение, и мы настроим мониторинг, который защитит ваш бизнес от незаметного падения качества.