Når RAG ikke virker, er det sjældent modellen der er problemet

Fra teori til praksis med RAG

Teorien bag Retrieval Augmented Generation er ligetil. Du kobler en ekstern vidensbase til en sprogmodel for at sikre præcise og aktuelle svar. Men virkeligheden rammer ofte hårdt, når flowet skal bygges, og datakilderne skal vælges.

Teori betaler ikke regninger.

Mange virksomheder ender med en halvautomatisk proces, der kræver mere manuel kontrol end forventet. Hos Lynpadden arbejder vi på at få disse systemer til at kræve så lidt manuelt arbejde som muligt. I vores case om lead research og personlige mails reducerede vi tidsforbruget til kun to minutter per lead. Det er her, værdien ligger.

Nøglen er ikke mængden af data, men relevansen. Du skal hente de rigtige oplysninger på det rigtige tidspunkt.

Dårlig chunking er ofte den største barriere. Hvis dokumenter skæres i tilfældige bidder uden kontekst, modtager modellen ufuldstændige informationer. Det hjælper ikke at opgradere til en dyrere model, hvis fundamentet er skævt. Strukturering af kildematerialet er vigtigere end valget af AI model.

Et stærkt flow skal ende i handling. I vores case om produktimport til WooCommerce håndteres 24 produkter dagligt helt automatisk. Fra rå data til færdige webshop produkter uden manuel kopiering. Det adskiller en reel løsning fra et eksperiment.

Automatisering af overvågning er et andet eksempel. Ved at automatisere konkurrentovervågning for et bureau sparede vi seks timer om ugen. Data bliver ikke bare hentet, men struktureret og gjort klar til brug med det samme. Hele kæden skal holde, ellers ender du med at rette fejl i stedet for at skalere forretningen.

De typiske fejl ligger i data og instrukser

De fleste skuffende resultater skyldes ikke modellen, men måden vi præsenterer opgaven på.

Dårlige kildedokumenter smitter af. Når du fodrer en AI med ustrukturerede noter, gamle PDFer eller tekster uden logisk opbygning, arver den forvirringen. Output bliver en afspejling af input, og hvis input er rodet, skal du regne med at bruge lang tid på redigering bagefter.

Når teksten bliver for lang, kan de vigtige detaljer forsvinde i mængden.

Når du sender for mange sider ind på én gang, kan modellen miste vigtige detaljer midt i teksten. Resultatet bliver overfladisk eller ensidigt. Uklare instrukser gør det ikke bedre. En prompt som “skriv noget om emnet” åbner for alt mellem himmel og jord. Uden en klar tone, et fast format og en tydelig målgruppe må modellen gætte sig frem. Det giver sjældent et svar, du kan bruge direkte.

For mange næsten ens svar gør resultatet ensartet og mindre anvendeligt. Når du sender den samme opgave afsted ti gange med minimale ændringer, får du ofte ti varianter af det samme. Det kan ligne flere valgmuligheder, men indholdet varierer ikke nok til at dække forskellige behov.

Manglende testspørgsmål betyder, at fejl først opdages i produktion. Du sætter en prompt i drift uden først at tjekke, om modellen forstår tabeller, følger formatet eller pludselig opfinder fakta. Så opdager du måske først fejlen, når kunden ser resultatet.

Forklar uden at gøre det for teknisk

Den bedste forklaring af en teknisk løsning fokuserer på udfaldet, ikke på koden bagved.

Det er fristende at beskrive hvert trin i en automatiseringsflow: API kaldene, betingelserne, dataformateringen. Men det, din kollega eller leder egentlig vil vide, er hvad løsningen ændrer i deres hverdag. Når du skal forklare metoder som RAG til ikke tekniske kolleger, så virker tekniske detaljer om vektordatabaser og embeddings modsat hensigten. Sig i stedet, at løsningen henter svar fra jeres egne dokumenter og giver dem direkte til kunden uden manuelt opslag. Så er det lettere at forstå, hvad I får ud af den.

Det samme gælder tal. En teknisk specifikation lyder: systemet behandler leads igennem fire integrerede moduler med NLP berigelse. En forretningsforklaring lyder: vi gik fra manuel research til personlig mail på to minutter per lead. Det er præcis den forskel, der afgør om et projekt bliver godkendt eller bliver liggende.

Begynd med noget, folk kan se.

Når du præsenterer en ny automatiseringsløsning, så vælg ét konkret eksempel. Vis én mail, der blev sendt automatisk. Vis én produkttekst, der blev genereret. Vis, hvordan en webshop nu modtager 24 produkter om dagen helt uden manuel indtastning. Eller hvordan et bureau fredag morgen har en færdig konkurrentanalyse i indbakken, der før tog seks timer om ugen at samle manuelt. Det konkrete eksempel bærer længere end enhver præsentation af integrationsarkitekturen.

En kort forklaring er ofte nok, også når teknikken bag er kompleks.

Ofte stillede spørgsmål

Hvorfor virker min RAG løsning ikke, selvom jeg bruger den nyeste LLM?

Det er sjældent sprogmodellen, der fejler. Problemet ligger ofte i dataforberedelsen, opdelingen af teksten eller søgedelen, som ikke finder den rigtige sammenhæng i jeres dokumenter.

Hvad er de mest almindelige årsager til forkerte svar?

Typiske årsager er mangelfuld datarensning og manglende filtrering af irrelevante dokumenter. Hvis dine prompts ikke beder modellen om kun at bruge de udleverede kilder, kan den begynde at opfinde svar.

Hvordan forbedrer jeg retrieval delen i min pipeline?

Start med at optimere dine embeddings og vælg en model, der passer til dit sprog. Eksperimentér med størrelsen på dine tekststykker og brug metadatafiltre for at mindske støj i søgeresultaterne.

Hvilken rolle spiller chunking for præcisionen?

Chunking afgør, hvor meget kontekst modellen får. For små bidder fjerner sammenhængen, mens for store bidder drukner informationen. En opdeling efter semantiske skift i teksten giver ofte de bedste resultater.

Hvordan ved jeg, om problemet ligger i retrieval eller generering?

Gennemgå de dokumenter, systemet finder frem, før de sendes til modellen. Hvis de relevante kilder mangler, er det retrieval, der fejler. Hvis kilderne er korrekte, men svaret er forkert, ligger fejlen i din prompt eller generering.

Hvordan evaluerer jeg om min løsning fungerer?

Byg et testsæt med kendte spørgsmål og korrekte svar. Mål om systemet finder de rigtige kilder og om det endelige output er faktuelt korrekt. Manuel gennemgang er nødvendig for at identificere præcis, hvor i kæden fejlen opstår.