Vad är ett kontextfönster? Det här bör alla LLM-användare känna till

Ett kontextfönster är den mängd information som en stor språkmodell (LLM) kan bearbeta i en enda begäran. Det mäts i token och kan omfatta din prompt, konversationshistorik, systeminstruktioner, hämtade dokument, verktygsresultat och modellens genererade svar.

Ett större kontextfönster låter en modell arbeta med mer information i en enda begäran. En kodningsagent som undersöker en bugg kan till exempel arbeta med relevanta källfiler, dokumentation, testresultat och nyliga kodändringar samtidigt, i stället för att analysera varje del separat och förlora användbar kontext mellan begäranden.

Ett större kontextfönster är dock inte samma sak som ett perfekt minne. Längre promptar kräver mer beräkning, förbrukar fler token och kan göra det svårare för en modell att avgöra vilka detaljer som faktiskt är viktiga. Forskning om modeller med lång kontext, inklusive studien Lost in the Middle och NVIDIAs RULER-riktmärket, har upprepade gånger visat att modeller använder mindre av den tillgängliga informationen när kontexten växer, särskilt när relevant information är begravd bland mindre användbart material.

Här går vi igenom hur kontextfönster fungerar, hur de mäts, vad som händer när de fylls och hur utvecklare kan hantera dem effektivt.

Sammanfattning

• Ett kontextfönster är den totala tokenbudget som en LLM använder för en enskild begäran. Det omfattar användarens prompt, konversationshistorik, hämtat innehåll och utdata.
• Större kontextfönster möjliggör längre dokument, kodbaser och konversationer, men garanterar inte att modellen använder alla delar av dem väl.
• Modeller hämtar information minst tillförlitligt från mitten av långa promptar, ett mönster som dokumenterats i studien Lost in the Middle och benchmarken RULER.
• Effektiv kontexthantering (hämtning, sammanfattning, cachning) är vanligtvis bättre än att bara maximera antalet token som skickas.
• Den bästa kontextstrategin är den som passar din faktiska arbetsbelastning, inte den som använder det största marknadsförda kontextfönstret.

Vad är ett kontextfönster i en AI-modell?

Ett kontextfönster är en modells aktiva arbetsyta, där allt som är relevant för den aktuella begäran samlas innan modellen genererar ett svar.

Tänk dig en AI-agent som sammanfattar ett samtal med kundtjänst och rekommenderar en lösning. För att göra det väl måste modellen bearbeta:

• En systemprompt
• Kundens meddelande
• Konversationshistoriken
• Företagets policyer
• Resultat från verktyg och API:er
• Utdata

Allt detta konkurrerar om utrymme i samma kontextfönster, oavsett hur stort fönstret är.

Kontextfönster omfattar inte träningsdata. Träningen bäddar permanent in information i en modells parametrar och formar vad den generellt ”vet”. Ett kontextfönster innehåller däremot bara information som tillhandahålls för den aktuella uppgiften.

Den här skillnaden är viktig i praktiken: Om en applikation behöver att en modell resonerar kring en specifik policy, kundpost eller tekniskt dokument är informationen inte tillgänglig bara för att modellen har tränats på liknande material. Den måste vanligtvis föras in direkt i modellens arbetskontext via prompten eller genom ett hämtnings- eller verktygssystem, annars resonerar modellen utifrån allmän kunskap i stället för det faktiska dokumentet framför den.

Tokenisering och kontextfönster: Så bearbetas data

Innan en LLM bearbetar text delar en tokenizer upp den i mindre enheter som kallas token. En token kan representera ett helt ord, en del av ett ord, ett skiljetecken eller någon annan kort textdel.

För engelska är en användbar tumregel att en token motsvarar ungefär fyra tecken, eller omkring tre fjärdedelar av ett ord. Enligt den uppskattningen motsvarar 100 token cirka 75 ord. Det är dock bara en uppskattning. Ta frasen ”Context windows affect application performance.” En tokenizer representerar den inte nödvändigtvis som fem kompletta ord; beroende på tokenizer kan ett eller flera ord delas upp i flera delordstoken.

Tokenisering varierar också mycket mellan språk. Två meningar med liknande betydelse och synlig längd kan förbruka mycket olika antal token beroende på språket och tokenizern. Forskning om rättvisa i tokenizers har visat att vissa språkpar kan skilja sig med upp till 15 gånger i tokeniserad längd för likvärdig text, även med tokenizers byggda för flerspråkigt stöd. Utvecklare som bygger flerspråkiga applikationer bör mäta tokenanvändningen med den faktiska tokenizern för sin modell i stället för att uppskatta utifrån ordantal.

Ett kontextfönster på 200 000 token kan låta enormt, men en applikation som kontinuerligt lägger till konversationshistorik, hämtad dokumentation, verktygssvar och systeminstruktioner kan nå gränsen snabbare än väntat. Därför övervakar produktionsapplikationer ofta tokenanvändningen och använder tekniker som sammanfattning, rensning av historik, hämtningsfiltrering och promptkomprimering för att behålla den mest relevanta informationen i den aktiva kontexten.

Hur fungerar ett kontextfönster i språkmodeller?

Ett kontextfönster fungerar genom transformerarkitekturens uppmärksamhetsmekanism, som beräknar hur varje token i en inmatning förhåller sig till alla andra token innan modellen ger ett svar.

Ta meningen ”Kunden lämnade tillbaka den bärbara datorn eftersom den slutade ladda.” För att tolka den korrekt måste modellen förstå hur kund, bärbar dator, lämnade tillbaka och ladda förhåller sig till varandra. När en sekvens blir längre växer antalet sådana relationer snabbt.

I vanlig self-attention växer den nödvändiga beräkningen ungefär med kvadraten på sekvenslängden. En prompt på 10 000 token kräver till exempel omkring 100 miljoner parvisa jämförelser, medan en prompt på 100 000 token kräver omkring 10 miljarder. Moderna modeller använder en rad arkitektur- och infrastrukturoptimeringar för att minska kostnaden i praktiken, men det underliggande skalningsproblemet försvinner inte.

Långa konversationer innebär ytterligare en begränsning: key-value-cachen, eller KV-cachen. Under generering behåller modeller mellanliggande representationer av tidigare token i stället för att räkna om dem för varje ny token, vilket snabbar upp inferensen avsevärt. Cachen tar dock själv upp minne och växer i takt med att sekvensen blir längre.

Maximal kontextlängd i AI-modeller och varför den är viktig

En modells maximala kontextlängd avgör hur mycket information den kan ta emot och bearbeta i en enda begäran. Huruvida modellen använder ett stort kontextfönster effektivt är dock en separat fråga.

Längre kontextfönster möjliggör användningsområden som var svåra eller opraktiska med tidigare LLM:er. Utvecklare kan ge en modell ett helt kodarkiv, ett långt juridiskt dokument, en forskningsrapport, ett mötestranskript eller en omfattande konversationshistorik utan att först behöva reducera materialet till några tusen token.

Detta är viktigt eftersom mer av den ursprungliga kontexten kan förbättra modellens förmåga att besvara frågor korrekt, identifiera relationer mellan avlägsna informationsdelar och utföra uppgifter som beror på dokumentet som helhet. En kodningsassistent kan till exempel behöva granska flera filer för att förstå hur en funktion anropas, medan en assistent för juridiska dokument kan behöva jämföra definitioner i ett avsnitt med skyldigheter som beskrivs mycket senare i dokumentet.

Ett större kontextfönster ger dock inte automatiskt bättre resultat. Mycket långa inmatningar kan öka kostnad och latens, och modeller kan ägna mindre uppmärksamhet åt information som är begravd i mitten av en stor kontext. Utvecklare bör därför välja relevant information selektivt, strukturera långa inmatningar tydligt och vid behov använda tekniker som hämtning, sammanfattning och kontextrensning.

Jämförelse av kontextfönsterstorlekar per modell

Kontextfönster varierar kraftigt mellan dagens stora modellfamiljer, från några hundra tusen token till 10 miljoner. Så här jämförs dagens flaggskeppsmodeller:

Marknadsförda gränser ändras snabbt när leverantörer lanserar nya modeller och höjer sina tak, så betrakta en sådan här tabell som en ögonblicksbild snarare än en permanent rankning. Kontextstorlek är dessutom bara en faktor vid val av modell. Den säger i sig inget om kvaliteten på resonemang, utdatagränser, latens eller kostnad.

Följder av ett litet jämfört med ett stort kontextfönster

Ett litet kontextfönster tvingar utvecklare att vara selektiva. Långa dokument delas upp, äldre konversationshistorik sammanfattas och extern kunskap hämtas bara när den faktiskt behövs.

Ett stort kontextfönster tar bort en del av dessa begränsningar. Du kan tillhandahålla fler exempel, behålla mer konversationshistorik eller analysera en större uppsättning dokument utan att först dela upp allt.

Ett större fönster medför dock ett annat problem: utspädd uppmärksamhet. När en prompt innehåller stora mängder information kan modellen få svårt att avgöra vilka detaljer som är mest relevanta för den aktuella begäran. Viktiga instruktioner eller belägg kan begravas bland mindre relevant innehåll, vilket ökar risken för ofullständiga, inkonsekventa eller mindre precisa svar.

Varför modeller går vilse i mitten

Modeller tenderar att hämta information bäst när den finns nära början eller slutet av en lång prompt, och sämst när den är begravd i mitten. Den inflytelserika studien Lost in the Middle testade detta direkt genom att placera svaret på en fråga på olika positioner i en lång prompt och mäta hur ofta modeller hittade det. Träffsäkerheten var genomgående bäst i början och slutet av kontexten, och svagast i mitten.

Det betyder att en modell tekniskt sett kan ta emot ett dokument utan att tillförlitligt använda varje del av det. Skicka 100 supportdokument till en LLM eftersom ett av dem innehåller svaret på en kundfråga, så kan ett större kontextfönster få plats med alla 100. Men modellen måste fortfarande hitta ett relevant avsnitt bland 99 irrelevanta, och ett längre fönster garanterar inte att den gör det.

Därför är det värt att skilja mellan en modells marknadsförda kontextfönster och dess effektiva kontextfönster för en viss arbetsbelastning. Benchmarks som RULER och LongBench försöker mäta den skillnaden. RULER visade att modeller som presterade nästan perfekt på enkla hämtningstester ändå försämrades när kontextlängden och uppgiftens komplexitet ökade. LongBench utvärderar bredare uppgifter, bland annat frågesvar om dokument, resonemang över flera dokument, sammanfattning, few-shot-inlärning och kodkomplettering.

Lång kontext ger fortfarande verkligt värde. Kapacitet och förståelse är helt enkelt olika egenskaper, och båda spelar roll när du väljer modell för en viss uppgift.

Hantera kontextgränser: Bästa praxis för utvecklare

God kontexthantering innebär att styra vad som når modellen: att tillhandahålla information som är relevant för uppgiften när den är relevant, snarare än att försöka maximera antalet token i varje begäran. Följande metoder kan hjälpa utvecklare att minska onödig kontext, förbättra svarskvaliteten och kontrollera kostnad och latens.

1. Hämta relevant information i stället för att läsa in allt

Retrieval-augmented generation, eller RAG, låter en applikation söka i en extern kunskapsbas och bara lägga in relevanta avsnitt i modellens kontext. I stället för att lägga in en hel manual på 500 sidor i varje supportbegäran hämtar applikationen de få avsnitt som ligger närmast kundens faktiska fråga.

Det minskar tokenanvändningen och ger modellen en mycket tydligare signal om vad som är viktigt. Kvaliteten på hämtningen spelar fortfarande roll: RAG-system i produktion förbättrar vanligtvis resultaten genom att dela upp dokument omsorgsfullt, hämta flera kandidatavsnitt, omrangordna kandidaterna och filtrera bort allt irrelevant innan den slutliga prompten byggs. ElevenLabs har till exempel byggt om sin RAG-pipeline för att lägga till omskrivning av frågor och parallella modellanrop, vilket halverade medianlatensen för hämtning.

2. Hantera konversationshistoriken medvetet

Konversationsapplikationer samlar snabbt på sig kontext. Att lägga till varje tidigare meddelande i all oändlighet slösar token och kan föra in irrelevanta detaljer i senare turer.

Applikationer hanterar detta genom att behålla de senaste turerna, sammanfatta äldre utbyten, extrahera bestående fakta till strukturerat minne och hämta äldre detaljer först när de blir relevanta igen. Det skapar en användbar uppdelning mellan kortsiktig konversationskontext, som modellen behöver direkt, och mer långsiktigt applikationsminne, som kan hämtas in igen senare.

3. Använd cachning när kontexten upprepas

Många applikationer skickar samma omfattande instruktioner upprepade gånger eller besvarar frågor som semantiskt liknar frågor de redan har hanterat. Cachning minskar den belastningen.

Prompt- eller kontextcachning gör att upprepad inmatning kan återanvändas effektivare, och semantisk cachning går ett steg längre genom att känna igen när en ny fråga betyder ungefär samma sak som en fråga systemet redan har besvarat. ”Vilken returpolicy har ni?” och ”Hur länge kan jag returnera en vara?” är olika strängar som en semantisk cache kan behandla som samma fråga, vilket hoppar över ett fullständigt genereringsanrop och minskar både latens och tokenkostnader.

4. Mät prestanda vid realistiska kontextlängder

Välj inte en kontextstrategi enbart utifrån en modellleverantörs marknadsförda tokengräns. Testa representativa produktionsarbetsbelastningar och mät svarskvalitet, hämtningsprecision, latens, tokenanvändning, kostnad och felfrekvens när kontextlängden ökar.

Jämför strategier som att tillhandahålla mer kontext, hämta färre avsnitt, sammanfatta konversationshistoriken eller kombinera hämtning med sammanfattning. En modell med ett kontextfönster på en miljon token kan tekniskt sett stödja din applikation, medan en mindre, omsorgsfullt hämtad prompt ger snabbare och mer korrekta resultat till lägre kostnad.

Kom igång med ElevenAgents för skalbara språklösningar

Kontexthantering är som viktigast i konversationsagenter, som måste kombinera det aktuella yttrandet med tidigare turer, affärsinstruktioner, kundinformation, innehåll från kunskapsbasen och verktygsresultat, samtidigt som de svarar tillräckligt snabbt för att samtalet ska kännas naturligt.

ElevenAgents samlar dessa delar i en plattform för att bygga och driftsätta AI-röstagenter. Dess orkestreringsmotor samordnar taligenkänning, en LLM och Text to Speech, medan utvecklare konfigurerar promptar, kunskapsbaser, verktyg, workflows och den underliggande språkmodellen. Uttrycksfull leverans, inklusive hur en agent förmedlar emotionell kontext i tal, beror på samma kontext som från början formar vad agenten säger.

För kunskapshantering särskilt stöder ElevenAgents både dokument med full kontext och RAG, som kan konfigureras direkt på plattformen. Små dokument läggs direkt i en agents prompt, så att innehållet är tillgängligt under hela konversationen. Större kunskapsbaser indexeras i stället, och RAG hämtar relevanta avsnitt för varje fråga i stället för att läsa in allt i kontextfönstret på en gång.

Kom igång genom att registrera dig för ElevenAgents i dag eller prata med vårt team för att få veta mer om dina driftsättningsalternativ.

Vanliga frågor om kontextfönster