Sådan bygger du et RAG-system fra bunden — komplet teknisk guide

Hvad RAG faktisk er — og forholdet til fine-tuning

Retrieval-Augmented Generation kombinerer en generativ model med information, der hentes under brug. Systemet finder relevante kilder og giver dem til modellen som kontekst for svaret.

Det gør det muligt at ændre vidensgrundlaget uden nødvendigvis at træne sprogmodellen igen. En ny politik er dog først tilgængelig, når den er godkendt, indlæst og korrekt indekseret. Opdateringer skal derfor være en del af arkitekturen.

Fine-tuning ændrer modellens vægte og kan være relevant for adfærd eller format. RAG og fine-tuning kan kombineres. Vælg ud fra fejltypen: manglende aktuelle oplysninger kræver et andet greb end en klassifikation, som modellen konsekvent misforstår.

Arkitektur — de seks lag

Et dokumentbaseret RAG-system kan beskrives i seks lag. Datakilderne er de godkendte dokumenter, FAQ'er eller registre. Indlæsningen udtrækker indhold, bevarer struktur og knytter version og adgangsoplysninger til materialet.

Et søgeindeks gør indholdet søgbart. Det kan være et vektorindeks, fuldtekstsøgning eller en kombination. Retrieval vælger kandidater til det konkrete spørgsmål, efter at brugerens adgang er afgrænset.

Et valgfrit reranking-lag omrangerer kandidaterne. I et illustrativt forsøg kan man hente 20 uddrag og sende fem videre, men antallet skal testes. Genereringslaget får spørgsmål, udvalgte kilder og instruktioner og skal kunne markere utilstrækkeligt grundlag.

Kontrollér hvert lag selvstændigt. Hvis det rigtige dokument aldrig når frem, er en ændring af sprogmodellens tone ikke en løsning.

Valg af komponenter

Vælg en embedding-model efter test på jeres sprog og dokumenter. Medtag synonymer, forkortelser og koder. En models placering i et generelt benchmark er ikke dokumentation for, at den bedst finder jeres danske instruktioner.

Hvis I allerede drifter PostgreSQL, kan pgvector være en kandidat. Sammenlign med andre løsninger på filtre, backup, opdatering, adgangsisolering og samtidig belastning. Et bestemt antal vektorer er ikke en universel grænse for, hvornår I skal skifte database.

Genereringsmodellen skal testes på korrekt kildebrug og passende afvisning. Rerankeren skal vurderes på, om relevante uddrag faktisk flyttes frem. Mål hele forløbets svartid og pris; der er ingen fast ekstra latenstid, der gælder for alle komponenter.

Chunking — bevar de nødvendige sammenhænge

Opdel efter dokumentets indhold, før I vælger et fast antal tokens. Overskrifter, forbehold og tabelkolonner kan være nødvendige for at forstå en regel. En parser, der mister kolonneoverskrifter, kan gøre ellers præcise tal misvisende.

Overvej overlap, når sammenhæng ellers bliver skåret over. Mere overlap giver dog også flere gentagelser og større indeks. Der findes ingen standardprocent, som sikrer god kvalitet på alle dokumenter.

Lav en konkret prøve: spørg til en undtagelse, der står efter hovedreglen, og undersøg om begge dele kommer med. Sammenlign flere opdelinger på samme testsæt. Rapporter antal korrekte svar og fejltyper fra jeres egne data, frem for at forvente et bestemt procentløft.

Hybrid search og reranking

Semantisk søgning kan finde omskrivninger, mens søgeordssøgning kan være nyttig ved præcise identifikatorer. Hybrid søgning kombinerer signalerne. Det er især værd at afprøve, hvis brugerens formuleringer spænder fra naturlige spørgsmål til produktnumre.

En reranker vurderer de hentede kandidater i forhold til spørgsmålet og ændrer rækkefølgen. Den kan hjælpe, når det rigtige uddrag findes blandt kandidaterne, men ligger for langt nede. Den kan ikke omrangere et dokument, som slet ikke blev hentet.

Sammenlign derfor retrieval alene med retrieval plus reranking. Mål genfinding, kildebelæg, tid og forbrug. Indekser, netværk og modelkald kan alle være flaskehalse; hele forløbet skal måles under realistisk belastning.

Evaluation — mål både søgning og svar

Saml repræsentative spørgsmål med kontrollerede kilder og forventede svar. Antallet skal dække variationen i dokumenterne. Hold testspørgsmål adskilt fra eksempler, som allerede indgår i prompten.

Mål først søgningen: blev det nødvendige belæg hentet, og kom forkerte eller utilgængelige dokumenter med? Mål derefter svaret: følger det kilden, besvarer det spørgsmålet, og er kilden stadig gældende?

En LLM-dommer kan hjælpe med screening, men dens vurdering kan også være forkert. Sammenhold den med faglig gennemgang og kontrollerede eksempler. Registrér både typisk svartid og langsomme tilfælde, eksempelvis p50 og p95.

Gentag relevante tests, når kilder, opdeling, model eller prompt ændres. På den måde bliver forbedringer målbare og fejl lettere at lokalisere.

Almindelige fælder

Manglende kildeversioner gør det svært at se, hvilken politik svaret bygger på. Manglende adgangsfiltre kan give brugeren oplysninger, vedkommende ikke må se. Begge dele bør håndteres før produktion.

Forældede dokumenter skal kunne erstattes eller fjernes i både kildelager og indeks. Ved ændring af embedding-model skal kompatibiliteten vurderes; ofte skal det berørte materiale beregnes på ny og det nye indeks testes før skiftet.

Planlæg også manglende svar og driftsfejl. En tom søgning skal ikke blive til et opdigtet svar. Ved timeout skal systemet forklare begrænsningen og tilbyde en aftalt vej videre. Bevar mulighed for at gå tilbage til en kendt konfiguration, hvis en opdatering forværrer kvaliteten.