Системная инструкция: как она влияет на ответ и на счёт

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

Из чего она состоит

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

Роль отвечает на вопрос, кто говорит и с кем. Двух-трёх предложений достаточно: «Ты редактор технических текстов, пишешь для инженеров, которые уже знают предметную область». Это сразу снимает половину проблем с тоном и уровнем объяснений.

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

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

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

Почему длинная инструкция вредит

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

У этого две цены. Очевидная — деньги: инструкция считается входными токенами при каждом обращении.

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

Как её чистить

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

Несколько частных признаков лишнего:

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

Что лучше держать не в инструкции

Часть вещей традиционно пишут в системный промпт, хотя им там не место.

Справочные данные — каталог, прайс, база правил. Если они большие и стабильные, их стоит вынести в отдельную часть запроса и кешировать; при обращении к российскому доступу через anthropic api это работает так же, как у вендора, и экономит заметную долю расхода.

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

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

Приёмы, которые действительно работают

Несколько формулировок дают заметный эффект почти в любой инструкции.

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

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

Границы длины в измеримых единицах. «Кратко» каждый понимает по-своему, «не более четырёх предложений» — однозначно.

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

Порядок и повторение

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

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

Инструкцию стоит хранить в отдельном файле с версией, а не в строке посреди кода. Тогда изменения видны в истории правок, и на вопрос «когда качество просело» есть ответ, а не догадки.

Как понять, что стало лучше

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

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

Коротко

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