Välj mellan promptning, RAG och finjustering (och när de bör kombineras)

Ett team får uppdraget: ”Gör vår AI bättre på att hantera vårt specifika användningsfall.” De har några alternativ. De kan skriva bättre prompter. De kan bygga ett RAG-system som förser modellen med relevanta data. De kan finjustera modellen på exempel från sin domän.

Dessa är inte utbytbara. De löser olika problem. Gör du fel kan du lägga tre månader och en budget på finjustering när lösningen var en bättre prompt. Eller bygga avancerad RAG-infrastruktur när finjustering hade varit enklare. Eller fastna i prompter när modellen i grunden inte kan göra det du behöver.

Den här artikeln ger ett ramverk för valet – när respektive metod är rätt verktyg, när de bör kombineras, de realistiska kostnaderna och vad som brukar gå rätt respektive fel i produktion.

Vad de faktiskt gör

En tydlig distinktion:

Promptning ändrar vad modellen ombeds göra. Du ger modellen bättre instruktioner, exempel, formatkrav och kontext. Modellen förändras inte; indata gör det.

RAG ändrar vilka data modellen ser. Du hämtar relevant information vid frågetillfället och inkluderar den i prompten. Modellen får aktuella, specifika och dynamiska data utan att tränas på dem.

Finjustering ändrar vad modellen kan eller hur den beter sig. Du tränar modellen på exempel och modifierar dess vikter. Själva modellen uppdateras.

De löser olika problem:

• Instruktionsgap: modellen skulle kunna utföra uppgiften om den tillfrågades på rätt sätt. → Promptning.
• Kunskapsgap: modellen behöver information som den saknar. → RAG.
• Förmågegap: modellen kan inte utföra uppgiften tillförlitligt ens med bra prompter och kontext. → Finjustering.

Att veta vilket gap du har är halva arbetet.

Diagnostisera gapet

När AI:n inte gör det du behöver, fråga:

Skulle en intelligent person kunna utföra uppgiften enbart utifrån prompten?

Om ja → instruktionsgap. En bättre prompt bör lösa det.

Om nej, skulle personen kunna göra det med relevant referensmaterial?

Om ja → kunskapsgap. RAG kan lösa det.

Om nej, skulle personen kunna göra det efter omfattande övning och återkoppling?

Om ja → förmågegap. Finjustering kan lösa det.

Om nej → uppgiften kanske inte går att lösa med en LLM. Ompröva problemet.

De flesta problem av typen ”AI:n fungerar inte” är instruktionsgap – bättre promptning löser dem. Kunskapsgap är näst vanligast. Verkliga förmågegap är den minsta kategorin men svårast att åtgärda.

Promptning: det underskattade verktyget

Promptning är billigast, snabbast och oftast rätt svar. Ändå hoppar team förbi den till RAG eller finjustering.

Några saker du kan göra enbart med promptning:

• Ändra ton, format och längd.
• Tillämpa resonemangsmönster (tankekedja, självkritik).
• Koda begränsningar (gör X, gör inte Y).
• Koda policyer och skyddsräcken.
• Anpassa till specifika användningsfall (olika prompter för olika funktioner).
• Förbättra konsekvensen med few-shot-exempel.

Vad du inte kan göra enbart med promptning:

• Få modellen att känna till fakta den saknar.
• Få en liten modell att bete sig som en stor.
• I grunden förändra modellens röst eller stil på djupet.
• Öka modellens inferenshastighet.

En rimlig regel: prova promptning först och iterera i minst en vecka innan du tar till RAG eller finjustering. Oftast upptäcker du att promptning löser problemet.

Arbetsinsatsen för promptutveckling

En veckas intensiv promptiteration kan ge dramatiska förbättringar. Den typiska kurvan:

• Dag 1: baslinje. Mediokra resultat.
• Dag 2–3: strukturella förändringar. Bättre format, tydligare instruktioner. Stora förbättringar.
• Dag 4–5: exempel och gränsfall. Fångar fellägen.
• Dag 6–7: ton, begränsningar, finslipning. Den sista förbättringen på 10 %.

Efter en vecka har du fått ut det mesta som promptning kan ge. Om du fortfarande inte är nöjd gäller gapet sannolikt kunskap eller förmåga.

Så ser bra prompter ut

Som referens innehåller en stark prompt normalt:

• Tydlig roll och uppgift.
• Specifika formatkrav.
• 1–5 representativa exempel (vid behov).
• Explicita begränsningar (vad som ska och inte ska göras).
• Hantering av gränsfall.
• Utdataschema.

Vanligen 5–10 stycken. Inte för kort (underspecificerad), inte för lång (modellen tappar fokus).

RAG: lösningen på kunskapsgapet

RAG är rätt verktyg när:

• Modellen behöver faktauppgifter som den saknar.
• Informationen förändras (live-data, aktuella händelser, kontospecifika data).
• Informationen är specifik för din domän eller organisation.
• Du behöver källhänvisningar/verifierbar förankring.

Det är fel verktyg när:

• Problemet gäller instruktioner, inte kunskap.
• Datamängden är tillräckligt liten för att rymmas direkt i en prompt.
• Du behöver att modellen gör något annorlunda, inte bara känner till något annat.

Den realistiska kostnaden

Ett RAG-system kräver verkligt utvecklingsarbete:

• Byggtid: 4–12 veckor för ett seriöst system (inläsning, uppdelning, inbäddning, hämtning, omrankning, utvärdering).
• Drift: löpande – hålla indexet uppdaterat, övervaka kvaliteten, åtgärda problem.
• Infrastruktur: vektordatabas, API-kostnader för inbäddning, kostnader för omrankning. Vanligen 200–2 000 euro/månad för system i måttlig skala.
• Kostnad per fråga: högre än enbart promptning (ytterligare inbäddning + hämtning + större kontextkostnad). Vanligen 2–5 gånger kostnaden för ett klassiskt API-anrop.

Det är väl värt det för rätt problem. Men jämfört med promptning är det en betydande investering.

RAG-kvalitet är en resa

Ett fungerande RAG-system under vecka 1 har vanligen 60–70 % kvalitet. Att nå produktionsklass (85 %+) kräver ytterligare 1–2 månaders arbete: förbättra uppdelningen, lägga till omrankning, åtgärda fellägen och bygga utvärderingar.

Planera för det. Produktionssätt inte vecka 1; du får arga användare.

Finjustering: när promptning och RAG inte räcker

Finjustering är rätt verktyg när:

• Du har ett tydligt förmågegap – modellen kan inte utföra uppgiften tillförlitligt ens med bra prompter och kontext.
• Du har en bra uppsättning högkvalitativa träningsexempel – minst några hundra för en mycket smal LoRA, mer typiskt 1 000+ för ett tillförlitligt generellt beteende. Se artikeln om finjustering för exakta trösklar per teknik.
• Du behöver ett konsekvent, smalt beteende (en specifik stil, ett specifikt utdataformat, en specifik domän).
• Inferenskostnad/latens spelar roll (en mindre finjusterad modell kan vara billigare än en större generell modell).

Det är fel verktyg när:

• Dina data förändras (den finjusterade modellen blir snabbt inaktuell).
• Du inte först har uttömt möjligheterna med promptning och RAG.
• Du saknar bra utvärderingar (du kan inte avgöra om finjusteringen hjälpte).
• Uppgiften kräver mycket aktuell information (finjustering är en ögonblicksbild).
• Du försöker lära in fakta (RAG gör det bättre, mer tillförlitligt och med källhänvisningar).

Typer av finjustering

Fullständig finjustering: alla modellvikter uppdateras. Kraftfullast, dyrast. Kräver betydande beräkningsresurser. Vanligen förbehållet laboratorier som utvecklar grundmodeller.

LoRA (Low-Rank Adaptation): endast en liten delmängd av vikterna tränas. Mycket billigare. Ger ofta resultat i nivå med fullständig finjustering för smala uppgifter.

QLoRA: kvantiserad LoRA. Ännu billigare. Lägre kvalitet i stor skala, men rimlig för många uppgifter.

Promptjustering/prefixjustering: ännu mindre; endast mjuka prompter tränas. Billigast. Begränsad förmåga.

Instruktionsjustering: träning av modellen att följa instruktioner. Görs vanligen på grundmodellnivå och är sällan användbart för slutanvändare.

RLHF/DPO/KTO: träning för att anpassa modellen till preferensdata (svar A jämfört med B). Kraftfullt för beteendeförändringar; svårt att göra väl.

År 2026 använder de flesta team som finjusterar LoRA ovanpå en stark basmodell. För de flesta användningsfall ger det rätt balans mellan kostnad och förmåga.

Den realistiska kostnaden

Kostnaden beror på metod och skala, men för LoRA-finjustering av en mellanstor öppen modell på 5 000–10 000 exempel är följande typiskt:

• Dataförberedelse: 1–4 veckor. Ofta huvuddelen av arbetet. Urval, rensning och formatering av exempel.
• Träning: timmar till dagar beroende på datamängd och infrastruktur. 100–2 000 euro i beräkningskostnad.
• Utvärdering: 1–2 veckor. Bygga utvärderingssviter, jämföra finjusterad modell med basmodell.
• Iteration: 1–3 cykler innan något är produktionsklart.
• Driftsättning: enkelt vid ett hanterat API (OpenAI fine-tuning, Anthropic, Vertex). Mer arbete vid egen drift.
• Underhåll: omträning när data uppdateras, basmodellen uppdateras eller användningsfallet förändras.

Totalt: 6–12 veckors arbete, 1 000–20 000 euro i beräkningskostnad (beroende på skala), löpande underhåll.

En betydande investering. Säkerställ att den är motiverad.

När finjustering ger bäst resultat

Specifika scenarier där finjustering tydligt vinner:

Strikta formatkrav. Utdata måste konsekvent följa ett specifikt schema eller en viss stil. Promptning kan ta dig 95 % av vägen; finjustering tar dig till 99 %.

Specialiserade domäner. Medicinsk terminologi, juridiska formuleringar, kod i ett internt DSL. Finjustering lär modellen din specifika dialekt.

Personlighet/röst. En konsekvent röst över tusentals interaktioner. Prompter kan glida; finjustering bygger in den.

Optimering av latens/kostnad. En finjusterad 7B-modell som hanterar din specifika uppgift kan vara billigare och snabbare än en generell 70B-modell. Vid stora volymer lönar det sig.

Beteendemässig säkerhet. Att finjustera modellen för att vägra vissa saker eller lägga till specifika skydd kan vara robustare än promptbaserade skyddsräcken.

När finjustering misslyckas

Vanliga sätt som finjustering gör användarna besvikna på:

Otillräckliga data. Finjustering på 100 exempel hjälper vanligen inte mycket. En mycket smal LoRA kan ibland fungera med några hundra exempel; planera för 1 000+ högkvalitativa exempel för ett tillförlitligt generellt beteende.

Dåliga data. Skräp in, skräp ut. Inkonsekventa exempel med låg kvalitet ger inkonsekventa modeller med låg kvalitet.

Katastrofal glömska. Omfattande finjustering på smala uppgifter kan skada generella förmågor. Modellen blir bra på din uppgift men sämre på allt annat.

Inaktuell kunskap. Den finjusterade modellen är en ögonblicksbild. Ny information kräver omträning. För dynamiska domäner är detta en ständig kostnad.

Basmodellens förbättringar springer förbi finjusteringen. Basmodellen förbättras så mycket att finjusteringen inte längre är bättre. Nu underhåller du en finjustering av en föråldrad bas.

Utvärderingsproblem. Utan robusta utvärderingar vet du inte om finjusteringen hjälpte, skadade eller inte hade någon effekt. Många ”lyckade” finjusteringar är placeboresultat.

Kombinationsmönstren

I produktion kombinerar de bästa systemen alla tre.

Kombination 1: Promptad RAG (vanligast)

Standardvalet för kunskapstunga tillämpningar.

• Noggrant utformade prompter kodar instruktioner, format och begränsningar.
• RAG tillhandahåller aktuell, specifik information.
• Ingen finjustering; förlita dig på en stark basmodell.

Detta är det vanligaste produktionsmönstret 2026. Det fungerar för de flesta användningsfall.

Kombination 2: Finjusterad modell + RAG

När du behöver både beteendespecialisering och dynamisk kunskap.

• Finjustera för röst, format och domän.
• RAG för aktuell information.
• Prompter orkestrerar.

Exempel: en modell som finjusterats för ett specifikt företags kundsupportsröst, med RAG över aktuella policyer och dokumentation. Finjusteringen ger den konsekventa rösten; RAG hanterar den föränderliga kunskapen.

Kombination 3: Specialiserade finjusteringar för specifika uppgifter

Olika finjusteringar för olika delar av ett system.

• Klassificeringsfinjustering för routning.
• Sammanfattningsfinjustering för sammanställningar.
• Genereringsfinjustering för kundsvar.
• Var och en mindre, snabbare och specialiserad.

Används när skala och kostnadsoptimering spelar roll. Varje finjustering gör sin smala uppgift väl; orkestreringen anropar dem.

Kombination 4: Finjusterad router + generella modeller

Routern finjusteras för att klassificera frågor tillförlitligt. Efter klassificeringen går frågorna till generella modeller för själva arbetet.

Finjusteringen är liten, snabb och smal. Det dyra generella arbetet utförs av generella modeller som hålls aktuella.

Det kombinerar ekonomi (finjusteringen är liten) med förmåga (generella modeller för det svåra arbetet).

Beslutsramverket

Ett praktiskt beslutsflöde:

Fråga 1: Går problemet att lösa med den aktuella modellen och en bra prompt?

Om ja: skriv prompten. Iterera i en vecka. Leverera.

Om nej, gå till fråga 2.

Fråga 2: Innefattar problemet kunskap som modellen saknar?

Om ja: bygg RAG. Lägg månaderna. Få upp det till produktionskvalitet. Kombinera med starka prompter.

Om nej, gå till fråga 3.

Fråga 3: Gäller problemet konsekvent format, en smal domän eller specifikt beteende?

Om ja, OCH du har minst flera hundra (helst 1 000+) högkvalitativa exempel: finjustera. Kombinera med promptning och eventuellt RAG.

Om du saknar exemplen: investera i att samla in dem ELLER fortsätt prova bättre promptning/RAG före finjustering.

Fråga 4: Har du gjort utvärderingsarbetet som krävs för att veta vilken metod som faktiskt hjälper?

Frågan gäller i varje steg. Utan utvärderingar gissar du.

Produktionsexempel

Några verkliga kombinationer:

Exempel 1: AI-kundsupport

Konfiguration: Ett SaaS-företags AI-kundsupport hanterar supportärenden på nivå 1.

Komponenter:

• Starka prompter för ton, format och eskaleringspolicyer.
• RAG över aktuell dokumentation, policyer och ärendehistorik.
• Lätt finjustering på företagets specifika röst och eskaleringsmönster (1 500 exempel, utvalda ur tidigare ärenden).

Resultat: Hanterar 65 % av ärendena självständigt. Finjusteringen står för den konsekventa rösten, RAG håller svaren korrekta och prompterna hanterar policyerna.

Exempel 2: Granskning av juridiska dokument

Konfiguration: En legaltech-produkt granskar avtal efter risker.

Komponenter:

• Detaljerade prompter som kodar vad som ska sökas (juridiska kategorier, allvarlighetsgrad).
• RAG över relevant rättspraxis och prejudikat.
• Ingen finjustering; resonemangsmodeller gör det tunga arbetet.

Resultat: Ren promptning + RAG fungerar väl eftersom modellen redan har juridisk träning. Finjustering skulle ge en marginell förbättring; investeringen kunde inte motiveras.

Exempel 3: Kodkomplettering i ett anpassat DSL

Konfiguration: Ett specialiserat dataverktyg med ett eget DSL.

Komponenter:

• Prompter med exempel.
• Ingen RAG (DSL:et är tillräckligt litet för att rymmas i kontexten).
• LoRA-finjustering på 10 000 exempel i DSL:et.

Resultat: Finjustering var avgörande. Utan den kunde modellen inte tillförlitligt producera giltigt DSL. Prompter och kontext räckte inte.

Exempel 4: Intern företagsassistent

Konfiguration: En generell assistent för företagets medarbetare.

Komponenter:

• Starka systemprompter (röst, beteende, vägran).
• RAG över företagets wiki, Slack och dokument.
• Ingen finjustering; företagets ”röst” fångas i prompter.

Resultat: RAG + prompter hanterar de flesta användningsfallen. Företaget är inte tillräckligt särpräglat för att behöva finjustera rösten.

Misstag vi ser

Några mönster av felallokering:

Misstag 1: Finjustering först. Team hör ”vi borde finjustera vår egen modell” och börjar där. I 90 % av fallen hade promptning + RAG varit snabbare, billigare och lika bra.

Misstag 2: Hoppa över RAG när det är lösningen. Team bygger komplicerade prompter för att ”påminna” modellen om företagsinformation som uppenbart borde hämtas vid frågetillfället. Det är bättre att helt enkelt hämta den.

Misstag 3: Finjustera utan utvärderingar. ”Vi finjusterade och nu är den bättre.” Inga mätvärden. Ofta gjorde finjusteringen ingenting eller rentav skadade. Utan utvärderingar vet du inte.

Misstag 4: Inaktuella finjusteringar. En finjustering från 6 månader sedan, när GPT-4 var bäst. Dagens frontlinjemodeller utan finjusteringen överträffar den äldre finjusterade modellen. Finjusteringar måste utvärderas på nytt när området utvecklas.

Misstag 5: Försöka finjustera in fakta. Team försöker finjustera modellen för att ”känna till vårt företag”. Det fungerar dåligt – modellen memorerar vissa fakta och hallucinerar andra. RAG hanterar fakta; finjustering hanterar beteende.

Misstag 6: Inte iterera tillräckligt länge på prompter. Två dagars promptiteration är en startpunkt. Två veckor ger det verkliga svaret.

Misstag 7: Överkonstruera RAG när promptning räcker. Ett företagsdokument på 50 000 token som läggs direkt i prompten är ibland enklare än RAG. Särskilt för små korpusar.

Jämförelse av kostnad och arbetsinsats

En grov jämförelse för ett typiskt mellanstort projekt:

Rätt val beror på ditt problem och dina resurser. För de flesta team är promptning + RAG den optimala avvägningen – en meningsfull förmågeökning utan hela investeringen i finjustering.

Slutsatsen

Promptning, RAG och finjustering löser olika problem. Rätt val kräver en ärlig diagnos: är detta ett instruktionsgap, ett kunskapsgap eller ett förmågegap?

Den ärliga ordningen att prova dem i:

1. Promptning (1–2 veckors iteration). Billigast, snabbast och oftast tillräckligt.
2. RAG om det finns ett tydligt kunskapsgap. Betydande men väl avgränsad investering.
3. Finjustering om det finns ett tydligt förmågegap som promptning + RAG inte kan överbrygga. Dyrast; gör det sist.
4. Kombinationer för mogna produktionssystem.

Team som lyckas är ärliga om vilket gap de har och disciplinerade med utvärderingar. Utan utvärderingar kan du inte avgöra vilken metod som hjälpte. Med dem är vägen vanligen tydlig.

De flesta projekt av typen ”vi måste finjustera vår egen modell” borde vid närmare granskning vara ”vi måste skriva bättre prompter och lägga till RAG”. Spara finjusteringen till fallen som verkligen behöver den.

Resultatet: bättre system, snabbare och till lägre kostnad. Det är vad leverans av produktionsklar AI ska handla om.