VoyageAI by MongoDB: rerank-2.5-lite

rerank-2.5-lite is het lichte model in de 2.5-rerankerrelease van Voyage AI. De fabrikant beschrijft het als een generalistisch model dat latentie en relevantiekwaliteit in evenwicht brengt, met instructies volgen in natuurlijke taal en meertalige ondersteuning. De invoer bestaat uit een zoekvraag en kandidaatteksten en de uitvoer is een verfijnde volgorde van die kandidaten met relevantiescores.

Een lichte relevantiebeslissing in de tweede fase

Het Lite-model verwerkt elk paar van zoekvraag en document samen als een cross-encoder. Het kan op een eerste embedding- of lexicale zoekfase volgen en de door die fase geselecteerde passages verfijnen. Dit verschilt van het voorbereiden van een herbruikbare embeddingindex: de reranker onderzoekt de ingediende zoekvraag en documenttekst samen voor de huidige relevantiebeslissing.

Dien voor een interactieve helpzoekfunctie de kandidaatuitleg in die de gebruikersvraag mogelijk beantwoordt. Behoud genoeg van elke passage om het gedrag en de voorwaarden duidelijk te maken en bewaar het verband tussen de invoerindex en het bronitem. Een gerichte kandidaatverzameling helpt de herschiktaak duidelijk te maken en laat het opgehaalde bewijsmateriaal tegelijk bruikbaar voor weergave of een later antwoord.

Instructies drukken uit wat de gebruiker voorrang wil geven

Net als rerank-2.5 aanvaardt Lite instructies in natuurlijke taal vóór of na de zoekvraag. De voorbeelden van de maker gebruiken die om documentonderdelen te benadrukken, een voorkeursbrontype te selecteren of context aan een dubbelzinnig woord toe te voegen. Een toepassing kan een vaste relevantievoorkeur meegeven of de huidige vraag kan een specifiekere voorkeur bevatten.

Een illustratieve supportzoekvraag kan vragen welke passage een fout uitlegt, met een instructie om probleemoplossingsstappen voorrang te geven boven algemene productbeschrijvingen. Een documentzoekopdracht kan om de oorspronkelijke beleidsformulering vragen in plaats van een bespreking van het beleid. Beschrijf het beoogde bewijsmateriaal en houd de instructie beknopt. Instructies beïnvloeden relevantiescores; leg eventuele strikte versie-, datum- of toegangsbeperkingen vast bij de kandidaatselectie in plaats van een relevantievoorkeur als een gegarandeerd filter te behandelen.

Lees de rangschikking en geef de bronpassage terug

De uitvoer wordt op afnemende relevantie gesorteerd. Elk resultaat bevat de oorspronkelijke documentindex en een score als zwevendekommagetal; de optionele instelling return-documents geeft ook de bijbehorende invoertekst terug. De optie top-k bepaalt hoeveel hoogst gerangschikte resultaten worden teruggegeven, terwijl weglaten ervan de rangschikking voor alle ingediende kandidaten teruggeeft.

Gebruik die indices om de bronpassage en haar identifier terug te vinden. Een herschikte kandidaat kan een zoekresultaat of bewijsmateriaal voor de volgende RAG-stap worden, maar de uitvoer is een ordening van aangeleverde tekst en geen herschreven antwoord. Beoordeel of de bovenste passages zowel aan de vraag als de relevantie-instructie voldoen, ook voor de talen en documenttypen die werkelijk in de verzameling voorkomen.

Limieten en een praktisch kandidatenbudget

De editie 2.5 Lite heeft een gedocumenteerd zoekvraagmaximum van 8.000 tokens en een limiet van 32.000 tokens voor de zoekvraag plus elk afzonderlijk document. Ze verschilt van het eerdere rerank-2-lite-model met zijn kleinere context. Er kunnen maximaal 1.000 documenten worden ingediend en de totale invoer is beperkt tot 600.000 tokens volgens de formule: zoekvraagtokens vermenigvuldigd met het aantal kandidaten, plus de som van de tokens van de kandidaatdocumenten.

Voor latentiegevoelig gebruik beveelt de FAQ van de maker rerank-2.5-lite aan met maximaal 200.000 totale tokens per aanvraag. Dit is praktisch advies onder het opgegeven maximum, geen ander venster per document. Een langere zoekvraag of instructie wordt eenmaal per kandidaatpaar geteld, zodat zowel het aantal kandidaten als de lengte van de zoekvraag het totaal beïnvloeden.

Afkappen is standaard ingeschakeld en kort te lange zoekvraag-/documentinvoer in om die passend te maken; uitschakelen geeft een fout bij een te lange zoekvraag of een te lang paar. Bereid compacte kandidaten met antwoorddragende inhoud bewust voor, zodat nuttig bewijsmateriaal niet buiten een afkapgrens valt. Minder uitvoerresultaten selecteren via top-k verwijdert de andere aangeleverde kandidaten niet uit de tokenberekening. Onderzoek de teruggegeven bronpassages en verfijn de invoervoorbereiding rond de werkelijke vragen die de zoekinterface moet beantwoorden.