I 2026, i modsætning til tidligere, har du kontekstvinduer på 1M tokens. Gemini, GPT-5, og Claude (med udvidet tænkning) understøtter dem alle. Demoer viser modeller, der læser hele bøger i én gennemgang. Drømmen er endelig blevet virkelig: Læg blot alt i konteksten, og lad modellen finde ud af det.
Virkeligheden er som altid mere nuanceret. 1M tokens er en teknisk kapacitet, ikke en garanti for ydelse. Reelle modeller fungerer bedst med en kontekst på 5 50K tokens. Ved 100K opstår subtile kvalitetsproblemer. Ved 500K overser modellerne jævnligt vigtige oplysninger. Ved 1M er modellen overbelastet.
Fænomenet — »kontekstforringelse« — er reelt, veldokumenteret og synligt i evalueringer. Konsekvensen er, at du ikke blot kan lægge alt i konteksten og betragte arbejdet som færdigt. Du har brug for kontekstengineering: bevidste beslutninger om, hvad der skal medtages, hvad der skal sammenfattes, hvad der skal hentes dynamisk, og hvordan den resulterende kontekst skal struktureres.
Denne artikel gennemgår mønstrene og disciplinen bag effektiv kontekstengineering til seriøse produktionssystemer.
Hvad kontekstforringelse er
»Kontekstforringelse« er den empiriske observation, at en LLM’s ydelse falder, når konteksten vokser, selv inden for den tekniske grænse.
Specifikke fejltilfælde:
Tabt i midten (Liu et al., 2023). Modeller fokuserer mere på indholdet i begyndelsen og slutningen af konteksten. Oplysninger i midten bruges mindre pålideligt. Et faktum placeret ved position 50K ud af 100K bliver oftere overset end det samme faktum ved position 1K eller 99K
Nylighedsbias. Modeller vægter nyere indhold for højt. I samtalehistorik, med mange trin, bliver ældre kontekst reelt usynlig.
Følsomhed over for distraktion. Irrelevant indhold i konteksten forringer ydelsen selv på opgaver, der ikke kræver det. Modellen skal filtrere, og filtreringen lykkes ikke altid.
Ræsonnementskvaliteten falder. Ræsonnement i flere trin bliver mindre pålideligt, når konteksten vokser. Modellen skal holde styr på mere, og kvaliteten lider.
Omkostninger og latenstid. Uanset kvaliteten er store kontekster dyre (pris pr. token) og langsommere (for mange modeller lineært med antallet af tokens).
Det er ikke teoretiske bekymringer. Produktionssystemer med ukritisk store kontekster klarer sig konsekvent dårligere end produktionssystemer med kuraterede kontekster.
Princip: mindre er mere
Den centrale indsigt er, at kontekst er en dyr ressource med aftagende kvalitet. Brug den strategisk.
En kontekst på 30K tokens med nøje udvalgt indhold klarer sig typisk bedre end en kontekst på 300K tokens, hvor alt er lagt ind. Kvalitet, omkostninger og latenstid taler alle for den mindre kontekst.
Det ændrer udviklerens opgave. I stedet for »find en måde at få mere ind i konteksten« bliver den: »Beslut, hvad der reelt skal være i konteksten, og placér det hensigtsmæssigt.«
Kontekstbudgettet
Tænk på kontekst som et budget, du fordeler.
En typisk allokering for en kundeserviceagent:
Total context budget: 30K tokens
- System prompt: 1500 tokens (5%)
- Tool descriptions: 1000 tokens (3%)
- User profile / context: 500 tokens (2%)
- Conversation history summary: 1000 tokens (3%)
- Recent conversation turns (full): 4000 tokens (13%)
- Retrieved relevant knowledge: 12000 tokens (40%)
- User's current message: 500 tokens (2%)
- Output token budget (response): 10K tokens (33%)
Hver komponent konkurrerer om plads. Når konteksten vokser, gør du kompromiser.
Disciplinen: vær eksplicit om allokeringen. Lad ikke nogen komponent vokse ubegrænset.
Mønster 1: Lagdelt samtalehukommelse
I samtaler med mange trin vokser den fulde historik uden grænse. De fleste produktionssystemer bruger lagdelt hukommelse:
Lag 1: De seneste samtaletrin i fuld længde. De sidste 5-10 udvekslinger, ordret.
Lag 2: Sammenfattede ældre samtaletrin. Tidligere dele af samtalen komprimeret til en kort sammenfatning.
Lag 3: Udtrukne fakta. Vigtige oplysninger fra samtalen (brugerens navn, præferencer og trufne beslutninger) gemt som strukturerede fakta.
Implementering:
On each turn:
1. Take the conversation history.
2. The last 10 turns are kept verbatim.
3. Turns 11-30 are summarized into 200 words ("Earlier, the user discussed X and we agreed Y").
4. Turns 31+ are reduced to extracted facts ("User prefers Python. User is on enterprise tier.").
5. Total memory: ~2K tokens regardless of conversation length.
Dette mønster er grundlæggende for enhver langvarig samtale. Uden det forringes samtalerne, efterhånden som de vokser.
En vigtig nuance er, at sammenfatningen skal bevare de oplysninger, agenten har brug for. Hvis brugeren nævnte et kontonummer ved trin 5 og agenten ikke gemmer det i langtidshukommelsen, er kontonummeret tabt ved trin 50
Lav sammenfatningen med eksplicitte instruktioner om, hvad der skal bevares:
Summarize the conversation so far. Preserve:
- All facts about the user (name, role, preferences, account info).
- All decisions made.
- All open commitments or follow-ups.
- The current goal of the conversation.
Discard:
- Pleasantries.
- Repeated information.
- Detailed reasoning that's been resolved.
Mønster 2: Just-in-time-hentning
I stedet for at indlæse kontekst på forhånd hentes det relevante indhold, når der er brug for det.
Et antimønster er at lægge alle brugerens dokumenter i konteksten, »hvis nu modellen får brug for dem«. De fleste spørgsmål kræver kun en lille del. Kontekstplads spildes, og ydelsen lider.
Bedre: Hent dokumenter ud fra det aktuelle spørgsmål. Forskellige spørgsmål får forskellige dokumenter. Den samlede kontekst pr. kald forbliver lille, og relevansen forbliver høj.
Det er blot RAG anvendt disciplineret. Nøglen er at modstå fristelsen til at »medtage alt, fordi vi kan«. Selv erfarne teams falder for den, når modeller med lang kontekst bliver tilgængelige.
Mønster 3: Komprimerede repræsentationer
Brug komprimerede repræsentationer til oplysninger, der skal bevares i konteksten.
Original (omfattende):
The user has been working in software engineering for 8 years. They started at a small startup called Acme Corp where they worked on backend systems. After 3 years they moved to a larger company called Beta Inc where they did frontend work. They're currently at Gamma LLC working on machine learning systems.
Komprimeret:
User: SWE, 8 years, currently ML at Gamma LLC. Prior: backend@Acme (3yr), frontend@Beta.
Den komprimerede version bevarer de relevante fakta med færre tokens. Til de fleste formål kan modellen bruge begge versioner lige godt.
Anvend denne teknik på:
- Brugerprofiler.
- Dokumentsammenfatninger.
- Tidligere samtalekontekst.
- Videnbaseindgange (når fuld tekst ikke er nødvendig).
Afvejningen er, at komprimering mister nuancer. Brug fuld tekst, når nuancer betyder noget, og den komprimerede form, når de ikke gør.
Mønster 4: Hierarkisk hentning
Hent hierarkisk fra meget store vidensbaser.
Trin 1: Hent brede kategorier eller dokumentsammenfatninger ud fra spørgsmålet.
Trin 2: Inden for de mest relevante kategorier, hent specifikke dele.
Trin 3: Inkluder kun dele valgt i trin 2 i den endelige kontekst.
Det undgår tankegangen: »Jeg har 10K dokumenter; lad mig lægge dem alle i konteksten.« I stedet holder tragten konteksten fokuseret.
En variant er, at et lille LLM-kald vælger de mest relevante dele, før de medtages i hovedkaldet. Det tilføjer en beskeden omkostning, men reducerer kontekstoverbelastningen betydeligt.
Mønster 5: Refleksion over kontekst
Ved lange agentopgaver bør du regelmæssigt vurdere, hvad der er i konteksten, og hvad der bør være der.
Every 10 steps, the agent does:
1. Reviews its current context.
2. Identifies what's relevant to ongoing work.
3. Summarizes or drops anything no longer needed.
4. Notes what additional context might help.
5. Replaces the old context with the curated version.
Det er »garbage collection« for kontekst. Uden det ophober agenter forældede oplysninger, som fortrænger nye og relevante oplysninger.
Implementeringen kræver specialbygget orkestrering — de fleste frameworks håndterer det ikke naturligt. Mønstret er, at agenten mellem trinene har en fase til hukommelsesstyring, som justerer kontekstens indhold.
Mønster 6: Dynamiske kontekstvinduer
Forskellige dele af en agentkørsel kan have forskellige optimale kontekststørrelser.
- Beslutningstrin: lille kontekst, fokuseret på den øjeblikkelige beslutning.
- Syntesetrin: større kontekst, der omfatter mange kilder.
- Genereringstrin: medium kontekst, med stil og formatreferencer.
Mønstret er, at hvert trin i agentens arbejdsgang bruger en forskellig kontekstform. Orkestreringen bestemmer, hvilket indhold der går til hvilket trin.
Det kræver, at agentens arbejde opdeles i eksplicitte trin frem for én stor løkke. Valget af framework er vigtigt her (LangGraph håndterer det naturligt; direkte API kræver manuelt arbejde).
Mønster 7: Positionsbaseret placering
Da modeller fokuserer mere på kontekstens begyndelse og slutning, bør vigtigt indhold placeres dér.
Mindre effektiv: kritisk instruktion skjult i midten af en lang systemprompt.
Mere effektiv: kritisk instruktion ved starten og gentaget tæt på slutningen.
Ved RAG med flere hentede dokumenter placeres det mest relevante dokument i begyndelsen, det næstmest relevante i slutningen og mindre relevante dokumenter i midten.
Det er en taktisk optimering, men har målbare effekter på outputtet.
Mønster 8: Målrettet sammenfatning
Ikke alle sammenfatninger er ens. Tilpas sammenfatningen til det, efterfølgende opgaver kræver.
Dårligt: En generisk sammenfatning, der fjerner brugerpræferencer.
Bedre: En sammenfatning, der eksplicit bevarer de brugerpræferencer, som er relevante for den efterfølgende opgave.
Summarize this document focusing on:
- Technical decisions made.
- Stakeholders mentioned.
- Open questions or risks.
Drop:
- General context already known to the team.
- Repeated points.
Prompten til sammenfatning er udformet til den efterfølgende anvendelse.
Mønster 9: Struktureret kontekst
Ren tekst er én mulighed. Struktureret kontekst (JSON, XML eller specifik markup) kan være langt mere kompakt.
Omfattende tekst:
The customer's name is John Smith. He's been a customer since March 2023. His current plan is Pro, billed monthly at $29. He has 3 active integrations: Slack, Notion, and Linear. His usage in the last 30 days has been moderate — 1,250 API calls.
Struktureret:
{
"customer": {
"name": "John Smith",
"since": "2023-03",
"plan": "Pro",
"billing": "monthly $29",
"integrations": ["Slack", "Notion", "Linear"],
"usage_30d": {"api_calls": 1250, "tier": "moderate"}
}
}
Den strukturerede version er kortere og ofte lettere for modellen at bruge. Modellen kan hurtigt finde bestemte fakta.
Advarsel: ikke alle modeller behandler struktureret input lige godt. Test begge formater for din anvendelse.
Mønster 10: Lagdeling af kontekst
Opdel konteksten i lag efter prioritet. Høj prioritet medtages altid, mellemprioritet medtages, når det er relevant, og lav prioritet hentes efter behov.
Altid lag:
- Systemprompt (identitet, adfærd).
- Aktuel brugerkontekst (essentielle fakta).
- Nylig samtale.
Når relevant:
- Hentede dokumenter, der matcher spørgsmålet.
- Værktøjets output fra nylige trin.
På anmodning:
- Specifik data, agenten anmoder om via værktøjskald.
- Historisk kontekst ud over det seneste vindue.
Mønstret »efter behov« er afgørende for skalerbarhed: Agenten henter det, den har brug for, når den har brug for det, frem for at indlæse alt på forhånd.
Mønster 11: Strategier for fjernelse
Hvad fjernes, når konteksten nærmer sig grænsen?
- Nylighedsbaseret: Det ældste indhold fjernes først.
- Relevansbaseret: Indhold, der er mindst relevant for den aktuelle opgave, fjernes først.
- Vigtighedsbaseret: Indhold markeret med lav prioritet fjernes først.
Et praktisk mønster er at mærke kontekstelementer med prioritetsniveauer. Når noget skal fjernes, sker det i prioriteret rækkefølge.
context_items = [
{"content": "...", "priority": "critical"}, # Never evict
{"content": "...", "priority": "high"}, # Evict last
{"content": "...", "priority": "medium"}, # Evict if needed
{"content": "...", "priority": "low"}, # Evict first
]
def evict_to_fit(items, budget):
items_by_priority = sorted(items, key=lambda x: priority_value(x.priority))
while total_tokens(items) > budget:
items.remove(items_by_priority.pop(0)) # Remove lowest priority
return items
Mønster 12: Cache for gentagne kontekster
Mange kald genbruger den samme kontekst — samme systemprompt, samme værktøjsbeskrivelser og samme brugerprofil.
De fleste leverandører understøtter nu promptcaching:
- Anthropic: eksplicitte
cache_controlmarkører i beskeder. - OpenAI: automatisk ved forespørgsler med et tilstrækkeligt ens præfiks.
- Google: eksplicit cacheindhold via API.
Når det samme præfiks genbruges, er den cachelagrede version hurtigere og billigere (ofte 90% billigere).
For agenter, der foretager mange kald i en session, skal de statiske dele (systemprompt, værktøjer og brugerkontekst) kunne caches. Placér dynamisk indhold (aktuelt trin og seneste resultater) efter det præfiks, der kan caches.
Det er en af optimeringerne med højest ROI. Et statisk præfiks på 10K tokens brugt over 50 kald i en session: fuld pris for det første kald og 90% rabat derefter. Det giver betydelige besparelser.
Mønster 13: Kontekstbevidste prompts
Prompts kan hjælpe modellen med at bruge konteksten effektivt:
Reference the documents below to answer the user's question. Always cite the specific document and quote relevant passages.
If you cannot find the answer in the provided documents, say so explicitly. Do not invent information.
When information from multiple documents is relevant, synthesize them and note any disagreements.
Denne type prompting reducerer hallucinationer i kontekstbaserede opgaver og forbedrer kvaliteten af kildehenvisninger.
Hvornår længere kontekst bør accepteres
Selvom kontekstforringelse eksisterer, er længere kontekst faktisk bedre for nogle opgaver:
Enkeltdokumentanalyse. Hvis opgaven er “analyser denne kontrakt”, er det ofte bedre at have hele kontrakten i konteksten end chunked hentning.
Sammenligning af mange elementer. Sammenligning af 10 kontrakter side om side bliver bedre, når alle 10 er i konteksten.
Kodebearbejdning i kontekst. At ændre en funktion i en 5K-LOC fil er nemmere med filen i konteksten end med hentede fragmenter.
Sammenfatning af hele samtaler. En sammenfatning af en lang samtale bliver bedre med den fulde kontekst (indtil et vist punkt).
Mønstret: når opgaven fundamentalt kræver forståelse af relationer mellem indhold, hjælper længere kontekst. Når opgaven kan udføres med en lille del, er mindre kontekst bedre.
En praktisk tommelfingerregel: Kontekster op til 50K tokens fungerer generelt fint. 50 200K tokens fungerer, men kvaliteten falder. 200K tokens klarer sig ofte dårligere end kortere kontekster. Test det empirisk.
Evalueringsdisciplin
Hvordan ved du, at din kontekststyring virker? Evaluer.
Specifikke evals:
Hukommelsestest. Indsæt vigtige fakta forskellige steder i lange kontekster. Test, om modellen bruger dem. Mål genkaldelse i forhold til position.
Distraktionstest. Sammenlign ydelsen på det samme spørgsmål med og uden irrelevant kontekst. Mål forringelsen.
Sammenligning af lang kontekst og RAG. Besvar det samme spørgsmål med fuld kontekst og med hentede dele. Sammenlign kvaliteten.
Tokeneffektivitet. Kvalitet pr. krone. Når konteksten vokser, betaler du mere — stiger kvaliteten tilsvarende?
Disse evalueringer viser, om dine kontekstvalg faktisk hjælper. Uden dem gætter du.
Et eksempel: forskningsassistent
Et konkret eksempel er en AI-researchassistent til et lille team.
Opgave: Besvar spørgsmål om et korpus med 200 dokumenter (artikler, interne dokumenter og mødenotater).
Naiv tilgang: Læg alle dokumenter i konteksten (300K tokens). Kvaliteten er acceptabel, omkostningerne er høje, og latenstiden er dårlig.
Ingeniørtilgang:
Context budget: 25K tokens
- System prompt: 1500 tokens (cached)
- Tool descriptions (search, fetch_doc, etc.): 800 tokens (cached)
- Conversation memory: 1500 tokens (last 10 turns)
- Retrieved chunks for current query: 18000 tokens (top 12 chunks via RAG)
- User's current question: 200 tokens
- Output budget: ~3000 tokens
Agenten henter dele dynamisk ud fra spørgsmålet. Samtalehukommelsen bevarer den seneste kontekst. Statiske elementer caches.
Resultat:
- Latenstid: 2-3 sekunder (vs 10-15 med 300K kontekst).
- Omkostning: ~€0.01/spørgsmål (vs ~€0.10).
- Kvalitet: bedre, målt på evalueringssættet, fordi relevant indhold behandles korrekt.
Sådan ser disciplineret kontekstengineering ud. Det er ikke en engangsbeslutning, men løbende tilpasning.
Almindelige fejl
Nogle mønstre:
Fejl 1: “Mere kontekst = bedre.” Gå efter længere kontekst som løsningen på kvalitetsproblemer. Ofte er det modsatte sandt.
Fejl 2: Intet kontekstbudget. Komponenter vokser uden grænse. Brugerprofilen bliver 5K tokens, og sektionen med hentede dele bliver 50K Ingen disciplin.
Fejl 3: Ignorere positioner. Kritiske instruktioner skjult i midten, håber modellen finder dem. Nogle gange gør den det; ofte gør den ikke.
Fejl 4: Omfattende tekst til fakta. Lange sætninger, hvor strukturerede data ville have været tilstrækkelige. Spild af tokens.
Fejl 5: Ingen samtalesammenfatning. Samtaler vokser, indtil de overskrider grænserne. Derefter bliver de enten afkortet eller går i stykker.
Fejl 6: Ingen caching. Gentagne statiske præfikser betales til fuld pris hver gang. En oplagt besparelse går tabt.
Fejl 7: Ingen evaluering af kontekstvalg. Man antager, at »bedre kontekstengineering« virker. Det gør den ikke altid.
Fejl 8: Generisk sammenfatning. Man sammenfatter uden at overveje, hvad efterfølgende opgaver kræver, og mister vigtige oplysninger.
Konklusionen
Lange kontekstvinduer findes, men de er ikke en tilladelse til at se bort fra kontekstengineering. Kvaliteten forringes længe før de tekniske grænser. Omkostninger og latenstid er reelle.
Disciplinen i kontekstengineering:
- Behandle kontekst som et budget.
- Opdel hukommelsen i lag (nyere ordret, ældre sammenfattet, de ældste som fakta).
- Hent just-in-time, ikke forud.
- Komprimér, hvor komprimering bevarer oplysningerne.
- Placer kritisk indhold på højopmærksomhedspositioner.
- Lag kontekst efter prioritet.
- Cache statiske præfikser.
- Evaluer kontinuerligt.
Disse mønstre skaber systemer, der fungerer bedre, hurtigere og billigere end naive tilgange, hvor »alt lægges i konteksten«.
I modne produktionssystemer er kontekstengineering et af de områder, der giver størst effekt. De tekniske primitiver er enkle; disciplinen i at anvende dem konsekvent adskiller »demoen virker« fra »produktionen er pålidelig«.
Investér i mønstrene. Byg disciplinen. Resultatet er AI-systemer, der skalerer elegant, når de møder mere data, flere samtaler og mere kompleksitet.
