Den løgnagtige reranker

Kapitel 3 — Den løgnagtige reranker

I den tekniske jargon inden for RAG er der en nøglefigur, der er lidt kedelig og ikke så meget omtalt: rerankeren. Forestil dig virksomhedssøgning som indgangen til en natklub. Vektordatabasen er portieren: den kigger hurtigt på mængden og lukker tredive kandidater ind, der ved første øjekast ligner det, du søger. Rerankeren er den interne vagt: den tager de tredive, kigger på dem grundigt, udvælger fem – dem som LLM'en faktisk vil læse for at konstruere svaret – og sender de andre femogtyve tilbage. Det er en lille, men enorm funktion: hvis den går galt, går det galt for alle. Hvis vagten ikke kan læse ansigter, fyldes lokalet med de forkerte mennesker, og ingen vil nogensinde forstå, hvorfor aftenen gik dårligt.

I 2025 dukkede der flere cloud-tjenester op på markedet, der tilbød rerankere som API'er. Du sender et spørgsmål og en liste over dokumenter, og de returnerer scores. Praktisk, skalerbart, ingen GPU'er at købe, ingen modeller at downloade. En berømt europæisk modeludbyder – uden at nævne navne, men du ved, hvilke navne vi undgår – eksponerede en lovende model fra Qwen-familien med fire milliarder parametre, mærket "Reranker". Prisen var rimelig, latenstiden acceptabel. Alle ville have valgt den på det tidspunkt. Mange valgte den.

Medmindre scorene var forkerte. Ikke "lidt" forkerte, som det kan ske med enhver model: strukturelt forkerte. Dokumenter, der tydeligvis var relevante, fik 0.2, dokumenter, der var ude af emnet, fik 0.8. De første mistanker, som altid i disse tilfælde, var rettet mod de sædvanlige syndere: embedding-modellen, chunking, formuleringen af forespørgslen, forbehandlingen af dokumenterne. Uger med undersøgelser på forkerte spor. Først da man systematisk sammenlignede svarene fra cloud-rerankeren med en lokal referencereranker – samme input, de samme dokumenter, score sat side om side i et Excel-ark – kom den ubehagelige sandhed frem: modellen, der blev eksponeret via API, var defekt. Måske en deploy-fejl, måske en forkert version, der ved en fejl blev uploadet, måske en fejl i serialiseringen af scorene. Udbyderen har aldrig formelt indrømmet det. Problemet forsvandt dog bare en dag, efter en stille opdatering og ingen ændringer i noter.

Pointen med denne historie er ikke "cloud-tjenester tager fejl" — alle tager fejl, selv lokale modeller tager fejl. Pointen er mere subtil: i en seriøs RAG er rerankeren en del, du skal kunne kigge ind i. Hvis det er en betalt sort boks, og hvis dens output er tal, der virker plausible, selv når de er tilfældige — og rerankerens scores ser altid plausible ud, fordi de er tal mellem nul og et med nogle decimaler —, har du ingen måde at forstå, hvad der er galt i dit system. Og da rerankeren er "mod slutningen" af pipelinen, forurener dens fejl enhver evaluering opstrøms: søgningen virker langsom, forespørgslen forkert, embeddings dårlige. I virkeligheden er det dørvagten, der ikke kan læse ansigter, og du sætter spørgsmålstegn ved dørens glas.

Valget imod strømmen for nogle teams i de seneste måneder – i stedet for at gå mere mod cloud, at vende tilbage – har været at bringe rerankeren i hus. En open source-model fra BGE-familien, ikke kæmpestor, kørende på lokal GPU (også på Apple Silicon, med en vis forsigtighed omkring driverne). Mere administrationsarbejde, det er rigtigt. Men muligheden for at lave kontrollerede eksperimenter, at forstå hvornår den tager fejl, at sammenligne versioner, at holde en historik. Og – ikke mindst – ikke at betale en brøkdel af en cent til API'en for hver enkelt brugerforespørgsel. En brøkdel, der ganget med titusindvis af forespørgsler om måneden hurtigt holder op med at være en brøkdel og bliver en post på budgettet.

Når en komponent er så kritisk, at dens fejlfunktion ødelægger enhver evne til at måle resten, er det så ikke effektivt at delegere den til en sort boks. Det er en trosbekendelse. Og trosbekendelser betaler man renter af i produktion.