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

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

Чтобы новая версия модели или промпта не ухудшила качество на уже работающих сценариях, нужен регрессионный тестовый сьют из 200–500 сложных продакшен-кейсов. Сьют запускается автоматически в CI/CD до и после каждого изменения, а пайплайн фейлится, если метрики ухудшились более чем на 5%. Для оценки используются как автоматические метрики (faithfulness, answer relevance), так и LLM-as-a-Judge для субъективных аспектов.

1. Термин: Регрессионное тестирование в контексте LLM

Регрессионное тестирование — это проверка, что новое изменение (модель, промпт, пайплайн) не сломало уже работающие сценарии. В классическом ML это сравнение метрик на отложенном тестовом наборе. В LLM-системах добавляется сложность: ответы могут быть вариативными, а «правильный» ответ не всегда единственный.

Зачем это нужно

• Изменение промпта может улучшить один тип запросов, но сломать другой (например, сделать ответы менее безопасными).
• Новая версия модели (fine-tuned или обновлённая базовая) может вести себя иначе на краевых случаях.
• Без регрессионного тестирования регрессии обнаруживаются только в продакшене, что дорого и рискованно.

2. Состав регрессионного сьюта

Сьют должен покрывать все критические сценарии из продакшена. Рекомендуемый размер — 200–500 кейсов. Меньше — недостаточная статистика, больше — слишком долгий прогон.

Категории кейсов

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

• Логи продакшена]] (реальные запросы пользователей).
• evaluation|Ручная разметка экспертами.
• Синтетическая генерация с помощью LLM (например, GPT-4) с последующей верификацией.

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

Для каждого кейса в сьюте мы получаем ответ от старой и новой версии. Затем сравниваем метрики. Используются как автоматические, так и LLM-асистированные метрики.

Порог ухудшения Если хотя бы одна метрика упала более чем на 5% (абсолютных или относительных — зависит от метрики), пайплайн фейлится. Для LLM-as-a-Judge можно использовать среднюю оценку: ухудшение на 0.3 балла и более — красный флаг.

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

Процесс автоматизируется в пайплайне (GitHub Actions, GitLab CI, Jenkins).

Шаги:

1. При пуше в ветку или создании PR запускается job.
2. Загружается текущая версия модели/промпта (из артефактов или реестра).
3. Прогоняется сьют кейсов, собираются метрики.
4. Результаты сравниваются с baseline (последняя стабильная версия).
5. Если ухудшение >5% — пайплайн фейлится, PR не мержится.
6. Генерируется отчёт с детализацией по каждому кейсу.

Пример конфигурации (YAML для GitHub Actions):

name: Regression Tests
on: [pull_request]
jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run regression suite
        run: |
          python run_regression.py \
            --suite data/regression_suite.json \
            --baseline baseline_metrics.json \
            --threshold 0.05
      - name: Upload report
        uses: actions/upload-artifact@v4
        with:
          name: regression-report
          path: report.html

5. Инструменты для регрессионного тестирования LLM

Пример использования DeepEval

from deepeval import evaluate
from deepeval.metrics import FaithfulnessMetric, AnswerRelevancyMetric
from deepeval.test_case import LLMTestCase

test_case = LLMTestCase(
    input="Какая столица Франции?",
    actual_output="Париж — столица Франции.",
    retrieval_context=["Париж — столица Франции."]
)

faithfulness = FaithfulnessMetric()
answer_relevancy = AnswerRelevancyMetric()

evaluate([test_case], [faithfulness, answer_relevancy])

6. Обработка ложных срабатываний

Автоматические метрики могут давать ложные срабатывания (например, LLM-as-a-Judge может быть нестабильным). Чтобы снизить шум:

• Калибровка порогов на исторических данных подбирается порог, при котором доля ложных срабатываний минимальна.
• Ручная валидация для кейсов, где метрики упали, но ответы субъективно не хуже, можно добавить ручную проверку (например, через интерфейс).
• Прогон нескольких судей использовать 2–3 разные LLM-судьи и брать среднее.
• A/B тестирование в проде если CI/CD пропустил изменение, но в продакшене метрики упали, кейс добавляется в сьют.

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

• Канареечный деплой сначала новая версия разворачивается на 5–10% трафика, мониторится в реальном времени, затем раскатывается полностью.
• Мониторинг после деплоя в продакшене собираются метрики (user feedback, latency, safety) и сравниваются с baseline. Если метрики ухудшаются — автоматический откат.
• Версионирование промптов каждый промпт хранится в Git, вместе с результатами регрессионного сьюта.

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

Задача Создать регрессионный тестовый сьют для простого RAG-бота (например, отвечающего на вопросы по документации FastAPI). Реализовать CI/CD с фейлом при ухудшении метрик.

Инструменты

• Python, DeepEval, pytest
• GitHub Actions
• FAISS + sentence-transformers для retrieval
• OpenAI API (или локальная модель) для генерации ответов

Шаги:

1. Собрать 50–100 вопросов-ответов из документации FastAPI (можно синтетически).
2. Разметить для каждого вопроса релевантный контекст (раздел документации).
3. Написать скрипт run_regression.py, который:
   • Загружает текущий промпт и модель.
   • Для каждого кейса генерирует ответ.
   • Считает faithfulness и answer relevance через DeepEval.
   • Сравнивает с baseline (сохранённые метрики).
4. Настроить GitHub Actions: при пуше в ветку main запускать скрипт, если ухудшение >5% — фейлить.
5. Сделать изменение промпта (например, добавить инструкцию «отвечай кратко») и убедиться, что пайплайн ловит регрессию.

Ожидаемый результат Рабочий репозиторий, где любой PR с изменением промпта или модели проверяется на регрессию, а отчёт сохраняется в артефактах.

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

Навигация

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