Hvad er prompt engineering?

Prompt engineering er håndværket at formulere instruktioner så en sprogmodel giver pålidelige og brugbare svar. Ordet lyder teknisk, men kernen er enkel: Den samme model giver vidt forskellige svar afhængigt af hvordan du spørger, og prompt engineering handler om at spørge på en måde der konsekvent giver dig det du har brug for. Her er det grundlæggende på cirka et minut.

Dårlig kontra god prompt

Den hurtigste måde at forstå værdien på er at sammenligne to prompts til den samme opgave.

Dårlig prompt: “Skriv om vores produkt.”

Modellen ved ikke hvem den skal skrive som, til hvem, hvor langt det skal være eller i hvilken tone. Resultatet bliver generisk og skal ofte laves om.

God prompt: “Du er produkttekstforfatter. Skriv en sælgende, men saglig produktbeskrivelse på cirka 80 ord om vores bogføringstjeneste, rettet mod ejere af små virksomheder der synes at økonomi er besværlig. Undgå teknisk jargon.”

Samme model, men nu kender den sin rolle, sin målgruppe, sin længde og sin tone. Svaret kan bruges med det samme. Forskellen i udfaldet er ikke lille, og den skyldes udelukkende formuleringen, ikke modellen.

De tre byggesten

Næsten alle gode prompts indeholder de samme tre dele. Hvis du kun husker én ting fra denne side, så lad det være denne tabel:

• Rolle sætter perspektivet. “Du er jurist” og “du er sælger” giver forskellige svar på det samme spørgsmål.
• Kontekst giver modellen det den har brug for at vide: baggrund, målgruppe, eventuelt materiale at tage udgangspunkt i.
• Format styrer udseendet: en punktopstilling, 80 ord, en tabel, en bestemt tone.

Får modellen alle tre, rammer den mærkbart mere præcist. Mangler de, gætter den, og gæt bliver sjældent det du ville have.

Skal man kunne kode?

Nej. At skrive gode prompts handler om at udtrykke sig klart og struktureret, og det kan alle øve sig i. Du behøver ikke være udvikler for at mærke at en gennemtænkt instruktion giver bedre svar end en sjusket.

Det der kræver teknisk kompetence, er næste skridt: at bygge prompts ind i et produktionssystem hvor de køres automatisk tusindvis af gange. Men selve håndværket at formulere instruktioner er tilgængeligt for alle der arbejder med sprog og vil have mere ud af deres AI-værktøjer.

Almindelige faldgruber

Selv de der forstår det grundlæggende, falder i de samme fælder. De mest almindelige:

• For vage instruktioner. “Gør det bedre” siger intet om hvad “bedre” betyder. Angiv hellere præcis hvad der skal ændres og hvordan resultatet skal se ud.
• For meget på én gang. En prompt der beder om ti ting på samme tid, giver ofte et svar der gør alle ti halvgodt. Del opgaven op, eller prioritér tydeligt.
• Ingen afgrænsning. Uden en grænse (“svar kun ud fra teksten nedenfor, find ikke på noget”) udfylder modellen gerne hullerne med kvalificerede gæt. Ved faktafølsomme opgaver er det en risiko.
• At antage at modellen husker. En model kender ikke jeres interne kontekst medmindre I giver den den. Det der er indlysende for jer, er usynligt for den.

Et andet eksempel gør pointen konkret. “Opsummer dette møde” giver en generisk opsummering. “Opsummer mødereferatet nedenfor i tre punkter: beslutninger, åbne spørgsmål og næste skridt. Skriv intet der ikke står i teksten.” giver noget I kan bruge med det samme, og den sidste sætning mindsker risikoen for at modellen tilføjer ting der aldrig blev sagt.

Hvorfor det betyder noget for en køber

For en virksomhed er prompt engineering ikke en kuriositet, men det der afgør om en AI-løsning bliver pålidelig nok til at man kan stole på den. Om det er en chatbot over for kunderne, et værktøj der opsummerer kontrakter, eller et flow der klassificerer henvendelser, står og falder løsningen med hvor godt prompts er skrevet og testet. Forskellen mellem en løsning der imponerer i en demo, og en der holder i den daglige drift, ligger ofte her.

Der er også en databeskyttelsesvinkel der er værd at nævne: En gennemtænkt prompt kan instruere modellen i ikke at bede om eller gentage følsomme oplysninger unødigt. Prompten er altså ikke kun et kvalitetsværktøj, men en del af hvordan I styrer hvad der sendes til og kommer tilbage fra en ekstern model.

Hvorfor prompts versionsstyres som kode

Når en prompt går fra at være noget du skriver i hånden, til at være en fast del af et system, ændrer kravene sig. I et produktionssystem er prompten en del af logikken (den afgør hvad tjenesten faktisk gør), præcis som kode.

Og fordi en lille ændring i formuleringen kan ændre resultatet mærkbart, skal prompts spores på samme måde som kode: hvad blev ændret, hvornår og hvorfor. Så kan man teste en ny version kontrolleret, måle om svarene blev bedre eller dårligere, og gå tilbage til den forrige hvis ændringen forringede noget. At ændre en prompt i produktion uden sporbarhed er lige så risikabelt som at ændre kode uden versionsstyring.

At bygge systemer hvor prompts er gennemtænkte, testede og sporbare, er en del af at gøre AI pålidelig i drift. Vil du vide hvordan vi arbejder med det, kan du læse mere om vores AI-ydelser eller kontakte os med en beskrivelse af hvad I vil have modellen til at gøre.