VoyageAI by MongoDB: rerank-3-lite

Voyage rerank-3-lite er den latenstidsorienterte utgaven av Voyages Rerank 3-serie. Den tar imot en tekstspørring og kandidatdokumenter, vurderer hvert spørring–dokument-par samlet og returnerer relevansskårer i rangert rekkefølge. Den dekker søkets andre trinn: en embedding- eller nøkkelordbasert innhenter finner kandidatene, og deretter finjusterer Lite rekkefølgen. Resultatet er en rangering som kan brukes i søk eller en arbeidsflyt for generering med støtte fra innhentet informasjon.

Hva som endres i Rerank 3 Lite Produsenten fremhever bedre innhenting fra lange dokumenter og kode sammenlignet med rerank-2.5-lite. Begge Rerank 3-utgavene beholder instruksjonsfølging og samme kontekstklasse på 32K, mens Lite er utviklet for applikasjoner som er følsomme for latenstid. Dette gjør den til en praktisk kandidat for interaktivt søk i kunnskapsbaser, innhenting av støttedokumenter og kodeoppslag når brukere trenger relevante resultater raskt. Velg den ut fra kvalitets- og responstidskravene til den faktiske samlingen, fremfor å anta at en mindre utgave betyr et mindre kontekstvindu.

Styr relevansen med spørringen Instruksjoner på naturlig språk kan følge spørringen for å forklare hva som regnes som relevant. Hold spørsmålet og relevanspreferansen korte og konsekvente. For et programvarestøttesøk kan du bruke «Finn fremgangsmåten for å tilbakestille en enhet; prioriter instruksjoner for den oppgitte maskinvarerevisjonen.» For et tvetydig produktnavn tar du med produktkategorien, slik at uvedkommende betydninger ikke dominerer. En preferanse i spørringen styrer semantisk skåring; bruk uttrykkelige metadata i samlingen for å velge riktig produkt, dokumentversjon eller tilgangsomfang før du bygger kandidatlisten.

Forbered en kortliste med tekstkandidater Inndatadokumentene er strenger. Hent ut lesbar tekst fra kildematerialet, og behold nyttige titler, overskrifter, identifikatorer og omkringliggende kontekst. Hold en stabil kobling fra hver inndataposisjon til den opprinnelige oppføringen. For en feilsøkingsartikkel tar du med symptomet og den relevante fremgangsmåten, ikke bare en løsrevet setning. For kildekodesøk tar du med funksjonen og nærliggende informasjon som trengs for å skille den fra funksjoner med lignende navn. Fjern gjentakende navigasjon eller standardtekst når den fortrenger det nyttige tekstutdraget.

Omrangeringsmodellen kan bare omordne dokumentene den mottar. Hvis det første søket aldri henter den relevante artikkelen, kan ikke dette trinnet hente inn den manglende kandidaten. Undersøk både kortlisten og den endelige rekkefølgen når et resultat virker feil. Når et langt dokument dekker mange temaer, deler du det i sammenhengende deler og beholder referansene til overordnet dokument, slik at en relevant del kan velges uten å miste kilden.

Kontekst- og forespørselsgrenser Produsentens nåværende veiledning angir et spørringsmaksimum på 8 000 tokener og et samlet maksimum på 32 000 tokener for spørringen pluss hvert enkelt dokument. Den tillater opptil 1000 kandidatdokumenter og et totalt forespørselsbudsjett på 600 000 tokener, beregnet som spørringstokener multiplisert med antall dokumenter, pluss alle dokumenttokener. En lang spørring bruker derfor plass i hvert par og bidrar gjentatte ganger til det samlede budsjettet. Tell den innsendte teksten med riktig modelltokenizer, fremfor å behandle tegn, ord og tokener som utskiftbare.

En spørring på 500 tokener med 100 dokumenter på 4 000 tokener hver utgjør for eksempel 450 000 inndatatokener etter denne formelen. Dette illustrerer budsjettering, ikke en anbefalt kortlistestørrelse eller et målt hastighetsresultat. Det dokumenterte avkortingsvalget er aktivert som standard; for stor tekst kan forkortes før skåring. Forbered viktige deler bevisst, slik at avkorting ikke fjerner akkurat tekstutdraget du trenger å finne samsvar med.

Les og bruk resultatet Resultatene sorteres fra høyeste relevansskår og nedover. Hvert resultat identifiserer dokumentets opprinnelige inndataposisjon, slik at applikasjonen kan knytte til sin egen tittel, oppføringsidentifikator og kilde. Innstillingen top_k styrer hvor mange rangerte kandidater som returneres; uten den returneres alle kandidater. Produsentens REST-grensesnitt kan også returnere dokumentteksten. Behold de opprinnelige identifikatorene sammen med de valgte resultatene når du viser en søkeside eller sender belegg inn i et trinn for svargenerering.

En relevansskår uttrykker hvor godt en kandidat samsvarer med spørringen; den fastslår ikke at kandidatens påstander er korrekte. Sammenlign de høyest rangerte elementene med brukerens faktiske spørsmål, inkludert det som skal utelates, og forskjeller i dokumentversjoner. Hvis hver kandidat er irrelevant, finnes det fortsatt et høyest rangert element. Avgjør hvordan applikasjonen håndterer dette tilfellet ved å bruke representative spørringer fra samlingen.

Oppgradering og valg av utgave Produsenten beskriver rerank-3-lite som en oppgradering av rerank-2.5-lite med uendret API-semantikk og skårer kalibrert til fordelingen hos den tilsvarende forgjengeren. Behold den eksisterende koblingen til oppføringer og innhentingstrinnet, og sammenlign deretter den resulterende rekkefølgen på meningsfulle spørringer før du stoler på en etablert skårgrense. Bruk Lite for en søkeopplevelse der responstid er viktig; bruk den kvalitetsorienterte rerank-3-utgaven som sammenligning når relevans for vanskelige kandidater har høyere prioritet.