Upstage Solar Decide er en struktureret beslutningsmodel bygget på Solar Mini 4. Den læser en indsendt tilstand og typede spørgsmål og returnerer derefter en beslutning for hvert spørgsmål med kalibrerede sandsynlighedsoplysninger. Producenten beskriver en beslutningsproces i én fremadrettet beregning, som ikke genererer prosa. De tilsigtede anvendelser omfatter routing, klassifikation og regelkontrol, og modellens koreanskforståelse fremhæves som en del af dens Solar Mini 4-grundlag.
Forbered tilstanden som en streng eller struktureret JSON, der beskriver de fakta, som skal vurderes. Producentens grænseflade serialiserer JSON-værdier til prompten. Et spørgsmålsskema definerer separat, hvad der skal afgøres, hvilke svarmuligheder der er tilladt, og hvordan en ordnet vurdering skal fortolkes. Brug stabile navne til spørgsmålene: Svarene returneres under samme navne, så resultatet let kan knyttes til arbejdsgangens oprindelige betingelse. Hold den faktuelle tilstand adskilt fra de instruktioner og kriterier, der definerer beslutningen.
De tre spørgsmålstyper har forskellige output. Et choice-spørgsmål returnerer den valgte mulighed, sandsynligheder for de navngivne alternativer og en konfidensværdi. Et noul-spørgsmål returnerer sandsynligheden for sand for en ja/nej-betingelse. Et score-spørgsmål returnerer en sandsynlighedsvægtet score, en indekseret tegnforklaring, sandsynligheder og konfidens. En ordnet score kan have decimaler, fordi den afspejler fordelingen over kriterier. Bevar felterne frem for at reducere ethvert resultat til en bar etiket eller behandle konfidens som en forklarende sætning.
Ved supportrouting skal du indsende den faktiske besked og relevant historik og derefter stille separate spørgsmål om hensigt, hast og en defineret betingelse, såsom om beskeden udtrykker utilfredshed. Beskriv kategorier efter deres betydning, og giv hasteskalaen en bevidst rækkefølge. Et eksempelskema kan skelne mellem en forespørgsel om leveringsstatus, et kontoadgangsproblem og et uvedkommende problem, mens hastekriterierne går fra ingen øjeblikkelig handling til øjeblikkelig gennemgang. Det observerbare resultat er en typet vurdering af disse valg, ikke et udkast til et kundesvar.
Ved regelkontrol skal den relevante regel og postens fakta medtages sammen i tilstanden. Definér hver betingelse tilstrækkeligt snævert til, at dens svar kan undersøges. En dokumentarbejdsgang kan spørge, om påkrævet information er til stede, hvilken gennemgangskategori der gælder, og hvor stærkt posten opfylder en ordnet fuldstændighedsstandard. En score eller sandsynlighed verificerer ikke uafhængigt postens fakta. Hvis afgørende information mangler, skal applikationen have en bevidst fastlagt behandling af denne usikkerhed frem for at fortolke en valgt mulighed som afgørende bevis.
Producenten angiver et kontekstvindue på 512K tokens for Solar Decide. Forbered store dokumenter som den tekst eller strukturerede tilstand, beslutningen kræver; en stor kontekst indebærer ikke automatisk parsing af en vilkårlig fil. Bevar kildegrænser og de passager, der er relevante for kriterierne. Brug fokuserede spørgsmål frem for at forvente et åbent resumé af dokumentet. Modellens output forbliver afgrænset af spørgsmålstyperne og svarmulighederne, uanset hvor meget materiale der medtages i tilstanden.
Et choice-spørgsmål accepterer to til 26 svarmuligheder i den dokumenterede producentgrænseflade. Producenten forklarer, at denne rute læser beslutninger fra etiketterne A til Z, som hver består af én token, så mere end 26 kandidater skal indsnævres eller opdeles i flere spørgsmål. Grænsen gælder choice-svarmuligheder og er ikke en generel grænse for dokumentlængde eller en grænse kopieret fra en anden beslutningsmodelfamilie. Definér kandidatbeskrivelserne, så deres betydninger er forskellige, og brug kun en hierarkisk beslutning, når hierarkiet passer til den faktiske arbejdsgang.
Ved koreansksprogede poster skal kildens betydning, navne og identifikatorer bevares intakte, og beslutningskriterierne beskrives tydeligt. Det typede resultat kan bruge stabile applikationsetiketter og samtidig vurdere evidens i naturligt sprog. Når en post blander sprog eller bruger domæneterminologi, skal de relevante definitioner bevares i tilstanden. En flydende fortolkning af et begreb er ikke nok til at fastslå, at klassifikationskriterierne stemmer med forretningsreglen, så undersøg repræsentative tvetydige tilfælde såvel som ligetil tilfælde.
Brug de returnerede sandsynligheder og konfidens efter arbejdsgangens beslutningspolitik. Bevar fordelingen og den ordnede tegnforklaring, når en vurdering ligger mellem kategorier. Fastlæg behandlingen af usikre resultater ud fra gennemgåede opgaveeksempler frem for at opfinde en universel sandsynlighedstærskel. Applikationen udfører enhver resulterende routing, eskalering eller gennemgang og registrerer udfaldet. Solar Decide leverer den afgrænsede modelvurdering, der bruges til at overveje handlingen; valg af en rute fastslår ikke, at en senere handling blev udført.
Det nyttige endelige resultat er answers-objektet sammen med den tilstand og de spørgsmålsdefinitioner, som frembragte det. Registreringerne gør det muligt at undersøge en overraskende klassifikation, skelne manglende evidens fra tvetydige kriterier og sammenligne vurderingen med et gennemgået tilfælde. Hvis en bruger har brug for en skriftlig forklaring eller et samtalesvar, kan beslutningen og kildematerialet indgå i et separat skrivetrin. Solar Decides specifikke rolle er at producere typede beslutninger med sandsynlighedsunderstøttelse ud fra indsendt tekst frem for selv at generere forklaringen.
", "aboutText": "Upstage Solar Decide er en struktureret beslutningsmodel bygget på Solar Mini 4. Den læser en indsendt tilstand og typede spørgsmål og returnerer derefter en beslutning for hvert spørgsmål med kalibrerede sandsynlighedsoplysninger. Producenten beskriver en beslutningsproces i én fremadrettet beregning, som ikke genererer prosa. De tilsigtede anvendelser omfatter routing, klassifikation og regelkontrol, og modellens koreanskforståelse fremhæves som en del af dens Solar Mini 4-grundlag.\n\nForbered tilstanden som en streng eller struktureret JSON, der beskriver de fakta, som skal vurderes. Producentens grænseflade serialiserer JSON-værdier til prompten. Et spørgsmålsskema definerer separat, hvad der skal afgøres, hvilke svarmuligheder der er tilladt, og hvordan en ordnet vurdering skal fortolkes. Brug stabile navne til spørgsmålene: Svarene returneres under samme navne, så resultatet let kan knyttes til arbejdsgangens oprindelige betingelse. Hold den faktuelle tilstand adskilt fra de instruktioner og kriterier, der definerer beslutningen.\n\nDe tre spørgsmålstyper har forskellige output. Et choice-spørgsmål returnerer den valgte mulighed, sandsynligheder for de navngivne alternativer og en konfidensværdi. Et noul-spørgsmål returnerer sandsynligheden for sand for en ja/nej-betingelse. Et score-spørgsmål returnerer en sandsynlighedsvægtet score, en indekseret tegnforklaring, sandsynligheder og konfidens. En ordnet score kan have decimaler, fordi den afspejler fordelingen over kriterier. Bevar felterne frem for at reducere ethvert resultat til en bar etiket eller behandle konfidens som en forklarende sætning.\n\nVed supportrouting skal du indsende den faktiske besked og relevant historik og derefter stille separate spørgsmål om hensigt, hast og en defineret betingelse, såsom om beskeden udtrykker utilfredshed. Beskriv kategorier efter deres betydning, og giv hasteskalaen en bevidst rækkefølge. Et eksempelskema kan skelne mellem en forespørgsel om leveringsstatus, et kontoadgangsproblem og et uvedkommende problem, mens hastekriterierne går fra ingen øjeblikkelig handling til øjeblikkelig gennemgang. Det observerbare resultat er en typet vurdering af disse valg, ikke et udkast til et kundesvar.\n\nVed regelkontrol skal den relevante regel og postens fakta medtages sammen i tilstanden. Definér hver betingelse tilstrækkeligt snævert til, at dens svar kan undersøges. En dokumentarbejdsgang kan spørge, om påkrævet information er til stede, hvilken gennemgangskategori der gælder, og hvor stærkt posten opfylder en ordnet fuldstændighedsstandard. En score eller sandsynlighed verificerer ikke uafhængigt postens fakta. Hvis afgørende information mangler, skal applikationen have en bevidst fastlagt behandling af denne usikkerhed frem for at fortolke en valgt mulighed som afgørende bevis.\n\nProducenten angiver et kontekstvindue på 512K tokens for Solar Decide. Forbered store dokumenter som den tekst eller strukturerede tilstand, beslutningen kræver; en stor kontekst indebærer ikke automatisk parsing af en vilkårlig fil. Bevar kildegrænser og de passager, der er relevante for kriterierne. Brug fokuserede spørgsmål frem for at forvente et åbent resumé af dokumentet. Modellens output forbliver afgrænset af spørgsmålstyperne og svarmulighederne, uanset hvor meget materiale der medtages i tilstanden.\n\nEt choice-spørgsmål accepterer to til 26 svarmuligheder i den dokumenterede producentgrænseflade. Producenten forklarer, at denne rute læser beslutninger fra etiketterne A til Z, som hver består af én token, så mere end 26 kandidater skal indsnævres eller opdeles i flere spørgsmål. Grænsen gælder choice-svarmuligheder og er ikke en generel grænse for dokumentlængde eller en grænse kopieret fra en anden beslutningsmodelfamilie. Definér kandidatbeskrivelserne, så deres betydninger er forskellige, og brug kun en hierarkisk beslutning, når hierarkiet passer til den faktiske arbejdsgang.\n\nVed koreansksprogede poster skal kildens betydning, navne og identifikatorer bevares intakte, og beslutningskriterierne beskrives tydeligt. Det typede resultat kan bruge stabile applikationsetiketter og samtidig vurdere evidens i naturligt sprog. Når en post blander sprog eller bruger domæneterminologi, skal de relevante definitioner bevares i tilstanden. En flydende fortolkning af et begreb er ikke nok til at fastslå, at klassifikationskriterierne stemmer med forretningsreglen, så undersøg repræsentative tvetydige tilfælde såvel som ligetil tilfælde.\n\nBrug de returnerede sandsynligheder og konfidens efter arbejdsgangens beslutningspolitik. Bevar fordelingen og den ordnede tegnforklaring, når en vurdering ligger mellem kategorier. Fastlæg behandlingen af usikre resultater ud fra gennemgåede opgaveeksempler frem for at opfinde en universel sandsynlighedstærskel. Applikationen udfører enhver resulterende routing, eskalering eller gennemgang og registrerer udfaldet. Solar Decide leverer den afgrænsede modelvurdering, der bruges til at overveje handlingen; valg af en rute fastslår ikke, at en senere handling blev udført.\n\nDet nyttige endelige resultat er answers-objektet sammen med den tilstand og de spørgsmålsdefinitioner, som frembragte det. Registreringerne gør det muligt at undersøge en overraskende klassifikation, skelne manglende evidens fra tvetydige kriterier og sammenligne vurderingen med et gennemgået tilfælde. Hvis en bruger har brug for en skriftlig forklaring eller et samtalesvar, kan beslutningen og kildematerialet indgå i et separat skrivetrin. Solar Decides specifikke rolle er at producere typede beslutninger med sandsynlighedsunderstøttelse ud fra indsendt tekst frem for selv at generere forklaringen.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "533b4b0f403a4d19c3b9409aa2d0ff35597db3d5c2b3c743b01067677098a1da", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "da", "methods": [ { "html": "upstage/solar-decideUpstage Solar Decide er en tekstbaseret beslutningsmodel bygget på Solar Mini 4. Den vurderer en indsendt tilstand og typede spørgsmål og returnerer navngivne valg, sandsynligheder for, at en betingelse er sand, eller vægtede scorer med sandsynlighedsoplysninger. Dens afgrænsede output understøtter klassifikation, routing og regelkontrol frem for genereret prosa.
Denne beskrivelse dækker modellens funktioner. Tilgængelige input, output og indstillinger i Ailoot står nedenfor for den valgte metode.
Upstage Solar Decide er en struktureret beslutningsmodel bygget på Solar Mini 4. Den læser en indsendt tilstand og typede spørgsmål og returnerer derefter en beslutning for hvert spørgsmål med kalibrerede sandsynlighedsoplysninger. Producenten beskriver en beslutningsproces i én fremadrettet beregning, som ikke genererer prosa. De tilsigtede anvendelser omfatter routing, klassifikation og regelkontrol, og modellens koreanskforståelse fremhæves som en del af dens Solar Mini 4-grundlag.
Forbered tilstanden som en streng eller struktureret JSON, der beskriver de fakta, som skal vurderes. Producentens grænseflade serialiserer JSON-værdier til prompten. Et spørgsmålsskema definerer separat, hvad der skal afgøres, hvilke svarmuligheder der er tilladt, og hvordan en ordnet vurdering skal fortolkes. Brug stabile navne til spørgsmålene: Svarene returneres under samme navne, så resultatet let kan knyttes til arbejdsgangens oprindelige betingelse. Hold den faktuelle tilstand adskilt fra de instruktioner og kriterier, der definerer beslutningen.
De tre spørgsmålstyper har forskellige output. Et choice-spørgsmål returnerer den valgte mulighed, sandsynligheder for de navngivne alternativer og en konfidensværdi. Et noul-spørgsmål returnerer sandsynligheden for sand for en ja/nej-betingelse. Et score-spørgsmål returnerer en sandsynlighedsvægtet score, en indekseret tegnforklaring, sandsynligheder og konfidens. En ordnet score kan have decimaler, fordi den afspejler fordelingen over kriterier. Bevar felterne frem for at reducere ethvert resultat til en bar etiket eller behandle konfidens som en forklarende sætning.
Ved supportrouting skal du indsende den faktiske besked og relevant historik og derefter stille separate spørgsmål om hensigt, hast og en defineret betingelse, såsom om beskeden udtrykker utilfredshed. Beskriv kategorier efter deres betydning, og giv hasteskalaen en bevidst rækkefølge. Et eksempelskema kan skelne mellem en forespørgsel om leveringsstatus, et kontoadgangsproblem og et uvedkommende problem, mens hastekriterierne går fra ingen øjeblikkelig handling til øjeblikkelig gennemgang. Det observerbare resultat er en typet vurdering af disse valg, ikke et udkast til et kundesvar.
Ved regelkontrol skal den relevante regel og postens fakta medtages sammen i tilstanden. Definér hver betingelse tilstrækkeligt snævert til, at dens svar kan undersøges. En dokumentarbejdsgang kan spørge, om påkrævet information er til stede, hvilken gennemgangskategori der gælder, og hvor stærkt posten opfylder en ordnet fuldstændighedsstandard. En score eller sandsynlighed verificerer ikke uafhængigt postens fakta. Hvis afgørende information mangler, skal applikationen have en bevidst fastlagt behandling af denne usikkerhed frem for at fortolke en valgt mulighed som afgørende bevis.
Producenten angiver et kontekstvindue på 512K tokens for Solar Decide. Forbered store dokumenter som den tekst eller strukturerede tilstand, beslutningen kræver; en stor kontekst indebærer ikke automatisk parsing af en vilkårlig fil. Bevar kildegrænser og de passager, der er relevante for kriterierne. Brug fokuserede spørgsmål frem for at forvente et åbent resumé af dokumentet. Modellens output forbliver afgrænset af spørgsmålstyperne og svarmulighederne, uanset hvor meget materiale der medtages i tilstanden.
Et choice-spørgsmål accepterer to til 26 svarmuligheder i den dokumenterede producentgrænseflade. Producenten forklarer, at denne rute læser beslutninger fra etiketterne A til Z, som hver består af én token, så mere end 26 kandidater skal indsnævres eller opdeles i flere spørgsmål. Grænsen gælder choice-svarmuligheder og er ikke en generel grænse for dokumentlængde eller en grænse kopieret fra en anden beslutningsmodelfamilie. Definér kandidatbeskrivelserne, så deres betydninger er forskellige, og brug kun en hierarkisk beslutning, når hierarkiet passer til den faktiske arbejdsgang.
Ved koreansksprogede poster skal kildens betydning, navne og identifikatorer bevares intakte, og beslutningskriterierne beskrives tydeligt. Det typede resultat kan bruge stabile applikationsetiketter og samtidig vurdere evidens i naturligt sprog. Når en post blander sprog eller bruger domæneterminologi, skal de relevante definitioner bevares i tilstanden. En flydende fortolkning af et begreb er ikke nok til at fastslå, at klassifikationskriterierne stemmer med forretningsreglen, så undersøg repræsentative tvetydige tilfælde såvel som ligetil tilfælde.
Brug de returnerede sandsynligheder og konfidens efter arbejdsgangens beslutningspolitik. Bevar fordelingen og den ordnede tegnforklaring, når en vurdering ligger mellem kategorier. Fastlæg behandlingen af usikre resultater ud fra gennemgåede opgaveeksempler frem for at opfinde en universel sandsynlighedstærskel. Applikationen udfører enhver resulterende routing, eskalering eller gennemgang og registrerer udfaldet. Solar Decide leverer den afgrænsede modelvurdering, der bruges til at overveje handlingen; valg af en rute fastslår ikke, at en senere handling blev udført.
Det nyttige endelige resultat er answers-objektet sammen med den tilstand og de spørgsmålsdefinitioner, som frembragte det. Registreringerne gør det muligt at undersøge en overraskende klassifikation, skelne manglende evidens fra tvetydige kriterier og sammenligne vurderingen med et gennemgået tilfælde. Hvis en bruger har brug for en skriftlig forklaring eller et samtalesvar, kan beslutningen og kildematerialet indgå i et separat skrivetrin. Solar Decides specifikke rolle er at producere typede beslutninger med sandsynlighedsunderstøttelse ud fra indsendt tekst frem for selv at generere forklaringen.
POST /v1/systemonetextdecisions| Felt | Type | Krav | Værdier og grænser | Standard |
|---|---|---|---|---|
Feltmodel | Typestring | KravPåkrævet | Værdier og grænser upstage/solar-decide | Standard— |
Feltprovider | Typeschema | KravValgfrit | Værdier og grænser | Standard— |
Feltquestions | Typeobject | KravPåkrævet | Værdier og grænser | Standard— |
Feltsession_id | Typestring | KravValgfrit | Værdier og grænser | Standard— |
Feltstate | Typeschema | KravPåkrævet | Værdier og grænser | Standard— |
Felttrace | Typeschema | KravValgfrit | Værdier og grænser | Standard— |
Feltuser | Typestring | KravValgfrit | Værdier og grænser | Standard— |
Feltquestions.<id>.type | Typestring | KravPåkrævet | Værdier og grænser noul, choice, score | Standard— |
Feltquestions.<id>.instructions | Typestring|object|array | KravPåkrævet | Værdier og grænser | Standard— |
Feltquestions.<id>.criteria | Typeobject|array | KravValgfrit | Værdier og grænser Betingelser: choice/score: påkrævet; noul: valgfrit. Kriterier for choice er et objekt; score er et array med minItems1. | Standard— |
Feltquestions.<id>.criteria.true | Typestring|object|array | KravPåkrævet | Værdier og grænser Gælder når: Der er angivet et noul-kriterieobjekt | Standard— |
Feltquestions.<id>.criteria.false | Typestring|object|array | KravPåkrævet | Værdier og grænser Gælder når: Der er angivet et noul-kriterieobjekt | Standard— |
noul · Påkrævet: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Påkrævet: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Påkrævet: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parameter | Kontrakt |
|---|---|
Parametercontent_type | Kontraktapplication/json |
Parameterrequired | Kontraktmodel, state, questions |
Parametermaterial_types | Kontrakttext |
Parameteroptional_controls | Kontraktprovider, session_id, trace, user |
Parametermultimodal_input_binding | Kontraktnull |
Livscyklus: synchronous
Send det præcise model-ID, og behold hele det native svar.
Tarifoplysninger tilføjer ikke anmodningsmuligheder. Understøttede parametre står ved den valgte metode.
Knyt hver omkostning til de viste betingelser. Brug én takst for hver gruppe af alternative konfigurationer.
| Konfiguration | Takstplan | Konteksttokens, mere end | Konteksttokens, op til og med | Beløb |
|---|---|---|---|---|
| KonfigurationGrundtakster for tokens | TakstplanGrundtakst | Konteksttokens, mere end— | Konteksttokens, op til og medIngen øvre grænse | Beløb Input · Inputtokens $0.0002 / 1K tokens Output · Outputtokens $0 / 1K tokens Input · Cachelæsning $0.0002 / 1K tokens Input · Cacheskrivning — / 1K tokens Input · Cacheskrivning, 1 time — / 1K tokens |
| KonfigurationAnmodningslængde · niveau 1 | Takstplan— | Konteksttokens, mere end0 | Konteksttokens, op til og medIngen øvre grænse | Beløb Input · Inputtokens $0.0002 / 1K tokens Output · Outputtokens $0 / 1K tokens Input · Cachelæsning $0.0002 / 1K tokens Input · Cacheskrivning — / 1K tokens Input · Cacheskrivning, 1 time — / 1K tokens |
Ailoot reserverer et estimeret beløb før en anmodning. Efter resultatet afregnes det endelige beløb ud fra det målte forbrug. Ved streaming bruges den endelige forbrugsregistrering til afregningen. Sådan fungerer reservation og afregning →
{\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
Gem hvert fuldstændigt returneret svar, hver fil og hver indholdsdel.
Hvert angivet svar på et spørgsmåls-ID bevares med sin præcise type, noul/choice/score-værdi, konfidens, sandsynligheder og forklaring. Hele det oprindelige JSON-svar gemmes og returneres først efter afregning.
Behold den oprindelige operation og hele eller det delvise svar; gentag ikke 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 | Betingelse | Næste trin |
|---|---|---|
Svar400 · invalid_request_error | BetingelseUgyldigt påkrævet felt, ugyldig repræsentation eller ugyldig værdi | Næste trinRet det angivne forespørgselsfelt. |
Ailoot Ultra upstage/solar-decide
Brug metodestierne vist ovenfor.