VoyageAI by MongoDB: rerank-3

Voyage rerank-3 er en omrangeringsmodell for tekst som er utviklet for å forbedre kvaliteten på innhentet belegg. Gitt en spørring og en liste over kandidatdokumenter undersøker den hvert par samlet og returnerer kandidatene ordnet etter relevans. Embeddings og nøkkelordsøk kan først avgrense en stor samling til en håndterbar kortliste; rerank-3 anvender deretter en mer detaljert relevansvurdering på denne kortlisten. Utdataene er skåret søkebelegg som en applikasjon kan vise eller sende inn i et separat trinn for svargenerering.

Kvalitetsorientert Rerank 3 Produsenten posisjonerer rerank-3 som den nøyaktighetsorienterte utgaven og rerank-3-lite som utgaven for søk som er følsomme for latenstid. Tredje generasjon oppdaterer grunnarkitekturen og treningsblandingen, med særlig forbedring i innhenting fra lange dokumenter og kildekode sammenlignet med de tilsvarende 2.5-forgjengerne. Produsenten evaluerer modellen på tvers av teknisk dokumentasjon, kode, flerspråklig materiale og andre dokumentdomener. Disse resultatene støtter innhentingsrollen; velg utgave ut fra spørsmålene og kandidatdokumentene som er viktige for din egen samling.

Lange dokumenter med nok kontekst En lang kandidat kan inneholde nyttig kontekst langt utover åpningsavsnittet. Gi en sammenhengende del eller et dokument med tittel og relevant omkringliggende materiale, slik at modellen kan vurdere hvordan det faktiske spørsmålet er knyttet til innholdet. For søk i produktretningslinjer bevarer du overskrifter og unntak rundt tekstutdraget av interesse. Hvis flere innhentede deler kommer fra samme kilde, beholder du dokument- og delidentifikatorene; applikasjonen kan da vise hvor det valgte belegget kom fra.

Kontekstvinduet deles av spørringen og hver kandidat. Produsentens nåværende veiledning angir 32 000 tokener for dette paret, inkludert en spørring på maksimalt 8 000 tokener. En spørring på 3 000 tokener gir derfor plass til maksimalt 29 000 tokener for hvert dokument. Forbered inndataene slik at det vesentlige innholdet får plass, særlig når en lang innledning eller gjentatt standardtekst ellers ville brukt opp vinduet. Det dokumenterte avkortingsvalget er aktivert som standard og kan forkorte for stor spørrings- eller dokumenttekst før skåring. Undersøk hva som beholdes når plasseringen av tekstutdraget er viktig.

Innhenting av kode og teknisk materiale For innhentingstrinnet i en kodeassistent kan kandidatene inneholde funksjonsimplementasjoner, API-dokumentasjon eller tekniske forklaringer som tekst. Ta med symbolene, signaturene og konteksten som trengs for å skille lignende kandidater. En spørring som «Finn funksjonen som normaliserer stier og samtidig bevarer et avsluttende skilletegn» gir en konkret oppførsel å finne samsvar med. Legg til eventuelle relevante språk-, plattform- eller versjonsbegrensninger. Etter rangering undersøker du den valgte koden og avhengighetene dens før du bruker den som kontekst; en relevansskår beviser ikke at en implementasjon oppfyller alle angitte krav.

Instruksjoner definerer relevans Modellen beholder den instruksjonsfølgende omrangeringsegenskapen som ble innført i Rerank 2.5. Legg en kort instruksjon før eller etter spørringen når brukerens intensjon trenger presisering. For søk i forskningsdokumenter forklarer du om fokuset er tittelen, en bestemt metode eller et bruksdomene. For en intern katalog angir du om forespørselen gjelder installasjon, feilsøking eller kompatibilitet. Hold denne instruksjonen i samsvar med spørsmålet; ekstra preferanser som strider mot hovedforespørselen, kan endre hva rangeringen prøver å optimalisere.

Forbered kandidatdokumenter og budsjetter Inndataene er en liste med tekststrenger. Hent ut brukbar tekst fra kildedokumenter, bevar meningsfulle delgrenser og hold en ordnet kobling til oppføringer ved siden av listen. Produsenten tillater opptil 1000 dokumenter i én forespørsel. Den angir også en samlet inndatagrense på 600 000 tokener: spørringstokener multiplisert med antall dokumenter, pluss summen av alle dokumenttokener. Dette skiller seg fra kontekstgrensen per par. Å redusere overflødig spørringstekst kan bevare både parkapasitet og det samlede forespørselsbudsjettet.

Tell tokener for den relevante modellen, fremfor å anta at et ord- eller tegnantall er et tokenantall. For store kandidater velger du sammenhengende tekstutdrag eller deler materialet etter nyttige overskrifter, samtidig som informasjon om overordnet kilde bevares. Omrangering er mest nyttig etter at det første søket allerede har funnet plausible kandidater: den kan ikke rangere en manglende kilde som aldri kom inn på listen.

Rangerte resultater og videre bruk Resultatet inneholder relevansskårer og indekser som viser til de opprinnelige inndatadokumentene, sortert i synkende relevansrekkefølge. Valget top_k begrenser antall rangerte resultater som returneres; ellers returneres alle inndatakandidater. Produsentens REST-grensesnitt tillater også at dokumentteksten tas med. Bruk hver opprinnelige indeks til å hente tittel, kildeidentifikator og eventuelle metadata applikasjonen trenger, og presenter deretter de valgte elementene eller legg den relevante teksten inn i belegget for et svar.

Undersøk toppresultatene opp mot spørsmålet, og hold kildeidentiteten synlig. En høy relativ rangering bekrefter ikke et dokuments faktiske korrekthet, og en kortliste med bare dårlige kandidater vil fortsatt ha et første element. Skill relevansutvelgelse fra avgjørelsen om det valgte belegget er tilstrekkelig til å besvare brukeren.

Bytte av utgave Produsenten beskriver rerank-3 som en direkte erstatning for rerank-2.5, med samme API-semantikk og skårer kalibrert til fordelingen hos den tilsvarende forgjengeren. Denne kompatibiliteten støtter å beholde et eksisterende innhentingstrinn og koblingen til oppføringer. Sammenlign meningsfulle resultatrekkefølger og eventuelle skårgrenser på det aktuelle korpuset før du stoler på byttet. Hold rerank-3 og rerank-3-lite som separate valg: felles grenser og instruksjonsfølging gjør ikke prioriteringene deres for kvalitet og latenstid identiske.