Hvad er tokenization og context windows?

Tokenization er opdelingen af tekst til tokens, som en sprogmodel kan behandle. Et context window er den samlede mængde tokens, modellen kan bruge på én gang. Begge begreber afgør, hvor meget information der kan indgå i et AI-svar, og hvor præcist input bør struktureres.

Hvordan hænger tokenization og context windows sammen?

Tokenization og context windows beskriver to forskellige led i samme tekniske proces. Tokenization gør tekst, tegnsætning, mellemrum og andre elementer om til en rækkefølge af tokens. Context window angiver, hvor mange af disse tokens modellen kan have til rådighed i en enkelt behandling.

Når du sender en lang instruktion, et dokument eller en samtale til en sprogmodel, bliver indholdet først opdelt efter modellens tokenizer. Derefter vurderes det samlede antal tokens i forhold til modellens context window. Hvis grænsen overskrides, må systemet afvise inputtet, forkorte det, opsummere det eller fjerne ældre dele.

Det gør tokenization praktisk vigtig, selv om brugeren normalt skriver almindelig tekst. To tekster med samme antal ord kan fylde forskelligt i tokens, især hvis de indeholder kode, tal, usædvanlige tegn, mange sammensatte ord eller flere sprog. Context window er derfor ikke bare en side- eller ordgrænse, men en modelafhængig tokenramme.

Hvad er en token i en sprogmodel?

En token er en lille tekstdel, som modellen behandler som et element i sin interne sekvens. En token kan være et helt ord, en del af et ord, et tegn, et mellemrum sammen med et ord eller et tegnsætningssymbol. OpenAI beskriver i sin vejledning til Tiktoken, at en tokenizer kan opdele en tekststreng i tokens, og at forskellige modeller kan bruge forskellige encodings.

Tokens bliver normalt omsat til numeriske værdier, som modellen kan bruge i beregninger. Det betyder ikke, at modellen forstår tekst ved at slå ord op i en ordbog. Den arbejder med mønstre i sekvenser af token-id’er, som er lært under træning og senere bruges til at beregne sandsynlige fortsættelser.

Tokenbegrebet er også relevant for AI-embeddings, fordi både sprogmodeller og embeddingmodeller skal omsætte tekst til en form, der kan beregnes på. Forskellen er, at embeddings typisk bruges til at repræsentere betydning i vektorer, mens tokenrækken er den direkte sekvens, modellen bearbejder i generering.

Hvorfor svarer tokens ikke bare til ord?

Tokens følger en teknisk encoding, ikke almindelig grammatik. Et kort dansk ord kan være én token, mens et langt sammensat ord kan blive delt i flere tokens. Et mellemrum kan hænge sammen med starten af et ord. Kode, specialtegn, produktnavne og URL’er kan også give flere tokens end en hurtig optælling af ord antyder.

Det betyder, at en tekst på 1.000 ord ikke har et fast tokenantal på tværs af modeller. Den samme tekst kan fylde forskelligt i to systemer, fordi tokenizeren og encoding-tabellen er anderledes. Derfor kan en tekst passe i ét værktøj og overskride grænsen i et andet.

For praktisk brug er den vigtigste konsekvens, at du bør måle med det konkrete værktøj eller den konkrete API, når tokenforbrug betyder noget. Det gælder især ved automatisering, hvor mange beskeder, dokumentuddrag eller historiske samtaletrin samles i samme input.

Hvad betyder et context window i praksis?

Et context window er den arbejdshukommelse, modellen kan bruge i den aktuelle behandling. Anthropic beskriver i sin dokumentation om context windows, at vinduet omfatter den tekst, modellen kan referere til, når den genererer et svar, og at det adskiller sig fra den større datamængde, modellen er trænet på.

Et context window kan indeholde instruktioner, brugerens input, tidligere svar, dokumentuddrag, værktøjsresultater og det nye svar, afhængigt af hvordan systemet er bygget. Når vinduet bliver fyldt, skal noget prioriteres. Ellers kan modellen mangle relevante oplysninger, selv om de har været nævnt tidligere i en samtale.

Du kan tænke på context window som et arbejdsbord. Et større bord giver plads til flere papirer, men det afgør ikke i sig selv, om de vigtigste papirer ligger synligt, er markeret tydeligt eller er ordnet i en rækkefølge, modellen kan bruge.

Hvilke dele tæller med i context window?

Det konkrete svar afhænger af leverandør, model og API, men hovedreglen er, at tekst og andre inputdele, der sendes til modellen, tæller med i tokenbudgettet. I mange systemer tæller tidligere beskeder og dele af modellens egne svar også med, når samtalen fortsætter over flere trin.

Ved værktøjsbrug kan der komme ekstra indhold ind i vinduet: søgeresultater, beregninger, databaseresultater, filuddrag eller fejlbeskeder. Det kan være nyttigt, men det kan også fortrænge vigtig kontekst, hvis systemet sender for meget rådata videre.

For organisationer betyder det, at tokenbudgettet bør ses som en designressource. Du skal ikke kun spørge, om modellen har et langt nok vindue, men også om systemet sender de rigtige oplysninger i den rigtige form.

Hvornår giver et langt context window reel værdi?

Et langt context window giver mest værdi, når opgaven kræver sammenhæng mellem mange tekstdele. Det kan være gennemgang af kontraktbilag, teknisk dokumentation, kodefiler, lange mødenoter eller flere datakilder, hvor modellen skal finde relationer på tværs af materialet.

Google beskriver i sin Gemini API-dokumentation om long context, at mange Gemini-modeller har context windows på 1 million eller flere tokens, og at store vinduer åbner for nye anvendelser. Det er en kapacitetsoplysning om bestemte modeller, ikke en garanti for, at alle detaljer i et langt input bruges lige godt.

Den største gevinst kommer ofte, når langt input kombineres med tydelig struktur: overskrifter, korte delspørgsmål, prioriterede kilder, metadata og en klar rækkefølge. Ustruktureret masse kan give højere omkostning og lavere præcision, selv om den teknisk kan være inden for vinduet.

Hvorfor er et større context window ikke altid bedre?

Et større vindue giver plads, men ikke automatisk bedre forståelse. Forskningen Lost in the Middle viste, at modeller kan klare sig dårligere, når den relevante information ligger midt i en lang kontekst, sammenlignet med når den ligger tættere på begyndelsen eller slutningen.

Det er en praktisk begrænsning: Hvis du lægger mange dokumenter ind uden markering af, hvad der er centralt, kan modellen overse eller undervurdere vigtige detaljer. Problemet bliver mere synligt, når konteksten er lang, fordi der er mere information at sortere i.

Derfor bør lange vinduer bruges med samme disciplin som kortere vinduer. De vigtigste krav, definitioner, forbehold og datakilder bør placeres tydeligt. Opgaven bør opdeles, hvis modellen skal kontrollere mange detaljer, og svaret bør efterprøves mod de oprindelige kilder.

Hvordan påvirker tokenization pris, hastighed og stabilitet?

Tokenforbrug påvirker typisk både pris og hastighed i API-baserede systemer, fordi mange leverandører måler input og output i tokens. Flere tokens kræver mere behandling, og lange svar kan optage plads, der ellers kunne bruges til dokumenter eller tidligere beskeder.

Tokenization påvirker også stabilitet. Hvis en automatiseret arbejdsgang nogle gange modtager meget lange filer, kan den fejle ved enkelte kørsler, selv om den virker ved korte eksempler. Det er en almindelig årsag til uforudsigelig adfærd i integrationsarbejde.

En enkel kontrol er at registrere tokenforbrug for typiske og ekstreme input. Brug derefter faste grænser for filstørrelser, antal dokumentuddrag, længden af historik og maksimalt output. Den slags tekniske rammer gør AI-funktionen mere forudsigelig for brugere og drift.

Hvordan bør du strukturere lange input?

Lange input bør bygges, så modellen kan finde det vigtigste uden at skulle udlede formålet fra en stor tekstmasse. Start med målet, afgrænsningen og de vigtigste definitioner. Placer derefter dokumentuddrag i en stabil rækkefølge, og brug korte labels, der forklarer, hvad hvert uddrag er.

• Angiv opgaven først, så modellen ved, om den skal forklare, sammenligne, kontrollere eller opsummere.
• Fjern dubletter og irrelevante bilag, før materialet sendes videre.
• Del meget lange arbejdsopgaver i trin, hvis hvert trin kræver præcis kontrol.
• Gem kildehenvisninger, så svaret kan spores tilbage til det rigtige dokumentuddrag.

Hvis du arbejder med flere dokumenter, kan du kombinere long context med søgning eller en vektordatabase. En vektordatabase kan finde relevante uddrag, mens context window bestemmer, hvor meget af det fundne materiale der faktisk sendes til modellen i den enkelte behandling.

Hvad er forskellen på context window, hukommelse og træningsdata?

Context window er den aktuelle inputramme. Hukommelse er en produkt- eller systemfunktion, hvor udvalgte oplysninger kan gemmes og bruges senere. Træningsdata er den historiske datamængde, som modellen blev lært på, før den blev taget i brug.

De tre begreber blandes ofte sammen, men de har forskellige konsekvenser. Noget kan være i træningsdata uden at være synligt i den aktuelle behandling. Noget kan være i et hukommelseslag uden at fylde hele inputtet. Og noget kan være i context window uden at være permanent gemt.

For brugere og organisationer er skellet vigtigt ved datafortrolighed. Hvis du sender følsomt materiale ind i et AI-system, er det ikke nok at kende modellens context window. Du skal også kende leverandørens databehandling, logning, adgangsstyring og aftalevilkår.

Hvordan hænger context windows sammen med transformer-modeller?

Moderne sprogmodeller bygger ofte på transformer-arkitekturen. En transformer-model bruger opmærksomhedsmekanismer til at beregne relationer mellem tokens i en sekvens. Context window sætter rammen for, hvor lang den sekvens kan være i den konkrete behandling.

Større context windows kræver tekniske løsninger, fordi beregning over mange tokens kan være dyrt. Derfor ser man forskellige metoder til længere sekvenser, komprimering, caching og udvælgelse af relevante dele. Disse metoder kan ændre, hvordan systemet opleves, selv når brugerfladen blot viser et tekstfelt.

Context window er derfor både et produktvilkår og et arkitekturspørgsmål. Produktet kan angive en maksimal grænse, men den effektive anvendelse afhænger af modeldesign, opgavetype, inputstruktur og test på de dokumenter, der faktisk skal bruges.

Hvordan tester du om en model kan bruge lang kontekst godt?

Den enkleste test er ikke at spørge, om materialet kan være i vinduet. Spørg i stedet, om modellen kan finde, sammenholde og gengive de rigtige oplysninger, når materialet ligger forskellige steder i inputtet. Test både begyndelse, midte og slutning.

En praktisk testpakke kan bestå af kendte dokumenter, kontrollerede spørgsmål og forventede svar med kildeplacering. Hvis modellen kun finder svar, når oplysningerne står tidligt eller sent, bør du ændre struktur, bruge kortere delopgaver eller hente færre, mere relevante uddrag.

Det samme princip gælder efter fine-tuning af sprogmodeller. Tilpasning kan ændre adfærd og format, men den fjerner ikke behovet for at teste, hvordan modellen håndterer lange input, tvetydige kilder og placering af centrale oplysninger.

Hvilke kontrolpunkter bør organisationer bruge?

Organisationer bør behandle tokenization og context windows som driftsnære designkrav. Det handler ikke kun om at vælge den model med størst tal i specifikationen, men om at gøre AI-funktionen stabil, sporbar og økonomisk fornuftig.

Kontrolpunkterne bør gentages, når modellen skiftes, når leverandøren ændrer API, eller når arbejdsgangen begynder at behandle større dokumenter. Context window-størrelser og tokenizers er modelafhængige, så en integration bør ikke antage, at alle modeller reagerer ens.

Hvilke kilder ligger til grund?