Prompt engineering: komplet guide

Prompt engineering handler om systematisk forbedring

Prompt engineering bliver først værdifuldt, når det behandles som design af en arbejdsproces: du opstiller en opgave, tester den på flere cases, måler fejl og ændrer én ting ad gangen.

Fra første udkast til en testbar prompt

Arbejd i iterationer med faste eval-kriterier

1. 1. Definér opgaven og den fejltype, der er dyrest.
2. 2. Lav et lille repræsentativt testsæt før du finjusterer prompten.
3. 3. Design input- og outputskema, så resultater kan sammenlignes.
4. 4. Tilføj eksempler dér hvor kategorier eller grænser er svære at forklare abstrakt.
5. 5. Kør testen, noter fejltyper og ændr kun én variabel ad gangen.
6. 6. Gem promptversion, testresultat og kendte begrænsninger.

Undgå prompt-teater og overdesign

• At vurdere prompten ud fra ét flot eksempel.
• At skifte model, prompt, temperature og input samtidig og derfor ikke vide hvad der forbedrede resultatet.
• At måle “lyder godt” i stedet for korrekthed, komplethed eller faktisk arbejdsbesparelse.

Lav et lille eval-sæt

Vælg en gentagen opgave og lav 10 realistiske inputcases. Skriv på forhånd, hvad der tæller som godkendt output, før du tester AI.

Mål stabilitet – ikke kun det bedste svar

• Har du cases der også repræsenterer fejl og særlige grænsetilfælde?
• Kan output valideres manuelt eller maskinelt?
• Er promptversionen dokumenteret?

Behandl prompten som en versioneret del af systemet

Når en prompt bruges gentagne gange i et team eller workflow, bør ændringer kunne forklares. Gem version, testcases og den fejl du forsøgte at rette. Ellers ender “forbedringer” let med at løse én case og ødelægge tre andre.

Et lille eval-sæt på 10–20 realistiske input er ofte mere værd end endnu en promptteknik. Kategorisér fejlene: manglende fakta, forkert format, overfortolkning, uønsket tone, ustabil klassifikation eller dårligt kildegrundlag. Ret derefter den del af systemet, der faktisk skaber fejlen. Nogle gange er løsningen bedre retrieval eller validering – ikke en ny sætning i prompten.

Prompt engineering bliver dermed mindre “ordmagi” og mere almindelig produktudvikling: hypotese, ændring, test, regression og dokumentation.

Fortsæt med chaining, few-shot og evaluering

• Sådan tester og forbedrer du prompts
• Few-shot prompting med eksempler
• Structured output

Lav en baseline, før du begynder at optimere

Gem den første simple prompt og kør den på det samme testsæt som senere versioner. Ellers kan du ikke vide, om en mere avanceret prompt faktisk er bedre. Mål eksempelvis korrekt klassifikation, manglende felter, faktuelle fejl og den tid en medarbejder bruger på at rette outputtet.

En baseline er også et værn mod overengineering. Hvis en kort instruktion allerede løser 96 procent af jeres cases, er et langt agentsetup måske ikke en forbedring.

Evaluer forskellige fejl med forskellige metoder

Nogle fejl kan testes maskinelt: gyldig JSON, obligatoriske felter, tilladte kategorier eller om et bestemt id findes. Andre kræver faglig bedømmelse: om argumentet er dækkende, om kilden virkelig støtter påstanden, eller om anbefalingen er brugbar.

Byg derfor et eval-ark med både hard checks og menneskelige kriterier. Giv alvorlige fejl – eksempelvis en opfundet pris eller en uautoriseret handling – deres egen hard-fail status i stedet for at skjule dem i et gennemsnit.

Prompt engineering stopper ofte uden for prompten

Hvis modellen mangler de rigtige dokumenter, er retrieval problemet. Hvis en kategori er tvetydig, er datamodellen problemet. Hvis et skriveværktøj tillader for brede handlinger, er værktøj-designet problemet. Den modne disciplin er derfor prompt + kontekst + modelvalg + værktøjer + validering + evaluering.