Kev-4B er en kompakt beslutningsmodell for å besvare typede spørsmål om en oppgitt tilstand. Tilstanden er dokumentet eller posten som vurderes, og hvert spørsmål definerer alternativene modellen kan skåre. Resultatet er en sannsynlighetsfordeling og en typet beslutningspost, noe som gjør modellen nyttig for dokumentklassifisering, ruting, triagering, valg ved uttrekk og kontroller mot angitte kriterier.
Modellen kombinerer en fryst Qwen3.5-4B-Base-ryggrad med en LoRA-adapter og et pekerhode. Ryggraden har 32 lag, bestående av 24 Gated DeltaNet-lag og åtte lag med full oppmerksomhet. Adapteren retter seg mot oppmerksomhets-, MLP- og DeltaNet-projeksjoner; pekerhodet skårer de oppgitte alternativene og gjør skårene om til sannsynligheter. Dette er en beslutningsflyt som bare kjører forhåndsutfyllingen (prefill), der alternativene utgjør svarrommet.
Tre spørsmålstyper kan forekomme i samme forespørsel. Et valgspørsmål tar imot 1–255 navngitte alternativer, eventuelt med beskrivelser, og returnerer det mest sannsynlige alternativet, en separat konfidensverdi og sannsynligheter for alternativene. Et ja/nei-spørsmål, kalt noul i produsentens format, returnerer sannsynligheten for ja. Definer hva ja betyr i spørsmålet, i stedet for å anta at et høyt tall alltid betyr et positivt utfall for applikasjonen.
Et spørsmål med ordnet skår tar imot 1–255 nivåer og returnerer sannsynligheter for nivåene og deres forventede indeks. Nivåindeksene starter på null. Produsentens resultatformat inneholder også nivåforklaringen og en separat konfidensverdi. En forventet indeks kan være ikke-heltallig: den oppsummerer fordelingen over de ordnede nivåene dine i stedet for å velge en ny tekstetikett. Behold nivårekkefølgen og forklaringen sammen med resultatet, slik at en vurdering kan tolkes konsekvent.
Spørsmålene deler den samme tilstanden, men vurderes uavhengig av hverandre. Ett spørsmål kan ikke lese et annet spørsmåls svar, og tilstanden beregnes én gang og brukes på nytt. Hvis en senere beslutning avhenger av resultatet fra en tidligere beslutning, gjør du denne avhengigheten eksplisitt i en påfølgende tilstand i stedet for å forvente at spørsmålene i én forespørsel danner en kjede. Dette gjør flyten med felles tilstand egnet for flere uavhengige kontroller av det samme dokumentet.
Forbered tilstanden med grunnlaget spørsmålene faktisk krever. Den kan være ren tekst eller et JSON-objekt eller en JSON-matrise gjengitt som merket tekst. Hold feltnavn, enheter, vilkår i retningslinjer og de relevante kildeavsnittene tydelige. Skriv en spesifikk instruksjon for hvert spørsmål, og gi alternativene betydninger som kan skilles fra hverandre ut fra posten. For en egenutviklet oppgave med ruting av supporthenvendelser kan tilstanden inneholde henvendelsen og konteksten, mens valgene definerer kategorier for levering, tilgang og produktstøtte med korte beskrivelser.
Et annet spørsmål kan vurdere hastegrad, og et ordnet spørsmål kan angi hvor mye oppfølging henvendelsen trenger. Disse besvarer ulike operative spørsmål, så definer hvert av dem separat. Ta med et passende alternativ for gjennomgang eller manglende grunnlag når valgoppgaven trenger det, og behold hele fordelingen når flere kategorier er plausible. Applikasjonen avgjør hvordan et resultat skal rutes eller gjennomgås; modellen leverer den skårede posten.
Kev-4B er beregnet på typede beslutninger over dokumenter på noen få tusen tokener. Produsentens driftsprofil tar imot tilstander på opptil 65 536 tokener og reserverer ekstra plass til hvert spørsmål, mens den validerte kontekstlengden for dette sjekkpunktet er 8192 tokener. Dette er ulike grenser: at en lengre tilstand godtas, viser ikke at beslutningene er like pålitelige ved alle lengder. Hold avgjørende avsnitt kompakte og bevar etikettene deres når du forbereder en lang post for klassifisering.
Den utgitte profilen er engelskspråklig. De nyttige oppgavene avhenger av grunnlaget i den oppgitte tilstanden og av de definerte alternativene, ikke av åpen chat, oppsummering eller bred kunnskapsbasert besvarelse. Datoregning på dagsnivå er en særskilt begrensning: produsenten leverer en egen forbehandler for datofakta som oppgir beregnede intervaller. For en fristkontroll tar du med de relevante datoene og de beregnede dagintervallene i tilstanden, sammen med regelen som bruker dem.
Sjekkpunktet leveres med tilpasset sannsynlighetskalibrering, men konfidensen kan endre seg med dokumentdomenet og utformingen av spørsmålene. Produsenten dokumenterer også finjustering av det åpne sjekkpunktet på oppgavespesifikke etiketter og tilpasning av sannsynlighetskalibreringen til den aktuelle arbeidsmengden; dette er en egen tilpasningsflyt, atskilt fra skåring av en oppgitt tilstand. Velg beslutningsterskler ved hjelp av merkede eksempler fra den faktiske arbeidsmengden, og hold usikre tilfeller synlige for gjennomgang. Produsenten utelukker helautomatiserte, konsekvensfulle beslutninger om mennesker uten menneskelig gjennomgang. Rekkefølgen på alternativene kan også påvirke et svar, så behold en stabil rekkefølge når du sammenligner resultater. Vurder den valgte etiketten, det separate konfidensfeltet og sannsynlighetsfordelingen ut fra rollen hver av dem har i arbeidsflyten din.
Den gjeldende Kev-4B-utgivelsen som produsenten beskriver, tilhører Kev 1.0 og bruker Qwen3.5-basen. Tidligere utgivelser basert på Qwen3 og utgivelser kun for dokumentstadiet er fortsatt egne versjoner. Hold den valgte utgaven og spørsmålsdefinisjonene knyttet til utdataene når du utvikler en oppgavespesifikk arbeidsflyt, i stedet for å blande resultater fra ulike profiler.
Et nyttig sluttresultat er et navngitt sett med beslutningsposter med de opprinnelige spørsmålene, definisjonene av alternativene, fordelingene og eventuelle forklaringer til ordnede nivåer. For en kontroll av svarkvalitet bør tilstanden inneholde det foreslåtte svaret, grunnlaget og kriteriet som testes. For triagering etter retningslinjer bør den inneholde den gjeldende regelen og relevante fakta. Ta vare på disse inndataene ved siden av resultatet, slik at en gjennomgang kan fastslå hvorfor en beslutning var riktig, eller hvilket manglende faktum som må tilføres.
", "aboutText": "Kev-4B er en kompakt beslutningsmodell for å besvare typede spørsmål om en oppgitt tilstand. Tilstanden er dokumentet eller posten som vurderes, og hvert spørsmål definerer alternativene modellen kan skåre. Resultatet er en sannsynlighetsfordeling og en typet beslutningspost, noe som gjør modellen nyttig for dokumentklassifisering, ruting, triagering, valg ved uttrekk og kontroller mot angitte kriterier.\n\nModellen kombinerer en fryst Qwen3.5-4B-Base-ryggrad med en LoRA-adapter og et pekerhode. Ryggraden har 32 lag, bestående av 24 Gated DeltaNet-lag og åtte lag med full oppmerksomhet. Adapteren retter seg mot oppmerksomhets-, MLP- og DeltaNet-projeksjoner; pekerhodet skårer de oppgitte alternativene og gjør skårene om til sannsynligheter. Dette er en beslutningsflyt som bare kjører forhåndsutfyllingen (prefill), der alternativene utgjør svarrommet.\n\nTre spørsmålstyper kan forekomme i samme forespørsel. Et valgspørsmål tar imot 1–255 navngitte alternativer, eventuelt med beskrivelser, og returnerer det mest sannsynlige alternativet, en separat konfidensverdi og sannsynligheter for alternativene. Et ja/nei-spørsmål, kalt noul i produsentens format, returnerer sannsynligheten for ja. Definer hva ja betyr i spørsmålet, i stedet for å anta at et høyt tall alltid betyr et positivt utfall for applikasjonen.\n\nEt spørsmål med ordnet skår tar imot 1–255 nivåer og returnerer sannsynligheter for nivåene og deres forventede indeks. Nivåindeksene starter på null. Produsentens resultatformat inneholder også nivåforklaringen og en separat konfidensverdi. En forventet indeks kan være ikke-heltallig: den oppsummerer fordelingen over de ordnede nivåene dine i stedet for å velge en ny tekstetikett. Behold nivårekkefølgen og forklaringen sammen med resultatet, slik at en vurdering kan tolkes konsekvent.\n\nSpørsmålene deler den samme tilstanden, men vurderes uavhengig av hverandre. Ett spørsmål kan ikke lese et annet spørsmåls svar, og tilstanden beregnes én gang og brukes på nytt. Hvis en senere beslutning avhenger av resultatet fra en tidligere beslutning, gjør du denne avhengigheten eksplisitt i en påfølgende tilstand i stedet for å forvente at spørsmålene i én forespørsel danner en kjede. Dette gjør flyten med felles tilstand egnet for flere uavhengige kontroller av det samme dokumentet.\n\nForbered tilstanden med grunnlaget spørsmålene faktisk krever. Den kan være ren tekst eller et JSON-objekt eller en JSON-matrise gjengitt som merket tekst. Hold feltnavn, enheter, vilkår i retningslinjer og de relevante kildeavsnittene tydelige. Skriv en spesifikk instruksjon for hvert spørsmål, og gi alternativene betydninger som kan skilles fra hverandre ut fra posten. For en egenutviklet oppgave med ruting av supporthenvendelser kan tilstanden inneholde henvendelsen og konteksten, mens valgene definerer kategorier for levering, tilgang og produktstøtte med korte beskrivelser.\n\nEt annet spørsmål kan vurdere hastegrad, og et ordnet spørsmål kan angi hvor mye oppfølging henvendelsen trenger. Disse besvarer ulike operative spørsmål, så definer hvert av dem separat. Ta med et passende alternativ for gjennomgang eller manglende grunnlag når valgoppgaven trenger det, og behold hele fordelingen når flere kategorier er plausible. Applikasjonen avgjør hvordan et resultat skal rutes eller gjennomgås; modellen leverer den skårede posten.\n\nKev-4B er beregnet på typede beslutninger over dokumenter på noen få tusen tokener. Produsentens driftsprofil tar imot tilstander på opptil 65 536 tokener og reserverer ekstra plass til hvert spørsmål, mens den validerte kontekstlengden for dette sjekkpunktet er 8192 tokener. Dette er ulike grenser: at en lengre tilstand godtas, viser ikke at beslutningene er like pålitelige ved alle lengder. Hold avgjørende avsnitt kompakte og bevar etikettene deres når du forbereder en lang post for klassifisering.\n\nDen utgitte profilen er engelskspråklig. De nyttige oppgavene avhenger av grunnlaget i den oppgitte tilstanden og av de definerte alternativene, ikke av åpen chat, oppsummering eller bred kunnskapsbasert besvarelse. Datoregning på dagsnivå er en særskilt begrensning: produsenten leverer en egen forbehandler for datofakta som oppgir beregnede intervaller. For en fristkontroll tar du med de relevante datoene og de beregnede dagintervallene i tilstanden, sammen med regelen som bruker dem.\n\nSjekkpunktet leveres med tilpasset sannsynlighetskalibrering, men konfidensen kan endre seg med dokumentdomenet og utformingen av spørsmålene. Produsenten dokumenterer også finjustering av det åpne sjekkpunktet på oppgavespesifikke etiketter og tilpasning av sannsynlighetskalibreringen til den aktuelle arbeidsmengden; dette er en egen tilpasningsflyt, atskilt fra skåring av en oppgitt tilstand. Velg beslutningsterskler ved hjelp av merkede eksempler fra den faktiske arbeidsmengden, og hold usikre tilfeller synlige for gjennomgang. Produsenten utelukker helautomatiserte, konsekvensfulle beslutninger om mennesker uten menneskelig gjennomgang. Rekkefølgen på alternativene kan også påvirke et svar, så behold en stabil rekkefølge når du sammenligner resultater. Vurder den valgte etiketten, det separate konfidensfeltet og sannsynlighetsfordelingen ut fra rollen hver av dem har i arbeidsflyten din.\n\nDen gjeldende Kev-4B-utgivelsen som produsenten beskriver, tilhører Kev 1.0 og bruker Qwen3.5-basen. Tidligere utgivelser basert på Qwen3 og utgivelser kun for dokumentstadiet er fortsatt egne versjoner. Hold den valgte utgaven og spørsmålsdefinisjonene knyttet til utdataene når du utvikler en oppgavespesifikk arbeidsflyt, i stedet for å blande resultater fra ulike profiler.\n\nEt nyttig sluttresultat er et navngitt sett med beslutningsposter med de opprinnelige spørsmålene, definisjonene av alternativene, fordelingene og eventuelle forklaringer til ordnede nivåer. For en kontroll av svarkvalitet bør tilstanden inneholde det foreslåtte svaret, grunnlaget og kriteriet som testes. For triagering etter retningslinjer bør den inneholde den gjeldende regelen og relevante fakta. Ta vare på disse inndataene ved siden av resultatet, slik at en gjennomgang kan fastslå hvorfor en beslutning var riktig, eller hvilket manglende faktum som må tilføres.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "97f724e696607041baf773901dd958fc49d5d82f3765ba15266002300663a2c8", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "nb", "methods": [ { "html": "jaredpalmer/kev-4bKev-4B skårer typede spørsmål om et oppgitt engelskspråklig dokument og returnerer kalibrerte sannsynligheter over alternativene du definerer. Bruk ja/nei-spørsmål, valgspørsmål og spørsmål med ordnet skår til klassifisering, ruting, triagering og kontroller som krever en strukturert beslutning i stedet for generert prosa.
Denne beskrivelsen dekker modellens funksjoner. Tilgjengelige inndata, utdata og alternativer i Ailoot er oppført nedenfor for den valgte metoden.
Kev-4B er en kompakt beslutningsmodell for å besvare typede spørsmål om en oppgitt tilstand. Tilstanden er dokumentet eller posten som vurderes, og hvert spørsmål definerer alternativene modellen kan skåre. Resultatet er en sannsynlighetsfordeling og en typet beslutningspost, noe som gjør modellen nyttig for dokumentklassifisering, ruting, triagering, valg ved uttrekk og kontroller mot angitte kriterier.
Modellen kombinerer en fryst Qwen3.5-4B-Base-ryggrad med en LoRA-adapter og et pekerhode. Ryggraden har 32 lag, bestående av 24 Gated DeltaNet-lag og åtte lag med full oppmerksomhet. Adapteren retter seg mot oppmerksomhets-, MLP- og DeltaNet-projeksjoner; pekerhodet skårer de oppgitte alternativene og gjør skårene om til sannsynligheter. Dette er en beslutningsflyt som bare kjører forhåndsutfyllingen (prefill), der alternativene utgjør svarrommet.
Tre spørsmålstyper kan forekomme i samme forespørsel. Et valgspørsmål tar imot 1–255 navngitte alternativer, eventuelt med beskrivelser, og returnerer det mest sannsynlige alternativet, en separat konfidensverdi og sannsynligheter for alternativene. Et ja/nei-spørsmål, kalt noul i produsentens format, returnerer sannsynligheten for ja. Definer hva ja betyr i spørsmålet, i stedet for å anta at et høyt tall alltid betyr et positivt utfall for applikasjonen.
Et spørsmål med ordnet skår tar imot 1–255 nivåer og returnerer sannsynligheter for nivåene og deres forventede indeks. Nivåindeksene starter på null. Produsentens resultatformat inneholder også nivåforklaringen og en separat konfidensverdi. En forventet indeks kan være ikke-heltallig: den oppsummerer fordelingen over de ordnede nivåene dine i stedet for å velge en ny tekstetikett. Behold nivårekkefølgen og forklaringen sammen med resultatet, slik at en vurdering kan tolkes konsekvent.
Spørsmålene deler den samme tilstanden, men vurderes uavhengig av hverandre. Ett spørsmål kan ikke lese et annet spørsmåls svar, og tilstanden beregnes én gang og brukes på nytt. Hvis en senere beslutning avhenger av resultatet fra en tidligere beslutning, gjør du denne avhengigheten eksplisitt i en påfølgende tilstand i stedet for å forvente at spørsmålene i én forespørsel danner en kjede. Dette gjør flyten med felles tilstand egnet for flere uavhengige kontroller av det samme dokumentet.
Forbered tilstanden med grunnlaget spørsmålene faktisk krever. Den kan være ren tekst eller et JSON-objekt eller en JSON-matrise gjengitt som merket tekst. Hold feltnavn, enheter, vilkår i retningslinjer og de relevante kildeavsnittene tydelige. Skriv en spesifikk instruksjon for hvert spørsmål, og gi alternativene betydninger som kan skilles fra hverandre ut fra posten. For en egenutviklet oppgave med ruting av supporthenvendelser kan tilstanden inneholde henvendelsen og konteksten, mens valgene definerer kategorier for levering, tilgang og produktstøtte med korte beskrivelser.
Et annet spørsmål kan vurdere hastegrad, og et ordnet spørsmål kan angi hvor mye oppfølging henvendelsen trenger. Disse besvarer ulike operative spørsmål, så definer hvert av dem separat. Ta med et passende alternativ for gjennomgang eller manglende grunnlag når valgoppgaven trenger det, og behold hele fordelingen når flere kategorier er plausible. Applikasjonen avgjør hvordan et resultat skal rutes eller gjennomgås; modellen leverer den skårede posten.
Kev-4B er beregnet på typede beslutninger over dokumenter på noen få tusen tokener. Produsentens driftsprofil tar imot tilstander på opptil 65 536 tokener og reserverer ekstra plass til hvert spørsmål, mens den validerte kontekstlengden for dette sjekkpunktet er 8192 tokener. Dette er ulike grenser: at en lengre tilstand godtas, viser ikke at beslutningene er like pålitelige ved alle lengder. Hold avgjørende avsnitt kompakte og bevar etikettene deres når du forbereder en lang post for klassifisering.
Den utgitte profilen er engelskspråklig. De nyttige oppgavene avhenger av grunnlaget i den oppgitte tilstanden og av de definerte alternativene, ikke av åpen chat, oppsummering eller bred kunnskapsbasert besvarelse. Datoregning på dagsnivå er en særskilt begrensning: produsenten leverer en egen forbehandler for datofakta som oppgir beregnede intervaller. For en fristkontroll tar du med de relevante datoene og de beregnede dagintervallene i tilstanden, sammen med regelen som bruker dem.
Sjekkpunktet leveres med tilpasset sannsynlighetskalibrering, men konfidensen kan endre seg med dokumentdomenet og utformingen av spørsmålene. Produsenten dokumenterer også finjustering av det åpne sjekkpunktet på oppgavespesifikke etiketter og tilpasning av sannsynlighetskalibreringen til den aktuelle arbeidsmengden; dette er en egen tilpasningsflyt, atskilt fra skåring av en oppgitt tilstand. Velg beslutningsterskler ved hjelp av merkede eksempler fra den faktiske arbeidsmengden, og hold usikre tilfeller synlige for gjennomgang. Produsenten utelukker helautomatiserte, konsekvensfulle beslutninger om mennesker uten menneskelig gjennomgang. Rekkefølgen på alternativene kan også påvirke et svar, så behold en stabil rekkefølge når du sammenligner resultater. Vurder den valgte etiketten, det separate konfidensfeltet og sannsynlighetsfordelingen ut fra rollen hver av dem har i arbeidsflyten din.
Den gjeldende Kev-4B-utgivelsen som produsenten beskriver, tilhører Kev 1.0 og bruker Qwen3.5-basen. Tidligere utgivelser basert på Qwen3 og utgivelser kun for dokumentstadiet er fortsatt egne versjoner. Hold den valgte utgaven og spørsmålsdefinisjonene knyttet til utdataene når du utvikler en oppgavespesifikk arbeidsflyt, i stedet for å blande resultater fra ulike profiler.
Et nyttig sluttresultat er et navngitt sett med beslutningsposter med de opprinnelige spørsmålene, definisjonene av alternativene, fordelingene og eventuelle forklaringer til ordnede nivåer. For en kontroll av svarkvalitet bør tilstanden inneholde det foreslåtte svaret, grunnlaget og kriteriet som testes. For triagering etter retningslinjer bør den inneholde den gjeldende regelen og relevante fakta. Ta vare på disse inndataene ved siden av resultatet, slik at en gjennomgang kan fastslå hvorfor en beslutning var riktig, eller hvilket manglende faktum som må tilføres.
POST /v1/systemonetextdecisions| Felt | Type | Krav | Verdier & grenser | Standard |
|---|---|---|---|---|
Feltmodel | Typestring | KravPåkrevd | Verdier & grenser jaredpalmer/kev-4b | 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.000084 / 1K tokener Utdata · Utgående tokener $0 / 1K tokener Inndata · Lesing fra hurtigbuffer — / 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.000084 / 1K tokener Utdata · Utgående tokener $0 / 1K tokener Inndata · Lesing fra hurtigbuffer — / 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": "jaredpalmer/kev-4b",\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']='jaredpalmer/kev-4b'\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 jaredpalmer/kev-4b
Bruk metodestiene som vises ovenfor.