Drex 1.5 er Nace.AI’s tekstbaserede beslutningsmodel. Den vurderer indsendte fakta ud fra lukkede spørgsmål og returnerer numeriske, typede svar frem for et åbent skriftligt svar. En anmodning kombinerer én tilstand med navngivne spørgsmål, og resultatet identificerer hvert svar med det samme spørgsmålsnavn. Det giver en arbejdsgang en konkret kategori, sandsynlighed eller placering i en vurderingsrubrik at bruge, mens applikationen står for den handling, resultatet fører til.
Tilstanden er den information, som alle spørgsmålene vedrører. Drex accepterer en JSON-streng, et objekt, et array, et tal, en boolesk værdi eller null, og feltet state er påkrævet. Indsend meningsfuld evidens, selv om null består producentens validering. En streng passer til en besked, et dokument eller en transskription; et objekt passer til fakta, der allerede er organiseret i felter. Bevar den information, der påvirker beslutningen, og udelad uvedkommende felter, når materialet er langt. Hold inputformatet stabilt ved fortolkning af sandsynlighedstærskler, fordi en ændret repræsentation kan ændre svaret.
Drex 1.5 læser kun tekst. Den dokumenterede grænseflade afviser billeder, lyd, video og PDF-indhold i både tilstanden og spørgsmålene, herunder kodede medier og objekter med medieindhold. Forbered en billedtekst, genkendt dokumenttekst eller en transskription, før materialet bruges som evidens. En tekstadresse er ikke et hentet dokument eller billede: Modellen kan ikke åbne den. For en supportanmodning er den nyttige tilstand den faktiske besked og relevant kontekst, ikke en henvisning til materiale, modellen ikke har modtaget.
Et noul-spørgsmål spørger, om en betingelse er opfyldt, og returnerer et tal fra 0 til 1, som repræsenterer den estimerede sandsynlighed for ja. Definér spørgsmålet med ikke-tomme instruktioner eller mindst ét ikke-tomt sand/falsk-kriterium. Spørg eksempelvis, om en besked rapporterer en defekt funktion, og definér, om langsom adfærd tæller som defekt. Drex fastsætter ikke en indbygget ja/nej-grænse; den anvendende arbejdsgang vælger, hvordan sandsynligheden fortolkes.
Et choice-spørgsmål vælger én indsendt etiket fra et uordnet sæt og returnerer en sandsynlighed for hver etiket. Kriterierne er et objekt, hvis nøgler er de returnerede etiketter, og hver beskrivelse er en streng eller null. Brug korte, stabile nøgler, og beskriv kategorigrænser tydeligt. En eksempelopgave til routing kan skelne mellem et adgangsproblem, en produktfejl og et generelt spørgsmål med en other-kategori til beskeder, der ikke passer. Den valgte etiket er nyttig til routing; fordelingen hjælper med at identificere tilfælde, hvor to svarmuligheder stadig er vanskelige at adskille.
Et score-spørgsmål bruger et ordnet array af niveauetiketter. Indeks begynder ved 0, og den returnerede score er summen af hvert niveauindeks ganget med dets sandsynlighed. Den kan derfor ligge mellem navngivne niveauer. Ved en alvorlighedsskala skal du definere, hvad der adskiller et kosmetisk problem, et problem med en omgåelsesmulighed og en fuldstændigt blokeret opgave. Resultatet indeholder niveauernes tegnforklaring og sandsynligheder samt den forventede score. Bevar scoren med decimaler til gennemsnit eller tendenser; valg af det mest sandsynlige niveau og afrunding af den forventede score besvarer forskellige spørgsmål.
Producenten tillader ét til 512 spørgsmål om samme tilstand. Giv hvert spørgsmål en ikke-tom, meningsfuld identifikator, såsom category eller severity, så det tilsvarende svar kan forstås uden at slå et nummereret spørgsmål op. Adskil uafhængige forhold i deres egne spørgsmål frem for at kombinere flere krav i ét uklart kriterium. En enkelt besked kan understøtte et kategorivalg, en alvorlighedsscore og en kontrol af en betingelse, som hver bevarer sin egen betydning.
Choice- og score-svar indeholder konfidens separat fra deres sandsynlighedsfordelinger. Producenten skelner udtrykkeligt mellem konfidens og den højeste sandsynlighed for en svarmulighed; beregn ikke den ene ud fra den anden. Ved en ja/nej-beslutning skal den rå sandsynlighed bevares sammen med det valgte udfald. Ved et usikkert valg skal du undersøge de konkurrerende sandsynligheder frem for at behandle vinderetiketten alene som evidens for sikkerhed. Definér gennemgangstærskler ud fra konsekvenserne af et forkert positivt eller negativt resultat, og brug repræsentative mærkede tilfælde til at vurdere dem.
Drex 1.5 dokumenterer et tilstandsbudget på 131.072 tokens og et rækkebudget på 139.264 tokens. Rækkebudgettet vedrører tilstanden plus det længste enkelte spørgsmål inklusive instruktioner og svarmuligheder; det er ikke summen af alle spørgsmål i anmodningen. Den serialiserede tilstand og spørgsmålene skal tilsammen også kunne være inden for 1.048.576 UTF-8-bytes. En anmodning kan overholde bytegrænsen og stadig overskride en tokengrænse. Den ældre 1.0-udgave angiver separat 32.768 tokens for både tilstand og række, så dens grænser bør ikke overføres til 1.5.
Nace dokumenterer drex-v1.5 som en versionsbestemt producentidentifikator, mens drex-latest er et skiftende alias. Hold den tilsigtede udgave eksplicit, når en arbejdsgang afhænger af dens grænser. Et forkert formateret spørgsmål, en manglende tilstand eller for stort input er et valideringsproblem, der kræver korrigeret input frem for en ændret kategori eller et gættet svar. Forbered kriterierne ud fra observerbar evidens, og bevar det typede resultat, de oprindelige fakta og spørgsmålsdefinitionen sammen. Det gør beslutningen anvendelig til routing, prioritering eller gennemgang uden at forveksle en sandsynlighed med en garanteret afgørelse.
", "aboutText": "Drex 1.5 er Nace.AI’s tekstbaserede beslutningsmodel. Den vurderer indsendte fakta ud fra lukkede spørgsmål og returnerer numeriske, typede svar frem for et åbent skriftligt svar. En anmodning kombinerer én tilstand med navngivne spørgsmål, og resultatet identificerer hvert svar med det samme spørgsmålsnavn. Det giver en arbejdsgang en konkret kategori, sandsynlighed eller placering i en vurderingsrubrik at bruge, mens applikationen står for den handling, resultatet fører til.\n\n### Forbered tilstanden\n\nTilstanden er den information, som alle spørgsmålene vedrører. Drex accepterer en JSON-streng, et objekt, et array, et tal, en boolesk værdi eller null, og feltet state er påkrævet. Indsend meningsfuld evidens, selv om null består producentens validering. En streng passer til en besked, et dokument eller en transskription; et objekt passer til fakta, der allerede er organiseret i felter. Bevar den information, der påvirker beslutningen, og udelad uvedkommende felter, når materialet er langt. Hold inputformatet stabilt ved fortolkning af sandsynlighedstærskler, fordi en ændret repræsentation kan ændre svaret.\n\nDrex 1.5 læser kun tekst. Den dokumenterede grænseflade afviser billeder, lyd, video og PDF-indhold i både tilstanden og spørgsmålene, herunder kodede medier og objekter med medieindhold. Forbered en billedtekst, genkendt dokumenttekst eller en transskription, før materialet bruges som evidens. En tekstadresse er ikke et hentet dokument eller billede: Modellen kan ikke åbne den. For en supportanmodning er den nyttige tilstand den faktiske besked og relevant kontekst, ikke en henvisning til materiale, modellen ikke har modtaget.\n\n### Ja/nej-sandsynlighed, valg eller score\n\nEt noul-spørgsmål spørger, om en betingelse er opfyldt, og returnerer et tal fra 0 til 1, som repræsenterer den estimerede sandsynlighed for ja. Definér spørgsmålet med ikke-tomme instruktioner eller mindst ét ikke-tomt sand/falsk-kriterium. Spørg eksempelvis, om en besked rapporterer en defekt funktion, og definér, om langsom adfærd tæller som defekt. Drex fastsætter ikke en indbygget ja/nej-grænse; den anvendende arbejdsgang vælger, hvordan sandsynligheden fortolkes.\n\nEt choice-spørgsmål vælger én indsendt etiket fra et uordnet sæt og returnerer en sandsynlighed for hver etiket. Kriterierne er et objekt, hvis nøgler er de returnerede etiketter, og hver beskrivelse er en streng eller null. Brug korte, stabile nøgler, og beskriv kategorigrænser tydeligt. En eksempelopgave til routing kan skelne mellem et adgangsproblem, en produktfejl og et generelt spørgsmål med en other-kategori til beskeder, der ikke passer. Den valgte etiket er nyttig til routing; fordelingen hjælper med at identificere tilfælde, hvor to svarmuligheder stadig er vanskelige at adskille.\n\nEt score-spørgsmål bruger et ordnet array af niveauetiketter. Indeks begynder ved 0, og den returnerede score er summen af hvert niveauindeks ganget med dets sandsynlighed. Den kan derfor ligge mellem navngivne niveauer. Ved en alvorlighedsskala skal du definere, hvad der adskiller et kosmetisk problem, et problem med en omgåelsesmulighed og en fuldstændigt blokeret opgave. Resultatet indeholder niveauernes tegnforklaring og sandsynligheder samt den forventede score. Bevar scoren med decimaler til gennemsnit eller tendenser; valg af det mest sandsynlige niveau og afrunding af den forventede score besvarer forskellige spørgsmål.\n\n### Fælles evidens og læsning af resultatet\n\nProducenten tillader ét til 512 spørgsmål om samme tilstand. Giv hvert spørgsmål en ikke-tom, meningsfuld identifikator, såsom category eller severity, så det tilsvarende svar kan forstås uden at slå et nummereret spørgsmål op. Adskil uafhængige forhold i deres egne spørgsmål frem for at kombinere flere krav i ét uklart kriterium. En enkelt besked kan understøtte et kategorivalg, en alvorlighedsscore og en kontrol af en betingelse, som hver bevarer sin egen betydning.\n\nChoice- og score-svar indeholder konfidens separat fra deres sandsynlighedsfordelinger. Producenten skelner udtrykkeligt mellem konfidens og den højeste sandsynlighed for en svarmulighed; beregn ikke den ene ud fra den anden. Ved en ja/nej-beslutning skal den rå sandsynlighed bevares sammen med det valgte udfald. Ved et usikkert valg skal du undersøge de konkurrerende sandsynligheder frem for at behandle vinderetiketten alene som evidens for sikkerhed. Definér gennemgangstærskler ud fra konsekvenserne af et forkert positivt eller negativt resultat, og brug repræsentative mærkede tilfælde til at vurdere dem.\n\n### Version og størrelsesgrænser\n\nDrex 1.5 dokumenterer et tilstandsbudget på 131.072 tokens og et rækkebudget på 139.264 tokens. Rækkebudgettet vedrører tilstanden plus det længste enkelte spørgsmål inklusive instruktioner og svarmuligheder; det er ikke summen af alle spørgsmål i anmodningen. Den serialiserede tilstand og spørgsmålene skal tilsammen også kunne være inden for 1.048.576 UTF-8-bytes. En anmodning kan overholde bytegrænsen og stadig overskride en tokengrænse. Den ældre 1.0-udgave angiver separat 32.768 tokens for både tilstand og række, så dens grænser bør ikke overføres til 1.5.\n\nNace dokumenterer drex-v1.5 som en versionsbestemt producentidentifikator, mens drex-latest er et skiftende alias. Hold den tilsigtede udgave eksplicit, når en arbejdsgang afhænger af dens grænser. Et forkert formateret spørgsmål, en manglende tilstand eller for stort input er et valideringsproblem, der kræver korrigeret input frem for en ændret kategori eller et gættet svar. Forbered kriterierne ud fra observerbar evidens, og bevar det typede resultat, de oprindelige fakta og spørgsmålsdefinitionen sammen. Det gør beslutningen anvendelig til routing, prioritering eller gennemgang uden at forveksle en sandsynlighed med en garanteret afgørelse.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "e73a79d85767d953e12e3d6d633c6179f319dbc21b59dda8daca3f89187849a9", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "da", "methods": [ { "html": "nace-ai/drex-v1.5Drex 1.5 vurderer indsendt tekst eller JSON ud fra typede spørgsmål og returnerer sandsynligheder, en valgt etiket eller en score med decimaler efter en vurderingsrubrik. Nace.AI dokumenterer beslutninger udelukkende baseret på tekst til klassifikation, routing og prioritering med versionsspecifikke grænser for tilstand og anmodning.
Denne beskrivelse dækker modellens funktioner. Tilgængelige input, output og indstillinger i Ailoot står nedenfor for den valgte metode.
Drex 1.5 er Nace.AI’s tekstbaserede beslutningsmodel. Den vurderer indsendte fakta ud fra lukkede spørgsmål og returnerer numeriske, typede svar frem for et åbent skriftligt svar. En anmodning kombinerer én tilstand med navngivne spørgsmål, og resultatet identificerer hvert svar med det samme spørgsmålsnavn. Det giver en arbejdsgang en konkret kategori, sandsynlighed eller placering i en vurderingsrubrik at bruge, mens applikationen står for den handling, resultatet fører til.
Tilstanden er den information, som alle spørgsmålene vedrører. Drex accepterer en JSON-streng, et objekt, et array, et tal, en boolesk værdi eller null, og feltet state er påkrævet. Indsend meningsfuld evidens, selv om null består producentens validering. En streng passer til en besked, et dokument eller en transskription; et objekt passer til fakta, der allerede er organiseret i felter. Bevar den information, der påvirker beslutningen, og udelad uvedkommende felter, når materialet er langt. Hold inputformatet stabilt ved fortolkning af sandsynlighedstærskler, fordi en ændret repræsentation kan ændre svaret.
Drex 1.5 læser kun tekst. Den dokumenterede grænseflade afviser billeder, lyd, video og PDF-indhold i både tilstanden og spørgsmålene, herunder kodede medier og objekter med medieindhold. Forbered en billedtekst, genkendt dokumenttekst eller en transskription, før materialet bruges som evidens. En tekstadresse er ikke et hentet dokument eller billede: Modellen kan ikke åbne den. For en supportanmodning er den nyttige tilstand den faktiske besked og relevant kontekst, ikke en henvisning til materiale, modellen ikke har modtaget.
Et noul-spørgsmål spørger, om en betingelse er opfyldt, og returnerer et tal fra 0 til 1, som repræsenterer den estimerede sandsynlighed for ja. Definér spørgsmålet med ikke-tomme instruktioner eller mindst ét ikke-tomt sand/falsk-kriterium. Spørg eksempelvis, om en besked rapporterer en defekt funktion, og definér, om langsom adfærd tæller som defekt. Drex fastsætter ikke en indbygget ja/nej-grænse; den anvendende arbejdsgang vælger, hvordan sandsynligheden fortolkes.
Et choice-spørgsmål vælger én indsendt etiket fra et uordnet sæt og returnerer en sandsynlighed for hver etiket. Kriterierne er et objekt, hvis nøgler er de returnerede etiketter, og hver beskrivelse er en streng eller null. Brug korte, stabile nøgler, og beskriv kategorigrænser tydeligt. En eksempelopgave til routing kan skelne mellem et adgangsproblem, en produktfejl og et generelt spørgsmål med en other-kategori til beskeder, der ikke passer. Den valgte etiket er nyttig til routing; fordelingen hjælper med at identificere tilfælde, hvor to svarmuligheder stadig er vanskelige at adskille.
Et score-spørgsmål bruger et ordnet array af niveauetiketter. Indeks begynder ved 0, og den returnerede score er summen af hvert niveauindeks ganget med dets sandsynlighed. Den kan derfor ligge mellem navngivne niveauer. Ved en alvorlighedsskala skal du definere, hvad der adskiller et kosmetisk problem, et problem med en omgåelsesmulighed og en fuldstændigt blokeret opgave. Resultatet indeholder niveauernes tegnforklaring og sandsynligheder samt den forventede score. Bevar scoren med decimaler til gennemsnit eller tendenser; valg af det mest sandsynlige niveau og afrunding af den forventede score besvarer forskellige spørgsmål.
Producenten tillader ét til 512 spørgsmål om samme tilstand. Giv hvert spørgsmål en ikke-tom, meningsfuld identifikator, såsom category eller severity, så det tilsvarende svar kan forstås uden at slå et nummereret spørgsmål op. Adskil uafhængige forhold i deres egne spørgsmål frem for at kombinere flere krav i ét uklart kriterium. En enkelt besked kan understøtte et kategorivalg, en alvorlighedsscore og en kontrol af en betingelse, som hver bevarer sin egen betydning.
Choice- og score-svar indeholder konfidens separat fra deres sandsynlighedsfordelinger. Producenten skelner udtrykkeligt mellem konfidens og den højeste sandsynlighed for en svarmulighed; beregn ikke den ene ud fra den anden. Ved en ja/nej-beslutning skal den rå sandsynlighed bevares sammen med det valgte udfald. Ved et usikkert valg skal du undersøge de konkurrerende sandsynligheder frem for at behandle vinderetiketten alene som evidens for sikkerhed. Definér gennemgangstærskler ud fra konsekvenserne af et forkert positivt eller negativt resultat, og brug repræsentative mærkede tilfælde til at vurdere dem.
Drex 1.5 dokumenterer et tilstandsbudget på 131.072 tokens og et rækkebudget på 139.264 tokens. Rækkebudgettet vedrører tilstanden plus det længste enkelte spørgsmål inklusive instruktioner og svarmuligheder; det er ikke summen af alle spørgsmål i anmodningen. Den serialiserede tilstand og spørgsmålene skal tilsammen også kunne være inden for 1.048.576 UTF-8-bytes. En anmodning kan overholde bytegrænsen og stadig overskride en tokengrænse. Den ældre 1.0-udgave angiver separat 32.768 tokens for både tilstand og række, så dens grænser bør ikke overføres til 1.5.
Nace dokumenterer drex-v1.5 som en versionsbestemt producentidentifikator, mens drex-latest er et skiftende alias. Hold den tilsigtede udgave eksplicit, når en arbejdsgang afhænger af dens grænser. Et forkert formateret spørgsmål, en manglende tilstand eller for stort input er et valideringsproblem, der kræver korrigeret input frem for en ændret kategori eller et gættet svar. Forbered kriterierne ud fra observerbar evidens, og bevar det typede resultat, de oprindelige fakta og spørgsmålsdefinitionen sammen. Det gør beslutningen anvendelig til routing, prioritering eller gennemgang uden at forveksle en sandsynlighed med en garanteret afgørelse.
POST /v1/systemonetextdecisions| Felt | Type | Krav | Værdier og grænser | Standard |
|---|---|---|---|---|
Feltmodel | Typestring | KravPåkrævet | Værdier og grænser nace-ai/drex-v1.5 | 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.00008 / 1K tokens Output · Outputtokens $0 / 1K tokens Input · Cachelæsning — / 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.00008 / 1K tokens Output · Outputtokens $0 / 1K tokens Input · Cachelæsning — / 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": "nace-ai/drex-v1.5",\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']='nace-ai/drex-v1.5'\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 nace-ai/drex-v1.5
Brug metodestierne vist ovenfor.