SLA-система для AI-агентів: метрики, моніторинг, гарантії надійності

Уявіть: AI-агент вашого ключового клієнта відповідає на запити із затримкою в 30 секунд, а потім ще й галюцинує, пропонуючи невірні дані. Клієнт втрачає гроші, ви — репутацію. Саме так сталося з одним фінтех-стартапом: їх агент з обробки транзакцій перевищив p95 latency в 12 секунд, і вони втратили 15% контрактів за квартал. Ми впровадили SLA-систему з моніторингом у реальному часі, і за місяць latency знизився до p95 < 4 секунд. При цьому доступність зросла до 99.7%. Наш досвід — понад 50 впроваджених AI-рішень, сертифікація з Kubernetes та ліцензії на ML-платформи. Ми знаємо, як побудувати SLA-систему, яка гарантує доступність, швидкість та якість відповідей під ваші конкретні метрики.

Проблеми, які вирішуємо

Залежність від LLM-провайдерів. Якщо OpenAI або Anthropic падають — ваш агент теж падає. Ми додаємо fallback-ланцюжки на резервні моделі (наприклад, Claude 3.5 → LLaMA 3 через vLLM) та кешуємо embeddings у ChromaDB. Доступність залишається > 99.5% навіть при падінні одного провайдера.

Непередбачуваний час відповіді. LLM генерує токени нелінійно: p95 може бути в 5 разів вище p50. Ми оптимізуємо через streaming, квантизацію INT8 та batch-обробку на Triton Inference Server. Типовий результат — p95 < 5 секунд, p99 < 8 секунд, що скорочує витрати на інфраструктуру до 40%.

Якість відповіді — суб'єктивна метрика. LLM може формально відповісти, але не вирішити задачу. Ми використовуємо LLM-суддю на базі GPT-4 з ансамблем класифікаторів, щоб детектувати галюцинації, відмови та нерелевантні відповіді. Метрика task completion показує, чи завершив агент задачу успішно, з точністю > 95%.

Як ми будуємо моніторинг SLA?

Ми будуємо систему на базі Prometheus + Grafana з кастомними експортерами для LLM-запитів. Прометеус збирає метрики з інтервалом 15 секунд, а Grafana візуалізує дашборди реального часу. Для оповіщення використовуємо Alertmanager з інтеграцією в Slack та PagerDuty. Кастомні експортери написані на Python з бібліотекою prometheus_client — вони вимірюють latency per token, швидкість стрімінгу та якість відповіді.

Типові SLA метрики для AI-агентів

Чому SLA для AI-агентів складніше традиційного?

Традиційний SLA оперує простими метриками: аптайм, latency, error rate. Для AI-агентів додається якість відповіді — метрика, яку не можна виміряти пінгом. Ми використовуємо ансамбль класифікаторів та LLM-as-a-judge, щоб детектувати галюцинації та відмови. До того ж час відповіді сильно залежить від довжини згенерованого тексту, тому ми відстежуємо не просто latency, а latency per token. Наприклад, модель з контекстним вікном 8K токенів може генерувати відповідь в 10 разів довше, ніж проста команда — це доводиться враховувати в SLO.

Реальне впровадження: кейс логістичного оператора

Клієнту був потрібен AI-агент для автоматизації обробки замовлень. Початковий прототип на GPT-4 мав p95 latency 9.2 секунди і доступність 98% через часті таймаути OpenAI. Ми застосували fallback на Mistral Large, кеш embeddings у pgvector, та налаштували streaming з batch-обробкою. Підсумок: p95 = 3.8 секунди, availability = 99.6%, task completion = 97%. Error budget дозволив клієнту безпечно впроваджувати нові функції без ризику порушення SLA.

Моніторинг SLA в реальному часі

from dataclasses import dataclass
from datetime import datetime, timedelta

@dataclass
class SLADefinition:
    name: str
    metric: str
    threshold: float
    comparison: str  # "gte" / "lte"
    measurement_window: int  # хвилини
    alerting_threshold: float  # відсоток порушень для алерту

SLA_SET = [
    SLADefinition("availability", "uptime_pct", 99.5, "gte", 60, 0.1),
    SLADefinition("p95_latency", "p95_latency_ms", 8000, "lte", 5, 0.05),
    SLADefinition("task_success", "success_rate", 0.95, "gte", 60, 0.1),
    SLADefinition("quality", "avg_quality_score", 4.0, "gte", 1440, 0.05),
]

class SLAMonitor:
    def check_sla(self, agent_name: str) -> SLAStatus:
        violations = []
        for sla in SLA_SET:
            current_value = self.metrics.get(agent_name, sla.metric, sla.measurement_window)
            is_met = self._compare(current_value, sla.threshold, sla.comparison)
            if not is_met:
                violations.append(SLAViolation(
                    sla_name=sla.name,
                    expected=sla.threshold,
                    actual=current_value,
                    since=self.metrics.get_violation_start(agent_name, sla.name)
                ))
        return SLAStatus(
            agent_name=agent_name,
            is_healthy=len(violations) == 0,
            violations=violations,
            checked_at=datetime.utcnow()
        )

Error Budgets (дотримуємося підходу Google SRE)

SLA 99.5% availability = 0.5% error budget. Це 216 хвилин на місяць, які можна витратити на деплої та експерименти. При вичерпанні — freeze на зміни. Ми автоматизуємо розрахунок та оповіщення при згорянні бюджету. Наприклад, якщо burn rate перевищує 1.0 за останній тиждень — система попереджає команду про прискорену витрату.

class ErrorBudgetTracker:
    def calculate(self, agent_name: str, period_days: int = 30) -> ErrorBudget:
        sla_availability = 0.995  # 99.5%
        total_minutes = period_days * 24 * 60
        downtime_minutes = self.metrics.get_downtime(agent_name, days=period_days)
        actual_availability = 1 - (downtime_minutes / total_minutes)
        budget_minutes = total_minutes * (1 - sla_availability)  # 216 хвилин за 30 днів
        consumed_minutes = downtime_minutes
        remaining_minutes = budget_minutes - consumed_minutes
        remaining_pct = remaining_minutes / budget_minutes
        return ErrorBudget(
            total_budget_minutes=budget_minutes,
            consumed_minutes=consumed_minutes,
            remaining_minutes=remaining_minutes,
            remaining_pct=remaining_pct,
            is_exhausted=remaining_pct <= 0,
            burn_rate=consumed_minutes / budget_minutes / (period_days / 30)
        )

Порівняння підходів до моніторингу

Prometheus-based моніторинг дає економію бюджету до 30% порівняно з хмарними рішеннями, при цьому швидкість налаштування кастомних метрик в 2–3 рази вища.

Звітність для клієнтів

Щомісячний SLA-звіт включає: фактичні значення vs SLA targets, час порушень з причинами, RCA за інцидентами, план заходів. Публічна status page для enterprise клієнтів з історією інцидентів та планових робіт. Ми також надаємо дашборди в Grafana для самостійного моніторингу.

Контрактні штрафи та кредити

Для enterprise SLA з фінансовими зобов'язаннями: автоматичний розрахунок кредитів при порушенні SLA. Наприклад: availability 99.0–99.5% → 5% credit, < 99.0% → 15% credit. Система автоматично розраховує та ініціює credit notes через білінгову систему.

Процес роботи

Ми йдемо по етапах: аудит поточних AI-агентів → проектування метрик та SLO → реалізація моніторингу та оповіщення → налаштування error budget та звітів → тестування та деплой. На виході ви отримуєте працюючу SLA-систему з документацією, дашбордами та алгоритмом дій при порушеннях.

Що входить в deliverables

• Конфігурація моніторингу (Prometheus, Grafana, Alertmanager)
• Інтеграція з LLM-провайдерами та кешем
• Дашборди реального часу за SLA
• Налаштування алертів (Slack, Telegram, PagerDuty)
• Щомісячні звіти з RCA
• Навчання команди: як керувати error budget та реагувати на інциденти

Отримайте консультацію з впровадження SLA-системи для ваших AI-агентів. Ми оцінимо проект і запропонуємо архітектуру під ваші метрики. Досвід понад 50 проектів з ML та AI — гарантуємо дотримання SLA. Замовте аудит поточної системи — розпочнемо з першого етапу.