Mercury Decide er Inceptions modell for strukturerte beslutninger over oppgitt grunnlag. Den kombinerer en felles tilstand med navngitte spørsmål og returnerer typede svar med sannsynligheter. Resultatet kan være en valgt kategori, en anslått ja/nei-sannsynlighet eller en posisjon på en definert skala. Denne profilen leverer en avgrenset beslutning som programvare kan tolke; det dokumenterte grensesnittet genererer ikke et fritt chattesvar.
Produsentens forespørsel inneholder en modell, en tilstand og en ikke-tom tilordning av spørsmål. Spørsmålsnavnene bevares i svartilordningen. Oppgi informasjonen som trengs for å bedømme hvert spørsmål, og gi spørsmålene navn etter resultatene arbeidsflyten bruker, for eksempel category, priority eller needs_follow_up. Flere spørsmål vurderer det samme grunnlaget uavhengig av hverandre. At de står i én forespørsel, gjør ikke et senere spørsmål avhengig av et tidligere svar.
Eksempelet fra Inception bruker et JSON-objekt for tilstanden. Veiledningen tillater også strenger, objekter eller matriser i tilstanden, instruksjonene og kriteriebeskrivelsene, der instruksjonene er valgfrie eller kan være null. Bevar nyttig struktur når grunnlaget allerede består av felter, og hold et dokument eller en melding identifiserbar når du oppgir tekst. For en supportsak tar du med den faktiske henvendelsen og relevante fakta i stedet for en anmodning om å utlede manglende kontekst.
Et noul-spørsmål representerer et ja/nei-vilkår. Utdataene er en sannsynlighet fra 0 til 1 for at det positive svaret gjelder. Valgfrie beskrivelser for sant og usant kan angi hva som teller på hver side av spørsmålet. Spør for eksempel om en melding uttrykkelig ber om en erstatning, og skill det fra en generell klage på varen. Sannsynligheten gir en numerisk vurdering; applikasjonen velger terskelen og den resulterende handlingen i arbeidsflyten.
Hold vilkåret smalt nok til at grunnlaget kan avgjøre det. Hvis ett spørsmål blander om brukeren vil ha hjelp, om en vare er defekt og om saken haster, skiller du disse vilkårene fra hverandre. Behold den returnerte sannsynligheten sammen med spørsmålsdefinisjonen, slik at en senere gjennomgang kan se hva tallet faktisk måler.
Et Choice-spørsmål bruker en tilordning av ett til 255 alternativnavn og beskrivelser; beskrivelsene kan være null. Det returnerte valget er det oppgitte alternativet med høyest sannsynlighet. Resultatet inneholder også en sannsynlighet for hvert alternativ og en konfidens. Definer tydelig adskilte betydninger for kategoriene, og ta med en reservekategori når noen inndata vil falle utenfor de spesifikke alternativene. Korte utdatanøkler kan identifisere kategorier, mens fyldigere beskrivelser fastsetter grensene mellom dem.
En rutingsbeskrivelse kan skille mellom et tilgangsproblem, et produktspørsmål og en rapportert feil. Angi betydningen av hvert alternativ, og oppgi meldingen som skal rutes. Utdataene er en valgt kategori med en fordeling, ikke en instruksjon som allerede har endret en kø eller kontaktet et annet system. Undersøk de konkurrerende sannsynlighetene når et tilfelle er tvetydig, i stedet for å tolke den vinnende etiketten som bevis på sikkerhet.
Et Score-spørsmål bruker en ordnet matrise med ett til ti nivåbeskrivelser, med start på nivå 0. Skåren er det sannsynlighetsvektede gjennomsnittet av nivåindeksene og kan havne mellom nivåene. Svaret inneholder nivåforklaringen, sannsynlighetene per nivå og konfidensen. Definer rekkefølgen og kriteriene for hvert nivå, for eksempel ingen umiddelbar virkning, et problem med et brukbart alternativ og en oppgave som er helt blokkert.
En ikke-heltallig forventet skår er nyttig for prioritering eller aggregering. Det er noe annet enn å velge det ene mest sannsynlige nivået. Behold nivåforklaringen sammen med tallet, slik at en skår ikke tolkes på en urelatert skala. Konfidensen for Choice og Score rapporteres separat som en verdi mellom 0 og 1; den aktuelle veiledningen definerer den ikke som identisk med den største sannsynligheten blant alternativene og gir heller ingen universell formel for å rekonstruere den.
Ett og samme grunnlag kan støtte uavhengige spørsmål om kategori, hastegrad og vilkår. En oppgave for dokumentgjennomgang kan spørre om et påkrevd emne er til stede, velge kategorien og vurdere relevansen på beskrevne nivåer. Bruk bare kildemateriale som finnes i tilstanden, med kriterier knyttet til beslutningen arbeidsflyten trenger som neste trinn. Hvis en handling krever et tidligere resultat, gjør du dette resultatet eksplisitt i grunnlaget for neste trinn i stedet for å anta at spørsmålene danner en skjult rekkefølge.
Svaret returnerer modellnavnet og en svartilordning med de oppgitte spørsmålsnavnene som nøkler. Sannsynlighetene for Choice bruker alternativnavnene; sannsynlighetene for Score bruker indekser i strengform, og nivåforklaringen angir hva disse indeksene betyr. Hold tilstandsidentifikatoren, spørsmålsdefinisjonene og de typede svarene knyttet sammen. Dette gir et tolkbart klassifiserings- eller vurderingsresultat i stedet for et tall løsrevet fra faktaene som ga opphav til det.
Inception dokumenterer Mercury Decide gjennom sitt eget beslutningsgrensesnitt. Modellen støtter ikke produsentens grensesnitt for chat-fullføring, strømming eller verktøykall, så egenskaper fra Mercurys profiler for resonnering, tale og kodegenerering skal ikke overføres til denne modellen. Beslutningsveiledningen angir antall alternativer og nivåer, men gir ingen numerisk tokengrense for tilstanden eller noe tak på antall spørsmål; hold det felles grunnlaget fokusert på spørsmålene som vurderes.
Vurder sannsynligheter og kategorigrenser på representativt merket materiale fra den tiltenkte oppgaven. Gjennomgå grensetilfeller mot tilstanden, og behold opplysningen om at informasjon mangler, i stedet for å erstatte den med oppdiktede fakta. Et nyttig resultat fra Mercury Decide gir en lukket beslutning, sannsynlighetene og definisjonene som trengs for å forstå den; den omkringliggende applikasjonen avgjør hvordan resultatet blir til ruting, prioritering eller et gjennomgangsutfall.
", "aboutText": "Mercury Decide er Inceptions modell for strukturerte beslutninger over oppgitt grunnlag. Den kombinerer en felles tilstand med navngitte spørsmål og returnerer typede svar med sannsynligheter. Resultatet kan være en valgt kategori, en anslått ja/nei-sannsynlighet eller en posisjon på en definert skala. Denne profilen leverer en avgrenset beslutning som programvare kan tolke; det dokumenterte grensesnittet genererer ikke et fritt chattesvar.\n\n### Felles tilstand og meningsfulle spørsmålsnavn\n\nProdusentens forespørsel inneholder en modell, en tilstand og en ikke-tom tilordning av spørsmål. Spørsmålsnavnene bevares i svartilordningen. Oppgi informasjonen som trengs for å bedømme hvert spørsmål, og gi spørsmålene navn etter resultatene arbeidsflyten bruker, for eksempel category, priority eller needs_follow_up. Flere spørsmål vurderer det samme grunnlaget uavhengig av hverandre. At de står i én forespørsel, gjør ikke et senere spørsmål avhengig av et tidligere svar.\n\nEksempelet fra Inception bruker et JSON-objekt for tilstanden. Veiledningen tillater også strenger, objekter eller matriser i tilstanden, instruksjonene og kriteriebeskrivelsene, der instruksjonene er valgfrie eller kan være null. Bevar nyttig struktur når grunnlaget allerede består av felter, og hold et dokument eller en melding identifiserbar når du oppgir tekst. For en supportsak tar du med den faktiske henvendelsen og relevante fakta i stedet for en anmodning om å utlede manglende kontekst.\n\n### Noul: et anslått positivt svar\n\nEt noul-spørsmål representerer et ja/nei-vilkår. Utdataene er en sannsynlighet fra 0 til 1 for at det positive svaret gjelder. Valgfrie beskrivelser for sant og usant kan angi hva som teller på hver side av spørsmålet. Spør for eksempel om en melding uttrykkelig ber om en erstatning, og skill det fra en generell klage på varen. Sannsynligheten gir en numerisk vurdering; applikasjonen velger terskelen og den resulterende handlingen i arbeidsflyten.\n\nHold vilkåret smalt nok til at grunnlaget kan avgjøre det. Hvis ett spørsmål blander om brukeren vil ha hjelp, om en vare er defekt og om saken haster, skiller du disse vilkårene fra hverandre. Behold den returnerte sannsynligheten sammen med spørsmålsdefinisjonen, slik at en senere gjennomgang kan se hva tallet faktisk måler.\n\n### Choice: velge ett navngitt alternativ\n\nEt Choice-spørsmål bruker en tilordning av ett til 255 alternativnavn og beskrivelser; beskrivelsene kan være null. Det returnerte valget er det oppgitte alternativet med høyest sannsynlighet. Resultatet inneholder også en sannsynlighet for hvert alternativ og en konfidens. Definer tydelig adskilte betydninger for kategoriene, og ta med en reservekategori når noen inndata vil falle utenfor de spesifikke alternativene. Korte utdatanøkler kan identifisere kategorier, mens fyldigere beskrivelser fastsetter grensene mellom dem.\n\nEn rutingsbeskrivelse kan skille mellom et tilgangsproblem, et produktspørsmål og en rapportert feil. Angi betydningen av hvert alternativ, og oppgi meldingen som skal rutes. Utdataene er en valgt kategori med en fordeling, ikke en instruksjon som allerede har endret en kø eller kontaktet et annet system. Undersøk de konkurrerende sannsynlighetene når et tilfelle er tvetydig, i stedet for å tolke den vinnende etiketten som bevis på sikkerhet.\n\n### Score: en forventet posisjon på en vurderingsskala\n\nEt Score-spørsmål bruker en ordnet matrise med ett til ti nivåbeskrivelser, med start på nivå 0. Skåren er det sannsynlighetsvektede gjennomsnittet av nivåindeksene og kan havne mellom nivåene. Svaret inneholder nivåforklaringen, sannsynlighetene per nivå og konfidensen. Definer rekkefølgen og kriteriene for hvert nivå, for eksempel ingen umiddelbar virkning, et problem med et brukbart alternativ og en oppgave som er helt blokkert.\n\nEn ikke-heltallig forventet skår er nyttig for prioritering eller aggregering. Det er noe annet enn å velge det ene mest sannsynlige nivået. Behold nivåforklaringen sammen med tallet, slik at en skår ikke tolkes på en urelatert skala. Konfidensen for Choice og Score rapporteres separat som en verdi mellom 0 og 1; den aktuelle veiledningen definerer den ikke som identisk med den største sannsynligheten blant alternativene og gir heller ingen universell formel for å rekonstruere den.\n\n### Forberede et nyttig beslutningsresultat\n\nEtt og samme grunnlag kan støtte uavhengige spørsmål om kategori, hastegrad og vilkår. En oppgave for dokumentgjennomgang kan spørre om et påkrevd emne er til stede, velge kategorien og vurdere relevansen på beskrevne nivåer. Bruk bare kildemateriale som finnes i tilstanden, med kriterier knyttet til beslutningen arbeidsflyten trenger som neste trinn. Hvis en handling krever et tidligere resultat, gjør du dette resultatet eksplisitt i grunnlaget for neste trinn i stedet for å anta at spørsmålene danner en skjult rekkefølge.\n\nSvaret returnerer modellnavnet og en svartilordning med de oppgitte spørsmålsnavnene som nøkler. Sannsynlighetene for Choice bruker alternativnavnene; sannsynlighetene for Score bruker indekser i strengform, og nivåforklaringen angir hva disse indeksene betyr. Hold tilstandsidentifikatoren, spørsmålsdefinisjonene og de typede svarene knyttet sammen. Dette gir et tolkbart klassifiserings- eller vurderingsresultat i stedet for et tall løsrevet fra faktaene som ga opphav til det.\n\n### Grensesnittets omfang og grenser\n\nInception dokumenterer Mercury Decide gjennom sitt eget beslutningsgrensesnitt. Modellen støtter ikke produsentens grensesnitt for chat-fullføring, strømming eller verktøykall, så egenskaper fra Mercurys profiler for resonnering, tale og kodegenerering skal ikke overføres til denne modellen. Beslutningsveiledningen angir antall alternativer og nivåer, men gir ingen numerisk tokengrense for tilstanden eller noe tak på antall spørsmål; hold det felles grunnlaget fokusert på spørsmålene som vurderes.\n\nVurder sannsynligheter og kategorigrenser på representativt merket materiale fra den tiltenkte oppgaven. Gjennomgå grensetilfeller mot tilstanden, og behold opplysningen om at informasjon mangler, i stedet for å erstatte den med oppdiktede fakta. Et nyttig resultat fra Mercury Decide gir en lukket beslutning, sannsynlighetene og definisjonene som trengs for å forstå den; den omkringliggende applikasjonen avgjør hvordan resultatet blir til ruting, prioritering eller et gjennomgangsutfall.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "8d58d67c32c97eab7ff8103b0f55beb3bc1825d894cd28cfbcc5a1809e0c8f60", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "nb", "methods": [ { "html": "inception/mercury-decideMercury Decide vurderer felles grunnlag i tekst eller JSON opp mot navngitte spørsmål og returnerer typede valg, ja/nei-sannsynligheter eller ikke-heltallige skårer på en vurderingsskala. Inception dokumenterer en egen beslutningsflyt med opptil 255 Choice-alternativer og ti Score-nivåer.
Denne beskrivelsen dekker modellens funksjoner. Tilgjengelige inndata, utdata og alternativer i Ailoot er oppført nedenfor for den valgte metoden.
Mercury Decide er Inceptions modell for strukturerte beslutninger over oppgitt grunnlag. Den kombinerer en felles tilstand med navngitte spørsmål og returnerer typede svar med sannsynligheter. Resultatet kan være en valgt kategori, en anslått ja/nei-sannsynlighet eller en posisjon på en definert skala. Denne profilen leverer en avgrenset beslutning som programvare kan tolke; det dokumenterte grensesnittet genererer ikke et fritt chattesvar.
Produsentens forespørsel inneholder en modell, en tilstand og en ikke-tom tilordning av spørsmål. Spørsmålsnavnene bevares i svartilordningen. Oppgi informasjonen som trengs for å bedømme hvert spørsmål, og gi spørsmålene navn etter resultatene arbeidsflyten bruker, for eksempel category, priority eller needs_follow_up. Flere spørsmål vurderer det samme grunnlaget uavhengig av hverandre. At de står i én forespørsel, gjør ikke et senere spørsmål avhengig av et tidligere svar.
Eksempelet fra Inception bruker et JSON-objekt for tilstanden. Veiledningen tillater også strenger, objekter eller matriser i tilstanden, instruksjonene og kriteriebeskrivelsene, der instruksjonene er valgfrie eller kan være null. Bevar nyttig struktur når grunnlaget allerede består av felter, og hold et dokument eller en melding identifiserbar når du oppgir tekst. For en supportsak tar du med den faktiske henvendelsen og relevante fakta i stedet for en anmodning om å utlede manglende kontekst.
Et noul-spørsmål representerer et ja/nei-vilkår. Utdataene er en sannsynlighet fra 0 til 1 for at det positive svaret gjelder. Valgfrie beskrivelser for sant og usant kan angi hva som teller på hver side av spørsmålet. Spør for eksempel om en melding uttrykkelig ber om en erstatning, og skill det fra en generell klage på varen. Sannsynligheten gir en numerisk vurdering; applikasjonen velger terskelen og den resulterende handlingen i arbeidsflyten.
Hold vilkåret smalt nok til at grunnlaget kan avgjøre det. Hvis ett spørsmål blander om brukeren vil ha hjelp, om en vare er defekt og om saken haster, skiller du disse vilkårene fra hverandre. Behold den returnerte sannsynligheten sammen med spørsmålsdefinisjonen, slik at en senere gjennomgang kan se hva tallet faktisk måler.
Et Choice-spørsmål bruker en tilordning av ett til 255 alternativnavn og beskrivelser; beskrivelsene kan være null. Det returnerte valget er det oppgitte alternativet med høyest sannsynlighet. Resultatet inneholder også en sannsynlighet for hvert alternativ og en konfidens. Definer tydelig adskilte betydninger for kategoriene, og ta med en reservekategori når noen inndata vil falle utenfor de spesifikke alternativene. Korte utdatanøkler kan identifisere kategorier, mens fyldigere beskrivelser fastsetter grensene mellom dem.
En rutingsbeskrivelse kan skille mellom et tilgangsproblem, et produktspørsmål og en rapportert feil. Angi betydningen av hvert alternativ, og oppgi meldingen som skal rutes. Utdataene er en valgt kategori med en fordeling, ikke en instruksjon som allerede har endret en kø eller kontaktet et annet system. Undersøk de konkurrerende sannsynlighetene når et tilfelle er tvetydig, i stedet for å tolke den vinnende etiketten som bevis på sikkerhet.
Et Score-spørsmål bruker en ordnet matrise med ett til ti nivåbeskrivelser, med start på nivå 0. Skåren er det sannsynlighetsvektede gjennomsnittet av nivåindeksene og kan havne mellom nivåene. Svaret inneholder nivåforklaringen, sannsynlighetene per nivå og konfidensen. Definer rekkefølgen og kriteriene for hvert nivå, for eksempel ingen umiddelbar virkning, et problem med et brukbart alternativ og en oppgave som er helt blokkert.
En ikke-heltallig forventet skår er nyttig for prioritering eller aggregering. Det er noe annet enn å velge det ene mest sannsynlige nivået. Behold nivåforklaringen sammen med tallet, slik at en skår ikke tolkes på en urelatert skala. Konfidensen for Choice og Score rapporteres separat som en verdi mellom 0 og 1; den aktuelle veiledningen definerer den ikke som identisk med den største sannsynligheten blant alternativene og gir heller ingen universell formel for å rekonstruere den.
Ett og samme grunnlag kan støtte uavhengige spørsmål om kategori, hastegrad og vilkår. En oppgave for dokumentgjennomgang kan spørre om et påkrevd emne er til stede, velge kategorien og vurdere relevansen på beskrevne nivåer. Bruk bare kildemateriale som finnes i tilstanden, med kriterier knyttet til beslutningen arbeidsflyten trenger som neste trinn. Hvis en handling krever et tidligere resultat, gjør du dette resultatet eksplisitt i grunnlaget for neste trinn i stedet for å anta at spørsmålene danner en skjult rekkefølge.
Svaret returnerer modellnavnet og en svartilordning med de oppgitte spørsmålsnavnene som nøkler. Sannsynlighetene for Choice bruker alternativnavnene; sannsynlighetene for Score bruker indekser i strengform, og nivåforklaringen angir hva disse indeksene betyr. Hold tilstandsidentifikatoren, spørsmålsdefinisjonene og de typede svarene knyttet sammen. Dette gir et tolkbart klassifiserings- eller vurderingsresultat i stedet for et tall løsrevet fra faktaene som ga opphav til det.
Inception dokumenterer Mercury Decide gjennom sitt eget beslutningsgrensesnitt. Modellen støtter ikke produsentens grensesnitt for chat-fullføring, strømming eller verktøykall, så egenskaper fra Mercurys profiler for resonnering, tale og kodegenerering skal ikke overføres til denne modellen. Beslutningsveiledningen angir antall alternativer og nivåer, men gir ingen numerisk tokengrense for tilstanden eller noe tak på antall spørsmål; hold det felles grunnlaget fokusert på spørsmålene som vurderes.
Vurder sannsynligheter og kategorigrenser på representativt merket materiale fra den tiltenkte oppgaven. Gjennomgå grensetilfeller mot tilstanden, og behold opplysningen om at informasjon mangler, i stedet for å erstatte den med oppdiktede fakta. Et nyttig resultat fra Mercury Decide gir en lukket beslutning, sannsynlighetene og definisjonene som trengs for å forstå den; den omkringliggende applikasjonen avgjør hvordan resultatet blir til ruting, prioritering eller et gjennomgangsutfall.
POST /v1/systemonetextdecisions| Felt | Type | Krav | Verdier & grenser | Standard |
|---|---|---|---|---|
Feltmodel | Typestring | KravPåkrevd | Verdier & grenser inception/mercury-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.00008 / 1K tokener Utdata · Utgående tokener $0 / 1K tokener Inndata · Lesing fra hurtigbuffer $0 / 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.00008 / 1K tokener Utdata · Utgående tokener $0 / 1K tokener Inndata · Lesing fra hurtigbuffer $0 / 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": "inception/mercury-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']='inception/mercury-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 inception/mercury-decide
Bruk metodestiene som vises ovenfor.