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."