Context Compression

Короткая версия

Главные способы compression:

Главное правило

Compression нужен не для того, чтобы “влезло побольше”, а для того, чтобы:

• убрать шум;
• сократить cost и latency;
• защитить output reserve;
• улучшить signal-to-noise ratio.

Есть 8 retrieved chunks, из которых 3 почти одинаковые, 2 слабо связаны с вопросом, а 3 полезны.

Что делать?

1. Compression начинается не с суммаризации, а с удаления лишнего

Самый полезный first step — не суммаризировать каждый длинный блок, а проверить:

• нет ли дубликатов;
• нет ли слабых retrieval chunks;
• нет ли избыточного transcript;
• нет ли огромного сырого tool output;
• нет ли повторов между instructions, memory и retrieved docs.

Очень часто “compression” на практике означает просто лучше отобранный context.

2. Compaction

Compaction — лучший вид compression для multi-turn state. Его задача не сделать текст “короче вообще”, а превратить длинный transcript в короткое рабочее состояние:

• цель;
• решения;
• ограничения;
• открытые вопросы;
• последние важные результаты.

Это почти всегда полезнее, чем держать старые сообщения дословно.

3. Semantic Deduplication

В retrieval-heavy системах контекст часто раздувают почти одинаковые chunks:

• одна и та же policy в разных документах;
• FAQ и docs с одинаковыми формулировками;
• похожие search results;
• повторяющиеся snippets из codebase.

Semantic deduplication удаляет такие near-duplicates и оставляет только наиболее полезные фрагменты.

Практически это даёт сразу три эффекта:

• меньше токенов;
• меньше повторяющегося шума;
• меньше lost-in-the-middle.

4. Selective Inclusion

Иногда документ слишком длинный не потому, что он плохой, а потому, что для текущего вопроса в нём важны только отдельные фрагменты.

Selective inclusion значит:

• не тащить весь документ целиком;
• оставлять нужные section-ы, paragraphs или sentences;
• включать только query-relevant parts.

Это особенно полезно для:

• документации;
• help center;
• contracts/policies с длинной структурой;
• browser/search results.

5. Query-aware compression

Сильнее всего compression работает, когда учитывает не общий смысл текста, а конкретный текущий вопрос. Именно для этого обычно и полезны подходы вроде LongLLMLingua: сначала понять, какие части контекста реально важны под этот запрос, и только потом их сжимать.

Это лучше, чем “универсальный summary на все случаи”, потому что один и тот же документ может быть релевантен по-разному для разных вопросов.

6. Prompt Compression

Отдельный класс задач — уплотнение instructions, few-shot examples и длинных stable prefixes.

Здесь compression полезен, когда:

• policy blocks разрослись;
• examples повторяют друг друга;
• один и тот же contract объяснён слишком многословно.

Но есть важное ограничение: prompt compression не должен разрушать:

• safety constraints;
• schema contracts;
• critical wording;
• explicit refusal behavior.

7. Что лучше не сжимать агрессивно

Есть типы контента, где compression легко ломает correctness:

• юридически значимые формулировки;
• точные числа и табличные данные;
• код и syntax-sensitive content;
• machine-readable schemas;
• tool arguments, где важна точность.

8. Compression и caching не одно и то же

Compression уменьшает объём контекста.

Caching не уменьшает объём, а уменьшает стоимость повторного использования стабильного prefix.

На практике они хорошо сочетаются:

• сначала уплотняете stable blocks;
• потом делаете их cache-friendly;
• dynamic tail оставляете без лишнего шума.

9. Compression и RAG

Для RAG-систем compression обычно работает лучше всего в таком порядке:

1. retrieval;
2. rerank;
3. deduplicate;
4. selective inclusion;
5. compaction/compression при необходимости.

То есть compression должен быть не заменой retrieval quality, а его последним cleanup-слоем.

10. Как измерять пользу compression

Минимальный набор метрик:

11. Healthy compression pipeline

Самый практичный pipeline обычно такой:

1. remove obvious junk;
2. deduplicate near-duplicates;
3. include only relevant fragments;
4. compact long history/state;
5. query-aware compress only if still too large.

То есть лучший compression — почти всегда многоступенчатый, а не один “супералгоритм”.

Пример простого compression pipeline

def compress_context(
    chunks: list[dict],
    max_chunks: int = 4,
) -> list[dict]:
    ranked = sorted(chunks, key=lambda c: c["score"], reverse=True)

    # 1. dedup by normalized text key
    seen = set()
    unique = []
    for chunk in ranked:
        key = chunk["text"].strip().lower()[:300]
        if key in seen:
            continue
        seen.add(key)
        unique.append(chunk)

    # 2. keep top useful chunks only
    trimmed = unique[:max_chunks]

    # 3. selectively shorten long chunks
    for chunk in trimmed:
        if len(chunk["text"]) > 2000:
            chunk["text"] = chunk["text"][:2000]

    return trimmed

Даже такой примитивный pipeline уже даёт три здоровых свойства:

• убирает явные повторы;
• ограничивает общее число chunks;
• не тянет длинные фрагменты целиком без разбора.