VoyageAI by MongoDB: rerank-2.5-lite

rerank-2.5-lite er det lette medlemmet i Voyage AIs 2.5-utgivelse av omrangeringsmodeller. Produsenten beskriver den som en generalistmodell som balanserer latenstid og relevanskvalitet, med instruksjonsfølging på naturlig språk og flerspråklig støtte. Inndataene er en spørring og kandidattekster, og utdataene er en forbedret rekkefølge for disse kandidatene med relevansskårer.

En lett relevansavgjørelse i andre trinn

Lite-modellen behandler hvert spørring–dokument-par samlet som en kryssenkoder. Den kan følge etter et embedding- eller leksikalsk søk i første trinn og finjustere tekstutdragene dette trinnet valgte. Dette skiller seg fra å forberede en gjenbrukbar embedding-indeks: omrangeringsmodellen undersøker den innsendte spørringen og dokumentteksten samlet for den aktuelle relevansavgjørelsen.

For et interaktivt hjelpesøk sender du inn kandidatforklaringene som kan besvare brukerens spørsmål. Behold nok av hvert tekstutdrag til å formidle oppførselen og forbeholdene ved den, og bevar koblingen mellom inndataindeksen og kildeelementet. Et avgrenset kandidatsett bidrar til å gjøre omrangeringsoppgaven tydelig, samtidig som det innhentede belegget forblir brukbart for visning eller et senere svar.

Instruksjoner uttrykker hva brukeren vil prioritere

Som rerank-2.5 godtar Lite instruksjoner på naturlig språk før eller etter spørringen. Produsentens eksempler bruker dem til å fremheve dokumentdeler, velge en foretrukket kildetype eller gi kontekst til et tvetydig ord. En applikasjon kan gi en fast relevanspreferanse, eller det aktuelle spørsmålet kan inneholde en mer spesifikk preferanse.

En illustrerende støttespørring kan spørre hvilket tekstutdrag som forklarer en feil, med en instruksjon om å prioritere feilsøkingstrinn fremfor generelle produktbeskrivelser. Et dokumentsøk kan be om den opprinnelige ordlyden i retningslinjer fremfor en diskusjon av retningslinjene. Beskriv det tiltenkte belegget, og hold instruksjonen kort. Instruksjoner påvirker relevansskårer; forbered eventuelle strenge versjons-, dato- eller tilgangsbegrensninger i kandidatutvalget, fremfor å behandle en relevanspreferanse som et garantert filter.

Les rangeringen og returner kildeteksten

Utdataene sorteres etter synkende relevans. Hvert resultat inneholder den opprinnelige dokumentindeksen og en flyttallsskår; det valgfrie return-documents-valget returnerer også den tilsvarende inndatateksten. Valget top-k bestemmer hvor mange av de fremste resultatene som returneres, mens utelatelse av det returnerer rangeringen for alle innsendte kandidater.

Bruk disse indeksene til å hente kildeteksten og identifikatoren. En omrangert kandidat kan bli et søkeresultat eller belegg for neste RAG-trinn, men utdataene er en ordning av gitt tekst fremfor et omskrevet svar. Vurder om de fremste tekstutdragene oppfyller både spørsmålet og relevansinstruksjonen, også for språkene og dokumenttypene som faktisk finnes i samlingen.

Grenser og et praktisk kandidatbudsjett

2.5 Lite-utgaven har et dokumentert spørringsmaksimum på 8 000 tokener og en grense på 32 000 tokener for spørringen pluss hvert enkelt dokument. Den er atskilt fra den tidligere rerank-2-lite-modellen og dens mindre kontekst. Maksimalt 1000 dokumenter kan sendes inn, og totale inndata er begrenset til 600 000 tokener etter formelen: spørringstokener multiplisert med antall kandidater, pluss summen av kandidatdokumentenes tokener.

For bruk som er følsom for latenstid, anbefaler produsentens FAQ rerank-2.5-lite med maksimalt 200 000 tokener totalt per forespørsel. Dette er praktisk veiledning under det angitte maksimumet, ikke et annet vindu per dokument. En lengre spørring eller instruksjon telles én gang for hvert kandidatpar, så både antall kandidater og spørringslengden påvirker totalen.

Avkorting er aktivert som standard og forkorter for lange spørrings-/dokumentinndata slik at de får plass; når den deaktiveres, returneres en feil for en for lang spørring eller et for langt par. Forbered kompakte kandidater som inneholder svaret, bevisst, slik at nyttig belegg ikke havner utenfor en avkortet grense. Å velge færre utdataresultater med top-k fjerner ikke de andre innsendte kandidatene fra tokenberegningen. Undersøk de returnerte kildetekstene, og forbedre inndataforberedelsen rundt de faktiske spørsmålene søkegrensesnittet må besvare.