De mest almindelige fejl i instruktionsdesign er uklare mål, for lidt kontekst, manglende test og svage sikkerhedsgrænser. Gode AI-svar kræver ikke kun en bedre formulering, men også klare kriterier, realistiske eksempler, outputkontrol og løbende evaluering.
De største fejl i instruktionsdesign opstår, når mål, kontekst, test og sikkerhedsgrænser er uklare. Overblikket viser, hvordan bedre krav, realistiske eksempler, outputkontrol og gentestning kan gøre AI-svar mere brugbare, mere stabile og lettere at styre.
Hvad er den mest almindelige fejl i instruktionsdesign?
Den mest almindelige fejl er at bede AI-systemet om noget bredt uden at definere, hvad et brugbart svar er. Når opgaven, målgruppen, formatet og afgrænsningen mangler, må modellen selv gætte. Det kan give et svar, der lyder rigtigt, men ikke passer til den konkrete arbejdssituation.
Instruktionsdesign handler derfor ikke kun om at skrive pænere sætninger. Det handler om at omsætte en opgave til klare krav: Hvad skal løses, hvilket materiale må bruges, hvordan skal svaret struktureres, og hvornår skal modellen markere usikkerhed?
En god formulering kan stadig fejle, hvis den bliver brugt til en opgave, hvor datagrundlaget er svagt eller risikoen er høj. Derfor bør instruktionen ses som én del af en samlet AI-arbejdsgang, ikke som en trylleformular.
Hvorfor giver uklare mål svage AI-svar?
Uklare mål skaber svage svar, fordi modellen ikke kan vide, hvilken kvalitet du prioriterer. Skal svaret være kort, nuanceret, handlingsrettet, dokumenteret, kreativt eller begrænset til et bestemt datasæt? Hvis det ikke står tydeligt, kan modellen vælge en retning, der ikke passer til behovet.
Et mål som “skriv noget bedre” er svært at evaluere. Et mål som “lav en intern opsummering på højst 120 ord med beslutninger, åbne spørgsmål og næste handlinger” er lettere at kontrollere. Jo mere præcis opgaven er, desto mindre plads er der til tilfældig fortolkning.
Det betyder ikke, at alle instruktioner skal være lange. Ofte er en kort, præcis opgave bedre end en lang tekst med mange uklare ønsker. Længde hjælper kun, hvis den tilføjer relevant kontekst, klare krav eller nyttige eksempler.
Hvordan skader for mange opgaver i samme instruktion?
En anden typisk fejl er at lægge for mange krav ind i samme besked. Modellen skal måske analysere, opsummere, omskrive, vurdere tone, udtrække data, lave en tabel og foreslå handlinger på én gang. Det øger risikoen for, at enkelte krav bliver overset.
Komplekse opgaver bliver ofte bedre, når de opdeles i trin. Først kan modellen udtrække fakta, derefter organisere dem, og til sidst kan den skrive svaret i det ønskede format. Trinvis arbejde gør det lettere at opdage, hvor fejlen opstår.
Opdeling er især nyttig, når resultatet skal bruges videre i en proces. Hvis et output skal ind i et regneark, et CRM-system eller et internt dokument, bør datatræk, fortolkning og formulering ikke blandes unødigt sammen.
Hvornår mangler modellen nødvendig kontekst?
Modellen mangler kontekst, når den ikke får de oplysninger, der er nødvendige for at løse opgaven på den måde, du forventer. Det kan være målgruppe, tone, datakilde, definitioner, begrænsninger, interne retningslinjer eller eksempler på tidligere godkendte svar.
Hvis du beder om en vurdering uden at give vurderingskriterier, vil modellen ofte bruge generelle mønstre fra træning og samtale. Det kan være nyttigt i en åben idefase, men det er svagt i en kontrolleret arbejdsproces.
For en løsning med egne dokumenter er kontekstspørgsmålet tæt forbundet med retrieval, datakvalitet og kildeafgrænsning. Det gælder for eksempel, når du vil arbejde med grounding af AI-modeller, hvor svaret bør kunne spores til det relevante materiale.
Hvorfor er outputformatet mere end pynt?
Outputformatet afgør, om svaret kan bruges direkte. Hvis modellen skal levere kategorier, felter, tjekpunkter eller data til et andet system, er løst formuleret prosa ofte ikke nok. Formatkrav skal være tydelige, og de bør testes.
OpenAI dokumenterer strukturerede output som en måde at styre svar mod bestemte skemaer i API-arbejdsgange. Pointen er bredere end én platform: Når output skal behandles maskinelt eller sammenlignes systematisk, bør strukturen være en del af opgaven fra starten.
En fejl er at bede om et bestemt format, men ikke definere, hvad der skal ske ved manglende data. Skal feltet være tomt, skal modellen skrive “ukendt”, eller skal den stille et opklarende spørgsmål? Hvis det ikke er afklaret, opstår der hurtigt uens svar.
Hvilken rolle spiller eksempler og mod-eksempler?
Eksempler hjælper modellen med at se mønstre, især når opgaven har en bestemt tone, kategori eller struktur. Men eksempler kan også vildlede. Hvis alle eksempler ligner hinanden, kan modellen tro, at opgaven er snævrere, end den faktisk er.
Derfor bør du bruge forskellige eksempler, når opgaven skal fungere i mange situationer. Medtag korte og lange input, almindelige og vanskelige sager samt situationer, hvor modellen skal svare forsigtigt. Mod-eksempler kan vise, hvad svaret ikke må gøre.
- Gode eksempler viser ønsket struktur og beslutningsregel.
- Mod-eksempler viser fejl, som modellen skal undgå.
- Kanttilfælde viser, hvor opgaven skifter karakter.
- Negative eksempler viser, hvornår modellen bør afvise eller spørge opklarende.
Eksempler bør opdateres, når opgaven ændrer sig. Et gammelt eksempel kan fastholde en stil eller regel, som ikke længere passer til den faktiske brug.
Hvordan opstår uønsket selvsikkerhed?
Uønsket selvsikkerhed opstår, når modellen giver et bestemt svar uden nok grundlag. Det kan ske, hvis instruktionen belønner hurtige konklusioner, hvis opgaven mangler kilder, eller hvis brugeren ikke har bedt modellen markere usikkerhed og antagelser.
En god instruktion bør beskrive, hvordan usikkerhed håndteres. Modellen kan for eksempel blive bedt om at skelne mellem dokumenterede oplysninger, rimelige fortolkninger og manglende grundlag. Det er især relevant ved tekniske, økonomiske, sundhedsfaglige eller reguleringsnære emner.
Uønsket selvsikkerhed kan ikke fjernes med formulering alene. Den bør også håndteres gennem kilder, test, menneskelig gennemgang og klare stopregler. OWASP placerer ukritisk afhængighed af LLM-output blandt de væsentlige risici for LLM-applikationer.
Hvilke sikkerhedsfejl overses ofte?
En overset sikkerhedsfejl er at antage, at en instruktion i sig selv beskytter systemet. Brugere, eksterne dokumenter og værktøjskald kan påvirke en AI-applikation på uventede måder. Derfor skal sikkerhed bygges ind i arkitektur, rettigheder, datagrænser og outputhåndtering.
OWASP Top 10 for LLM Applications 2025 peger blandt andet på uønsket inputmanipulation, følsomme oplysninger, utilstrækkelig outputhåndtering og overdreven handlefrihed som centrale risikoområder. Det er relevante fejl at tænke ind, også når opgaven virker sproglig og ufarlig.
Hvis modellen kan kalde værktøjer, sende beskeder, opdatere systemer eller hente data, bør instruktionen suppleres med adgangskontrol og tekniske begrænsninger. Læs også om beskyttelse mod AI-system-hacking og forebyggelse af datalækager i AI-applikationer, hvis løsningen bruger interne eller følsomme data.
Hvorfor er test med egne data nødvendigt?
Generelle eksempler kan vise, om en formulering fungerer i princippet. De viser ikke nødvendigvis, om den fungerer med dine dokumenter, kunder, produkter, interne begreber eller fejltyper. Test med egne data er derfor nødvendig, når AI-svaret skal bruges i en konkret arbejdsproces.
OpenAI beskriver evalueringsarbejde med testdata og bedømmelseskriterier. Den disciplin gør det lettere at se, om en ændring faktisk forbedrer resultatet. Det minder om A/B-testning med AI, men skal også dække sikkerhed, format og fejltyper.
Test med egne data bør dog ske med omtanke. Brug anonymiserede eller syntetiske eksempler, når det er tilstrækkeligt, og hold følsomme oplysninger ude af unødige testmiljøer. Hvis datafortrolighed er en central del af løsningen, bør den vurderes sammen med generativ AI og datafortrolighed.
Hvordan undgår du at låse en dårlig formulering fast?
Dårlige formuleringer låses fast, når de bliver kopieret ind i skabeloner uden løbende måling. Det kan ske, fordi en instruktion virkede godt i en demonstration, eller fordi ingen har ansvar for at opdatere den. Over tid kan opgaven, modellen og datagrundlaget ændre sig.
Undgå det ved at gemme versioner og begrundelser. Notér, hvad der blev ændret, hvilke fejl der skulle løses, hvilke tests der blev kørt, og hvad resultatet blev. Så kan teamet se, om en ændring var en reel forbedring eller bare en sproglig justering.
Det er også nyttigt at have en lille fast testpakke, som køres ved større ændringer. Testpakken bør indeholde typiske sager, kanttilfælde og eksempler på uønsket adfærd. Når den holdes stabil, kan resultater sammenlignes over tid.
Hvilke fejl betyder mest i organisationer?
I organisationer er de vigtigste fejl ofte dem, der påvirker ansvar og gentagelighed. En instruktion kan virke for én medarbejder, men fejle, når den bruges af mange personer med forskellige input. Derfor skal sprog, data, rettigheder og kvalitetssikring hænge sammen.
Fejl med størst praktisk betydning er typisk uklare stopregler, manglende kildeafgrænsning, svag test, for høj handlefrihed og uklar ansvarsfordeling. NIST AI RMF beskriver AI-risikostyring som en livscyklus med styring, kortlægning, måling og håndtering. Det passer godt til daglig brug: Instruktionen skal indgå i en kontrolleret proces.
En enkel kontrol før drift kan være:
- Definér opgaven og det ønskede output.
- Angiv datakilder og forbudte datatyper.
- Tilføj eksempler, mod-eksempler og stopregler.
- Test på realistiske input og registrér fejltyper.
- Beslut, hvem der må ændre instruktionen, og hvornår den skal gentestes.
Den bedste beskyttelse mod gentagne fejl er en arbejdsgang, hvor formulering, test og risikostyring udvikles sammen. Så bliver instruktionsdesign en vedligeholdt praksis frem for en samling tilfældige tekstskabeloner.
Hvilke kilder ligger til grund?
De praktiske principper er kontrolleret mod OpenAI’s dokumentation om evals og OpenAI’s vejledning om strukturerede output. Sikkerhedsdelen bygger på OWASP Top 10 for LLM Applications, mens risikostyring og livscyklusperspektiv er sammenholdt med NIST AI Risk Management Framework 1.0.