MongoDB flytter reranking ind i databasen – rerank-2.5 bliver legacy

MongoDB præsenterede rerank-3 og indbygget efterrangering i Atlas den 30. september 2026. Den nye model kan bruges via et selvstændigt API eller som sidste rangeringstrin i en Atlas-forespørgsel. For udviklere med et eksisterende RAG-system er modelskiftet og flytningen af efterrangeringen derfor to særskilte beslutninger.

MongoDBs oversigt over modelstatus angiver, at rerank-3 og rerank-3-lite blev Active den 29. september 2026, mens rerank-2.5 og rerank-2.5-lite samme dag blev Legacy. De ældre modeller er fortsat tilgængelige via Embedding and Reranking API. Legacy-status er således en anbefaling om at vælge afløserne til nye projekter, ikke en lukning af eksisterende API-kald.

rerank-3 ændrer rækkefølgen, ikke kandidatlisten

rerank-3 er en model til efterrangering: Den vurderer, hvor godt hvert fundet dokument passer til et spørgsmål, og sorterer kandidaterne efter relevans. OpenRouters modeloversigt registrerer udgivelsen den 30. september 2026 og beskriver samme funktion. Modellen skriver ikke svaret til brugeren; i et RAG-forløb bestemmer dens sortering, hvilke uddrag der først tilbydes den sprogmodel, som skal formulere svaret.

Den første søgning sætter stadig grænsen for, hvad efterrangeringen kan forbedre. Tekstsøgning, vektorsøgning eller en kombination finder dokumenter ud fra samlingen og dens filtre. Hvis det relevante dokument falder uden for kandidatlisten, kan rerank-3 ikke løfte det ind i resultatet. Derfor bør en evaluering skelne mellem, om søgningen fandt det rigtige dokument, og hvor modellen placerede det bagefter.

To veje fra søgning til RAG-svar

I en eksisterende integration med særskilt API henter applikationen kandidater fra søgesystemet, sender spørgsmål og dokumenttekst til rerankeren og samler den nye rækkefølge med dokumenternes øvrige data. Et skift fra rerank-2.5 til rerank-3 kan afprøves i dette forløb uden samtidig at ændre søgeindeks, filtre eller placeringen af dokumenterne. Det giver en sammenligning, hvor modellen er den tilsigtede forskel.

Med den indbyggede $rerank-operator sker efterrangeringen som et trin efter kandidatsøgningen i Atlas' aggregeringspipeline. Atlas-forespørgslen kan dermed returnere de omordnede dokumenter direkte, og applikationen behøver ikke selv at sende kandidaterne videre til et særskilt rerankingkald og samle svaret igen. For et system, hvor søgningen allerede foregår i Atlas, er det en konkret forenkling af integrationskoden; den siger i sig selv intet om den samlede svartid eller regning.

En flytning til operatoren ændrer også, hvem der vælger tekstfelter, kandidatantal og rækkefølgen før efterrangering: Det skal nu være korrekt udtrykt i databaseforespørgslen. Udviklere bør derfor kontrollere, at de dokumentfelter, som modellen skal læse, findes i alle relevante resultater, og at den forudgående søgning leverer en stabil og tilstrækkelig kandidatliste. De skal desuden kontrollere den aktuelle understøttelse af rerank-3 for deres Atlas-klynge; modellens Active-status beskriver ikke alene kravene til en bestemt integrationsvej.

Migrationen bør deles i et modelskift og en arkitekturændring

Den mest oplysende rækkefølge er at måle den nuværende løsning og derefter udskifte rerank-2.5 med rerank-3 i samme API-forløb. Behold spørgsmål, dokumentsamling, søgemetode, filtre og kandidatantal faste. Dermed kan ændringer i relevans og svartid knyttes tættere til modelskiftet, selv om almindelig variation i drift stadig skal medregnes.

Først i en særskilt sammenligning bør $rerank overtage efterrangeringen i Atlas. Her skal den samlede forespørgsel levere samme kandidater og samme tekst til modellen som API-varianten, hvis formålet er at isolere arkitekturens virkning. Ændres søgningen, tekstuddragene eller antallet af kandidater samtidig, måles en ny RAG-konfiguration snarere end effekten af at flytte ét trin.

Også applikationens brug af resultatet kræver gennemgang. Kode, der gemmer relevansscore, antager en bestemt rækkefølge eller bruger en tærskel til at fravælge dokumenter, kan ændre adfærd efter et modelskift. Kontroller samtidig, hvordan tomme resultater, fejl og tidsgrænser håndteres på de to integrationsveje, så en teknisk ændring ikke utilsigtet ændrer, hvilket grundlag sprogmodellen får.

Tre målinger afgør, om skiftet gavner systemet

En reproducerbar evaluering skal bruge de samme spørgsmål og en fast version af dokumenterne i alle varianter. Spørgsmålene bør afspejle systemets faktiske opgaver, herunder danske formuleringer, lange dokumenter og præcise fagudtryk, hvis de findes i samlingen. Marker på forhånd, hvilke dokumenter der er relevante, så vurderingen ikke afhænger af, hvilket svar en enkelt model tilfældigvis giver.

• Relevans: Registrer først, om hvert relevant dokument nåede kandidatlisten, og derefter dets placering efter reranking. Se også på, om de uddrag, som faktisk sendes til sprogmodellen, rummer den nødvendige information. En bedre placering i en leverandørtest kan ikke erstatte denne kontrol på egne dokumenter.
• Svartid: Mål både tiden til et færdigt, rangeret kandidatsæt og tiden til det endelige RAG-svar. Gentag målingen under en belastning, der svarer til systemets normale brug, og registrer forsinkelser i den tunge ende af fordelingen. At applikationen foretager færre kald, er en arkitektonisk ændring, ikke en målt hastighedsgevinst.
• Driftsomkostning: Registrer tekstmængde og antal kandidater, der behandles ved hver forespørgsel, sammen med udgifter til reranking, Atlas og den efterfølgende sprogmodel. Sammenlign ved samme arbejdsbyrde og samme mængde kontekst til svarmodellen; ellers kan en billigere forespørgsel blot skyldes, at færre dokumenter blev vurderet.

Beslutningen om at erstatte rerank-2.5 afhænger dermed af, om rerank-3 giver en bedre rangering på systemets egne spørgsmål inden for dets krav til svartid og pris. En flytning til $rerank skal vurderes oveni: Den ændrer integrationen omkring modellen og kræver, at Atlas-forespørgslen bevarer den kandidatliste, som RAG-svaret bygger på.

Læs også:

• Confido rejser 55 mio. dollar – AI flytter ind i varebrandets bagkontor
• Skriv en AI-politik, før medarbejdere kopierer persondata ind
• Kraken eller Coinbase? Ordretypen flytter kryptogebyret