VoyageAI by MongoDB: rerank-2.5-lite

rerank-2.5-lite is het lichtgewicht lid van de 2.5-rerankerrelease van Voyage AI. De fabrikant beschrijft het als een generalistisch model dat latentie en relevantiekwaliteit in balans brengt, met instructievolging 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 lichtgewicht relevantiebeslissing in de tweede fase

Het Lite-model verwerkt elk zoekvraag-documentpaar gezamenlijk als cross-encoder. Het kan volgen op een eerste zoekfase met embeddings of lexicaal zoeken 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.

Lever voor een interactieve hulpzoekfunctie de kandidaatverklaringen aan die de vraag van de gebruiker mogelijk beantwoorden. Behoud voldoende van elke passage om het gedrag en de bijbehorende voorwaarden over te brengen en behoud de koppeling tussen invoerindex en bronitem. Een gerichte kandidatenreeks helpt de reranktaak duidelijk te maken en houdt het opgehaalde bewijs bruikbaar voor weergave of een later antwoord.

Instructies drukken uit waaraan de gebruiker voorrang wil geven

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

Een illustratieve ondersteuningsvraag kan vragen welke passage een fout verklaart, met een instructie om stappen voor probleemoplossing voorrang te geven boven algemene productbeschrijvingen. Een documentzoekopdracht kan om de oorspronkelijke beleidstekst vragen in plaats van een bespreking van het beleid. Beschrijf het beoogde bewijs en houd de instructie beknopt. Instructies beïnvloeden relevantiescores; verwerk harde beperkingen voor versie, datum of toestemming in de kandidatenselectie in plaats van een relevantievoorkeur als gegarandeerd filter te behandelen.

Lees de rangschikking en geef de bronpassage terug

De uitvoer is gesorteerd op afnemende relevantie. Elk resultaat bevat de oorspronkelijke documentindex en een score als drijvendekommagetal; de optionele instelling return-documents geeft ook de bijbehorende invoertekst terug. De optie top-k bepaalt het aantal teruggegeven best gerangschikte resultaten; als die wordt weggelaten, wordt de rangschikking voor alle ingediende kandidaten teruggegeven.

Gebruik die indices om de bronpassage en haar identificator op te halen. Een opnieuw gerangschikte kandidaat kan een zoekresultaat of bewijs voor de volgende RAG-stap worden, maar de uitvoer is een ordening van aangeleverde tekst in plaats van een herschreven antwoord. Beoordeel of de leidende passages zowel aan de vraag als aan de relevantie-instructie voldoen, ook voor de talen en documenttypen die daadwerkelijk in de collectie voorkomen.

Limieten en een praktisch kandidatenbudget

De 2.5 Lite-editie heeft een gedocumenteerd zoekvraagmaximum van 8.000 tokens en een limiet van 32.000 tokens voor de zoekvraag plus elk afzonderlijk document. Zij onderscheidt zich van het eerdere rerank-2-lite-model en de kleinere context daarvan. 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 in kandidaatdocumenten.

Voor latentiegevoelig gebruik beveelt de FAQ van de maker rerank-2.5-lite aan met niet meer dan 200.000 tokens in totaal per verzoek. Dit is praktische begeleiding onder het genoemde maximum, geen ander venster per document. Een langere zoekvraag of instructie wordt eenmaal per kandidatenpaar geteld, dus zowel het aantal kandidaten als de zoekvraaglengte beïnvloeden het totaal.

Afkappen staat standaard aan en verkort te lange zoekvraag-/documentinvoer zodat die past; uitschakelen geeft een fout terug bij een te lange zoekvraag of een te lang paar. Bereid compacte kandidaten met antwoorddragende inhoud bewust voor, zodat bruikbaar bewijs niet buiten een afkapgrens valt. Minder uitvoerresultaten selecteren via top-k verwijdert de andere aangeleverde kandidaten niet uit de tokenberekening. Controleer de teruggegeven bronpassages en verfijn de invoervoorbereiding rond de daadwerkelijke vragen die de zoekinterface moet beantwoorden.