Prompt engineering в продакшне: 7 практик, которые реально работают

2026-04-02 · Дмитрий Соколов

Prompt engineering в продакшне: 7 практик, которые реально работают

За последние два года мы прошли путь от «промпт — это строка в коде» до полноценного prompt CI/CD. По дороге собрали набор практик, которые стабильно снижают количество регрессий и ускоряют итерации. Делимся.

1. Промпт — это артефакт, а не строка

Храните промпты отдельно от кода: в Git, в registry, в базе. У промпта должен быть id, версия, owner и набор тестов. Подход «git diff на prompt.py» ломается, как только редактировать начинают не только инженеры.

2. Всегда фиксируйте temperature и seed

Если вам важна воспроизводимость выводов — temperature=0 и seed (где поддерживается). На eval-сете разница между temperature=0 и temperature=0.2 на наших задачах давала до 3–4% шума в accuracy.

3. Few-shot примеры живут рядом с промптом

Выносите примеры в отдельный файл и подставляйте через шаблон. Так проще менять их независимо от инструкций и вести changelog.

from promptlayer import Prompt

prompt = Prompt.load("intent-classifier", version="v7")
response = prompt.run(
    inputs={"user_message": msg, "examples": load_examples("intent-v7")},
    model="claude-3-sonnet",
    temperature=0,
)

4. Любое изменение прогоняется через eval-сет

Даже если «просто поменяли одно слово». Наш минимальный eval-сет — 200–500 размеченных примеров + 3 метрики (accuracy, latency, cost). Без зелёного eval — не релизим.

5. LLM-as-judge — не замена людям, а фильтр

Используем judge-модель как первый слой: она отсеивает очевидно хорошие и очевидно плохие ответы. В серую зону (confidence 0.4–0.7) смотрят люди. Так размечать в 4–5 раз быстрее, чем вручную читать всё подряд.

6. Версионируйте и промпт, и модель

Промпт, написанный под gpt-4-turbo-2024-04-09, может вести себя иначе на gpt-4-turbo-2024-08-06. Храните (prompt_version, model_id) как единый ключ. При смене любой части — прогон eval заново.

7. Мониторьте стоимость и latency на том же уровне, что accuracy

Классика: команда оптимизирует accuracy на eval-сете, выкатывает, через неделю FinOps-отчёт показывает +40% к счёту за API. Дашборд должен показывать все три метрики одновременно — иначе оптимизируете одно за счёт другого.

Таблица типичных ошибок

Симптом Частая причина
Регрессии после «косметических» правок Нет eval-сета или прогоняют не весь
Ответы расходятся между запусками temperature > 0 без seed
Внезапный рост latency Добавили длинный system prompt без кеша
Скачок счёта за API Сменили модель, забыли обновить бюджеты
Разные outputs у prod и staging Разные версии промптов/моделей

Вывод

Промпты — это код с неопределённым поведением. Весь привычный инструментарий (версионирование, ревью, eval, мониторинг) применим, только внутри него появляется новая ось — модель. Не пренебрегайте eval-сетом: это дешевле любого инцидента в проде.


← Ко всем постам