Written by:
Last Published:
4. august 2026
•
Best practice inden for prompt engineering kan koges ned til fire greb: Angiv opgaven og dens begrænsninger eksplicit, giv modellen den nødvendige kontekst og de eksempler, den har brug for, lad den ræsonnere, før den svarer, og test din prompt med virkelige input, før den når ud til brugeren. Alt andet er blot detaljer under disse fire punkter.
Betragt en prompt som en arbejdsbeskrivelse, du rækker over disken til en håndværker, der er ekstremt hurtig, arbejder for småpenge og tager hvert et ord bogstaveligt. Skriver du "fikse døren", får du en dør, der kan åbnes – på en eller anden måde. Skriver du derimod, hvilken dør der er tale om, hvilken vej den skal svinge, og hvad der skal gøres, hvis karmen viser sig at være rådden, så får du det resultat, du rent faktisk ønskede. Du får aldrig chancen for at uddybe det senere. Det, der står på arket, er hele briefingen.
Det er derfor, prompts er kommercielt vigtige. En prompt er den billigste del af en AI-funktion at ændre, men den dyreste at få forkert, fordi en dårlig prompt ikke fejler med et brag. Den producerer et plausibelt output, som nogen senere i processen er nødt til at opdage.
Denne artikel gennemgår fundamentet, teknikkerne der forbedrer outputkvaliteten, praksisser der er værd at standardisere på tværs af et team, avancerede kontroller som ræsonneringsindsats og token-grænser, samt hvad promptkvalitet koster forretningen. Den bruger OpenAIs GPT-5-familie som eksempel (GPT-5.4 på skrivetidspunktet), men praksisserne kan overføres til enhver stor sprogmodel med et tilsvarende API. Lad os komme i gang.
ChatGPT er udviklet af OpenAI og er en stor sprogmodel, eller LLM, trænet på en enorm mængde tekst, hvilket gør den i stand til at generere menneskelignende svar på en prompt. Sagt på almindeligt dansk: Den forudsiger det næste token i en sekvens, og et token svarer nogenlunde til tre fjerdedele af et ord. Det er hele tricket, og det har været nok til at gøre teknologien uundværlig for professionelle i stort set alle brancher.
Betyder det, at du skal holde øje med hver eneste modeludgivelse? Nej, og hvis du har fulgt med de sidste atten måneder, ved du hvorfor. OpenAI udfasede hele GPT-4- og GPT-4o-serien i starten af 2026 og samlede alt under GPT-5-familien; alle, hvis kode stadig havde hardcodet gpt-4-turbo , fandt ud af det på den hårde måde. Modelnavne skifter hurtigere, end nogen artikel kan nå at følge med, så fokuser i stedet på de tre specifikationer, der rent faktisk ændrer, hvad du kan bygge, frem for navnet på dette kvartals udgivelse:
Kontekstvinduet, målt i tokens, definerer hvor meget materiale du kan præsentere for modellen på én gang. En nuværende frontlinjemodel som GPT-5.4 har et vindue på omkring en million tokens – svarende til over to tusinde sider – hvilket gør det praktisk at arbejde med lange dokumenter, som f.eks. at opsummere en kontrakt eller en hel support-historik, i ét enkelt kald frem for en hel kæde af dem. Hold dog øje med prisniveauerne: På modeller med en million tokens bliver alt over cirka 272.000 input-tokens faktureret med et tillæg for hele sessionen, så et større vindue er ikke en undskyldning for at holde op med at tænke over dataindsamling.
Vidensgrænsen er den dato, hvorefter modellen ikke har nogen viden. Alle modeller har en, og den er altid tidligere, end man kunne ønske sig. Alt, hvad der ligger efter denne dato, skal nå frem til modellen via prompten, gennem dataindsamling eller et værktøjskald. En model, der svarer ud fra forældede træningsdata, er en af de mest almindelige årsager til selvsikre, men forkerte svar. Tjek det aktuelle modelkort for den præcise dato, før du baserer dig på den.
Prisen pr. token, som afregnes separat for input og output, og som nu ofte opdeles efter kontekstlængde og ræsonneringsindsats. GPT-5.4 koster cirka 2,50 dollars pr. million input-tokens og 15 dollars pr. million output-tokens ved kort kontekst, og prisen stiger ved kald med lang kontekst. En ændring i disse tal kan fra den ene dag til den anden gøre en use case fra for dyr til rentabel, hvilket er præcis grunden til, at du bør genberegne omkostningerne for en funktion, hver gang sortimentet ændrer sig, frem for kun at gøre det én gang i starten.
En fjerde variabel plejede at ligge ved siden af disse tre; nu ligger den ovenpå dem: hvor grundigt modellen ræsonnerer, før den svarer. På den GPT-5-familien dette er en indstilling (ræsonnementsindsatsen går fra ingen til den højeste indstilling), og den gør internt det, som chain-of-thought-prompting herunder beder en ældre model om at gøre højt. Højere indsats koster mere pr. kald og svarer langsommere. Hvor opgaven reelt kræver ræsonnement i flere trin, er den afvejning normalt det værd, og din prompt bliver enklere, fordi du ikke længere behøver at skitsere trinnene. Hvor det ikke er tilfældet, er det ren besparelse at skrue ned for indstillingen.
Tjek OpenAI's API-reference for aktuelle tal, før du bygger en business case på nogen af dem. De ændrer sig hver måned.
Prompt engineering er det, der forvandler en generel model til et værktøj, der løser en specifik opgave pålideligt. Dette afsnit gennemgår, hvad det er, hvorfor prompts spiller så stor en rolle, og hvad der ligger til grund for valget af den ene prompt frem for den anden.
Prompt engineering er den strategiske proces med at planlægge og generere prompts for at fremkalde de ønskede svar fra en model som ChatGPT. Det handler om at skrive de instruktioner og inputs, der styrer modellens adfærd og former kvaliteten og relevansen af det, man får tilbage.
Værdien ligger i at tilpasse modellens svar til en specifik opgave uden at ændre selve modellen. Angiv din hensigt præcist, og du får et nøjagtigt og kontekstuelt relevant output fra et system, der ellers ville besvare et uklart spørgsmål med et uklart svar. Spørg uklart, få uklart. Sådan er det.
Prompts giver modellen den kontekst, den skal bruge for at producere et relevant svar, og de sætter udgangspunktet for samtalen. Strukturér instruktionen tydeligt, og du styrer modellen mod det ønskede resultat.
Dette er dokumenteret i OpenAIs egen forskning, ikke bare i vandrehistorier. Language Models are Few-Shot Learners, GPT-3-artiklen, viste, at det at levere en håndfuld eksempler i selve prompten forbedrer opgavepræstationen væsentligt uden ændringer i modellens vægte, og at præstationen skalerer med antallet af eksempler. Tidligere arbejde med unsupervised multitask-læring viste, at de samme modeller udførte opgaver, de aldrig var blevet specifikt trænet til, forudsat at opgaven var beskrevet tydeligt i inputtet. Nyere modeller kræver færre eksempler for at nå dertil, men konklusionen er stadig den samme.
Sammenlign disse to:
Prompt 1
Opsummér denne supporthenvendelse.
Prompt 2
Opsummér denne supporthenvendelse i tre sætninger til en second-line tekniker. Angiv produktområdet, hvad kunden allerede har forsøgt, og den næste konkrete handling. Gentag ikke kundens tone.
Den anden giver teknikeren noget at arbejde videre med. Den første giver blot en omskrivning. Intet ændrede sig udover præcisionen.
At vide, hvordan prompts klassificeres, hjælper dig med at opbygge dem ud fra det svar, du rent faktisk ønsker. De vigtigste kategorier:
En række elementer afgør kvaliteten, relevansen og nøjagtigheden af det, du får tilbage:
Prompt engineering er stadig et område i rivende udvikling, så forvent, at teknikkerne herunder ændrer sig i takt med, at modellerne gør det.
En prompt er bindeleddet mellem en generel model og en specifik opgave. Den indeholder selve opgaven, den kontekst modellen ikke selv kan regne ud, begrænsningerne for outputtet og – når det er relevant – eksempler på, hvordan et godt resultat ser ud. Præcision i instruktionen er det, der adskiller output, som en programmør kan bruge, fra output, der skal omskrives. Kategorierne ovenfor er en tjekliste for den type svar, du efterspørger. Faktorerne er en tjekliste for, hvad modellen har brug for, før den kan levere varen.
Fem teknikker gør det meste af arbejdet.
Eksplicit vejledning forbedrer kvaliteten af svarene mere pålideligt end nogen anden ændring, du kan foretage.
Generisk prompt
Fortæl mig om vores churn-problem.
Specifik prompt
Her er en tabel over månedlig churn fordelt på kundesegmenter for de sidste 12 måneder. Identificer de to segmenter med den største stigning, angiv stigningens størrelse, og opstil tre spørgsmål, jeg bør stille kontoteamet, før jeg drager konklusioner. Marker alt det, som dataene ikke kan fortælle mig.
Den generiske prompt giver en definition af churn. Den specifikke giver dig noget, du kan tage med til et møde.
Begrænsninger er ekstra instruktioner, der former modellens adfærd og indsnævrer feltet for acceptable svar. Vil du have en procedure? Bed om "en detaljeret, sekventiel proces, hvor hvert trin er en nummereret linje, og intet trin afhænger af information, som læseren endnu ikke har". Bed i stedet om "trin", og du får et afsnit med ordet "først" i.
Begrænsninger er også det billigste værn, der findes. En prompt, der slutter med en defineret fejltilstand, giver dig et maskinkontrollerbart resultat i stedet for et opdigtet:
Opsummer den vedhæftede politik på højst 120 ord, på britisk engelsk, i almindelig prosa uden punkttegn. Hvis politikken ikke angiver en opbevaringsperiode, skal du svare præcis: NOT FOUND.
Kontekst er den tilføjelse, der giver det største udbytte i næsten enhver prompt. Sammenlign:
Prompt uden kontekst
Skriv en e-mail om forsinkelsen.
Prompt med kontekst og ønsket output
Skriv en e-mail til en kunde, hvis integrations-go-live bliver udskudt med to uger på grund af en afhængighed af deres eget it-team. Anerkend konsekvensen, angiv den nye dato, nævn den ene ting, vi har brug for fra dem for at overholde den, og tilbyd et opkald. Seks sætninger, ingen dobbeltundskyldninger, britisk engelsk.
Den anden indeholder alt det, modellen ikke kunne have vidst. Det er hele teknikken. Sandheden er, at de fleste prompts, der "ikke virker", blot mangler dette.
System 1-spørgsmål fremkalder hurtige, instinktive svar. System 2-spørgsmål kræver grundig og detaljeret ræsonnering. Ved at kombinere begge i én arbejdsgang får du hastighed, hvor det er tilstrækkeligt, og dybde, hvor det er nødvendigt.
En assistent til support-triage:
System 1-forespørgslen sorterer sagen på et splitsekund til en brøkdel af prisen. System 2-forespørgslen gemmes til sager, der kræver nærmere undersøgelse, hvor et forkert svar er dyrt, og de ekstra tokens er givet godt ud. På GPT-5-familien svarer dette direkte til ræsonneringsindsats: sorter med minimal indsats, undersøg med høj. At opdele en arbejdsgang på denne måde er typisk den største enkeltstående besparelse, man kan opnå i en LLM-funktion. Det er værd at gøre, før du begynder at lede efter en billigere model.
Styring af detaljegrad fastlægger omfanget og længden af outputtet, hvilket er vigtigst, når svaret skal passe til en skærm eller et efterfølgende felt.
Lav detaljegrad
Giv mig implementeringstrinene som en nummereret liste. Én linje pr. trin, ingen forklaring.
Høj detaljegrad
Giv mig implementeringstrinene som en nummereret liste. Forklar under hvert trin, hvad det gør, hvad det afhænger af, og hvad man skal tjekke, før man går videre til det næste. Gå ud fra, at læseren aldrig har implementeret denne tjeneste før.
Den samme underliggende viden kan bruges af både en erfaren tekniker, der kører en velkendt release, og en nyansat, der gør det for første gang. Detaljegraden er den eneste forskel, og det er en beslutning, der tages på prompt-niveau frem for model-niveau.
Teknikker forbedrer en enkelt prompt. Best practices er det, der får hundredevis af prompts til at fungere på tværs af et team og på tværs af modelopdateringer, som ingen har advaret dig om.
For de AI-funktioner, vi tager i produktion hos Imaginary Cloud, skriver vi prompts som specifikationer i fire dele. Vi kalder det en prompt-specifikation, og det er den struktur, der ligger bag hvert eneste eksempel i denne artikel:
Den fjerde del er den, som teams springer over, og det er netop det, der gør, at arbejde med prompts føles som gætteværk. En prompt uden acceptkriterier kan ikke gennemgås, kan ikke regressionstestes og kan ikke videregives til en anden programmør uden en tyve minutters samtale. Den samme fejl ses i teknisk gæld generelt: arbejde uden en definition af "færdig" hober sig stille og roligt op, indtil nogen betaler prisen på det værst tænkelige tidspunkt.
Gode prompts bliver til gennem iteration, ikke ved at blive skrevet én gang. Gennemgå outputtet, justér, gentag.
Iteration 1: Udtræk handlingspunkterne fra disse mødenoter. → outputtet indeholder både beslutninger og observationer samt handlinger.
Iteration 2: Udtræk kun handlingspunkterne. Et handlingspunkt har en ansvarlig og en underforstået deadline. Ekskludér beslutninger og observationer. → bedre, men de ansvarlige optræder kun med fornavne, som ikke matcher medarbejderlisten.
Iteration 3: Udtræk kun handlingspunkterne som en tabel med kolonnerne Ansvarlig, Handling og Frist. Match hver ansvarlig med det fulde navn på deltagerlisten. Ekskludér beslutninger og observationer. Hvis der ikke er angivet en frist, skal der stå TBC.
Tre gennemgange forvandlede et afsnit til en tabel, som et andet system kan læse. Behold det samme testgrundlag undervejs: de samme mødenoter, som køres igen ved hver prompt-ændring, så du kan se, om iteration fire uforvarende ødelagde iteration tre.
Nogle opgaver kræver ét korrekt svar. Andre kræver valgmuligheder. En tekstassistent, der kun genererer én overskrift, er mindre nyttig end en, der genererer seks, mens en kontrakt-opsummering, der genererer seks versioner, slet ikke er nyttig.
Generér seks emnelinjer til denne produktnyhedsmail. To faktuelle, to fordelscentrerede og to nysgerrighedsvækkende. Under 60 tegn hver. Brug ikke udråbstegn. Returnér dem som en nummereret liste med stilen i parentes.
Prompten sætter rammerne. Inden for disse kan modellen være lige så kreativ, som du ønsker, uden at afvige fra opgaven.
En model kan ikke kende din ordrestatus, dine lagerniveauer eller dagens vejr. Værktøjskald og API-integrationer er det, der forbinder arbejdsopgaven med live-data. Prompten definerer, hvornår modellen skal kalde værktøjet, og hvad den skal gøre, hvis kaldet fejler:
Du er en assistent for ordrestatus. Når kunden spørger til en ordre, skal du kalde get_order_status med ordrereferencen. Svar kun ud fra de værdier, den returnerer. Hvis referencen mangler, eller kaldet fejler, skal du bede kunden om referencen. Forsøg aldrig at estimere en leveringsdato, som værktøjet ikke har returneret.Selve værktøjet er almindelig kode:
def get_order_status(order_ref: str) -> dict:
response = requests.get(
f"https://api.example.com/orders/{order_ref}",
headers={"Authorization": f"Bearer {API_KEY}"},
timeout=5,
)
response.raise_for_status()
data = response.json()
return {
"status": data["status"],
"carrier": data["carrier"],
"expected": data["expected_delivery"],
}Genereret svar: "Ordre 4417 blev afsendt i går med DPD og forventes leveret torsdag den 12. marts."
Værdien af mønsteret ligger i arbejdsdelingen. Faktummet kom fra dit system, sætningen kom fra modellen, og ingen af dem udfører den andens arbejde.
API'et giver dig mulighed for at indbygge den samme interaktion i dit eget produkt:
from openai import OpenAI
client = OpenAI()
def ask(question: str, history: list[dict] | None = None) -> str:
messages = [{"role": "system", "content": SYSTEM_PROMPT}]
messages += history or []
messages.append({"role": "user", "content": question})
response = client.chat.completions.create(
model="gpt-5.4",
messages=messages,
temperature=0.2,
max_tokens=500,
)
return response.choices[0].message.contentSystem-prompten indeholder specifikationen, historikken indeholder samtalen, og temperature og max_tokens afspejler de produktbeslutninger, vi når frem til nedenfor. En vigtig detalje: på modeller med fokus på ræsonnement har temperature mindre effekt, end det var tilfældet med modeller fra GPT-4-æraen, og ræsonneringsindsats bliver den parameter, der betyder noget. Betragt derfor værdien her som vejledende, og bekræft modellens adfærd via modelkortet. Vejen fra et kodestykke som dette til noget, du kan præsentere for kunder, er længere, og vi har skrevet om at tage en AI-prototype i produktion separat.
Når en model påvirker en beslutning om et menneske, ophører bias med at være et kvalitetsproblem og bliver et juridisk problem. Forestil dig, at et system bruger en LLM til at opsummere interviewbesvarelser for et ansættelsespanel. Disse trin reducerer risikoen:
Jo højere indsatsen er, desto mere skal "mennesket i loopet" være en reel funktion frem for blot pynt, og disciplinen er den samme, uanset om systemet er en LLM eller noget helt andet. Da vi byggede Geo Matrix Decision Engine til Aurora Analytica, et scenarieplanlægningsværktøj til teams, der arbejder med kliniske forsøg, var pointen aldrig, at softwaren skulle lyde overbevisende. Pointen var, om en CRO-analytiker kunne se på et resultat og kontrollere det, før det lå til grund for en reel beslutning om et forsøg. Det er ikke en LLM-historie (det er en beslutningsmotor), men det er den samme årsag til, at accepttjekket indgår i vores prompt-specifikation: I regulerede omgivelser er output, som et menneske ikke kan verificere, en risiko, uanset hvordan det er genereret. Den samme standard gælder for enhver LLM-funktion, der når ud til en kunde, en tilsynsmyndighed eller en kontrakt. Hvis du arbejder inden for et reguleret felt som sundhedsvæsenet eller jura, betragter vores team for anvendt AI og maskinlæring evaluering som en del af leverancen frem for en fase, der er tilføjet bagefter.
Prompt engineering lyder som et håndværksmæssigt emne, men ender som en udgiftspost. Fire tal gør indtryk på en bestyrelse:
Time-to-value er grunden til at bekymre sig om alle fire på én gang. Arbejde på prompt-niveau går hurtigt, hvilket er præcis grunden til, at teams springer de dele over, der ikke gør, for derefter at bruge de uger, de sparede, på hændelseshåndtering. De teknologivalg omkring en AI-funktion følger det samme mønster: Det billige valg tidligt er sjældent det billige valg over tre år.
For GPT-5-familien er det første greb, du bør justere, resonneringsindsats, fra ingen til den højeste indstilling. Lav indsats til alt, der er overfladisk og i store mængder; høj indsats til de få kald, hvor et forkert svar er dyrt. Det er det mest effektive værktøj, du har til at styre omkostningerne.
Temperatur styrer stadig tilfældighed, hvor det er relevant. Lave værdier som 0,2 giver fokuserede, overvejende deterministiske svar; højere værdier som 0,9 giver mere varierede og udforskende svar. Beslutningen er produktorienteret:
temperature=0.2: Udtræk betalingsbetingelserne fra denne kontraktklausul og opsummer dem i én sætning.temperature=0.9: Giv mig ti navne til et internt værktøj, der afstemmer fakturaer mod indkøbsordrer. Det skal være enkelt og huskbart frem for smart.Alt, hvad en kunde skal læse som fakta, bør have lav temperatur og lav indsats. Alt, hvad en person skal vælge imellem, kan tåle mere af begge dele.
Token-grænser begrænser svarets længde. Ved at indstille max_tokens holder du bevidst outputtet inden for den plads, der er til rådighed, og undgår, at et langt svar bliver afbrudt midt i en sætning i en brugerflade, hvor der kun var plads til tre linjer. Da output-tokens er den dyreste del af regningen, er det ofte en større besparelse at begrænse længden end at skære i inputtet.
Kædning forbinder prompts, så hver enkelt kan referere til tidligere input og output. Det er det, der gør opgaver i flere trin mulige.
En onboarding-assistent:
Det andet trin afhænger fuldstændigt af det første. Kædning holder også hver prompt lille nok til, at en kollega kan gennemgå den, hvilket en enkelt monolitisk prompt, der forsøger begge trin, aldrig ville kunne.
At tilpasse en prompt til et domæne betyder at inddrage dens ordforråd, begrænsninger og risikoprofil i instruktionen.
En generel prompt, Opsummér denne kontrakt, bliver til:
Du assisterer en erhvervsadvokat med at gennemgå en leverandøraftale. Identificer opsigelsesbestemmelser, ansvarsbegrænsning, betalingsbetingelser og eventuelle klausuler om automatisk fornyelse. Angiv klausulnummeret for hver enkelt. Hvis en bestemmelse mangler, skal du eksplicit oplyse dette frem for at udlede en tilsvarende. Du må ikke give juridisk rådgivning eller en vurdering af, om vilkårene er fordelagtige.
Svaret kommer derefter i en form, som korrekturlæseren kan tjekke klausul for klausul:
Domænetilpasning handler ikke om tonefaldet. Det handler om den eksplicitte liste over, hvad man skal kigge efter, samt instruktionen om, hvad man skal gøre, når noget mangler.
Brugere beder om modstridende ting, og en model, der løser modstriden uden at sige noget, vil før eller siden løse den forkert.
Bruger: Giv mig sidste kvartals omsætning fordelt på region, men kun for enterprise-konti, og inkluder pipelinen.
Omsætning og pipeline er forskellige måleenheder, og "sidste kvartal" kan betyde kalenderkvartal eller regnskabskvartal. Instruér derfor modellen til at stoppe op og spørge:
Hvis anmodningen er tvetydig, så lad være med at gætte. Stil ét afklarende spørgsmål og vent.
Assistent: Ønsker du realiseret omsætning og åben pipeline som separate kolonner, og skal kvartalet forstås som regnskabsmæssigt 3. kvartal eller kalendermæssigt 1. kvartal?
Når brugeren har svaret, kan modellen levere et korrekt resultat frem for blot et sandsynligt et. Ved at indbygge dette afklarende trin i prompten forhindrer man assistenten i selv at opfinde en definition af "sidste kvartal" og rapportere selvsikkert ud fra den.
DeepLearning.AI's lynkursus ChatGPT Prompt Engineering for Developers, undervist af Isa Fulford og Andrew Ng, er stadig den mest overskuelige gratis introduktion for ingeniører. En bemærkning om aktualitet: kurset blev optaget med GPT-3.5 Turbo, som nu er udgået, så betragt de modelspecifikke detaljer som forældede; principperne kan dog overføres direkte til GPT-5-familien. Her er, hvad materialet bidrager med til hver del af prompt-specifikationen, og hvor produktion kræver mere, end kurset dækker.
Opgave: hvorfor specifikke instruktioner er bedre end korte. Kursets første princip er at skrive klare og specifikke instruktioner, og den mest nyttige korrektion er, at en klar prompt ikke er det samme som en kort prompt. To af taktikkerne hører hjemme i opgavelinjen. Afgrænsere markerer de forskellige dele af inputtet (tredobbelte anførselstegn, backticks, bindestreger, vinkelparenteser eller XML-tags), så modellen kan skelne dine instruktioner fra brugerens tekst, hvilket også mindsker risikoen for prompt-injection. Few-shot prompting giver eksempler på opgaven udført korrekt, før du beder om den rigtige. Hvad kurset ikke dækker, er hvor opgavelinjen placeres: i et API-kald indeholder systembeskeden rollen og de faste regler, mens brugerbeskeden kun indeholder denne forespørgsels input. Teams, der propper de faste regler ind i brugerbeskeden, oplever, at deres prompt driver.
Begrænsninger: strukturerede outputs og maskinkontrollerbar fejlhåndtering. Kursets anden taktik er at anmode om struktureret output, såsom JSON. At bede pænt om JSON er den svage version. Nuværende API'er vil håndhæve et skema for dig: en JSON-tilstand, der garanterer gyldig JSON, eller strukturerede outputs hvor du leverer skemaet, og modellen tvinges til at validere i forhold til det. Hvis outputtet skal fødes ind i et andet system, så brug skemaet. En parse-fejl, du fanger ved grænsefladen, er bedre end en prompt, der "normalt" overholder reglerne.
Bevis og accept: verificer antagelserne, og test derefter batchet. Kursets tredje taktik er at lade modellen tjekke sine betingelser først og rapportere alle, der ikke er opfyldt – accepttjekket flyttet ind i selve prompten. Dets iterative loop anvender samme idé uden for prompten: forsøg, analyser afvigelsen, præciser, og forfin i forhold til et batch. Batchet er dit faste testsæt, og det er forskellen på en prompt, der virker på det eksempel, du havde åbent, og en, der virker på de inputs, du rent faktisk modtager. Det er her, vores praksis adskiller sig fra kurset: en kursus-prompt er færdig, når outputtet i notebooken ser rigtigt ud; en produktions-prompt er færdig, når den består et testsæt, har en navngiven ansvarlig og et fastlagt svar på "hvad sker der den dag, modellen under den ændrer sig."
Tankekæde: giv modellen plads til at ræsonnere. Det andet princip er at give modellen tid til at tænke. Bed om ræsonnementet først og konklusionen derefter; det forhindrer modellen i at låse sig fast på et svar, den ikke har gennemtænkt. Ræsonnerende modeller gør nu dette internt, hvilket ændrer økonomien snarere end princippet: Ved disse modeller medfører en eksplicit anmodning om trin blot ekstra omkostninger uden nævneværdig forbedring af præcisionen. Prøv derfor med en simpel prompt først, og tilføj kun struktur, hvor din evaluering viser, at det gør en forskel.
Hvad LLM'er er gode til: opsummering, inferens, transformering, udvidelse. Kurset opdeler hverdagens anvendelsesmuligheder i fire kategorier, hvilket er et yderst brugbart værktøj til prioritering. Opsummering kan fokusere på én bestemt dimension frem for at komprimere alt ensartet. Inferens bestemmer sentiment, udtrækker navne og identificerer emner uden behov for opgavespecifik træning. Transformering (oversættelse, grammatik, tone, formatkonvertering) er den mest pålidelige af de fire, fordi inputtet allerede indeholder svaret. Udvidelse forvandler et kort input til en længere tekst og indebærer den største risiko, da modellen tilføjer materiale, som ikke var i det oprindelige input – og det er netop her, risikoen for opspind opstår. Vægt din evaluering derefter.
Prompt engineering er det lag, hvor størstedelen af kvaliteten – og størstedelen af omkostningerne – ved en LLM-funktion bliver afgjort. Teknikkerne er ikke svære: Vær specifik, giv kontekst, begræns outputtet, giv modellen plads til at ræsonnere, og fastlæg indsats og længde bevidst. Det, der adskiller de teams, der leverer pålidelige AI-funktioner, fra dem, der blot leverer demoer, er det kedelige arbejde. At skrive prompts som specifikationer med tilhørende acceptkriterier. At vedligeholde et fast sæt af reelle input. At køre testen igen, når den underliggende model ændrer sig – og det gør den i 2026.
Tilbage til den disk. Håndværkeren spørger dig ikke, hvad du mente, og der kommer en ny hver anden måned uden at give besked. Derfor skal din arbejdsbeskrivelse være komplet, og du skal kunne bevise, at den forrige stadig fungerer. Prompts skrevet som specifikationer overlever det. Prompts skrevet som heldige sætninger gør ikke.
Lige så lang som det kræver at fjerne enhver tvetydighed, og ikke længere. En kort prompt er ikke nødvendigvis en klar prompt. De fleste prompts i produktion er på flere hundrede ord, fordi de indeholder opgaven, begrænsningerne, fejlhåndtering og et par eksempler. Omkostningerne ved disse tokens er reelle, men små sammenlignet med prisen for et output, som nogen efterfølgende skal rette.
Begræns den og giv den et grundlag at arbejde ud fra. Lever kildematerialet i prompten eller via retrieval, instruér modellen i kun at svare ud fra dette materiale, og giv den en eksplicit måde at fejle på, f.eks. ved at svare "IKKE FUNDET", når svaret ikke findes. Sænk temperaturen og ræsonnementet for alt, der er faktuelt. Intet af dette eliminerer risikoen for opdigtede svar, hvilket er grunden til, at alt af betydning altid bør gennemgås af et menneske.
Ja, omend mindre som en jobtitel og mere som almindelig ingeniørpraksis. Bedre modeller kræver mindre tilpasning, men de kender stadig ikke dine data, dine begrænsninger eller hvad dine brugere mener med "sidste kvartal". At definere en opgave præcist og beskrive, hvordan et korrekt svar ser ud, er stadig selve arbejdet.
Prompt engineering ændrer instruktionen. Fine-tuning ændrer selve modellen ved at træne den yderligere på dine egne eksempler. Prompting er hurtigere, billigere og kan fortrydes, så det er det rigtige første skridt. Fine-tuning bliver værd at overveje, når en opgave er volumenbaseret, snæver og stabil nok til, at eksemplerne ikke bliver forældede, og når man allerede har optimeret promptingen så meget som muligt.
Lav et testsæt med tyve til halvtreds reelle inputs sammen med de forventede outputs, kør prompten mod dem alle, og gennemgå resultaterne samlet frem for ét ad gangen. Kør testen igen ved hver ændring af prompten og efter hver modelopdatering. Det er den eneste pålidelige måde at vide, om en ændring har forbedret prompten, eller om den blot har flyttet fejlen til et sted, du ikke holdt øje med.
Styring af ræsonnement, temperatur og token-grænser for at kontrollere omkostninger, tilfældighed og længde; kædning af prompts over flere omgange; tilpasning af prompts til et specifikt domæne med dets ordforråd og begrænsninger; samt håndtering af tvetydige eller modstridende inputs ved at instruere modellen i at spørge frem for at gætte.
Hvis du overvejer, om en LLM passer ind i en bestemt arbejdsgang, er det mest nyttigt at starte samtalen med acceptkriterierne frem for selve modellen: hvordan ser et korrekt output ud, hvem opdager fejlene, og hvad koster det jer? Vores data science- og AI-udviklingsteam arbejder sammen med kunder om netop dette spørgsmål, lige fra evaluering af et use case til drift i produktion. Hvis du har en arbejdsgang i tankerne, så kontakt os , så giver vi dig et ærligt svar på, om det kan betale sig at bygge.
Alexandra Mendes er Senior Growth Specialist hos Imaginary Cloud med 3+ års erfaring med at skrive om softwareudvikling, AI og digital transformation. Efter at have gennemført et frontend-udviklingskursus fik Alexandra nogle praktiske kodningsevner og arbejder nu tæt sammen med tekniske teams. Alexandra brænder for, hvordan nye teknologier former erhvervslivet og samfundet, og hun nyder at omdanne komplekse emner til klart og nyttigt indhold for beslutningstagere.
CEO hos Imaginary Cloud og medforfatter til bogen Product Design Process. Jeg nyder mad, vin og Krav Maga (ikke nødvendigvis i den rækkefølge).
LinkedIn
People who read this post, also found these interesting:
