VoyageAI by MongoDB: rerank-3

Voyage rerank-3 er en tekstreranker udviklet til at forbedre kvaliteten af hentet belæg. Med en forespørgsel og en liste over kandidatdokumenter undersøger den hvert par samlet og returnerer kandidaterne ordnet efter relevans. Embeddings og nøgleordssøgning kan først indsnævre en stor samling til en håndterbar kortliste; rerank-3 anvender derefter en mere detaljeret relevansvurdering på kortlisten. Dens output er scoret søgebelæg, som en applikation kan vise eller sende videre til et særskilt trin med svargenerering.

Kvalitetsfokuseret Rerank 3 Producenten positionerer rerank-3 som den nøjagtighedsfokuserede udgave og rerank-3-lite som udgaven til latensfølsom søgning. Tredje generation opdaterer grundarkitekturen og træningsblandingen med særlige forbedringer i hentning fra lange dokumenter og kildekode sammenlignet med de tilsvarende 2.5-forgængere. Producenten evaluerer den på tværs af teknisk dokumentation, kode, flersproget materiale og andre dokumentdomæner. Disse resultater understøtter dens rolle i informationshentning; vælg udgaven ud fra de spørgsmål og kandidatdokumenter, der er vigtige for din egen samling.

Lange dokumenter med tilstrækkelig kontekst En lang kandidat kan indeholde nyttig kontekst langt ud over sit indledende afsnit. Lever et sammenhængende afsnit eller dokument med titel og relevant omgivende materiale, så modellen kan vurdere, hvordan det faktiske spørgsmål relaterer sig til indholdet. Ved søgning i produktpolitikker skal du bevare overskrifter og undtagelser omkring det relevante tekststykke. Hvis flere hentede afsnit kommer fra samme kilde, skal du bevare deres dokument- og afsnits-id'er; applikationen kan derefter vise, hvor det valgte belæg stammer fra.

Kontekstvinduet deles af forespørgslen og hver kandidat. Producentens aktuelle vejledning angiver 32.000 tokens til dette par, inklusive en forespørgsel på højst 8.000 tokens. En forespørgsel på 3.000 tokens efterlader derfor højst 29.000 tokens til hvert dokument. Forbered inputtet, så dets væsentlige indhold kan være der, især når en lang indledning eller gentagen standardtekst ellers ville optage vinduet. Den dokumenterede trunkeringsindstilling er som standard aktiveret og kan afkorte for stor forespørgsels- eller dokumenttekst før scoring. Undersøg, hvad der bevares, når tekststykkets placering er vigtig.

Hentning af kode og teknisk materiale Til en kodeassistents hentetrin kan kandidater indeholde funktionsimplementeringer, API-dokumentation eller tekniske forklaringer som tekst. Medtag de symboler, signaturer og den kontekst, der er nødvendige for at skelne mellem lignende kandidater. En forespørgsel som “Find den funktion, der normaliserer stier og samtidig bevarer en afsluttende separator” giver en konkret adfærd at matche. Tilføj eventuelle relevante sprog-, platforms- eller versionsbegrænsninger. Efter rangering skal du undersøge den valgte kode og dens afhængigheder, før den bruges som kontekst; en relevansscore beviser ikke, at en implementering opfylder alle angivne krav.

Instruktioner definerer relevans Modellen bevarer evnen til instruktionsfølgende omrangering, som blev indført i Rerank 2.5. Tilføj en kort instruktion før eller efter forespørgslen, når brugerens hensigt skal præciseres. Ved søgning i researchdokumenter skal du forklare, om fokus er på titlen, en bestemt metode eller et anvendelsesdomæne. Ved et internt katalog skal du angive, om anmodningen vedrører installation, fejlfinding eller kompatibilitet. Hold instruktionen på linje med spørgsmålet; ekstra præferencer, der strider mod hovedanmodningen, kan ændre det, rangeringen forsøger at optimere.

Forbered kandidatdokumenter og budgetter Inputtet er en liste af tekststrenge. Udtræk anvendelig tekst fra kildedokumenter, bevar meningsfulde afsnitsgrænser, og behold en ordnet registreringskobling ved siden af listen. Producenten tillader op til 1.000 dokumenter i én anmodning. Den angiver også et samlet inputloft på 600.000 tokens: forespørgselstokens ganget med dokumentantallet plus summen af alle dokumenttokens. Det adskiller sig fra kontekstgrænsen pr. par. Ved at reducere redundant forespørgselstekst kan du bevare både kapaciteten for hvert par og det samlede anmodningsbudget.

Tæl tokens til den relevante model frem for at antage, at et ord- eller tegntal er et tokental. Ved store kandidater skal du vælge sammenhængende tekststykker eller opdele materialet efter nyttige overskrifter, mens oplysninger om hovedkilden bevares. Omrangering er mest nyttig, efter den første søgning allerede har fundet plausible kandidater: den kan ikke rangere en manglende kilde, der aldrig kom på listen.

Rangerede resultater og efterfølgende brug Resultatet indeholder relevansscorer og indeks, som henviser til de oprindelige inputdokumenter, sorteret i faldende relevansrækkefølge. Indstillingen top_k begrænser antallet af rangerede resultater, der returneres; ellers returneres alle inputkandidater. Producentens REST-grænseflade tillader også, at dokumentteksten medtages. Brug hvert oprindeligt indeks til at genskabe titel, kilde-id og de metadata, applikationen har brug for, og vis derefter de valgte elementer eller saml den relevante tekst i et svars belægskontekst.

Undersøg de øverste resultater mod spørgsmålet, og hold kildeidentiteten synlig. En høj relativ placering verificerer ikke et dokuments faktuelle nøjagtighed, og en kortliste, der kun indeholder dårlige kandidater, vil stadig have et første element. Adskil udvælgelse efter relevans fra afgørelsen af, om det valgte belæg er tilstrækkeligt til at besvare brugeren.

Migrering mellem udgaver Producenten beskriver rerank-3 som en direkte afløser for rerank-2.5 med samme API-semantik og scorer kalibreret til den tilsvarende forgængers fordeling. Denne kompatibilitet understøtter bevarelse af et eksisterende hentetrin og en eksisterende registreringskobling. Sammenlign meningsfulde resultatrækkefølger og eventuelle scoregrænser på det aktuelle korpus, før du stoler på migreringen. Hold rerank-3 og rerank-3-lite som særskilte valg: fælles grænser og instruktionsefterlevelse gør ikke deres kvalitets- og latensprioriteter identiske.