RAG: find årsagen til forkerte eller manglende kilder

Begynd med ét forkert svar og følg grundlaget

Vælg en konkret samtale, hvor en fagperson kan forklare, hvad svaret burde have været. Find det originale dokument og det afsnit, der støtter svaret. Undersøg derefter, om afsnittet findes i indekset, om søgningen fandt det, og om det kom med i modelinputtet.

Hvis kilden aldrig blev indlæst, er problemet ikke en svag svarmodel. Hvis den blev fundet på en lav placering og skåret fra, handler det måske om kandidatvalg eller rangering. Hvis den kom korrekt med, men blev misfortolket, er prompt, kildekonflikter eller svarverifikation mere relevante spor.

Gem et kort fejlkort med spørgsmålet, forventet kilde-ID, faktisk kilde-ID og den afgørende forskel. Undlad at ændre flere komponenter samtidig. En ny embeddingmodel, en større kandidatliste og en ny prompt kan tilsammen give et andet svar, men I ved ikke, hvilken ændring der hjalp eller skabte en ny fejl.

Kontrollér tekst og dokumentgrænser før rangeringen

Se på den tekst, søgesystemet faktisk har modtaget. PDF-udtræk kan blande kolonner, fjerne tabeloverskrifter eller splitte en betingelse fra dens undtagelse. En høj relevansscore hjælper ikke, hvis uddraget har mistet den betydning, originalen havde.

Hvert søgbart afsnit bør kunne forbindes med stabilt dokument-ID, version og en forståelig placering i kilden. Bevar de overskrifter og produktbetegnelser, der er nødvendige for at forstå et fund. Kontrollér samtidig, om dubletter eller gamle kopier fylder blandt resultaterne.

Lav et lille kendt dokumentudsnit til afprøvningen. Det skal indeholde både den korrekte kilde og overbevisende alternativer: samme emne for en anden produktgeneration, en tidligere version eller en generel vejledning uden den konkrete undtagelse. Så tester I, om søgningen kan skelne mellem relevante forskelle, ikke blot om den kan finde noget om emnet.

Definér relevante kilder og mål dækningen

Skriv testspørgsmål i de formuleringer, brugerne forventes at anvende. Til hvert spørgsmål angives de afsnit, der er nødvendige eller acceptable som grundlag. Nogle spørgsmål kræver ét afsnit; andre kræver flere dokumenter. Markér denne forskel, så ét delvist match ikke tæller som fuld dækning.

En enkel startmåling er, hvor mange spørgsmål der har mindst én relevant kilde blandt de første k resultater. Det er et hitmål. Recall@k undersøger i stedet, hvor stor en andel af de kendte relevante dokumenter der findes i top k. De mål besvarer forskellige spørgsmål og skal navngives korrekt.

Sentence Transformers dokumenterer flere retrieval-mål, herunder recall og rangbaserede mål. Vælg få mål, som jeres team kan forklare. Medtag også spørgsmål uden et dækkende svar og vurder dem særskilt. En søgemotor kan altid returnere nærmeste match, selv når materialet ikke besvarer behovet.

Afprøv ordsøgning som et tydeligt udgangspunkt

BM25 er en nyttig baseline, når materialet indeholder præcise termer, navne og produktkoder. Kontrollér søgesystemets tekstanalyse: hvordan behandles bindestreger, store bogstaver, danske bøjninger og sammensatte ord? Et varenummer skal ikke miste sin identitet, fordi en generel sprogregel deler det uhensigtsmæssigt.

Gem resultaterne for de samme testspørgsmål, som senere bruges til vektorer og hybrid search. Se efter konkrete mønstre. Finder ordsøgningen præcise fejlkoder, men overser spørgsmål i dagligsprog? Er et vigtigt afsnit svagt placeret, fordi dokumentgrænserne giver for lidt eller for meget tekst?

Ret åbenlyse problemer i grundlaget først. En kontrolleret synonymordliste kan løse kendte forskelle i sprog uden et ekstra modelkald. Den skal dog afprøves mod nærliggende forkerte betydninger. Brug ikke en ny generativ komponent til at skjule en uklar navngivning, som en fagperson kan afklare direkte.

Undersøg hvad vektorsøgningen tilføjer

Vektorsøgning sammenligner repræsentationer af spørgsmål og dokumenter. Den kan finde beslægtet betydning, når ordvalget er forskelligt. Men semantisk nærhed kan også pege på en forkert produktvariant eller en generel tekst, som ikke svarer på den konkrete afgrænsning.

Kontrollér, at spørgsmål og dokumenter bruger en kompatibel embeddingopsætning og det forventede lighedsmål. Gem model og indeksversion. Ved et modelskift kan dokumentvektorer skulle gendannes; samme antal dimensioner beviser ikke, at gamle og nye repræsentationer passer sammen.

Hvis et ANN-indeks bruges, kan et mindre udsnit sammenlignes med eksakt vektorsøgning. Det hjælper med at skelne mellem indeksets tilnærmelse og embeddingmodellens vurdering. Faiss dokumenterer både eksakte og tilnærmede indeksmetoder. En god teknisk nabogenfinding er dog stadig noget andet end at finde det fagligt nødvendige kildeafsnit.

Saml søgespor uden at blande scorebetydninger

Hybrid search kan kombinere ordmatch med vektorsøgning i en fælles liste. Gem stadig de oprindelige spor under afprøvningen, så I kan se, hvilket bidrag de hver især giver. Hvis begge finder samme irrelevante afsnit, løser sammenlægningen ikke problemet alene.

Rå BM25- og vektorscorer har ikke nødvendigvis sammenlignelige skalaer. Reciprocal rank fusion er en metode, der kombinerer resultater ud fra deres placeringer i listerne. Andre løsninger kan bruge en begrundet normalisering eller vægtning. Den valgte metode og dens parametre skal være en del af testkonfigurationen.

Undersøg dubletter og kandidatbredde efter fusion. Et dokument, der forekommer i mange kopier, må ikke fylde det meste af det begrænsede svargrundlag. Bevar nødvendige kilde-ID’er og versioner ved sammenlægningen. Elastic beskriver hybrid search og RRF som separate dele, hvilket gør det nyttigt at afprøve både søgespor og fusion hver for sig.

Tilføj reranking, når kandidaterne er gode nok

En reranker undersøger det allerede fundne kandidatfelt igen. En cross-encoder kan eksempelvis vurdere spørgsmål og uddrag samlet. Det kan være relevant, når den første søgning finder den rigtige kilde, men ikke placerer den højt nok. Den kan ikke redde en kilde, som slet ikke findes blandt kandidaterne.

Afprøv flere begrundede kandidatstørrelser på samme testsæt. For få kan udelukke vigtigt materiale; for mange kan koste tid og kapacitet. Dokumentér også eventuel afkortning af tekstpar. En vigtig undtagelse uden for modellens input kan ikke påvirke vurderingen.

Se derefter på det endelige udvalg. Kommer de nødvendige forskellige afsnit med, eller får næsten ens formuleringer alle pladserne? Sentence Transformers beskriver netop et forløb med hurtig kandidatfinding efterfulgt af mere detaljeret rangering. Behandl det som en arkitekturmulighed, der skal måles på jeres data, og ikke som en automatisk forbedring af enhver vidensbase.

Sammenlign metoder på et lille kontrolleret problem

Forestil jer tre manualer: en aktuel model A, en tidligere model A og model B. Alle beskriver rengøring, men kun den aktuelle A-manual forklarer en bestemt låsemekanisme. Testspørgsmålet nævner model A og symptomet, men bruger et hverdagsord for mekanismen.

Fagpersonen markerer det nødvendige afsnit i den aktuelle manual. De tre søgeopsætninger køres med samme dokumenter, spørgsmål og adgangsfiltre. Først registreres, om afsnittet findes blandt kandidaterne. Derefter vurderes placering og det grundlag, som sendes til svarmodellen.

Tabellen viser, hvad forsøget skal undersøge, ikke målte resultater eller en påstået vinder. Hvis en metode ser bedre ud, gentages sammenligningen på andre spørgsmål og et separat kontrolsæt. Ét heldigt fund er et spor til videre undersøgelse, ikke et benchmark, som kan generaliseres til hele løsningen.

Kontrollér filtre og omskrivning som selvstændige trin

Sammenlign brugerens oprindelige spørgsmål med den forespørgsel, søgemotoren modtager. En omskrivning kan hjælpe med en opfølgning, men også miste en negation, periode eller identifikator. Bevar begge formuleringer under testen og markér ændret hensigt som en fejl.

Adgangs- og versionsfiltre skal gælde i alle spor. Filtreringens placering i forhold til vektorsøgningen kan påvirke, hvilke kandidater der overhovedet bliver fundet. Microsoft beskriver, hvordan nogle efterfiltreringsformer kan miste relevante matches ved snævre filtre. Undersøg den konkrete implementering frem for at overføre en generel antagelse.

Test med de filtre, der bruges i drift. En flot måling på hele samlingen fortæller ikke nok om en kunde med få tilladte dokumenter. Fjern aldrig et nødvendigt adgangsfilter for at forbedre en relevansscore. Et utilstrækkeligt resultat skal løses inden for den rigtige datagrænse.

Kontrollér hvad svarmodellen faktisk får

Efter søgning og rangering kan materialet blive trimmet, sammenfattet eller pakket i en prompt. Det er endnu et sted, hvor en nødvendig undtagelse eller kildehenvisning kan gå tabt. Inspicér derfor det faktiske modelinput på de kendte fejlsager.

Sørg for, at dokument-ID, version og den relevante tekst følges ad. Et korrekt svar med en forkert kildehenvisning er ikke en fuld succes. Ved modstridende kilder skal løsningen kende en dokumenteret prioritering eller vise konflikten frem for at kombinere oplysningerne til en ny, udokumenteret regel.

Afprøv også et spørgsmål, som intet tilladt dokument kan besvare. Systemet skal kunne markere manglende grundlag, selv når søgemotoren returnerer nogle kandidater. En højeste placering betyder blot, at dokumentet vandt den konkrete rangering. Den betyder ikke, at der findes et dækkende svar i materialet.

Test spørgsmål, som kræver mere end ét fund

Et enkelt relevant dokument er ikke altid et tilstrækkeligt svargrundlag. Forestil jer et spørgsmål om, hvorvidt en reservedel kan bestilles til en bestemt maskine. Produktmanualen forklarer kompatibiliteten, mens en separat servicevejledning beskriver bestillingsbetingelserne. Begge er nødvendige, hvis svaret skal dække hele spørgsmålet.

Markér i testsættet, hvilke dele af spørgsmålet hver kilde besvarer. Kontrollér først, om begge findes blandt kandidaterne, og derefter, om de begge overlever rangering og afkortning. Hvis de sidste pladser optages af næsten identiske manualuddrag, kan løsningen miste betingelserne, selv om dens topresultat er korrekt.

Lav også en variant, hvor den ene nødvendige kilde mangler. Et acceptabelt svar kan forklare den dokumenterede kompatibilitet og markere, at bestillingsbetingelserne ikke er afklaret. Det må ikke låne en betingelse fra et lignende produkt for at afslutte svaret.

Denne test adskiller delvis genfinding fra fuld dækning og viser, hvor fejlen opstår. Brug den, når brugernes spørgsmål ofte kombinerer produkt, aftale, periode eller proces. Bevar den oprindelige formulering under forsøget, så en automatisk opdeling ikke får lov at ændre det behov, systemet skal besvare.

Vurder gevinsten sammen med svartid og vedligeholdelse

Mål tiden for forespørgselsbehandling, søgning, reranking og generering hver for sig. Se også på den samlede tid fra brugerens spørgsmål til et færdigt svar. En hurtig første tekstlinje kan skjule, at resten af forløbet er langsomt eller kræver flere forsøg.

Brug repræsentative inputlængder og samtidighed. Gentagne testspørgsmål med varm cache kan give et andet billede end nye spørgsmål under almindelig belastning. Registrér de forhold, som påvirker sammenligningen, og hold dem så ens som muligt mellem varianterne.

Vælg derefter den enkleste opsætning, som opfylder de aftalte krav. Et ekstra søgespor eller en reranker skal have et konkret bidrag, som står mål med drift og fejlsøgning. Gem konfiguration og tests, så teamet kan undersøge senere ændringer. En lokal forbedring er først relevant, når den kan fastholdes på det materiale og den belastning, løsningen skal håndtere.

Forbered et kildeproblem, der kan undersøges

Et godt diagnosebrief indeholder et anonymiseret spørgsmål, det forventede kildeafsnit og de resultater, løsningen faktisk fandt. Tilføj dokumentversion, eventuelle filtre og en oversigt over søgemetoden. Del gerne et konkret misvisende svar, men fjern adgangsnøgler og unødvendige kundedata.

Med det grundlag kan Moselstudio hjælpe med at lokalisere problemet i dokumentbehandling, forespørgsel, retrieval, rangering eller generering. En indledende vurdering bør ende i en begrundet næste undersøgelse, ikke automatisk i et forslag om at udskifte hele platformen.

Aftal også, hvordan en mulig rettelse skal dokumenteres. Det kan være et fast testsæt, en sammenligning med den eksisterende løsning og en kontrol af adgang og svartid. Når ændring og acceptkriterium hænger sammen, bliver det lettere at afgrænse opgaven og vurdere, om den er løst.