Upstage Solar Decide er en strukturert beslutningsmodell bygget på Solar Mini 4. Den leser en innsendt tilstand og typede spørsmål og returnerer deretter en beslutning for hvert spørsmål med kalibrert sannsynlighetsinformasjon. Produsenten beskriver en beslutningsprosess i én fremoverpassering som ikke genererer prosa. De tilsiktede bruksområdene omfatter ruting, klassifisering og regelkontroller, med modellens koreanskforståelse fremhevet som en del av Solar Mini 4-grunnlaget.
Forbered tilstanden som en streng eller strukturert JSON som beskriver faktaene som skal vurderes. Produsentens grensesnitt serialiserer JSON-verdier inn i prompten. Et spørsmålsskjema definerer separat hva som skal avgjøres, hvilke alternativer som er tillatt, og hvordan en ordnet vurdering skal tolkes. Bruk stabile navn på spørsmålene: Svarene returneres under de samme navnene, slik at resultatet enkelt kan knyttes til den opprinnelige betingelsen i arbeidsflyten. Hold den faktiske tilstanden atskilt fra instruksjonene og kriteriene som definerer beslutningen.
De tre spørsmålstypene har ulike resultater. Et choice-spørsmål returnerer det valgte alternativet, sannsynligheter på tvers av de navngitte alternativene og en konfidensverdi. Et noul-spørsmål returnerer sannsynligheten for at en ja/nei-betingelse er sann. Et score-spørsmål returnerer en sannsynlighetsvektet skår, en indeksert tegnforklaring, sannsynligheter og konfidens. En ordnet skår kan ha desimaler fordi den gjenspeiler fordelingen over kriteriene. Behold disse feltene fremfor å redusere alle resultater til en ren etikett eller behandle konfidens som en forklarende setning.
For supportruting sender du inn den faktiske meldingen og relevant historikk og stiller deretter separate spørsmål om intensjon, hastegrad og en definert betingelse, som om meldingen uttrykker misnøye. Beskriv kategoriene etter betydning og gi hasteskalaen en bevisst rekkefølge. Et eksempelskjema kan skille mellom en forespørsel om leveringsstatus, et problem med kontotilgang og et uvedkommende problem, mens hastekriteriene går fra ingen umiddelbar handling til umiddelbar gjennomgang. Det observerbare resultatet er en typet vurdering av disse valgene, ikke et utkast til svar til kunden.
For regelkontroller inkluderer du den relevante regelen og faktaene i posten sammen i tilstanden. Definer hver betingelse snevert nok til at svaret kan undersøkes. En dokumentarbeidsflyt kan spørre om nødvendig informasjon er til stede, hvilken gjennomgangskategori som gjelder, og hvor sterkt posten oppfyller en ordnet fullstendighetsstandard. En skår eller sannsynlighet bekrefter ikke faktaene i posten uavhengig. Hvis avgjørende informasjon mangler, trenger applikasjonen en bevisst behandling av usikkerheten fremfor å tolke et valgt alternativ som avgjørende bevis.
Produsenten oppgir et kontekstvindu på 512K tokener for Solar Decide. Forbered store dokumenter som teksten eller den strukturerte tilstanden beslutningen krever; en stor kontekst innebærer ikke automatisk parsing av en vilkårlig fil. Bevar kildegrenser og passasjene som er relevante for kriteriene. Bruk fokuserte spørsmål fremfor å forvente et åpent sammendrag av dokumentet. Modellens resultat forblir avgrenset av spørsmålstypene og alternativene, uansett hvor mye materiale som inngår i tilstanden.
Et choice-spørsmål godtar to til 26 alternativer i det dokumenterte produsentgrensesnittet. Produsenten forklarer at denne ruten leser beslutninger fra enkelttokenetikettene A til Z, så mer enn 26 kandidater må snevres inn eller deles i flere spørsmål. Grensen gjelder choice-alternativer, ikke en generell grense for dokumentlengde eller en grense kopiert fra en annen beslutningsmodellfamilie. Definer kandidatbeskrivelser slik at betydningene er ulike, og bruk en hierarkisk beslutning bare når hierarkiet samsvarer med den faktiske arbeidsflyten.
For koreanskspråklige poster bevarer du kildebetydningen, navnene og identifikatorene intakte og beskriver beslutningskriteriene tydelig. Det typede resultatet kan bruke stabile applikasjonsetiketter mens det vurderer evidens i naturlig språk. Når en post blander språk eller bruker fagterminologi, behold de relevante definisjonene i tilstanden. En flytende tolkning av en term er ikke nok til å fastslå at klassifiseringskriteriene stemmer med forretningsregelen, så undersøk representative tvetydige tilfeller i tillegg til enkle tilfeller.
Bruk de returnerte sannsynlighetene og konfidensen etter arbeidsflytens beslutningspolicy. Bevar fordelingen og den ordnede tegnforklaringen når en vurdering ligger mellom kategorier. Fastsett behandlingen av usikre resultater fra gjennomgåtte oppgaveeksempler fremfor å finne på en universell sannsynlighetsterskel. Applikasjonen utfører eventuell resulterende ruting, eskalering eller gjennomgang og registrerer utfallet. Solar Decide gir den avgrensede modellvurderingen som brukes til å overveie handlingen; å velge en rute fastslår ikke at en senere handling ble utført.
Det nyttige sluttproduktet er answers-objektet sammen med tilstanden og spørsmålsdefinisjonene som frembrakte det. Disse postene gjør det mulig å undersøke en overraskende klassifisering, skille manglende evidens fra tvetydige kriterier og sammenligne vurderingen med et gjennomgått tilfelle. Hvis en bruker trenger en skriftlig forklaring eller et samtalesvar, kan beslutningen og kildematerialet gå inn i et separat skrivetrinn. Solar Decides spesifikke rolle er å produsere typede beslutninger med sannsynlighetsgrunnlag fra innsendt tekst, fremfor å generere forklaringen selv.
", "aboutText": "Upstage Solar Decide er en strukturert beslutningsmodell bygget på Solar Mini 4. Den leser en innsendt tilstand og typede spørsmål og returnerer deretter en beslutning for hvert spørsmål med kalibrert sannsynlighetsinformasjon. Produsenten beskriver en beslutningsprosess i én fremoverpassering som ikke genererer prosa. De tilsiktede bruksområdene omfatter ruting, klassifisering og regelkontroller, med modellens koreanskforståelse fremhevet som en del av Solar Mini 4-grunnlaget.\n\nForbered tilstanden som en streng eller strukturert JSON som beskriver faktaene som skal vurderes. Produsentens grensesnitt serialiserer JSON-verdier inn i prompten. Et spørsmålsskjema definerer separat hva som skal avgjøres, hvilke alternativer som er tillatt, og hvordan en ordnet vurdering skal tolkes. Bruk stabile navn på spørsmålene: Svarene returneres under de samme navnene, slik at resultatet enkelt kan knyttes til den opprinnelige betingelsen i arbeidsflyten. Hold den faktiske tilstanden atskilt fra instruksjonene og kriteriene som definerer beslutningen.\n\nDe tre spørsmålstypene har ulike resultater. Et choice-spørsmål returnerer det valgte alternativet, sannsynligheter på tvers av de navngitte alternativene og en konfidensverdi. Et noul-spørsmål returnerer sannsynligheten for at en ja/nei-betingelse er sann. Et score-spørsmål returnerer en sannsynlighetsvektet skår, en indeksert tegnforklaring, sannsynligheter og konfidens. En ordnet skår kan ha desimaler fordi den gjenspeiler fordelingen over kriteriene. Behold disse feltene fremfor å redusere alle resultater til en ren etikett eller behandle konfidens som en forklarende setning.\n\nFor supportruting sender du inn den faktiske meldingen og relevant historikk og stiller deretter separate spørsmål om intensjon, hastegrad og en definert betingelse, som om meldingen uttrykker misnøye. Beskriv kategoriene etter betydning og gi hasteskalaen en bevisst rekkefølge. Et eksempelskjema kan skille mellom en forespørsel om leveringsstatus, et problem med kontotilgang og et uvedkommende problem, mens hastekriteriene går fra ingen umiddelbar handling til umiddelbar gjennomgang. Det observerbare resultatet er en typet vurdering av disse valgene, ikke et utkast til svar til kunden.\n\nFor regelkontroller inkluderer du den relevante regelen og faktaene i posten sammen i tilstanden. Definer hver betingelse snevert nok til at svaret kan undersøkes. En dokumentarbeidsflyt kan spørre om nødvendig informasjon er til stede, hvilken gjennomgangskategori som gjelder, og hvor sterkt posten oppfyller en ordnet fullstendighetsstandard. En skår eller sannsynlighet bekrefter ikke faktaene i posten uavhengig. Hvis avgjørende informasjon mangler, trenger applikasjonen en bevisst behandling av usikkerheten fremfor å tolke et valgt alternativ som avgjørende bevis.\n\nProdusenten oppgir et kontekstvindu på 512K tokener for Solar Decide. Forbered store dokumenter som teksten eller den strukturerte tilstanden beslutningen krever; en stor kontekst innebærer ikke automatisk parsing av en vilkårlig fil. Bevar kildegrenser og passasjene som er relevante for kriteriene. Bruk fokuserte spørsmål fremfor å forvente et åpent sammendrag av dokumentet. Modellens resultat forblir avgrenset av spørsmålstypene og alternativene, uansett hvor mye materiale som inngår i tilstanden.\n\nEt choice-spørsmål godtar to til 26 alternativer i det dokumenterte produsentgrensesnittet. Produsenten forklarer at denne ruten leser beslutninger fra enkelttokenetikettene A til Z, så mer enn 26 kandidater må snevres inn eller deles i flere spørsmål. Grensen gjelder choice-alternativer, ikke en generell grense for dokumentlengde eller en grense kopiert fra en annen beslutningsmodellfamilie. Definer kandidatbeskrivelser slik at betydningene er ulike, og bruk en hierarkisk beslutning bare når hierarkiet samsvarer med den faktiske arbeidsflyten.\n\nFor koreanskspråklige poster bevarer du kildebetydningen, navnene og identifikatorene intakte og beskriver beslutningskriteriene tydelig. Det typede resultatet kan bruke stabile applikasjonsetiketter mens det vurderer evidens i naturlig språk. Når en post blander språk eller bruker fagterminologi, behold de relevante definisjonene i tilstanden. En flytende tolkning av en term er ikke nok til å fastslå at klassifiseringskriteriene stemmer med forretningsregelen, så undersøk representative tvetydige tilfeller i tillegg til enkle tilfeller.\n\nBruk de returnerte sannsynlighetene og konfidensen etter arbeidsflytens beslutningspolicy. Bevar fordelingen og den ordnede tegnforklaringen når en vurdering ligger mellom kategorier. Fastsett behandlingen av usikre resultater fra gjennomgåtte oppgaveeksempler fremfor å finne på en universell sannsynlighetsterskel. Applikasjonen utfører eventuell resulterende ruting, eskalering eller gjennomgang og registrerer utfallet. Solar Decide gir den avgrensede modellvurderingen som brukes til å overveie handlingen; å velge en rute fastslår ikke at en senere handling ble utført.\n\nDet nyttige sluttproduktet er answers-objektet sammen med tilstanden og spørsmålsdefinisjonene som frembrakte det. Disse postene gjør det mulig å undersøke en overraskende klassifisering, skille manglende evidens fra tvetydige kriterier og sammenligne vurderingen med et gjennomgått tilfelle. Hvis en bruker trenger en skriftlig forklaring eller et samtalesvar, kan beslutningen og kildematerialet gå inn i et separat skrivetrinn. Solar Decides spesifikke rolle er å produsere typede beslutninger med sannsynlighetsgrunnlag fra innsendt tekst, fremfor å generere forklaringen selv.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "6a1c280fa2c261d5b266139ca680a7f2bd41cc0ebc56ebdf6671c189a91383f2", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "nb", "methods": [ { "html": "upstage/solar-decideUpstage Solar Decide er en tekstbasert beslutningsmodell bygget på Solar Mini 4. Den vurderer en innsendt tilstand og typede spørsmål og returnerer navngitte valg, sannsynligheter for at en betingelse er sann, eller vektede skårer med sannsynlighetsinformasjon. Det avgrensede resultatet støtter klassifisering, ruting og regelkontroller fremfor generert prosa.
Denne beskrivelsen dekker modellens funksjoner. Tilgjengelige inndata, utdata og alternativer i Ailoot er oppført nedenfor for den valgte metoden.
Upstage Solar Decide er en strukturert beslutningsmodell bygget på Solar Mini 4. Den leser en innsendt tilstand og typede spørsmål og returnerer deretter en beslutning for hvert spørsmål med kalibrert sannsynlighetsinformasjon. Produsenten beskriver en beslutningsprosess i én fremoverpassering som ikke genererer prosa. De tilsiktede bruksområdene omfatter ruting, klassifisering og regelkontroller, med modellens koreanskforståelse fremhevet som en del av Solar Mini 4-grunnlaget.
Forbered tilstanden som en streng eller strukturert JSON som beskriver faktaene som skal vurderes. Produsentens grensesnitt serialiserer JSON-verdier inn i prompten. Et spørsmålsskjema definerer separat hva som skal avgjøres, hvilke alternativer som er tillatt, og hvordan en ordnet vurdering skal tolkes. Bruk stabile navn på spørsmålene: Svarene returneres under de samme navnene, slik at resultatet enkelt kan knyttes til den opprinnelige betingelsen i arbeidsflyten. Hold den faktiske tilstanden atskilt fra instruksjonene og kriteriene som definerer beslutningen.
De tre spørsmålstypene har ulike resultater. Et choice-spørsmål returnerer det valgte alternativet, sannsynligheter på tvers av de navngitte alternativene og en konfidensverdi. Et noul-spørsmål returnerer sannsynligheten for at en ja/nei-betingelse er sann. Et score-spørsmål returnerer en sannsynlighetsvektet skår, en indeksert tegnforklaring, sannsynligheter og konfidens. En ordnet skår kan ha desimaler fordi den gjenspeiler fordelingen over kriteriene. Behold disse feltene fremfor å redusere alle resultater til en ren etikett eller behandle konfidens som en forklarende setning.
For supportruting sender du inn den faktiske meldingen og relevant historikk og stiller deretter separate spørsmål om intensjon, hastegrad og en definert betingelse, som om meldingen uttrykker misnøye. Beskriv kategoriene etter betydning og gi hasteskalaen en bevisst rekkefølge. Et eksempelskjema kan skille mellom en forespørsel om leveringsstatus, et problem med kontotilgang og et uvedkommende problem, mens hastekriteriene går fra ingen umiddelbar handling til umiddelbar gjennomgang. Det observerbare resultatet er en typet vurdering av disse valgene, ikke et utkast til svar til kunden.
For regelkontroller inkluderer du den relevante regelen og faktaene i posten sammen i tilstanden. Definer hver betingelse snevert nok til at svaret kan undersøkes. En dokumentarbeidsflyt kan spørre om nødvendig informasjon er til stede, hvilken gjennomgangskategori som gjelder, og hvor sterkt posten oppfyller en ordnet fullstendighetsstandard. En skår eller sannsynlighet bekrefter ikke faktaene i posten uavhengig. Hvis avgjørende informasjon mangler, trenger applikasjonen en bevisst behandling av usikkerheten fremfor å tolke et valgt alternativ som avgjørende bevis.
Produsenten oppgir et kontekstvindu på 512K tokener for Solar Decide. Forbered store dokumenter som teksten eller den strukturerte tilstanden beslutningen krever; en stor kontekst innebærer ikke automatisk parsing av en vilkårlig fil. Bevar kildegrenser og passasjene som er relevante for kriteriene. Bruk fokuserte spørsmål fremfor å forvente et åpent sammendrag av dokumentet. Modellens resultat forblir avgrenset av spørsmålstypene og alternativene, uansett hvor mye materiale som inngår i tilstanden.
Et choice-spørsmål godtar to til 26 alternativer i det dokumenterte produsentgrensesnittet. Produsenten forklarer at denne ruten leser beslutninger fra enkelttokenetikettene A til Z, så mer enn 26 kandidater må snevres inn eller deles i flere spørsmål. Grensen gjelder choice-alternativer, ikke en generell grense for dokumentlengde eller en grense kopiert fra en annen beslutningsmodellfamilie. Definer kandidatbeskrivelser slik at betydningene er ulike, og bruk en hierarkisk beslutning bare når hierarkiet samsvarer med den faktiske arbeidsflyten.
For koreanskspråklige poster bevarer du kildebetydningen, navnene og identifikatorene intakte og beskriver beslutningskriteriene tydelig. Det typede resultatet kan bruke stabile applikasjonsetiketter mens det vurderer evidens i naturlig språk. Når en post blander språk eller bruker fagterminologi, behold de relevante definisjonene i tilstanden. En flytende tolkning av en term er ikke nok til å fastslå at klassifiseringskriteriene stemmer med forretningsregelen, så undersøk representative tvetydige tilfeller i tillegg til enkle tilfeller.
Bruk de returnerte sannsynlighetene og konfidensen etter arbeidsflytens beslutningspolicy. Bevar fordelingen og den ordnede tegnforklaringen når en vurdering ligger mellom kategorier. Fastsett behandlingen av usikre resultater fra gjennomgåtte oppgaveeksempler fremfor å finne på en universell sannsynlighetsterskel. Applikasjonen utfører eventuell resulterende ruting, eskalering eller gjennomgang og registrerer utfallet. Solar Decide gir den avgrensede modellvurderingen som brukes til å overveie handlingen; å velge en rute fastslår ikke at en senere handling ble utført.
Det nyttige sluttproduktet er answers-objektet sammen med tilstanden og spørsmålsdefinisjonene som frembrakte det. Disse postene gjør det mulig å undersøke en overraskende klassifisering, skille manglende evidens fra tvetydige kriterier og sammenligne vurderingen med et gjennomgått tilfelle. Hvis en bruker trenger en skriftlig forklaring eller et samtalesvar, kan beslutningen og kildematerialet gå inn i et separat skrivetrinn. Solar Decides spesifikke rolle er å produsere typede beslutninger med sannsynlighetsgrunnlag fra innsendt tekst, fremfor å generere forklaringen selv.
POST /v1/systemonetextdecisions| Felt | Type | Krav | Verdier & grenser | Standard |
|---|---|---|---|---|
Feltmodel | Typestring | KravPåkrevd | Verdier & grenser upstage/solar-decide | Standard— |
Feltprovider | Typeschema | KravValgfritt | Verdier & grenser | Standard— |
Feltquestions | Typeobject | KravPåkrevd | Verdier & grenser | Standard— |
Feltsession_id | Typestring | KravValgfritt | Verdier & grenser | Standard— |
Feltstate | Typeschema | KravPåkrevd | Verdier & grenser | Standard— |
Felttrace | Typeschema | KravValgfritt | Verdier & grenser | Standard— |
Feltuser | Typestring | KravValgfritt | Verdier & grenser | Standard— |
Feltquestions.<id>.type | Typestring | KravPåkrevd | Verdier & grenser noul, choice, score | Standard— |
Feltquestions.<id>.instructions | Typestring|object|array | KravPåkrevd | Verdier & grenser | Standard— |
Feltquestions.<id>.criteria | Typeobject|array | KravValgfritt | Verdier & grenser Vilkår: choice/score: påkrevd; noul: valgfritt. Kriteriene for choice er et objekt; score er en matrise med minItems1. | Standard— |
Feltquestions.<id>.criteria.true | Typestring|object|array | KravPåkrevd | Verdier & grenser Gjelder når: Kriterieobjektet noul er angitt | Standard— |
Feltquestions.<id>.criteria.false | Typestring|object|array | KravPåkrevd | Verdier & grenser Gjelder når: Kriterieobjektet noul er angitt | Standard— |
noul · Påkrevd: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Påkrevd: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Påkrevd: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parameter | Avtale |
|---|---|
Parametercontent_type | Avtaleapplication/json |
Parameterrequired | Avtalemodel, state, questions |
Parametermaterial_types | Avtaletext |
Parameteroptional_controls | Avtaleprovider, session_id, 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 | Konteksttokener, mer enn | Konteksttokener, opptil og med | Kostnad |
|---|---|---|---|---|
| KonfigurasjonGrunnpriser for tokener | PrisplanGrunnsats | Konteksttokener, mer enn— | Konteksttokener, opptil og medIngen øvre grense | Kostnad Inndata · Inngående tokener $0.0002 / 1K tokener Utdata · Utgående tokener $0 / 1K tokener Inndata · Lesing fra hurtigbuffer $0.0002 / 1K tokener Inndata · Skriving til hurtigbuffer — / 1K tokener Inndata · Skriving til hurtigbuffer, 1 time — / 1K tokener |
| KonfigurasjonNivå 1 for forespørselslengde | Prisplan— | Konteksttokener, mer enn0 | Konteksttokener, opptil og medIngen øvre grense | Kostnad Inndata · Inngående tokener $0.0002 / 1K tokener Utdata · Utgående tokener $0 / 1K tokener Inndata · Lesing fra hurtigbuffer $0.0002 / 1K tokener Inndata · Skriving til hurtigbuffer — / 1K tokener Inndata · Skriving til hurtigbuffer, 1 time — / 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 "model": "upstage/solar-decide",\n "questions": {\n "is_bug": {\n "criteria": {\n "false": "The customer is asking a question or requesting a feature.",\n "true": "The customer describes broken or unexpected product behavior."\n },\n "instructions": "Is the customer reporting a software defect?",\n "type": "noul"\n },\n "team": {\n "criteria": {\n "account": "Login, permissions, or profile issues.",\n "frontend": "Rendering, layout, or browser compatibility issues.",\n "payments": "Checkout, billing, or payment processing issues."\n },\n "instructions": "Which team should own this ticket?",\n "type": "choice"\n },\n "urgency": {\n "criteria": [\n "Can wait for the next release",\n "Should be fixed this week",\n "Blocking revenue right now"\n ],\n "instructions": "How urgent is this ticket?",\n "type": "score"\n }\n },\n "state": {\n "customer_tier": "enterprise",\n "ticket": "My checkout page shows a blank screen after I click Pay. I have tried two browsers."\n }\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']='upstage/solar-decide'\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/systemone \\\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.
Hvert oppgitt svar knyttet til en spørsmåls-ID bevares med sin eksakte type, noul/choice/score-verdi, konfidens, sannsynligheter og tegnforklaring. 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 |
Feltanswers.<id>.type | Typestring |
Feltanswers.<id>.noul | Typenumber |
Feltanswers.<id>.choice | Typestring |
Feltanswers.<id>.score | Typenumber |
Feltanswers.<id>.confidence | Typenumber |
Feltanswers.<id>.probabilities | Typeobject |
Feltanswers.<id>.legend | Typeobject |
Feltusage.input_tokens | Typeinteger |
Feltusage.output_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 upstage/solar-decide
Bruk metodestiene som vises ovenfor.