Vælg mellem prompting, RAG og finjustering (og hvornår de skal kombineres)

Et team får opgaven: “Gør vores AI bedre til vores konkrete brugssituation.” De har flere muligheder. De kan skrive bedre prompts. De kan bygge et RAG-system, der giver modellen relevante data. De kan finjustere modellen med eksempler fra deres domæne.

Mulighederne er ikke indbyrdes udskiftelige. De løser forskellige problemer. Vælger du forkert, kan du bruge tre måneder og et stort budget på finjustering, selv om en bedre prompt var løsningen. Eller bygge omfattende RAG-infrastruktur, selv om finjustering havde været enklere. Eller sidde fast i prompts, selv om modellen grundlæggende ikke kan løse opgaven.

Denne artikel giver en ramme for valget — hvornår hver tilgang er det rette værktøj, hvornår de skal kombineres, deres realistiske omkostninger, og hvad der typisk går rigtigt og galt i produktion.

Hvad de enkelte tilgange faktisk gør

En klar skelnen:

Prompting ændrer, hvad modellen bliver bedt om. Du giver modellen bedre instruktioner, eksempler, formatkrav og kontekst. Modellen ændres ikke; inputtet gør.

RAG ændrer, hvilke data modellen ser. Du henter relevante oplysninger på forespørgselstidspunktet og medtager dem i prompten. Modellen får aktuelle, specifikke og dynamiske data uden at blive trænet på dem.

Finjustering ændrer, hvad modellen ved, eller hvordan den opfører sig. Du træner modellen på eksempler og ændrer dens vægte. Selve modellen opdateres.

Tilgangene løser forskellige problemer:

• Instruktionskløft: Modellen kunne løse opgaven, hvis den blev instrueret korrekt. → Prompting.
• Videnskløft: Modellen mangler nødvendige oplysninger. → RAG.
• Evnekløft: Modellen kan ikke løse opgaven pålideligt, selv med gode prompts og kontekst. → Finjustering.

At kende den konkrete kløft er halvdelen af løsningen.

Diagnosticér kløften

Når AI’en ikke gør det ønskede, så spørg:

Kunne en kompetent person løse opgaven alene ud fra prompten?

Hvis ja → instruktionskløft. En bedre prompt bør løse den.

Hvis nej, kunne personen løse den med relevant referencemateriale?

Hvis ja → videnskløft. RAG kan løse den.

Hvis nej, kunne personen løse den efter omfattende øvelse og feedback?

Hvis ja → evnekløft. Finjustering kan muligvis løse den.

Hvis nej → opgaven egner sig måske ikke til en LLM. Genovervej problemet.

De fleste problemer af typen “AI’en virker ikke” er instruktionskløfter — bedre prompting løser dem. Videnskløfter er næstmest almindelige. Reelle evnekløfter er den mindste kategori, men den sværeste at håndtere.

Prompting: Det undervurderede greb

Prompting er billigst og hurtigst og er oftest den rette løsning. Alligevel springer teams direkte til RAG eller finjustering.

Nogle ting, du kan opnå alene med prompting:

• Ændre tone, format og længde.
• Anvende ræsonnementsmønstre (chain-of-thought, selvkritik).
• Indkode begrænsninger (gør X, gør ikke Y).
• Indkode politikker og sikkerhedsrammer.
• Tilpasse til bestemte brugssituationer (forskellige prompts til forskellige funktioner).
• Forbedre ensartethed gennem few-shot-eksempler.

Det kan prompting ikke gøre alene:

• Få modellen til at kende fakta, den ikke har.
• Få en lille model til at opføre sig som en stor model.
• Fundamentalt ændre modellens stemme eller stil på et dybt niveau.
• Gøre modellens inferens hurtigere.

En rimelig regel er at prøve prompting først og iterere i mindst en uge, før du vælger RAG eller finjustering. Som regel viser prompting sig at løse problemet.

Arbejdet med prompt engineering

En uges intensiv promptiteration kan give markante forbedringer. Det typiske forløb:

• Dag 1: Baseline. Middelmådige resultater.
• Dag 2-3: Strukturelle ændringer. Bedre format og klarere instruktioner. Store forbedringer.
• Dag 4-5: Eksempler og kanttilfælde. Opdager fejltyper.
• Dag 6-7: Tone, begrænsninger og finpudsning. De sidste 10% forbedring.

Efter en uge har du hentet det meste af det, prompting kan give. Er du stadig utilfreds, handler kløften sandsynligvis om viden eller evne.

Sådan ser gode prompts ud

En stærk prompt har typisk:

• En klar rolle og opgave.
• Konkrete formatkrav.
• 1-5 repræsentative eksempler (om nødvendigt).
• Eksplicitte begrænsninger (hvad der skal og ikke skal gøres).
• Håndtering af kanttilfælde.
• Et outputskema.

Typisk 5-10 afsnit. Ikke for kort (utilstrækkeligt specificeret) og ikke for lang (modellen mister fokus).

RAG: Løsningen på videnskløften

RAG er det rette værktøj, når:

• Modellen mangler faktuelle oplysninger.
• Oplysningerne ændrer sig (live-data, aktuelle hændelser, kontospecifikke data).
• Oplysningerne er specifikke for dit domæne eller din organisation.
• Du har brug for kildehenvisninger/verificerbar forankring.

Det er det forkerte værktøj, når:

• Problemet handler om instruktioner, ikke viden.
• Datamængden er lille nok til at være direkte i prompten.
• Modellen skal gøre noget anderledes, ikke blot vide noget andet.

Den realistiske omkostning

Et RAG-system kræver reelt ingeniørarbejde:

• Byg: 4-12 uger til en seriøs løsning (indlæsning, opdeling, embeddings, søgning, reranking, evaluering).
• Drift: Løbende opdatering af indeks, kvalitetsovervågning og fejlrettelse.
• Infrastruktur: Vektordatabase, embedding-API og reranking. Typisk €200-2000/month for systemer i moderat skala.
• Omkostning pr. forespørgsel: Højere end kun prompting (ekstra embedding + søgning + større kontekst). Normalt 2-5x prisen for et klassisk API-kald.

Til de rette problemer er investeringen pengene værd. Men den er betydelig sammenlignet med prompting.

RAG-kvalitet er en rejse

Et fungerende RAG-system i uge 1 ligger som regel på 60-70% kvalitet. At nå produktionskvalitet (85%+) kræver yderligere 1-2 måneders arbejde: bedre opdeling, reranking, håndtering af fejltyper og evalueringer.

Planlæg det. Lancér ikke i uge 1; det giver utilfredse brugere.

Finjustering: Når prompting og RAG ikke er nok

Finjustering er det rette værktøj, når:

• Der er en tydelig evnekløft — modellen kan ikke løse opgaven pålideligt, selv med gode prompts og kontekst.
• Du har en god samling træningseksempler af høj kvalitet — mindst nogle hundrede til en meget snæver LoRA, men mere typisk 1,000+ til pålidelig generel adfærd. Se artiklen om finjustering for de konkrete tærskler pr. teknik.
• Du har brug for ensartet, snæver adfærd (en bestemt stil, et bestemt outputformat eller et bestemt domæne).
• Omkostning/latenstid ved inferens betyder noget (en mindre finjusteret model kan være billigere end en større generel model).

Det er det forkerte værktøj, når:

• Dine data ændrer sig hurtigt (den finjusterede model bliver hurtigt forældet).
• Du ikke først har udtømt mulighederne i prompting og RAG.
• Du mangler gode evalueringer (du kan ikke se, om finjusteringen hjalp).
• Opgaven kræver meget aktuelle oplysninger (finjustering er et øjebliksbillede).
• Du forsøger at lære modellen fakta (RAG gør det bedre, mere pålideligt og med kildehenvisninger).

Typer af finjustering

Fuld finjustering: Alle modelvægte opdateres. Mest effektiv og dyrest. Kræver betydelig beregningskraft. Normalt forbeholdt laboratorier, der udvikler grundmodeller.

LoRA (Low-Rank Adaptation): Kun en lille del af vægtene trænes. Langt billigere. Giver ofte resultater på niveau med fuld finjustering til snævre opgaver.

QLoRA: Kvantiseret LoRA. Endnu billigere. Lavere kvalitet i stor skala, men rimelig til mange opgaver.

Prompt tuning/prefix tuning: Endnu mindre; kun bløde prompts trænes. Billigst. Begrænset effekt.

Instruction tuning: Træner modellen til at følge instruktioner. Udføres normalt på grundmodelniveau og er sjældent relevant for slutbrugere.

RLHF/DPO/KTO: Træner modellen til at følge præferencedata (svar A kontra B). Effektivt til adfærdsændringer, men vanskeligt at udføre godt.

I 2026, hvor dette skrives, bruger de fleste teams LoRA oven på en stærk grundmodel. Det giver den bedste balance mellem omkostning og evne i de fleste brugssituationer.

Den realistiske omkostning

Omkostningen afhænger af tilgang og skala. Et typisk LoRA-forløb for en mellemstor åben model med 5K-10K eksempler:

• Dataforberedelse: 1-4 uger. Ofte hovedparten af arbejdet. Kuratering, rensning og formatering af eksempler.
• Træning: Timer til dage afhængigt af datasæt og infrastruktur. €100-2000 i beregningskraft.
• Evaluering: 1-2 uger. Opbygning af suiter og sammenligning mellem finjusteret model og grundmodel.
• Iteration: 1-3 cyklusser, før noget er produktionsklart.
• Udrulning: Enkelt med en administreret API (OpenAI fine-tuning, Anthropic, Vertex). Mere arbejde ved egen hosting.
• Vedligeholdelse: Genoptræning, når data, grundmodel eller brugssituation ændrer sig.

I alt: 6-12 ugers arbejde, €1K-€20K i beregningskraft (afhængigt af skala) og løbende vedligeholdelse.

Det er en betydelig investering. Sørg for, at den er berettiget.

Hvornår finjustering virker bedst

Konkrete scenarier, hvor finjustering klart vinder:

Strenge formatkrav. Output skal konsekvent følge et bestemt skema eller en bestemt stil. Prompting kan bringe dig 95% i mål; finjustering giver 99%.

Specialiserede domæner. Medicinsk terminologi, juridiske formuleringer eller kode i et internt DSL. Finjustering lærer modellen din specifikke dialekt.

Personlighed/stemme. En ensartet stemme i tusindvis af interaktioner. Prompts kan drive; finjustering indbygger den.

Optimering af latenstid/omkostning. En finjusteret 7B-model til din konkrete opgave kan være billigere og hurtigere end en generel 70B-model. Ved stor volumen betaler det sig.

Adfærdsmæssig sikkerhed. Finjustering til at afvise bestemte ting eller tilføje konkrete sikkerhedsforanstaltninger kan være mere robust end promptbaserede sikkerhedsrammer.

Hvornår finjustering fejler

Almindelige årsager til skuffende finjustering:

For få data. Finjustering med 100 eksempler hjælper normalt ikke meget. En meget snæver LoRA kan nogle gange fungere med nogle hundrede eksempler; til pålidelig generel adfærd bør du planlægge 1,000+ eksempler af høj kvalitet.

Dårlige data. Dårlige input giver dårlige output. Inkonsistente eksempler af lav kvalitet giver inkonsistente modeller af lav kvalitet.

Katastrofal glemsel. Kraftig finjustering på snævre opgaver kan skade generelle evner. Modellen bliver god til din opgave, men dårligere til alt andet.

Forældet viden. Den finjusterede model er et øjebliksbillede. Nye oplysninger kræver genoptræning. I dynamiske domæner er det en permanent omkostning.

Grundmodellen forbedres hurtigere end finjusteringen. Grundmodellen er blevet så meget bedre, at finjusteringen ikke længere vinder. Nu vedligeholder du en finjustering af en forældet grundmodel.

Evalueringsproblemer. Uden solide evalueringer ved du ikke, om finjusteringen hjalp, skadede eller intet ændrede. Mange “vellykkede” finjusteringer er placeboeffekter.

Kombinationsmønstrene

De bedste produktionssystemer kombinerer alle tre.

Kombination 1: RAG med stærke prompts (mest almindelig)

Standardvalget til videnstunge applikationer.

• Omhyggeligt designede prompts indkoder instruktioner, format og begrænsninger.
• RAG leverer aktuelle, specifikke oplysninger.
• Ingen finjustering; brug en stærk grundmodel.

Det er det mest almindelige produktionsmønster i 2026. Det fungerer til de fleste brugssituationer.

Kombination 2: Finjusteret model + RAG

Når både adfærdsspecialisering og dynamisk viden er nødvendige.

• Finjustér til stemme, format og domæne.
• Brug RAG til aktuelle oplysninger.
• Lad prompts orkestrere.

Eksempel: En model, der er finjusteret til en virksomheds kundesupportstemme, med RAG over aktuelle politikker og dokumentation. Finjusteringen giver den ensartede stemme; RAG leverer den skiftende viden.

Kombination 3: Specialiserede finjusteringer til konkrete opgaver

Forskellige finjusteringer til forskellige dele af et system.

• Finjustering af klassifikation til routing.
• Finjustering af opsummering til resuméer.
• Finjustering af generering til kundesvar.
• Hver model er mindre, hurtigere og specialiseret.

Bruges, når skala og omkostningsoptimering betyder noget. Hver finjustering løser sin snævre opgave godt; orkestreringen kalder dem.

Kombination 4: Finjusteret router + generelle modeller

Routeren finjusteres til pålidelig klassifikation af forespørgsler. Derefter sendes de klassificerede forespørgsler til generelle modeller, som udfører arbejdet.

Finjusteringen er lille, hurtig og snæver. Det dyre, generelle arbejde udføres af aktuelle, generelle modeller.

Det kombinerer økonomi (finjusteringen er lille) med evne (generelle modeller til det vanskelige arbejde).

Beslutningsrammen

Et praktisk beslutningsforløb:

Spørgsmål 1: Kan den nuværende model løse problemet med en god prompt?

Hvis ja: Skriv prompten. Iterér i en uge. Lancér.

Hvis nej, gå til spørgsmål 2.

Spørgsmål 2: Kræver problemet viden, som modellen mangler?

Hvis ja: Byg RAG. Brug de nødvendige måneder. Bring det op på produktionskvalitet. Kombinér med stærke prompts.

Hvis nej, gå til spørgsmål 3.

Spørgsmål 3: Handler problemet om ensartet format, et snævert domæne eller en bestemt adfærd?

Hvis ja, OG du har mindst nogle hundrede (helst 1,000+) eksempler af høj kvalitet: Finjustér. Kombinér med prompting og eventuelt RAG.

Hvis du mangler eksemplerne: Investér i at indsamle dem, ELLER arbejd videre med prompting/RAG, før du finjusterer.

Spørgsmål 4: Har du udført det evalueringsarbejde, der viser, hvilken tilgang der faktisk hjælper?

Spørgsmålet gælder ved hvert trin. Uden evalueringer gætter du.

Eksempler fra produktion

Nogle virkelige kombinationer:

Eksempel 1: AI-kundesupport

Opsætning: En SaaS-virksomheds AI til kundesupport håndterer henvendelser på niveau 1 i første omgang.

Komponenter:

• Stærke prompts til tone, format og eskaleringspolitikker.
• RAG over aktuelle dokumenter, politikker og sagshistorik.
• Let finjustering til virksomhedens stemme og eskaleringsmønstre (1,500 eksempler kurateret fra tidligere sager).

Resultat: Håndterer 65% af sagerne selvstændigt. Finjusteringen giver en ensartet stemme; RAG sikrer korrekthed; prompts håndterer politikkerne.

Eksempel 2: Gennemgang af juridiske dokumenter

Opsætning: Et legal-tech-produkt gennemgår kontrakter for risici.

Komponenter:

• Detaljerede prompts, der angiver, hvad der skal findes (juridiske kategorier, alvorlighedskriterier).
• RAG over relevant retspraksis og præcedens.
• Ingen finjustering; ræsonnementsmodeller udfører hovedarbejdet.

Resultat: Ren prompting + RAG fungerer godt, fordi modellen allerede har juridisk træning. Finjustering ville kun hjælpe marginalt; investeringen kunne ikke forsvares.

Eksempel 3: Kodefuldførelse i et tilpasset DSL

Opsætning: Et specialiseret dataværktøj med eget DSL.

Komponenter:

• Prompts med eksempler.
• Ingen RAG (DSL’et er lille nok til at være i konteksten).
• LoRA-finjustering med 10K eksempler i DSL’et.

Resultat: Finjustering var afgørende. Uden den kunne modellen ikke pålideligt producere gyldigt DSL. Prompts og kontekst var ikke nok.

Eksempel 4: Intern virksomhedsassistent

Opsætning: En generel assistent til virksomhedens medarbejdere.

Komponenter:

• Stærke systemprompts (stemme, adfærd, afvisninger).
• RAG over virksomhedens wiki, Slack og dokumenter.
• Ingen finjustering; virksomhedens “stemme” indfanges i prompts.

Resultat: RAG + prompts dækker de fleste brugssituationer. Virksomhedens stil er ikke særpræget nok til at kræve finjustering.

Fejl, vi ofte ser

Nogle mønstre for fejlallokering:

Fejl 1: Finjustering vælges først. Teams hører “vi bør finjustere vores egen model” og begynder dér. 90% af tiden havde prompting + RAG været hurtigere, billigere og lige så godt.

Fejl 2: RAG springes over, selv om det er løsningen. Teams bygger omfattende prompts for at “minde” modellen om virksomhedsoplysninger, som åbenlyst bør hentes ved forespørgslen. Hent dem i stedet.

Fejl 3: Finjustering uden evalueringer. “Vi finjusterede, og nu er den bedre.” Ingen målinger. Ofte ændrede finjusteringen intet eller gjorde resultatet værre. Uden evalueringer ved du det ikke.

Fejl 4: Forældede finjusteringer. En finjustering fra 6 måneder siden, da GPT-4 var bedst. Nutidens frontmodeller uden finjustering overgår den ældre finjusterede model. Finjusteringer skal revurderes, når feltet udvikler sig.

Fejl 5: Forsøg på at finjustere fakta ind i modellen. Teams forsøger at få modellen til at “kende vores virksomhed”. Det fungerer dårligt — modellen husker nogle fakta og hallucinerer andre. RAG håndterer fakta; finjustering håndterer adfærd.

Fejl 6: For kort iteration på prompts. To dages iteration er et udgangspunkt. To uger giver det reelle svar.

Fejl 7: Overudviklet RAG, hvor prompting var nok. Et virksomhedsdokument på 50K-token direkte i prompten er nogle gange enklere end RAG. Især ved små korpora.

Sammenligning af omkostning og indsats

En grov sammenligning for et typisk mellemstort projekt:

Det rette valg afhænger af problem og ressourcer. For de fleste teams er prompting + RAG det bedste kompromis — en meningsfuld forbedring uden den fulde investering i finjustering.

Konklusionen

Prompting, RAG og finjustering løser forskellige problemer. Det rette valg kræver en ærlig diagnose: Er det en instruktionskløft, videnskløft eller evnekløft?

Den ærlige rækkefølge er:

1. Prompting (1-2 ugers iteration). Billigst, hurtigst og oftest tilstrækkeligt.
2. RAG, hvis der er en klar videnskløft. En betydelig, men velafgrænset investering.
3. Finjustering, hvis der er en tydelig evnekløft, som prompting + RAG ikke kan lukke. Dyrest; gør det til sidst.
4. Kombinationer til modne produktionssystemer.

Teams, der lykkes, er ærlige om deres kløft og disciplinerede omkring evalueringer. Uden evalueringer kan du ikke se, hvilken tilgang der hjalp. Med dem er vejen som regel tydelig.

De fleste projekter med udgangspunktet “vi skal finjustere vores egen model” burde ved nærmere eftersyn være “vi skal skrive bedre prompts og tilføje RAG”. Gem finjustering til de tilfælde, der virkelig kræver den.

Resultatet er bedre systemer, hurtigere og til lavere pris. Det er netop formålet med at levere produktions-AI.