Как тестировать промпты (prompt regression testing)?

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

Prompt regression testing — это набор практик и инструментов, гарантирующих, что изменение промпта не ухудшит качество ответов на уже протестированные сценарии. Процесс строится на фиксации baseline (эталонных ответов старого промпта на golden dataset), прогоне того же набора через новый промпт и семантическом сравнении результатов с помощью LLM-as-Judge или косинусной близости. Отклонение выше заданного порога (ε, обычно 10–15%) вызывает alert и отправляет кейс на ручную проверку. Встраивание в CI/CD позволяет автоматически ловить регрессии при каждой модификации промпта.

1. Что такое prompt regression testing и зачем он нужен

Промпты (системные сообщения, инструкции, шаблоны) в агентных RAG-системах — это «код» на естественном языке. Изменение даже одной фразы может исправить одну ошибку, но сломать другие, корректно работавшие ранее. Prompt regression testing — аналог юнит-тестов для промптов: проверяет, что новые версии не ухудшают ответы на фиксированном наборе запросов.

В RAG|Agentic RAG важность выше: агенты выполняют многошаговые действия, и регрессия в одном шаге (например, в правиле выбора инструмента) может каскадно испортить финальный ответ. Без regression testing изменения промпта превращаются в гадание.

2. Компоненты: baseline, golden dataset, regression run

2.1 Golden dataset (золотой датасет)

Набор пар (вход → ожидаемый ответ), размеченный вручную или собранный из продакшн-логов. Характеристики:

• репрезентативен (разные типы запросов, краевые случаи);
• не слишком велик (20–100 примеров для быстрого прогона);
• стабилен (не меняется без веской причины).

2.2 Baseline

Результаты выполнения v1 промпта на golden dataset:

• ответы (текст);
• метаданные (latency, число токенов, вызванные инструменты);
• эмбеддинги ответов (для cosine similarity).

Baseline сохраняется в репозитории (например, в JSON/YAML) и версионируется вместе с промптом.

2.3 Regression run

Запуск того же golden dataset через v2 промпта с теми же параметрами (модель, температура, top-p). Результаты сравниваются с baseline.

3. Метрики сравнения: как измерять «поломку»

Простое сравнение строк (exact match) редко работает — LLM может перефразировать ответ, не теряя смысла. Используют семантические метрики.

3.1 Cosine similarity на эмбеддингах

from sentence_transformers import SentenceTransformer
from sklearn.metrics.pairwise import cosine_similarity

model = SentenceTransformer('all-MiniLM-L6-v2')
emb1 = model.encode("Ответ от старого промпта")
emb2 = model.encode("Ответ от нового промпта")
score = cosine_similarity([emb1], [emb2])[0][0]  # от -1 до 1

Порог: 0.85–0.95 (зависит от модели). Просто, быстро, но не улавливает фактологические ошибки — может дать высокий score при одинаковой структуре, но разном содержании.

3.2 LLM-as-Judge

Используется отдельный LLM (GPT-4, Claude, Llama), который получает промпт, запрос, старый и новый ответ и выставляет оценку (например, от 1 до 5) или вердикт «identical / minor change / major regression».

Плюсы улавливает тонкие смысловые различия, может объяснить причину. Минусы дорого, может быть нестабилен (зависит от температуры), добавляет задержку.

3.3 BERTScore / BLEU / ROUGE

• BERTScore — F1 на токенах с поправкой на контекст (надёжнее BLEU для LLM).
• BLEU/ROUGE — подходят для перевода/суммаризации, но плохо для генеративных ответов (карают перефразирования).

Таблица сравнения методов:

Рекомендация комбинировать — сначала дешёвая cosine similarity, для кейсов с порогом ниже ε запускать LLM-as-Judge.

4. Порог (ε) и alert

Порог выбирается эмпирически:

• для cosine similarity: ε = 0.1 (т.е. изменение на 10% косинусной дистанции);
• для LLM-as-Judge: ε = 1 балл по 5-балльной шкале.

Если метрика упала ниже порога → alert. Формат: список запросов с изменёнными ответами, график распределения score, ссылка на ручное сравнение.

Пример алерта в CI/CD:

⚠️ Prompt regression detected in 3/50 test cases:
- "как сбросить пароль" → score 0.72 (порог 0.85)
  old: "Перейдите в настройки..."
  new: "Для сброса используйте форму..."
  LLM judge: "minor change, safe"
- "удалить аккаунт" → score 0.55
  old: "Вы уверены? Эта операция необратима."
  new: "Напишите в поддержку."
  LLM judge: "major regression — пропущено предупреждение"

5. Ручная валидация (manual review)

Не все изменения можно автоматизировать. Случаи, когда требуется человек:

• противоречивые сигналы — cosine similarity низкая, LLM-as-Judge считает изменение безопасным;
• изменение тона или стиля — бизнес-требования могут считать «дружелюбный тон» регрессией, если до этого был формальный;
• новые краевые случаи — если golden dataset не покрывает изменение.

Процесс:

1. Автоматика помечает спорные кейсы.
2. Разработчик/продукт-менеджер просматривает пары (старый/новый) в специальном UI.
3. Принимает решение: принять (обновить baseline) или отклонить (откатить промпт).

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

Лучшая практика — запускать regression testing при каждом push, изменяющем файл промпта.

Пример пайплайна (GitHub Actions):

name: Prompt Regression Tests
on:
  pull_request:
    paths:
      - 'prompts/*.yaml'
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: pip install -r requirements.txt
      - run: python run_regression.py --baseline baseline.json --new_prompt prompts/v2.yaml
      - name: Fail on major regressions
        if: ${{ env.REG_SCORE < 0.9 }}
        run: exit 1

Версионирование промптов — хранить .yaml/.jinja файлы в Git, тегировать релизы. Baseline автоматически генерируется для каждой версии.

7. Инструменты

Выбор зависит от масштаба: для стартапов — pytest + SentenceTransformers, для enterprise — LangSmith или коммерческие решения.

8. Best practices

• Поддерживать golden dataset актуальным добавлять новые сценарии из продакшн-логов, убирать устаревшие.
• Автоматически детектить мультимодальные регрессии если промпт влияет на выбор изображений/аудио — сравнивать и их эмбеддинги.
• Тестировать не только главный ответ, но и промежуточные шаги (в агентах): например, какие инструменты выбрал агент, порядок действий.
• A/B тестирование в дополнение регрессионные тесты — офлайн, A/B — онлайн. Они не заменяют друг друга.
• Документировать изменения каждый commit к промпту должен содержать метку "prompt_version" и ссылку на отчёт регрессии.

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

Задача написать скрипт, который при изменении системного промпта RAG-агента запускает regression testing и отправляет отчёт в Telegram.

Инструменты Python, sentence-transformers, openai (или другой LLM), pytest, pandas, python-telegram-bot.

Шаги:

1. Собрать golden dataset (30 вопросов) с эталонными ответами от старого промпта.
2. Реализовать функцию generate_response(question, prompt_template) — вызывает LLM с заданным промптом.
3. Для каждого вопроса прогнать старый и новый промпт.
4. Посчитать cosine similarity между эмбеддингами ответов.
5. Для пар с score < 0.8 вызвать LLM-as-Judge (GPT-4o) с инструкцией «Оцени, изменился ли смысл ответа: 1 — кардинально, 5 — идентично».
6. Если средний score по всем вопросам < 0.85 или >20% кейсов имеют оценку LLM ≤ 2 — отправить alert в Telegram.
7. Интегрировать скрипт в local pre-commit hook (или GitHub Action).

Ожидаемый результат автоматическая защита от «тихих» регрессий: каждое изменение промпта сопровождается отчётом, а при обнаружении проблем — уведомление команде.

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

Prompt regression testing тесно связан с общей оценкой RAG (вопрос 5): baseline включает не только ответ, но и retrieved документы. Изменение промпта может повлиять на то, как LLM использует контекст — это отслеживается теми же методами. Вопрос 7 (latency) важен, так как регрессия может быть не только в содержании, но и в скорости (например, новый промпт заставляет LLM генерировать больше токенов). Вопрос 8 (no-answer scenarios) — critical edge case: если промпт меняет правило «если ответа нет — скажи об этом», regression testing должен проверить, что система не начала выдумывать. Self-RAG (вопрос 10) добавляет циклы рефлексии, что требует тестирования регрессии на каждом шаге агента.

Навигация

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