VoyageAI by MongoDB: rerank-2.5-lite

rerank-2.5-lite er det lette medlem af Voyage AI's 2.5-rerankerudgivelse. Producenten beskriver den som en generalistmodel, der afvejer latens og relevanskvalitet med instruktionsefterlevelse i naturligt sprog og flersproget understøttelse. Dens input er en forespørgsel og kandidattekster, og dens output er en finjusteret rækkefølge af disse kandidater med relevansscorer.

En let relevansafgørelse i andet trin

Lite-modellen behandler hvert forespørgsels-dokumentpar samlet som en cross-encoder. Den kan følge efter en første embedding- eller leksikalsk søgning og finjustere de tekststykker, dette trin valgte. Det adskiller sig fra at forberede et genbrugeligt embeddingindeks: rerankeren undersøger den indsendte forespørgsel og dokumenttekst samlet til den aktuelle relevansafgørelse.

Til en interaktiv hjælpesøgning skal du indsende de kandidatforklaringer, der kan besvare brugerens spørgsmål. Bevar tilstrækkeligt af hvert tekststykke til at formidle adfærden og dens forbehold, og bevar forbindelsen mellem inputindekset og kildeelementet. Et fokuseret kandidatsæt hjælper med at tydeliggøre omrangeringsopgaven, mens det hentede belæg forbliver anvendeligt til visning eller et senere svar.

Instruktioner udtrykker det, brugeren vil prioritere

Ligesom rerank-2.5 accepterer Lite instruktioner i naturligt sprog før eller efter forespørgslen. Producentens eksempler bruger dem til at fremhæve dokumentdele, vælge en foretrukken kildetype eller tilføje kontekst til et tvetydigt ord. En applikation kan levere en fast relevanspræference, eller det aktuelle spørgsmål kan indeholde en mere specifik.

En illustrativ supportforespørgsel kan spørge, hvilket tekststykke der forklarer en fejl, med en instruktion om at prioritere fejlfindingstrin frem for generelle produktbeskrivelser. En dokumentsøgning kan bede om en politiks oprindelige ordlyd frem for en drøftelse af politikken. Beskriv det tilsigtede belæg, og hold instruktionen kort. Instruktioner påvirker relevansscorer; forbered eventuelle strenge versions-, dato- eller rettighedsbegrænsninger i kandidatudvælgelsen frem for at behandle en relevanspræference som et garanteret filter.

Læs rangeringen, og returnér kildetekststykket

Outputtet sorteres efter faldende relevans. Hvert resultat omfatter det oprindelige dokumentindeks og et flydende kommatal som score; den valgfrie return-documents-indstilling returnerer også den tilsvarende inputtekst. Indstillingen top-k bestemmer antallet af øverste resultater, der returneres, mens udeladelse af den returnerer rangeringen for alle indsendte kandidater.

Brug disse indeks til at genskabe kildetekststykket og dets id. En omrangeret kandidat kan blive et søgeresultat eller belæg til næste RAG-trin, men outputtet er en ordning af leveret tekst frem for et omskrevet svar. Vurdér, om de øverste tekststykker opfylder både spørgsmålet og relevansinstruktionen, også på de sprog og dokumenttyper, der faktisk findes i samlingen.

Grænser og et praktisk kandidatbudget

Udgaven 2.5 Lite har et dokumenteret forespørgselsmaksimum på 8.000 tokens og en grænse på 32.000 tokens for forespørgslen plus hvert enkelt dokument. Den adskiller sig fra den tidligere rerank-2-lite-model og dens mindre kontekst. Højst 1.000 dokumenter kan indsendes, og samlet input er begrænset til 600.000 tokens efter formlen: forespørgselstokens ganget med kandidatantal plus summen af kandidatdokumenternes tokens.

Til latensfølsom brug anbefaler producentens FAQ rerank-2.5-lite med højst 200.000 samlede tokens pr. anmodning. Det er praktisk vejledning under det angivne maksimum, ikke et andet vindue pr. dokument. En længere forespørgsel eller instruktion tælles én gang for hvert kandidatpar, så både kandidatantal og forespørgselslængde påvirker totalen.

Trunkering er aktiveret som standard og forkorter for lange forespørgsels- eller dokumentinput, så de passer; deaktivering returnerer en fejl ved en for lang forespørgsel eller et for langt par. Forbered bevidst kompakte kandidater, der indeholder svaret, så nyttigt belæg ikke ligger uden for en trunkeret grænse. Valg af færre outputresultater med top-k fjerner ikke de øvrige leverede kandidater fra tokenberegningen. Undersøg de returnerede kildetekststykker, og præcisér inputforberedelsen omkring de faktiske spørgsmål, søgegrænsefladen skal besvare.