Как вы проверяете, что новая версия модели не сломала старые кейсы?

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

Проверка регрессии для моделей в RAG|Agentic RAG — это автоматизированный процесс, основанный на regression test suite (наборе регрессионных тестов) из 200–500 сложных кейсов, собранных из production. Тесты запускаются в CI/CD pipeline до и после каждого изменения модели или промпта. Ключевые метрики — accuracy (точность ответа) и faithfulness (верность контексту) — не должны ухудшаться более чем на 5%. При провале тестов merge блокируется, требуется ручной review. Дополнительно используется staging окружение для автоматического бенчмарка и shadow deployment для безопасного сравнения.

1. Термин: Regression test suite (набор регрессионных тестов)

Что это Коллекция тестовых примеров (запросов и ожидаемых ответов), которые покрывают критические сценарии работы системы. В контексте RAG|Agentic RAG это не просто юнит-тесты, а end-to-end тесты, проверяющие полный пайплайн: retrieval → reasoning → генерация ответа.

Почему важно:

• Модели LLM — недетерминированные: одно и то же изменение промпта может улучшить одни кейсы, но сломать другие.
• Без регрессионного тестирования невозможно безопасно обновлять модель, менять эмбеддинги или дорабатывать агентскую логику.
• Тесты служат «сигналом тревоги» перед деплоем в production.

Термин «Кейс» (test case) — пара (входной запрос пользователя, эталонный ответ или набор критериев качества). Пример: запрос «Какая погода в Москве?» → ожидаем, что ответ содержит температуру и не выдумывает данные.

2. Состав regression test suite

Источники кейсов:

• Production логи: 70% кейсов — реальные запросы пользователей, которые вызвали проблемы (низкая faithfulness, галлюцинации, отказ отвечать).
• Граничные случаи: 20% — специально сконструированные запросы (пустой контекст, противоречивые данные, запросы на нескольких языках, очень длинные вопросы).
• Исторические баги: 10% — кейсы, которые ранее были исправлены (чтобы не допустить регрессии).

Размер:

• Минимум 200 кейсов для базового покрытия.
• Оптимально 300–500 для production-grade системы.
• Для Agentic RAG с несколькими агентами — 500+ кейсов, так как каждый агент может иметь свои сценарии.

Структура кейса (пример в JSON):

{
  "id": "case_042",
  "query": "Какие документы нужны для оформления визы в Германию?",
  "expected_criteria": {
    "contains_key_info": ["загранпаспорт", "анкета", "фото"],
    "faithfulness_threshold": 0.9,
    "no_hallucination": true,
    "max_tokens": 500
  },
  "context_docs": ["doc_visa_DE_2024.pdf", "doc_requirements_general.pdf"],
  "tags": ["production_issue", "visa"]
}

Термин «Faithfulness» — метрика, показывающая, насколько ответ модели соответствует предоставленному контексту (не содержит выдумок). Измеряется от 0 до 1.

3. Метрики для регрессионного тестирования

Основные метрики, которые отслеживаются при прогоне тестов:

Почему порог 5% — Это эмпирическое значение: меньше — слишком жёстко (шум от недетерминированности модели), больше — риск пропустить серьёзную деградацию.

Пример кода для расчёта faithfulness с RAGAS:

from ragas import evaluate
from ragas.metrics import faithfulness
from datasets import Dataset

# Подготовка данных: список кейсов с ответами модели
data = {
    "question": ["Какая столица Франции?"],
    "answer": ["Париж — столица Франции."],
    "contexts": [["Франция — страна в Европе. Её столица — Париж."]]
}
dataset = Dataset.from_dict(data)

# Оценка
result = evaluate(dataset, metrics=[faithfulness])
print(result['faithfulness'])  # 1.0

4. Интеграция в CI/CD pipeline

CI/CD (Continuous Integration / Continuous Deployment) — практика автоматической сборки, тестирования и развёртывания изменений. Для Agentic RAG pipeline выглядит так:

1. Commit → разработчик пушит изменение (новый промпт, обновлённая модель, правка агента).
2. Build → сборка Docker-образа с новой версией.
3. Unit tests → быстрые тесты на отдельные компоненты (парсинг, вызов API).
4. Regression tests → запуск полного набора из 200–500 кейсов на staging окружении.
5. Benchmark → сравнение метрик с baseline (текущая production-версия).
6. Gate → если accuracy или faithfulness упали >5% → pipeline фейлится.
7. Manual review → если pipeline провален, требуется approval от senior engineer.
8. Deploy → при успехе — деплой на canary (5% трафика) и постепенное расширение.

Пример конфигурации GitHub Actions:

name: Regression Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run regression suite
        run: |
          python run_regression.py --suite production_cases.json --baseline baseline_metrics.json
      - name: Check thresholds
        run: |
          python check_thresholds.py --accuracy 0.05 --faithfulness 0.05

Термин «Staging окружение» — копия production с теми же данными, но без реального трафика. Используется для безопасного тестирования.

5. Автоматический benchmark на staging

Benchmark — это не просто прогон тестов, а сравнение метрик новой версии с baseline (текущей стабильной версией). Процесс:

1. Запускаем baseline на staging → получаем эталонные метрики.
2. Запускаем новую версию на том же наборе кейсов.
3. Сравниваем: если разница по любой ключевой метрике >5% → фейл.

Дополнительные проверки:

• A/B тестирование на staging: 50% запросов идут на старую версию, 50% — на новую. Сравниваются метрики в реальном времени.
• Shadow deployment: новая версия получает копию трафика, но её ответы не показываются пользователям. Анализируется faithfulness и latency.

Термин «Baseline» — эталонная версия модели/системы, с которой сравниваются изменения. Обычно это текущая production-версия.

6. Блокировка merge и ручной review

Если regression tests провалены:

• Автоматическая блокировка: PR (pull request) не может быть слит в основную ветку.
• Уведомление: команда получает отчёт с указанием, какие кейсы упали и на сколько.
• Ручной review: senior engineer анализирует:
  • Является ли падение случайным (flaky test) или системным?
  • Можно ли скорректировать порог (например, если падение на 6% из-за одного кейса)?
  • Нужно ли откатить изменение или доработать?

Flaky test — тест, который иногда проходит, иногда нет, из-за недетерминированности LLM. Для борьбы с flaky:

• Запускать каждый кейс 3 раза и брать медиану метрики.
• Использовать семплирование с фиксированным seed (если модель поддерживает).

7. Дополнительные практики

Версионирование датасета тестов:

• Хранить regression suite в Git LFS или DVC (Data Version Control).
• Каждый релиз модели привязывать к конкретной версии тестов.

Канареечный деплой (canary release):

• После успешного staging деплоим новую версию на 5% production-трафика.
• Мониторим метрики в реальном времени (faithfulness, latency, user feedback).
• Если метрики стабильны в течение 1 часа → расширяем до 50%, затем до 100%.

Rollback:

• Автоматический откат, если после деплоя faithfulness упала ниже порога на canary.
• Хранить предыдущую версию модели и конфигурации в registry (MLflow, S3).

Термин «Canary release» — постепенный деплой новой версии на небольшую часть пользователей для минимизации риска.

8. Пример полного пайплайна (Python + CI)

# run_regression.py
import json
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy
from my_rag_system import RAGSystem  # ваша реализация

def load_test_suite(path):
    with open(path) as f:
        return json.load(f)

def run_suite(suite, model_version):
    results = []
    for case in suite:
        response = RAGSystem(model_version).answer(case["query"])
        # Формируем датасет для RAGAS
        dataset = {
            "question": [case["query"]],
            "answer": [response["answer"]],
            "contexts": [response["contexts"]]
        }
        metrics = evaluate(dataset, metrics=[faithfulness, answer_relevancy])
        results.append({
            "id": case["id"],
            "faithfulness": metrics["faithfulness"],
            "answer_relevancy": metrics["answer_relevancy"]
        })
    return results

def compare_with_baseline(new_results, baseline_path):
    with open(baseline_path) as f:
        baseline = json.load(f)
    diffs = {}
    for new, old in zip(new_results, baseline):
        for metric in ["faithfulness", "answer_relevancy"]:
            diff = new[metric] - old[metric]
            if abs(diff) > 0.05:
                diffs[new["id"]] = {metric: diff}
    return diffs

if __name__ == "__main__":
    suite = load_test_suite("regression_suite.json")
    new_results = run_suite(suite, "v2.1")
    diffs = compare_with_baseline(new_results, "baseline_v2.0.json")
    if diffs:
        print("Regression detected:", diffs)
        exit(1)
    else:
        print("All tests passed")

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

Задача: Создать regression test suite для простого RAG-бота, отвечающего на вопросы по документации Python.

Инструменты:

• Python, pytest, RAGAS, LangChain (для RAG), GitHub Actions.
• Датасет: 50 кейсов (20 из production-логов, 20 граничных, 10 исторических багов).

Шаги:

1. Соберите 50 запросов и эталонных ответов (можно использовать документацию Python).
2. Напишите скрипт test_regression.py, который для каждого кейса вызывает RAG-систему и вычисляет faithfulness и accuracy (через RAGAS).
3. Сохраните baseline метрики (текущая версия модели).
4. Внесите изменение в промпт (например, добавьте инструкцию «отвечай кратко»).
5. Запустите тесты — убедитесь, что pipeline фейлится, если faithfulness упала >5%.
6. Настройте GitHub Actions: при пуше в main запускается regression suite, при провале — блокировка merge.

Ожидаемый результат: Рабочий CI/CD пайплайн, который автоматически проверяет регрессию и не даёт слить изменения, ломающие старые кейсы.

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

Навигация

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