Как менять промпт, не ломая прод

Правка промпта — это изменение в проде

Промпты не выглядят как код. Они живут в текстовом поле, читаются по-человечески, и правка занимает десять секунд. Именно поэтому они вызывают аварии, которые никто авариями не считает: нет компилятора, который отвергнет изменение, нет ошибки типов, нет стектрейса и нет очевидного момента, где что-то сломалось. Система продолжает отвечать. Просто отвечать иначе.

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

Закрепите модель и версионируйте всю конфигурацию

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

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

Соберите оценочный набор из настоящих сбоев

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

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

Прогоняйте набор на каждое изменение и ставьте шлюз

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

Выкатывайте на срез, а не на всех

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

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

Держите аварийный выключатель с пригодным запасным путём

Поведенческие сбои — не те, что ловит мониторинг, поэтому нужен рычаг, гасящий функцию за секунды без выкладки. «Выключено» должно означать то, с чем продукт выживет: прежнюю конфигурацию, более простой детерминированный путь, очередь, направляющую работу человеку, или честное сообщение. Выключатель, превращающий функцию в страницу ошибки, в нужный момент никто не нажмёт.

Логируйте достаточно, чтобы объяснить регресс потом

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