Voyage rerank-3-lite är den latensinriktade utgåvan i Voyages Rerank 3-serie. Den tar en textfråga och kandidatdokument, bedömer varje fråga–dokument-par tillsammans och returnerar relevanspoäng i rangordning. Den fyller sökningens andra steg: en embedding- eller nyckelordsbaserad hämtare hittar kandidaterna och Lite förfinar sedan deras ordning. Resultatet är en rangordning att använda i sökning eller ett arbetsflöde för hämtningsförstärkt generering.
Vad som ändras i Rerank 3 Lite Tillverkaren betonar starkare hämtning för långa dokument och kod jämfört med rerank-2.5-lite. Båda Rerank 3-utgåvorna behåller instruktionsföljning och samma kontextklass på 32K, medan Lite är utformad för latenskänsliga applikationer. Det gör den till en praktisk kandidat för interaktiv kunskapsbassökning, hämtning av supportdokument och koduppslagning när användarna behöver relevanta resultat snabbt. Välj den utifrån den faktiska samlingens kvalitets- och svarstidskrav i stället för att anta att en mindre utgåva innebär ett mindre kontextfönster.
Styr relevansen med frågan Instruktioner på naturligt språk kan följa med frågan för att förklara vad som räknas som relevant. Håll frågan och relevansönskemålet korta och samstämmiga. För en supportsökning om programvara använder du ”Hitta förfarandet för att återställa en enhet; prioritera instruktioner för den angivna hårdvarurevisionen.” För ett tvetydigt produktnamn tar du med produktkategorin så att orelaterade betydelser inte dominerar. Ett önskemål i frågan styr den semantiska poängsättningen; använd uttryckliga samlingsmetadata för att välja rätt produkt, dokumentversion eller åtkomstomfattning innan kandidatlistan byggs.
Förbered ett kort urval av textkandidater Indatadokumenten är strängar. Extrahera läsbar text ur källmaterialet och behåll användbara titlar, rubriker, identifierare och omgivande kontext. Behåll en stabil koppling från varje indataposition till originalposten. För en felsökningsartikel tar du med symtomet och det relevanta förfarandet, inte bara en lösryckt mening. För källkodssökning tar du med funktionen och närliggande information som behövs för att skilja den från funktioner med liknande namn. Ta bort upprepad navigation eller standardtext när den tränger undan det användbara avsnittet.
Omrangordnaren kan bara ändra ordningen på dokumenten den tar emot. Om den första sökningen aldrig hämtar den relevanta artikeln kan detta steg inte återvinna den saknade kandidaten. Granska både urvalet och den slutliga ordningen när ett resultat verkar fel. När ett långt dokument omfattar många ämnen delar du upp det i sammanhängande avsnitt och behåller hänvisningarna till överordnat dokument så att ett relevant avsnitt kan väljas utan att källan förloras.
Kontext- och förfrågningsgränser Tillverkarens aktuella guide anger högst 8 000 token för frågan och högst 32 000 token sammanlagt för frågan plus varje enskilt dokument. Den tillåter upp till 1 000 kandidatdokument och en total förfrågningsbudget på 600 000 token, beräknad som antalet frågetoken multiplicerat med antalet dokument plus alla dokumenttoken. En lång fråga förbrukar därför utrymme i varje par och bidrar upprepade gånger till totalbudgeten. Räkna den inskickade texten med den aktuella modellens tokenizer i stället för att behandla tecken, ord och token som utbytbara.
Till exempel motsvarar en fråga på 500 token med 100 dokument på 4 000 token vardera 450 000 indatatoken enligt formeln. Detta illustrerar budgetering, ingen rekommenderad urvalsstorlek eller ett uppmätt hastighetsresultat. Det dokumenterade trunkeringsalternativet är aktiverat som standard; för stor text kan kortas före poängsättning. Förbered viktiga avsnitt medvetet så att trunkeringen inte tar bort just det avsnitt som du behöver matcha.
Läs och använd resultatet Resultaten sorteras från högsta relevanspoäng och nedåt. Varje resultat identifierar dokumentets ursprungliga indataposition, vilket låter applikationen koppla på egen titel, postidentifierare och källa. Inställningen top_k styr hur många rangordnade kandidater som returneras; utan den returneras alla kandidater. Tillverkarens REST-gränssnitt kan även returnera dokumenttexten. Behåll originalidentifierarna tillsammans med de valda resultaten när en söksida visas eller belägg förs vidare till ett svarsgenereringssteg.
En relevanspoäng uttrycker hur väl en kandidat matchar frågan; den fastställer inte att kandidatens påståenden är korrekta. Jämför de högst rankade objekten med användarens faktiska fråga, inklusive undantag och skillnader i dokumentversion. Om varje kandidat är irrelevant finns det ändå ett högst rankat objekt. Avgör hur applikationen hanterar det fallet med representativa frågor från samlingen.
Uppgradering och val av utgåva Tillverkaren beskriver rerank-3-lite som en uppgradering från rerank-2.5-lite med oförändrad API-semantik och poäng kalibrerade mot motsvarande föregångares fördelning. Bevara den befintliga postkopplingen och hämtningssteget och jämför sedan den resulterande ordningen för meningsfulla frågor innan du förlitar dig på ett etablerat poängtröskelvärde. Använd Lite för en sökupplevelse där svarstiden spelar roll; använd den kvalitetsinriktade rerank-3-utgåvan som jämförelse när relevans för svåra kandidater är den starkare prioriteringen.
", "aboutText": "Voyage rerank-3-lite är den latensinriktade utgåvan i Voyages Rerank 3-serie. Den tar en textfråga och kandidatdokument, bedömer varje fråga–dokument-par tillsammans och returnerar relevanspoäng i rangordning. Den fyller sökningens andra steg: en embedding- eller nyckelordsbaserad hämtare hittar kandidaterna och Lite förfinar sedan deras ordning. Resultatet är en rangordning att använda i sökning eller ett arbetsflöde för hämtningsförstärkt generering.\n\nVad som ändras i Rerank 3 Lite\nTillverkaren betonar starkare hämtning för långa dokument och kod jämfört med rerank-2.5-lite. Båda Rerank 3-utgåvorna behåller instruktionsföljning och samma kontextklass på 32K, medan Lite är utformad för latenskänsliga applikationer. Det gör den till en praktisk kandidat för interaktiv kunskapsbassökning, hämtning av supportdokument och koduppslagning när användarna behöver relevanta resultat snabbt. Välj den utifrån den faktiska samlingens kvalitets- och svarstidskrav i stället för att anta att en mindre utgåva innebär ett mindre kontextfönster.\n\nStyr relevansen med frågan\nInstruktioner på naturligt språk kan följa med frågan för att förklara vad som räknas som relevant. Håll frågan och relevansönskemålet korta och samstämmiga. För en supportsökning om programvara använder du ”Hitta förfarandet för att återställa en enhet; prioritera instruktioner för den angivna hårdvarurevisionen.” För ett tvetydigt produktnamn tar du med produktkategorin så att orelaterade betydelser inte dominerar. Ett önskemål i frågan styr den semantiska poängsättningen; använd uttryckliga samlingsmetadata för att välja rätt produkt, dokumentversion eller åtkomstomfattning innan kandidatlistan byggs.\n\nFörbered ett kort urval av textkandidater\nIndatadokumenten är strängar. Extrahera läsbar text ur källmaterialet och behåll användbara titlar, rubriker, identifierare och omgivande kontext. Behåll en stabil koppling från varje indataposition till originalposten. För en felsökningsartikel tar du med symtomet och det relevanta förfarandet, inte bara en lösryckt mening. För källkodssökning tar du med funktionen och närliggande information som behövs för att skilja den från funktioner med liknande namn. Ta bort upprepad navigation eller standardtext när den tränger undan det användbara avsnittet.\n\nOmrangordnaren kan bara ändra ordningen på dokumenten den tar emot. Om den första sökningen aldrig hämtar den relevanta artikeln kan detta steg inte återvinna den saknade kandidaten. Granska både urvalet och den slutliga ordningen när ett resultat verkar fel. När ett långt dokument omfattar många ämnen delar du upp det i sammanhängande avsnitt och behåller hänvisningarna till överordnat dokument så att ett relevant avsnitt kan väljas utan att källan förloras.\n\nKontext- och förfrågningsgränser\nTillverkarens aktuella guide anger högst 8 000 token för frågan och högst 32 000 token sammanlagt för frågan plus varje enskilt dokument. Den tillåter upp till 1 000 kandidatdokument och en total förfrågningsbudget på 600 000 token, beräknad som antalet frågetoken multiplicerat med antalet dokument plus alla dokumenttoken. En lång fråga förbrukar därför utrymme i varje par och bidrar upprepade gånger till totalbudgeten. Räkna den inskickade texten med den aktuella modellens tokenizer i stället för att behandla tecken, ord och token som utbytbara.\n\nTill exempel motsvarar en fråga på 500 token med 100 dokument på 4 000 token vardera 450 000 indatatoken enligt formeln. Detta illustrerar budgetering, ingen rekommenderad urvalsstorlek eller ett uppmätt hastighetsresultat. Det dokumenterade trunkeringsalternativet är aktiverat som standard; för stor text kan kortas före poängsättning. Förbered viktiga avsnitt medvetet så att trunkeringen inte tar bort just det avsnitt som du behöver matcha.\n\nLäs och använd resultatet\nResultaten sorteras från högsta relevanspoäng och nedåt. Varje resultat identifierar dokumentets ursprungliga indataposition, vilket låter applikationen koppla på egen titel, postidentifierare och källa. Inställningen top_k styr hur många rangordnade kandidater som returneras; utan den returneras alla kandidater. Tillverkarens REST-gränssnitt kan även returnera dokumenttexten. Behåll originalidentifierarna tillsammans med de valda resultaten när en söksida visas eller belägg förs vidare till ett svarsgenereringssteg.\n\nEn relevanspoäng uttrycker hur väl en kandidat matchar frågan; den fastställer inte att kandidatens påståenden är korrekta. Jämför de högst rankade objekten med användarens faktiska fråga, inklusive undantag och skillnader i dokumentversion. Om varje kandidat är irrelevant finns det ändå ett högst rankat objekt. Avgör hur applikationen hanterar det fallet med representativa frågor från samlingen.\n\nUppgradering och val av utgåva\nTillverkaren beskriver rerank-3-lite som en uppgradering från rerank-2.5-lite med oförändrad API-semantik och poäng kalibrerade mot motsvarande föregångares fördelning. Bevara den befintliga postkopplingen och hämtningssteget och jämför sedan den resulterande ordningen för meningsfulla frågor innan du förlitar dig på ett etablerat poängtröskelvärde. Använd Lite för en sökupplevelse där svarstiden spelar roll; använd den kvalitetsinriktade rerank-3-utgåvan som jämförelse när relevans för svåra kandidater är den starkare prioriteringen.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "298b49222ebfd9409b64fb7aaf69cc0beae60969893fa38447a2d3e550f1e0e2", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "sv", "methods": [ { "html": "voyageai/rerank-3-liteVoyage rerank-3-lite poängsätter och omordnar kandidatdokument i text för en fråga, med fokus på snabba söksvar. Den stöder relevansinstruktioner och ett fråga–dokument-fönster på 32 000 token, vilket gör den användbar efter vektor- eller nyckelordshämtning i sök- och RAG-flöden.
Den här beskrivningen omfattar modellens förmågor. Tillgängliga indata, utdata och alternativ i Ailoot anges nedan för den valda metoden.
Voyage rerank-3-lite är den latensinriktade utgåvan i Voyages Rerank 3-serie. Den tar en textfråga och kandidatdokument, bedömer varje fråga–dokument-par tillsammans och returnerar relevanspoäng i rangordning. Den fyller sökningens andra steg: en embedding- eller nyckelordsbaserad hämtare hittar kandidaterna och Lite förfinar sedan deras ordning. Resultatet är en rangordning att använda i sökning eller ett arbetsflöde för hämtningsförstärkt generering.
Vad som ändras i Rerank 3 Lite Tillverkaren betonar starkare hämtning för långa dokument och kod jämfört med rerank-2.5-lite. Båda Rerank 3-utgåvorna behåller instruktionsföljning och samma kontextklass på 32K, medan Lite är utformad för latenskänsliga applikationer. Det gör den till en praktisk kandidat för interaktiv kunskapsbassökning, hämtning av supportdokument och koduppslagning när användarna behöver relevanta resultat snabbt. Välj den utifrån den faktiska samlingens kvalitets- och svarstidskrav i stället för att anta att en mindre utgåva innebär ett mindre kontextfönster.
Styr relevansen med frågan Instruktioner på naturligt språk kan följa med frågan för att förklara vad som räknas som relevant. Håll frågan och relevansönskemålet korta och samstämmiga. För en supportsökning om programvara använder du ”Hitta förfarandet för att återställa en enhet; prioritera instruktioner för den angivna hårdvarurevisionen.” För ett tvetydigt produktnamn tar du med produktkategorin så att orelaterade betydelser inte dominerar. Ett önskemål i frågan styr den semantiska poängsättningen; använd uttryckliga samlingsmetadata för att välja rätt produkt, dokumentversion eller åtkomstomfattning innan kandidatlistan byggs.
Förbered ett kort urval av textkandidater Indatadokumenten är strängar. Extrahera läsbar text ur källmaterialet och behåll användbara titlar, rubriker, identifierare och omgivande kontext. Behåll en stabil koppling från varje indataposition till originalposten. För en felsökningsartikel tar du med symtomet och det relevanta förfarandet, inte bara en lösryckt mening. För källkodssökning tar du med funktionen och närliggande information som behövs för att skilja den från funktioner med liknande namn. Ta bort upprepad navigation eller standardtext när den tränger undan det användbara avsnittet.
Omrangordnaren kan bara ändra ordningen på dokumenten den tar emot. Om den första sökningen aldrig hämtar den relevanta artikeln kan detta steg inte återvinna den saknade kandidaten. Granska både urvalet och den slutliga ordningen när ett resultat verkar fel. När ett långt dokument omfattar många ämnen delar du upp det i sammanhängande avsnitt och behåller hänvisningarna till överordnat dokument så att ett relevant avsnitt kan väljas utan att källan förloras.
Kontext- och förfrågningsgränser Tillverkarens aktuella guide anger högst 8 000 token för frågan och högst 32 000 token sammanlagt för frågan plus varje enskilt dokument. Den tillåter upp till 1 000 kandidatdokument och en total förfrågningsbudget på 600 000 token, beräknad som antalet frågetoken multiplicerat med antalet dokument plus alla dokumenttoken. En lång fråga förbrukar därför utrymme i varje par och bidrar upprepade gånger till totalbudgeten. Räkna den inskickade texten med den aktuella modellens tokenizer i stället för att behandla tecken, ord och token som utbytbara.
Till exempel motsvarar en fråga på 500 token med 100 dokument på 4 000 token vardera 450 000 indatatoken enligt formeln. Detta illustrerar budgetering, ingen rekommenderad urvalsstorlek eller ett uppmätt hastighetsresultat. Det dokumenterade trunkeringsalternativet är aktiverat som standard; för stor text kan kortas före poängsättning. Förbered viktiga avsnitt medvetet så att trunkeringen inte tar bort just det avsnitt som du behöver matcha.
Läs och använd resultatet Resultaten sorteras från högsta relevanspoäng och nedåt. Varje resultat identifierar dokumentets ursprungliga indataposition, vilket låter applikationen koppla på egen titel, postidentifierare och källa. Inställningen top_k styr hur många rangordnade kandidater som returneras; utan den returneras alla kandidater. Tillverkarens REST-gränssnitt kan även returnera dokumenttexten. Behåll originalidentifierarna tillsammans med de valda resultaten när en söksida visas eller belägg förs vidare till ett svarsgenereringssteg.
En relevanspoäng uttrycker hur väl en kandidat matchar frågan; den fastställer inte att kandidatens påståenden är korrekta. Jämför de högst rankade objekten med användarens faktiska fråga, inklusive undantag och skillnader i dokumentversion. Om varje kandidat är irrelevant finns det ändå ett högst rankat objekt. Avgör hur applikationen hanterar det fallet med representativa frågor från samlingen.
Uppgradering och val av utgåva Tillverkaren beskriver rerank-3-lite som en uppgradering från rerank-2.5-lite med oförändrad API-semantik och poäng kalibrerade mot motsvarande föregångares fördelning. Bevara den befintliga postkopplingen och hämtningssteget och jämför sedan den resulterande ordningen för meningsfulla frågor innan du förlitar dig på ett etablerat poängtröskelvärde. Använd Lite för en sökupplevelse där svarstiden spelar roll; använd den kvalitetsinriktade rerank-3-utgåvan som jämförelse när relevans för svåra kandidater är den starkare prioriteringen.
POST /v1/reranktextrerank| Fält | Typ | Krav | Värden & gränser | Standard |
|---|---|---|---|---|
Fältdocuments | Typarray | KravObligatoriskt | Värden & gränser | Standard— |
Fältmodel | Typstring | KravObligatoriskt | Värden & gränser voyageai/rerank-3-lite | Standard— |
Fältprovider | Typschema | KravValfritt | Värden & gränser | Standard— |
Fältquery | Typstring | KravObligatoriskt | Värden & gränser | Standard— |
Fältsession_id | Typstring | KravValfritt | Värden & gränser | Standard— |
Fälttop_n | Typinteger | KravValfritt | Värden & gränser Minimum: 1 | Standard— |
Fälttrace | Typschema | KravValfritt | Värden & gränser | Standard— |
Fältuser | Typstring | KravValfritt | Värden & gränser | Standard— |
Fältdocuments[].text | Typstring | KravValfritt | Värden & gränser | Standard— |
Fältdocuments[].image | Typstring | KravValfritt | Värden & gränser | Standard— |
text_rerank · Krävs: query, documents array with minItems1
| Parameter | Avtal |
|---|---|
Parametercontent_type | Avtalapplication/json |
Parameterrequired | Avtalmodel, query, documents |
Parametermaterial_types | Avtaltext |
Parameteroptional_controls | Avtalprovider, session_id, top_n, trace, user |
Parametermultimodal_input_binding | Avtalnull |
Livscykel: synchronous
Skicka det exakta modell-ID:t och behåll hela svaret i leverantörens format.
Tariffuppgifter lägger inte till begäransalternativ. Parametrar som stöds anges för den valda metoden.
Matcha varje avgift mot de visade villkoren. Använd ett pris för varje uppsättning alternativa konfigurationer.
| Konfiguration | Prislista | Debiteringsenhet | Avgift |
|---|---|---|---|
| KonfigurationGrundpriser för token | PrislistaGrundpris | Debiteringsenhet— | Avgift Indata · Indatatoken — / 1K token Utdata · Utdatatoken — / 1K token Indata · Cacheläsning — / 1K token Indata · Skrivning till cache — / 1K token Indata · Skrivning till cache, 1 tim — / 1K token |
| KonfigurationUltra | Prislista— | Debiteringsenhet/ 1K token | Avgift Indata $0.00004 / 1K token |
Ailoot reserverar ett uppskattat belopp före en begäran. Efter resultatet slutregleras avgiften utifrån uppmätt förbrukning. Slutreglering för strömning använder den slutliga förbrukningsposten. Så fungerar reservation och slutreglering →
{\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
Behåll varje fullständigt returnerat svar, fil och innehållsdel.
Varje faktiskt resultatindex, ändligt relevance_score och ursprungligt dokumentobjekt behålls. Indexen knyter resultaten till den ursprungliga dokumentarrayen. Hela det ursprungliga JSON-svaret lagras och returneras först efter avräkning.
Bevara den ursprungliga operationen och hela eller det partiella svaret; upprepa inte POST.
| Fält | Typ |
|---|---|
Fältmodel | Typstring |
Fältid | Typstring |
Fältprovider | Typstring |
Fältresults[].index | Typinteger |
Fältresults[].relevance_score | Typnumber |
Fältresults[].document.text | Typstring |
Fältresults[].document.image | Typstring |
Fältusage.search_units | Typinteger |
Fältusage.total_tokens | Typinteger |
Fältusage.cost | Typnumber |
| Svar | Villkor | Nästa steg |
|---|---|---|
Svar400 · invalid_request_error | VillkorOgiltigt obligatoriskt fält, ogiltig representation eller ogiltigt värde | Nästa stegKorrigera det angivna fältet i begäran. |
Ailoot Ultra voyageai/rerank-3-lite
Använd metodsökvägarna som visas ovan.