Hybrid Search og reranking for AI-chatbots: bedre RAG-resultater

Website-chatbots fejler sjældent, fordi en videnbase slet ikke indeholder informationer. Oftest finder retrieval-trinnet blot ikke det afsnit, der passer til spørgsmålet og den konkrete kontekst. Besøgende bruger produktnavne, fejlmeddelelser og artikelnumre, men formulerer sig i lige så høj grad frit: „Hvorfor viser chatbotten den forkerte abonnementstype?“ eller „Kan jeg stadig ændre en ordre, der allerede er afsendt?“ Til denne blanding er hverken ren søgeordssøgning eller ren vektorsøgning nok som et generelt svar. Hybrid Search forbinder begge signaler, så en RAG-chatbot får mere solide kilder ind i sin svarkontekst.

Søgeords- og vektorsøgning løser forskellige opgaver

Søgeordssøgning er stærk, når ord skal forekomme præcist. Det gælder for ordrenumre, produktbetegnelser, konkrete fejlmeddelelser, aftalenavne eller en version som „2.4“. Den kan gennemskueligt vise, hvorfor et dokument passer: Det søgte ord står i titlen, i en overskrift eller i afsnittet. Dens svaghed viser sig ved hverdagssprog, synonymer og ufuldstændige formuleringer. Et spørgsmål fra en besøgende om en „fakturakopi“ finder så ikke nødvendigvis en side, der kun taler om at „downloade kvittering“.

Vektorsøgning udfylder dette hul. Den repræsenterer spørgsmål og indhold som semantisk nærhed og kan derfor finde lignende henvendelser, selvom de samme begreber mangler. Det hjælper ved naturligt formulerede supportspørgsmål, flersprogede varianter og forskellige betegnelser for den samme proces. Semantisk nærhed alene er dog intet frikort: Et afsnit kan ligne emnet, men vedrøre en anden produktversion, et andet marked eller en udløbet regel. Netop derfor hører kontekstkontrol til i retrieval-pipelinen og ikke først hos sprogmodellen.

Hvorfor Hybrid Search er et fornuftigt udgangspunkt

Microsoft beskriver Hybrid Search som en fælles forespørgsel med både en fritekst- og en vektordel. Begge forespørgsler kører parallelt, og deres resultatlister flettes efterfølgende sammen. Det er attraktivt for virksomheders hjemmesider, fordi præcise begreber bevares, samtidig med at beslægtet, godt formuleret indhold bliver tilgængeligt. En chatbot behøver ikke lade de besøgende vælge mellem en „teknisk“ og en „semantisk“ søgning. Udvælgelsen sker i baggrunden og kan testes med den samme kvalitetsproces for alle spørgsmål.

Hybrid Search forbedrer feltet af kandidater; den skaber ingen sandhed. Chatbotten må kun bruge indhold, der er godkendt til den konkrete situation. Offentlige websider, interne udkast og beskyttede kundedata hører ikke hjemme i en fælles, ukontrolleret kontekst. Lige så vigtig er en klar adfærd, når ingen passende kilde er tilgængelig: Et opklarende spørgsmål, et link til kontaktsiden eller Human Handoff er sikrere end et flydende formuleret gæt.

Forstå RRF: fletning af ranglister

Scores fra friteks- og vektorsøgning har forskellige betydninger og skalaer. At lægge dem direkte sammen eller opfinde en fast grænseværdi for dem fører ofte til ustabile resultater. Reciprocal Rank Fusion, forkortet RRF, arbejder derfor med et dokuments placering i hver rangliste. Et dokument, der ligger højt oppe på begge lister, får et stærkt kombineret signal. Et dokument, der kun ses på én liste, kan også tages i betragtning, men udskyder ikke automatisk alt andet.

RRF er hverken en magisk standardværdi eller en erstatningsformel for faglige tests. Hvor mange kandidater fra hver søgning der kommer med i fusionen, hvilke filtre der gælder forinden, og hvornår et resultat overhovedet anses for brugbart, afhænger af indhold og risiko. Ved hyppige produktspørgsmål kan et lille, fokuseret vindue give mening. Ved komplekse vejledninger eller fejlfinding er der muligvis brug for flere kandidater. Det afgørende er at sammenligne ændringen mod et testsæt med reelle spørgsmål i stedet for at overtages en universel parameter fra et eksempel.

Semantisk reranking som et andet, afgrænset trin

Efter en god forudvælgelse kan en reranker vurdere det snævrere kandidatfelt endnu en gang i forhold til hele spørgsmålet. Microsoft placerer semantisk ranking som en sekundær ranking oven på en allerede forud-rangordnet resultatliste. Amazon Bedrock beskriver tilsvarende reranking som en vurdering af tekstdokumenters relevans i forhold til forespørgslen. Dette andet trin egner sig til spørgsmål med flere betingelser: for eksempel om et skift af abonnement er muligt, efter at en ordre allerede er afsendt, og der foreligger en bestemt aftaletype.

Reranking bør afgrænses bevidst. Det koster ekstra latenstid og kan, afhængigt af tjenesten, være belagt med omkostninger. Send derfor ikke hele videnbasen til en reranker, men kun den allerede filtrerede og flettede topmængde. Definer et tidsbudget og en fallback. Overskrides budgettet, kan chatbotten for eksempel vise den mest pålidelige kildeliste, bede om en præcisering eller overdrage samtalen til et supportteam. En reranker reparerer ikke forældet, manglende eller ugodkendt indhold.

Metadatafiltre beskytter konteksten

Metadata afgør ofte svarkvaliteten i højere grad endnu en modelmulighed. Vedligehold for hver kilde mindst sprog, produkt eller tjeneste, versionsstand, marked, målgruppe og gyldighed, i det omfang disse oplysninger er relevante for brugen. Et filter på den rigtige tenant eller det rigtige rettighedsområde skal gælde før output. På et offentligt website kan en chatbot kun hente offentligt indhold; for et logget ind-område gælder derudover verificerbare rettigheder.

Tid er også et spørgsmål om metadata. Prislister, leveringsbetingelser og vejledninger bør have en klar opdateringsdato eller en kontrolleret gyldighedsstatus. Er kilden ikke længere tillidsvækkende, hører den hjemme ude af indeks eller i en separat kontrolsti. Filtre skal afspejle krav, der er gennemskuelige for besøgende, og ikke hemmeligt manipulere rækkefølgen. Dokumenter derfor, hvilke filtre der gælder for hvilke typer spørgsmål, og hvordan et team verificerer ændringer.

En konkret pipeline fra query til kontekst

1. Normaliser spørgsmålet: Genkend sprog og åbenlys kontekst uden at gemme eller ændre personlige data unødigt.
2. Kontroller adgang og metadata: Fastslå før retrieval, hvilke kilder der er tilladt for produkt, marked, rolle og gyldighedsperiode.
3. Hent parallelt: Udfør fritekst- og vektorsøgning mod den samme tilladte kildemængde.
4. Flet ranglister: Kombiner listerne med RRF, og gem oprindelsessignalerne for hver kandidat til debugging.
5. Rerank i begrænset omfang: Udfør kun relevansvurderingen på den lille topmængde, og mål latenstiden.
6. Sikr konteksten: Kontroller dubletter, kildestatus og en passende længde, før afsnit sendes til svarmodellen.
7. Svar med afgrænsning: Dokumenter kilder, marker usikkerhed, og brug om nødvendigt en sikker overdragelse.

Praktisk eksempel: forsendelsesstatus og ændring af abonnement

Antag, at en besøgende spørger: „Kan jeg stadig ændre mit abonnement, selvom pakken allerede er på vej?“ Søgeordssøgningen finder muligvis en side om „ændring af abonnement“ og en supportartikel med „pakke på vej“. Vektorsøgningen finder en vejledning, der beskriver processen som en ændring efter afsendelse. RRF bringer dokumenter op, der kombinerer begge aspekter. En reranker kan derefter kontrollere, om det relevante afsnit virkelig indeholder kombinationen af abonnement og forsendelse.

Før et svar filtrerer du i forhold til det berørte marked, produktlinjen og den aktuelle gyldighedsstatus. Er kilderne modstridende, eller mangler der nødvendige detaljer, bør chatbotten ikke drage konklusioner ud fra lignende tilfælde. Den kan gennemskueligt oplyse, hvilken betingelse der stadig er åben, og henvise den besøgende til en passende, verificeret kontaktmulighed. På den måde forbliver samtalen hjælpsom uden at opfinde et tilsagn, der ikke er dækning for.

No-result-tilfælde og score-debugging

Et no-result er ofte et tegn på et hul i videnbasen, ikke på en ødelagt søgning. Skeln derfor mellem mindst fire tilfælde: Der er ingen tilladt kilde, der er kilder, men intet tilstrækkeligt passende resultat, spørgsmålet er flertydigt, eller en teknisk fejl forhindrer retrieval. Hvert tilfælde kræver sin egen, forståelige reaktion. „Det finder jeg ingen pålidelige oplysninger om i det godkendte materiale“ er mere ærligt end en generisk sætning uden et næste skridt.

Til debugging er slutscores alene ikke nok. For hvert testspørgsmål bør teams kunne se, hvilke filtre der trådte i kraft, hvilke dokumenter der kom fra søgeords- og vektorsøgningen, hvordan de blev flettet, og om reranking ændrede rækkefølgen. Gem i den forbindelse kun de data, der er nødvendige for kvaliteten, og behandl dem dataminimeret. Søg efter mønstre: Mangler der bestemte synonymer? Overskygger en gammel kilde nyt indhold? Afviger en locale fra metadatalogikken? Først den konkrete årsag afgør, om chunking, metadata, kildevedligeholdelse eller ranking skal ændres.

Testsæt, målepunkter og omkostningsbudget

Et lille Golden Set med 30 til 50 realistiske spørgsmål er en god start. Definer for hvert spørgsmål forventede kilder, ulovlige kilder og den ønskede reaktion ved manglende viden. Mål separat, om en korrekt kilde findes blandt kandidaterne, om den rangerer højt nok, og om det endelige svar kun bruger dokumenterede informationer. Suppler bevidst med stavefejl, præcise begreber, naturlige formuleringer, flersprogethed og kritiske negative tilfælde.

Ændr kun én variabel pr. testkørsel: et filter, antallet af kandidater, reranking-dybden eller chunk-strukturen. Noter desuden svartiden og antallet af eksterne modelkald. En højere relevansværdi kan være ubrugelig, hvis svaret kommer for sent, eller omkostningerne for hyppige standardspørgsmål stiger. Definer derfor et latens- og omkostningsbudget pr. spørgsmålskategori. Hurtige, veldokumenterede standardsvar og konservative overdragelser er mere værdifulde for mange websites end en maksimalt komplex ranking.

Typiske fejl ved introduktionen

• At sammenligne rå søgeords- og vektorscores direkte, selvom deres skalaer ikke er ens.
• At indeksere udkast, gamle prislister eller beskyttet indhold uden status- og rettighedsfilter.
• At anvende reranking på for mange kandidater og derved miste kontrollen over latenstid og omkostninger.
• At behandle en demo med få gode spørgsmål som tilstrækkeligt kvalitetsbevis.
• At generere et plausibelt svar ved manglende kilde i stedet for at indtænke usikkerhed, opklarende spørgsmål eller handoff.
• Ikke at versionere ændringer i kilder, chunking og ranking og senere ikke kunne forklare dem.

Tjekliste til introduktion

• Fastlæg tilladte kilder og rettighedsgrænser før indeksering.
• Vedligehold metadata for sprog, produkt, version, marked og gyldighed.
• Hent fritekst og vektorsøgning parallelt, og flet dem derefter via RRF.
• Anvend kun reranking på en lille, tilladt kandidatmængde.
• Evaluer kildelinks, no-result-svar og Human Handoff i testsættet.
• Mål latenstid, omkostninger og kritiske fejlsvar for hver ændring.

Konklusion

Hybrid Search er et robust udgangspunkt for website-chatbots med forskellige spørgeformer. Søgeordssøgning bevarer præcise signaler, vektorsøgning åbner op for lignende henvendelser, RRF fletter deres ranglister, og en afgrænset reranker kan forbedre det snævre udvalg. Den bæredygtige kvalitetsgevinst opstår dog gennem velholdte kilder, passende metadata, gennemskuelige tests og en svarlogik, der åbent viser sine begrænsninger. På den måde bliver retrieval verificerbar i stedet for blot teknisk imponerende.

Kilder og viderelæsning

• Microsoft Learn: Hybrid Search
• Microsoft Learn: Relevans og RRF ved Hybrid Search
• Microsoft Learn: Semantic Ranking
• Amazon Bedrock: Reranking
• ChatReact: RAG-Chunking für KI-Chatbots
• ChatReact: Antwortqualität mit Golden Set testen
• ChatReact: Wissensbasis aktuell halten