OpenAI сообщила, что в sample внутренних coding-agent evals более короткие system prompts подняли evaluation score примерно на 10–15%. Одновременно total tokens снизились на 41–66%, а cost на 33–67%. Для команды, которая месяцами наращивала правила поверх правил, это неприятная новость: нейро инструкция может стать хуже именно потому, что в неё добавляли «страховки».
Вывод не в том, что любой промт надо срочно урезать. Это внутренний результат OpenAI на coding-agent evals, а не обещание для каждой модели, задачи или продукта. В опубликованной рекомендации эти диапазоны даны как directional result. Поэтому переносить можно метод проверки, но не сами проценты. Практическая ценность в другом: появился ясный способ выяснить, какие слова действительно защищают качество, а какие лишь повторяют уже сказанное и расходуют контекст.
Длина сама по себе не делает инструкцию надёжнее
В работающем system prompt обычно смешаны четыре разных слоя:
- доменный контекст: термины, данные и правила предметной области;
- жёсткие ограничения: security, compliance и запреты;
- границы автономии: где агент отвечает, проверяет, диагностирует, меняет или строит;
- компенсирующие патчи: добавленные после единичного сбоя напоминания, повторы и запреты.
Первые три слоя нельзя вырезать ради красивого числа токенов. Даже компактная политика должна различать ответ, review и диагностику от изменений, сборки и исправлений; внешние записи, разрушительные действия, покупки и существенное расширение задачи требуют подтверждения.
Четвёртый слой обычно лучший кандидат на проверку. OpenAI рекомендует формулировать каждое правило один раз, показывать только релевантные инструменты и делать их описания краткими. Но примеры и stylistic guidance остаются, если в них зашито продуктовое требование или они закрывают измеренный разрыв качества.
В июльском обсуждении r/codex пользователи описывали знакомую картину: старые инструкции, оставшиеся от GPT-5.5, подталкивают GPT-5.6 к overplanning. Автор поста от 11 июля, набравшего 20 голосов на момент фиксации, предлагал отключать поведенческие патчи и возвращать только минимальное правило для воспроизводимого сбоя. Это не доказательство причинности, но полезная гипотеза для аудита.
Где короткий prompt может сломать продукт
Сильное возражение против сокращения справедливо: длинная инструкция иногда является не шумом, а архивом дорогих ошибок. Представьте задачу, в которой базовая версия останавливается перед внешней записью и запрашивает подтверждение. Если после удаления «повторяющейся» группы правил вариант без неё выполняет запись сам, сокращение провалило regression test, даже если стало дешевле и получило более высокую общую оценку.
Удаление из prompt правила согласования или критерия полноты может дать экономию, но только если на том же workload измерены tokens и cost, а требования к approval и полноте результата сохранены. Поэтому проверять нужно не «стал ли ответ короче», а сохранил ли агент обязательное поведение на одинаковом наборе задач. Внутренние диапазоны OpenAI стоит сопоставлять с собственными метриками:
| Что сравнивать | Почему это важно |
|---|---|
| Успех задачи и полнота результата | Экономия не компенсирует пропущенное требование |
| Обязательные доказательства и ограничения | Здесь чаще всего скрыт дорогой регресс |
| Input, cached и output tokens | Процент cache hit не показывает абсолютный расход |
| Latency и cost | Они имеют смысл только при сохранённом качестве |
Эксперимент, который отделяет улучшение от случайности
Начните с текущего рабочего prompt и набора tools. Затем выберите одну группу для удаления: например, повторяющиеся правила, нерелевантные описания инструментов или один компенсирующий патч. Прогоните тот же набор representative tasks и сравните результаты с базовой версией.
Не меняйте одновременно стиль, инструменты, примеры и порог автономии. Если качество просело, вы не поймёте причину. Если выросло, не сможете доказать, что помогло именно сокращение.
Полезный порядок проверки:
- Зафиксируйте baseline: prompt, tools и набор задач.
- Выпишите каждое правило в одну из четырёх групп: контекст, ограничение, граница автономии, патч.
- Уберите только одну группу дублей или нерелевантных описаний.
- Повторите те же evals и проверьте обязательные требования вручную или установленным способом.
- Оставьте изменение только при сохранённом качестве и понятной динамике total tokens, latency и cost.
Тред r/codex от 14 июля, набравший 138 голосов на момент фиксации, хорошо показывает вторую сторону проблемы: даже длинная anti-overengineering инструкция может породить новые противоречия. Это не аргумент против правил, а напоминание, что правило должно соответствовать конкретному риску и проходить проверку на задачах.
Когда stable короткий system prefix отделён от динамической задачи, provod.ai позволяет измерять input, cached и output tokens и сравнивать варианты prompt на одном наборе кейсов. Экономия засчитывается только после подтверждения, что качество не ухудшилось.
provod.ai — понятный расчётный контур для юридических лиц
Переведите AI из личных оплат в нормальную закупку: компания получает рублёвые расчёты, договор, счёт и закрывающие документы, а техническая команда — единый API.
В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.
Документальный контур не маскирует дополнительную маржу: модели оплачиваются по официальным ценам 1:1, без наценки provod.ai.
Оформите AI для бизнеса: форма регистрации · цены на модели · защита данных по 152-ФЗ · реквизиты для договора
Что для вашего representative workload дороже: сохранить длинный prompt, пока сокращённый вариант хотя бы раз нарушает approval boundary, критерий полноты или обязательное доказательство, или выделить время на regression eval по одному изменению за раз?
Top comments (0)