Prompt Engineer

En prompt engineer får en sprogmodel til at gøre det samme rigtigt hver gang. Det lyder simpelt. Det er det sjældent.

Arbejdet starter altid med en konkret opgave. Det kan være en kundeservicebot, der skal svare på spørgsmål om abonnementer. Eller et internt værktøj, der læser 200 siders udbudsmateriale og trækker kravene ud. Prompt engineeren skriver instruktionen, kører den mod rigtige eksempler og finder ud af, hvor den fejler.

Typiske opgaver:

• Skrive og forbedre systemprompts til chatbots og interne værktøjer
• Bygge et testsæt med 50-200 realistiske spørgsmål og måle svarene (evaluering)
• Finde årsagen til fejlsvar: mangler modellen data, kontekst eller klare regler?
• Koble modellen til virksomhedens egne dokumenter, så svarene bygger på dem (RAG)
• Sætte grænser, så modellen afviser det, den ikke må svare på
• Teste for prompt injection, hvor en bruger prøver at overskrive instruktionen
• Følge tokenforbrug, svartid og pris per svar
• Skrive ned, hvorfor en prompt ser ud, som den gør

En almindelig dag ligner en udviklers dag. Formiddagen går med at rette en instruktion, der gav fem forkerte svar ud af hundrede. Eftermiddagen går med at sidde sammen med en sagsbehandler eller supportmedarbejder. Det er dem, der kan afgøre, om et svar reelt er brugbart. Uden den faglige sparring bliver målingerne ligegyldige.

En stor del af faget er kedelig disciplin. Man ændrer én ting ad gangen. Man kører hele testsættet igen. Man dokumenterer, hvad der blev bedre, og hvad der blev værre. Prompts, der virker på tre eksempler, falder ofte fra hinanden på tre hundrede.

Dokumentation fylder mere, end mange tror. EU's AI-forordning stiller krav om gennemsigtighed for en række AI-systemer, blandt andet at brugere kan se, at de taler med en maskine. Datatilsynet har desuden udgivet vejledning om kunstig intelligens og persondata. Derfor bruger en prompt engineer også tid på logning og på at holde personoplysninger ude af prompts.

Brancher, hvor rollen findes i dag:

• It-konsulenthuse og softwarevirksomheder
• Banker, pension og forsikring, typisk til kundeservice og sagsbehandling
• Medico og pharma, ofte til dokumentation og litteratursøgning
• Kommuner og styrelser, ofte til journalisering og aktindsigt
• E-handel og mediehuse, typisk til produkttekster og redaktionelle værktøjer
• Advokat- og revisionsbranchen, til kontrakt- og bilagsgennemgang

Skal du ansætte en prompt engineer?
Bed om at se et evalueringssæt, ikke en samling smarte prompts. Spørg, hvordan kandidaten måler, om en ændring gjorde løsningen bedre. Bed om et konkret eksempel, hvor modellen svarede forkert, og hvad der løste det. Vær opmærksom på, at rollen sjældent er et fuldtidsjob i sig selv i mindre virksomheder. Den ligger ofte hos en udvikler, en dataanalytiker eller en fagperson med teknisk flair.

Der findes ingen dansk uddannelse, der hedder prompt engineer. Titlen er ikke beskyttet, og faget kræver ingen autorisation. Folk kommer ind ad tre typiske veje.

Den tekniske vej
Datamatiker tager 2,5 år på et erhvervsakademi. Adgangskravet er typisk en gymnasial eksamen med matematik C eller en relevant erhvervsuddannelse. Derefter kan man tage en professionsbachelor i softwareudvikling på halvandet år. Universitetsvejen er en bachelor i datalogi, software engineering eller data science på tre år. Dertil kommer to års kandidat. DTU, ITU, Københavns Universitet, Aarhus Universitet og Aalborg Universitet udbyder beslægtede uddannelser.

Vejen fra et fagområde
Mange dygtige prompt engineers kommer fra det fag, modellen skal hjælpe. En jurist bygger et værktøj til kontraktgennemgang. En supportchef bygger svarudkast til kundeservice. Fagligheden er en reel fordel. Du kan selv se, om et svar er godt nok. Til gengæld skal du lære at teste systematisk og kalde et API.

Vejen fra sprog og kommunikation
Lingvistik, kommunikation og teknisk skrivning giver et godt greb om præcis formulering. Det er cirka halvdelen af faget. Den anden halvdel er data, målinger og lidt kode.

Der findes ingen officiel dansk certificering i prompt engineering. Leverandørerne udbyder selv korte kurser og certifikater, blandt andet Anthropic, OpenAI, Google og Microsoft. De tæller mindre end en portefølje af færdige løsninger. Arbejdsgivere spørger i praksis til, hvad du har bygget, og hvordan du målte det.

EU's AI-forordning stiller krav om, at virksomheder sikrer tilstrækkelige AI-kompetencer hos de medarbejdere, der bruger og udvikler AI-systemer. Det krav har fået mange danske organisationer til at opbygge kompetencerne internt. Derfor bliver en del prompt engineers oplært på jobbet i en eksisterende rolle.

En realistisk plan, hvis du starter ved siden af et job:

• Lær Python på et niveau, hvor du kan kalde et API og læse en fejlbesked
• Byg to-tre løsninger færdige, ikke ti halve
• Lav et testsæt til hver løsning og gem resultaterne før og efter
• Lær grundprincipperne i RAG, så modellen svarer ud fra dokumenter og ikke ud fra hukommelse
• Sæt dig ind i, hvilke data der må sendes til en ekstern model

Regn med 6-18 måneder, hvis du i forvejen kan enten koden eller fagområdet. Kan du ingen af delene, tager det længere tid.

Værktøjskassen består af tre lag: modellerne, koden omkring dem og målingerne.

Modeller og grænseflader
ChatGPT, Claude, Gemini og Microsoft Copilot bruges til hurtige forsøg. Åbne modeller som Llama og Mistral kan køres lokalt eller i egen sky. Det vælges ofte, når data ikke må forlade huset.

API'er og platforme
Det meste produktionsarbejde sker gennem API'er fra Anthropic, OpenAI eller Google. Større danske virksomheder bruger typisk Azure OpenAI eller Amazon Bedrock. Valget afhænger tit af, hvor data må ligge, og hvilket databehandlergrundlag der findes.

Kode og rammeværk
Python er standardsproget. Jupyter-notebooks bruges til hurtige forsøg. LangChain og LlamaIndex bruges til at binde modeller sammen med data og værktøjer. Vektordatabaser som pgvector, Pinecone, Weaviate og Qdrant gemmer dokumenterne, modellen skal slå op i.

Måling og drift
Evalueringsværktøjer som promptfoo, LangSmith og Braintrust kører testsæt automatisk. Mange bruger derudover et helt almindeligt regneark til at score svar i hånden. Git bruges til versionsstyring, for prompts hører hjemme i kildekoden og ikke i et løst dokument. Logning og observability bruges til at følge fejl, svartid og forbrug.

Dertil kommer det almindelige: Jira eller Azure DevOps til opgaver, Confluence eller Notion til dokumentation.