I måler en AI-søgning i egne dokumenter med en liste af spørgsmål, hvor I på forhånd kender det rigtige svar og det dokument, svaret står i. Ved at måle fundet og svaret hver for sig kan I se, om fejlene kommer fra søgningen eller fra modellen, og dermed hvad der skal skiftes.
Søgning i egne dokumenter kaldes ofte RAG, en forkortelse for retrieval-augmented generation. Metoden blev beskrevet i en forskningsartikel fra 2020 som modeller, der kombinerer den viden, der ligger i modellen, med et eksternt indeks, der søges i, før svaret dannes. I praksis betyder det, at systemet først finder de dokumenter eller tekststykker, der passer til spørgsmålet, og derefter lader sprogmodellen skrive et svar ud fra dem.
To led, to slags fejl
Når et svar er forkert, kan det skyldes to ting.
Fejl i fundet. Søgningen fandt ikke det dokument, hvor svaret står, eller den fandt et forkert. Modellen har så intet rigtigt at svare ud fra. Fejlen ligger i indekset, i opdelingen af dokumenterne eller i indlejringsmodellen, som omsætter tekst til de talrækker, der søges i.
Fejl i svaret. Søgningen fandt det rigtige, men modellen gengav det forkert, tilføjede noget, der ikke står i kilden, eller udelod det vigtige. Fejlen ligger i sprogmodellen eller i instruktionen.
Skelnen betyder noget for valget. Er det fundet, der fejler, hjælper det ikke at skifte til en dyrere sprogmodel. Er det svaret, hjælper det ikke at bygge indekset om.
To mål, I kan bruge som begreber
Værktøjer til evaluering af RAG har gjort de to fejl målbare. Vi bruger begreberne her uden at anbefale et værktøj.
Genfinding. Hvor stor en del af de dokumenter, der burde være fundet, blev faktisk fundet? Kender I det rigtige dokument for hvert spørgsmål, kan I tælle det selv.
Troskab mod kilden. I hvor høj grad holder svaret sig til det, der står i de fundne tekster? Et svar, der lyder rigtigt, men som påstår noget, kilden ikke siger, er utro mod kilden.
En sikkerhedsorganisation for AI-applikationer, OWASP, nævner også tre led til vurdering af sådanne systemer: om den fundne tekst er relevant, om svaret er forankret i den, og om svaret er relevant for spørgsmålet.
Sådan bygger I prøven
Metoden er sitets egen og kræver ingen programmering.
- Vælg dokumenterne, der skal kunne søges i, fx håndbøger, procedurer, kontrakter eller tidligere svar til kunder.
- Skriv tyve til fyrre spørgsmål, som en medarbejder faktisk kunne stille. Lad fagfolk skrive dem, så sproget ligner virkeligheden.
- Notér for hvert spørgsmål det rigtige svar og det dokument eller afsnit, det står i.
- Tag svære spørgsmål med: spørgsmål, hvor svaret står to steder, hvor dokumenterne modsiger hinanden, og hvor svaret slet ikke står nogen steder. Det sidste viser, om systemet siger, at det ikke ved det.
- Kør spørgsmålene og gem både de fundne dokumenter og svaret.
- Bedøm hvert spørgsmål to gange: blev det rigtige dokument fundet, og er svaret tro mod det fundne og korrekt.
Hvem der vurderer
Genfinding kan en IT-ansvarlig tælle, når facit er skrevet. Troskab og korrekthed kræver en fagperson, der kender dokumenterne. Den samme fagperson bør ikke både skrive spørgsmålene og bedømme svarene, hvis det kan undgås, fordi den, der kender facit udenad, let overser en halv fejl.
Hvad tallene fortæller jer
- Lav genfinding, høj troskab. Søgningen er problemet. Prøv en anden opdeling af dokumenterne, en anden model til indlejringer, eller ryd op i dokumenterne. Et skift af model til indlejringer kan kræve, at alle dokumenter indlejres igen, og det binder på sin egen måde, som beskrevet i indlejringer binder.
- Høj genfinding, lav troskab. Sprogmodellen eller instruktionen er problemet. Prøv en anden instruktion eller en anden model.
- Begge lave. Start med søgningen. Et svar kan ikke blive bedre end det, der er fundet.
Hvor indekset ligger, og hvem der har adgang til det, står i søgning i egne dokumenter.
Når søgningen viser for meget
Prøven kan også afsløre, at søgningen finder dokumenter, som spørgeren ikke burde se. Det hører under rettighederne i dokumenterne, som er emnet i rettigheder i dokumenterne, og det skal håndteres, før systemet tages i brug bredt.
Hvad det kræver, og hvad det koster at lade være
At skrive tyve til fyrre spørgsmål med facit tager fagfolk to til fire dage. Hver kørsel og bedømmelse tager en til to dage. Prøven bruges igen ved hvert skift af model, indeks eller dokumentsamling. Sæt jeres egen timepris på.
Lader I være, ved I ikke, hvor fejlene kommer fra. Det koster tid og penge at skifte den forkerte del: en dyrere sprogmodel, der ikke hjælper, eller et nyt indeks, der ikke var problemet. Og brugere, der får forkerte svar fra egne dokumenter, holder op med at bruge dem.
Det skal I lade være med
- At måle kun det endelige svar · så kan I ikke se, om søgningen eller modellen fejler.
- At skrive spørgsmålene ud fra dokumenternes ordlyd · brugerne spørger med deres egne ord.
- At udelade spørgsmål uden svar · de viser, om systemet opfinder noget.
Det skal valget kunne vise
- ☐ Spørgsmål med facit og kildedokument.
- ☐ Genfinding og troskab mod kilden målt hver for sig.
- ☐ Hvem der bedømte, og hvordan.
- ☐ Hvilken del der blev ændret efter prøven, og resultatet af næste kørsel.
Kilder
- Lewis m.fl., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, arXiv:2005.11401, læst 8. november 2026.
- Ragas, dokumentation om Faithfulness og Context Recall, læst 8. november 2026.
- OWASP Gen AI Security Project, LLM01:2025 Prompt Injection, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Lad to fagfolk skrive ti spørgsmål hver om de dokumenter, søgningen skal dække, med svar og kilde.
Læs også: Hvor godt kan modellen dansk? · Fejl i svarene
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
