Sprogmodeller og LLM'er — Hvad de er og hvordan de virker

En Large Language Model er ikke et vidensystem — det er et sandsynlighedssystem. Den forudsiger, token for token, hvad der statistisk set sandsynligvis kommer næste i en sekvens. Det lyder simpelt. Det er grundlaget for det meste af det AI-baserede arbejde der sker i SEO og content-automation i dag.

At forstå de grundlæggende mekanismer giver dig et bedre udgangspunkt for at bruge modellerne effektivt: du ved hvornår de fejler, hvorfor de fejler, og hvad du kan gøre ved det.

Transformer-arkitekturen — grundlaget for moderne LLM’er

Alle frontier-modeller i dag er bygget på transformer-arkitekturen, introduceret i Google-papiret “Attention is All You Need” fra 2017. Det centrale element er attention-mekanismen: modellen lærer at fokusere på de mest relevante dele af input-sekvensen når den genererer output.

Forestil dig at du læser sætningen “Nøglen lå på bordet, og hun tog den op.” For at forstå at “den” refererer til “nøglen” og ikke “bordet” skal din hjerne holde styr på relationer over afstand i teksten. Attention-mekanismen gør præcis det — men over milliarder af parametre trænet på internet-skala tekst.

Konsekvensen: LLM’er er exceptionelt gode til at forstå kontekst, fastholde sammenhæng over lange tekster og producere sprogligt kohærent output. De er ikke gode til at “vide” fakta i den forstand vi normalt bruger ordet.

Tokens — modelens grundenhed

Modellen behandler ikke tekst som bogstaver eller ord — den behandler tokens. En token er typisk 3-4 tegn på engelsk, lidt færre på dansk (dansk morfologi giver lidt anderledes tokenisering). Ordet “søgemaskineoptimering” kan tokeniseres som 5-7 tokens afhængig af modellen.

Tokenisering har praktiske konsekvenser:

Pris: API-kald prissættes per token. En prompt med 10.000 ord koster mere end en med 1.000 ord. Effektiv prompt-design handler delvis om at kommunikere præcist uden overflødige tokens.

Context window: Modellens hukommelse i en session måles i tokens — ikke ord. Claudes 200k token-grænse svarer til ca. 150.000 ord eller en roman.

Tallene er svære for modellen: Fordi tal tokeniseres som tegn-sekvenser snarere end numeriske værdier, er aritmetik og tal-manipulation noget LLM’er er dårlige til uden eksternt hjælp (calculator tool, kodeeksekvering).

Context window — modelens kortidshukommelse

Context window er mængden af information modellen kan “holde i hovedet” under en enkelt session. Alt der ikke er i context window eksisterer ikke for modellen — den kan ikke “huske” hvad der skete i en tidligere session medmindre det er givet som kontekst igen.

Praktisk implikation for SEO: Claudes 200k token-grænse gør det muligt at sende et komplet crawl-datasæt, et fuldt content-audit eller et repositories kode til analyse i én omgang. GPT-4o’s 128k token-grænse er stadig stor — men der er tilfælde hvor forskellen er afgørende.

Det er også grunden til at lange, komplekse analytiske opgaver klarer sig bedre med frontier-modeller end med ældre eller billigere modeller: de kan holde mere kontekst aktivt og dermed producere mere sammenhængende analyser.

Embeddings — mening som matematik

Embeddings er måden LLM’er repræsenterer semantisk mening som tal. Hvert ord, sætning eller dokument kan konverteres til en vektor — en liste af tal — hvor semantisk lignende indhold ligger tæt på hinanden i det matematiske rum.

“Søgemaskine” og “Google” vil have embeddings der er tæt på hinanden. “Søgemaskine” og “havtorn” vil ligge langt fra hinanden.

Det bruges i praksis til:

Semantisk søgning: I stedet for at søge efter eksakte keyword-matches finder du indhold der er semantisk relateret. Grundlaget for mange RAG-systemer.

Content clustering: Du kan embedde store mængder URLs eller sider og clustre dem automatisk baseret på semantisk lighed — uden manuelt at læse dem.

Duplicate detection: Semantisk ens indhold kan identificeres selv om det er formuleret forskelligt.

Embeddings er en separat kapacitet fra generativ output — du kalder typisk en embedding-model (f.eks. OpenAIs text-embedding-3-large eller Anthropics egne) og gemmer vektorerne i en vektordatabase (Pinecone, Weaviate, pgvector).

Hallucination — hvad det er og hvad det ikke er

Hallucination er et ord der bruges upræcist i populærpressen. En LLM hallucinerer ikke fordi den er dum, sygelig eller uærlig. Den hallucinerer fordi den er designet til at producere flydende, sandsynligt næste-token-output — og det indebærer at den sommetider producerer faktamæssigt forkert men sprogligt overbevisende tekst.

Klassiske hallucination-scenarier:

• Modellen opfinder citater, studier eller statistikker der lyder troværdige men ikke eksisterer
• Modellen “husker” forkert om specifikke tal, datoer eller navne
• Modellen ekstrapolerer logisk korrekt men fra forkerte præmisser

Løsningen er ikke at stole blindt på modellens output — det er at designe workflows der inkluderer verifikationstrin. RAG (Retrieval-Augmented Generation) er den primære tekniske løsning: du giver modellen faktadokumenter som kontekst, og den er instrueret til at basere svar udelukkende på disse dokumenter.

For SEO-brug: brug aldrig en LLM til at hente faktuelle statistikker eller citater uden verifikation. Brug den til at transformere, strukturere og analysere data du selv har indsamlet.

Fine-tuning — hvornår det giver mening

Fine-tuning er processen hvor du træner en eksisterende model videre på dine egne data. Resultatet er en model der taler dit brand-sprog, kender dit format eller er specialiseret til en specifik opgave.

I praksis: du tager et basisfundament (GPT-4o mini, Llama, Mistral) og træner det videre på par af input/output-eksempler der repræsenterer den adfærd du ønsker.

Fine-tuning giver mening når:

• Du har et meget specifikt outputformat der er svært at kommunikere via prompts alene
• Du kører high-volume tasks og en billigere fine-tuned model kan erstatte en dyr frontier-model
• Du arbejder med domæne-specifikt sprog (juridisk, medicinsk, meget teknisk) der er underrepræsenteret i træningsdata

Fine-tuning giver ikke mening som erstatning for god prompt engineering. Før du fine-tuner, er spørgsmålet altid: kan du få det ønskede output med en bedre system prompt og few-shot eksempler? Svaret er hyppigere ja end de fleste tror.

RAG — Retrieval-Augmented Generation

RAG er arkitekturen der kobler LLM’er med ekstern, verificerbar viden. I stedet for at stole på hvad modellen “husker” fra træning, retriever du relevante dokumenter i realtid og sender dem som kontekst.

En typisk RAG-pipeline:

1. Bruger stiller et spørgsmål
2. Spørgsmålet embeddes og matches mod en vektordatabase med relevante dokumenter
3. De mest relevante dokumenter sendes som kontekst til LLM’en
4. LLM’en genererer svar baseret på de specifikke dokumenter

For SEO er RAG relevant i f.eks. content intelligence-systemer: du embedder alle dine egne sider og konkurrenternes sider, og agenten kan retrieve relevant kontekst for enhver opgave — uden at sende hele databasen som context.

Hvilken model til hvad — en praktisk oversigt

Frontier-modellerne har forskellige profiler. Her er udgangspunktet for at vælge:

Claude Opus 4.6 (200k tokens) — dybde, præcision, kompleks ræsonnering. Til strategidokumenter, lang kodeanalyse og komplekse audits. Markant dyrere end Sonnet.

Claude Sonnet 4.6 (200k tokens) — balance mellem kvalitet og pris. Defaultvalget til produktion-SEO-workflows, content-analyse og API-brug i skala.

Claude Haiku 4.5 (200k tokens) — hastighed og lav pris. Til klassifikation, simple transformationer og real-time chat. Ikke til opgaver der kræver nuanceret forståelse.

GPT-4o (128k tokens) — kreativitet og multimodal analyse. Bedre end Claude til billedanalyse og brainstorming hvor variation i output er en fordel frem for præcis instruktionsfølgning.

GPT-4o mini (128k tokens) — pris og hastighed til high-volume simple opgaver.

Hvad det betyder for dit daglige LLM-brug

Du behøver ikke forstå transformer-matematik for at bruge LLM’er effektivt. Men de konceptuelle byggeklodser — tokens, context window, embeddings, hallucination, fine-tuning, RAG — giver dig et mentalt framework der hjælper dig til at:

• Vælge den rigtige model til den rigtige opgave
• Designe prompts der ikke spilder tokens
• Bygge workflows der håndterer hallucination intelligent
• Vide hvornår RAG eller fine-tuning er den rigtige løsning

De tekniske detaljer er sekundære. Den praktiske forståelse er det der adskiller dem der bruger AI effektivt fra dem der er frustrerede over at det ikke virker som forventet.

Næste skridt: se LLM og SEO for konkrete workflows.