Prompt Compression

Суть в двух словах

Prompt compression полезен, когда:

• input-cost высок;
• контекст разрастается;
• latency важна;
• в prompt много повторов, воды и избыточных пояснений.

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

Что важно различать

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

Когда compression действительно работает

Правильный вопрос перед compression

Сначала стоит спросить:

1. Это повторяющийся префикс? -> возможно caching.
2. Это мусор в истории? -> возможно compaction.
3. Это второстепенные блоки? -> возможно priority truncation.
4. Только если нет — применяйте compression.

Это простое правило спасает от pointless prompt surgery там, где проблема вообще не в длине текста как таковой.

Где compression особенно полезен

Хорошие сценарии:

• длинные planning chains;
• RAG summaries;
• conversation state handoff;
• support/copilot contexts;
• multi-agent state passing;
• app-level fallback to cheaper models.

Почему compression полезен именно как economics tool

Технику легко воспринимать как чисто текстовую оптимизацию, но на практике она чаще нужна ради economics:

• длинный контекст мешает перейти на более дешёвую модель;
• input tokens становятся основной статьёй cost;
• latency растёт из-за bloated prompts;
• downstream routes получают слишком тяжёлый state.

То есть compression полезен не ради "красоты prompt-а", а ради возможности держать рабочий quality при более строгом token budget.

Менее полезен compression:

• на already compact prompts;
• там, где важен precise wording каждого правила;
• на юридически чувствительных instructions;
• если есть provider-side caching и high prompt reuse.

Если речь идёт о критичных system rules или policy wording, компрессия почти всегда рискованнее, чем кажется. Там лучше сначала думать о routing, caching или более аккуратной context assembly.

Что компрессия часто ломает

Главный риск — потеря meaning-bearing деталей:

• отрицаний;
• чисел и единиц;
• дат;
• edge-case exceptions;
• provenance and citations;
• nuanced policy wording.

То есть чем более sensitive and rule-heavy контекст, тем осторожнее надо относиться к compression.

Хорошая retention policy

Перед compression полезно явно фиксировать, что нельзя терять:

• числа и units;
• даты и дедлайны;
• negation и exceptions;
• citations / evidence markers;
• owner names and statuses.

Без такой retention policy модель легко делает "гладкий" текст, который уже хуже исходного с точки зрения работы системы.

Compression и RAG

В RAG compression полезен, но опасен:

• полезен, потому что retrieved chunks часто шумные;
• опасен, потому что можно сломать groundedness и вырезать ключевое evidence.

Поэтому для RAG обычно важнее не "сжать всё", а:

• очистить;
• дедуплицировать;
• приоритизировать;
• оставить evidence-bearing fragments.

То есть в RAG compression чаще должен быть последним шагом после retrieval hygiene, а не первым instinctive ответом на длинный контекст.

Сравнение с соседними приёмами

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

Ещё типичные проблемы:

• не измеряется quality before/after;
• compression применяется к system rules без осторожности;
• экономия токенов ставится выше factual fidelity;
• никто не считает, не выгоднее ли был caching.

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

Если проблема в:

• повторяющемся префиксе -> prompt caching;
• длинной истории диалога -> compaction;
• noisy retrieval chunks -> cleanup + rerank;
• избыточных низкоприоритетных блоках -> priority truncation.

Compression стоит включать там, где действительно нужно сохранить смысл в меньшем объёме, а не просто сделать prompt короче любым способом.

Engineering pattern

def compress_context(blocks):
    return [
        block for block in blocks
        if block.priority in {"critical", "high"}
    ]

Хорошая production-практика

• держать compression как отдельный measurable step;
• сравнивать answer quality до и после;
• не сжимать blindly всё подряд;
• считать economics вместе с caching;
• хранить retention policy: что именно нельзя терять.

Что полезно мерить

• compression ratio;
• answer quality delta;
• groundedness delta;
• citation retention;
• latency / cost improvement.

Если качество не падает, а стоимость снижается — техника окупается. Если quality delta отрицательная, "короче" не равно "лучше".

Production anti-pattern