Udvikling af dynamiske prompts for AI

Dynamiske prompts er modelinstruktioner, der samles i øjeblikket ud fra brugerens opgave, relevante data, regler og ønsket outputformat. De bruges, når en AI-løsning skal svare mere præcist end med en fast standardskabelon, men de kræver klare grænser, test og kontrol af ubetroet indhold.

Hvad betyder dynamiske prompts i en AI-løsning?

Dynamiske prompts er ikke bare længere instruktioner. De er sammensatte instruktioner, hvor et system kombinerer faste regler med variable dele, før modellen modtager opgaven. De variable dele kan være brugerens formulering, valgte rolle, sprog, dokumentuddrag, kundetype, adgangsniveau, historik eller et bestemt outputformat.

Den praktiske forskel er, at instruktionen ikke skrives manuelt fra gang til gang. Den bygges af applikationen ud fra en skabelon og et sæt regler. En supportløsning kan for eksempel indsætte ordrestatus, relevante politikker og kundens sprog, mens en analysefunktion kan indsætte kolonnenavne, datoperiode og krav til tabelformat.

OpenAI beskriver i sin dokumentation, at faste udviklerinstruktioner og brugerinput har forskellige prioriteter, og at de kan tænkes som en funktion og dens argumenter. Den analogi passer godt på dynamiske prompts: den faste del definerer logikken, mens de variable dele leverer den konkrete sag, som logikken skal anvendes på.

Hvornår giver dynamiske prompts mere værdi end faste instruktioner?

Faste instruktioner fungerer godt, når opgaven næsten altid er den samme. Dynamiske prompts giver mere værdi, når opgaven skifter efter situation, data eller brugerens rettigheder. De er især relevante i løsninger, hvor svar skal tilpasses uden at udvikleren vil vedligeholde mange næsten ens skabeloner.

Typiske eksempler er interne vidensassistenter, rapportgenerering, mødeopsummering, kundeservice, søgning i dokumenter, kodehjælp og læringsværktøjer. I alle tilfælde kan den samme grundlogik genbruges, mens skabelonen får forskellige data og krav for hver kørsel.

Værdien falder, hvis variationen er kosmetisk. Hvis systemet kun skifter tiltaleform eller indsætter et navn, er en almindelig tekstskabelon ofte nok. Dynamiske prompts er mest nyttige, når de styrer valg af kontekst, afgrænser opgaven, reducerer støj eller sikrer, at svaret følger en form, som andre systemer kan bruge.

Hvilke dele bør adskilles i en dynamisk instruktionsskabelon?

En robust skabelon opdeler instruktionen i moduler. Det gør den lettere at teste, ændre og fejlfinde. Den faste del bør forklare opgaven, grænserne, tonen og prioriteringen. De variable dele bør indsættes på veldefinerede steder og helst have tydelige feltnavne, så både udviklere og testpersoner kan se, hvad der kommer fra hvor.

Den vigtigste afgrænsning er mellem instruktion og data. Instruktionen bør komme fra applikationen. Data kan komme fra brugeren, databasen eller søgning, men de bør ikke få lov til at omskrive reglerne for opgaven.

Hvordan bruges brugerdata uden at gøre svarene usikre?

Brugerdata kan gøre en AI-funktion mere relevant, men de bør behandles som input med begrænset tillid. Et navn, et dokumentuddrag eller en tidligere samtale kan hjælpe modellen, men det kan også indeholde fejl, personoplysninger eller tekst, som forsøger at styre modellen væk fra den oprindelige opgave.

En praktisk tilgang er at bruge mindst mulige data. Indsæt kun det, der er nødvendigt for opgaven, og marker tydeligt, om informationen kommer fra brugeren, et internt system eller en ekstern kilde. Hvis systemet har adgang til følsomme oplysninger, bør skabelonen også beskrive, hvornår oplysninger ikke må gengives.

OpenAI-dokumentationen om tekstgenerering peger på, at udviklerinstruktioner har højere prioritet end brugerinput. Det fjerner ikke behovet for kontrol. Hvis applikationen selv samler instruktionen forkert, eller hvis ubetroet tekst blandes sammen med regler, kan modellen stadig få uklare signaler. Derfor bør dynamiske prompts bygges med samme disciplin som anden kode, der håndterer input.

Hvordan hænger dynamiske prompts sammen med RAG og kontekststyring?

Retrieval augmented generation, ofte forkortet RAG, handler om at hente relevant viden ind i modelkaldet. Dynamiske prompts bestemmer, hvordan den hentede viden placeres, prioriteres og forklares for modellen. De to begreber overlapper derfor i praksis, men de er ikke det samme.

RAG afhænger typisk af søgning, rangering, uddrag og embeddings. En dynamisk skabelon afgør derefter, om modellen skal citere kilder, afvise utilstrækkelig kontekst, svare med usikkerhed eller stille et opklarende spørgsmål. Se også AI Mentors forklaringer af retrieval augmented generation og AI embeddings, som dækker den tekniske side af søgning og repræsentation.

Kontekststyring handler ikke kun om at putte mere tekst ind. OpenAI beskriver, at enkelte tekstgenereringskald er uafhængige, medmindre applikationen aktivt sender tidligere indhold eller bruger en stateful mekanisme. Det betyder, at udvikleren skal vælge, hvad der skal med videre, hvad der skal opsummeres, og hvad der skal udelades.

Hvordan kan skabeloner gøre output mere stabilt?

Stabilitet kommer ikke af én formulering alene. Den kommer af klare felter, få tvetydige regler og en forventning om, hvordan svaret skal se ud. Hvis outputtet skal bruges af mennesker, kan en enkel rækkefølge være nok. Hvis outputtet skal bruges af et andet system, er en egentlig struktur ofte bedre.

OpenAI beskriver structured outputs som en måde at få modellen til at levere svar, der følger en JSON Schema-baseret struktur. Det er relevant, når en dynamisk skabelon skal danne grundlag for klassifikation, dataudtræk, statusfelter eller automatiske beslutningspunkter. Her bør outputkravet ikke kun ligge som prose, men også afspejles i validering.

Et godt kontrolpunkt er at spørge, om en fejl kan opdages automatisk. Hvis et svar mangler en kildeangivelse, et risikoniveau eller et påkrævet felt, bør systemet kunne fange det. AI Mentors ordbog om zero-shot og few-shot forklarer også, hvornår eksempler kan hjælpe modellen med at følge en form.

Hvordan testes en dynamisk instruktionskæde?

Test bør begynde med konkrete succeskriterier. Det kan være korrekt klassifikation, relevant kildebrug, fravær af persondata i svaret, et bestemt JSON-format, kort svartid eller en fast afvisningsadfærd ved manglende grundlag. Anthropic anbefaler at definere succeskriterier og bygge evalueringer, før en skabelon forbedres systematisk.

For dynamiske prompts bør tests dække både normale sager og kanttilfælde. En testpakke kan indeholde korte og lange brugerinput, manglende data, modstridende dokumentuddrag, uventede sprog, flere roller, tomme søgeresultater og forsøg på at få modellen til at ignorere reglerne.

• Gem faste testcases med input, variable data og forventet type svar.
• Mål både formelle fejl, som manglende felter, og faglige fejl, som ukorrekt konklusion.
• Kør tests igen, når model, skabelon, søgeindeks eller datafelter ændres.
• Brug menneskelig gennemgang på risikofyldte opgaver, hvor automatiske checks ikke fanger nuance.

OpenAI anbefaler også fixtures, tests og evalueringschecks før ændringer i produktionsskabeloner. Den anbefaling gør dynamiske prompts til en del af applikationens almindelige kvalitetssikring, ikke en løs tekst, der kun justeres efter mavefornemmelse.

Hvilke sikkerhedsrisici opstår ved indhold udefra?

Den største risiko opstår, når tekst udefra bliver blandet sammen med systemets egne regler. Et hentet dokument, en e-mail, en webside eller et værktøjsresultat kan indeholde skjulte instruktioner, som forsøger at ændre opgaven. Anthropic skelner mellem direkte angreb fra en bruger og indirekte angreb, hvor ubetroet tredjepartsindhold læses på brugerens vegne.

OWASP Top 10 for LLM Applications beskriver manipulerende input som en central risiko for LLM-applikationer og nævner også usikker outputhåndtering og læk af følsomme oplysninger som selvstændige risikoområder. For dynamiske prompts betyder det, at sikkerhed ikke kan overlades til formuleringen alene.

En sikker skabelon bør derfor markere ubetroet indhold som data, begrænse adgang til værktøjer, undgå unødvendige hemmeligheder i konteksten og kræve bekræftelse før handlinger med konsekvens. Ved høj risiko bør systemet også logge skabelonversion, datakilde, værktøjskald og afvisningsårsag, så fejl kan analyseres uden at gemme mere persondata end nødvendigt.

Hvordan styres omkostning, svartid og kontekstlængde?

Dynamiske prompts kan blive dyre og langsomme, hvis de ukritisk fylder hver opgave med hele dokumenter, lang samtalehistorik og mange eksempler. Større kontekst kan give mere grundlag, men den kan også øge svartid, gøre instruktionen mindre skarp og gøre fejl sværere at finde.

En god praksis er at styre konteksten i lag. Først medtages de faste regler. Derefter tilføjes kun de variable data, som opgaven kræver. Til sidst indsættes få, relevante uddrag fra søgning eller historik. Hvis informationen er lang, kan applikationen bruge opsummering, rangering eller begrænse kilder til de mest relevante passager.

Temperatur og andre modelindstillinger spiller også ind. Lavere variation kan være nyttig ved klassifikation og faste formater, mens kreative opgaver kan tåle mere variation. AI Mentors forklaring af temperatur i AI-prompts uddyber, hvordan indstillingen påvirker sandsynlighed og variation i svar.

Hvordan kan teams dokumentere ændringer uden tung proces?

Dynamiske prompts bør dokumenteres nok til, at et team kan forstå, hvorfor de virker, og hvornår de blev ændret. Det behøver ikke være en stor rapport. En kort ændringslog med version, formål, forventet effekt, testresultat og kendte begrænsninger er ofte tilstrækkelig.

Dokumentationen bør især vise, hvilke variable der må indsættes, hvilke kilder der er tilladt, og hvilke handlinger modellen aldrig må tage uden ekstra kontrol. Hvis en skabelon bruges i en organisation, bør der også stå, hvem der ejer den, og hvilke typer opgaver den er godkendt til.

NISTs AI Risk Management Framework beskriver risikostyring som en proces, der skal indgå i design, udvikling, brug og evaluering af AI-systemer. Overført til dynamiske prompts betyder det, at ændringer i instruktioner, dataflow og evalueringskriterier bør kunne spores, især når løsningen bruges i drift.

Hvilke fejl ses ofte i udviklingen af dynamiske prompts?

En hyppig fejl er at gøre skabelonen for generel. Hvis den prøver at dække alle opgaver, ender den ofte med uklare prioriteringer. En anden fejl er at indsætte for meget kontekst, så modellen får mange svage signaler i stedet for få stærke.

Der opstår også fejl, når variable data ikke valideres. Hvis et felt kan være tomt, forkert kodet eller indeholde instruktioner fra en ekstern kilde, bør skabelonen håndtere det eksplicit. Ellers bliver fejl først synlige som mærkelige eller inkonsistente svar.

• Brug ikke én stor skabelon til alle opgaver, hvis opgaverne har forskellige risici.
• Lad ikke hentede dokumenter stå samme sted som systemets egne regler.
• Skift ikke model, søgeindeks og skabelon på samme tid uden separat test.
• Undgå skjulte standardværdier, som ændrer svaret uden at være dokumenteret.

Den bedste modvægt er at behandle dynamiske prompts som en lille softwarekomponent: modulopdelt, testbar og versioneret. Det gør arbejdet mere teknisk, men også mere stabilt, når flere personer skal vedligeholde samme AI-funktion.

Hvordan kommer man praktisk i gang?

Begynd med én konkret opgave, hvor variationen er reel. Definér først, hvad modellen skal levere, hvilke data den må bruge, og hvordan et godt svar ser ud. Skriv derefter en enkel skabelon med faste regler, variable felter og et tydeligt outputkrav.

1. Vælg en afgrænset opgave, for eksempel klassifikation, opsummering eller forslag til næste handling.
2. Lav en skabelon med adskilte felter for regler, brugerinput, kontekst og svarformat.
3. Opret testcases med normale input, manglende data og modstridende kontekst.
4. Log skabelonversion, datakilder og fejltyper, men undgå unødvendige persondata.
5. Rul ændringer ud gradvist, hvis funktionen påvirker kunder, medarbejdere eller automatiske handlinger.

Den praktiske gevinst viser sig først, når skabelonen både kan tilpasse sig og kontrolleres. Dynamiske prompts skal derfor ikke kun vurderes på, om ét svar lyder godt, men på om mange svar følger opgaven, bruger den rette kontekst og fejler på en forudsigelig måde.

Hvilke kilder ligger til grund?

Artiklen bygger på OpenAIs dokumentation om tekstgenerering og message roles, OpenAIs vejledning om structured outputs, Anthropics sikkerhedsvejledning om jailbreaks og indlejrede instruktioner, OWASP Top 10 for LLM Applications og NISTs AI Risk Management Framework.