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.
", "aboutText": "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.\n\nHva som endres i Rerank 3 Lite\nProdusenten 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.\n\nStyr relevansen med spørringen\nInstruksjoner 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.\n\nForbered en kortliste med tekstkandidater\nInndatadokumentene 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.\n\nOmrangeringsmodellen 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.\n\nKontekst- og forespørselsgrenser\nProdusentens 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.\n\nEn 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.\n\nLes og bruk resultatet\nResultatene 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.\n\nEn 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.\n\nOppgradering og valg av utgave\nProdusenten 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.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "7efa04ed190cc50e8f9dbb19207d6a6117d7be2d8a813b565053de937def39dc", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "nb", "methods": [ { "html": "voyageai/rerank-3-liteVoyage rerank-3-lite skårer og omordner kandidattekstdokumenter for en spørring, med vekt på rask respons i søk. Den støtter relevansinstruksjoner og et spørring–dokument-vindu på 32 000 tokener, noe som gjør den nyttig etter vektor- eller nøkkelordinnhenting i søke- og RAG-arbeidsflyter.
Denne beskrivelsen dekker modellens funksjoner. Tilgjengelige inndata, utdata og alternativer i Ailoot er oppført nedenfor for den valgte metoden.
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.
POST /v1/reranktextrerank| Felt | Type | Krav | Verdier & grenser | Standard |
|---|---|---|---|---|
Feltdocuments | Typearray | KravPåkrevd | Verdier & grenser | Standard— |
Feltmodel | Typestring | KravPåkrevd | Verdier & grenser voyageai/rerank-3-lite | Standard— |
Feltprovider | Typeschema | KravValgfritt | Verdier & grenser | Standard— |
Feltquery | Typestring | KravPåkrevd | Verdier & grenser | Standard— |
Feltsession_id | Typestring | KravValgfritt | Verdier & grenser | Standard— |
Felttop_n | Typeinteger | KravValgfritt | Verdier & grenser Minimum: 1 | Standard— |
Felttrace | Typeschema | KravValgfritt | Verdier & grenser | Standard— |
Feltuser | Typestring | KravValgfritt | Verdier & grenser | Standard— |
Feltdocuments[].text | Typestring | KravValgfritt | Verdier & grenser | Standard— |
Feltdocuments[].image | Typestring | KravValgfritt | Verdier & grenser | Standard— |
text_rerank · Påkrevd: query, documents array with minItems1
| Parameter | Avtale |
|---|---|
Parametercontent_type | Avtaleapplication/json |
Parameterrequired | Avtalemodel, query, documents |
Parametermaterial_types | Avtaletext |
Parameteroptional_controls | Avtaleprovider, session_id, top_n, trace, user |
Parametermultimodal_input_binding | Avtalenull |
Livssyklus: synchronous
Send den eksakte modell-ID-en og behold hele svaret i det opprinnelige formatet.
Tariffopplysninger legger ikke til forespørselsvalg. Støttede parametere står ved den valgte metoden.
Knytt hver kostnad til de viste vilkårene. Bruk én sats for hvert sett med alternative konfigurasjoner.
| Konfigurasjon | Prisplan | Faktureringsenhet | Kostnad |
|---|---|---|---|
| KonfigurasjonGrunnpriser for tokener | PrisplanGrunnsats | Faktureringsenhet— | Kostnad Inndata · Inngående tokener — / 1K tokener Utdata · Utgående tokener — / 1K tokener Inndata · Lesing fra hurtigbuffer — / 1K tokener Inndata · Skriving til hurtigbuffer — / 1K tokener Inndata · Skriving til hurtigbuffer, 1 time — / 1K tokener |
| KonfigurasjonUltra | Prisplan— | Faktureringsenhet/ 1K tokener | Kostnad Inndata $0.00004 / 1K tokener |
Ailoot reserverer et estimert beløp før en forespørsel. Etter resultatet gjøres det endelige beløpet opp basert på målt forbruk. Oppgjør for strømming bruker den endelige forbruksposten. Slik fungerer reservasjon og oppgjør →
{\n "documents": [\n "Paris is the capital of France.",\n "Berlin is the capital of Germany."\n ],\n "model": "voyageai/rerank-3-lite",\n "query": "What is the capital of France?",\n "top_n": 3\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_REQUEST_FILE:?Set your actual JSON request file}"\nexport AILOOT_REQUEST_FILE\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads(Path(os.environ['AILOOT_REQUEST_FILE']).read_text(encoding='utf-8'))\nif not isinstance(p,dict): raise SystemExit('Request must be a JSON object')\np['model']='voyageai/rerank-3-lite'\nPath('request.json').write_text(json.dumps(p,ensure_ascii=False),encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/rerank \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path('result.json').read_text()),ensure_ascii=False,indent=2))\nPY_RESULT\njson
Behold alle fullstendige returnerte svar, filer og innholdsdeler.
Alle faktiske resultatindekser, alle endelige relevance_score-verdier og de opprinnelige dokumentobjektene bevares. Indeksene knytter resultatene til den opprinnelige dokumentmatrisen. Hele det opprinnelige JSON-svaret lagres og returneres først etter oppgjør.
Behold den opprinnelige operasjonen og hele eller deler av svaret; ikke gjenta POST.
| Felt | Type |
|---|---|
Feltmodel | Typestring |
Feltid | Typestring |
Feltprovider | Typestring |
Feltresults[].index | Typeinteger |
Feltresults[].relevance_score | Typenumber |
Feltresults[].document.text | Typestring |
Feltresults[].document.image | Typestring |
Feltusage.search_units | Typeinteger |
Feltusage.total_tokens | Typeinteger |
Feltusage.cost | Typenumber |
| Svar | Vilkår | Neste trinn |
|---|---|---|
Svar400 · invalid_request_error | VilkårUgyldig påkrevd felt, representasjon eller verdi | Neste trinnKorriger det angitte forespørselsfeltet. |
Ailoot Ultra voyageai/rerank-3-lite
Bruk metodestiene som vises ovenfor.