中文翻译暂不可用,显示俄语原文。

Реализовать SLO для RAG

ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Реализовать SLO для RAG

1. Цель задачи

Научиться формализовать и мониторить Service Level Objectives (SLO) для production RAG-системы. Необходимо определить два ключевых SLO: latency p95 < 2 секунд и faithfulness > 0.9, настроить сбор соответствующих метрик, организовать дашборд и alerting, а также рассчитать error budget для каждого SLO.

Ключевой результат Работающий error budget для RAG-системы, который позволяет команде принимать обоснованные решения о релизах и инцидентах.


2. Исходные данные

Перед началом необходимо иметь:

Что нужноОткуда взять
RAG-система (рабочая или тестовая)Собранный pet-проект / существующая система (например, на FastAPI + LangChain)
HTTP-запросы к RAG API (или эмуляция нагрузки)Подготовленный скрипт генерации трафика (locust / k6)
LLM-модель для оценки faithfulnessOpenAI API / локальная модель (например, Llama 3) / RAGAS
Система мониторингаPrometheus + Grafana (локально или Docker)
Инструмент распределённой трассировкиOpenTelemetry (Python SDK) + Jaeger / Tempo (опционально)
База данных для метрикPrometheus TSDB (будет создана автоматически)

Если нет реального инструмента — симулируем:

  1. Разверни локальную RAG-систему на FastAPI с эндпоинтом /rag/query. Используй FAISS (в памяти) и sentence-transformers (all-MiniLM-L6-v2) для эмбеддингов.
  2. Напиши простой скрипт, который отправляет 100–500 тестовых запросов с разным содержимым, имитируя пользовательский трафик.
  3. Для оценки faithfulness без LLM-асистента используй эвристику: сравнивай ответ с исходными документами через BERTScore или ROUGE-L; запиши результат как float 0..1. Если нет возможности – просто генерируй случайные faithfulness метрики в диапазоне [0.85, 0.95] для симуляции.
  4. Установи OpenTelemetry Python SDK и Prometheus клиент для экспорта метрик.

3. Технологический стек

КомпонентИнструментыНазначение
RAG-серверFastAPI + LangChain / LlamaIndexОбработка запросов
Эмбеддингиsentence-transformers (all-MiniLM-L6-v2)Chunk + query embedding
Векторное хранилищеFAISS (in-memory)Retrieval
Мониторинг метрикPrometheus (python client) + pushgateway (опционально)Сбор latency p95, faithfulness
ВизуализацияGrafanaДашборд SLO
ТрассировкаOpenTelemetry + Jaeger (опционально)Детальное измерение latency по компонентам
Генерация нагрузкиLocust / k6Нагрузочное тестирование
Оценка faithfulnessRAGAS / DeepEval / эвристика BERTScoreМетрика качества ответа
Хранение метрикPrometheus TSDBДолгосрочное хранение

4. Этапы выполнения

Этап 1: Определение SLO и сценариев (30 минут)

Действия

  1. Запиши SLO в читаемом виде:
    • latency_p95 < 2s — 95-й перцентиль времени ответа RAG (от получения запроса до отправки ответа) меньше 2 секунд.
    • faithfulness > 0.9 — средняя faithfulness оценка за окно (например, 5 минут) должна быть выше 0.9.
  2. Установи период наблюдения (SLI window): например, последние 5 минут для вычисления p95.
  3. Определи Error Budget:
    • За период (например, 30 дней) допустимое количество ошибок = (1 - SLO_target) * total_requests.
    • SLO target для latency: 99% (соответствие <2с) → error budget = 1% запросов.
    • SLO target для faithfulness: 95% (средняя >0.9) → error budget = 5% плохих ответов. (Вы можете выбрать другие таргеты, но они должны быть осмыслены)
  4. Согласуй, как часто пересчитывать error budget: ежедневно.

Ожидаемый результат этапа Чёткая документация SLO (в README или Confluence): показатели, окна, таргеты, метод расчёта error budget.


Этап 2: Инструментирование RAG-пайплайна для сбора метрик (2–3 часа)

Действия

  1. Установи Prometheus client для Python: pip install prometheus-client.
  2. В RAG-эндпоинте добавь Histogram для latency:
    from prometheus_client import Histogram, Counter
    import time
    
    LATENCY_HISTOGRAM = Histogram('rag_latency_seconds', 'Latency of RAG query',
                                   buckets=[0.5, 1.0, 1.5, 2.0, 2.5, 3.0, 5.0, 10.0])
    FAITHFULNESS_SUMMARY = Gauge('rag_faithfulness', 'Faithfulness score (last value)')
    
    @app.post("/rag/query")
    async def rag_query(request: QueryRequest):
        start = time.time()
        # ... ваш RAG pipeline ...
        latency = time.time() - start
        LATENCY_HISTOGRAM.observe(latency)
        # после получения ответа оцени faithfulness
        faithfulness = compute_faithfulness(query, docs, answer)
        FAITHFULNESS_SUMMARY.set(faithfulness)
        return {"answer": answer, "faithfulness": faithfulness}
    
  3. Экспонируй метрики: добавь endpoint /metrics на FastAPI (используя prometheus_client's make_asgi_app).
  4. Настрой Prometheus для сбора метрик с этого endpoint (scrape_config).
  5. Добавь распределённую трассировку (опционально): используй OpenTelemetry для замера времени retrieval и LLM вызова отдельно.
  6. Проверь: запусти RAG, выполни несколько запросов, убедись, что в /metrics появились rag_latency_seconds_bucket, rag_faithfulness.

Ожидаемый результат этапа Метрики latency и faithfulness экспортируются в Prometheus, данные можно видеть в PromQL.


Этап 3: Настройка вычислителя faithfulness (1–2 часа)

Действия

  1. Выбери способ оценки faithfulness:
    • Вариант 1: RAGAS (pip install ragas). Пример:
      from ragas.metrics import faithfulness
      from ragas import evaluate
      from datasets import Dataset
      
      def compute_faithfulness(query, documents, answer):
          ds = Dataset.from_dict({
              "question": [query],
              "contexts": [documents],
              "answer": [answer]
          })
          result = evaluate(ds, metrics=[faithfulness])
          return result['faithfulness'][0]  # float 0..1
      
    • Вариант 2: эвристика с BERTScore (без LLM) – медленнее, но дешевле.
  2. Интегрируй функцию в RAG-пайплайн после получения ответа.
  3. Важно не замедляй ответ для пользователя. Вычисляй faithfulness асинхронно (например, отправляй в background task) и обновляй метрику позже. Для простоты на первых порах можно вычислять синхронно.
  4. Настрой Gauge-метрику (rag_faithfulness), которая обновляется после каждой оценки.

Ожидаемый результат этапа Faithfulness вычисляется и попадает в Prometheus как последнее значение. В дальнейшем можно перейти на Summary или Histogram.


Этап 4: Дашборд и alerting в Grafana (1–2 часа)

Действия

  1. Установи и настрой Grafana (через Docker compose вместе с Prometheus).
  2. Создай дашборд "RAG SLO" с панелями:
    • Latency p95 за окно 5 мин:
      histogram_quantile(0.95, sum(rate(rag_latency_seconds_bucket[5m])) by (le))
      
    • SLO compliance latency: процент запросов <2с:
      sum(rate(rag_latency_seconds_bucket{le="2.0"}[5m])) / sum(rate(rag_latency_seconds_count[5m]))
      
    • Faithfulness (средняя за 5 мин):
      avg_over_time(rag_faithfulness[5m])
      
    • Error budget latency (оставшийся budget в процентах за период, например, 30 дней):
      • Рассчитай total requests и bad events; сложнее, поэтому можно вывести gauge с ручным обновлением.
      • Упрощённо: выведи отношение количества ошибок к total за окно.
    • График faithfulness за последний час.
  3. Настрой alerting:
    • Если latency p95 > 2.0 в течение 1 минуты → предупреждение (warning).
    • Если faithfulness avg < 0.85 в течение 2 минут → критический алерт.
    • Настрой канал (email/slack/telegram) – используй тестовый receiver.
  4. Импортируй дашборд (сохрани JSON для последующего использования).

Ожидаемый результат этапа Графана дашборд с панелями SLO и рабочими алертами.


Этап 5: Расчёт error budget и автоматизация (1 час)

Действия

  1. Напиши Python-скрипт (или используй PromQL) для расчёта error budget:
    • Для latency: определи SLO target (например, 99% попаданий <2с). Error budget за период = (1 - target) * total_requests.
    • Используй range запросы: sum(increase(rag_latency_seconds_count[30d])) и sum(increase(rag_latency_seconds_bucket{le="2.0"}[30d])).
    • Вычисли consumed budget.
  2. Запиши error budget как метрику в Prometheus (Gauge, обновляется раз в час cron-задачей).
  3. Добавь панель "Error Budget Remaining" в Grafana.
  4. Документируй процесс:
    • Как пересчитывать error budget.
    • Правило: если error budget исчерпан на >50% за период, запрещены релизы.

Ожидаемый результат этапа Автоматизированный error budget, отображаемый на дашборде.


5. Критерии приемки (Definition of Done)

  • В RAG-сервер добавлены метрики latency (Histogram) и faithfulness (Gauge).
  • Prometheus настроен и успешно скрейпит /metrics.
  • Faithfulness корректно вычисляется для каждого ответа (синхронно или асинхронно).
  • В Grafana создан дашборд с панелями: latency p95 за 5 мин, SLO compliance %, faithfulness avg, error budget.
  • Настроены алерты для выхода за пределы SLO.
  • Error budget рассчитывается автоматически и виден на дашборде.
  • Нагрузочное тестирование (locust) подтверждает, что при нагрузке <50 RPS p95 latency < 2s (иначе надо тюнить).
  • Написана README с описанием SLO, метрик и правил использования error budget.

6. Ожидаемый результат

Основной артефакт GitHub-репозиторий / папка проекта со следующим содержимым:

  • rag_server.pyFastAPI сервер с инструментированием.
  • faithfulness_evaluator.py — функция вычисления faithfulness (RAGAS / эвристика).
  • docker-compose.yml — запуск Prometheus + Grafana (готовые конфиги).
  • grafana_dashboard.json — экспортированный дашборд.
  • locustfile.py — сценарий нагрузочного тестирования (опционально).
  • README.md — документация SLO, инструкция по запуску, описание метрик.

Дополнительно Скриншоты Grafana дашборда с работающими метриками и alerting.


7. Возможные сложности и их решение

СложностьРешение
Faithfulness требует LLM, что увеличивает latencyВычислять faithfulness асинхронно (background task), записывать в отдельный gauge с задержкой. Или использовать быструю эвристику (BERTScore).
Latency p95 может быть неточным при малом количестве запросовУвеличить bucket resolution, использовать sliding window (например, 5 минут). Для тестов достаточно 100+ запросов.
Prometheus не хранит точные перцентили по умолчаниюИспользовать histogram_quantile с достаточным количеством buckets. Для productionVictoriaMetrics или Thanos.
Оценка faithfulness нестабильнаПовышать threshold усреднения (за 10-15 минут). Использовать несколько независимых оценок.
Error budget сложно подсчитать из-за разных оконФиксировать календарный месяц как период SLO. Рассчитывать error budget ежедневно через PromQL subquery.

8. Бюджет времени (оценка)

ЭтапВремя
Этап 1: Определение SLO и сценариев30 мин
Этап 2: Инструментирование RAG2–3 ч
Этап 3: Настройка faithfulness1–2 ч
Этап 4: Дашборд и alerting1–2 ч
Этап 5: Error budget1 ч
Итого6–8 ч

Примечание для первого раза Если RAG-система строится с нуля, добавь 2–3 часа на базовую реализацию (эмбеддинги, FAISS, простой LLM). В таблице время указано при уже рабочем RAG-сервере.


9. Связанные вопросы из базы знаний

ВопросТема
201Что такое SLO и SLI?
203Как рассчитать error budget?
207Мониторинг latency p95 в Prometheus
210Настройка дашборда SLO в Grafana
302Оценка faithfulness в RAG (RAGAS)
305Метрики faithfulness: проблемы и best practices
401Установка и настройка Prometheus
408Использование histogram_quantile
509Распределённая трассировка с OpenTelemetry
701Нагрузочное тестирование RAG‑системы (k6/locust)

10. Чек-лист самопроверки

  • Я прописал SLO (latency p95 <2s, faithfulness >0.9) и их таргеты.
  • Я добавил Prometheus Histogram для latency и Gauge для faithfulness.
  • Я настроил Prometheus scrape и Grafana datasource.
  • Я создал дашборд с панелями p95, compliance, faithfulness, error budget.
  • Я протестировал алерт на выход за SLO.
  • Я написал скрипт или PromQL для расчёта error budget.
  • Я сохранил дашборд как JSON.
  • README объясняет, как запустить проект и интерпретировать метрики.