# Context Pruning: Cut LLM Tokens Without Losing Quality

**Szerző:** Jim Allen Wallace (Redis blog)
**Dátum:** 2026. május 9.
**Forrás:** https://redis.io/blog/context-pruning-llm-tokens/

---

## Core Concept

A context pruning célja, hogy szelektíven eltávolítsa az alacsony értékű tokeneket, mondatokat vagy bekezdéseket az LLM inputból — ezzel csökkentve a költségeket, latenciát, és gyakran javítva a kimeneti minőséget.

## Négy Pruning Módszercsalád

### 1. Token-szintű pruning (LLMLingua-2)
- Egy kisebb modell (pl. XLM-RoBERTa-large) tokenenként Yes/No döntést hoz
- **3x–6x gyorsabb** mint a korábbi 7B-s módszerek (párhuzamos feldolgozás)
- **Kockázat:** mondattöredékek, amiket a modellnek kell összeraknia

### 2. Mondat- és chunk-szintű pruning
- Teljes mondatokat vagy fix méretű rész-okat tart meg/dob el
- **Előny:** elkerüli a token-szintű töredezést, jól illik RAG pipeline-okhoz
- **Hátrány:** filler szavakat is bent tart, ha a mondat hasznos részt tartalmaz

### 3. Attention-alapú pruning (EHPC)
- A modell saját attention mintáit használja a fontossági pontozáshoz
- **Előny:** nincs szükség külső scoring modelre
- Specifikus attention head-ek azonosítják a releváns tokeneket

### 4. Dinamikus layer-progresszív pruning (SlimInfer)
- **Inference közben** történik, nem előtte
- Mélyebb layerekben agresszívebb vágás (az információ már szétterjedt)
- "Information diffusion" elv: a fontos kontextus layer-ről layer-re terjed

## Miért Nem Elég a Nagyobb Context Window?

- **"Lost in the middle":** U-alakú teljesítménygörbe — a középső kontextus romlik
- **Gyakorlati limit < spec:** RULER benchmark szerint az effektív hossz sokkal rövidebb (1M spec → 100K-nál degradáció)
- **Model-függő:** GPT-4o javult 128K-nál, más modellek 32K felett romlottak
- **Input hossz önmagában ront:** Egy 2025-ös tanulmány 67.6 pontos MMLU romlást mért 30K padding tokennél

## Számok: Mit Spórol a Pruning?

| Módszer | Kompresszió | Hatás |
|---------|------------|-------|
| LLMLingua | 20x | ~1.5 pont veszteség GSM8K-n, 1.7-5.7x latency speedup |
| MUSTAFAR (KV cache) | 55% | 2.23x throughput |
| FastKV | — | 1.82x prefill, 2.87x decoding |
| Redis LangCache | — | 15x gyorsabb válasz, 73% költségcsökkentés |

## Hibamódok

### Információvesztés & Hallucináció
- Túl agresszív vágás → hallucináció növekedés
- Rövid kontextusnál kevesebb a biztonságosan eltávolítható zaj
- **Megoldás:** query-aware módszerek, amik a kérdés szempontjából releváns tokeneket tartják meg

### Kód & Strukturált Adat
- Token-szintű pruning tönkreteheti a szintaktikai érvényességet
- SWE-Bench: domain-specifikus SWE-Pruner 64% siker, LLMLingua-2 54%
- **Megoldás:** chunk-szintű pruning (függvények, osztályok egészben)

### Multi-turn Beszélgetés
- A jövőbeli fordulók olyan tokeneket igényelhetnek, amik most irrelevánsnak tűnnek
- **Megoldás:** dual-tier memória (working memory + long-term memory)

### Kumulált Degradáció
- Pruning + kvantálás + egyéb optimalizálások → nem-lineáris minőségromlás
- **Megoldás:** egyszerre több task-típuson értékelni, ne egy benchmarkon

## Semantic Caching + Pruning: Réteges Architektúra

```
Query → Semantic Cache (Redis)
  ├─ Hit → cached response (nincs LLM hívás)
  └─ Miss → Retrieval → Pruning → LLM → Cache response
```

- Redis LangCache: 90% precision, ~200ms latency, 50 párhuzamos query
- Ugyanaz a vector search infrastruktúra hajtja a cache-t és a pruning retrieval-t

## OpenClaw Relevancia

- **Inbox-processor:** A transcript első N% elég lehet a témák azonosításához, a teljes transcript helyett kulcspont extrakció (recite-before-answer)
- **Wiki rendszer:** A nagy topic fájlok pruningje a drift check előtt — csak a releváns szekciókat kell vizsgálni
- **Memóriastratégia:** A dual-tier memória (working/long-term) már implementált: daily logs vs MEMORY.md
- **Caching potenciál:** Hasonló podcastok/query-k esetén a semantic caching csökkenthetné az ismételt LLM hívásokat

## Idézetek

> "Your agents aren't failing. Their context is."

> "Moderate, task-appropriate pruning can improve LLM outputs compared with dumping everything into a massive context window."

> "Pruning works best as one piece of a broader system, paired with semantic caching upstream."