Fine-tuning vs RAG vs prompting: Beslutsmatris för svenska företag

När ett företag vill få en LLM att göra exakt vad de behöver landar samtalet snabbt i tre ord: prompting, RAG och fine-tuning. Och nästan lika snabbt i en missuppfattning - att de är konkurrerande alternativ man väljer mellan, och att fine-tuning är det "riktiga" valet medan resten är genvägar. Det stämmer inte. De löser olika problem, har helt olika kostnad och underhåll, och i de allra flesta fall ska de provas i en bestämd ordning. Att hoppa direkt till fine-tuning är ett av de vanligaste och dyraste misstagen jag ser.

Jag hjälper svenska bolag att välja rätt LLM-strategi inom AI Engineering, och här är beslutsmatrisen jag använder, från enklast till tyngst.

Prompting: börja alltid här

Prompting är att styra modellen med instruktioner, exempel och struktur - utan att ändra modellen själv. Det är billigast, snabbast och mest flexibelt: du kan iterera på minuter och ändra beteendet utan att träna om något. Förvånansvärt ofta räcker det hela vägen. Med en genomtänkt systeminstruktion, några välvalda exempel och tydlig struktur löser moderna modeller mer än de flesta tror. Min regel är enkel: uttöm prompting innan du ens överväger något tyngre. Om du inte fått ut det modellen kan med en bra prompt vet du inte ens vad ditt verkliga problem är.

RAG: när modellen saknar din kunskap

Prompting hjälper inte om modellen inte känner till er specifika information - era produkter, era dokument, er senaste data. Det är vad RAG (Retrieval-Augmented Generation) löser: du hämtar relevant information vid frågetillfället och ger den till modellen som kontext. Det är rätt verktyg när problemet är kunskap, inte beteende. RAG har två stora fördelar: informationen är alltid aktuell eftersom den hämtas live, och du kan visa källan till varje svar. För de allra flesta "AI som kan vår data"-projekt är RAG svaret - inte fine-tuning, vilket många tror.

Fine-tuning: när beteendet måste ändras

Fine-tuning tränar faktiskt om modellen på era exempel och förändrar dess grundbeteende. Det är det dyraste och mest underhållskrävande alternativet, och det löser ett smalare problem än folk tror. Det lyser när du behöver en konsekvent stil eller ett format som är svårt att beskriva i en prompt, när du vill destillera ett beteende till en mindre och billigare modell, eller när du har stora mängder högkvalitativa exempel på exakt det utfall du vill ha. Det löser däremot inte kunskapsproblem - en finjusterad modell vet fortfarande inget om data den inte sett, och att försöka stoppa in fakta via fine-tuning är både dyrt och opålitligt.

• Behöver modellen veta saker den inte vet? Då är det RAG, inte fine-tuning.
• Behöver modellen bete sig eller låta annorlunda? Då kan fine-tuning vara rätt - efter att prompting prövats.
• Vill du bara styra utfallet här och nu? Då är prompting nästan alltid tillräckligt.

De kombineras - och det är ofta svaret

I praktiken är det sällan antingen-eller. Ett moget system använder ofta alla tre: prompting styr beteendet, RAG förser modellen med aktuell kunskap, och fine-tuning kan ligga underst för att ge en konsekvent stil eller köra en billigare modell. Att se dem som lager som bygger på varandra, snarare än som tävlande alternativ, är nyckeln. Men varje lager ska motiveras av att det föregående inte räckte - inte läggas till för säkerhets skull.

Beslutsregeln, kort

Börja med prompting och pressa det ordentligt. Når du gränsen för att modellen saknar din kunskap, lägg till RAG. Behöver du fortfarande ändra hur modellen beter sig eller låter, överväg fine-tuning sist. Den ordningen sparar er pengar, tid och underhåll, och ser till att ni inte bygger en komplex finjusteringspipeline för ett problem en bra prompt hade löst på en eftermiddag. Komplexitet ska förtjänas, inte antas.

Relaterat

• LangGraph vs n8n vs Temporal: När välja vad för agentiska workflows
• RAG-arkitektur 2026: Från naiv chunking till hybrid retrieval med rerankers
• Anthropic Claude Sonnet 4.5 i enterprise: Säkerhet, kostnad och guardrails

Ett exempel på ett system som kombinerar metoderna finns i kundcase.

Vill du ta det vidare?

Jag hjälper svenska bolag att välja rätt LLM-strategi - och att inte bygga en fine-tuning-pipeline för ett problem prompting eller RAG löser. Boka ett förutsättningslöst samtal så går vi igenom ert use case.