Indledning: Hvorfor fejler prompts i virkeligheden?

Lad os være ærlige. De fleste guides til prompt engineering lyder lidt ens: “Vær mere specifik.” “Giv flere eksempler.” “Brug chain of thought.” Det lyder smart, men når du sidder med et rigtigt system – et der skal håndtere rodede data, krav om dokumentation og brugere, der ikke tilgiver fejl – så falder det hele ofte fra hinanden. Vi har set det hos Snilld, både i vores egne eksperimenter og hos kunder, der troede de var i mål, fordi deres prompt virkede på et par testeksempler. Men virkeligheden er sjældent så pæn. Artiklen her handler ikke om at skrive endnu smartere prompts, men om at tænke systematisk og bygge robusthed ind fra starten. Ikke hype – bare det, der virker, når det gælder.

Virkelighedens krav: Produktion, nøjagtighed og sporbarhed

Det interessante er, at kravene til AI-systemer i det offentlige og i store virksomheder er langt skrappere end de fleste tror. Det er ikke nok, at modellen gætter rigtigt 95% af tiden, hvis de sidste 5% betyder fejl i sagsbehandling eller tabte borgerrettigheder. Vi har set det konkret i et OCR-projekt, hvor en lille fejl i prompten betød, at elever mistede karakterer. Det var ikke modellen, der var dårlig – det var prompten, der ikke holdt til virkelighedens rod. I sagsbehandling skal du kunne dokumentere, hvorfor en beslutning blev truffet. I borgerrettede løsninger skal du kunne forklare, hvad der skete, hvis nogen klager. Det kræver sporbarhed og nøjagtighed, ikke bare “smarte” prompts.

De ti teknikker – kort oversigt

Her er de ti teknikker, der faktisk gør en forskel i praksis:

• Arithmetic Validation (validering med matematik)
• Algorithmic Protocols (mekaniske, trin-for-trin instruktioner)
• Granular Documentation (tving modellen til at dokumentere, hvad den har gjort)
• Chain of Thought (synliggør ræsonnementet)
• Tree of Thoughts (flere løsningsveje før valg)
• ReAct (skiftevis ræsonnement og handling)
• Self-Consistency (flere uafhængige løsninger, vælg den bedste)
• Meta-Prompting (lad modellen designe sine egne prompts)
• Zero-Shot vs Few-Shot (hvornår eksempler hjælper – og hvornår de skader)
• Prompting Reasoning Models (hvordan man arbejder med avancerede modeller som O1 og O3)

For Snillds målgruppe er især Arithmetic Validation, Granular Documentation og Algorithmic Protocols relevante – de løser de problemer, vi ser igen og igen i produktion.

Teknikker i praksis – cases og kode

Tag Arithmetic Validation. Vi havde en kunde, hvor et budget skulle splittes op på flere afdelinger. Modellen fordelte pengene, men tjekkede ikke, om summen passede. Efter vi tilføjede et valideringstrin – “Tjek, at alle beløb summerer til det samlede budget” – faldt fejlene drastisk. Kodeeksempel (Python, pseudokode):

if sum(afdelingsbudgetter) != totalbudget:
    raise ValueError("Budget stemmer ikke!")

Algorithmic Protocols er en anden klassiker. I stedet for at skrive “find relevante dokumenter”, så lav en trin-for-trin-protokol: 1) Identificér dokumenttype, 2) Tjek dato, 3) Udeluk dubletter, 4) Gem resultat. Det lyder banalt, men det gør output langt mere stabilt – og nemmere at debugge, når noget går galt.

Granular Documentation: Vi så en model, der påstod at have læst alle sider i en PDF, men havde sprunget side 5 over. Løsningen var at tvinge modellen til at dokumentere, hvad den havde fundet på hver side. Det afslørede fejlene med det samme. Det er lidt som at bede en praktikant om at skrive logbog – du kan se, hvor de har været, og hvor de har sjusket.

Integration og systemdesign

Nu bliver det lidt mere teknisk. Hvordan får man prompt engineering til at spille sammen med resten af systemet? Vi har oplevet, at det hjælper at tænke i moduler: ét modul til prompten, ét til validering, ét til logging. Diagrammer kan være overkill, men forestil dig en pipeline, hvor data ryger igennem: Input → Prompt → Output → Validering → Logging → Bruger. Hver teknik får sit eget trin. Det gør det nemmere at udskifte eller forbedre dele uden at vælte hele systemet.

I større ML-pipelines kan du indlejre valideringstrin direkte i workflowet. Fx i en Airflow DAG: Først kører prompten, så valideres output, og først derefter sendes data videre. Det lyder måske lidt tørt, men det er her, robustheden opstår.

Dokumentation, forklaring og brugeroplevelse

Det her er måske lidt niche, men vi har set flere gange, at dokumentation ikke kun er for udviklere. Når en ikke-teknisk kollega spørger “hvorfor sagde modellen nej?”, skal du kunne vise, hvordan beslutningen blev truffet. Det kan være en logfil, en rapport eller bare et letforståeligt output, hvor hvert trin er forklaret. Vi har brugt simple tabeller: “Input: x, Regel: y, Output: z”. Det gør det også nemmere at teste output – hvis du kan følge beslutningsvejen, kan du også spotte, hvor det gik galt.

Brugeroplevelsen bliver bedre, når fejl ikke bare er “ukendt fejl”, men “beløbet stemmer ikke – tjek afdeling C”. Det er småting, men det gør en kæmpe forskel for tilliden til systemet.

Robusthed, vedligehold og læring af fejl

Robusthed kommer ikke af sig selv. Vi har oplevet, at det vigtigste er at lære af fejlene – og at gøre det nemt at rette dem. Hvis du kan se, præcis hvor prompten fejlede, kan du hurtigt justere. Vi har fx haft et system, hvor en enkelt ændring i prompten fjernede 80% af fejlene. Men det kræver, at du logger alt og tester på virkelige data, ikke kun på “pæne” eksempler.

Vedligehold handler også om at opdatere prompts, når kravene ændrer sig. Det er fristende at lade dem være, når de virker, men virkeligheden ændrer sig. Vi har set, at de bedste systemer har faste rutiner for at gennemgå og opdatere prompts – lidt som at opdatere software.

Afslutning: Hvad kan du tage med dig?

Hvis du kun tager én ting med: Tænk systemisk. En god prompt er ikke nok – det er hele kæden fra input til validering, dokumentation og brugerfeedback, der afgør, om dit system holder i virkeligheden. Prøv teknikkerne af i små bidder. Eksperimentér. Og vær ikke bange for at fejle – bare sørg for, at du kan se, hvor det gik galt. Vi kommer til at dykke endnu dybere ned i praksis og teknik i kommende artikler. Indtil da: Byg systemer, der kan tåle virkeligheden. Man opdager først forskellen, når man sidder med det i hænderne.

Kilder:

• https://towardsai.net/p/machine-learning/how-to-think-like-a-prompt-engineer-not-just-write-better-prompts-m007
• https://towardsai.net/
• https://www.reddit.com/r/computervision/comments/1ctf0jh/2024_review_of_ocr_tools_extracting_text_from/
• https://www.promptingguide.ai/techniques/tot
• https://www.promptingguide.ai/techniques/react

Målgruppens mening om artiklen

Anders, IT-chef i kommune:
Jeg giver artiklen 92. Den rammer virkelig plet i forhold til de udfordringer, vi sidder med, især omkring krav til dokumentation og sporbarhed. Eksemplerne er relevante, og jeg kan genkende problemstillingerne fra vores egne AI-projekter. Jeg savner måske lidt mere om, hvordan man håndterer legacy-systemer, men ellers er det spot on.

Maria, digitaliseringskonsulent i region:
Jeg giver den 85. Jeg synes, artiklen er praktisk og konkret, og jeg kan bruge flere af teknikkerne direkte. Det er fedt, at der ikke bare er hype, men reelle erfaringer fra produktion. Den kunne dog godt have haft lidt mere fokus på samarbejdet mellem teknik og forretning.

Jens, AI-udvikler i større privat virksomhed:
Jeg giver den 95. Artiklen er superrelevant og rammer præcis de problemer, vi støder på, når vi skal operationalisere AI. Eksemplerne med validering og granular documentation er virkelig brugbare. Jeg ville ønske, der var endnu flere kodeeksempler, men ellers er det noget af det bedste, jeg har læst om emnet.

Louise, projektleder i offentlig digitalisering:
Jeg giver den 78. Jeg synes, artiklen er god og praktisk, men den bliver lidt teknisk i nogle afsnit, hvor jeg mister overblikket. Til gengæld er pointerne om dokumentation og brugeroplevelse vigtige og relevante for mit arbejde.

Thomas, compliance-ansvarlig i finanssektoren:
Jeg giver den 88. Artiklen adresserer de centrale krav om sporbarhed og robusthed, som vi kæmper med dagligt. Jeg kunne godt have brugt lidt mere om governance og risikostyring, men det er klart en af de bedre artikler om AI i praksis.

Gennemsnitlig score: 88

Begrundelse: Artiklen får en høj score, fordi den er praksisnær, ærlig og adresserer de reelle udfordringer, målgruppen oplever med AI og prompt engineering i produktion. Den balancerer tekniske detaljer med konkrete cases og peger på løsninger, der kan implementeres direkte. Enkelte savner dog lidt mere fokus på samarbejde, governance eller flere eksempler, hvilket trækker lidt ned, men samlet set er relevansen meget høj.

*Denne artiklen er skrevet af en redaktion bestående af kunstig intelligenser, der har skrevet artiklen på baggrund af automatiseret research og oplysninger om de seneste teknologi nyheder fra internettet.

Billederne i artiklen er lavet af Gemini 3 Pro Nano Banana 2 Pro fra Google.