Den ljugande omrankaren

Kapitel 3 — Den ljugande omrankaren

Inom den tekniska jargongen för RAG finns en nyckelperson, lite okänd och sällan omtalad: omrankaren. Föreställ dig företagssökningen som en entré till en nattklubb. Vektordatabasen är vakten: den tittar snabbt på folkmassan och släpper in trettio kandidater som, vid en snabb blick, liknar det du söker. Omrankaren är den inre dörrvakten: den tar dessa trettio, tittar noggrant på dem, väljer ut fem — de som LLM faktiskt kommer att läsa för att bygga svaret — och skickar tillbaka de andra tjugofem. Det är en liten men enorm funktion: om han gör fel, gör alla fel. Om dörrvakten inte kan läsa ansikten kommer lokalen att fyllas med fel personer och ingen kommer någonsin att förstå varför kvällen gick dåligt.

Under 2025 dök det upp flera molntjänster på marknaden som erbjöd omrankare som API:er. Du skickar en fråga och en lista med dokument, och de returnerar poäng. Bekvämt, skalbart, inga GPU:er att köpa, inga modeller att ladda ner. En välkänd europeisk leverantör av modeller — utan att nämna namn, men du vet vilka namn vi undviker — exponerade en lovande modell från Qwen-familjen, med fyra miljarder parametrar, märkt "Omrankare". Priset var rimligt, latensen acceptabel. Alla skulle ha valt den vid den tidpunkten. Många valde den.

Om inte annat, så var poängen felaktiga. Inte "lite" felaktiga, som kan hända vilket modell som helst: felaktiga strukturellt. Dokument som uppenbart var relevanta fick 0.2, dokument som inte hörde hemma fick 0.8. De första misstankarna, som alltid i dessa fall, riktades mot de vanliga syndarna: embedding-modellen, chunking, formuleringen av frågan, förbehandlingen av dokumenten. Veckor av utredningar på felaktiga spår. Det var först genom att systematiskt jämföra svaren från den molnbaserade rerankern med en lokal referens-reranker – samma input, samma dokument, poäng sida vid sida i ett Excel-ark – som den obekväma sanningen framkom: modellen som exponerades via API var trasig. Kanske ett distributionsfel, kanske en felaktig version som laddades upp av misstag, kanske ett fel i serialiseringen av poängen. Leverantören har aldrig erkänt det formellt. Problemet försvann dock bara en dag, efter en tyst uppdatering och inga ändrade release notes.

Poängen med den här historien är inte "molntjänster gör fel" — alla gör fel, även lokala modeller gör fel. Poängen är mer subtil: i en seriös RAG-lösning är omrankeraren en del som du måste kunna titta in i. Om det är en betald svart låda, och om dess utdata är siffror som verkar plausibla även när de är slumpmässiga — och omrankerarens poäng ser alltid plausibla ut, eftersom de är siffror mellan noll och ett med några decimaler — har du inget sätt att förstå vad som är fel i ditt system. Och eftersom omrankeraren är "mot slutet" av pipelinen, förorenar dess fel varje utvärdering uppströms: sökningen verkar långsam, frågan felaktig, inbäddningarna dåliga. I själva verket är det dörrvakten som inte kan läsa ansikten, och du ifrågasätter dörrens glas.

Vissa team har under de senaste månaderna gjort ett oväntat val – istället för att gå mot mer molntjänster, har de valt att återföra reranker hem. En öppen källkodsmodell från BGE-familjen, inte jättestor, körd på lokal GPU (även på Apple Silicon, med viss försiktighet kring drivrutinerna). Mer hanteringsarbete, visst. Men möjligheten att göra kontrollerade experiment, förstå när den gör fel, jämföra versioner och behålla en historik. Och – inte minst – att inte betala en bråkdel av en cent till API:et för varje enskild användarsökning. En bråkdel som, multiplicerad med tiotusentals frågor per månad, snabbt slutar vara en bråkdel och blir en budgetpost.

När en komponent är så kritisk att dess fel fungerar korrumperar din förmåga att mäta allt annat, är det inte effektivt att delegera den till en svart låda. Det är en trosakt. Och trosakter betalar man ränta på ränta för i produktion.