SLO для AI/ML-систем: что измерять у LLM и моделей¶
В главах про «SLI» и «SLO» мы разбирали классические метрики: latency, error rate, throughput. Для обычных сервисов этого хватает. Но когда в продукт встраивается LLM или ML-модель, появляются новые типы отказов, которые не ловятся стандартными SLI.
Эта глава — про надёжность AI/ML-систем: что измерять, какие SLO ставить и как реагировать на деградации, которые не похожи на привычные 5xx.
Что особенного в AI/ML-сервисах¶
Обычный сервис детерминирован: один и тот же запрос с теми же параметрами даёт один и тот же ответ. AI/ML-сервисы — нет:
1. Недетерминированность. Один запрос к LLM может давать разные ответы при одинаковых параметрах (temperature > 0). Это ломает привычные метрики вроде «успешность запроса» — что считать успехом, если ответ каждый раз разный?
2. Деградация качества. Модель может работать быстро и без ошибок, но выдавать бред. Latency = 200 мс, status = 200, error rate = 0%, а пользователь видит ерунду. Классические SLI этого не поймают.
3. Стоимость как метрика. LLM-запросы платные. Стоимость токенов может быть SLI: «средняя стоимость запроса ≤ $0.01». Это не про доступность, а про экономику.
4. Дрейф модели (model drift). Со временем распределение данных меняется, и модель деградирует. Сегодня работает отлично, через месяц — нет. Это не падение, это медленная деградация.
5. Prompt injection и атаки. Злоумышленник может через запрос заставить модель выдать то, что не должна. Классический error rate это не поймает — статус ответа будет 200.
6. Зависимость от внешних API. Если вы используете OpenAI/Anthropic/Cohere, ваша надёжность зависит от их. Их деградация = ваша деградация.
Какие SLI/SLO нужны для AI/ML¶
1. Классические SLI (по-прежнему важны)¶
- Latency — время до первого токена (TTFT, time-to-first-token) и время до последнего токена
- Throughput — токены в секунду на пользователя, RPS
- Error rate — 5xx, таймауты, недоступность API
- Availability — процент успешных запросов от общего числа
2. SLI на качество ответа¶
Это новая категория, которой нет в обычных сервисах:
- Hallucination rate — процент ответов с фактическими ошибками. Измеряется через LLM-as-a-judge или экспертную оценку
- Relevance score — насколько ответ релевантен запросу (для RAG-систем)
- Format compliance — процент ответов в нужном формате (JSON, определённая структура)
- Refusal rate — процент отказов модели отвечать («I can’t help with that»). Скачок = проблема с промптом или моделью
- Toxicity/safety — процент ответов, попавших под фильтры безопасности
3. SLI на стоимость¶
- Cost per request — средняя стоимость одного запроса в рублях
- Tokens per session — общее количество токенов на сессию пользователя
- Cost ratio — стоимость LLM / стоимость всего запроса (для гибридных пайплайнов)
4. SLI на дрейф¶
- Input drift — насколько изменилось распределение входящих запросов
- Output drift — насколько изменилось распределение ответов
- Embedding drift — для эмбеддинг-моделей, насколько сместился векторный центр
5. SLI на prompt injection¶
- Injection attempt rate — процент запросов, классифицированных как попытки prompt injection
- Successful injection rate — процент атак, которые модель не отразила (должен быть 0)
- Jailbreak rate — аналогично, процент успешных обходов safety-фильтров
Пример SLO для AI-чата поддержки¶
apiVersion: openslo/v1
kind: SLO
metadata:
name: support-chat-quality
labels:
product: support-chat
model: gpt-4
spec:
service: support-chat
indicatorRef: support-chat-latency
timeWindow:
- duration: 28d
type: Rolling
budgetingMethod: Occurrences
objectives:
- displayName: "Latency p95 ≤ 3 сек"
target: 0.95
indicatorRef: latency-p95
- displayName: "Error rate ≤ 1%"
target: 0.99
indicatorRef: error-rate
- displayName: "Hallucination rate ≤ 5%"
target: 0.95
indicatorRef: hallucination-rate
- displayName: "Cost per session ≤ $0.05"
target: 0.90
indicatorRef: cost-per-session
- displayName: "Successful injection rate ≤ 0%"
target: 1.0
indicatorRef: injection-block-rate
Как измерять качество ответов¶
Самая сложная часть — измерение качества. Несколько подходов:
1. LLM-as-a-judge¶
Используете другую (часто более мощную) LLM, чтобы оценить качество ответов основной. Например: «Вот запрос пользователю, вот ответ ассистента. Оцени от 1 до 5 по шкале…»
Плюсы: масштабируется, недорого, можно запускать на 100% трафика Минусы: bias модели-судьи, дополнительная стоимость, не идеально для фактической точности
2. Human-in-the-loop¶
Эксперты размечают подмножество ответов (5-10% трафика), и это становится ground truth для LLM-as-a-judge и для оценки дрейфа.
Плюсы: высокая точность, ловит то, что модель не увидит Минусы: дорого, медленно, не масштабируется
3. Автоматические проверки¶
Для структурированных ответов (JSON, SQL, код) — можно парсить и проверять автоматически: - Валидный JSON? - Соответствует схеме? - SQL выполнился без ошибок? - Unit-тесты на сгенерированном коде прошли?
4. Онлайн-метрики¶
Сами пользователи — лучший судья: - Thumbs up/down после ответа - Время до закрытия тикета (для саппорта) - Repeat rate — пользователь переспросил (вероятно, ответ не помог) - CSAT score
Алертинг на деградацию AI¶
Burn rate по качеству¶
Классический multi-window burn rate из главы «Error Budget» применим и к AI-метрикам:
SLO: hallucination_rate ≤ 5%
Budget: 5% за 28 дней
Burn rate 1h window > 14.4 — page on-call (исчерпание бюджета за 2 дня)
Burn rate 6h window > 6 — slack alert (за 4 дня)
Аномалии на метриках¶
Latency inference может скакать из-за: - Медленного upstream API - Большого размера батча - Холодного старта GPU-инстанса
Нужны anomaly detection алерты: «latency p99 за последний час отклоняется от 7-дневного паттерна более чем на 2σ».
Алерты на дрейф¶
Входной дрейф ловится сравнением распределений эмбеддингов за сегодня vs за неделю назад (PSI, KS-test). Выходной дрейф — аналогично по распределению ответов. Порог срабатывания — PSI > 0.2.
Канареечные промпты и модели¶
В главе «Canary и Progressive Delivery» описана раскатка изменений. Для AI-систем канарейка выглядит иначе:
Канареечные промпты: - 5% трафика идёт через новый промпт, 95% через старый - Сравниваем метрики качества на двух группах - Если новый промпт лучше — расширяем до 100% - Если хуже — откатываем
Канареечные модели: - A/B между моделями (gpt-4 vs gpt-4o vs Claude) - Сравниваем не только latency и стоимость, но и качество - Promotion: модель с лучшим балансом получает больше трафика
Специфика GPU-инфраструктуры¶
ML-inference на GPU добавляет свои reliability-вызовы:
- Холодный старт — загрузка модели в GPU-память занимает минуты. Помогают warm pools, model preloading
- OOM при большом батче — запросы могут падать с CUDA OOM. Нужны retry с уменьшенным батчем
- GPU utilization — если < 30%, платите за простаивающие ресурсы. Если > 90%, будут скачки latency
- Multi-GPU/NVLink — для больших моделей, добавляет сложность планирования
- Spot instances для training — дешевле, но может прерываться
Когда НЕ нужно всё это¶
- Если LLM используется для некритичных фич (автокомплит в чате, суммаризация статьи) — достаточно latency + error rate
- Если вы перепродаёте чужой API — ваши SLI это SLI upstream-провайдера плюс ваша обвязка
- Если у вас 10 запросов в день — гнаться за метриками качества нет смысла
- Если нет возможности оценить качество — без ground truth ни LLM-as-a-judge, ни human-in-loop не работают
Резюме¶
AI/ML-сервисы требуют новой категории SLI: на качество ответа, стоимость, дрейф модели и prompt injection. Классические latency/error rate по-прежнему важны, но недостаточны.
Главные подходы: - LLM-as-a-judge для масштабируемой оценки качества - Human-in-the-loop на 5-10% трафика для ground truth - Автоматические проверки для структурированных ответов - Drift detection для долгосрочной деградации - Burn rate SLO на качественные метрики так же, как на error rate
Не пытайтесь измерить всё сразу. Начните с latency, error rate и одного показателя качества, специфичного для вашего продукта. Наращивайте по мере того, как учитесь понимать поведение модели в проде.
См. также: «SLI», «SLO», «Error Budget», «Принципы качественного алертинга», «Использование AI-агентов в работе SRE», «OpenSLO».