Как вы обрабатываете production incident с LLM (playbook)?

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

Production incident с LLM — это любое критическое отклонение в работе системы, от галлюцинаций до внезапного роста стоимости. Playbook — это формализованный набор шагов: Detect (обнаружение через мониторинг), Page on-call (эскалация), Mitigate (немедленное снижение ущерба: rollback, fallback), RCA (анализ первопричины), Fix (исправление), Prevent (долгосрочные меры). Главная особенность LLM-инцидентов — их качественная природа: метрики вроде faithfulness или toxicity требуют отдельного мониторинга, а не только latency и error rate.

1. Термин: Production Incident с LLM

Production incident — это событие, которое нарушает нормальную работу сервиса или снижает его качество. Для LLM-систем инциденты бывают:

• Качественные: галлюцинации, токсичные ответы, потеря контекста, неверные факты.
• Инфраструктурные: рост latency, ошибки 5xx, падение GPU-нод, превышение лимитов API.
• Безопасностные: prompt injection, утечка данных, генерация вредоносного контента.
• Финансовые: неожиданный рост cost per query из-за увеличения длины контекста или числа токенов.

Playbook — это документ, который описывает, кто, что и когда делает при инциденте. Он должен быть конкретным, проверяемым и автоматизированным.

2. Этап 1: Detection — обнаружение инцидента

Обнаружение строится на мониторинге нескольких слоёв:

Пороги срабатывания (alerts):

• Latency p99 > 3x baseline → инцидент производительности.
• Faithfulness < 0.7 → возможны галлюцинации.
• Error rate > 1% → проблема с LLM API или инфраструктурой.
• Cost per query > 2x baseline → утечка токенов или бесконечный цикл.

3. Этап 2: Page on-call — эскалация

После срабатывания алерта нужно уведомить дежурного инженера (on-call). Процесс:

1. Severity classification:

   • P0 (критический): сервис полностью недоступен, генерируются опасные ответы. Время реакции — 5 минут.
   • P1 (высокий): серьёзное ухудшение качества, но сервис работает. Время реакции — 15 минут.
   • P2 (средний): незначительные ошибки, не влияющие на пользователей. Время реакции — 1 час.
   • P3 (низкий): косметические проблемы, можно отложить.

2. Каналы: PagerDuty, Opsgenie, Slack-бот с кнопками "Принять/Эскалировать".

3. Первичный дамп: on-call инженер собирает логи, метрики, трассировку запросов (через OpenTelemetry или LangFuse).

4. Этап 3: Mitigate — немедленное снижение ущерба

Цель — остановить или ограничить негативное влияние, не дожидаясь полного исправления.

Важно: все действия должны быть автоматизированы через CI/CD pipeline или feature flag system (LaunchDarkly, Unleash). Ручные действия — зона риска.

5. Этап 4: Root Cause Analysis (RCA)

После стабилизации проводится анализ первопричины. Для LLM-инцидентов RCA включает:

1. Сбор данных:

   • Логи запросов и ответов (сэмплирование за период инцидента).
   • Метрики мониторинга (latency, error rate, cost).
   • Версии модели, промпта, эмбеддингов, чанков.
   • A/B тесты (если был канареечный деплой).

2. Гипотезы:

   • Data drift: изменилось распределение пользовательских запросов.
   • Model drift: новая версия модели (например, GPT-4 → GPT-4-turbo) ведёт себя иначе.
   • Prompt regression: изменение промпта привело к неожиданным эффектам.
   • Infrastructure: сбой в векторной БД, перегрузка GPU.
   • External API: провайдер LLM изменил поведение (например, OpenAI deprecation).

3. Валидация:

   • Воспроизвести инцидент в staging-окружении.
   • Использовать A/B тесты для сравнения версий.
   • Проверить offline метрики (hit rate, MRR) на исторических данных.

6. Этап 5: Fix — исправление

Исправление зависит от найденной причины:

Hotfix — быстрое исправление, которое деплоится вне обычного цикла. Для LLM-систем hotfix может быть:

• Изменение системного промпта через feature flag.
• Блокировка определённых запросов через regex.
• Переключение на более дешёвую/безопасную модель.

7. Этап 6: Prevent — предотвращение повторения

Долгосрочные меры делятся на три категории:

1. Мониторинг:

   • Добавить новые алерты (например, на faithfulness < 0.8).
   • Внедрить drift detection для эмбеддингов и запросов.
   • Настроить cost anomaly detection.

2. Тестирование:

   • Regression tests: набор промптов с ожидаемыми ответами (golden dataset).
   • Red teaming: автоматизированные атаки (prompt injection, jailbreak).
   • Chaos engineering: симуляция сбоев (отказ API, высокая нагрузка).

3. Процессы:

   • Postmortem (разбор инцидента) с action items.
   • Playbook review раз в квартал.
   • Training для on-call инженеров по специфике LLM.

8. Специфика LLM-инцидентов: что нужно знать

• Галлюцинации — самый частый качественный инцидент. Не всегда видны по метрикам latency. Требуют LLM-as-judge для автоматической оценки.
• Prompt injection — атака, при которой пользовательский ввод переопределяет системный промпт. Защита: input sanitization, guardrails.
• Cost explosion — из-за рекурсивных вызовов (agentic RAG) или очень длинных контекстов. Мониторить total tokens per session.
• Model deprecation — провайдер отключает старую модель. Нужен fallback plan и version pinning.

9. Пример playbook для типичного инцидента (P1)

10. Инструменты для реализации playbook

• Мониторинг: Prometheus + Grafana, Datadog, New Relic.
• LLM-специфичный мониторинг: LangSmith, Weights & Biases, LangFuse, Arize AI.
• Эскалация: PagerDuty, Opsgenie, Slack.
• Feature flags: LaunchDarkly, Unleash, split.io.
• CI/CD: GitHub Actions, GitLab CI, ArgoCD.
• Guardrails: NeMo Guardrails, Guardrails AI, NVIDIA Guardrails.

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

Задача: Разработать playbook для инцидента "галлюцинации в RAG-системе" и автоматизировать часть шагов.

Инструменты: Python, LangChain, FastAPI, Prometheus, Docker, PagerDuty (trial).

Шаги:

1. Разверните простую RAG-систему (FastAPI + LangChain + ChromaDB).
2. Добавьте мониторинг метрик faithfulness через LLM-as-judge (например, с помощью GPT-4o-mini).
3. Настройте алерт в Prometheus (правило: faithfulness < 0.7 за 5 минут).
4. Напишите скрипт для автоматического rollback: при алерте переключать версию промпта через feature flag (файл конфигурации).
5. Реализуйте fallback: если faithfulness низкий, возвращать ответ "Извините, я не могу ответить на этот вопрос" вместо генерации.
6. Проведите симуляцию: измените промпт так, чтобы он начал галлюцинировать, и проверьте срабатывание playbook.

Ожидаемый результат: Работающий playbook, который при падении faithfulness автоматически откатывает промпт и отправляет уведомление в PagerDuty (или Slack).

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

Навигация

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