Системный промпт или короткие правила: как снизить дрейф

Почему длинный промпт начинает плыть

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

Особенно это заметно после нескольких правок. Команда добавляет одну оговорку, потом вторую, потом вставляет новый абзац между старыми. Через месяц текст уже похож на набор заплаток. Модель читает все подряд, а люди начинают по-разному понимать одни и те же строки.

Обычно длинный промпт плывет по четырем причинам:

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

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

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

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

Когда короткие правила дают больше контроля

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

У длинного системного текста есть неприятный побочный эффект: спорить о нем легко, а менять трудно. Если ответ стал слишком формальным, никто не знает, виноват ли абзац про стиль, блок про безопасность или старое исключение, которое забыли удалить месяц назад. С набором коротких правил причина видна быстрее. Убрали одно правило, прогнали тесты и сразу увидели разницу.

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

Что легче проверять на ревью

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

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

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

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

Короткие правила не делают систему проще сами по себе. Они просто не прячут ошибки. Для ревью это почти всегда плюс.

Когда один большой промпт все еще удобен

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

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

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

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

Дробить промпт пока рано, если:

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

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

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

Как разложить длинный промпт на модули

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

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

Как делить модули

Обычно хватает четырех групп:

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

Каждому модулю дайте короткое имя, которое легко читать на ревью. Например: role_support, format_json, ban_secrets, policy_pii. Короткие имена уменьшают лишние споры: команда обсуждает не весь промпт сразу, а конкретный блок.

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

Как проверить, что модули работают

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

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

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

Как проводить ревью без лишних споров

Больше всего времени съедает не сама правка, а спор о том, что именно команда сейчас обсуждает. Один человек смотрит на тон ответа, другой на риск, третий на длину системного текста. Замечаний много, а решение неясно.

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

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

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

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

Удобный шаблон ревью выглядит так:

• цель правила в одной строке;
• что изменили в тексте;
• какой хороший ответ ожидаем;
• какой плохой ответ теперь считаем ошибкой;
• как это проверим отдельно от метрик.

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

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

Пример для внутреннего чат-бота банка

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

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

После этого требования разделили на отдельные модули и проверили их по одному:

• тон: коротко, спокойно, без лишних объяснений;
• отказ: в каких случаях бот не отвечает и как именно это формулирует;
• формат: фиксированная структура ответа для внутренних сотрудников.

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

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

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

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

Частые ошибки

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

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

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

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

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

Рабочий вариант обычно скучнее, зато надежнее:

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

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

Если LLM-приложение идет в продакшен через AI Router, такие тесты удобно гонять на нескольких моделях и версиях правил. Тогда видно не абстрактный дрейф инструкций, а конкретный сбой: какой запрос его вызвал, после какого изменения и в каком модуле.

Быстрая проверка перед релизом

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

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

Перед релизом полезно пройтись по пяти вопросам:

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

Размытые слова вредят сильнее, чем кажется. Фраза по возможности будь кратким для одной модели значит три строки, для другой - десять. Лучше писать прямо: отвечай в 3-5 предложениях или если данных не хватает, задай один уточняющий вопрос. Так поведение модели становится предсказуемее.

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

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

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

Что делать дальше

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

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

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

Удобный порядок работы такой:

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

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

Если команда прогоняет тесты на разных моделях, полезно держать одинаковые правила и одинаковый маршрут запуска. В этом месте AI Router может быть удобен: один и тот же набор инструкций можно отправлять через api.airouter.kz и сравнивать ответы, не меняя SDK, код и сами промпты. Заодно проще проверить аудит-логи и увидеть, где проблема в модели, а где в правилах.

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