Версионирование и хранение промптов

Ты написал отличный промпт. Протестировал. Внедрил. Через месяц понадобилось что-то поменять — а старая версия потеряна. Или ты изменил промпт, а через неделю обнаружил, что новая версия работает хуже, но откатиться не можешь. Версионирование решает эти проблемы.

Зачем версионировать промпты

Промпт — это код. Как и программный код, он evolves (эволюционирует): ты его улучшаешь, адаптируешь к новым требованиям, чинишь. И как код, промпт нужно хранить и отслеживать:

История изменений — когда и зачем меняли.
Возможность отката — если новая версия работает хуже.
Сравнение версий — что именно изменилось между v1.2 и v1.3.
Коллаборация — если над промптами работает несколько человек.

Формат хранения

Храни каждый промпт как отдельный файл. Файловая структура:

prompts/
  customer_support/
    classify_inquiry/
      v1.0_2026-04-01.md    ← первая версия
      v1.1_2026-04-15.md    ← добавили few-shot примеры
      v2.0_2026-04-30.md    ← полностью переработали
      eval_set.json         ← оценочный набор
      metrics.md            ← метрики по версиям

Внутри файла промпта — метаданные:

# classify_inquiry — классификация обращений клиентов
Версия: 1.1
Дата: 2026-04-15
Автор: @stepan
Изменения: добавлены 3 few-shot примера (жалоба, вопрос, предложение)
Точность на eval set: 91% (было 78%)

## Системный промпт
Ты — сотрудник поддержки...

## Промпт
Классифицируй обращение...

Git для промптов

Промпты — это текст. Git идеально подходит для их хранения:

git add prompts/customer_support/classify_inquiry/v1.1_2026-04-15.md
git commit -m "prompt(classify): v1.1 — add few-shot examples, accuracy 78→91%"

Преимущества Git:

Полная история всех изменений.
git diff показывает, что именно поменялось между версиями.
git blame — кто и когда изменил каждую строку промпта.
Ветки — можно экспериментировать с промптом в отдельной ветке.

Чек-лист для новой версии промпта

Каждый раз, когда меняешь промпт:

Создал новый файл с номером версии и датой.
Описал, ЧТО изменилось и ПОЧЕМУ.
Записал baseline-метрику (точность на eval set) для СТАРОЙ версии.
Измерил и записал метрику для НОВОЙ версии.
Убедился, что новая версия не хуже старой (или осознанно принял регрессию).
Закоммитил.

Шаблон файла промпта

---
prompt_id: classify_inquiry
version: 1.1
date: 2026-04-15
author: @stepan
status: active | draft | deprecated
accuracy: 91%
eval_set: classify_inquiry_eval.json
changes: added 3 few-shot examples
---

# Classify Customer Inquiry

## System Prompt
...

## User Prompt Template
...

## Parameters
- temperature: 0.1
- max_tokens: 200

## Eval Results
| Version | Date | Accuracy | Notes |
|---------|------|----------|-------|
| v1.0 | 2026-04-01 | 78% | Baseline |
| v1.1 | 2026-04-15 | 91% | +few-shot |

Типичная ошибка: потеря старой версии

Соблазн велик: поправил промпт прямо в веб-интерфейсе, увидел, что стало лучше, и продолжил. А файл не обновил. Через неделю забыл, что именно менял.

Решение: редактируй промпт ТОЛЬКО в файле. Копируй его в веб-интерфейс для тестирования, но «источник правды» — файл. Веб-интерфейс — это runtime, файл — это код.

Проверь себя

Твой промпт для анализа отзывов имеет точность 85%. Ты хочешь попробовать новую версию с изменённой ролью (было «аналитик», стало «маркетолог»). Опиши процесс версионирования: какие файлы создашь, что закоммитишь, как назовёшь коммит.

Итог

Промпт — это код. Версионируй его как код.
Храни промпты в файлах с метаданными: версия, дата, автор, изменения, метрики.
Используй Git: история, diff, blame, ветки для экспериментов.
Каждая новая версия — отдельный файл с записью об изменениях и метриках.
«Источник правды» — файл. Веб-интерфейс — только для тестирования.

Что дальше

Версионирование — production-практика. Prompt injection и галлюцинации — риски. В финальном уроке модуля соберём всё вместе: проведём аудит безопасности промпта и подготовим его к production.

Версионирование и хранение промптов