RAG i praksis: hvad der skal til, før en intern vidensdatabase virker

RAG — retrieval-augmented generation — er blevet standardsvaret, når en virksomhed vil bruge AI på sin egen viden. Ideen er enkel nok: i stedet for at håbe på at modellen kender jeres processer, finder man de relevante dokumenter frem og giver dem til modellen sammen med spørgsmålet.

Teknisk er det ikke svært længere. En fungerende prototype kan bygges på en dag. Alligevel ender mange af dem med at blive brugt i to uger og derefter aldrig igen. Årsagen er næsten altid den samme, og den har ingenting med sprogmodellen at gøre.

Problemet er indholdet, ikke modellen

En RAG-løsning kan kun svare ud fra det, den kan finde. Peger man den mod et drev med ti års akkumuleret dokumentation, får man svar der afspejler præcis det: tre versioner af samme procesbeskrivelse, hvoraf den nyeste ligger i en mail, og den ældste ligger øverst i søgeresultatet.

Modellen kan ikke se, at et dokument er forældet. Den kan se, at det er relevant. Det er to forskellige ting, og forskellen er hele forklaringen på, hvorfor svaret lyder rigtigt og er forkert.

Derfor starter et RAG-projekt i praksis med en oprydning:

Hvilke kilder er autoritative? Der skal være ét sted hvor sandheden står, og resten skal ude af indekset.
Er dokumenterne daterede og ejede? Et dokument uden ejer bliver aldrig opdateret, og et dokument uden dato kan ikke vægtes.
Findes viden kun i hovedet på folk? Så skal den skrives ned først. RAG kan ikke hente det der aldrig er blevet formuleret.

Det er den kedelige del, og det er den der afgør resultatet. Jeg bruger typisk lige så meget tid på den som på selve implementeringen.

Definér hvad et godt svar er — før I bygger

Det næstoftest oversete skridt er at blive enige om, hvad løsningen skal kunne, i konkrete termer.

Lav en liste med 30-50 rigtige spørgsmål fra jeres eget arbejde. Ikke opfundne demospørgsmål — dem I faktisk har fået fra nye medarbejdere, fra supporten, fra kunder. Skriv det rigtige svar ved siden af, og noter hvor det står.

Den liste er jeres testsæt. Den gør tre ting:

Den viser, om løsningen bliver bedre eller dårligere, når I ændrer noget.
Den afslører hvilke spørgsmål der slet ikke kan besvares, fordi kilden mangler.
Den flytter diskussionen fra fornemmelse til målbarhed.

Uden testsættet bliver evalueringen til, at nogen prøver fem spørgsmål og siger "det virker meget godt". Det holder ikke til den dag, hvor en medarbejder handler på et forkert svar.

Chunking, embeddings og de valg der faktisk betyder noget

Der bruges meget energi på at diskutere embedding-modeller. I praksis er der tre valg, der rykker mere:

Hvordan dokumenterne deles op. At skære teksten i tilfældige blokke på tusind tegn ødelægger sammenhængen. Følg dokumentets egen struktur — afsnit, overskrifter, tabelrækker — og lad blokke overlappe lidt, så en sætning ikke bliver klippet midt over.

Hvad der følger med hver blok som metadata. Kilde, dato, ejer, afdeling og dokumenttype. Uden metadata kan I ikke filtrere, og uden filtrering kan I ikke lave regler som "kun gældende procedurer" eller "kun det denne afdeling må se".

Om der er et ekstra sorteringstrin. At hente tyve kandidater og lade en model rangere dem, før de fem bedste sendes videre, flytter typisk mere på kvaliteten end at skifte embedding-model. Det koster lidt mere pr. forespørgsel og er næsten altid pengene værd.

Kildehenvisninger er ikke pynt

Hvert svar skal vise, hvor det kommer fra — helst med et link direkte til afsnittet.

Det er ikke en detalje i brugerfladen. Det er det, der gør systemet brugbart i en virksomhed, fordi det giver medarbejderen mulighed for at kontrollere svaret på ti sekunder i stedet for at stole blindt på det. Det er også det, der gør fejl synlige: peger halvdelen af svarene på det samme forældede dokument, opdager man det med det samme.

Et system uden kildehenvisninger flytter ansvaret over på den, der spørger. Det er sjældent en god handel.

Adgangsstyring skal med fra start

Hvis vidensdatabasen indeholder andet end offentligt materiale, skal rettighederne følge med ind i indekset — ikke lægges ovenpå bagefter.

Det betyder i praksis, at hver blok bærer sin adgangsgruppe, og at filtreringen sker før søgningen, ikke efter. Bygger man det omvendt, ender man med en løsning, der skal laves om, første gang HR spørger til lønfiler.

Hvad det koster

Grovregning for en typisk intern løsning med nogle tusinde dokumenter:

Bygning: 4-8 uger for oprydning, indeksering, evaluering og en brugbar flade.
Drift: typisk et par tusind kroner om måneden i API-kald og hosting ved almindelig intern brug.
Vedligehold: den reelle omkostning. Nogen skal holde kilderne opdaterede. Er der ikke en ejer, forfalder løsningen stille og roligt i løbet af et år.

Den sidste post er den, der oftest mangler i en business case, og den der afgør, om løsningen stadig bliver brugt om atten måneder.

Når RAG ikke er svaret

Der er tre situationer hvor jeg fraråder det:

Materialet er lille og stabilt. Er der tale om tredive sider, der sjældent ændrer sig, er en god søgefunktion eller en velskrevet intern side både billigere og mere pålidelig.
Spørgsmålene kræver beregning, ikke opslag. "Hvad er dækningsbidraget på kunde X i år?" er et databasespørgsmål. Det skal ikke besvares af en model, der læser dokumenter.
Ingen ejer kilderne. Uden en ansvarlig for indholdet bygger man en løsning, der bliver forældet, mens den stadig ser rigtig ud. Det er værre end ingen løsning.

I de tilfælde er det bedre at sige det højt end at bygge noget, der ser imponerende ud i en demo og skuffer i drift.