Instruction Following

Instruction Following er den mest direkte form for prompting. Du beskriver opgaven som en række imperative kommandoer med målbare krav: præcis tre punkter, maksimalt 15 ord per punkt, ingen tekniske termer. Modellen får ingen eksempler at efterligne og ingen forklaring af, hvorfor kravene er som de er.

Forskellen til zero-shot er snæver, men reel. Zero-shot beskriver typisk opgaven ('resumér denne tekst'), mens Instruction Following specificerer outputtets form ned til tællelige enheder. Zero-shot spørger hvad, Instruction Following bestemmer også hvordan.

Forskellen til few-shot er tydeligere. Few-shot demonstrerer formatet gennem to eller tre færdige eksempler og lader modellen udlede reglen. Instruction Following skriver reglen ud og springer demonstrationen over. Det gør prompten kortere og billigere i tokens, men også mere sårbar over for tvetydig formulering.

System-prompts er ikke en konkurrerende teknik, men et andet sted at placere de samme instruktioner. Regler der gælder på tværs af alle kald, hører hjemme i system-prompten. Regler der gælder den enkelte opgave, hører hjemme i brugerprompten.

Instruktioner virker, fordi de indsnævrer fordelingen over mulige fortsættelser. Uden formatkrav er der tusindvis af plausible resumeer af en tekst, og modellen sampler fra en bred fordeling. Med kravet om præcis tre punkter og en øvre ordgrænse falder sandsynlighedsmassen sammen om en langt mindre gruppe outputs.

Instruction tuning er en direkte årsag. Modellerne er efterfølgende trænet på par af instruktion og ønsket svar, hvor overholdelse af eksplicitte krav blev belønnet. Formuleringer som 'skriv', 'brug ikke' og 'maksimalt' er stærkt repræsenteret i det træningsmateriale og er derfor pålidelige signaler.

Placering betyder noget for genereringen. Instruktioner der står før input-teksten, ligger i konteksten under hele produktionen af svaret, og hver ny token betinges på dem. Står kravene efter en lang tekst, er de stadig i context window, men konkurrerer med mere materiale om opmærksomheden.

Negative instruktioner fungerer dårligere end positive. 'Brug ikke tekniske termer' kræver at modellen både genererer og filtrerer. 'Brug hverdagssprog som en gymnasieelev forstår' peger direkte på den ønskede fordeling.

Præcise talkrav er den klassiske fejlkilde. Modeller tæller ikke ord og tegn pålideligt, fordi tokenisering ikke følger ordgrænser. Krav som 'præcis 15 ord' eller 'maksimalt 280 tegn' overholdes ofte tilnærmelsesvis. Skal grænsen holde, må du validere i kode bagefter, ikke stole på instruktionen.

Mange samtidige regler nedbryder overholdelsen. Ved otte til ti krav i samme prompt begynder de svageste at falde ud, typisk de negative og de mest specifikke. Claude Haiku 4.5 og GPT-5 nano rammer den grænse tidligere end Claude Opus 5 og Gemini 3.1 Pro.

Modsatrettede instruktioner giver falsk tryghed. Beder du om både udtømmende dækning og maksimalt 50 ord, ser prompten stram ud, men modellen må prioritere selv, og valget er ikke stabilt mellem kald.

Når kravet er svært at beskrive i ord, er teknikken det forkerte valg. En bestemt tone, en fast JSON-struktur med kantede detaljer eller et sært tabelformat forklares langsommere end det demonstreres. Der er few-shot både kortere og mere præcist.

Reasoning-modeller ændrer ikke meget her. Instruction Following handler om outputtets form, ikke om opgavens vanskelighed, og ekstra tænketid gør ikke en model bedre til at tælle ord. Claude Opus 5 og Gemini 3.1 Pro håndterer flere samtidige regler end tidligere generationer, men fejlmønstret er det samme.

En reel forandring er structured outputs og tool use. Skal svaret være gyldig JSON efter et bestemt skema, er constrained decoding mere pålideligt end en instruktion om det. Formatkravet håndhæves da under selve genereringen i stedet for at være en anmodning i prompten.

Instruktionerne er stadig nødvendige for indholdet. Skemaet sikrer at feltet findes, ikke at det er udfyldt fornuftigt.