Prompt-compressie voor lange contexten: samenvatten of inkorten

Waarom contextcompressie noodzakelijk blijft bij grote contextvensters

De beschikbaarheid van contextvensters van 128k tot 1M tokens suggereert dat ontwikkelaars zich geen zorgen meer hoeven te maken over de omvang van hun prompts. Dit is een hardnekkig misverstand. Een groot contextvenster garandeert namelijk niet dat een model alle informatie even nauwkeurig verwerkt. Het bekende lost-in-the-middle fenomeen toont aan dat transformermodellen informatie aan het begin en het einde van een lange prompt aanzienlijk beter ophalen dan feiten die ergens in het midden verborgen liggen.

Daarnaast schaalt de rekenkracht die nodig is voor de prefill-fase van de inference lineair met de contextlengte (en kwadratisch in de pure self-attention lagen zonder optimalisaties). Een prompt van 80.000 tokens zorgt voor een merkbare vertraging in de Time To First Token (TTFT), wat interactieve toepassingen en chatbots traag en stroef maakt. Wie de werkelijke financiële impact van omvangrijke contexten wil analyseren, vindt in het artikel over wat een lang contextvenster echt kost een gedetailleerde economische berekening.

Tot slot leidt onnodige contextvervuiling tot hallucinaties en instructiedrift. Wanneer een prompt duizenden regels irrelevante documentatie, overtollige logregels of verouderde gespreksbeurten bevat, raakt het aandachtsmechanisme overbelast. Doelgerichte compressie fungeert als een signaal-ruisfilter: het dwingt het model zich te concentreren op de kerninstructies en de direct benodigde variabelen.

Semantische compressie: recursief en hiërarchisch samenvatten

Semantische compressie maakt gebruik van een taalmodel om een lange tekst te herschrijven naar een compactere representatie met behoud van de betekenis. Dit gebeurt meestal via een secundaire, goedkopere LLM-aanroep (zoals een compact flash- of haiku-model). We onderscheiden hierin twee gangbare patronen: rolling buffers en hiërarchische MapReduce-samenvattingen.

Bij een rolling summary buffer wordt na elke gespreksbeurt de oudste interactie samengevoegd met een bestaande samenvatting. Het promptformaat behoudt daardoor een vaste structuur: een permanente systeemprompt, een geactualiseerde statusparagraaf en de meest recente twee tot vier dialoogwisselingen. Hierdoor blijft het totale tokenaantal binnen een voorspelbare bandbreedte.

Bij hiërarchische samenvatting wordt een lang document opgeknipt in thematische brokken (chunks). Elk brok wordt parallel samengevat, waarna de tussenresultaten in een tweede stap worden gecondenseerd tot een overkoepelend uittreksel. Dit patroon is zeer geschikt voor lange rapporten of transcripties, maar introduceert specifieke risico's:

• Informatieverval (telefooneffect): Bij meerdere opeenvolgende samenvattingslagen gaan subtiele nuances, ontkenningen of randvoorwaarden onherroepelijk verloren.
• Hallucinatie-accumulatie: Als een eerdere samenvatting een klein feitelijk foutje bevat, wordt deze fout in daaropvolgende stappen behandeld als een absolute waarheid.
• Latentie- en kostenoverhead: Het genereren van samenvattingen vereist extra modelaanroepen, wat zowel de totale verwerkingstijd als het API-verbruik per sessie verhoogt.

Syntactisch snoeien: deterministic pruning en token truncation

In tegenstelling tot semantische compressie vertrouwt syntactisch snoeien (pruning) niet op een taalmodel, maar op deterministische code en heuristieken. Het doel is om tokens te elimineren zonder dat er ook maar één extra LLM-aanroep nodig is. Dit levert een directe reductie in latentie en verwerkingskosten op.

Deterministische pruning kan op verschillende niveaus worden ingericht:

• Structurele data-compressie: Het converteren van logge JSON-payloads naar compactere formaten zoals YAML, TOON of door tabs gescheiden tabellen. Alleen al het verwijderen van overtollige witruimtes, accolades en herhaalde sleutels kan 25% tot 40% van de tokens besparen.
• Stopwoord- en stijleliminatie: Het programmatisch filteren van beleefdheidsvormen, herhaalde headers, boilerplate-disclaimers en standaard HTML-opmaak in brondocumenten.
• Attention-aware token dropping: Geavanceerdere systemen berekenen de informatiedichtheid van zinnen via TF-IDF of embedding-gelijkenis en verwijderen paragrafen die een te lage relevantiescore hebben ten opzichte van de huidige gebruikersvraag.

Het grote voordeel van syntactisch snoeien is de absolute precisie rondom variabelen. Getallen, bron-URL's, identificatienummers en variabelenamen in broncode blijven exact gelijk, terwijl een samenvattend model dergelijke details gemakkelijk kan afronden of verkeerd overnemen.

Compressie in autonome workflows en agentic loops

Bij autonome AI-systemen die meerdere stappen achter elkaar uitvoeren, is contextgroei een van de voornaamste faalredenen. Wie dieper in de werking van deze systemen wil duiken, kan het overzichtsartikel over AI-agents en autonome assistenten raadplegen om te zien hoe geheugen en taakuitvoering op elkaar ingrijpen.

Tijdens een uitvoering verzamelt een agent voortdurend observaties, ruwe tool-outputs, stack traces en tussenconclusies in zijn scratchpad. Na zes of zeven iteraties bevat de context tienduizenden tokens aan verouderde JSON-antwoorden. Wanneer deze context niet actief wordt opgeschoond, ontstaat contextvervuiling waardoor de agent vastloopt in redundante acties. Voor ontwikkelaars die tegen vastlopende systemen aanlopen, biedt de handleiding over het debuggen van agentic loops concrete diagnostische strategieën om geheugenlekken en cirkelredeneringen op te sporen.

Vergelijking: samenvatten, snoeien en RAG-extractie

Om te bepalen welke methode het beste past bij een specifieke architectuur, moeten we de eigenschappen van semantisch samenvatten, syntactisch snoeien en dynamische RAG-filtering tegen elkaar afwegen. De onderstaande tabel vat de belangrijkste operationele verschillen samen.

Praktische implementatie van een hybride compressie-pipeline

In productietoepassingen levert een hybride benadering het meest stabiele resultaat op. Hierbij worden deterministische filters aan de voorkant gecombineerd met een sliding window en een periodieke samenvattingsbuffer. Het onderstaande Python-patroon illustreert hoe een dergelijke pipeline kan worden opgezet zonder externe bibliotheken.

import re

class ContextCompressor:
  def __init__(self, max_tokens=2000, system_prompt=""):
    self.max_tokens = max_tokens
    self.system_prompt = system_prompt
    self.summary_buffer = ""
    self.recent_turns = []

  def _prune_text(self, text: str) -> str:
    # Verwijder meervoudige witruimtes en lege regels
    text = re.sub(r'\n\s*\n', '\n\n', text)
    text = re.sub(r'[ \t]+', ' ', text)
    # Verwijder standaard HTML- en markdown-ruis
    text = re.sub(r'<!--.*?-->', '', text, flags=re.DOTALL)
    return text.strip()

  def _estimate_tokens(self, text: str) -> int:
    # Snelle benadering: 1 token ~= 4 karakters
    return len(text) // 4

  def add_turn(self, role: str, content: str):
    clean_content = self._prune_text(content)
    self.recent_turns.append({"role": role, "content": clean_content})
    self._rebalance()

  def _rebalance(self):
    total = self._estimate_tokens(self.system_prompt) + \
            self._estimate_tokens(self.summary_buffer)
    
    # Bereken tokens in recente beurten
    for turn in self.recent_turns:
      total += self._estimate_tokens(turn["content"])

    # Als limiet wordt overschreden, verplaats oudste beurt naar samenvatting
    while total > self.max_tokens and len(self.recent_turns) > 2:
      oldest = self.recent_turns.pop(0)
      # In productie: vervang onderstaande append door een compacte LLM-samenvatting
      self.summary_buffer += f"\n[{oldest['role']}: {oldest['content'][:120]}...]"
      total = self._estimate_tokens(self.system_prompt) + \
              self._estimate_tokens(self.summary_buffer) + \
              sum(self._estimate_tokens(t["content"]) for t in self.recent_turns)

  def build_prompt(self) -> str:
    prompt_parts = [f"SYSTEM: {self.system_prompt}"]
    if self.summary_buffer:
      prompt_parts.append(f"HISTORIE SAMENVATTING: {self.summary_buffer}")
    for turn in self.recent_turns:
      prompt_parts.append(f"{turn['role'].upper()}: {turn['content']}")
    return "\n\n".join(prompt_parts)

Deze architectuur zorgt ervoor dat de actieve interactie altijd scherp en ongewijzigd blijft voor de meest recente dialoogwisselingen, terwijl oudere interacties trapsgewijs condenseren naar een compact historisch overzicht.

Informatieverlies kwantificeren en evalueren

Elke compressiestap brengt het risico met zich mee dat essentiële details verdwijnen. Om te voorkomen dat optimalisaties leiden tot kwaliteitsverlies in de uiteindelijke antwoorden, is een gestructureerde evaluatiemethode noodzakelijk. Vertrouw nooit op subjectieve steekproeven, maar meet de prestaties systematisch.

De meest betrouwbare meetmethoden omvatten:

• Needle In A Haystack (NIAH) testen: Verberg een specifiek feit (zoals een unieke toegangscode of datum) diep in de context en controleer of het model na compressie nog steeds het juiste antwoord kan reproduceren.
• Entity F1-Score: Vergelijk de set entiteiten (namen, getallen, identifiers) in de ongecomprimeerde bron met de output na compressie om te controleren of er geen kritische variabelen zijn weggevallen.
• Taakgebonden A/B-testen: Evalueer parallelle prompts met een vast testframework. Wie een betrouwbare testopstelling wil inrichten, kan de methode voor A/B-testen van prompts hanteren om systematisch statistische kwaliteitsverschillen vast te leggen.

Meet bij elke evaluatie altijd drie variabelen tegelijk: de tokenreductie (in procenten), de TTFT-latentie (in milliseconden) en de accuracy op je validatieset. Alleen wanneer de nauwkeurigheid binnen aanvaardbare marges blijft, is een compressiemethode productierijp.

Context-caching en prefix-stabiliteit: de verborgen valkuil

Een veelvoorkomende fout bij het implementeren van dynamische samenvattingsbuffers is het verstoren van de prefix cache. Veel moderne LLM-aanbieders bieden prompt-caching aan: statische tekst aan het begin van een prompt wordt op de server gecachet, waardoor herhaalde invoertokens tot 75% goedkoper en aanzienlijk sneller worden verwerkt.

Wanneer een rolling summary direct achter de systeemprompt wordt geplaatst en bij elke beurt verandert, breekt de cache voor de gehele prompt af. De kostenbesparing van enkele honderden gecomprimeerde tokens weegt dan vaak niet op tegen het verlies van de cachingkorting over tienduizenden statische tokens. Voor meer achtergrond over de exacte tariefstructuren en cachemechanismen biedt het artikel over wat een prompt kost qua tokens en caching praktische berekeningen.

Wie direct toepasbare praktijktips zoekt om het tokenverbruik zonder prestatieverlies terug te dringen, vindt in het overzicht over bewezen token-besparingstrucs aanvullende richtlijnen voor slimme cache-alignering.

De oplossing voor dit dilemma is het positioneren van statische blokken vóór dynamische elementen. Houd de vaste systeemprompt en de ongewijzigde documentatie exact gelijk aan het begin van de payload, en plaats samenvattingsbuffers en wisselende gespreksgeschiedenissen uitsluitend aan het staartstuk van de prompt.

Beslisboom: welke methode kies je wanneer?

De keuze tussen samenvatten, snoeien of hybridiseren hangt primair af van twee factoren: de vereiste verwerkingssnelheid en de mate waarin de taak afhankelijk is van exacte getallen en identifiers.

• Kies voor syntactisch snoeien wanneer de interactie realtime moet plaatsvinden (< 1 seconde latentie), de tekst veel ruwe data zoals logs of JSON bevat, of wanneer exacte numerieke waarden absoluut behouden moeten blijven.
• Kies voor semantisch samenvatten bij lange narratieve gesprekken, helpdeskinteracties of vergadertranscripties waarbij de rode draad en intenties belangrijker zijn dan letterlijke datums of losse veldcodes.
• Kies voor een hybride pipeline bij autonome agent-architecturen en complexe applicaties: snoei alle binnenkomende tool-data deterministisch op bronniveau en vat uitsluitend afgeronde taakstappen periodiek samen.

Door context niet te behandelen als een bodemloze put maar als een schaarse werkgeheugenruimte, blijven applicaties snel, betaalbaar en betrouwbaar, ongeacht de schaalgrootte van de onderliggende modellen.