
RAG eller finjustering? Forkerte data kan gøre begge valg dyrere

Vælg RAG, når virksomhedens svar skal bygge på dokumenter, der ændrer sig, eller når brugeren skal kunne se den relevante kilde. Vælg finjustering, når opgaven og oplysningerne er stabile, men modellen skal levere et bestemt format eller en mere ensartet fremgangsmåde. Begge valg kan blive dyrere, hvis søgningen henter forkerte afsnit, eller træningseksemplerne lærer modellen et mønster, som ikke passer til arbejdet.
Det første spørgsmål er derfor, om modellen mangler viden, eller om den bruger den viden, den allerede har, forkert. OpenAI's vejledning om modelpræcision skelner mellem manglende eller forældet kontekst og ustabil adfærd; den beskriver også, hvordan irrelevant hentet tekst og træningseksempler, der ikke ligner virkelige opgaver, kan forringe svarene. En grundmodel med en enkel prompt giver et sammenligningspunkt, før virksomheden betaler for mere teknik.
Opdaterbar viden og kildekrav taler for RAG

RAG finder relevante passager i et eksternt dokumentgrundlag og føjer dem til modellens prompt, når spørgsmålet stilles. Det er nyttigt ved spørgsmål om interne regler, produktinformation og procedurer, som ændres uden at modellen skal trænes igen. AWS' sammenligning af metoderne anbefaler RAG som udgangspunkt til spørgsmål over egne dokumenter med kildehenvisninger; finjustering nævnes til yderligere opgaver som sammenfatning.
Opdaterbarheden kræver dog, at nye dokumentversioner faktisk bliver indlæst, og at udgåede versioner ikke længere kan vælges som grundlag. Et svar med et præcist citat fra en gammel procedure kan stadig være forkert. Ved adgangsbegrænsede dokumenter skal søgningen desuden respektere brugerens rettigheder, så en korrekt passage ikke hentes til den forkerte modtager.
RAG har to adskilte kvalitetstrin: Søgningen skal finde den rigtige passage, og modellen skal bruge den korrekt. Hvis et næsten relevant afsnit kommer øverst, hjælper en velformuleret prompt kun begrænset; for meget uvedkommende tekst kan skjule den afgørende oplysning. Kildehenvisninger gør svaret lettere at efterprøve, men de beviser ikke, at konklusionen følger af passagen.
Stabilt svarmønster taler for finjustering
Finjustering ændrer modellens adfærd ved hjælp af eksempler på input og ønskede svar. Metoden passer til tilbagevendende klassifikation, et fast outputformat eller en bestemt måde at sammenfatte på, hvis almindelige instruktioner og få eksempler i prompten ikke giver tilstrækkelig konsistens. Her er det afgørende, at træningseksemplerne ligner de opgaver, modellen senere får, også når de er besværlige eller tvetydige.
Hvis et datasæt kun rummer entydige eksempler, kan modellen komme til at svare for sikkert på situationer, hvor den burde bede om afklaring. Fejl i facit bliver en del af den adfærd, træningen belønner. Derfor bør eksemplerne gennemgås for uenighed, forældede regler og manglende variation, før resultatet vurderes på spørgsmål, som ikke indgik i træningen.
Finjustering er mindre egnet som eneste løsning, hvis svaret skal afspejle den seneste dokumentversion. Når oplysningerne ændres, skal datasæt og model muligvis opdateres, mens det stadig kan være vanskeligt at pege på den konkrete passage bag et svar. Den løbende vedligeholdelse hører med i regnestykket, selv om et enkelt modelkald ser billigt ud.
Industriforsøget viser, hvorfor grundmodellen tæller

Et industriforsøg med data fra BMW Group fandt RAG mest omkostningseffektivt på bilmanualer og kvalitetsregistreringer, mens en dyrere grundmodel uden tilpasning var mere økonomisk end en billigere på manualerne; på kvalitetsregistreringerne nåede en grundmodel i et eksempel 1,43 dollar pr. løst opgave mod antagne 1 dollar for et manuelt svar. Forsøget sammenlignede grundmodeller, RAG, finjustering og kombinationer. Beregningen medregnede modelkald, gentagelser, menneskelig kontrol og manuelt arbejde, når systemet ikke løste opgaven.
De hentede passager gjorde RAG dyrere at køre pr. forespørgsel, men flere korrekte svar mindskede behovet for gentagelser og menneskelige indgreb i de undersøgte opsætninger. En billig model kan tilsvarende koste mere samlet, hvis dens svar kræver hyppigere kontrol. Derfor bør den uændrede grundmodel indgå i sammenligningen på lige fod med de tilpassede løsninger.
Spørgsmål og facit blev dannet syntetisk ud fra virksomhedens materiale, og korrekthed blev bedømt med en anden sprogmodel. Prisen for menneskelig kontrol og manuelt svar indgik som antagelser, ikke som målte timer hos brugere. Resultatet viser en relevant omkostningsmekanisme, men vinderen kan skifte med andre dokumenter, spørgsmål og kontrolkrav.
Trafik og menneskelig kontrol ændrer prisen
RAG kræver indlæsning, indeksering og søgning, og de hentede passager øger ofte antallet af inputtokens pr. svar. Finjustering kræver kuraterede eksempler, træning og senere genoptræning, når opgaven ændres. Den indledende udgift fordeles på trafikken: Ved få forespørgsler vejer opsætningen tungt, mens mange ensartede forespørgsler kan gøre et kortere, stabilt svarmønster mere værdifuldt.
Sammenlign derfor pris pr. accepteret svar frem for pris pr. modelkald. Medregn afviste svar, nye forsøg, svartid og den tid, en medarbejder bruger på at kontrollere eller rette resultatet. Hvis hvert svar under alle omstændigheder skal godkendes, er gevinsten den kontroltid, som en bedre opsætning faktisk sparer; hvis nogle svar kan bruges direkte, må acceptgrænsen afspejle konsekvensen af en fejl.
Et beslutningstræ for virksomhedens egne data
- Mangler modellen oplysninger fra egne dokumenter? Sammenlign en grundmodel med en RAG-løsning på realistiske spørgsmål, og se, om søgningen finder de nødvendige passager.
- Ændres oplysningerne ofte, eller kræves en kilde til hvert svar? Giv RAG forrang, og medregn versionsstyring og adgang til dokumenterne.
- Er viden til stede, men format eller opgaveløsning svinger? Prøv tydelige instruktioner og få eksempler først; overvej finjustering, hvis fejlen stadig er væsentlig.
- Er trafikken høj, eller kræver svarene meget kontrol? Sammenlign samlet pris og accepteret kvalitet ved den belastning, løsningen faktisk skal klare.
- Forekommer begge fejltyper? Evaluer en kombination, hvor RAG leverer den aktuelle kilde, og en finjusteret model lærer at bruge konteksten konsekvent.
Brug samme særskilte testsæt til grundmodel, RAG, finjustering og en eventuel kombination. Mål både om svaret er korrekt, om en angivet passage faktisk støtter det, og hvor meget arbejde der kræves for at godkende resultatet. Kombinationen er kun et bedre valg, hvis den ekstra kompleksitet giver en målbar gevinst på netop de spørgsmål, virksomheden skal besvare.
Læs også:
Relaterede artikler


Sikr RAG mod prompt injection: Tre lag slog ét filter klart

Harvest eller Everhour? Fem sæder kan gøre den billige plan dyrere

LangChain eller LlamaIndex til RAG? Overhead er kun halvdelen af valget

Cohere Embed 5 deler indeks mellem Pro og Fast – migreringen kræver egen test

Google løfter kilderne i AI-søgning – officielle links får en topplacering
Tilmeld dig vores nyhedsbrev
Få de seneste nyheder om Web3, AI og krypto direkte i din indbakke.