Вы обновили промпт в пятницу вечером. Вроде мелочь — добавили одно слово. А в понедельник RAG-система перестала отвечать на половину вопросов. Знакомо? Это она — prompt regression. И чем сложнее ваш пайплайн, тем чаще она будет подкрадываться. В этой статье я покажу, как построить артиллерию против скрытых ошибок, не превращая тесты в проклятие.
Почему промпты деградируют, а вы этого не замечаете
Любой промпт — это хрупкий компромисс. Вы меняете формулировку, чтобы улучшить одну метрику, а три других падают. Модель обновляется — и те же слова начинают работать иначе. Добавляете контекст из RAG-пайплайна — и внезапно теряете способность отвечать на простые вопросы. Беда в том, что человеческий глаз не способен заметить плавную деградацию: сначала 5% плохих ответов, потом 10%, а через месяц вы чините пожар.
Регрессия промпта — это ситуация, когда изменение промпта (или окружения) ухудшает качество ответов на запросы, которые раньше работали идеально. В классическом софте мы привыкли к регрессионным тестам. В мире LLM многие до сих пор проверяют «на глаз» — и платят за это.
Реальный случай из моей практики: команда добавила в инструкцию «Отвечай кратко» (2 слова). Через неделю RAG перестал выдавать цитаты из источников. Слово «кратко» убило контекстную точность. Тест на golden queries сразу показал падение метрики полноты на 0.15.
Кстати, мы уже обсуждали, как промпт-инжиниринг в продакшене превращается в инженерную дисциплину. Без тестирования это магия, а с тестами — математика. 2026 год окончательно убил магию.
Архитектура тестовой системы: от золотых запросов до LLM-судьи
Чтобы поймать регрессию, нужны три вещи:
- Golden queries — эталонный набор запросов с ожидаемыми ответами или правилами проверки.
- Метрики сравнения — численные показатели (semantic similarity, ROUGE-L, точность извлечения, score от LLM).
- Автоматический раннер — скрипт, который проганяет пайплайн по всем квери и сравнивает результат с эталоном.
1 Собираем golden queries
Золотой набор — это не 10 случайных вопросов. Это стресс-тест всех пограничных сценариев:
- Happy path — типовые запросы, которые должны работать идеально.
- Negative test — запросы, на которые система должна отказаться отвечать (вредный контент).
- Edge cases — пустой запрос, запрос с опечатками, вопрос с отрицанием («Какие продукты не содержат лактозу?»).
- Контекстная полнота — вопросы, где ответ зависит от корректного RAG-ректрива.
Для каждого запроса нужно определить ожидаемое поведение. Это может быть:
- Конкретный текст ответа (если он детерминирован).
- Список ключевых фактов, которые должны присутствовать.
- Числовой порог семантического сходства с эталонным ответом.
- Булевы флаги: содержит ли ответ ссылку на источник, не содержит ли токсичных фраз.
2 Метрики: что меряем и почему
Единого «правильного» числа не существует. Используйте комбинацию:
| Метрика | Что измеряет | Когда использовать |
|---|---|---|
| Cosine similarity (embedding) | Семантическая близость к эталону | Общая оценка качества ответа |
| ROUGE-L | Перекрытие по n-граммам | Фактологическая точность |
| LLM-as-a-judge (1-5) | Субъективная оценка релевантности, полноты, безопасности | Сложные критерии, которые сложно закодировать |
| Boolean checks (есть токен X, нет токена Y) | Наличие/отсутствие обязательных/запрещённых фрагментов | Безопасность, стилистика |
Пишем тестовый раннер: Python в действии
Хватит теории. Покажу на примере фреймворка pytest с кастомными фикстурами и ассертами. Предположим, у нас есть RAG-система, которая вызывает LLM (Claude 4 по умолчанию) с промптом. Тестовая структура:
# tests/test_prompt_regression.py
import pytest
from my_rag import answer_question
from metrics import (
compute_cosine_similarity,
llm_judge_relevance,
check_contains_fact,
check_no_hallucination
)
# Золотые запросы: (пользовательский запрос, ожидаемый_ответ, порог_сходства)
GOLDEN_QUERIES = [
{
"query": "Какие продукты не содержат лактозу?",
"expected": "Безлактозные продукты включают ...",
"min_similarity": 0.85,
"required_facts": ["лактоза", "альтернативы"],
"context": "...выдержка из базы знаний..."
},
{
"query": "Как удалить аккаунт?",
"expected": "", # пустой - система не должна отвечать на опасный запрос
"min_similarity": 0.0,
"safety_check": True
},
]
@pytest.mark.parametrize("golden", GOLDEN_QUERIES)
def test_prompt_regression(golden):
# Прогоняем через текущий пайплайн
response = answer_question(golden["query"], context=golden.get("context"))
# 1. Проверка на безопасность
if golden.get("safety_check"):
assert response.strip() == "", f"Ожидался отказ, получен ответ: {response}"
return
# 2. Семантическое сходство
sim = compute_cosine_similarity(response, golden["expected"])
assert sim >= golden["min_similarity"], (
f"Сходство {sim:.3f} ниже порога {golden['min_similarity']} "
f"для запроса '{golden['query']}'"
)
# 3. Проверка наличия фактов
for fact in golden.get("required_facts", []):
assert fact.lower() in response.lower(), (
f"Факт '{fact}' отсутствует в ответе"
)
# 4. LLM-as-a-judge: проверка галлюцинаций
score = llm_judge_relevance(response, golden["query"])
assert score >= 4, f"LLM judge поставил {score}/5"
Обратите внимание: для каждого golden query мы задаём разные пороги и проверки. Это не универсальная рубашка, а кастомная система допусков. Именно так и нужно строить — гибко, под каждый сценарий.
Кстати, 6 паттернов промпт-инжиниринга помогут вам избежать типовых ошибок при написании самого промпта, а тесты поймают регрессию не только от изменений, но и от смены модели. Например, если вы переходите с Claude 4 на Gemini 2.5 Pro, тесты мгновенно покажут, где сломалось поведение.
Интеграция в CI/CD: не дайте плохому промпту попасть в прод
Мало написать тесты — нужно заставить их запускаться на каждый PR. Вот минимальная конфигурация GitHub Actions:
# .github/workflows/prompt-tests.yml
name: Prompt Regression Tests
on: [pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.12'
- run: pip install -r requirements.txt
- run: pytest tests/test_prompt_regression.py --junitxml=report.xml
- uses: dorny/test-reporter@v1
if: always()
with:
name: Prompt Tests
path: report.xml
reporter: java-junit
Важный нюанс: LLM-тесты медленные и дорогие. Обычно я рекомендую запускать полный набор golden queries (100-200 штук) только на PR, где менялись промпты или конфигурация RAG. В остальных PR достаточно прогонять сэмпл (например, 20 критичных кейсов). Используйте метки (labels) или детектирование изменённых файлов.
Типичные ошибки и как их избежать
Ошибка №1: Золотые запросы шиты на одну колодку. Вы пишете тесты на текущую (идеальную) версию промпта. А потом меняете промпт — и тесты падают. Но падают не потому, что стало хуже, а потому что ожидаемый ответ устарел. Решение: хранить golden queries в отдельной директории с датами и пересматривать их раз в месяц, привлекая предметных экспертов. A/B-тестирование на малых выборках может помочь обновлять эталоны на основе пользовательских предпочтений.
Ошибка №2: LLM-as-a-judge переобучается под golden queries. Если вы используете одну и ту же модель для суда и для ответов, может возникнуть систематическая ошибка — судья будет хвалить близкие себе по стилю ответы. Лучше разделять: для ответа — лучшая production-модель, для оценки — другая (например, ответ генерирует Claude, а оценивает GPT-4o или Mistral Large 3).
Ошибка №3: Пропускаете отрицание. Reprompt — отличный пример, как изменение одного слова может разорвать логику. Тесты на запросы с отрицанием («не», «кроме», «без») должны быть обязательными. И не доверяйте единичной метрике — проверяйте через несколько разных аспектов.
Также полезно прочитать про википедию промптов с автозаполнением и тестированием — там есть готовые решения для организации тестовой базы.
Когда тестов недостаточно: мониторинг в продакшне
Golden queries проверяют известные грабли. Но промпт может сломаться на данных, которых нет в тестах. Поэтому после CI тестов нужно настроить мониторинг реальных ответов. Собирайте логи, считайте долю отказов, процент «не знаю» ответов, жалобы пользователей. Подключайте LLM-as-a-judge на сэмпле продакшн-трафика. Если метрика упала — триггерите перезапуск полной тестовой батареи.
Кстати, автоматическая оптимизация промптов может генерировать новые варианты, но без тестов вы не узнаете, не убило ли улучшение что-то важное.
Даже если вы автоматизировали всё подряд, ручное тестирование остаётся важным навыком. Например, для проверки субъективных аспектов (вежливость, стиль) человек всё ещё лучше машины. Если хотите прокачать эти скиллы, рекомендую курс Ручное тестирование (Manual QA) от Skillbox — он закроет пробелы в методологии тестирования, которые часто не учитывают в AI-командах.
Подытожим без выводов
Prompt regression — это не «баг», а неизбежное свойство нестабильных сред. Единственный способ с ней бороться — автоматические тесты, встроенные в вашу инженерную культуру. Golden queries, разнообразные метрики, CI/CD и мониторинг — четыре слоя защиты. Начните с малого: заведите 10-20 эталонных запросов, напишите простой pytest-раннер, запускайте его перед каждым коммитом. Через месяц вы не сможете жить без этого.
Следующий вызов — автоматическое поддержание golden queries в актуальном состоянии. Я ставлю на то, что уже через год LLM сами будут предлагать тестовые сценарии на основе анализа продакшн-логов. А пока — стройте фундамент. И ни пуха, ни пера.
