Din side bliver aldrig læst. Ét afsnit af den bliver.
Når en AI-model citerer et website, henter den ikke siden, som et menneske ville have læst den – fra toppen, gennem en indledning, ned til konklusionen. Den henter én chunk: en lille, afgrænset tekstbid, ofte ikke mere end et afsnit. Den chunk sættes ind i et svar, isoleret fra alt andet, der stod omkring den, og din side får aldrig chancen til at forklare sig selv i sin helhed.
Det gør chunken, ikke siden, til den reelle konkurrenceenhed. To sider kan have identisk godt overordnet indhold og alligevel præstere helt forskelligt i AI-søgning, hvis den ene er skrevet i bidder, der giver mening alene, og den anden ikke er det.
Retrieval i korte træk: embedding, lighed, hentning
Mekanikken bag dette hedder retrieval, og den behøver ikke være jargon for at kunne forstås. Et retrieval-system deler først indholdet på en side op i chunks. Hver chunk gøres derefter om til en embedding – en talvektor, der fanger den overordnede mening i teksten, ikke kun ordene i den. Når nogen stiller et spørgsmål, gøres spørgsmålet om til samme type talvektor.
Systemet sammenligner derefter spørgsmålets vektor med vektorerne for alle de chunks, det har gemt, og finder dem, der ligger tættest på – altså de chunks, der »ligner mest« det, spørgsmålet handler om. Det er dem, og kun dem, der hentes ind som grundlag for svaret. En chunk længere nede på siden kan blive hentet, mens en chunk lige over eller under den ikke gør, fordi ligheden beregnes pr. chunk, ikke pr. side.
Konsekvensen er praktisk, ikke teoretisk: du skriver ikke længere til en læser, der ser hele din side på én gang. Du skriver til et system, der kan finde på at plukke netop ét afsnit af den ud og lade resten ligge.
Hvad gør en chunk selvstændig
En chunk, der fungerer, kan stå alene uden noget af teksten omkring den. Den har et tydeligt subjekt i stedet for et pronomen som »vi« eller »det« (se næste del i serien). Den definerer eller forklarer det, den handler om, der og da, i stedet for at henvise til »som nævnt tidligere«. Og den fuldender sin tanke inden for sine egne grænser, i stedet for at indlede en påstand, der først giver mening, når næste afsnit læses ved siden af.
Et enkelt spørgsmål afslører svagheden: kopiér afsnittet ud af siden, og sæt det ind et helt andet sted, alene. Giver det stadig mening? Hvis svaret kræver, at læseren husker noget længere oppe på siden, gør det formentlig heller ikke det for et retrieval-system.
Overskriftshierarkiet er en chunk-grænse, ikke bare design
Mange retrieval-systemer deler indhold op langs den struktur, der allerede findes i HTML'en – og overskriftshierarkiet er den tydeligste struktur, en side har. En H2 markerer ofte, hvor én chunk slutter, og en ny begynder, på samme måde som den markerer et nyt afsnit for en menneskelig læser. Det gør overskriften til mere end typografi: den er en bogstavelig grænse for, hvad der regnes som samme tekstenhed, og hvad der ikke gør.
En overskrift som »Lidt mere om dette« eller »Andre forhold« giver ingen information om, hvad der ligger under den, hverken til en menneskelig skimlæser eller til et system, der skal afgøre, om chunken er relevant for et givet spørgsmål. En overskrift formuleret som selve spørgsmålet eller påstanden, den svarer på, gør derimod dobbelt arbejde: den fortæller et menneske, hvad der følger, og den fungerer som et præcist filter for hentningen.
Lange indledninger er dødvægt
»I denne artikel skal vi se på …« er en almindelig åbning, og den er næsten altid spildt plads set fra retrieval-systemets side. Hentes netop den indledende chunk – hvilket sker oftere, end man skulle tro, da den ofte er den første, mest generiske tekst på siden – består svaret af en varsling om, at et svar kommer, uden selve svaret. For en menneskelig læser er det en mild irritation. For en AI-model, der skal bygge en citering direkte fra chunken, er det en blindgyde: ingen påstand at citere, kun et løfte om én længere nede.
Reglen, der følger af dette, er enkel: lad den første sætning i hvert afsnit indeholde selve pointen, ikke en varsling om, at pointen kommer.
| Form | Har egen afgrænsning? | Chunk-egnethed |
|---|---|---|
| Løbende afsnit med flere påstande efter hinanden | Nej – grænsen mellem påstand 1 og påstand 2 findes kun i forfatterens hoved | Lav: hentes halvdelen af afsnittet, mangler halvdelen af påstanden sin kontekst. |
| Definition (»X er Y«) | Ja – begreb og forklaring i samme sætning | Høj: kan hentes og citeres helt alene. |
| Punkt i en liste under en præcis overskrift | Ja – hvert punkt er én afgrænset påstand | Høj: hvert punkt kan hentes enkeltvis uden resten af listen. |
| Række i en tabel | Ja – kolonneoverskriften følger med og giver konteksten | Høj: rækken giver mening selv uden teksten omkring tabellen. |
Tabeller, lister og definitioner: formerne der overlever hentningen
Løbende prosa er ikke forkert i sig selv, men den skjuler ofte flere separate påstande bag samme afsnit uden nogen synlig grænse mellem dem. Strukturerede former undgår det problem, fordi grænsen er indbygget i selve formatet. En definition (»X er Y«) er per konstruktion én selvstændig påstand. Et punkt i en liste under en præcis overskrift er afgrænset af selve listeformatet. En tabelrække tager kolonneoverskriften med som kontekst, uanset hvor i teksten den citeres fra.
Det betyder ikke, at hele siden bør skrives som lister og tabeller – det ville være lige så ulæseligt som en side fuld af »vi«. Det betyder, at hvor du står med et valg mellem at vikle en påstand ind i et langt afsnit eller give den sin egen, tydelige form, er den tydelige form næsten altid det sikrere valg for, hvordan indholdet overlever at blive hentet ud alene.
Én side, ét spørgsmål slår én side, ti spørgsmål
En side, der forsøger at dække ti beslægtede spørgsmål på én gang, spreder nødvendigvis signalet for hvert enkelt spørgsmål tyndere. Chunken, der til sidst hentes for spørgsmål nummer syv, konkurrerer da mod en dedikeret side, der ikke gør andet end at svare grundigt på netop det spørgsmål. Den dedikerede side vinder oftere, ikke fordi den er »bedre skrevet« i en generel forstand, men fordi hver eneste chunk på den er skrevet med kun ét formål for øje.
Praktisk konsekvens: når en side vokser til at dække stadig flere delspørgsmål, er det værd at overveje, om nogle af dem hellere fortjener deres egen, smallere side – ikke for at oppuste sidetallet, men fordi en smallere side producerer skarpere, mere citerbare chunks for netop det spørgsmål.
Hvor dette møder det, du allerede måler
Hvor godt en given side reelt præsterer i AI-citeringer, ikke kun i teorien, er noget af det, CAVIS-rammeværket fra CitationLab er bygget til at måle over tid – på tværs af modeller, ikke bare som et øjebliksbillede. Chunk-struktur er én af flere strukturelle faktorer, der spiller ind i det billede, ved siden af entitetsklarhed og tekniske forhold, som resten af denne serie har dækket.
Selvtjek: sæt ét tilfældigt afsnit ind alene
Selvtjek. Åbn en vilkårlig side på dit website, og kopiér ét tilfældigt afsnit ud – ikke det første, ikke det du er mest stolt af, men et helt almindeligt afsnit et sted i midten. Sæt det ind alene i et nyt dokument, uden overskriften over det og uden afsnittet før eller efter.
Giver det stadig mening? Ved en læser, der aldrig har set resten af siden, hvad teksten reelt handler om, og hvem den handler om? Hvis svaret er nej, er der formentlig ikke noget galt med indholdet – kun med hvor selvstændigt det er skrevet til at stå. Og en chunk, der ikke giver mening alene, bliver ikke citeret alene.
Ofte stillede spørgsmål
Hvad er en »chunk« i AI-søgning?
Hvor stor er en typisk chunk?
Betyder det, at jeg bør gøre mine afsnit kortere?
Hvordan hænger det sammen med næste del i serien, om at droppe »vi«?
Var dette nyttigt?
