Voyage rerank-3 er en omrangeringsmodell for tekst som er utviklet for å forbedre kvaliteten på innhentet belegg. Gitt en spørring og en liste over kandidatdokumenter undersøker den hvert par samlet og returnerer kandidatene ordnet etter relevans. Embeddings og nøkkelordsøk kan først avgrense en stor samling til en håndterbar kortliste; rerank-3 anvender deretter en mer detaljert relevansvurdering på denne kortlisten. Utdataene er skåret søkebelegg som en applikasjon kan vise eller sende inn i et separat trinn for svargenerering.
Kvalitetsorientert Rerank 3 Produsenten posisjonerer rerank-3 som den nøyaktighetsorienterte utgaven og rerank-3-lite som utgaven for søk som er følsomme for latenstid. Tredje generasjon oppdaterer grunnarkitekturen og treningsblandingen, med særlig forbedring i innhenting fra lange dokumenter og kildekode sammenlignet med de tilsvarende 2.5-forgjengerne. Produsenten evaluerer modellen på tvers av teknisk dokumentasjon, kode, flerspråklig materiale og andre dokumentdomener. Disse resultatene støtter innhentingsrollen; velg utgave ut fra spørsmålene og kandidatdokumentene som er viktige for din egen samling.
Lange dokumenter med nok kontekst En lang kandidat kan inneholde nyttig kontekst langt utover åpningsavsnittet. Gi en sammenhengende del eller et dokument med tittel og relevant omkringliggende materiale, slik at modellen kan vurdere hvordan det faktiske spørsmålet er knyttet til innholdet. For søk i produktretningslinjer bevarer du overskrifter og unntak rundt tekstutdraget av interesse. Hvis flere innhentede deler kommer fra samme kilde, beholder du dokument- og delidentifikatorene; applikasjonen kan da vise hvor det valgte belegget kom fra.
Kontekstvinduet deles av spørringen og hver kandidat. Produsentens nåværende veiledning angir 32 000 tokener for dette paret, inkludert en spørring på maksimalt 8 000 tokener. En spørring på 3 000 tokener gir derfor plass til maksimalt 29 000 tokener for hvert dokument. Forbered inndataene slik at det vesentlige innholdet får plass, særlig når en lang innledning eller gjentatt standardtekst ellers ville brukt opp vinduet. Det dokumenterte avkortingsvalget er aktivert som standard og kan forkorte for stor spørrings- eller dokumenttekst før skåring. Undersøk hva som beholdes når plasseringen av tekstutdraget er viktig.
Innhenting av kode og teknisk materiale For innhentingstrinnet i en kodeassistent kan kandidatene inneholde funksjonsimplementasjoner, API-dokumentasjon eller tekniske forklaringer som tekst. Ta med symbolene, signaturene og konteksten som trengs for å skille lignende kandidater. En spørring som «Finn funksjonen som normaliserer stier og samtidig bevarer et avsluttende skilletegn» gir en konkret oppførsel å finne samsvar med. Legg til eventuelle relevante språk-, plattform- eller versjonsbegrensninger. Etter rangering undersøker du den valgte koden og avhengighetene dens før du bruker den som kontekst; en relevansskår beviser ikke at en implementasjon oppfyller alle angitte krav.
Instruksjoner definerer relevans Modellen beholder den instruksjonsfølgende omrangeringsegenskapen som ble innført i Rerank 2.5. Legg en kort instruksjon før eller etter spørringen når brukerens intensjon trenger presisering. For søk i forskningsdokumenter forklarer du om fokuset er tittelen, en bestemt metode eller et bruksdomene. For en intern katalog angir du om forespørselen gjelder installasjon, feilsøking eller kompatibilitet. Hold denne instruksjonen i samsvar med spørsmålet; ekstra preferanser som strider mot hovedforespørselen, kan endre hva rangeringen prøver å optimalisere.
Forbered kandidatdokumenter og budsjetter Inndataene er en liste med tekststrenger. Hent ut brukbar tekst fra kildedokumenter, bevar meningsfulle delgrenser og hold en ordnet kobling til oppføringer ved siden av listen. Produsenten tillater opptil 1000 dokumenter i én forespørsel. Den angir også en samlet inndatagrense på 600 000 tokener: spørringstokener multiplisert med antall dokumenter, pluss summen av alle dokumenttokener. Dette skiller seg fra kontekstgrensen per par. Å redusere overflødig spørringstekst kan bevare både parkapasitet og det samlede forespørselsbudsjettet.
Tell tokener for den relevante modellen, fremfor å anta at et ord- eller tegnantall er et tokenantall. For store kandidater velger du sammenhengende tekstutdrag eller deler materialet etter nyttige overskrifter, samtidig som informasjon om overordnet kilde bevares. Omrangering er mest nyttig etter at det første søket allerede har funnet plausible kandidater: den kan ikke rangere en manglende kilde som aldri kom inn på listen.
Rangerte resultater og videre bruk Resultatet inneholder relevansskårer og indekser som viser til de opprinnelige inndatadokumentene, sortert i synkende relevansrekkefølge. Valget top_k begrenser antall rangerte resultater som returneres; ellers returneres alle inndatakandidater. Produsentens REST-grensesnitt tillater også at dokumentteksten tas med. Bruk hver opprinnelige indeks til å hente tittel, kildeidentifikator og eventuelle metadata applikasjonen trenger, og presenter deretter de valgte elementene eller legg den relevante teksten inn i belegget for et svar.
Undersøk toppresultatene opp mot spørsmålet, og hold kildeidentiteten synlig. En høy relativ rangering bekrefter ikke et dokuments faktiske korrekthet, og en kortliste med bare dårlige kandidater vil fortsatt ha et første element. Skill relevansutvelgelse fra avgjørelsen om det valgte belegget er tilstrekkelig til å besvare brukeren.
Bytte av utgave Produsenten beskriver rerank-3 som en direkte erstatning for rerank-2.5, med samme API-semantikk og skårer kalibrert til fordelingen hos den tilsvarende forgjengeren. Denne kompatibiliteten støtter å beholde et eksisterende innhentingstrinn og koblingen til oppføringer. Sammenlign meningsfulle resultatrekkefølger og eventuelle skårgrenser på det aktuelle korpuset før du stoler på byttet. Hold rerank-3 og rerank-3-lite som separate valg: felles grenser og instruksjonsfølging gjør ikke prioriteringene deres for kvalitet og latenstid identiske.
", "aboutText": "Voyage rerank-3 er en omrangeringsmodell for tekst som er utviklet for å forbedre kvaliteten på innhentet belegg. Gitt en spørring og en liste over kandidatdokumenter undersøker den hvert par samlet og returnerer kandidatene ordnet etter relevans. Embeddings og nøkkelordsøk kan først avgrense en stor samling til en håndterbar kortliste; rerank-3 anvender deretter en mer detaljert relevansvurdering på denne kortlisten. Utdataene er skåret søkebelegg som en applikasjon kan vise eller sende inn i et separat trinn for svargenerering.\n\nKvalitetsorientert Rerank 3\nProdusenten posisjonerer rerank-3 som den nøyaktighetsorienterte utgaven og rerank-3-lite som utgaven for søk som er følsomme for latenstid. Tredje generasjon oppdaterer grunnarkitekturen og treningsblandingen, med særlig forbedring i innhenting fra lange dokumenter og kildekode sammenlignet med de tilsvarende 2.5-forgjengerne. Produsenten evaluerer modellen på tvers av teknisk dokumentasjon, kode, flerspråklig materiale og andre dokumentdomener. Disse resultatene støtter innhentingsrollen; velg utgave ut fra spørsmålene og kandidatdokumentene som er viktige for din egen samling.\n\nLange dokumenter med nok kontekst\nEn lang kandidat kan inneholde nyttig kontekst langt utover åpningsavsnittet. Gi en sammenhengende del eller et dokument med tittel og relevant omkringliggende materiale, slik at modellen kan vurdere hvordan det faktiske spørsmålet er knyttet til innholdet. For søk i produktretningslinjer bevarer du overskrifter og unntak rundt tekstutdraget av interesse. Hvis flere innhentede deler kommer fra samme kilde, beholder du dokument- og delidentifikatorene; applikasjonen kan da vise hvor det valgte belegget kom fra.\n\nKontekstvinduet deles av spørringen og hver kandidat. Produsentens nåværende veiledning angir 32 000 tokener for dette paret, inkludert en spørring på maksimalt 8 000 tokener. En spørring på 3 000 tokener gir derfor plass til maksimalt 29 000 tokener for hvert dokument. Forbered inndataene slik at det vesentlige innholdet får plass, særlig når en lang innledning eller gjentatt standardtekst ellers ville brukt opp vinduet. Det dokumenterte avkortingsvalget er aktivert som standard og kan forkorte for stor spørrings- eller dokumenttekst før skåring. Undersøk hva som beholdes når plasseringen av tekstutdraget er viktig.\n\nInnhenting av kode og teknisk materiale\nFor innhentingstrinnet i en kodeassistent kan kandidatene inneholde funksjonsimplementasjoner, API-dokumentasjon eller tekniske forklaringer som tekst. Ta med symbolene, signaturene og konteksten som trengs for å skille lignende kandidater. En spørring som «Finn funksjonen som normaliserer stier og samtidig bevarer et avsluttende skilletegn» gir en konkret oppførsel å finne samsvar med. Legg til eventuelle relevante språk-, plattform- eller versjonsbegrensninger. Etter rangering undersøker du den valgte koden og avhengighetene dens før du bruker den som kontekst; en relevansskår beviser ikke at en implementasjon oppfyller alle angitte krav.\n\nInstruksjoner definerer relevans\nModellen beholder den instruksjonsfølgende omrangeringsegenskapen som ble innført i Rerank 2.5. Legg en kort instruksjon før eller etter spørringen når brukerens intensjon trenger presisering. For søk i forskningsdokumenter forklarer du om fokuset er tittelen, en bestemt metode eller et bruksdomene. For en intern katalog angir du om forespørselen gjelder installasjon, feilsøking eller kompatibilitet. Hold denne instruksjonen i samsvar med spørsmålet; ekstra preferanser som strider mot hovedforespørselen, kan endre hva rangeringen prøver å optimalisere.\n\nForbered kandidatdokumenter og budsjetter\nInndataene er en liste med tekststrenger. Hent ut brukbar tekst fra kildedokumenter, bevar meningsfulle delgrenser og hold en ordnet kobling til oppføringer ved siden av listen. Produsenten tillater opptil 1000 dokumenter i én forespørsel. Den angir også en samlet inndatagrense på 600 000 tokener: spørringstokener multiplisert med antall dokumenter, pluss summen av alle dokumenttokener. Dette skiller seg fra kontekstgrensen per par. Å redusere overflødig spørringstekst kan bevare både parkapasitet og det samlede forespørselsbudsjettet.\n\nTell tokener for den relevante modellen, fremfor å anta at et ord- eller tegnantall er et tokenantall. For store kandidater velger du sammenhengende tekstutdrag eller deler materialet etter nyttige overskrifter, samtidig som informasjon om overordnet kilde bevares. Omrangering er mest nyttig etter at det første søket allerede har funnet plausible kandidater: den kan ikke rangere en manglende kilde som aldri kom inn på listen.\n\nRangerte resultater og videre bruk\nResultatet inneholder relevansskårer og indekser som viser til de opprinnelige inndatadokumentene, sortert i synkende relevansrekkefølge. Valget top_k begrenser antall rangerte resultater som returneres; ellers returneres alle inndatakandidater. Produsentens REST-grensesnitt tillater også at dokumentteksten tas med. Bruk hver opprinnelige indeks til å hente tittel, kildeidentifikator og eventuelle metadata applikasjonen trenger, og presenter deretter de valgte elementene eller legg den relevante teksten inn i belegget for et svar.\n\nUndersøk toppresultatene opp mot spørsmålet, og hold kildeidentiteten synlig. En høy relativ rangering bekrefter ikke et dokuments faktiske korrekthet, og en kortliste med bare dårlige kandidater vil fortsatt ha et første element. Skill relevansutvelgelse fra avgjørelsen om det valgte belegget er tilstrekkelig til å besvare brukeren.\n\nBytte av utgave\nProdusenten beskriver rerank-3 som en direkte erstatning for rerank-2.5, med samme API-semantikk og skårer kalibrert til fordelingen hos den tilsvarende forgjengeren. Denne kompatibiliteten støtter å beholde et eksisterende innhentingstrinn og koblingen til oppføringer. Sammenlign meningsfulle resultatrekkefølger og eventuelle skårgrenser på det aktuelle korpuset før du stoler på byttet. Hold rerank-3 og rerank-3-lite som separate valg: felles grenser og instruksjonsfølging gjør ikke prioriteringene deres for kvalitet og latenstid identiske.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "36192bff7de0a0f7629344120d2f81882627806f7f3a92dd9f78e0025076bd69", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "nb", "methods": [ { "html": "voyageai/rerank-3Voyage rerank-3 er den kvalitetsorienterte Rerank 3-utgaven for skåring av spørring–dokument-relevans. Den omordner innhentede tekstkandidater, støtter relevansinstruksjoner på naturlig språk og håndterer par på 32 000 tokener for søk i lange dokumenter, kode og kunnskapsbaser.
Denne beskrivelsen dekker modellens funksjoner. Tilgjengelige inndata, utdata og alternativer i Ailoot er oppført nedenfor for den valgte metoden.
Voyage rerank-3 er en omrangeringsmodell for tekst som er utviklet for å forbedre kvaliteten på innhentet belegg. Gitt en spørring og en liste over kandidatdokumenter undersøker den hvert par samlet og returnerer kandidatene ordnet etter relevans. Embeddings og nøkkelordsøk kan først avgrense en stor samling til en håndterbar kortliste; rerank-3 anvender deretter en mer detaljert relevansvurdering på denne kortlisten. Utdataene er skåret søkebelegg som en applikasjon kan vise eller sende inn i et separat trinn for svargenerering.
Kvalitetsorientert Rerank 3 Produsenten posisjonerer rerank-3 som den nøyaktighetsorienterte utgaven og rerank-3-lite som utgaven for søk som er følsomme for latenstid. Tredje generasjon oppdaterer grunnarkitekturen og treningsblandingen, med særlig forbedring i innhenting fra lange dokumenter og kildekode sammenlignet med de tilsvarende 2.5-forgjengerne. Produsenten evaluerer modellen på tvers av teknisk dokumentasjon, kode, flerspråklig materiale og andre dokumentdomener. Disse resultatene støtter innhentingsrollen; velg utgave ut fra spørsmålene og kandidatdokumentene som er viktige for din egen samling.
Lange dokumenter med nok kontekst En lang kandidat kan inneholde nyttig kontekst langt utover åpningsavsnittet. Gi en sammenhengende del eller et dokument med tittel og relevant omkringliggende materiale, slik at modellen kan vurdere hvordan det faktiske spørsmålet er knyttet til innholdet. For søk i produktretningslinjer bevarer du overskrifter og unntak rundt tekstutdraget av interesse. Hvis flere innhentede deler kommer fra samme kilde, beholder du dokument- og delidentifikatorene; applikasjonen kan da vise hvor det valgte belegget kom fra.
Kontekstvinduet deles av spørringen og hver kandidat. Produsentens nåværende veiledning angir 32 000 tokener for dette paret, inkludert en spørring på maksimalt 8 000 tokener. En spørring på 3 000 tokener gir derfor plass til maksimalt 29 000 tokener for hvert dokument. Forbered inndataene slik at det vesentlige innholdet får plass, særlig når en lang innledning eller gjentatt standardtekst ellers ville brukt opp vinduet. Det dokumenterte avkortingsvalget er aktivert som standard og kan forkorte for stor spørrings- eller dokumenttekst før skåring. Undersøk hva som beholdes når plasseringen av tekstutdraget er viktig.
Innhenting av kode og teknisk materiale For innhentingstrinnet i en kodeassistent kan kandidatene inneholde funksjonsimplementasjoner, API-dokumentasjon eller tekniske forklaringer som tekst. Ta med symbolene, signaturene og konteksten som trengs for å skille lignende kandidater. En spørring som «Finn funksjonen som normaliserer stier og samtidig bevarer et avsluttende skilletegn» gir en konkret oppførsel å finne samsvar med. Legg til eventuelle relevante språk-, plattform- eller versjonsbegrensninger. Etter rangering undersøker du den valgte koden og avhengighetene dens før du bruker den som kontekst; en relevansskår beviser ikke at en implementasjon oppfyller alle angitte krav.
Instruksjoner definerer relevans Modellen beholder den instruksjonsfølgende omrangeringsegenskapen som ble innført i Rerank 2.5. Legg en kort instruksjon før eller etter spørringen når brukerens intensjon trenger presisering. For søk i forskningsdokumenter forklarer du om fokuset er tittelen, en bestemt metode eller et bruksdomene. For en intern katalog angir du om forespørselen gjelder installasjon, feilsøking eller kompatibilitet. Hold denne instruksjonen i samsvar med spørsmålet; ekstra preferanser som strider mot hovedforespørselen, kan endre hva rangeringen prøver å optimalisere.
Forbered kandidatdokumenter og budsjetter Inndataene er en liste med tekststrenger. Hent ut brukbar tekst fra kildedokumenter, bevar meningsfulle delgrenser og hold en ordnet kobling til oppføringer ved siden av listen. Produsenten tillater opptil 1000 dokumenter i én forespørsel. Den angir også en samlet inndatagrense på 600 000 tokener: spørringstokener multiplisert med antall dokumenter, pluss summen av alle dokumenttokener. Dette skiller seg fra kontekstgrensen per par. Å redusere overflødig spørringstekst kan bevare både parkapasitet og det samlede forespørselsbudsjettet.
Tell tokener for den relevante modellen, fremfor å anta at et ord- eller tegnantall er et tokenantall. For store kandidater velger du sammenhengende tekstutdrag eller deler materialet etter nyttige overskrifter, samtidig som informasjon om overordnet kilde bevares. Omrangering er mest nyttig etter at det første søket allerede har funnet plausible kandidater: den kan ikke rangere en manglende kilde som aldri kom inn på listen.
Rangerte resultater og videre bruk Resultatet inneholder relevansskårer og indekser som viser til de opprinnelige inndatadokumentene, sortert i synkende relevansrekkefølge. Valget top_k begrenser antall rangerte resultater som returneres; ellers returneres alle inndatakandidater. Produsentens REST-grensesnitt tillater også at dokumentteksten tas med. Bruk hver opprinnelige indeks til å hente tittel, kildeidentifikator og eventuelle metadata applikasjonen trenger, og presenter deretter de valgte elementene eller legg den relevante teksten inn i belegget for et svar.
Undersøk toppresultatene opp mot spørsmålet, og hold kildeidentiteten synlig. En høy relativ rangering bekrefter ikke et dokuments faktiske korrekthet, og en kortliste med bare dårlige kandidater vil fortsatt ha et første element. Skill relevansutvelgelse fra avgjørelsen om det valgte belegget er tilstrekkelig til å besvare brukeren.
Bytte av utgave Produsenten beskriver rerank-3 som en direkte erstatning for rerank-2.5, med samme API-semantikk og skårer kalibrert til fordelingen hos den tilsvarende forgjengeren. Denne kompatibiliteten støtter å beholde et eksisterende innhentingstrinn og koblingen til oppføringer. Sammenlign meningsfulle resultatrekkefølger og eventuelle skårgrenser på det aktuelle korpuset før du stoler på byttet. Hold rerank-3 og rerank-3-lite som separate valg: felles grenser og instruksjonsfølging gjør ikke prioriteringene deres for kvalitet og latenstid identiske.
POST /v1/reranktextrerank| Felt | Type | Krav | Verdier & grenser | Standard |
|---|---|---|---|---|
Feltdocuments | Typearray | KravPåkrevd | Verdier & grenser | Standard— |
Feltmodel | Typestring | KravPåkrevd | Verdier & grenser voyageai/rerank-3 | Standard— |
Feltprovider | Typeschema | KravValgfritt | Verdier & grenser | Standard— |
Feltquery | Typestring | KravPåkrevd | Verdier & grenser | Standard— |
Feltsession_id | Typestring | KravValgfritt | Verdier & grenser | Standard— |
Felttop_n | Typeinteger | KravValgfritt | Verdier & grenser Minimum: 1 | Standard— |
Felttrace | Typeschema | KravValgfritt | Verdier & grenser | Standard— |
Feltuser | Typestring | KravValgfritt | Verdier & grenser | Standard— |
Feltdocuments[].text | Typestring | KravValgfritt | Verdier & grenser | Standard— |
Feltdocuments[].image | Typestring | KravValgfritt | Verdier & grenser | Standard— |
text_rerank · Påkrevd: query, documents array with minItems1
| Parameter | Avtale |
|---|---|
Parametercontent_type | Avtaleapplication/json |
Parameterrequired | Avtalemodel, query, documents |
Parametermaterial_types | Avtaletext |
Parameteroptional_controls | Avtaleprovider, session_id, top_n, trace, user |
Parametermultimodal_input_binding | Avtalenull |
Livssyklus: synchronous
Send den eksakte modell-ID-en og behold hele svaret i det opprinnelige formatet.
Tariffopplysninger legger ikke til forespørselsvalg. Støttede parametere står ved den valgte metoden.
Knytt hver kostnad til de viste vilkårene. Bruk én sats for hvert sett med alternative konfigurasjoner.
| Konfigurasjon | Prisplan | Faktureringsenhet | Kostnad |
|---|---|---|---|
| KonfigurasjonGrunnpriser for tokener | PrisplanGrunnsats | Faktureringsenhet— | Kostnad Inndata · Inngående tokener — / 1K tokener Utdata · Utgående tokener — / 1K tokener Inndata · Lesing fra hurtigbuffer — / 1K tokener Inndata · Skriving til hurtigbuffer — / 1K tokener Inndata · Skriving til hurtigbuffer, 1 time — / 1K tokener |
| KonfigurasjonUltra | Prisplan— | Faktureringsenhet/ 1K tokener | Kostnad Inndata $0.0001 / 1K tokener |
Ailoot reserverer et estimert beløp før en forespørsel. Etter resultatet gjøres det endelige beløpet opp basert på målt forbruk. Oppgjør for strømming bruker den endelige forbruksposten. Slik fungerer reservasjon og oppgjør →
{\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
Behold alle fullstendige returnerte svar, filer og innholdsdeler.
Alle faktiske resultatindekser, alle endelige relevance_score-verdier og de opprinnelige dokumentobjektene bevares. Indeksene knytter resultatene til den opprinnelige dokumentmatrisen. Hele det opprinnelige JSON-svaret lagres og returneres først etter oppgjør.
Behold den opprinnelige operasjonen og hele eller deler av svaret; ikke gjenta 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 | Vilkår | Neste trinn |
|---|---|---|
Svar400 · invalid_request_error | VilkårUgyldig påkrevd felt, representasjon eller verdi | Neste trinnKorriger det angitte forespørselsfeltet. |
Ailoot Ultra voyageai/rerank-3
Bruk metodestiene som vises ovenfor.