VoyageAI by MongoDB: rerank-3-lite

Voyage rerank-3-lite is de op lage latentie gerichte editie van de Rerank 3-reeks van Voyage. Het verwerkt een tekstuele zoekvraag en kandidaatdocumenten, beoordeelt elk paar van zoekvraag en document samen en geeft relevantiescores in gerangschikte volgorde terug. Het vormt de tweede zoekfase: een embedding- of trefwoordzoeker vindt de kandidaten, waarna Lite hun volgorde verfijnt. Het resultaat is een rangschikking voor gebruik in zoeken of een workflow voor retrieval-augmented generation.

Wat verandert in Rerank 3 Lite De producent benadrukt betere informatieophaling uit lange documenten en code ten opzichte van rerank-2.5-lite. Beide Rerank 3-edities behouden de mogelijkheid om instructies te volgen en dezelfde contextklasse van 32K, terwijl Lite voor latentiegevoelige toepassingen is ontworpen. Daardoor is het een praktische kandidaat voor interactief zoeken in kennisbanken, het ophalen van supportdocumenten en het opzoeken van code wanneer gebruikers snel relevante resultaten nodig hebben. Kies het op basis van de kwaliteits- en responstijdvereisten van de werkelijke verzameling 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 vergezellen om uit te leggen wat relevant is. Houd de vraag en de relevantievoorkeur beknopt en consistent. Gebruik voor een zoekopdracht in softwaresupport bijvoorbeeld: “Vind de procedure om een apparaat te resetten; geef voorrang aan instructies voor de opgegeven hardwarerevisie.” Voeg bij een dubbelzinnige productnaam de productcategorie toe, zodat ongerelateerde betekenissen niet overheersen. Een voorkeur in de zoekvraag stuurt de semantische score; gebruik expliciete metagegevens van de verzameling om het juiste product, de documentversie of het toegangsbereik te selecteren voordat je de kandidatenlijst opbouwt.

Bereid een shortlist van tekstkandidaten voor De invoerdocumenten zijn strings. Haal leesbare tekst uit bronmateriaal en behoud nuttige titels, koppen, identifiers en omliggende context. Houd een stabiele koppeling bij van elke invoerpositie naar de oorspronkelijke registratie. Voeg bij een artikel over probleemoplossing het symptoom en de relevante procedure toe, niet alleen een losstaande zin. Voeg voor zoeken in broncode de functie en nabijgelegen informatie toe die nodig is om die van gelijknamige functies te onderscheiden. Verwijder herhaalde navigatie of standaardtekst wanneer die de nuttige 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 terugvinden. Onderzoek zowel de shortlist als de eindvolgorde wanneer een resultaat verkeerd lijkt. Deel een lang document met veel onderwerpen op in samenhangende secties en behoud hun verwijzingen naar het bovenliggende document, zodat een relevante sectie geselecteerd kan worden zonder de bron te verliezen.

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

Een zoekvraag van 500 tokens met 100 documenten van elk 4.000 tokens telt volgens die formule bijvoorbeeld als 450.000 invoertokens. Dit illustreert de budgetberekening, geen aanbevolen shortlistgrootte of gemeten snelheidsresultaat. De gedocumenteerde afkapoptie is standaard ingeschakeld; te lange tekst kan vóór het scoren worden ingekort. Bereid belangrijke secties bewust voor, zodat het afkappen niet precies de passage verwijdert die je wilt laten overeenkomen.

Lees en gebruik het resultaat Resultaten worden van de hoogste relevantiescore naar beneden gesorteerd. Elk resultaat benoemt de oorspronkelijke invoerpositie van het document, zodat de toepassing haar eigen titel, registratie-identifier 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. Behoud de oorspronkelijke identifiers bij de geselecteerde resultaten wanneer je een zoekpagina toont of bewijsmateriaal aan een antwoordgeneratiestap doorgeeft.

Een relevantiescore drukt uit hoe goed een kandidaat bij de zoekvraag past; ze stelt niet vast dat de beweringen van de kandidaat correct zijn. Vergelijk de hoogst gerangschikte items met de werkelijke gebruikersvraag, inclusief uitsluitingen en verschillen in documentversie. Als elke kandidaat irrelevant is, bestaat er nog steeds een hoogst gerangschikt item. Bepaal met representatieve zoekvragen uit de verzameling hoe je toepassing daarmee omgaat.

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 op de verdeling van de overeenkomstige voorganger zijn gekalibreerd. Behoud de bestaande registratiekoppeling en ophaalfase en vergelijk vervolgens de resulterende volgorde op betekenisvolle zoekvragen voordat je op een bestaande scoredrempel vertrouwt. Gebruik Lite voor een zoekervaring waarbij responstijd telt; gebruik de kwaliteitsgerichte editie rerank-3 als vergelijking wanneer relevantie bij moeilijke kandidaten zwaarder weegt.