Промпт-инжиниринг: примеры слоёв вместо форков

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

Проблема форков

Развитие почти всегда идёт по одному сценарию. Есть рабочий промпт. Приходит второй клиент с небольшой спецификой - промпт копируется и правится. Приходит третий - копируется снова.

Через полгода:

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

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

Слои

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

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

Слой предметной области. То, что общее для класса задач: терминология поддержки, правила работы с документами, специфика домена.

Слой конкретного случая. Тонкий: название компании, особый термин, исключение из общего правила, список категорий.

Правило, которое решает большинство споров: если что-то верно более чем для одного случая, оно живёт слоем ниже. Специфика, попавшая в базу, ломает других; общее правило, оставшееся в верхнем слое, придётся дублировать.

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

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

Без набора примеров правка промпта - это гадание.

Минимальный работающий набор:

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

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

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

Версионирование

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

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

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

Что это даёт

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

Развёрнутый разбор такой схемы на реальной задаче с несколькими клиентами - в блоге: слои промптов вместо форков. Что стоит знать про сам промпт до того, как строить слои, - основы промпт-инжиниринга. Общая картина - гид по ИИ-агентам.