Крутой вопрос — у многих команд одна и та же боль: «поменяли промпт → не ясно, сломалось ли что‑то». Ниже — практическое руководство + набор шаблонов и паттернов, которые можно взять в CI/CD и вписать в привычный веб‑стек (Vitest/Playwright и т.д.).
Ключевые идеи (вкратце)
- Не полагаться на один вид проверки. Комбинация unit‑тестов промптов, регрессионных “golden” тестов, LLM‑оценки (judge), и прод‑мониторинга даёт покрытие.
- Для детерминированных проверок ставьте temperature=0 и фиксируйте max_tokens; для поведенческих тестов — используйте статистические пороги.
- Для UI — интегрируйте с Playwright; для логики промптов — Vitest/Jest/pytest в CI.
- Безопасность: автоматические прошивки jailbreak‑/injection‑тестов + ручная red‑team для критичных продуктов.
Когда понимать, что промпт «поплыл»
- Метрики качества упали (точность/ответы pass/fail по набору тестов).
- Увеличение частоты отказов/hallucinations в логах.
- Пользовательская телеметрия: рост жалоб, падение конверсий, увеличение ручных правок.
- Статистические сдвиги в представлении выдач (drift в embedding‑пространстве, увеличение perplexity, изменение распределения категорий ответов).
Сигналы должны быть и автоматические (CI/alerts), и продуктовые.
Типы тестов и как их строить
1) Unit‑тесты промпта
- Проверяют шаблоны: заполнение плейсхолдеров, отсутствие лишних токенов/инструкций.
- Быстрое локальное выполнение (mock LLM или вызываем модель с temperature=0).
- Пример: если промпт формирует JSON, проверить, что выдача валидный JSON и содержит нужные поля.
2) Golden / regression tests
- Набор входов + эталонные ответы. Сравнение: exact match, token diff или семантическая близость.
- Для генеративных ответов лучше сравнивать семантику (embedding cosine / BERTScore) либо чекать наличие ключевых фактов/фрагментов.
- Хранить «golden» ответы в репозитории; в CI — при изменении промпта — запускать.
3) LLM‑judge (автопроверка)
- Использовать более сильную модель как судью: даёт pass/fail и пояснение.
- Риск: judge тоже может быть нестабилен; лучше комбинация judge + метрик.
- Формировать prompt для оценки (checklist: полнота, точность, тональность, формат).
4) Safety / adversarial tests
- Набор jailbreak‑promptов, prompt‑injections, запросы с утечкой PII, вредоносные инструкции.
- Автоматические тесты должны содержать категории: «должен отказаться», «не выдавать PII», «не давать инструкции по вреду».
- Регулярно обновлять корпус атак.
5) E2E UI тесты (Playwright)
- Проверяют интеграцию промпта в интерфейс: загрузка, экранирование, отображение «сгенерированного» контента.
- Snapshot‑тесты UI + функциональные проверки (нажатие кнопок, ожидание ответа).
6) Production monitoring + canary
- Shadow/canary deployment: небольшой процент трафика на новую версию промпта.
- Логирование входов/ответов, подсчёт метрик: pass_rate (по автотестам), drift в embeddings, частота safety‑инцидентов.
- Автоматические оповещения при отклонении (>X sigma или порог).
Интеграция в веб‑стек (Vitest / Playwright)
- Vitest: хорошие для unit/regression тестов промпта (fast, node). Запускайте в CI на PR.
- Playwright: end‑to‑end сценарии с реальным UI и mocked/real LLM.
- Пример паттерна: в PR CI запустить:
1) unit tests (template, rendering)
2) regression tests (golden)
3) lightweight safety suite
4) если всё OK — deploy в канари
Пример простого теста (JS/TS, Vitest) — концепт
- 1) Запрос к LLM (temperature=0).
- 2) Проверка семантической близости через embeddings.
Пример (упрощённо):
- Впишите URL/ключи под свои SDK.
1) Генерация ответа:
fetch("https://api.llm.provider/v1/chat/completions", { method: "POST", headers: { Authorization: `Bearer ${API_KEY}` }, body: JSON.stringify({ model: "MODEL", messages: [{ role: "system", content: "You are a strict JSON generator..." }, { role: "user", content: "Summarize: <text>" }], temperature: 0, max_tokens: 200 }) })
2) Оценка семантики (embedding):
- Вычислите embedding ожидаемого ответа и embedding реального ответа, сравните cosine similarity. Порог, например, 0.85 для «прохода». Настройте порог эмпирически.
3) LLM‑judge (опция):
- Отправьте по примеру: «Оцени, содержит ли ответ X, Y, Z. Выведи PASS/FAIL и объясни».
Метрики и сигналы для автоматических алёртов
- Pass rate по regression suite (например, ниже 95% → тревога).
- Средняя cosine similarity по семантике.
- Частота safety‑fail (любая — критично).
- PROD‑метрики: CTR, время сессии, жалобы.
- Дрейф: KL/JS divergence между распределениями токенов/тем/embedding centroid.
Практические советы и шаблоны политики
- Разделяйте «логический промпт» (куда попадают переменные) и «системную инструкцию» (immutable base instructions). Меньше ошибок при правках.
- Маленькие инкременты в промптах; проверять каждый PR.
- Автоматизируйте smoke‑suite (быстрый набор тестов) для PR и более тяжёлую батарею — nightly.
- Keep golden tests «small but high‑value» — тяжёлые золотые наборы запускайте в nightly.
- Версионируйте промпты (git tag + хранение истории) — возможность отката.
Инструменты/репозитории, которые стоит посмотреть
- OpenAI Evals (openai/evals) — платформа для создания автоматизированных evals и red‑teaming.
- EleutherAI lm-evaluation-harness — для стандартных NLP задач (не идеально для prompt regression, но полезно).
- LangChain — содержит утилиты для оценки и feedback loop (evaluation chains).
- Для drift detection: Evidently AI, Deepchecks (адаптируйте для embeddings).
- Для red‑teaming: публичные датасеты jailbreak prompts (гуглите «jailbreak dataset», «adversarial prompts»).
Безопасность и injection — насколько критично?
- Если ваш продукт может создавать последствия (юридические, финансовые, здоровье, PII) — предрелизная проверка безопасности обязательна.
- Тесты безопасности включают:
- prompt injection (включение «/system» и др. инструкций в user input),
- попытки получить PII/секреты,
- запросы, тренирующие модель на вред,
- social engineering сценарии.
- Автоматические тесты должны быть базовыми; для глубоких атак выделяйте red‑team/ручную оценку.
Организация в CI (примерный pipeline)
- On PR:
- Lint + unit tests
- Smoke prompt tests (Vitest)
- Lightweight safety checks
- Nightly:
- Full regression suite
- LLM judge passes
- Canary rollout if nightly OK
- Post‑deploy:
- Shadow tests, telemetry drift monitoring, alerts
Риски и ограничения
- LLM‑judge может ошибаться/быть нестабильным — не полагайтесь на одну модель.
- Exact match не подходит для генеративных задач, используйте семантику и чеклисты.
- Автотесты нужно поддерживать и обновлять по мере роста функционала и появления новых типов запросов.
Небольшая чек‑лист‑шаблон для PR, меняющего промпт
- [ ] Запуск unit тестов (шаблоны/подстановки)
- [ ] Пройдены smoke regression tests
- [ ] Пройден safety smoke (jailbreaks)
- [ ] Обновлены golden ответы / внесено обоснование, если изменяются
- [ ] Canary rollout с мониторингом разрешён
Если хотите, могу:
- Прислать минимальный репозиторий с Vitest + примером теста/сравнения через embeddings.
- Помочь составить checklist для safety/regression под ваш сценарий (чат‑бот, summarizer, кодогенерация и т.п.).
Интересно, для чего вы используете LLM в продакшне? (чат, генерация текстов, валидация данных...) Это поможет предложить более конкретные тесты и метрики.