Kontextutveckling: hantera fönster med 1 miljon token utan kontextförfall

År 2026 finns kontextfönster med 1 miljon token. Gemini, GPT-5 och Claude med utökat tänkande stöder dem alla. Demonstrationer visar modeller som läser hela böcker i ett enda svep. Drömmen har äntligen blivit verklighet: lägg bara allt i kontexten och låt modellen reda ut det.

Verkligheten är som vanligt mer nyanserad. 1 miljon token är en teknisk kapacitet, inte en prestandagaranti. Verkliga modeller fungerar bäst med 5 000–50 000 token kontext. Vid över 100 000 uppstår subtila kvalitetsproblem. Vid över 500 000 missas viktig information i praktiken systematiskt. Vid 1 miljon blir modellen överbelastad.

Fenomenet ”kontextförfall” är verkligt, väldokumenterat och synligt i utvärderingar. Konsekvensen är att du inte bara kan hälla in allt i kontexten och betrakta arbetet som klart. Du behöver kontextutveckling: medvetna beslut om vad som ska tas med, vad som ska sammanfattas, vad som ska hämtas dynamiskt och hur den resulterande kontexten ska struktureras.

Den här artikeln behandlar mönstren och disciplinen för effektiv kontextutveckling i seriösa produktionssystem.

Vad kontextförfall är

”Kontextförfall” är den empiriska observationen att LLM-modellers prestanda försämras när kontexten växer, även inom den tekniska gränsen.

Specifika fellägen:

Borttappat i mitten (Liu et al., 2023). Modeller uppmärksammar innehåll i början och slutet av kontexten mer. Information i mitten används mindre tillförlitligt. Ett faktum på position 50 000 av 100 000 missas oftare än samma faktum på position 1 000 eller 99 000.

Aktualitetsbias. Modeller övervärderar nyligt innehåll. I en samtalshistorik blir äldre kontext i praktiken osynlig.

Känslighet för distraktioner. Irrelevant innehåll i kontexten försämrar prestandan även för uppgifter som inte behöver innehållet. Modellen måste filtrera, och en del av filtreringssignalen läcker igenom.

Resonemangskvaliteten sjunker. Resonemang i flera steg blir mindre tillförlitligt när kontexten växer. Modellen måste hålla reda på mer och gör det sämre.

Kostnad och latens. Oberoende av kvalitet är stora kontexter dyra på grund av prissättning per token och långsamma eftersom tiden för många modeller ökar linjärt med antalet token.

Detta är inga teoretiska farhågor. Produktionsdriftsättningar med naivt stora kontexter presterar konsekvent sämre än driftsättningar med kurerade kontexter.

Principen: mindre är mer

Kärninsikten är att kontext är en dyrbar resurs som försämras. Använd den strategiskt.

En kontext på 30 000 token med noggrant utvalt innehåll presterar vanligtvis bättre än en kontext på 300 000 token där allt har lagts in. Kvalitet, kostnad och latens talar alla för den mindre kontexten.

Detta förskjuter utvecklingsarbetet. I stället för ”hitta ett sätt att få in mer i kontexten” blir frågan ”avgör vad som verkligen behöver finnas i kontexten och placera det där på ett bra sätt”.

Kontextbudgeten

Se kontexten som en budget du fördelar.

En typisk fördelning för en kundtjänstagent:

Total kontextbudget: 30K token

- Systemprompt: 1500 token (5 %)
- Verktygsbeskrivningar: 1000 token (3 %)
- Användarprofil/kontext: 500 token (2 %)
- Sammanfattning av samtalshistoriken: 1000 token (3 %)
- Senaste samtalsturerna (fullständiga): 4000 token (13 %)
- Hämtad relevant kunskap: 12000 token (40 %)
- Användarens aktuella meddelande: 500 token (2 %)
- Tokenbudget för utdata (svar): 10K token (33 %)

Varje komponent konkurrerar om utrymmet. När kontexten växer måste du göra avvägningar.

Disciplinen består i att göra fördelningen explicit. Låt ingen komponent växa utan gräns.

Mönster 1: Nivåindelat samtalsminne

För samtal med flera turer växer den fullständiga historiken utan gräns. De flesta produktionssystem använder ett nivåindelat minne:

Nivå 1: De senaste turerna i sin helhet. De senaste 5–10 utbytena, ordagrant.

Nivå 2: Sammanfattade äldre turer. Tidigare delar av samtalet komprimeras till en kort sammanfattning.

Nivå 3: Extraherade fakta. Viktig information från samtalet, exempelvis användarens namn, preferenser och fattade beslut, lagras som strukturerade fakta.

Implementering:

Vid varje tur:
1. Hämta samtalshistoriken.
2. Behåll de senaste 10 turerna ordagrant.
3. Sammanfatta tur 11–30 med 200 ord (”Tidigare diskuterade användaren X och vi enades om Y”).
4. Reducera tur 31 och framåt till extraherade fakta (”Användaren föredrar Python. Användaren har abonnemangsnivån enterprise.”).
5. Totalt minne: cirka 2 000 token oavsett samtalets längd.

Detta mönster är grundläggande för alla långvariga samtal. Utan det försämras samtalen när de växer.

En nyans är att sammanfattningen måste bevara information som agenten kommer att behöva. Om användaren nämnde ett kontonummer i tur 5 och agenten inte flyttar det till långtidsminnet är kontonumret förlorat vid tur 50.

Kör sammanfattningen med uttryckliga instruktioner om vad som ska bevaras:

Sammanfatta samtalet hittills. Bevara:
- Alla fakta om användaren (namn, roll, preferenser och kontoinformation).
- Alla fattade beslut.
- Alla öppna åtaganden eller uppföljningar.
- Samtalets aktuella mål.

Utelämna:
- Artighetsfraser.
- Upprepad information.
- Detaljerade resonemang som redan har avslutats.

Mönster 2: Hämtning vid behov

Hämta det relevanta när det blir relevant i stället för att läsa in kontexten i förväg.

Ett antimönster är att stoppa in alla användarens dokument i kontexten ”ifall modellen behöver dem”. De flesta frågor behöver en mycket liten del. Kontexten slösas bort och prestandan försämras.

Bättre är att hämta dokument utifrån den aktuella frågan. Olika frågor får olika dokument. Den totala kontexten per anrop förblir liten och relevansen hög.

Detta är helt enkelt RAG tillämpat med disciplin. Nyckeln är att inte frestas att ”bara ta med allt eftersom vi kan”. Den frestelsen påverkar även erfarna team när modeller med långa kontextfönster finns tillgängliga.

Mönster 3: Komprimerade representationer

Använd komprimerade representationer för information som behöver finnas kvar i kontexten.

Original (utförligt):

Användaren har arbetat med programvaruutveckling i 8 år. Personen började på det lilla uppstartsbolaget Acme Corp och arbetade där med backend-system. Efter 3 år gick personen vidare till det större företaget Beta Inc och arbetade med frontend. Nu arbetar personen med maskininlärningssystem på Gamma LLC.

Komprimerat:

Användare: programvaruutvecklare, 8 år, arbetar nu med ML på Gamma LLC. Tidigare: backend på Acme (3 år), frontend på Beta.

Den komprimerade versionen bevarar relevanta fakta med färre token. För de flesta ändamål kan modellen använda båda lika bra.

Tillämpa metoden på:

• Användarprofiler.
• Dokumentsammanfattningar.
• Tidigare samtalskontext.
• Poster i kunskapsbasen när det fullständiga innehållet inte behövs.

Avvägningen är att komprimering förlorar nyanser. Använd fullständig text när nyanserna spelar roll och en komprimerad version när de inte gör det.

Mönster 4: Hierarkisk hämtning

Hämta hierarkiskt från mycket stora kunskapsbaser.

Steg 1: Hämta breda kategorier eller dokumentsammanfattningar utifrån frågan.

Steg 2: Hämta specifika segment inom de mest relevanta kategorierna.

Steg 3: Ta bara med segmenten från steg 2 i den slutliga kontexten.

Detta undviker tankesättet ”jag har 10 000 dokument, låt mig bädda in dem alla i kontexten”. Tratten håller i stället kontexten snäv.

En variant är att låta ett litet LLM-anrop välja vilka segment som är mest relevanta innan de inkluderas i huvudanropet. Det tillför en liten kostnad men minskar kontextöverflödet avsevärt.

Mönster 5: Reflektion över kontexten

Låt agenter i långvariga uppgifter regelbundet reflektera över vad som finns och bör finnas i kontexten.

Efter vart tionde steg gör agenten följande:

1. Granskar sin aktuella kontext.
2. Identifierar vad som är relevant för det pågående arbetet.
3. Sammanfattar eller tar bort sådant som inte längre behövs.
4. Noterar vilken ytterligare kontext som kan vara till hjälp.
5. Ersätter den gamla kontexten med den kurerade versionen.

Detta är kontextens ”skräpinsamling”. Utan den samlar agenter på sig inaktuell information som tränger undan ny, relevant information.

Implementeringen kräver anpassad orkestrering, eftersom de flesta ramverk inte hanterar detta direkt. Mönstret är att agenten mellan stegen har en fas för ”minneskonsolidering” som justerar vad som finns i kontexten.

Mönster 6: Dynamiska kontextfönster

Olika delar av en agentkörning kan ha olika optimala kontextstorlekar.

• Beslutssteg: liten kontext med fokus på det omedelbara beslutet.
• Syntessteg: större kontext som innehåller många källor.
• Genereringssteg: medelstor kontext med referenser för stil och format.

Ett mönster är att varje steg i agentens arbetsflöde använder en egen kontextform. Orkestreringen hanterar vilket innehåll som går till vilket steg.

Det kräver att agentens arbete delas upp i uttryckliga steg i stället för en stor loop. Valet av ramverk spelar roll här: LangGraph hanterar detta naturligt, medan direkt-API kräver manuellt arbete.

Mönster 7: Positionsmedveten placering

Eftersom modeller uppmärksammar början och slutet av kontexten mer bör viktigt innehåll placeras där.

Mindre effektivt: en kritisk instruktion begravd mitt i en lång systemprompt.

Mer effektivt: den kritiska instruktionen längst fram OCH upprepad nära slutet.

För RAG med flera hämtade dokument: placera det mest relevanta dokumentet först, det näst mest relevanta sist och mindre relevanta dokument i mitten.

Detta är en taktisk optimering, men den har mätbar effekt på resultatet.

Mönster 8: Selektiv sammanfattning

Alla sammanfattningar är inte likvärdiga. Anpassa sammanfattningen efter vad efterföljande uppgifter behöver.

Dåligt: en allmän sammanfattning som tappar användarens preferenser.

Bättre: en sammanfattning som uttryckligen bevarar användarpreferenser som är relevanta för den efterföljande uppgiften.

Sammanfatta dokumentet med fokus på:
- Fattade tekniska beslut.
- Omnämnda intressenter.
- Öppna frågor eller risker.

Utelämna:
- Allmän kontext som teamet redan känner till.
- Upprepade punkter.

Sammanfattningsprompten utformas för den efterföljande användningen.

Mönster 9: Strukturerad kontext

Oformaterad text är ett alternativ. Strukturerad kontext i JSON, XML eller särskild märkning kan vara betydligt kompaktare.

Utförlig prosa:

Kunden heter John Smith och har varit kund sedan mars 2023. Hans nuvarande abonnemang är Pro och faktureras månadsvis med $29. Han har 3 aktiva integrationer: Slack, Notion och Linear. Under de senaste 30 dagarna har användningen varit måttlig – 1 250 API-anrop.

Strukturerat:

{
  "customer": {
    "name": "John Smith",
    "since": "2023-03",
    "plan": "Pro",
    "billing": "$29 per månad",
    "integrations": ["Slack", "Notion", "Linear"],
    "usage_30d": {"api_calls": 1250, "tier": "moderate"}
  }
}

Den strukturerade versionen är kortare och ofta lättare för modellen att använda. Modellen kan snabbt hitta specifika fakta.

Ett förbehåll är att alla modeller inte är lika bra på strukturerade indata. Testa båda formaten för ditt användningsfall.

Mönster 10: Kontextlager

Skikta kontexten efter prioritet. Hög prioritet inkluderas alltid, medelhög när det är relevant och låg prioritet hämtas på begäran.

Alltid:

• Systemprompt med identitet och beteende.
• Aktuell användarkontext med centrala fakta.
• Det senaste samtalet.

När det är relevant:

• Hämtade dokument som matchar frågan.
• Verktygsresultat från de senaste stegen.

På begäran:

• Specifika data som agenten begär genom verktygsanrop.
• Historisk kontext utanför det senaste fönstret.

Mönstret ”på begäran” är avgörande för skalning: agenten hämtar vad den behöver när den behöver det i stället för att läsa in allt i förväg.

Mönster 11: Strategier för utkastning

Vad kastas ut när kontexten närmar sig gränsen?

• Efter aktualitet: äldst innehåll kastas ut först.
• Efter relevans: innehåll med minst koppling till den aktuella uppgiften kastas ut först.
• Efter betydelse: innehåll märkt med låg betydelse kastas ut först.

Ett praktiskt mönster är att märka kontextobjekt med prioritetsnivåer. När något måste kastas ut görs det i prioritetsordning.

context_items = [
    {"content": "...", "priority": "critical"},   # Kasta aldrig ut
    {"content": "...", "priority": "high"},        # Kasta ut sist
    {"content": "...", "priority": "medium"},     # Kasta ut vid behov
    {"content": "...", "priority": "low"},         # Kasta ut först
]

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))  # Ta bort lägsta prioritet
    return items

Mönster 12: Cachelagring av upprepad kontext

Många anrop återanvänder samma kontext: samma systemprompt, verktygsbeskrivningar och användarprofil.

De flesta leverantörer stöder nu promptcache:

• Anthropic: uttryckliga cache_control-markörer i meddelanden.
• OpenAI: automatiskt för anrop med matchande prefix.
• Google: explicit cachelagrat innehåll via API.

När samma prefix återanvänds blir den cachelagrade versionen snabbare och billigare, ofta 90 % billigare.

Se till att statiska delar som systemprompt, verktyg och användarkontext går att cachelagra för agenter som gör många anrop under en session. Placera dynamiskt innehåll, som aktuellt steg och nya resultat, efter det cachelagringsbara prefixet.

Detta är en av optimeringarna med högst avkastning. Ett statiskt prefix på 10 000 token som används i 50 anrop under en session kostar fullt pris första gången och 90 % mindre efterföljande gånger. Det ger betydande besparingar.

Mönster 13: Kontextmedvetna prompter

Prompter kan uppmuntra modellen att använda kontexten väl:

Använd dokumenten nedan för att besvara användarens fråga. Hänvisa alltid till det specifika dokumentet och citera relevanta avsnitt.

Om du inte hittar svaret i de tillhandahållna dokumenten ska du uttryckligen säga det. Hitta inte på information.

När information från flera dokument är relevant ska du sammanställa den och uppmärksamma eventuella motstridigheter.

Den sortens promptning minskar hallucinationer i kontextgrundade uppgifter och förbättrar citeringskvaliteten.

När längre kontext bör användas

Trots kontextförfall är längre kontext faktiskt bättre för vissa uppgifter:

Analys av ett enskilt dokument. Om uppgiften är ”analysera det här avtalet” är det ofta bättre att få plats med hela avtalet i kontexten än att använda segmenterad hämtning.

Jämförelse av många objekt. Att jämföra 10 avtal sida vid sida gynnas av att alla 10 finns i kontexten.

Kodredigering i kontext. Att ändra en funktion i en fil med 5 000 kodrader är lättare med filen i kontexten än med hämtade kodavsnitt.

Sammanfattning av hela samtal. En sammanfattning av ett långt samtal blir bättre med fullständig kontext, upp till en viss gräns.

Mönstret är att längre kontext hjälper när uppgiften i grunden kräver förståelse av relationer mellan innehåll. När uppgiften kan lösas med en liten del är mindre kontext bättre.

En praktisk tumregel är att kontexter upp till 50 000 token normalt fungerar bra. 50 000–200 000 fungerar, men kvaliteten sjunker. Över 200 000 presterar ofta sämre än kortare kontexter. Testa empiriskt.

Utvärderingsdisciplin

Hur vet du att kontextutvecklingen fungerar? Genom utvärdering.

Specifika utvärderingar:

Återkallningstest. Lägg in centrala fakta på olika positioner i långa kontexter. Testa om modellen använder dem. Mät återkallning mot position.

Distraktionstest. Jämför prestanda för samma fråga med och utan irrelevant kontext. Mät försämringen.

Jämförelse mellan lång kontext och RAG. Besvara samma frågor med fullständig kontext respektive hämtade segment. Jämför kvaliteten.

Tokeneffektivitet. Kvalitet per euro. Du betalar mer när kontexten växer – ökar kvaliteten i motsvarande grad?

Dessa utvärderingar visar om kontextvalen faktiskt hjälper. Utan dem gissar du.

Ett genomarbetat exempel: forskningsassistent

Ett verkligt exempel är en AI-forskningsassistent för ett litet team.

Uppgift: besvara frågor om ett material på 200 dokument, bestående av forskningsartiklar, interna dokument och mötesanteckningar.

Naiv metod: bädda in alla dokument i kontexten, totalt 300 000 token. Kvaliteten är acceptabel, kostnaden hög och latensen dålig.

Utvecklad metod:

Kontextbudget: 25K token

- Systemprompt: 1500 token (cachelagrad)
- Verktygsbeskrivningar (search, fetch_doc med flera): 800 token (cachelagrade)
- Samtalsminne: 1500 token (de senaste 10 turerna)
- Hämtade segment för den aktuella frågan: 18000 token (de 12 främsta segmenten via RAG)
- Användarens aktuella fråga: 200 token
- Utdatabudget: cirka 3000 token

Agenten hämtar dynamiskt segment utifrån frågan. Samtalsminnet bevarar den senaste kontexten. Statiska delar cachelagras.

Resultat:

• Latens: 2–3 sekunder, jämfört med 10–15 med 300 000 token kontext.
• Kostnad: cirka 0,01 euro per fråga, jämfört med cirka 0,10 euro.
• Kvalitet: bättre, uppmätt med utvärderingsuppsättningen, eftersom relevant innehåll uppmärksammas ordentligt.

Så ser disciplinerad kontextutveckling ut. Det är inte ett engångsbeslut, utan fortlöpande trimning.

Vanliga misstag

Några mönster:

Misstag 1: ”Mer kontext är bättre.” Längre kontext används som lösning på kvalitetsproblem. Ofta gäller motsatsen.

Misstag 2: Ingen kontextbudget. Komponenter växer utan gräns. Användarprofilen blir 5 000 token och de hämtade segmenten 50 000. Disciplin saknas.

Misstag 3: Positioner ignoreras. Kritiska instruktioner begravs i mitten i hopp om att modellen hittar dem. Ibland gör den det, ofta inte.

Misstag 4: Utförlig prosa för fakta. Långa meningar där strukturerade data hade räckt. Token slösas.

Misstag 5: Ingen samtalssammanfattning. Samtal växer tills de överskrider gränserna. Därefter tappar de antingen tråden eller går sönder.

Misstag 6: Ingen cachelagring. Fullt pris betalas vid varje anrop för upprepade statiska prefix. En enkel besparing lämnas outnyttjad.

Misstag 7: Kontextvalen utvärderas inte. Teamet litar på att ”bättre kontextutveckling” fungerar. Ibland gör den inte det.

Misstag 8: Generisk sammanfattning. Innehållet sammanfattas utan hänsyn till vad efterföljande uppgifter behöver. Viktig information går förlorad.

Slutsatsen

Långa kontextfönster finns, men de ger inte tillåtelse att strunta i kontextutveckling. Kvaliteten försämras långt före de tekniska gränserna. Kostnaden och latensen är verkliga.

Disciplinen kontextutveckling innebär att:

• Behandla kontexten som en budget.
• Nivåindela minnet: senaste innehållet ordagrant, äldre innehåll sammanfattat och det äldsta som fakta.
• Hämta vid behov, inte i förväg.
• Komprimera där informationen bevaras.
• Placera kritiskt innehåll på positioner som får stor uppmärksamhet.
• Skikta kontexten efter prioritet.
• Cachelagra statiska prefix.
• Utvärdera kontinuerligt.

Dessa mönster skapar system som fungerar bättre, snabbare och billigare än naiva metoder där allt läggs i kontexten.

För mogna produktionssystem är kontextutveckling ett av områdena med störst hävstång. De tekniska byggstenarna är enkla. Disciplinen att tillämpa dem rigoröst är det som skiljer ”demonstrationen fungerar” från ”produktionen är tillförlitlig”.

Investera i mönstren. Bygg disciplinen. Resultatet är AI-system som skalar väl när de möter mer data, fler samtal och större komplexitet.