Voyage rerank-3 is een tekstreranker die is ontworpen om de kwaliteit van opgehaald bewijsmateriaal te verbeteren. Het onderzoekt bij een zoekvraag en een lijst kandidaatdocumenten elk paar gezamenlijk en geeft de kandidaten op relevantie gerangschikt terug. Embeddings en trefwoordzoeken kunnen een grote collectie eerst tot een beheersbare shortlist beperken; rerank-3 past daarna een gedetailleerdere relevantiebeoordeling op die shortlist toe. De uitvoer is gescoord zoekbewijsmateriaal dat een toepassing kan tonen of doorgeven aan een afzonderlijke stap voor antwoordgeneratie.
Rerank 3 met de nadruk op kwaliteit De maker positioneert rerank-3 als de op nauwkeurigheid gerichte editie en rerank-3-lite als de editie voor latentiegevoelige zoekfuncties. De derde generatie vernieuwt de backbone en de trainingsmix, met bijzondere verbeteringen voor retrieval van lange documenten en broncode tegenover de overeenkomstige 2.5-voorgangers. De producent evalueert het model op technische documentatie, code, meertalig materiaal en andere documentdomeinen. Die resultaten ondersteunen de retrievalrol; selecteer de editie op basis van de vragen en kandidaatdocumenten die voor je eigen collectie van belang zijn.
Lange documenten met voldoende context Een lange kandidaat kan nuttige context bevatten ver voorbij de openingsalinea. Lever een samenhangende sectie of een document aan met de titel en het relevante omringende materiaal, zodat het model kan beoordelen hoe de daadwerkelijke vraag verband houdt met de inhoud. Behoud bij een zoekopdracht naar productbeleid de koppen en uitzonderingen rond de betreffende passage. Als meerdere opgehaalde secties uit dezelfde bron komen, behoud dan hun document- en sectie-identificatoren; de toepassing kan vervolgens tonen waar het geselecteerde bewijs vandaan komt.
Het contextvenster wordt gedeeld door de zoekvraag en elke kandidaat. De huidige gids van de maker specificeert 32.000 tokens voor dat paar, inclusief een zoekvraag van maximaal 8.000 tokens. Een zoekvraag van 3.000 tokens laat dus maximaal 29.000 tokens voor elk document over. Bereid de invoer zo voor dat de essentiële inhoud past, vooral wanneer een lange inleiding of herhaalde standaardtekst anders het venster zou vullen. De gedocumenteerde afkapoptie staat standaard aan en kan te lange zoekvraag- of documenttekst vóór de scoring inkorten. Controleer wat behouden blijft wanneer de plaats van de passage van belang is.
Code en technische retrieval Voor de retrievalfase van een programmeerassistent kunnen kandidaten functie-implementaties, API-documentatie of technische uitleg als tekst bevatten. Neem de symbolen, signaturen en context op die nodig zijn om vergelijkbare kandidaten te onderscheiden. Een zoekvraag zoals “Vind de functie die paden normaliseert en daarbij een afsluitend scheidingsteken behoudt” geeft concreet gedrag om op te matchen. Voeg relevante beperkingen voor taal, platform of versie toe. Onderzoek na rangschikking de geselecteerde code en afhankelijkheden voordat je die als context gebruikt; een relevantiescore bewijst niet dat een implementatie aan elke genoemde vereiste voldoet.
Instructies definiëren relevantie Het model behoudt de instructievolgende rerankmogelijkheid die in Rerank 2.5 werd geïntroduceerd. Zet een beknopte instructie vóór of achter de zoekvraag wanneer de intentie van de gebruiker verduidelijking nodig heeft. Leg voor zoeken in onderzoeksdocumenten uit of de nadruk ligt op de titel, een specifieke methode of een toepassingsdomein. Specificeer voor een interne catalogus of het verzoek installatie, probleemoplossing of compatibiliteit betreft. Houd die instructie in lijn met de vraag; extra voorkeuren die met het hoofdverzoek botsen, kunnen veranderen wat de rangschikking probeert te optimaliseren.
Bereid kandidaatdocumenten en budgetten voor De invoer is een lijst tekststrings. Extraheer bruikbare tekst uit brondocumenten, behoud betekenisvolle sectiegrenzen en houd naast de lijst een geordende registratiekoppeling bij. De maker staat maximaal 1.000 documenten in één verzoek toe. Hij specificeert ook een totale invoerlimiet van 600.000 tokens: zoekvraagtokens vermenigvuldigd met het aantal documenten, plus de som van alle documenttokens. Dit verschilt van de contextlimiet per paar. Het verminderen van overbodige zoekvraagtekst kan zowel paarcapaciteit als het totale verzoekbudget vrijhouden.
Tel tokens voor het relevante model in plaats van aan te nemen dat een woord- of tekenaantal een tokenaantal is. Selecteer bij grote kandidaten samenhangende passages of deel het materiaal op bij bruikbare koppen met behoud van informatie over de bovenliggende bron. Reranking is het nuttigst nadat de eerste zoekopdracht al aannemelijke kandidaten heeft gevonden: het kan een ontbrekende bron die nooit in de lijst kwam niet rangschikken.
Gerangschikte resultaten en vervolggebruik Het resultaat bevat relevantiescores en indices die naar de oorspronkelijke invoerdocumenten verwijzen, gesorteerd op aflopende relevantie. De optie top_k beperkt het aantal teruggegeven gerangschikte resultaten; anders worden alle invoerkandidaten teruggegeven. De REST-interface van de maker laat ook toe dat de documenttekst wordt opgenomen. Gebruik elke oorspronkelijke index om de titel, bronidentificator en eventuele metadata op te halen die de toepassing nodig heeft en presenteer vervolgens de geselecteerde items of neem de relevante tekst op in de bewijscontext van een antwoord.
Controleer de bovenste resultaten aan de hand van de vraag en houd de bronidentiteit zichtbaar. Een hoge relatieve positie verifieert niet de feitelijke juistheid van een document en een shortlist met alleen slechte kandidaten heeft nog steeds een eerste item. Scheid relevantieselectie van de beslissing of het geselecteerde bewijs voldoende is om de gebruiker te antwoorden.
Editiemigratie De maker beschrijft rerank-3 als een direct inzetbare opvolger van rerank-2.5, met dezelfde API-semantiek en scores die zijn gekalibreerd op de verdeling van de overeenkomstige voorganger. Die compatibiliteit ondersteunt het behoud van een bestaande retrievalfase en registratiekoppeling. Vergelijk betekenisvolle resultaatvolgorden en eventuele scoredrempels op het huidige corpus voordat je op de migratie vertrouwt. Houd rerank-3 en rerank-3-lite als afzonderlijke keuzes: gedeelde limieten en instructievolging maken hun kwaliteits- en latentieprioriteiten niet identiek.
", "aboutText": "Voyage rerank-3 is een tekstreranker die is ontworpen om de kwaliteit van opgehaald bewijsmateriaal te verbeteren. Het onderzoekt bij een zoekvraag en een lijst kandidaatdocumenten elk paar gezamenlijk en geeft de kandidaten op relevantie gerangschikt terug. Embeddings en trefwoordzoeken kunnen een grote collectie eerst tot een beheersbare shortlist beperken; rerank-3 past daarna een gedetailleerdere relevantiebeoordeling op die shortlist toe. De uitvoer is gescoord zoekbewijsmateriaal dat een toepassing kan tonen of doorgeven aan een afzonderlijke stap voor antwoordgeneratie.\n\nRerank 3 met de nadruk op kwaliteit\nDe maker positioneert rerank-3 als de op nauwkeurigheid gerichte editie en rerank-3-lite als de editie voor latentiegevoelige zoekfuncties. De derde generatie vernieuwt de backbone en de trainingsmix, met bijzondere verbeteringen voor retrieval van lange documenten en broncode tegenover de overeenkomstige 2.5-voorgangers. De producent evalueert het model op technische documentatie, code, meertalig materiaal en andere documentdomeinen. Die resultaten ondersteunen de retrievalrol; selecteer de editie op basis van de vragen en kandidaatdocumenten die voor je eigen collectie van belang zijn.\n\nLange documenten met voldoende context\nEen lange kandidaat kan nuttige context bevatten ver voorbij de openingsalinea. Lever een samenhangende sectie of een document aan met de titel en het relevante omringende materiaal, zodat het model kan beoordelen hoe de daadwerkelijke vraag verband houdt met de inhoud. Behoud bij een zoekopdracht naar productbeleid de koppen en uitzonderingen rond de betreffende passage. Als meerdere opgehaalde secties uit dezelfde bron komen, behoud dan hun document- en sectie-identificatoren; de toepassing kan vervolgens tonen waar het geselecteerde bewijs vandaan komt.\n\nHet contextvenster wordt gedeeld door de zoekvraag en elke kandidaat. De huidige gids van de maker specificeert 32.000 tokens voor dat paar, inclusief een zoekvraag van maximaal 8.000 tokens. Een zoekvraag van 3.000 tokens laat dus maximaal 29.000 tokens voor elk document over. Bereid de invoer zo voor dat de essentiële inhoud past, vooral wanneer een lange inleiding of herhaalde standaardtekst anders het venster zou vullen. De gedocumenteerde afkapoptie staat standaard aan en kan te lange zoekvraag- of documenttekst vóór de scoring inkorten. Controleer wat behouden blijft wanneer de plaats van de passage van belang is.\n\nCode en technische retrieval\nVoor de retrievalfase van een programmeerassistent kunnen kandidaten functie-implementaties, API-documentatie of technische uitleg als tekst bevatten. Neem de symbolen, signaturen en context op die nodig zijn om vergelijkbare kandidaten te onderscheiden. Een zoekvraag zoals “Vind de functie die paden normaliseert en daarbij een afsluitend scheidingsteken behoudt” geeft concreet gedrag om op te matchen. Voeg relevante beperkingen voor taal, platform of versie toe. Onderzoek na rangschikking de geselecteerde code en afhankelijkheden voordat je die als context gebruikt; een relevantiescore bewijst niet dat een implementatie aan elke genoemde vereiste voldoet.\n\nInstructies definiëren relevantie\nHet model behoudt de instructievolgende rerankmogelijkheid die in Rerank 2.5 werd geïntroduceerd. Zet een beknopte instructie vóór of achter de zoekvraag wanneer de intentie van de gebruiker verduidelijking nodig heeft. Leg voor zoeken in onderzoeksdocumenten uit of de nadruk ligt op de titel, een specifieke methode of een toepassingsdomein. Specificeer voor een interne catalogus of het verzoek installatie, probleemoplossing of compatibiliteit betreft. Houd die instructie in lijn met de vraag; extra voorkeuren die met het hoofdverzoek botsen, kunnen veranderen wat de rangschikking probeert te optimaliseren.\n\nBereid kandidaatdocumenten en budgetten voor\nDe invoer is een lijst tekststrings. Extraheer bruikbare tekst uit brondocumenten, behoud betekenisvolle sectiegrenzen en houd naast de lijst een geordende registratiekoppeling bij. De maker staat maximaal 1.000 documenten in één verzoek toe. Hij specificeert ook een totale invoerlimiet van 600.000 tokens: zoekvraagtokens vermenigvuldigd met het aantal documenten, plus de som van alle documenttokens. Dit verschilt van de contextlimiet per paar. Het verminderen van overbodige zoekvraagtekst kan zowel paarcapaciteit als het totale verzoekbudget vrijhouden.\n\nTel tokens voor het relevante model in plaats van aan te nemen dat een woord- of tekenaantal een tokenaantal is. Selecteer bij grote kandidaten samenhangende passages of deel het materiaal op bij bruikbare koppen met behoud van informatie over de bovenliggende bron. Reranking is het nuttigst nadat de eerste zoekopdracht al aannemelijke kandidaten heeft gevonden: het kan een ontbrekende bron die nooit in de lijst kwam niet rangschikken.\n\nGerangschikte resultaten en vervolggebruik\nHet resultaat bevat relevantiescores en indices die naar de oorspronkelijke invoerdocumenten verwijzen, gesorteerd op aflopende relevantie. De optie top_k beperkt het aantal teruggegeven gerangschikte resultaten; anders worden alle invoerkandidaten teruggegeven. De REST-interface van de maker laat ook toe dat de documenttekst wordt opgenomen. Gebruik elke oorspronkelijke index om de titel, bronidentificator en eventuele metadata op te halen die de toepassing nodig heeft en presenteer vervolgens de geselecteerde items of neem de relevante tekst op in de bewijscontext van een antwoord.\n\nControleer de bovenste resultaten aan de hand van de vraag en houd de bronidentiteit zichtbaar. Een hoge relatieve positie verifieert niet de feitelijke juistheid van een document en een shortlist met alleen slechte kandidaten heeft nog steeds een eerste item. Scheid relevantieselectie van de beslissing of het geselecteerde bewijs voldoende is om de gebruiker te antwoorden.\n\nEditiemigratie\nDe maker beschrijft rerank-3 als een direct inzetbare opvolger van rerank-2.5, met dezelfde API-semantiek en scores die zijn gekalibreerd op de verdeling van de overeenkomstige voorganger. Die compatibiliteit ondersteunt het behoud van een bestaande retrievalfase en registratiekoppeling. Vergelijk betekenisvolle resultaatvolgorden en eventuele scoredrempels op het huidige corpus voordat je op de migratie vertrouwt. Houd rerank-3 en rerank-3-lite als afzonderlijke keuzes: gedeelde limieten en instructievolging maken hun kwaliteits- en latentieprioriteiten niet identiek.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "aac1a67dae46604d739e764c7547e15854239063af2d5677b53b0350b3aa5bb7", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "nl", "methods": [ { "html": "voyageai/rerank-3Voyage rerank-3 is de op kwaliteit gerichte Rerank 3-editie voor het scoren van zoekvraag-documentrelevantie. Het herschikt opgehaalde tekstkandidaten, ondersteunt relevantie-instructies in natuurlijke taal en verwerkt paren van 32.000 tokens voor zoeken in lange documenten, code en kennisbanken.
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 is een tekstreranker die is ontworpen om de kwaliteit van opgehaald bewijsmateriaal te verbeteren. Het onderzoekt bij een zoekvraag en een lijst kandidaatdocumenten elk paar gezamenlijk en geeft de kandidaten op relevantie gerangschikt terug. Embeddings en trefwoordzoeken kunnen een grote collectie eerst tot een beheersbare shortlist beperken; rerank-3 past daarna een gedetailleerdere relevantiebeoordeling op die shortlist toe. De uitvoer is gescoord zoekbewijsmateriaal dat een toepassing kan tonen of doorgeven aan een afzonderlijke stap voor antwoordgeneratie.
Rerank 3 met de nadruk op kwaliteit De maker positioneert rerank-3 als de op nauwkeurigheid gerichte editie en rerank-3-lite als de editie voor latentiegevoelige zoekfuncties. De derde generatie vernieuwt de backbone en de trainingsmix, met bijzondere verbeteringen voor retrieval van lange documenten en broncode tegenover de overeenkomstige 2.5-voorgangers. De producent evalueert het model op technische documentatie, code, meertalig materiaal en andere documentdomeinen. Die resultaten ondersteunen de retrievalrol; selecteer de editie op basis van de vragen en kandidaatdocumenten die voor je eigen collectie van belang zijn.
Lange documenten met voldoende context Een lange kandidaat kan nuttige context bevatten ver voorbij de openingsalinea. Lever een samenhangende sectie of een document aan met de titel en het relevante omringende materiaal, zodat het model kan beoordelen hoe de daadwerkelijke vraag verband houdt met de inhoud. Behoud bij een zoekopdracht naar productbeleid de koppen en uitzonderingen rond de betreffende passage. Als meerdere opgehaalde secties uit dezelfde bron komen, behoud dan hun document- en sectie-identificatoren; de toepassing kan vervolgens tonen waar het geselecteerde bewijs vandaan komt.
Het contextvenster wordt gedeeld door de zoekvraag en elke kandidaat. De huidige gids van de maker specificeert 32.000 tokens voor dat paar, inclusief een zoekvraag van maximaal 8.000 tokens. Een zoekvraag van 3.000 tokens laat dus maximaal 29.000 tokens voor elk document over. Bereid de invoer zo voor dat de essentiële inhoud past, vooral wanneer een lange inleiding of herhaalde standaardtekst anders het venster zou vullen. De gedocumenteerde afkapoptie staat standaard aan en kan te lange zoekvraag- of documenttekst vóór de scoring inkorten. Controleer wat behouden blijft wanneer de plaats van de passage van belang is.
Code en technische retrieval Voor de retrievalfase van een programmeerassistent kunnen kandidaten functie-implementaties, API-documentatie of technische uitleg als tekst bevatten. Neem de symbolen, signaturen en context op die nodig zijn om vergelijkbare kandidaten te onderscheiden. Een zoekvraag zoals “Vind de functie die paden normaliseert en daarbij een afsluitend scheidingsteken behoudt” geeft concreet gedrag om op te matchen. Voeg relevante beperkingen voor taal, platform of versie toe. Onderzoek na rangschikking de geselecteerde code en afhankelijkheden voordat je die als context gebruikt; een relevantiescore bewijst niet dat een implementatie aan elke genoemde vereiste voldoet.
Instructies definiëren relevantie Het model behoudt de instructievolgende rerankmogelijkheid die in Rerank 2.5 werd geïntroduceerd. Zet een beknopte instructie vóór of achter de zoekvraag wanneer de intentie van de gebruiker verduidelijking nodig heeft. Leg voor zoeken in onderzoeksdocumenten uit of de nadruk ligt op de titel, een specifieke methode of een toepassingsdomein. Specificeer voor een interne catalogus of het verzoek installatie, probleemoplossing of compatibiliteit betreft. Houd die instructie in lijn met de vraag; extra voorkeuren die met het hoofdverzoek botsen, kunnen veranderen wat de rangschikking probeert te optimaliseren.
Bereid kandidaatdocumenten en budgetten voor De invoer is een lijst tekststrings. Extraheer bruikbare tekst uit brondocumenten, behoud betekenisvolle sectiegrenzen en houd naast de lijst een geordende registratiekoppeling bij. De maker staat maximaal 1.000 documenten in één verzoek toe. Hij specificeert ook een totale invoerlimiet van 600.000 tokens: zoekvraagtokens vermenigvuldigd met het aantal documenten, plus de som van alle documenttokens. Dit verschilt van de contextlimiet per paar. Het verminderen van overbodige zoekvraagtekst kan zowel paarcapaciteit als het totale verzoekbudget vrijhouden.
Tel tokens voor het relevante model in plaats van aan te nemen dat een woord- of tekenaantal een tokenaantal is. Selecteer bij grote kandidaten samenhangende passages of deel het materiaal op bij bruikbare koppen met behoud van informatie over de bovenliggende bron. Reranking is het nuttigst nadat de eerste zoekopdracht al aannemelijke kandidaten heeft gevonden: het kan een ontbrekende bron die nooit in de lijst kwam niet rangschikken.
Gerangschikte resultaten en vervolggebruik Het resultaat bevat relevantiescores en indices die naar de oorspronkelijke invoerdocumenten verwijzen, gesorteerd op aflopende relevantie. De optie top_k beperkt het aantal teruggegeven gerangschikte resultaten; anders worden alle invoerkandidaten teruggegeven. De REST-interface van de maker laat ook toe dat de documenttekst wordt opgenomen. Gebruik elke oorspronkelijke index om de titel, bronidentificator en eventuele metadata op te halen die de toepassing nodig heeft en presenteer vervolgens de geselecteerde items of neem de relevante tekst op in de bewijscontext van een antwoord.
Controleer de bovenste resultaten aan de hand van de vraag en houd de bronidentiteit zichtbaar. Een hoge relatieve positie verifieert niet de feitelijke juistheid van een document en een shortlist met alleen slechte kandidaten heeft nog steeds een eerste item. Scheid relevantieselectie van de beslissing of het geselecteerde bewijs voldoende is om de gebruiker te antwoorden.
Editiemigratie De maker beschrijft rerank-3 als een direct inzetbare opvolger van rerank-2.5, met dezelfde API-semantiek en scores die zijn gekalibreerd op de verdeling van de overeenkomstige voorganger. Die compatibiliteit ondersteunt het behoud van een bestaande retrievalfase en registratiekoppeling. Vergelijk betekenisvolle resultaatvolgorden en eventuele scoredrempels op het huidige corpus voordat je op de migratie vertrouwt. Houd rerank-3 en rerank-3-lite als afzonderlijke keuzes: gedeelde limieten en instructievolging maken hun kwaliteits- en latentieprioriteiten niet identiek.
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 | 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.0001 / 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",\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
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
Gebruik de hierboven getoonde methodepaden.