VoyageAI by MongoDB: rerank-3-lite

Voyage rerank-3-lite is de op lage latentie gerichte editie van de Rerank 3-serie van Voyage. Het neemt een tekstuele zoekvraag en kandidaatdocumenten aan, beoordeelt elk zoekvraag-documentpaar gezamenlijk en geeft relevantiescores in gerangschikte volgorde terug. Het verzorgt de tweede zoekfase: een embedding- of trefwoordzoekfunctie vindt de kandidaten en daarna verfijnt Lite hun volgorde. Het resultaat is een rangschikking voor gebruik in zoeken of een retrieval-augmented generation-workflow.

Wat verandert in Rerank 3 Lite De producent benadrukt sterkere retrieval voor lange documenten en code vergeleken met rerank-2.5-lite. Beide Rerank 3-edities behouden instructievolging en dezelfde contextklasse van 32K, terwijl Lite is ontworpen voor toepassingen die gevoelig zijn voor latentie. Dit maakt het een praktische kandidaat voor interactieve zoekfuncties in kennisbanken, retrieval van ondersteuningsdocumenten en het opzoeken van code wanneer gebruikers snel relevante resultaten nodig hebben. Kies op basis van de kwaliteits- en responstijdeisen van de daadwerkelijke collectie, in plaats van aan te nemen dat een kleinere editie een kleiner contextvenster betekent.

Stuur relevantie met de zoekvraag Instructies in natuurlijke taal kunnen de zoekvraag aanvullen om uit te leggen wat als relevant geldt. Houd de vraag en de relevantievoorkeur beknopt en consistent. Gebruik voor een zoekopdracht naar softwareondersteuning: “Vind de procedure om een apparaat te resetten; geef voorrang aan instructies voor de vermelde hardwarerevisie.” Voeg bij een dubbelzinnige productnaam de productcategorie toe, zodat niet-gerelateerde betekenissen niet overheersen. Een voorkeur in de zoekvraag stuurt de semantische scoring; gebruik expliciete collectiemetadata om het juiste product, de documentversie of de toegangsafbakening te selecteren voordat je de kandidatenlijst opbouwt.

Bereid een shortlist van tekstkandidaten voor De invoerdocumenten zijn strings. Extraheer leesbare tekst uit bronmateriaal en behoud bruikbare titels, koppen, identificatoren en omringende context. Houd een stabiele koppeling van elke invoerpositie naar de oorspronkelijke registratie bij. Neem voor een probleemoplossingsartikel het symptoom en de relevante procedure op, niet alleen een losse zin. Neem voor broncodezoeken de functie en nabijgelegen informatie op die nodig is om haar van gelijknamige functies te onderscheiden. Verwijder herhaalde navigatie of standaardtekst wanneer die de bruikbare passage verdringt.

De reranker kan alleen de documenten herschikken die hij ontvangt. Als de eerste zoekopdracht het relevante artikel nooit ophaalt, kan deze fase die ontbrekende kandidaat niet terughalen. Controleer zowel de shortlist als de uiteindelijke volgorde wanneer een resultaat onjuist lijkt. Splits een lang document met veel onderwerpen in samenhangende secties en behoud de verwijzingen naar het bovenliggende document, zodat een relevante sectie kan worden geselecteerd zonder de bron te verliezen.

Context en verzoeklimieten De huidige gids van de maker specificeert een zoekvraagmaximum van 8.000 tokens en een gecombineerd maximum van 32.000 tokens voor de zoekvraag plus elk afzonderlijk document. Er zijn maximaal 1.000 kandidaatdocumenten en een totaal verzoekbudget van 600.000 tokens toegestaan, berekend als zoekvraagtokens vermenigvuldigd met het aantal documenten, plus alle documenttokens. Een lange zoekvraag verbruikt dus ruimte in elk paar en telt herhaaldelijk mee in het totale budget. Tel de ingediende tekst met de juiste modeltokenizer in plaats van tekens, woorden en tokens als uitwisselbaar te beschouwen.

Een zoekvraag van 500 tokens met 100 documenten van elk 4.000 tokens komt volgens die formule bijvoorbeeld op 450.000 invoertokens. Dit illustreert budgettering, geen aanbevolen shortlistgrootte of gemeten snelheidsresultaat. De gedocumenteerde afkapoptie staat standaard aan; te grote tekst kan vóór de scoring worden ingekort. Bereid belangrijke secties bewust voor, zodat afkappen niet precies de passage verwijdert die je wilt laten overeenkomen.

Lees en gebruik het resultaat Resultaten worden gesorteerd van de hoogste relevantiescore naar beneden. Elk resultaat identificeert de oorspronkelijke invoerpositie van het document, zodat de toepassing haar eigen titel, registratie-ID en bron kan toevoegen. De instelling top_k bepaalt hoeveel gerangschikte kandidaten worden teruggegeven; zonder die instelling worden alle kandidaten teruggegeven. De REST-interface van de maker kan ook de documenttekst teruggeven. Bewaar de oorspronkelijke identificatoren bij de geselecteerde resultaten wanneer je een zoekpagina toont of bewijs doorgeeft aan een stap voor antwoordgeneratie.

Een relevantiescore drukt uit hoe goed een kandidaat bij de zoekvraag past; zij stelt niet vast dat de beweringen van die kandidaat juist zijn. Vergelijk de hoogst gerangschikte items met de daadwerkelijke vraag van de gebruiker, inclusief uitsluitingen en verschillen tussen documentversies. Als elke kandidaat irrelevant is, bestaat er nog steeds een hoogst gerangschikt item. Bepaal met representatieve zoekvragen uit de collectie hoe de toepassing dat geval afhandelt.

Upgraden en de editie kiezen De maker beschrijft rerank-3-lite als een upgrade van rerank-2.5-lite met ongewijzigde API-semantiek en scores die zijn gekalibreerd op de verdeling van de overeenkomstige voorganger. Behoud de bestaande registratiekoppeling en retrievalfase en vergelijk vervolgens de resulterende volgorde voor betekenisvolle zoekvragen voordat je vertrouwt op een bestaande scoredrempel. Gebruik Lite voor een zoekervaring waarin responstijd belangrijk is; gebruik de op kwaliteit gerichte rerank-3-editie ter vergelijking wanneer relevantie bij lastige kandidaten de grotere prioriteit heeft.