Voyage rerank-3-lite is de op lage latentie gerichte editie van de Rerank 3-serie van Voyage. Het neemt een tekstuele zoekvraag en kandidaatdocumenten aan, beoordeelt elk zoekvraag-documentpaar gezamenlijk en geeft relevantiescores in gerangschikte volgorde terug. Het verzorgt de tweede zoekfase: een embedding- of trefwoordzoekfunctie vindt de kandidaten en daarna verfijnt Lite hun volgorde. Het resultaat is een rangschikking voor gebruik in zoeken of een retrieval-augmented generation-workflow.
Wat verandert in Rerank 3 Lite De producent benadrukt sterkere retrieval voor lange documenten en code vergeleken met rerank-2.5-lite. Beide Rerank 3-edities behouden instructievolging en dezelfde contextklasse van 32K, terwijl Lite is ontworpen voor toepassingen die gevoelig zijn voor latentie. Dit maakt het een praktische kandidaat voor interactieve zoekfuncties in kennisbanken, retrieval van ondersteuningsdocumenten en het opzoeken van code wanneer gebruikers snel relevante resultaten nodig hebben. Kies op basis van de kwaliteits- en responstijdeisen van de daadwerkelijke collectie, in plaats van aan te nemen dat een kleinere editie een kleiner contextvenster betekent.
Stuur relevantie met de zoekvraag Instructies in natuurlijke taal kunnen de zoekvraag aanvullen om uit te leggen wat als relevant geldt. Houd de vraag en de relevantievoorkeur beknopt en consistent. Gebruik voor een zoekopdracht naar softwareondersteuning: “Vind de procedure om een apparaat te resetten; geef voorrang aan instructies voor de vermelde hardwarerevisie.” Voeg bij een dubbelzinnige productnaam de productcategorie toe, zodat niet-gerelateerde betekenissen niet overheersen. Een voorkeur in de zoekvraag stuurt de semantische scoring; gebruik expliciete collectiemetadata om het juiste product, de documentversie of de toegangsafbakening te selecteren voordat je de kandidatenlijst opbouwt.
Bereid een shortlist van tekstkandidaten voor De invoerdocumenten zijn strings. Extraheer leesbare tekst uit bronmateriaal en behoud bruikbare titels, koppen, identificatoren en omringende context. Houd een stabiele koppeling van elke invoerpositie naar de oorspronkelijke registratie bij. Neem voor een probleemoplossingsartikel het symptoom en de relevante procedure op, niet alleen een losse zin. Neem voor broncodezoeken de functie en nabijgelegen informatie op die nodig is om haar van gelijknamige functies te onderscheiden. Verwijder herhaalde navigatie of standaardtekst wanneer die de bruikbare passage verdringt.
De reranker kan alleen de documenten herschikken die hij ontvangt. Als de eerste zoekopdracht het relevante artikel nooit ophaalt, kan deze fase die ontbrekende kandidaat niet terughalen. Controleer zowel de shortlist als de uiteindelijke volgorde wanneer een resultaat onjuist lijkt. Splits een lang document met veel onderwerpen in samenhangende secties en behoud de verwijzingen naar het bovenliggende document, zodat een relevante sectie kan worden geselecteerd zonder de bron te verliezen.
Context en verzoeklimieten De huidige gids van de maker specificeert een zoekvraagmaximum van 8.000 tokens en een gecombineerd maximum van 32.000 tokens voor de zoekvraag plus elk afzonderlijk document. Er zijn maximaal 1.000 kandidaatdocumenten en een totaal verzoekbudget van 600.000 tokens toegestaan, berekend als zoekvraagtokens vermenigvuldigd met het aantal documenten, plus alle documenttokens. Een lange zoekvraag verbruikt dus ruimte in elk paar en telt herhaaldelijk mee in het totale budget. Tel de ingediende tekst met de juiste modeltokenizer in plaats van tekens, woorden en tokens als uitwisselbaar te beschouwen.
Een zoekvraag van 500 tokens met 100 documenten van elk 4.000 tokens komt volgens die formule bijvoorbeeld op 450.000 invoertokens. Dit illustreert budgettering, geen aanbevolen shortlistgrootte of gemeten snelheidsresultaat. De gedocumenteerde afkapoptie staat standaard aan; te grote tekst kan vóór de scoring worden ingekort. Bereid belangrijke secties bewust voor, zodat afkappen niet precies de passage verwijdert die je wilt laten overeenkomen.
Lees en gebruik het resultaat Resultaten worden gesorteerd van de hoogste relevantiescore naar beneden. Elk resultaat identificeert de oorspronkelijke invoerpositie van het document, zodat de toepassing haar eigen titel, registratie-ID en bron kan toevoegen. De instelling top_k bepaalt hoeveel gerangschikte kandidaten worden teruggegeven; zonder die instelling worden alle kandidaten teruggegeven. De REST-interface van de maker kan ook de documenttekst teruggeven. Bewaar de oorspronkelijke identificatoren bij de geselecteerde resultaten wanneer je een zoekpagina toont of bewijs doorgeeft aan een stap voor antwoordgeneratie.
Een relevantiescore drukt uit hoe goed een kandidaat bij de zoekvraag past; zij stelt niet vast dat de beweringen van die kandidaat juist zijn. Vergelijk de hoogst gerangschikte items met de daadwerkelijke vraag van de gebruiker, inclusief uitsluitingen en verschillen tussen documentversies. Als elke kandidaat irrelevant is, bestaat er nog steeds een hoogst gerangschikt item. Bepaal met representatieve zoekvragen uit de collectie hoe de toepassing dat geval afhandelt.
Upgraden en de editie kiezen De maker beschrijft rerank-3-lite als een upgrade van rerank-2.5-lite met ongewijzigde API-semantiek en scores die zijn gekalibreerd op de verdeling van de overeenkomstige voorganger. Behoud de bestaande registratiekoppeling en retrievalfase en vergelijk vervolgens de resulterende volgorde voor betekenisvolle zoekvragen voordat je vertrouwt op een bestaande scoredrempel. Gebruik Lite voor een zoekervaring waarin responstijd belangrijk is; gebruik de op kwaliteit gerichte rerank-3-editie ter vergelijking wanneer relevantie bij lastige kandidaten de grotere prioriteit heeft.
", "aboutText": "Voyage rerank-3-lite is de op lage latentie gerichte editie van de Rerank 3-serie van Voyage. Het neemt een tekstuele zoekvraag en kandidaatdocumenten aan, beoordeelt elk zoekvraag-documentpaar gezamenlijk en geeft relevantiescores in gerangschikte volgorde terug. Het verzorgt de tweede zoekfase: een embedding- of trefwoordzoekfunctie vindt de kandidaten en daarna verfijnt Lite hun volgorde. Het resultaat is een rangschikking voor gebruik in zoeken of een retrieval-augmented generation-workflow.\n\nWat verandert in Rerank 3 Lite\nDe producent benadrukt sterkere retrieval voor lange documenten en code vergeleken met rerank-2.5-lite. Beide Rerank 3-edities behouden instructievolging en dezelfde contextklasse van 32K, terwijl Lite is ontworpen voor toepassingen die gevoelig zijn voor latentie. Dit maakt het een praktische kandidaat voor interactieve zoekfuncties in kennisbanken, retrieval van ondersteuningsdocumenten en het opzoeken van code wanneer gebruikers snel relevante resultaten nodig hebben. Kies op basis van de kwaliteits- en responstijdeisen van de daadwerkelijke collectie, in plaats van aan te nemen dat een kleinere editie een kleiner contextvenster betekent.\n\nStuur relevantie met de zoekvraag\nInstructies in natuurlijke taal kunnen de zoekvraag aanvullen om uit te leggen wat als relevant geldt. Houd de vraag en de relevantievoorkeur beknopt en consistent. Gebruik voor een zoekopdracht naar softwareondersteuning: “Vind de procedure om een apparaat te resetten; geef voorrang aan instructies voor de vermelde hardwarerevisie.” Voeg bij een dubbelzinnige productnaam de productcategorie toe, zodat niet-gerelateerde betekenissen niet overheersen. Een voorkeur in de zoekvraag stuurt de semantische scoring; gebruik expliciete collectiemetadata om het juiste product, de documentversie of de toegangsafbakening te selecteren voordat je de kandidatenlijst opbouwt.\n\nBereid een shortlist van tekstkandidaten voor\nDe invoerdocumenten zijn strings. Extraheer leesbare tekst uit bronmateriaal en behoud bruikbare titels, koppen, identificatoren en omringende context. Houd een stabiele koppeling van elke invoerpositie naar de oorspronkelijke registratie bij. Neem voor een probleemoplossingsartikel het symptoom en de relevante procedure op, niet alleen een losse zin. Neem voor broncodezoeken de functie en nabijgelegen informatie op die nodig is om haar van gelijknamige functies te onderscheiden. Verwijder herhaalde navigatie of standaardtekst wanneer die de bruikbare passage verdringt.\n\nDe reranker kan alleen de documenten herschikken die hij ontvangt. Als de eerste zoekopdracht het relevante artikel nooit ophaalt, kan deze fase die ontbrekende kandidaat niet terughalen. Controleer zowel de shortlist als de uiteindelijke volgorde wanneer een resultaat onjuist lijkt. Splits een lang document met veel onderwerpen in samenhangende secties en behoud de verwijzingen naar het bovenliggende document, zodat een relevante sectie kan worden geselecteerd zonder de bron te verliezen.\n\nContext en verzoeklimieten\nDe huidige gids van de maker specificeert een zoekvraagmaximum van 8.000 tokens en een gecombineerd maximum van 32.000 tokens voor de zoekvraag plus elk afzonderlijk document. Er zijn maximaal 1.000 kandidaatdocumenten en een totaal verzoekbudget van 600.000 tokens toegestaan, berekend als zoekvraagtokens vermenigvuldigd met het aantal documenten, plus alle documenttokens. Een lange zoekvraag verbruikt dus ruimte in elk paar en telt herhaaldelijk mee in het totale budget. Tel de ingediende tekst met de juiste modeltokenizer in plaats van tekens, woorden en tokens als uitwisselbaar te beschouwen.\n\nEen zoekvraag van 500 tokens met 100 documenten van elk 4.000 tokens komt volgens die formule bijvoorbeeld op 450.000 invoertokens. Dit illustreert budgettering, geen aanbevolen shortlistgrootte of gemeten snelheidsresultaat. De gedocumenteerde afkapoptie staat standaard aan; te grote tekst kan vóór de scoring worden ingekort. Bereid belangrijke secties bewust voor, zodat afkappen niet precies de passage verwijdert die je wilt laten overeenkomen.\n\nLees en gebruik het resultaat\nResultaten worden gesorteerd van de hoogste relevantiescore naar beneden. Elk resultaat identificeert de oorspronkelijke invoerpositie van het document, zodat de toepassing haar eigen titel, registratie-ID en bron kan toevoegen. De instelling top_k bepaalt hoeveel gerangschikte kandidaten worden teruggegeven; zonder die instelling worden alle kandidaten teruggegeven. De REST-interface van de maker kan ook de documenttekst teruggeven. Bewaar de oorspronkelijke identificatoren bij de geselecteerde resultaten wanneer je een zoekpagina toont of bewijs doorgeeft aan een stap voor antwoordgeneratie.\n\nEen relevantiescore drukt uit hoe goed een kandidaat bij de zoekvraag past; zij stelt niet vast dat de beweringen van die kandidaat juist zijn. Vergelijk de hoogst gerangschikte items met de daadwerkelijke vraag van de gebruiker, inclusief uitsluitingen en verschillen tussen documentversies. Als elke kandidaat irrelevant is, bestaat er nog steeds een hoogst gerangschikt item. Bepaal met representatieve zoekvragen uit de collectie hoe de toepassing dat geval afhandelt.\n\nUpgraden en de editie kiezen\nDe maker beschrijft rerank-3-lite als een upgrade van rerank-2.5-lite met ongewijzigde API-semantiek en scores die zijn gekalibreerd op de verdeling van de overeenkomstige voorganger. Behoud de bestaande registratiekoppeling en retrievalfase en vergelijk vervolgens de resulterende volgorde voor betekenisvolle zoekvragen voordat je vertrouwt op een bestaande scoredrempel. Gebruik Lite voor een zoekervaring waarin responstijd belangrijk is; gebruik de op kwaliteit gerichte rerank-3-editie ter vergelijking wanneer relevantie bij lastige kandidaten de grotere prioriteit heeft.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "6fef474ea72655638215f9ee0b530c55552729404b1cc99ec0e173b6d0708539", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "nl", "methods": [ { "html": "voyageai/rerank-3-liteVoyage rerank-3-lite scoort en herschikt kandidaattekstdocumenten voor een zoekvraag, met de nadruk op snel reagerende zoekfuncties. Het ondersteunt relevantie-instructies en een zoekvraag-documentvenster van 32.000 tokens, waardoor het bruikbaar is na vector- of trefwoordretrieval in zoek- en RAG-workflows.
Deze beschrijving gaat over de mogelijkheden van het model. De via Ailoot beschikbare invoer, uitvoer en opties staan hieronder voor de geselecteerde methode.
Voyage rerank-3-lite is de op lage latentie gerichte editie van de Rerank 3-serie van Voyage. Het neemt een tekstuele zoekvraag en kandidaatdocumenten aan, beoordeelt elk zoekvraag-documentpaar gezamenlijk en geeft relevantiescores in gerangschikte volgorde terug. Het verzorgt de tweede zoekfase: een embedding- of trefwoordzoekfunctie vindt de kandidaten en daarna verfijnt Lite hun volgorde. Het resultaat is een rangschikking voor gebruik in zoeken of een retrieval-augmented generation-workflow.
Wat verandert in Rerank 3 Lite De producent benadrukt sterkere retrieval voor lange documenten en code vergeleken met rerank-2.5-lite. Beide Rerank 3-edities behouden instructievolging en dezelfde contextklasse van 32K, terwijl Lite is ontworpen voor toepassingen die gevoelig zijn voor latentie. Dit maakt het een praktische kandidaat voor interactieve zoekfuncties in kennisbanken, retrieval van ondersteuningsdocumenten en het opzoeken van code wanneer gebruikers snel relevante resultaten nodig hebben. Kies op basis van de kwaliteits- en responstijdeisen van de daadwerkelijke collectie, in plaats van aan te nemen dat een kleinere editie een kleiner contextvenster betekent.
Stuur relevantie met de zoekvraag Instructies in natuurlijke taal kunnen de zoekvraag aanvullen om uit te leggen wat als relevant geldt. Houd de vraag en de relevantievoorkeur beknopt en consistent. Gebruik voor een zoekopdracht naar softwareondersteuning: “Vind de procedure om een apparaat te resetten; geef voorrang aan instructies voor de vermelde hardwarerevisie.” Voeg bij een dubbelzinnige productnaam de productcategorie toe, zodat niet-gerelateerde betekenissen niet overheersen. Een voorkeur in de zoekvraag stuurt de semantische scoring; gebruik expliciete collectiemetadata om het juiste product, de documentversie of de toegangsafbakening te selecteren voordat je de kandidatenlijst opbouwt.
Bereid een shortlist van tekstkandidaten voor De invoerdocumenten zijn strings. Extraheer leesbare tekst uit bronmateriaal en behoud bruikbare titels, koppen, identificatoren en omringende context. Houd een stabiele koppeling van elke invoerpositie naar de oorspronkelijke registratie bij. Neem voor een probleemoplossingsartikel het symptoom en de relevante procedure op, niet alleen een losse zin. Neem voor broncodezoeken de functie en nabijgelegen informatie op die nodig is om haar van gelijknamige functies te onderscheiden. Verwijder herhaalde navigatie of standaardtekst wanneer die de bruikbare passage verdringt.
De reranker kan alleen de documenten herschikken die hij ontvangt. Als de eerste zoekopdracht het relevante artikel nooit ophaalt, kan deze fase die ontbrekende kandidaat niet terughalen. Controleer zowel de shortlist als de uiteindelijke volgorde wanneer een resultaat onjuist lijkt. Splits een lang document met veel onderwerpen in samenhangende secties en behoud de verwijzingen naar het bovenliggende document, zodat een relevante sectie kan worden geselecteerd zonder de bron te verliezen.
Context en verzoeklimieten De huidige gids van de maker specificeert een zoekvraagmaximum van 8.000 tokens en een gecombineerd maximum van 32.000 tokens voor de zoekvraag plus elk afzonderlijk document. Er zijn maximaal 1.000 kandidaatdocumenten en een totaal verzoekbudget van 600.000 tokens toegestaan, berekend als zoekvraagtokens vermenigvuldigd met het aantal documenten, plus alle documenttokens. Een lange zoekvraag verbruikt dus ruimte in elk paar en telt herhaaldelijk mee in het totale budget. Tel de ingediende tekst met de juiste modeltokenizer in plaats van tekens, woorden en tokens als uitwisselbaar te beschouwen.
Een zoekvraag van 500 tokens met 100 documenten van elk 4.000 tokens komt volgens die formule bijvoorbeeld op 450.000 invoertokens. Dit illustreert budgettering, geen aanbevolen shortlistgrootte of gemeten snelheidsresultaat. De gedocumenteerde afkapoptie staat standaard aan; te grote tekst kan vóór de scoring worden ingekort. Bereid belangrijke secties bewust voor, zodat afkappen niet precies de passage verwijdert die je wilt laten overeenkomen.
Lees en gebruik het resultaat Resultaten worden gesorteerd van de hoogste relevantiescore naar beneden. Elk resultaat identificeert de oorspronkelijke invoerpositie van het document, zodat de toepassing haar eigen titel, registratie-ID en bron kan toevoegen. De instelling top_k bepaalt hoeveel gerangschikte kandidaten worden teruggegeven; zonder die instelling worden alle kandidaten teruggegeven. De REST-interface van de maker kan ook de documenttekst teruggeven. Bewaar de oorspronkelijke identificatoren bij de geselecteerde resultaten wanneer je een zoekpagina toont of bewijs doorgeeft aan een stap voor antwoordgeneratie.
Een relevantiescore drukt uit hoe goed een kandidaat bij de zoekvraag past; zij stelt niet vast dat de beweringen van die kandidaat juist zijn. Vergelijk de hoogst gerangschikte items met de daadwerkelijke vraag van de gebruiker, inclusief uitsluitingen en verschillen tussen documentversies. Als elke kandidaat irrelevant is, bestaat er nog steeds een hoogst gerangschikt item. Bepaal met representatieve zoekvragen uit de collectie hoe de toepassing dat geval afhandelt.
Upgraden en de editie kiezen De maker beschrijft rerank-3-lite als een upgrade van rerank-2.5-lite met ongewijzigde API-semantiek en scores die zijn gekalibreerd op de verdeling van de overeenkomstige voorganger. Behoud de bestaande registratiekoppeling en retrievalfase en vergelijk vervolgens de resulterende volgorde voor betekenisvolle zoekvragen voordat je vertrouwt op een bestaande scoredrempel. Gebruik Lite voor een zoekervaring waarin responstijd belangrijk is; gebruik de op kwaliteit gerichte rerank-3-editie ter vergelijking wanneer relevantie bij lastige kandidaten de grotere prioriteit heeft.
POST /v1/reranktextrerank| Veld | Type | Vereiste | Waarden en limieten | Standaard |
|---|---|---|---|---|
Velddocuments | Typearray | VereisteVereist | Waarden en limieten | Standaard— |
Veldmodel | Typestring | VereisteVereist | Waarden en limieten voyageai/rerank-3-lite | Standaard— |
Veldprovider | Typeschema | VereisteOptioneel | Waarden en limieten | Standaard— |
Veldquery | Typestring | VereisteVereist | Waarden en limieten | Standaard— |
Veldsession_id | Typestring | VereisteOptioneel | Waarden en limieten | Standaard— |
Veldtop_n | Typeinteger | VereisteOptioneel | Waarden en limieten Minimum: 1 | Standaard— |
Veldtrace | Typeschema | VereisteOptioneel | Waarden en limieten | Standaard— |
Velduser | Typestring | VereisteOptioneel | Waarden en limieten | Standaard— |
Velddocuments[].text | Typestring | VereisteOptioneel | Waarden en limieten | Standaard— |
Velddocuments[].image | Typestring | VereisteOptioneel | Waarden en limieten | Standaard— |
text_rerank · Vereist: query, documents array with minItems1
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, query, documents |
Parametermaterial_types | Contracttext |
Parameteroptional_controls | Contractprovider, session_id, top_n, trace, user |
Parametermultimodal_input_binding | Contractnull |
Levenscyclus: synchronous
Verstuur de exacte model-ID en bewaar het volledige native antwoord.
Tariefverwijzingen voegen geen verzoekopties toe. Ondersteunde parameters staan bij de geselecteerde methode.
Koppel elke kostenpost aan de getoonde voorwaarden. Gebruik één tarief voor elke groep alternatieve configuraties.
| Configuratie | Tariefstaffel | Rekeneenheid | Kosten |
|---|---|---|---|
| ConfiguratieBasistarieven voor tokens | TariefstaffelBasistarief | Rekeneenheid— | Kosten Invoer · Invoertokens — / 1K tokens Uitvoer · Uitvoertokens — / 1K tokens Invoer · Cache lezen — / 1K tokens Invoer · Cache schrijven — / 1K tokens Invoer · Cache schrijven, 1 uur — / 1K tokens |
| ConfiguratieUltra | Tariefstaffel— | Rekeneenheid/ 1K tokens | Kosten Invoer $0.00004 / 1K tokens |
Ailoot reserveert vóór een verzoek een geschat bedrag. Na het resultaat worden de uiteindelijke kosten afgerekend op basis van het gemeten verbruik. Bij streaming gebeurt de afrekening op basis van de definitieve verbruiksregistratie. Zo werken reservering en afrekening →
{\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
Bewaar elk volledig teruggegeven antwoord, bestand en inhoudsonderdeel.
Elke daadwerkelijke resultaatindex, eindige relevance_score en elk oorspronkelijk documentobject blijven behouden. De indices koppelen aan de oorspronkelijke documentarray. De volledige oorspronkelijke JSON wordt opgeslagen en pas na afrekening geretourneerd.
Bewaar de oorspronkelijke operatie en het volledige of gedeeltelijke antwoord; herhaal POST niet.
| Veld | Type |
|---|---|
Veldmodel | Typestring |
Veldid | Typestring |
Veldprovider | Typestring |
Veldresults[].index | Typeinteger |
Veldresults[].relevance_score | Typenumber |
Veldresults[].document.text | Typestring |
Veldresults[].document.image | Typestring |
Veldusage.search_units | Typeinteger |
Veldusage.total_tokens | Typeinteger |
Veldusage.cost | Typenumber |
| Antwoord | Voorwaarde | Volgende stap |
|---|---|---|
Antwoord400 · invalid_request_error | VoorwaardeOngeldig vereist veld, ongeldige weergave of waarde | Volgende stapCorrigeer het aangegeven verzoekveld. |
Ailoot Ultra voyageai/rerank-3-lite
Gebruik de hierboven getoonde methodepaden.