Жизненный цикл промпта

Версии, контрольные кейсы, реабилитация и выпуск в рабочий контур

Большинство промптов начинают жизнь одинаково.

Человек открывает чат, пишет инструкцию, несколько раз её поправляет и наконец получает хороший ответ. После этого текст торжественно копируют в рабочую систему, объявляют готовым и стараются больше не трогать.

Иногда такой промпт действительно работает.

До первого необычного запроса.

Или до смены модели.

Или до того момента, когда кто-нибудь добавляет в конец ещё одно правило со словами:

ОЧЕНЬ ВАЖНО! НИКОГДА НЕ НАРУШАЙ ПРЕДЫДУЩИЕ ПРАВИЛА!

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

Так промпт из инструмента постепенно превращается в заклинание.

Чтобы этого не происходило, ему нужен жизненный цикл.

Промпт — не просто текст

Промпт часто сравнивают с программным кодом. Сравнение полезное, но не полное.

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

• конкретной модели;
• версии или режима модели;
• параметров генерации;
• системного окружения;
• переданного контекста;
• структуры пользовательского запроса;
• формата входных данных;
• предыдущих сообщений;
• инструментов, доступных модели.

Поэтому настоящий рабочий артефакт — это не один файл с красивым текстом.

Это связка:

промпт + целевая модель + параметры + входной контракт + выходной контракт + контрольные кейсы.

Если сохранить только текст, а через полгода запустить его на другой модели, можно получить совершенно иное поведение и долго убеждать себя, что раньше всё работало исключительно благодаря особой фазе Луны.

Рождение: сначала проблема, потом правило

Хороший промпт начинается не с формулировки.

Он начинается с наблюдаемой проблемы.

Не:

Модель отвечает как-то не очень.

А:

В трёх случаях из пяти модель добавляет к итоговой строке пояснение, хотя выходной контракт разрешает только готовые теги.

Разница принципиальна.

В первом случае человек недоволен результатом и собирается улучшать всё сразу.

Во втором — зафиксировано конкретное нежелательное поведение, которое можно воспроизвести и проверить.

Первая версия промпта должна отвечать минимум на четыре вопроса:

1. Какую задачу выполняет система?
2. Какие входные данные она получает?
3. Как должен выглядеть результат?
4. Что считается ошибкой?

На этом этапе промпт ещё не является рабочей системой. Это гипотеза, записанная в форме инструкции.

Ему только предстоит доказать, что он способен трудиться в НИИ ИИ без постоянного надзора Кота.

Паспорт промпта

У каждой версии должен быть собственный паспорт.

В нём желательно фиксировать:

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

Статусы могут быть простыми:

• draft — черновик;
• candidate — кандидат на проверку;
• control — контрольная версия;
• rehab — находится на реабилитации;
• released — допущен в рабочий контур;
• archived — снят с эксплуатации, но сохранён.

Последний статус особенно важен.

Старый промпт не следует уничтожать только потому, что появился новый. Новая версия может выглядеть чище, короче и современнее, а затем при первом реальном прогоне проиграть предшественнику.

В истории DES такое уже случалось: версия 5.0, собранная после перехода к новому инструменту разработки, при первом API-тесте проиграла 4.1.1. После этого пришлось возвращаться к более ранним исходникам и заново искать устойчивую основу. Самой стабильной в той линейке оказалась версия 3.0.

Версия с большим номером — это не повышение в должности.

Это только новый кандидат на собеседование.

Как нумеровать версии

Единого закона версионирования промптов не существует. Команда может использовать семантические номера, последовательные редакции, даты или собственную схему.

Важно не то, будет файл называться 1.2.1, 0.3-Cat или редакция после случая с сарафанами.

Важно, чтобы по номеру или имени можно было однозначно установить:

• какой именно текст запускался;
• на какой модели он проверялся;
• чем он отличается от предыдущего;
• какие результаты были получены;
• можно ли воспроизвести эксперимент.

Небольшое исправление опечатки может считаться patch-версией. Добавление нового правила — minor. Перестройка выходного контракта — major.

Но смена целевой модели нередко требует не следующего номера, а отдельной ветки.

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

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

Контрольные кейсы: память о прошлых ошибках

Промпт невозможно надёжно улучшать, если его проверяют только на примере, ради которого внесли последнюю правку.

Допустим, модель перепутала цвет предмета. Разработчик добавил новое правило, повторил тот же запрос и получил правильный ответ.

Исправлена ли система?

Неизвестно.

Возможно, новый пункт решил одну проблему и одновременно сломал распознавание людей, формат результата и чувство собственного достоинства тестировщика.

Поэтому вокруг промпта постепенно формируется набор контрольных кейсов.

В него входят:

Обычные случаи

Типовые запросы, ради которых система вообще создавалась.

Они показывают, не разучился ли промпт выполнять основную работу, пока команда героически исправляла редкое исключение.

Граничные случаи

Неполные, неоднозначные или противоречивые данные.

Здесь проверяется не способность модели угадать намерение разработчика, а умение корректно работать с недостатком информации.

Известные ошибки

Случаи, на которых предыдущие версии уже ломались.

После исправления они остаются в наборе навсегда. Иначе старая ошибка однажды вернётся, представится новым сотрудником и снова получит доступ к рабочему контуру.

Запрещённые сценарии

Промпт-инъекции, попытки изменить роль системы, извлечь закрытые инструкции, заставить модель нарушить формат или выдать данные, которых она не должна выдавать.

Набор тестов должен содержать не только входные данные и «правильный ответ», но и объяснение:

• что именно проверяется;
• какие свойства результата обязательны;
• какие варианты допустимы;
• какое поведение считается провалом.

Это важно потому, что в вероятностной системе два разных ответа могут быть одинаково корректными, а дословное совпадение с эталоном ещё не гарантирует качества.

Но это уже отдельная история — о том, почему правильный ответ ещё не становится gold-кейсом.

Кто принимает экзамен

Часть проверок можно автоматизировать.

Например:

• является ли ответ валидным JSON;
• присутствуют ли обязательные поля;
• соблюдена ли допустимая длина;
• отсутствуют ли запрещённые элементы;
• соответствует ли результат формальной схеме.

Другие свойства требуют содержательной оценки:

• опирается ли ответ на исходный материал;
• не добавлены ли отсутствующие факты;
• сохранена ли хронология;
• правильно ли применены предметные правила;
• не разрушен ли смысл ради формального соответствия.

Такую проверку может проводить человек, другая модель или сочетание нескольких методов.

Модель-судья удобна для массовых прогонов, но не является беспристрастным электронным божеством. Она тоже может ошибаться, предпочитать определённый стиль, пропускать систематические дефекты и уверенно объяснять, почему явно плохой ответ на самом деле прекрасен.

Поэтому критические решения нельзя строить на одном оценщике.

Формальная проверка отвечает за форму.

Эксперт — за предметный смысл.

Контрольные кейсы — за повторяемость.

А Кот — за то, чтобы после всего этого кто-нибудь действительно посмотрел на результат.

Реабилитация: когда промпт начал вести себя странно

Даже выпущенный промпт не становится бессмертным.

Со временем могут измениться:

• пользовательские данные;
• требования задачи;
• интерфейс системы;
• модель провайдера;
• доступные инструменты;
• длина или структура контекста.

Кроме того, сам промпт может постепенно зарасти исправлениями.

Обычно это выглядит так:

1. система допускает ошибку;
2. в конец добавляют запрет;
3. появляется другая ошибка;
4. рядом пишут ещё более строгий запрет;
5. через месяц половина инструкции начинается со слова «ВАЖНО»;
6. важным перестаёт быть вообще всё.

В DES процесс восстановления проблемной версии получил название rehab, или реабилитация.

Задача rehab — не наказать промпт и не дописать ему ещё десять угроз. Нужно установить, где именно возникла поломка.

Протокол rehab

1. Зафиксировать симптомы

Собрать реальные неудачные ответы вместе с полными входными данными, версией промпта, моделью и параметрами запуска.

Ответ без окружения почти бесполезен: невозможно понять, ошибся ли текст инструкции, модель, входной материал или предыдущий этап системы.

2. Воспроизвести ошибку

Один плохой ответ ещё не доказывает устойчивый дефект промпта.

Нужно выяснить:

• повторяется ли ошибка;
• возникает ли она в чистом чате;
• зависит ли от предыдущего контекста;
• проявляется ли на контрольной версии;
• связана ли с конкретной моделью.

Иногда после такого расследования выясняется, что лечить собирались не промпт, а остаточный контекст старого разговора.

3. Найти класс проблемы

Ошибка может находиться в разных слоях:

• неверное предметное правило;
• конфликт инструкций;
• двусмысленная формулировка;
• неудачный пример;
• недостаток входных данных;
• слишком широкий набор задач;
• несовместимость с целевой моделью;
• дефект следующего или предыдущего этапа.

Пока слой не установлен, правка остаётся случайным экспериментом.

4. Изменить одну причину

Чем больше правил меняется одновременно, тем труднее понять, какое из них помогло, а какое подготовило следующую аварию.

Поэтому хорошая реабилитация похожа не на капитальный ремонт кувалдой, а на контролируемую операцию:

одна гипотеза → одно изменение → повторный прогон.

5. Провести полный экзамен

Исправленный кейс запускается первым, но не последним.

После него новая версия должна пройти весь контрольный набор. Иначе локальное выздоровление может сопровождаться системной потерей памяти, зрения и поддержки JSON.

6. Сравнить с контрольной версией

Новая редакция должна быть не просто «хорошей».

Она должна показать, в чём именно стала лучше прежней и какой ценой достигнуто улучшение.

Если старая версия проходит 48 кейсов из 50, а новая — 49, но при этом отвечает вдвое дольше и расходует втрое больше токенов, решение уже не выглядит очевидным.

Выпуск в рабочий контур

После контрольных прогонов кандидат ещё не обязан сразу получать весь поток задач.

Способ выпуска зависит от масштаба системы.

Для небольшого внутреннего инструмента достаточно:

1. сохранить контрольную версию;
2. прогнать кандидата на полном наборе;
3. проверить несколько реальных задач параллельно;
4. оставить возможность быстрого отката;
5. зафиксировать результат выпуска.

Для системы с живым пользовательским трафиком могут применяться более сложные схемы:

• теневой запуск — новая версия обрабатывает копии настоящих запросов, но её ответы пока не показываются пользователям;
• канареечный выпуск — кандидат получает небольшую часть трафика;
• A/B-проверка — версии сравниваются по заранее выбранным продуктовым метрикам.

Эти методы не являются обязательным ритуалом для каждого промпта. Нет смысла разворачивать канареечный релиз из трёх микросервисов, если системой пользуется один Кот по вечерам.

Процесс должен быть соразмерен риску.

Но возможность сравнить версии и быстро вернуть предыдущую необходима всегда.

Наблюдение после выпуска

Работа не заканчивается в момент, когда версия получает статус released.

Необходимо продолжать собирать:

• новые классы ошибок;
• нарушения выходного формата;
• случаи необоснованных выводов;
• изменение длины и стоимости ответов;
• задержки;
• срабатывания резервных сценариев;
• пользовательские исправления;
• расхождения между моделями.

Каждая подтверждённая ошибка может стать новым контрольным кейсом.

Но не каждая ошибка требует немедленно менять промпт.

Иногда проблема единична. Иногда виноват входной материал. Иногда правило уже существует, но конкретная модель его нестабильно выполняет. А иногда исправление одного редкого случая нанесёт системе больше вреда, чем сама ошибка.

Поэтому между наблюдением и изменением должна находиться гипотеза.

Иначе жизненный цикл превращается в бесконечный:

увидел ошибку → дописал запрет → увидел новую ошибку → увеличил капслок.

Архив — тоже часть системы

Снятая версия не исчезает.

В архиве должны оставаться:

• её текст;
• паспорт;
• результаты тестов;
• причины выпуска;
• известные дефекты;
• причины замены;
• связь с предыдущими и следующими версиями.

Архив нужен не ради любви к папкам.

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

Без архива команда каждый раз начинает историю заново.

А потом с удивлением повторяет собственные эксперименты.

Жизненный цикл вместо магии

Рабочий промпт проходит несколько состояний:

проблема → гипотеза → черновик → кандидат → контрольные кейсы → rehab → выпуск → наблюдение → новая версия или архив.

Интуиция всё ещё нужна. Именно она часто помогает придумать первое решение.

Но интуиция не должна единолично подписывать акт приёмки.

Промпт становится инженерным артефактом не тогда, когда его назвали PromptOps и нарисовали для него красивую схему. Он становится им тогда, когда команда может ответить:

• почему появилась эта версия;
• на какой модели она работает;
• чем отличается от предыдущей;
• на каких случаях проверена;
• какие ошибки известны;
• как вернуть прежнее состояние;
• что произойдёт после следующей правки.

До этого перед нами всего лишь заклинание, которому однажды повезло.

А в НИИ ИИ даже магия обязана проходить испытательный срок.