Уявіть: 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-специфіка |
|---|---|---|
| Availability | > 99.5% | Включаючи LLM provider availability |
| Response time (p95) | < 5s | Залежить від довжини відповіді (tokens/s) |
| Error rate | < 1% | Включаючи AI-помилки (hallucination, refusal) |
| Task completion | N/A | > 95% задач завершуються успішно |
| Quality score | N/A | > 4.0/5.0 за LLM-суддею |
Чому 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 + Grafana | Хмарний моніторинг (CloudWatch) |
|---|---|---|
| Налаштування кастомних метрик | Гнучке, будь-який експортер | Обмежено стандартними метриками |
| Оповіщення за складними умовами | Підтримка PromQL | Умовні правила |
| Зберігання історії | Будь-які Retention | Обмежені планом |
| Вартість при великому обсязі | Нижча | Вища при масштабі |
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-систему з документацією, дашбордами та алгоритмом дій при порушеннях.
Чек-лист впровадження SLA-системи
- Визначити SLO для кожної метрики (latency, availability, quality)
- Налаштувати збір метрик через Prometheus експортери
- Розгорнути дашборди Grafana з візуалізацією SLA та error budget
- Налаштувати алерти в Alertmanager (Slack, Telegram, PagerDuty)
- Інтегрувати білінг для автоматичних кредитів
- Провести RCA-тренінг для команди
Що входить в deliverables
- Конфігурація моніторингу (Prometheus, Grafana, Alertmanager)
- Інтеграція з LLM-провайдерами та кешем
- Дашборди реального часу за SLA
- Налаштування алертів (Slack, Telegram, PagerDuty)
- Щомісячні звіти з RCA
- Навчання команди: як керувати error budget та реагувати на інциденти
Отримайте консультацію з впровадження SLA-системи для ваших AI-агентів. Ми оцінимо проект і запропонуємо архітектуру під ваші метрики. Досвід понад 50 проектів з ML та AI — гарантуємо дотримання SLA. Замовте аудит поточної системи — перший етап безкоштовно.