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.

Här är ett ramverk för valet och, viktigare, för att göra en rättvis jämförelse. Det publicerar inga universella projektkostnader eller träffsäkerhetsvinster. Huvudkällor är den ursprungliga RAG-artikeln, OpenAI:s aktuella guide för finjustering och dokumentationen för Hugging Face PEFT.

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 modellens vikter för att anpassa beteendet på en uppmätt uppgift. Det kan påverka stil, format, uppgiftsprestanda och memorerade samband. Det är däremot inget tillförlitligt eller underhållbart sätt att installera en aktuell faktadatabas.

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.

Anta inte hur vanligt varje gap är. Märk upp felen från en representativ utvärderingsmängd: instruktionsföljande, saknad eller felaktig kontext, hämtningsfel, förmågefel, policyfel eller integrationsfel nedströms. Den fördelningen visar var du bör investera.

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.

Ett rimligt första experiment är den billigaste promptbaslinjen. Tidsbegränsa den med antalet utvärderade varianter och en stoppregel – inte med en godtyckligt vald vecka. Gå vidare när ytterligare promptändringar inte längre förbättrar det undanhållna mätvärdet, eller när de bryter mot något annat krav.

Arbetsinsatsen för promptutveckling

Kör promptvarianterna mot samma tränings- och utvecklingsuppdelning och håll en testmängd undanhållen. Ändra en designdimension i taget – uppgiftskontrakt, exempel, kontext, utdataschema eller verktygsuppsättning – och notera kvalitet, latens och kostnad. Sluta när det i förväg fastställda acceptanskravet är uppfyllt eller när nästa ändring inte förbättrar utvecklingsmängden. En kalenderlängd bevisar inte att promptning är uttömd.

Så ser bra prompter ut

Promptelement som är värda att testa:

• Tydlig roll och uppgift.
• Specifika formatkrav.
• Representativa exempel när en utvärdering visar att de hjälper.
• Explicita begränsningar (vad som ska och inte ska göras).
• Hantering av gränsfall.
• Utdataschema.

Använd den kortaste prompt som bevarar det uppmätta beteendet och de nödvändiga begränsningarna. Antal stycken är inget kvalitetsmått.

RAG: lösningen på kunskapsgapet

RAG är en kandidat 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:

• Bygga: inläsning, behörigheter, uppdelning, indexering, hämtning, utvärdering och drift. Uppskatta utifrån dina egna källor och acceptanskriterier.
• Drift: löpande – hålla indexet uppdaterat, övervaka kvaliteten, åtgärda problem.
• Infrastruktur: parsning och OCR, lagring, inbäddning, hämtning, omrankning, generering, säkerhetskopior och telemetri. Prissätt dem utifrån datummärkta offerter och uppmätta volymer.
• Kostnad per fråga: kan tillkomma för frågeinbäddning, hämtning, omrankning och kontexttoken, men kan också minska bortkastad kontext eller möjliggöra en billigare genereringsmodell. Mät hela vägen.

Godkänn investeringen först när den utvärderade hämtningsvägen förbättrar det definierade utfallet tillräckligt för att motivera arbetet med inläsning, behörigheter, färskhet, latens, kostnad och drift.

RAG-kvalitet är en resa

Det finns ingen överförbar kvalitetsprocent för ”första veckan”. Sätt baslinjer för lexikal, vektorbaserad och hybrid hämtning på en märkt mängd, redovisa recall och slutsvarsmått per segment, och ändra sedan ett steg i taget. Produktionssätt först när de verksamhetsspecifika fel- och behörighetskontrollerna går igenom.

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 tillräckligt med representativa, licensierade och integritetsgranskade träningsdata för att förbättra resultatet på en undanhållen mängd. Avgör vad som räcker med en inlärningskurva, inte med ett universellt antal exempel.
• 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 har byggt en relevant baslinje med prompter, begränsade utdata, hämtning eller verktyg att jämföra mot.
• Du saknar bra utvärderingar (du kan inte avgöra om finjusteringen hjälpte).
• Uppgiften kräver mycket aktuell information (finjustering är en ögonblicksbild).
• Uppgiften i första hand kräver aktuella, hänförbara fakta. Hämtning eller auktoritativa verktyg är enklare att uppdatera och att hänvisa till än viktändringar – men de kräver ändå utvärdering.

Typer av finjustering

Fullständig finjustering: alla modellvikter kan uppdateras. Det ger den största tränbara ytan och den tyngsta bördan i beräkning och lagring, men ger inte i sig det bästa resultatet på undanhållna data.

LoRA (Low-Rank Adaptation): tränar lågrangsadaptrar medan basvikterna är frysta. Det minskar antalet tränbara parametrar och brukar minska behovet av optimeringsminne. Jämför kvalitet och stöd i serveringsledet med fullständig justering för just din uppgift.

QLoRA: bakåtpropagerar genom en fryst, kvantiserad basmodell in i LoRA-adaptrar. Det kan minska minnesbehovet. Kvaliteten är en empirisk fråga, inte en fast regel om ”sämre i stor skala”.

Promptjustering/prefixjustering: tränar kontinuerliga prompt- eller prefixparametrar. Hårdvara, leverantörsstöd, uppgiftskvalitet och integration i serveringsledet avgör om den mindre tränbara ytan är användbar.

Instruktionsjustering: övervakad anpassning på exempel av instruktion och svar. Det är vanligt i modellutveckling och kan även vara ett experiment för ett applikationsteam när modellens licens, data, infrastruktur och utvärderingar tillåter det.

RLHF/DPO/KTO: olika familjer för preferensoptimering. De är inte utbytbara och förbrukar inte alla identiska data. Utgå från primärartikeln och dokumentationen för den valda implementationen, och testa sedan belönings- och preferenskvalitet samt regressioner i säkerhet.

Parametereffektiv justering är en användbar kandidat när fullständig justering inte ryms i hårdvaru- eller iterationsbudgeten. Den här artikeln bygger inte på någon representativ kartläggning av vad de flesta team använder eller av någon universellt bästa avvägning.

Den realistiska kostnaden

Finjusteringens kostnad och varaktighet beror på basmodell, sekvenslängder, token, epoker, hårdvara, distributionsstrategi, misslyckade körningar och utvärdering. Bygg uppskattningen från en liten, instrumenterad körning:

• Dataförberedelse: proveniens, rättigheter, avduplicering, integritetsgranskning, formatering och kvalitetsmärkning.
• Träning: uppmätta token per sekund × planerade token, plus checkpointing, misslyckade körningar och lagring.
• Utvärdering: basmodell mot justerad modell på undanhållna mängder för måluppgiften, säkerheten och de generella förmågorna.
• Iteration: budgetera först efter att ni definierat vilket resultat som skulle motivera ytterligare en körning.
• Driftsättning: leverantörens tillgänglighet, servering av adaptrar, återställning, övervakning och skyldigheter kring lagringstid.
• Underhåll: omträning när data uppdateras, basmodellen uppdateras eller användningsfallet förändras.

Räkna med ingenjörs- och granskartid – enbart beräkningskraft är inte totalkostnaden. Gå vidare först när den uppmätta förbättringen är värd den fortlöpande bördan av servering och omträning.

När finjustering ger bäst resultat

Scenarier där ett finjusteringsexperiment kan vara motiverat:

Stabilt uppgiftsbeteende. Finjustering kan förbättra format eller stil på en viss fördelning, men begränsad avkodning kan redan garantera de schemaformer som stöds. Jämför en baslinje med enbart prompt, en med begränsade utdata och en justerad – i stället för att lova 95 % mot 99 %.

Specialiserat språk eller syntax. Medicinsk terminologi, juridiska formuleringar eller ett internt DSL kan förbättras på undanhållna exempel, men korrekthet med höga insatser kräver ändå extern validering, aktuella belägg och kvalificerad granskning.

Stil och röst. En justerad modell kan höja poängen i en bedömningsmatris för stil på måldistributionen. Den ”bygger inte in” perfekt konsekvens – mät innehållskvalitet, säkerhet och drift, inte bara rösten.

Experiment med latens och kostnad. En mindre justerad modell kan klara samma acceptanskrav till lägre uppmätt serveringskostnad eller latens. Räkna in träning, utvärdering, kapacitet, tillförlitlighet och underhåll innan du hävdar en vinst.

Beteendemässig anpassning. Säkerhetsjustering kan förbättra ett uppmätt avvisningsbeteende, men den kan också avvisa för mycket, för lite eller försämra andra förmågor. Den måste förbli ett lager bredvid deterministisk behörighetskontroll, policytillämpning, övervakning och mänskliga grindar.

När finjustering misslyckas

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

Otillräckliga eller icke-representativa data. Små, smala datamängder hjälper ibland, och stora brusiga datamängder skadar ibland. Rita upp resultatet på undanhållna data när träningsmängden växer och granska hur väl segmenten täcks innan du köper mer beräkningskraft.

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

Vissa produktionssystem kombinerar metoderna, men varje tillagd metod utökar ytan för utvärdering och drift.

Kombination 1: Promptad RAG

En kandidat för tillämpningar som behöver dynamisk och hänförbar kunskap.

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

Godkänn den bara om hämtningen förbättrar den definierade uppgiften och testerna för behörighet, färskhet, källhänvisning, latens, kostnad och fel går igenom.

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: bygg och utvärdera en promptbaslinje. Leverera bara om acceptans- och säkerhetskriterierna går igenom.

Om nej, gå till fråga 2.

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

Om ja: jämför direkt kontext, lexikal hämtning, vektorhämtning och hybridhämtning efter vad som är relevant. Uppskatta implementationen efter att du kartlagt källor och behörigheter.

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 representativa data med nödvändiga rättigheter och integritetskontroller: kör ett litet finjusteringsexperiment och jämför det med den oförändrade baslinjen.

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

Illustrativa kombinationer (inte uppmätta fallstudier):

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).

Utfall (illustrativt scenario): Hanterar en stor andel av nivå 1-ärendena självständigt, mätt mot det teamets utvärderingsmängd. 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.

Beslutskriterium: jämför recall på klausulnivå, falsk trygghet, korrekta källhänvisningar, täckning av jurisdiktioner och granskning av kvalificerad jurist. Ingen metod godkänns för juridisk tillit enbart för att en basmodell har sett juridisk text.

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).
• En rättighetsklarerad träningsmängd vars storlek väljs utifrån täckning och en inlärningskurva, inte utifrån ett kopierat antal exempel.

Beslutskriterium: jämför parsningsframgång, semantisk korrekthet och exekveringssäkerhet för promptade och justerade versioner på undanhållna program. Den illustrativa uppsättningen visar inte att finjustering är nödvändig för ett verkligt DSL.

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.

Beslutskriterium: jämför varianter med enbart prompt respektive med hämtning på korrektheten i aktuella svar, källhänvisningar, behörigheter, avståenden, latens, kostnad och granskad stil. Finjustera först om ett kvarstående, värdefullt beteendegap kan visas.

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. Testa baslinjer med prompter och hämtning först – många skenbara finjusteringsproblem är instruktions- eller kontextproblem, och baslinjen ger dig underlaget för beslutet.

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.” Utan en undanhållen baslinje och resultat per segment går förändringen inte att hänföra, och regressioner förblir dolda.

Misstag 4: Inaktuella finjusteringar. Basmodeller, serveringsstackar, data och produktkrav förändras. Kör om den oförändrade baslinjen och acceptanssviten innan du tränar om eller fortsätter servera en adapter.

Misstag 5: Behandla vikterna som en aktuell databas. Träning kan skapa memorerade samband utan garantier för uppdatering, proveniens eller radering. Håll auktoritativa fakta i styrda källor eller verktyg och testa hämtningen. Använd justering för ett påvisat uppgiftsbeteende, inte som system of record.

Misstag 6: Ingen stoppregel för promptning. Att iterera utan en undanhållen mängd kan överanpassa mot exemplen i all oändlighet. Sluta eller eskalera när de i förväg fastställda mätvärdena planar ut.

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

Ett jämförelseunderlag – fyll det med uppmätta eller offererade värden för samma acceptanskrav:

Rätt val beror på det uppmätta gapet och på hela driftmodellen. Promptning plus hämtning är vanligt för dynamisk kunskap, men det är ingen universell optimal punkt.

Välj gapet först, verktyget sedan

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

Ordningen att prova dem i:

1. Bygg den enklaste relevanta baslinjen. Ofta är det promptning eller begränsade utdata, men en baslinje med hämtning eller verktyg kan vara enklare när fakta redan finns i ett auktoritativt system.
2. Lägg till hämtning vid ett påvisat gap i belägg eller färskhet, och utvärdera sedan hela vägen genom inläsning, behörigheter, hämtning och generering.
3. Kör ett finjusteringsexperiment vid ett påvisat gap i beteende eller uppgiftsprestanda, när rättighetsklarerade och representativa data finns och serveringsledet stöder det.
4. Kombinera metoder först när varje komponent ger en uppmätt tilläggsvinst som är värd sin operativa yta.

Utan undanhållna utvärderingar går det inte att hänföra vilken metod som hjälpte. Dokumentera gapet, baslinjen, acceptanskriterierna, de segment som påverkas negativt, hela kostnaden och återställningsvägen innan du väljer verktyg.