Kontekstvinduet ingen forteller deg om

Samtalen om AI-verktøy handler nesten alltid om funksjoner. Hva kan den gjøre? Det er feil spørsmål. Riktig spørsmål er: hvor godt kan den gjøre det? Og svaret avhenger av noe de færreste snakker om.

Arbeidsminnet

Alle språkmodeller har et kontekstvindu — en øvre grense for hvor mye informasjon de kan behandle i én forespørsel. Tenk på det som arbeidsminne. Alt modellen trenger for å svare deg må passe inn: samtalehistorikken, systeminstruksjonene, relevante dokumenter, og — det folk glemmer — beskrivelsen av hvert eneste verktøy modellen har tilgang til.

Kontekstvinduer har blitt større. Claude håndterer 200 000 tokens, GPT-4o rundt 128 000. Det høres mye ut. Men det er ikke størrelsen som er problemet. Det er hva du fyller det med.

Verktøydefinisjonsavgiften

Når en AI-agent har tilgang til verktøy — muligheten til å utføre handlinger, ikke bare generere tekst — må hvert verktøy beskrives fullstendig i konteksten. Modellen trenger å vite: hva heter verktøyet, hva gjør det, hvilke parametere tar det, hvilke typer har parameterne, og hvilke begrensninger gjelder.

Et enkelt verktøy tar kanskje 200 tokens. Et komplekst med mange parametere og nestede skjemaer kan ta 500 eller mer. Ti verktøy: rundt 3 000 tokens. Håndterbart. Femti verktøy: 15 000 tokens. Hundre og femti verktøy: 45 000 tokens — opptatt av verktøybeskrivelser alene, før samtalen i det hele tatt har begynt.

Tenk på det som å møte opp til en eksamen der 30 prosent av pulten er dekket av verktøykasser du kanskje trenger. Du har mindre plass til å tenke.

Hva forskningen viser

Det er ikke bare en metafor. Forskning på språkmodellers ytelse med mange verktøy viser dramatiske fall i kvalitet. I eksperimenter med GPT-4o falt nøyaktigheten for verktøyvalg fra 43 % med fire verktøy til 2 % med femtien. Ikke en gradvis nedgang — et stup.

Fenomenet kalles «context rot» i fagmiljøene. Det handler ikke om at modellen går tom for plass. Det handler om signal-støy-forholdet. Jo mer irrelevant informasjon i konteksten, jo vanskeligere er det for modellen å finne det som faktisk er relevant. «Lost in the middle»-effekten forsterker problemet: modeller håndterer informasjon i starten og slutten av konteksten godt, men sliter med det som ligger i midten — nøyaktig der de fleste verktøydefinisjoner havner.

Og det er et dobbelt tap. Modellen blir ikke bare dårligere til å velge riktig verktøy — den blir dårligere til alt. Resonneringen svekkes. Tekstkvaliteten faller. Evnen til å følge instruksjoner reduseres. Samtidig betaler du mer per forespørsel, fordi tokenforbruk skalerer lineært med kontekststørrelse. Flere verktøy gir dårligere kvalitet til høyere pris.

Hvorfor dette treffer saksbehandling hardt

Domenespesifikke oppgaver krever domenespesifikke verktøy. Juridisk oppslag krever verktøy mot lovverk. Eiendomsdata krever verktøy mot matrikkelen. Artsdata krever verktøy mot Artsdatabanken. Geodata krever verktøy for arealanalyse og reguleringsplaner. Arkivintegrasjoner krever verktøy for dokumenthåndteringssystemer.

Et komplett saksbehandlingssystem kan trenge over hundre spesialiserte verktøy. Men å putte alle i ett kontekstvindu skaper en umulig avveining: færre verktøy gir mindre funksjonalitet, flere verktøy gir dårligere kvalitet. Det er et arkitekturproblem, ikke et modellproblem. Ingen fremtidig modell løser det, fordi problemet ikke er kapasitet — det er oppmerksomhet.

Spesialister fremfor generalister

Alternativet er å ikke gi én generalist alle verktøyene. I stedet: et lag av spesialister som hver har et avgrenset, relevant verktøysett.

En juridisk spesialist som kan tre ting: søke i lovverket, hente ut spesifikke dokumenter, og planlegge en søkestrategi. En eiendomsspesialist som kan fire ting: slå opp i matrikkelen, validere adresser, hente kommunedata, og sjekke eiendomsgrenser. En arkivspesialist som kjenner API-et til det relevante dokumenthåndteringssystemet inngående — kanskje ti til femten operasjoner.

Over disse sitter en koordinator som forstår oppgaven og delegerer til riktig spesialist. Koordinatoren ser ikke hundre og femti verktøy — den ser et knippe spesialister. Og hver spesialist jobber i sin egen, rene kontekst. Når koordinatoren trenger et juridisk svar, starter spesialisten med et rent arbeidsminne: bare spørsmålet og bare sine tre verktøy.

Resultatet er målbart. Hver spesialist opererer med et høyt signal-støy-forhold. Verktøyvalget er presist fordi det finnes få alternativer. Resonneringen er bedre fordi konteksten ikke er overfylt med irrelevant informasjon. Og kostnaden per forespørsel er lavere fordi hvert kall bruker bare de tokenene som faktisk er nødvendige.

Datalag designet for tokenøkonomi

Arkitekturen stopper ikke ved agentene. Datakildene som agentene bruker, må også være designet for hvordan språkmodeller fungerer.

Ta en veiledningstjeneste med hundre faglige retningslinjer. Å hente alt innholdet for alle retningslinjer koster titusenvis av tokens, hvorav det meste er irrelevant for den aktuelle saken. Alternativet: først hente en kompakt indeks — bare ID og tittel — og deretter hente detaljert innhold kun for de relevante retningslinjene. Det sparer tokens, forbedrer kvaliteten, og gjør det mulig for agenten å jobbe iterativt: utforsk bredden først, gå i dybden etterpå.

Samme prinsipp gjelder for eiendomsdata, artsdata, geodata, og alle andre domenespesifikke kilder. API-responsene struktureres med validerte skjemaer som gir modellen nøyaktig den informasjonen den trenger i et forutsigbart format. Ikke et generelt JSON-dump — et tilpasset, maskinlesbart svar.

Kontekststyring som disiplin

Utover selve agentarkitekturen finnes det flere teknikker for å holde konteksten fokusert:

Oppsummering. Når samtalehistorikken vokser forbi en terskel — for eksempel 120 000 tokens — komprimeres eldre meldinger til et sammendrag. De siste meldingene beholdes intakt. Det holder konteksten innenfor budsjett uten å miste viktig sammenheng.

Isolasjon. Hver spesialist starter med en ren kontekst for hvert oppdrag. Den bærer ikke med seg bagasjen fra hele samtalen — bare det spesifikke spørsmålet den skal besvare. Resultatet sendes tilbake til koordinatoren, som beholder det den trenger og forkaster resten.

Oppdeling. Store dokumenter som overstiger en spesialists kapasitet deles opp i biter. Hver bit behandles separat, og resultatene syntetiseres i et eget steg. Modellen beregner selv hvor store bitene kan være, basert på eget kontekstvindu.

Dynamisk verktøyvalg. I stedet for å gi agenten alle tilgjengelige verktøy hele tiden, aktiveres verktøy basert på oppgavens behov. En samtale om byggesøknader trenger ikke verktøy for artsdata — med mindre samtalen dreier den veien.

Den usynlige arkitekturen

Ingenting av dette er synlig for brukeren. De ser en samtale. De stiller et spørsmål og får et svar. Men bak svaret ligger en arkitektur som respekterer de grunnleggende begrensningene i hvordan språkmodeller faktisk fungerer.

Den viktigste forskjellen mellom AI-systemer er ikke hvilken modell de bruker. Modellene er i stor grad de samme. Forskjellen er hvordan de organiserer konteksten. Hvordan de avgrenser verktøy. Hvordan de delegerer oppgaver. Hvordan de styrer oppmerksomheten.

Det er arkitektur. Og den er usynlig — helt til den ikke fungerer.

Neste gang noen sier «vi bruker AI», spør hva som fyller kontekstvinduet.