Automatic Prompt Engineering (APE)

APE gør prompt-formulering til et søgeproblem. En model genererer et antal kandidat-prompts til samme opgave, hver kandidat køres mod et sæt test cases med kendte svar, og resultaterne scores efter en metrik du har defineret på forhånd. Den bedst scorende prompt går videre, enten til produktion eller til en ny runde hvor den bruges som udgangspunkt for nye varianter.

Forskellen til meta-prompting er målingen. Meta-prompting beder en model om at skrive eller forbedre en prompt, og du vurderer selv resultatet. APE tilføjer en evalueringsløkke, så udvælgelsen sker på tal fra et datasæt og ikke på din læsning af, hvilken formulering der ser bedst ud.

Forskellen til few-shot og self-consistency ligger et andet sted. Few-shot ændrer indholdet i én prompt ved at tilføje eksempler, og self-consistency varierer output ved at sample flere gange på samme prompt. APE varierer selve prompten og holder alt andet fast. De tre kan kombineres: antallet og udvalget af few-shot-eksempler kan sagtens være en af de parametre APE søger over.

En prompt er betingelse for en sandsynlighedsfordeling over tokens. Ordvalg, rækkefølge og outputformat flytter den fordeling, og flytningerne er ikke små. Forskellen mellem at bede om fritekst og at bede om JA/NEJ/USIKKER ændrer både hvilke tokens der er sandsynlige, og hvor let svaret kan parses maskinelt uden fejl.

De flytninger kan ikke forudsiges analytisk. Hvilken formulering der rammer bedst på netop din opgavefordeling afhænger af træningsdata, af hvordan opgaven ligner mønstre modellen har set, og af hvor tvetydige dine grænsetilfælde er. Introspektion over prompten giver ikke svaret, men måling gør.

Generator-delen behøver ikke at ramme rigtigt. Den skal producere spredning i formuleringsrummet, herunder varianter et menneske ville have kasseret på forhånd. Selektionen sker i evalueringen, og det er dér gevinsten kommer fra. Systemet er en simpel søgning med tilfældig variation og en scoringsfunktion, ikke en forståelse af opgaven.

Med for få test cases måler du støj. Eksemplet ovenfor med 10 eksempler er en illustration, ikke en anbefaling: forskellen mellem 92 % og 95 % er dér ét enkelt eksempel, og rangordenen kan vende ved næste stikprøve. Under omkring 50 eksempler bør du behandle forskelle på få procentpoint som ikke-eksisterende.

Teknikken kræver et facit. På opgaver uden objektiv korrekthed, som brainstorming, rådgivning eller redaktionel tekst, må scoringen enten laves af en anden model eller af mennesker. En model-dommer indfører sine egne præferencer, og du risikerer at optimere mod dommerens smag frem for mod brugsværdi.

Er flaskehalsen manglende information, hjælper ingen formulering. Hvis modellen mangler kontekst, produktdata eller domæneregler, er RAG eller fine-tuning det rigtige greb, og APE giver kun falsk tryghed i form af et pænt tal på et datasæt der ikke rammer problemet.

Gevinsten er desuden mindre på nyere reasoning-modeller. Claude Opus 5 og Gemini 3.1 Pro leverer mere ensartet på tværs af formuleringer, hvor ældre modeller kunne svinge kraftigt. Effekten er stadig tydelig på mindre og hurtigere modeller som GPT-5 nano og Gemini 3.7 Flash, hvor prompt-formatet betyder mere for præcisionen.

Kandidater og evaluering behøver ikke køre på samme model. Det giver ofte mening at generere varianter med en stor model og evaluere dem på den model der faktisk skal i drift, typisk en billigere som Claude Haiku 4.5 eller GPT-5 nano.

En optimeret prompt er bundet til den model og version den blev målt på. Skifter du til GPT-5.6 Sol eller opgraderer inden for samme familie, gælder resultaterne ikke længere med sikkerhed. Regn evalueringen som noget der skal køres igen ved hvert modelskift, og planlæg omkostningen derefter.