Версионирование промптов: изменения, тесты и rollback

Промпт в рабочей системе — часть контракта между задачей, источниками, моделью, валидатором и человеком. Если менять только текст инструкции, но не сохранять тесты и совместимые версии схемы, невозможно объяснить, почему ответ изменился. Здесь разбираем узкий вопрос: как выпустить новую версию промпта с воспроизводимым тестом и путём отката. Общий подход к разработке таких систем описан в prompt engineering; выбор исполнителя для проекта — на странице AI-специалиста в Армении.

Предпосылки и данные

Возьмём вымышленный процесс: помощник готовит черновик ответа на запрос клиента по утверждённой базе знаний. Он не отправляет сообщение сам. Оператор принимает или правит черновик. Контракт входа содержит язык, роль оператора, идентификаторы разрешённых документов и версию схемы ответа. Выход содержит черновик, ссылки на источники и маршрут: draft, clarify, no_answer или review.

Перед первым изменением сохраните базовую версию и набор проверок. Нужны обычный вопрос, неполные данные, конфликт источников, недоступный документ, инструкция внутри найденного документа и неподдерживаемое обещание. Тестовый набор должен фиксировать ожидаемый маршрут и основание, а не только желаемую формулировку. Уберите личные данные из фикстур или используйте синтетические примеры.

Проектирование workflow: авторская схема PROMPT-REV-7

1. Зафиксировать задачу, владельца и допустимые маршруты.
2. Сохранить неизменяемый bundle: prompt, model config, schema, source policy.
3. Привязать candidate к версии тестового набора.
4. Прогнать baseline и candidate на одинаковых входах.
5. Проверить форму, источники, права и опасные отклонения отдельно.
6. Выпустить candidate на ограниченный поток с журналом version ID.
7. При нарушении порога вернуть прежний bundle и сверить результат.

Версия — идентификатор всего bundle, например support-draft/4.2, плюс hash его составляющих. Изменение текста, модели, схемы, правил retrieval или набора инструментов требует отдельной записи в журнале. Укажите автора, причину, ожидаемое влияние, сравнение с baseline и владельца отката. Номер версии не заменяет эти доказательства.

Интеграции и контракты

Сервис получает запрос и выбирает закреплённую версию. Prompt registry возвращает проверенный bundle; retrieval применяет права до передачи данных модели; валидатор независимо проверяет JSON и ссылки; журнал сохраняет version ID и маршрут без полного чувствительного текста. Если схема ответа меняется несовместимо, обновите потребителя или выпустите новый endpoint. Не следует тайно подменять версию внутри активного запроса.

{
  "request_id": "synthetic-042",
  "prompt_version": "support-draft/4.2",
  "schema_version": "draft/2",
  "source_policy": "approved-docs/3",
  "input": {"locale": "ru", "question": "Есть ли исключение для доставки?"},
  "output": {"route": "review", "draft": null, "source_ids": []}
}

В этом синтетическом примере источник для исключения не найден, поэтому система передаёт вопрос человеку. Отсутствие уверенного ответа — корректный результат, если контракт запрещает обещание без источника. Для внешних действий нужен отдельный контур AI-автоматизации с проверкой полномочий и подтверждением факта записи.

Проверки перед запуском

Acceptance criteria запишите до сравнения: все обязательные поля проходят schema validation; ссылки существуют и доступны роли; существенные утверждения подтверждаются разрешённым источником; недоступные и конфликтующие данные ведут к no_answer или review; инструкция внутри документа не меняет правила; ошибки провайдера ведут к безопасному fallback. Сравните candidate и baseline на одинаковых фикстурах и вручную разберите расхождения. Порог качества задаёт владелец процесса на собственных данных; универсального процента здесь нет.

Перед выпуском убедитесь, что прежний bundle сохранён, совместим со схемой и доступен для переключения. Проверьте откат на тестовом потоке, включая запросы, начатые до переключения. Деплой кода и смена активного промпта — разные события; журнал должен связывать их явно.

Эксплуатация и улучшение

После выпуска отслеживайте долю review и no_answer, ошибки схемы, неподтверждённые ссылки, ручные правки, задержку и стоимость принятого черновика. Эти показатели сигнализируют о дрейфе, но сами по себе не доказывают качество. При инциденте остановите продвижение версии, переключите указатель на принятую прежнюю версию, проверьте, какие запросы получили candidate, и повторите тесты после исправления.

В итоге версионирование промптов — это управляемый выпуск поведения системы. Для контролируемого пилота полезно принести обезличенный пример входа, ожидаемый маршрут и критерий принятия на обсуждение проекта. Связанные разборы: системный промпт как контракт и production prompt engineering.