Voyage rerank-3 är en omrangordnare för text utformad för att förbättra kvaliteten på hämtade underlag. Med en fråga och en lista med kandidatdokument granskar den varje par tillsammans och returnerar kandidaterna ordnade efter relevans. Embeddings och nyckelordssökning kan först begränsa en stor samling till ett hanterbart urval; rerank-3 tillämpar sedan en mer detaljerad relevansbedömning på urvalet. Utdata är poängsatta sökunderlag som en applikation kan visa eller skicka vidare till ett separat svarsgenereringssteg.
Kvalitetsinriktad Rerank 3 Tillverkaren positionerar rerank-3 som den noggrannhetsinriktade utgåvan och rerank-3-lite som utgåvan för latenskänslig sökning. Den tredje generationen uppdaterar basarkitekturen och träningsblandningen, med särskilda förbättringar för hämtning av långa dokument och källkod jämfört med motsvarande 2.5-föregångare. Tillverkaren utvärderar den över teknisk dokumentation, kod, flerspråkigt material och andra dokumentdomäner. Dessa resultat stöder dess hämtningsroll; välj utgåva utifrån de frågor och kandidatdokument som spelar roll i din egen samling.
Långa dokument med tillräcklig kontext En lång kandidat kan innehålla användbar kontext långt bortom det inledande stycket. Tillhandahåll ett sammanhängande avsnitt eller dokument med titel och relevant omgivande material så att modellen kan bedöma hur den faktiska frågan hänger ihop med innehållet. För en sökning om produktpolicy bevarar du rubriker och undantag kring det intressanta avsnittet. Om flera hämtade avsnitt kommer från samma källa behåller du deras dokument- och avsnittsidentifierare; applikationen kan då visa var det valda underlaget kom ifrån.
Kontextfönstret delas av frågan och varje kandidat. Tillverkarens aktuella guide anger 32 000 token för paret, inklusive en fråga på högst 8 000 token. En fråga på 3 000 token lämnar därför högst 29 000 token för varje dokument. Förbered indata så att det väsentliga innehållet ryms, särskilt när en lång inledning eller upprepad standardtext annars skulle förbruka fönstret. Det dokumenterade trunkeringsalternativet är aktiverat som standard och kan korta för stor fråge- eller dokumenttext före poängsättningen. Granska vad som behålls när avsnittets placering spelar roll.
Kod och teknisk hämtning För en kodassistents hämtningssteg kan kandidater innehålla funktionsimplementationer, API-dokumentation eller tekniska förklaringar som text. Ta med symboler, signaturer och kontext som behövs för att skilja liknande kandidater åt. En fråga som ”Hitta funktionen som normaliserar sökvägar och samtidigt bevarar en avslutande avgränsare” ger ett konkret beteende att matcha. Lägg till eventuella relevanta språk-, plattforms- eller versionskrav. Efter rangordning granskar du den valda koden och dess beroenden innan den används som kontext; en relevanspoäng bevisar inte att en implementation uppfyller varje angivet krav.
Instruktioner definierar relevans Modellen behåller den instruktionsföljande omrangordningsförmåga som infördes i Rerank 2.5. Lägg en kort instruktion före eller efter frågan när användarens avsikt behöver förtydligas. För sökning i forskningsdokument förklarar du om fokus ligger på titeln, en viss metod eller ett tillämpningsområde. För en intern katalog anger du om förfrågan gäller installation, felsökning eller kompatibilitet. Håll instruktionen i linje med frågan; extra önskemål som står i konflikt med huvudförfrågan kan ändra vad rangordningen försöker optimera.
Förbered kandidatdokument och budgetar Indata är en lista med textsträngar. Extrahera användbar text ur källdokumenten, bevara meningsfulla avsnittsgränser och behåll en ordnad postkarta tillsammans med listan. Tillverkaren tillåter upp till 1 000 dokument i en förfrågan. Den anger även ett sammanlagt indatatak på 600 000 token: frågetoken multiplicerat med antalet dokument plus summan av alla dokumenttoken. Detta skiljer sig från kontextgränsen per par. Att minska överflödig frågetext kan bevara både parkapacitet och total förfrågningsbudget.
Räkna token för den relevanta modellen i stället för att anta att ett ord- eller teckenantal är ett tokenantal. För stora kandidater väljer du sammanhängande textavsnitt eller delar materialet efter användbara rubriker samtidigt som information om överordnad källa behålls. Omrangordning är mest användbar när den första sökningen redan har hittat rimliga kandidater: den kan inte rangordna en saknad källa som aldrig kom med i listan.
Rangordnade resultat och efterföljande användning Resultatet innehåller relevanspoäng och index som hänvisar till de ursprungliga indatadokumenten, sorterade i fallande relevansordning. Alternativet top_k begränsar antalet rangordnade resultat som returneras; annars returneras alla indatakandidater. Tillverkarens REST-gränssnitt tillåter även att dokumenttexten inkluderas. Använd varje ursprungligt index för att återfinna titel, källidentifierare och eventuella metadata som applikationen behöver och presentera sedan de valda objekten eller lägg den relevanta texten i svarets beläggskontext.
Granska toppresultaten mot frågan och håll källidentiteten synlig. En hög relativ placering verifierar inte ett dokuments faktiska korrekthet och ett urval med bara dåliga kandidater får ändå ett förstaplacerat objekt. Skilj relevansurval från beslutet om huruvida det valda underlaget är tillräckligt för att besvara användaren.
Migrering mellan utgåvor Tillverkaren beskriver rerank-3 som en direkt ersättare till rerank-2.5, med samma API-semantik och poäng kalibrerade mot motsvarande föregångares fördelning. Kompatibiliteten stöder att behålla ett befintligt hämtningssteg och postkoppling. Jämför meningsfulla resultatordningar och eventuella poängtrösklar på den aktuella samlingen innan du förlitar dig på migreringen. Håll rerank-3 och rerank-3-lite som separata val: gemensamma gränser och instruktionsföljning gör inte deras kvalitets- och latensprioriteringar identiska.
", "aboutText": "Voyage rerank-3 är en omrangordnare för text utformad för att förbättra kvaliteten på hämtade underlag. Med en fråga och en lista med kandidatdokument granskar den varje par tillsammans och returnerar kandidaterna ordnade efter relevans. Embeddings och nyckelordssökning kan först begränsa en stor samling till ett hanterbart urval; rerank-3 tillämpar sedan en mer detaljerad relevansbedömning på urvalet. Utdata är poängsatta sökunderlag som en applikation kan visa eller skicka vidare till ett separat svarsgenereringssteg.\n\nKvalitetsinriktad Rerank 3\nTillverkaren positionerar rerank-3 som den noggrannhetsinriktade utgåvan och rerank-3-lite som utgåvan för latenskänslig sökning. Den tredje generationen uppdaterar basarkitekturen och träningsblandningen, med särskilda förbättringar för hämtning av långa dokument och källkod jämfört med motsvarande 2.5-föregångare. Tillverkaren utvärderar den över teknisk dokumentation, kod, flerspråkigt material och andra dokumentdomäner. Dessa resultat stöder dess hämtningsroll; välj utgåva utifrån de frågor och kandidatdokument som spelar roll i din egen samling.\n\nLånga dokument med tillräcklig kontext\nEn lång kandidat kan innehålla användbar kontext långt bortom det inledande stycket. Tillhandahåll ett sammanhängande avsnitt eller dokument med titel och relevant omgivande material så att modellen kan bedöma hur den faktiska frågan hänger ihop med innehållet. För en sökning om produktpolicy bevarar du rubriker och undantag kring det intressanta avsnittet. Om flera hämtade avsnitt kommer från samma källa behåller du deras dokument- och avsnittsidentifierare; applikationen kan då visa var det valda underlaget kom ifrån.\n\nKontextfönstret delas av frågan och varje kandidat. Tillverkarens aktuella guide anger 32 000 token för paret, inklusive en fråga på högst 8 000 token. En fråga på 3 000 token lämnar därför högst 29 000 token för varje dokument. Förbered indata så att det väsentliga innehållet ryms, särskilt när en lång inledning eller upprepad standardtext annars skulle förbruka fönstret. Det dokumenterade trunkeringsalternativet är aktiverat som standard och kan korta för stor fråge- eller dokumenttext före poängsättningen. Granska vad som behålls när avsnittets placering spelar roll.\n\nKod och teknisk hämtning\nFör en kodassistents hämtningssteg kan kandidater innehålla funktionsimplementationer, API-dokumentation eller tekniska förklaringar som text. Ta med symboler, signaturer och kontext som behövs för att skilja liknande kandidater åt. En fråga som ”Hitta funktionen som normaliserar sökvägar och samtidigt bevarar en avslutande avgränsare” ger ett konkret beteende att matcha. Lägg till eventuella relevanta språk-, plattforms- eller versionskrav. Efter rangordning granskar du den valda koden och dess beroenden innan den används som kontext; en relevanspoäng bevisar inte att en implementation uppfyller varje angivet krav.\n\nInstruktioner definierar relevans\nModellen behåller den instruktionsföljande omrangordningsförmåga som infördes i Rerank 2.5. Lägg en kort instruktion före eller efter frågan när användarens avsikt behöver förtydligas. För sökning i forskningsdokument förklarar du om fokus ligger på titeln, en viss metod eller ett tillämpningsområde. För en intern katalog anger du om förfrågan gäller installation, felsökning eller kompatibilitet. Håll instruktionen i linje med frågan; extra önskemål som står i konflikt med huvudförfrågan kan ändra vad rangordningen försöker optimera.\n\nFörbered kandidatdokument och budgetar\nIndata är en lista med textsträngar. Extrahera användbar text ur källdokumenten, bevara meningsfulla avsnittsgränser och behåll en ordnad postkarta tillsammans med listan. Tillverkaren tillåter upp till 1 000 dokument i en förfrågan. Den anger även ett sammanlagt indatatak på 600 000 token: frågetoken multiplicerat med antalet dokument plus summan av alla dokumenttoken. Detta skiljer sig från kontextgränsen per par. Att minska överflödig frågetext kan bevara både parkapacitet och total förfrågningsbudget.\n\nRäkna token för den relevanta modellen i stället för att anta att ett ord- eller teckenantal är ett tokenantal. För stora kandidater väljer du sammanhängande textavsnitt eller delar materialet efter användbara rubriker samtidigt som information om överordnad källa behålls. Omrangordning är mest användbar när den första sökningen redan har hittat rimliga kandidater: den kan inte rangordna en saknad källa som aldrig kom med i listan.\n\nRangordnade resultat och efterföljande användning\nResultatet innehåller relevanspoäng och index som hänvisar till de ursprungliga indatadokumenten, sorterade i fallande relevansordning. Alternativet top_k begränsar antalet rangordnade resultat som returneras; annars returneras alla indatakandidater. Tillverkarens REST-gränssnitt tillåter även att dokumenttexten inkluderas. Använd varje ursprungligt index för att återfinna titel, källidentifierare och eventuella metadata som applikationen behöver och presentera sedan de valda objekten eller lägg den relevanta texten i svarets beläggskontext.\n\nGranska toppresultaten mot frågan och håll källidentiteten synlig. En hög relativ placering verifierar inte ett dokuments faktiska korrekthet och ett urval med bara dåliga kandidater får ändå ett förstaplacerat objekt. Skilj relevansurval från beslutet om huruvida det valda underlaget är tillräckligt för att besvara användaren.\n\nMigrering mellan utgåvor\nTillverkaren beskriver rerank-3 som en direkt ersättare till rerank-2.5, med samma API-semantik och poäng kalibrerade mot motsvarande föregångares fördelning. Kompatibiliteten stöder att behålla ett befintligt hämtningssteg och postkoppling. Jämför meningsfulla resultatordningar och eventuella poängtrösklar på den aktuella samlingen innan du förlitar dig på migreringen. Håll rerank-3 och rerank-3-lite som separata val: gemensamma gränser och instruktionsföljning gör inte deras kvalitets- och latensprioriteringar identiska.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "1fc78f1a47224c01c80f9d98e796d07865f414d10dac070d7cdbec1f49bdfeda", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "sv", "methods": [ { "html": "voyageai/rerank-3Voyage rerank-3 är den kvalitetsinriktade Rerank 3-utgåvan för poängsättning av relevansen mellan fråga och dokument. Den omordnar hämtade textkandidater, stöder relevansinstruktioner på naturligt språk och hanterar par på 32 000 token för sökning i långa dokument, kod och kunskapsbaser.
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 är en omrangordnare för text utformad för att förbättra kvaliteten på hämtade underlag. Med en fråga och en lista med kandidatdokument granskar den varje par tillsammans och returnerar kandidaterna ordnade efter relevans. Embeddings och nyckelordssökning kan först begränsa en stor samling till ett hanterbart urval; rerank-3 tillämpar sedan en mer detaljerad relevansbedömning på urvalet. Utdata är poängsatta sökunderlag som en applikation kan visa eller skicka vidare till ett separat svarsgenereringssteg.
Kvalitetsinriktad Rerank 3 Tillverkaren positionerar rerank-3 som den noggrannhetsinriktade utgåvan och rerank-3-lite som utgåvan för latenskänslig sökning. Den tredje generationen uppdaterar basarkitekturen och träningsblandningen, med särskilda förbättringar för hämtning av långa dokument och källkod jämfört med motsvarande 2.5-föregångare. Tillverkaren utvärderar den över teknisk dokumentation, kod, flerspråkigt material och andra dokumentdomäner. Dessa resultat stöder dess hämtningsroll; välj utgåva utifrån de frågor och kandidatdokument som spelar roll i din egen samling.
Långa dokument med tillräcklig kontext En lång kandidat kan innehålla användbar kontext långt bortom det inledande stycket. Tillhandahåll ett sammanhängande avsnitt eller dokument med titel och relevant omgivande material så att modellen kan bedöma hur den faktiska frågan hänger ihop med innehållet. För en sökning om produktpolicy bevarar du rubriker och undantag kring det intressanta avsnittet. Om flera hämtade avsnitt kommer från samma källa behåller du deras dokument- och avsnittsidentifierare; applikationen kan då visa var det valda underlaget kom ifrån.
Kontextfönstret delas av frågan och varje kandidat. Tillverkarens aktuella guide anger 32 000 token för paret, inklusive en fråga på högst 8 000 token. En fråga på 3 000 token lämnar därför högst 29 000 token för varje dokument. Förbered indata så att det väsentliga innehållet ryms, särskilt när en lång inledning eller upprepad standardtext annars skulle förbruka fönstret. Det dokumenterade trunkeringsalternativet är aktiverat som standard och kan korta för stor fråge- eller dokumenttext före poängsättningen. Granska vad som behålls när avsnittets placering spelar roll.
Kod och teknisk hämtning För en kodassistents hämtningssteg kan kandidater innehålla funktionsimplementationer, API-dokumentation eller tekniska förklaringar som text. Ta med symboler, signaturer och kontext som behövs för att skilja liknande kandidater åt. En fråga som ”Hitta funktionen som normaliserar sökvägar och samtidigt bevarar en avslutande avgränsare” ger ett konkret beteende att matcha. Lägg till eventuella relevanta språk-, plattforms- eller versionskrav. Efter rangordning granskar du den valda koden och dess beroenden innan den används som kontext; en relevanspoäng bevisar inte att en implementation uppfyller varje angivet krav.
Instruktioner definierar relevans Modellen behåller den instruktionsföljande omrangordningsförmåga som infördes i Rerank 2.5. Lägg en kort instruktion före eller efter frågan när användarens avsikt behöver förtydligas. För sökning i forskningsdokument förklarar du om fokus ligger på titeln, en viss metod eller ett tillämpningsområde. För en intern katalog anger du om förfrågan gäller installation, felsökning eller kompatibilitet. Håll instruktionen i linje med frågan; extra önskemål som står i konflikt med huvudförfrågan kan ändra vad rangordningen försöker optimera.
Förbered kandidatdokument och budgetar Indata är en lista med textsträngar. Extrahera användbar text ur källdokumenten, bevara meningsfulla avsnittsgränser och behåll en ordnad postkarta tillsammans med listan. Tillverkaren tillåter upp till 1 000 dokument i en förfrågan. Den anger även ett sammanlagt indatatak på 600 000 token: frågetoken multiplicerat med antalet dokument plus summan av alla dokumenttoken. Detta skiljer sig från kontextgränsen per par. Att minska överflödig frågetext kan bevara både parkapacitet och total förfrågningsbudget.
Räkna token för den relevanta modellen i stället för att anta att ett ord- eller teckenantal är ett tokenantal. För stora kandidater väljer du sammanhängande textavsnitt eller delar materialet efter användbara rubriker samtidigt som information om överordnad källa behålls. Omrangordning är mest användbar när den första sökningen redan har hittat rimliga kandidater: den kan inte rangordna en saknad källa som aldrig kom med i listan.
Rangordnade resultat och efterföljande användning Resultatet innehåller relevanspoäng och index som hänvisar till de ursprungliga indatadokumenten, sorterade i fallande relevansordning. Alternativet top_k begränsar antalet rangordnade resultat som returneras; annars returneras alla indatakandidater. Tillverkarens REST-gränssnitt tillåter även att dokumenttexten inkluderas. Använd varje ursprungligt index för att återfinna titel, källidentifierare och eventuella metadata som applikationen behöver och presentera sedan de valda objekten eller lägg den relevanta texten i svarets beläggskontext.
Granska toppresultaten mot frågan och håll källidentiteten synlig. En hög relativ placering verifierar inte ett dokuments faktiska korrekthet och ett urval med bara dåliga kandidater får ändå ett förstaplacerat objekt. Skilj relevansurval från beslutet om huruvida det valda underlaget är tillräckligt för att besvara användaren.
Migrering mellan utgåvor Tillverkaren beskriver rerank-3 som en direkt ersättare till rerank-2.5, med samma API-semantik och poäng kalibrerade mot motsvarande föregångares fördelning. Kompatibiliteten stöder att behålla ett befintligt hämtningssteg och postkoppling. Jämför meningsfulla resultatordningar och eventuella poängtrösklar på den aktuella samlingen innan du förlitar dig på migreringen. Håll rerank-3 och rerank-3-lite som separata val: gemensamma gränser och instruktionsföljning gör inte deras kvalitets- och latensprioriteringar identiska.
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 | 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.0001 / 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",\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'\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
Använd metodsökvägarna som visas ovan.