TL;DR
Когда убираешь из системного промпта «лишнее» — есть риск удалить именно то, что держит модель на курсе. Исследование вводит понятие операционных якорей: конкретных деталей (точный синтаксис, формула, порядок проверок), которые занимают мало места, но без которых модель начинает «блуждать» — пробовать варианты, переспрашивать, делать лишние шаги. Результат: итоговых токенов тратится больше, чем если б промпт остался длиннее.
Главная находка — «короче» не значит «лучше» и не значит «дешевле». Конкретный пример из исследования: стратегия «упрощения пошаговых инструкций» сократила сам текст, но увеличила расход токенов при выполнении задачи в 1,14 раза против оригинала. Это парадокс: чем сжатее инструкция о последовательности шагов — тем больше модель отклоняется и потом «восстанавливается».
Метод предлагает не «сжимай всё», а сохраняй нужный тип якоря под тип задачи. Для задач с кодом и инструментами — точный синтаксис и API. Для пошаговых процессов — порядок и условия проверки. Для расчётных задач — формулы, пороги, схемы. Остальное — можно убрать.
Схема метода
ШАГ 1: Определи тип задачи
→ Код/инструменты? Пошаговый процесс? Правила и расчёты?
ШАГ 2: Выбери стратегию сохранения
→ Код-задачи: оставь точный синтаксис, импорты, команды
→ Процесс-задачи: оставь порядок шагов, условия проверки, что делать при ошибке
→ Правило-задачи: оставь формулы, пороги, схемы, исключения
ШАГ 3: Остальное — сокращай
→ Убирай объяснения «почему», вводные слова, повторы
→ Сохраняй только anchor-детали выбранного типа
Всё выполняется в одном промпте / ревизии системного промпта.
Пример применения
Задача: Ты ведёшь инвест-канал в Telegram и попросил GPT помочь анализировать компании перед публикацией. Написал подробный системный промпт на 800 слов. Потом решил «почистить» — срезал до 300. Качество разборов упало: модель путает мультипликаторы, игнорирует условия и пишет «в целом хорошая компания».
Промпт (аудит системного промпта):
Я хочу сократить свой системный промпт, но не потерять качество.
Вот мой текущий промпт:
"""
[вставь свой системный промпт]
"""
Моя задача относится к типу: [выбери одно]
— Код или работа с инструментами / API
— Пошаговый процесс с проверками (например: анализ, редактура, аудит)
— Расчёты, правила, формулы, критерии (например: оценка компаний, юридический анализ)
Сделай следующее:
1. Найди операционные якоря — конкретные детали, без которых модель будет угадывать.
Для моего типа задач это: [формулы/пороги/схемы] / [порядок шагов и условия ошибок] / [точный синтаксис и команды].
2. Отметь, какие части промпта НЕЛЬЗЯ сокращать — это якоря.
3. Отметь, что можно безопасно убрать: вводные фразы, объяснения «почему», повторы.
4. Предложи сокращённую версию с сохранёнными якорями.
Результат: Модель разобьёт промпт на две зоны: «нетрогаемые якоря» и «безопасно убрать». По каждому якорю объяснит, почему именно этот элемент критичен. Выдаст сокращённую версию, в которой убраны объяснения и лирика, но сохранены все конкретные детали, числа, порядок действий.
Почему это работает
Слабость LLM: модель не хранит намерение между шагами — она работает с тем, что написано сейчас. Если в промпте нет конкретного порога («P/E ниже 15»), модель сгенерит ответ из «общих знаний». Это чаще всего выглядит как расплывчатые формулировки или отклонение от задуманного формата.
Сильная сторона LLM: модель отлично следует явным, конкретным инструкциям — если они прописаны. Точный синтаксис, чёткий порядок шагов, конкретная формула — это не «лишние детали», это навигационные точки. Модель держится за них и не блуждает.
Как метод использует это: вместо «сократи всё» — выбирает, что именно сохранить. Для каждого типа задачи — свой тип якоря. Вся остальная «обёртка» убирается свободно.
Рычаги управления: - Тип задачи → определяет какие якоря приоритетны. Ошибся с типом — сохранишь не то. - Уровень детализации якоря → чем точнее («рентабельность > 20%» вместо «хорошая маржа»), тем меньше модель интерпретирует сама. - Условия ошибки → для пошаговых процессов особенно важны: «если шаг 2 не выполнен — стоп, не переходи к шагу 3». Без них модель «проскакивает» мимо.
Шаблон промпта
Я сокращаю {тип_документа: системный промпт / инструкцию / чеклист}.
Тип задачи: {код_и_инструменты / пошаговый_процесс / правила_и_расчёты}.
Правило сокращения — сохрани операционные якоря:
- Для кода и инструментов: точный синтаксис, команды, порядок импортов, обработка ошибок
- Для процессов: последовательность шагов, условия перехода, что делать при сбое
- Для правил и расчётов: формулы, числовые пороги, схемы, исключения из правил
Всё остальное — объяснения, вводные слова, повторы — убери.
Вот текст для сокращения:
"""
{твой_текст}
"""
Формат ответа:
1. Список якорей, которые сохраняешь — и почему каждый критичен
2. Сокращённая версия текста
Плейсхолдеры:
- {тип_документа} — что именно сокращаешь: системный промпт, инструкция для агента, чеклист
- {тип_задачи} — выбери один из трёх типов
- {твой_текст} — вставь оригинал
🚀 Быстрый старт — вставь в чат:
Вот шаблон аудита промпта. Адаптируй под мою задачу: [опиши что делает твой промпт].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит: что за текст ты сокращаешь и к какому типу задач он относится — потому что без типа задачи невозможно определить, какие якоря критичны, а что можно смело убрать.
Ограничения
⚠️ Нет универсальной стратегии: Один и тот же тип сокращения работает хорошо для одних задач и плохо для других. «Упрощение пошаговых инструкций» стабильно увеличивает количество блужданий модели — даже когда текст становится короче.
⚠️ Требует правильной классификации задачи: Если ошибся с типом задачи — выберешь не те якоря. Например, если задача на самом деле процессная, но ты отнёс её к расчётной — модель получит формулы, но потеряет порядок шагов и начнёт их пропускать.
⚠️ Не работает как разовая чистка: Разные части одного промпта могут требовать разных стратегий. Длинный промпт с кодом и пошаговым процессом — нужно аудировать зонами, а не целиком.
Ресурсы
Название работы: What Should a Skill Remember? Quality-Cost Trade-offs in Cost-Aware Skill Rewriting for Language Model Agents
Ресурсы: SkillEE на GitHub, бенчмарк SkillsBench
Авторы: Qinghua Xing, Yinda Chen, Bohan Lin (University of Science and Technology of China), Yaping Jin, Zhenhe Wu, Xinghao Chen, Hanting Chen (Huawei Technologies), Hang Zhou (Tianjin University)