VoyageAI by MongoDB: rerank-3

Voyage rerank-3 is een tekstreranker die is ontworpen om de kwaliteit van opgehaald bewijsmateriaal te verbeteren. Het onderzoekt bij een zoekvraag en een lijst kandidaatdocumenten elk paar gezamenlijk en geeft de kandidaten op relevantie gerangschikt terug. Embeddings en trefwoordzoeken kunnen een grote collectie eerst tot een beheersbare shortlist beperken; rerank-3 past daarna een gedetailleerdere relevantiebeoordeling op die shortlist toe. De uitvoer is gescoord zoekbewijsmateriaal dat een toepassing kan tonen of doorgeven aan een afzonderlijke stap voor antwoordgeneratie.

Rerank 3 met de nadruk op kwaliteit De maker positioneert rerank-3 als de op nauwkeurigheid gerichte editie en rerank-3-lite als de editie voor latentiegevoelige zoekfuncties. De derde generatie vernieuwt de backbone en de trainingsmix, met bijzondere verbeteringen voor retrieval van lange documenten en broncode tegenover de overeenkomstige 2.5-voorgangers. De producent evalueert het model op technische documentatie, code, meertalig materiaal en andere documentdomeinen. Die resultaten ondersteunen de retrievalrol; selecteer de editie op basis van de vragen en kandidaatdocumenten die voor je eigen collectie van belang zijn.

Lange documenten met voldoende context Een lange kandidaat kan nuttige context bevatten ver voorbij de openingsalinea. Lever een samenhangende sectie of een document aan met de titel en het relevante omringende materiaal, zodat het model kan beoordelen hoe de daadwerkelijke vraag verband houdt met de inhoud. Behoud bij een zoekopdracht naar productbeleid de koppen en uitzonderingen rond de betreffende passage. Als meerdere opgehaalde secties uit dezelfde bron komen, behoud dan hun document- en sectie-identificatoren; de toepassing kan vervolgens tonen waar het geselecteerde bewijs vandaan komt.

Het contextvenster wordt gedeeld door de zoekvraag en elke kandidaat. De huidige gids van de maker specificeert 32.000 tokens voor dat paar, inclusief een zoekvraag van maximaal 8.000 tokens. Een zoekvraag van 3.000 tokens laat dus maximaal 29.000 tokens voor elk document over. Bereid de invoer zo voor dat de essentiële inhoud past, vooral wanneer een lange inleiding of herhaalde standaardtekst anders het venster zou vullen. De gedocumenteerde afkapoptie staat standaard aan en kan te lange zoekvraag- of documenttekst vóór de scoring inkorten. Controleer wat behouden blijft wanneer de plaats van de passage van belang is.

Code en technische retrieval Voor de retrievalfase van een programmeerassistent kunnen kandidaten functie-implementaties, API-documentatie of technische uitleg als tekst bevatten. Neem de symbolen, signaturen en context op die nodig zijn om vergelijkbare kandidaten te onderscheiden. Een zoekvraag zoals “Vind de functie die paden normaliseert en daarbij een afsluitend scheidingsteken behoudt” geeft concreet gedrag om op te matchen. Voeg relevante beperkingen voor taal, platform of versie toe. Onderzoek na rangschikking de geselecteerde code en afhankelijkheden voordat je die als context gebruikt; een relevantiescore bewijst niet dat een implementatie aan elke genoemde vereiste voldoet.

Instructies definiëren relevantie Het model behoudt de instructievolgende rerankmogelijkheid die in Rerank 2.5 werd geïntroduceerd. Zet een beknopte instructie vóór of achter de zoekvraag wanneer de intentie van de gebruiker verduidelijking nodig heeft. Leg voor zoeken in onderzoeksdocumenten uit of de nadruk ligt op de titel, een specifieke methode of een toepassingsdomein. Specificeer voor een interne catalogus of het verzoek installatie, probleemoplossing of compatibiliteit betreft. Houd die instructie in lijn met de vraag; extra voorkeuren die met het hoofdverzoek botsen, kunnen veranderen wat de rangschikking probeert te optimaliseren.

Bereid kandidaatdocumenten en budgetten voor De invoer is een lijst tekststrings. Extraheer bruikbare tekst uit brondocumenten, behoud betekenisvolle sectiegrenzen en houd naast de lijst een geordende registratiekoppeling bij. De maker staat maximaal 1.000 documenten in één verzoek toe. Hij specificeert ook een totale invoerlimiet van 600.000 tokens: zoekvraagtokens vermenigvuldigd met het aantal documenten, plus de som van alle documenttokens. Dit verschilt van de contextlimiet per paar. Het verminderen van overbodige zoekvraagtekst kan zowel paarcapaciteit als het totale verzoekbudget vrijhouden.

Tel tokens voor het relevante model in plaats van aan te nemen dat een woord- of tekenaantal een tokenaantal is. Selecteer bij grote kandidaten samenhangende passages of deel het materiaal op bij bruikbare koppen met behoud van informatie over de bovenliggende bron. Reranking is het nuttigst nadat de eerste zoekopdracht al aannemelijke kandidaten heeft gevonden: het kan een ontbrekende bron die nooit in de lijst kwam niet rangschikken.

Gerangschikte resultaten en vervolggebruik Het resultaat bevat relevantiescores en indices die naar de oorspronkelijke invoerdocumenten verwijzen, gesorteerd op aflopende relevantie. De optie top_k beperkt het aantal teruggegeven gerangschikte resultaten; anders worden alle invoerkandidaten teruggegeven. De REST-interface van de maker laat ook toe dat de documenttekst wordt opgenomen. Gebruik elke oorspronkelijke index om de titel, bronidentificator en eventuele metadata op te halen die de toepassing nodig heeft en presenteer vervolgens de geselecteerde items of neem de relevante tekst op in de bewijscontext van een antwoord.

Controleer de bovenste resultaten aan de hand van de vraag en houd de bronidentiteit zichtbaar. Een hoge relatieve positie verifieert niet de feitelijke juistheid van een document en een shortlist met alleen slechte kandidaten heeft nog steeds een eerste item. Scheid relevantieselectie van de beslissing of het geselecteerde bewijs voldoende is om de gebruiker te antwoorden.

Editiemigratie De maker beschrijft rerank-3 als een direct inzetbare opvolger van rerank-2.5, met dezelfde API-semantiek en scores die zijn gekalibreerd op de verdeling van de overeenkomstige voorganger. Die compatibiliteit ondersteunt het behoud van een bestaande retrievalfase en registratiekoppeling. Vergelijk betekenisvolle resultaatvolgorden en eventuele scoredrempels op het huidige corpus voordat je op de migratie vertrouwt. Houd rerank-3 en rerank-3-lite als afzonderlijke keuzes: gedeelde limieten en instructievolging maken hun kwaliteits- en latentieprioriteiten niet identiek.