Системный промпт — это налог на каждый вызов
Он растёт незаметно: правило за правилом, случай за случаем. Через полгода половина его содержимого относится к ситуациям, которых больше не бывает.
Системный промпт растёт по одному сценарию. Что-то пошло не так — дописали правило. Ещё раз не так — ещё правило. Никто никогда не удаляет.
Через полгода это полторы страницы, из которых треть описывает случаи, которых больше не случается, а ещё треть противоречит друг другу, потому что писалась в разное время под разные задачи.
Платится он в каждом вызове. Это первое, что стоит осознать: в отличие от запроса пользователя, системная часть едет всегда, включая вызовы, где половина её правил нерелевантна. При частой операции это ощутимая доля счёта.
Дороже денег — вытеснение внимания. Чем больше правил, тем ниже шанс, что модель выполнит каждое конкретное. Пятнадцать равноправных требований она соблюдает хуже, чем пять, — и вы не узнаете, какие десять не сработали.
Что я делаю раз в пару месяцев: читаю системный промпт целиком и по каждому правилу спрашиваю, помню ли я случай, ради которого оно написано. Не помню — удаляю. Обычно уходит около трети, и качество не проседает.
Отдельная привычка — не чинить системным промптом то, что чинится кодом. Правило «всегда возвращай валидный JSON» в системном промпте — это надежда; схема вывода — это гарантия. Каждый раз, когда правило можно перенести в код, промпт становится короче, а поведение — надёжнее.
Оговорка: у стабильной системной части есть плюс, ради которого её иногда держат длинной — она кешируется. Но кешируется и мусор.