VoyageAI by MongoDB: rerank-3-lite

Voyage rerank-3-lite er den latensfokuserede udgave af Voyages Rerank 3-serie. Den modtager en tekstforespørgsel og kandidatdokumenter, vurderer hvert forespørgsels-dokumentpar samlet og returnerer relevansscorer i rangeret rækkefølge. Den betjener søgningens andet trin: en embedding- eller nøgleordssøger finder kandidaterne, hvorefter Lite finjusterer deres rækkefølge. Resultatet er en rangering til brug i søgning eller en arbejdsgang med retrieval-augmented generation.

Hvad ændres i Rerank 3 Lite Producenten fremhæver stærkere informationshentning fra lange dokumenter og kode sammenlignet med rerank-2.5-lite. Begge Rerank 3-udgaver bevarer instruktionsefterlevelse og samme kontekstklasse på 32K, mens Lite er udviklet til latensfølsomme applikationer. Det gør den til en praktisk kandidat til interaktiv søgning i vidensbaser, hentning af supportdokumenter og kodeopslag, når brugerne hurtigt har brug for relevante resultater. Vælg den ud fra den faktiske samlings kvalitets- og svartidskrav frem for at antage, at en mindre udgave betyder et mindre kontekstvindue.

Styr relevansen med forespørgslen Instruktioner i naturligt sprog kan ledsage forespørgslen for at forklare, hvad der tæller som relevant. Hold spørgsmålet og relevanspræferencen korte og konsekvente. Til en softwaresupportsøgning kan du bruge “Find fremgangsmåden til at nulstille en enhed; prioritér instruktioner til den angivne hardwarerevision.” Ved et tvetydigt produktnavn skal du medtage produktkategorien, så uvedkommende betydninger ikke dominerer. En præference i forespørgslen styrer den semantiske scoring; brug eksplicitte samlingsmetadata til at vælge det korrekte produkt, den korrekte dokumentversion eller det korrekte adgangsomfang, før kandidatlisten opbygges.

Forbered en kortliste med tekstkandidater Inputdokumenterne er strenge. Udtræk læsbar tekst fra kildematerialet, og bevar nyttige titler, overskrifter, id'er og omgivende kontekst. Bevar en stabil kobling fra hver inputposition til den oprindelige registrering. Ved en fejlfindingsartikel skal du medtage symptomet og den relevante fremgangsmåde, ikke kun en løsrevet sætning. Ved kildekodesøgning skal du medtage funktionen og nærliggende oplysninger, der er nødvendige for at skelne den fra funktioner med lignende navne. Fjern gentagen navigation eller standardsidertekst, når den fortrænger det nyttige tekststykke.

Rerankeren kan kun omordne de dokumenter, den modtager. Hvis den første søgning aldrig henter den relevante artikel, kan dette trin ikke genfinde den manglende kandidat. Undersøg både kortlisten og den endelige rækkefølge, når et resultat virker forkert. Hvis et langt dokument dækker mange emner, skal du adskille sammenhængende afsnit og bevare deres referencer til hoveddokumentet, så et relevant afsnit kan vælges uden at miste kilden.

Kontekst og anmodningsgrænser Producentens aktuelle vejledning angiver et forespørgselsmaksimum på 8.000 tokens og et samlet maksimum på 32.000 tokens for forespørgslen plus hvert enkelt dokument. Den tillader op til 1.000 kandidatdokumenter og et samlet anmodningsbudget på 600.000 tokens, beregnet som forespørgselstokens ganget med dokumentantal plus alle dokumenttokens. En lang forespørgsel optager derfor plads i hvert par og bidrager gentagne gange til det samlede budget. Tæl den indsendte tekst med den passende modeltokenizer frem for at behandle tegn, ord og tokens som udskiftelige.

En forespørgsel på 500 tokens med 100 dokumenter på hver 4.000 tokens svarer eksempelvis til 450.000 inputtokens efter denne formel. Det illustrerer budgettering, ikke en anbefalet størrelse på kortlisten eller et målt hastighedsresultat. Den dokumenterede trunkeringsindstilling er aktiveret som standard; for stor tekst kan afkortes før scoring. Forbered vigtige afsnit bevidst, så trunkeringen ikke fjerner netop det tekststykke, du har brug for at matche.

Læs og brug resultatet Resultaterne sorteres fra højeste relevansscore og nedad. Hvert resultat identificerer dokumentets oprindelige inputposition, så applikationen kan tilføje sin egen titel, sit eget registrerings-id og sin egen kilde. Indstillingen top_k styrer, hvor mange rangerede kandidater der returneres; uden den returneres alle kandidater. Producentens REST-grænseflade kan også returnere dokumentteksten. Bevar de oprindelige id'er sammen med de valgte resultater, når du viser en søgeside eller sender belæg videre til et trin med svargenerering.

En relevansscore udtrykker, hvor godt en kandidat matcher forespørgslen; den fastslår ikke, at kandidatens udsagn er korrekte. Sammenlign de højest rangerede elementer med brugerens faktiske spørgsmål, herunder udelukkelser og forskelle i dokumentversioner. Hvis alle kandidater er irrelevante, findes der stadig et højest rangeret element. Afgør, hvordan applikationen håndterer dette tilfælde, ved hjælp af repræsentative forespørgsler fra samlingen.

Opgradering og valg af udgave Producenten beskriver rerank-3-lite som en opgradering af rerank-2.5-lite med uændret API-semantik og scorer kalibreret til den tilsvarende forgængers fordeling. Bevar den eksisterende registreringskobling og det eksisterende hentetrin, og sammenlign derefter den resulterende rækkefølge på meningsfulde forespørgsler, før du stoler på en etableret scoregrænse. Brug Lite til en søgeoplevelse, hvor svartid er vigtig; brug den kvalitetsfokuserede rerank-3-udgave som sammenligning, når relevans blandt vanskelige kandidater har højere prioritet.