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.
", "aboutText": "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.\n\nHvad ændres i Rerank 3 Lite\nProducenten 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.\n\nStyr relevansen med forespørgslen\nInstruktioner 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.\n\nForbered en kortliste med tekstkandidater\nInputdokumenterne 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.\n\nRerankeren 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.\n\nKontekst og anmodningsgrænser\nProducentens 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.\n\nEn 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.\n\nLæs og brug resultatet\nResultaterne 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.\n\nEn 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.\n\nOpgradering og valg af udgave\nProducenten 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.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "b14b34805729f20310a3f3f7009c941af03027b3cfbc4c09b0ca5bd132b5207b", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "da", "methods": [ { "html": "voyageai/rerank-3-liteVoyage rerank-3-lite scorer og omordner kandidattekstdokumenter til en forespørgsel med fokus på hurtig søgning. Den understøtter relevansinstruktioner og et forespørgsels-dokumentvindue på 32.000 tokens, hvilket gør den nyttig efter vektor- eller nøgleordssøgning i søge- og RAG-arbejdsgange.
Denne beskrivelse dækker modellens funktioner. Tilgængelige input, output og indstillinger i Ailoot står nedenfor for den valgte metode.
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.
POST /v1/reranktextrerank| Felt | Type | Krav | Værdier og grænser | Standard |
|---|---|---|---|---|
Feltdocuments | Typearray | KravPåkrævet | Værdier og grænser | Standard— |
Feltmodel | Typestring | KravPåkrævet | Værdier og grænser voyageai/rerank-3-lite | Standard— |
Feltprovider | Typeschema | KravValgfrit | Værdier og grænser | Standard— |
Feltquery | Typestring | KravPåkrævet | Værdier og grænser | Standard— |
Feltsession_id | Typestring | KravValgfrit | Værdier og grænser | Standard— |
Felttop_n | Typeinteger | KravValgfrit | Værdier og grænser Minimum: 1 | Standard— |
Felttrace | Typeschema | KravValgfrit | Værdier og grænser | Standard— |
Feltuser | Typestring | KravValgfrit | Værdier og grænser | Standard— |
Feltdocuments[].text | Typestring | KravValgfrit | Værdier og grænser | Standard— |
Feltdocuments[].image | Typestring | KravValgfrit | Værdier og grænser | Standard— |
text_rerank · Påkrævet: query, documents array with minItems1
| Parameter | Kontrakt |
|---|---|
Parametercontent_type | Kontraktapplication/json |
Parameterrequired | Kontraktmodel, query, documents |
Parametermaterial_types | Kontrakttext |
Parameteroptional_controls | Kontraktprovider, session_id, top_n, trace, user |
Parametermultimodal_input_binding | Kontraktnull |
Livscyklus: synchronous
Send det præcise model-ID, og behold hele det native svar.
Tarifoplysninger tilføjer ikke anmodningsmuligheder. Understøttede parametre står ved den valgte metode.
Knyt hver omkostning til de viste betingelser. Brug én takst for hver gruppe af alternative konfigurationer.
| Konfiguration | Takstplan | Afregningsenhed | Beløb |
|---|---|---|---|
| KonfigurationGrundpriser for tokens | TakstplanGrundtakst | Afregningsenhed— | Beløb Input · Inputtokens — / 1K tokens Output · Outputtokens — / 1K tokens Input · Cachelæsning — / 1K tokens Input · Cacheskrivning — / 1K tokens Input · Cacheskrivning, 1 time — / 1K tokens |
| KonfigurationUltra | Takstplan— | Afregningsenhed/ 1K tokens | Beløb Input $0.00004 / 1K tokens |
Ailoot reserverer et estimeret beløb før en anmodning. Efter resultatet afregnes det endelige beløb ud fra det målte forbrug. Ved streaming bruges den endelige forbrugsregistrering til afregningen. Sådan fungerer reservation og afregning →
{\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
Gem hvert fuldstændigt returneret svar, hver fil og hver indholdsdel.
Hvert faktisk resultatindeks, hver relevance_score med en endelig talværdi og hvert oprindeligt dokumentobjekt bevares. Indekserne knytter resultaterne til det oprindelige dokumentarray. Hele det oprindelige JSON-svar gemmes og returneres først efter afregning.
Behold den oprindelige operation og hele eller det delvise svar; gentag ikke 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 | Betingelse | Næste trin |
|---|---|---|
Svar400 · invalid_request_error | BetingelseUgyldigt påkrævet felt, ugyldig repræsentation eller ugyldig værdi | Næste trinRet det angivne forespørgselsfelt. |
Ailoot Ultra voyageai/rerank-3-lite
Brug metodestierne vist ovenfor.