Kev-4B er en kompakt beslutningsmodel til at besvare typede spørgsmål om en indsendt tilstand. Tilstanden er det dokument eller den post, der vurderes, og hvert spørgsmål definerer de svarmuligheder, modellen kan score. Resultatet er en sandsynlighedsfordeling og en typet beslutningsregistrering, hvilket gør modellen nyttig til dokumentklassifikation, routing, triage, valg ved udtræk og kontroller ud fra angivne kriterier.
Modellen kombinerer en frossen Qwen3.5-4B-Base-grundmodel med en LoRA-adapter og et pointer-hoved. Grundmodellen har 32 lag, bestående af 24 Gated DeltaNet-lag og otte full-attention-lag. Adapteren er rettet mod attention-, MLP- og DeltaNet-projektioner; pointer-hovedet scorer de indsendte svarmuligheder og omdanner scorerne til sandsynligheder. Dette er en beslutningsarbejdsgang, som kun udfører prefill, hvor svarmulighederne udgør svarrummet.
Tre spørgsmålstyper kan forekomme i samme anmodning. Et choice-spørgsmål accepterer 1–255 navngivne svarmuligheder, eventuelt med beskrivelser, og returnerer den mest sandsynlige mulighed, en separat konfidensværdi og sandsynligheder for mulighederne. Et ja/nej-spørgsmål, kaldet noul i producentens format, returnerer sandsynligheden for ja. Definér betydningen af ja i spørgsmålet frem for at antage, at et højt tal altid betyder et positivt udfald for applikationen.
Et ordnet score-spørgsmål accepterer 1–255 niveauer og returnerer sandsynligheder for niveauerne og deres forventede indeks. Niveauindeks begynder ved nul. Producentens resultatformat indeholder også niveauernes tegnforklaring og en separat konfidensværdi. Et forventet indeks kan have decimaler: Det sammenfatter fordelingen over dine ordnede niveauer frem for at vælge en ny tekstetiket. Gem niveaurækkefølgen og tegnforklaringen sammen med resultatet, så en vurdering kan fortolkes konsekvent.
Spørgsmålene deler samme tilstand, men vurderes uafhængigt. Ét spørgsmål kan ikke læse et andet spørgsmåls svar, og tilstanden beregnes én gang og genbruges. Hvis en senere beslutning afhænger af resultatet fra en tidligere beslutning, skal afhængigheden gøres eksplicit i en efterfølgende tilstand frem for at forvente, at spørgsmålene i én anmodning danner en kæde. Det gør arbejdsgangen med fælles tilstand egnet til flere uafhængige kontroller af samme dokument.
Forbered tilstanden med den evidens, spørgsmålene faktisk kræver. Den kan være almindelig tekst eller et JSON-objekt eller -array gengivet som mærket tekst. Hold feltnavne, enheder, regelbetingelser og relevante kildepassager tydelige. Skriv en konkret instruktion til hvert spørgsmål, og giv dets svarmuligheder betydninger, der kan skelnes ud fra posten. Ved en selvstændig supportroutingopgave kan tilstanden indeholde anmodningen og dens kontekst, mens svarmulighederne definerer kategorier for levering, adgang og produktsupport med korte beskrivelser.
Et andet spørgsmål kan vurdere hast, og et ordnet spørgsmål kan vurdere, hvor meget opfølgning anmodningen kræver. Disse besvarer forskellige operationelle spørgsmål, så definér dem hver for sig. Medtag en passende mulighed for gennemgang eller manglende evidens, når valgopgaven har brug for det, og bevar hele fordelingen, når flere kategorier er plausible. Applikationen afgør, hvordan et resultat routes eller gennemgås; modellen leverer den scorede registrering.
Kev-4B er beregnet til typede beslutninger over dokumenter på nogle få tusinde tokens. Producentens serveringsprofil accepterer tilstande på op til 65.536 tokens og reserverer yderligere plads til hvert spørgsmål, mens den validerede kontekstlængde for dette checkpoint er 8192 tokens. Det er forskellige grænser: At acceptere en længere tilstand fastslår ikke lige pålidelige beslutninger ved enhver længde. Hold afgørende passager kompakte, og bevar deres etiketter, når du forbereder en lang post til klassifikation.
Den udgivne profil er engelsksproget. Dens nyttige opgaver afhænger af evidens i den indsendte tilstand og de definerede svarmuligheder frem for åben chat, opsummering eller brede vidensbaserede svar. Datoberegning på dagsniveau er en særlig begrænsning: Producenten leverer en separat forbehandler til datofakta, som angiver beregnede intervaller. Ved en fristkontrol skal relevante datoer og beregnede dagintervaller medtages i tilstanden sammen med den regel, der bruger dem.
Checkpointet leveres med tilpasset sandsynlighedskalibrering, men konfidens kan ændre sig med dokumentdomæne og spørgsmålsdesign. Producenten dokumenterer også finjustering af det åbne checkpoint på opgavespecifikke etiketter og tilpasning af sandsynlighedskalibreringen til de pågældende opgaver; det er en separat tilpasningsarbejdsgang i forhold til scoring af en indsendt tilstand. Vælg beslutningstærskler med mærkede eksempler på de faktiske opgaver, og hold usikre tilfælde synlige til gennemgang. Producenten udelukker fuldautomatiske beslutninger med væsentlige konsekvenser for mennesker uden menneskelig gennemgang. Svarmulighedernes rækkefølge kan også påvirke et svar, så bevar en stabil rækkefølge ved sammenligning af resultater. Vurdér den valgte etiket, det separate konfidensfelt og sandsynlighedsfordelingen ud fra den rolle, de hver især spiller i arbejdsgangen.
Den aktuelle Kev-4B-udgivelse beskrevet af producenten tilhører Kev 1.0 og bruger Qwen3.5-grundmodellen. Tidligere Qwen3-baserede udgivelser og udgivelser begrænset til dokumentstadiet er fortsat særskilte versioner. Hold den valgte udgave og spørgsmålsdefinitionerne knyttet til outputtene ved udvikling af en opgavespecifik arbejdsgang frem for at blande resultater fra forskellige profiler.
Et nyttigt endeligt resultat er et navngivet sæt beslutningsregistreringer med de oprindelige spørgsmål, svarmulighedernes definitioner, fordelinger og eventuelle tegnforklaringer til ordnede niveauer. Ved en kontrol af svarkvalitet bør tilstanden indeholde svarforslaget, evidensen og det kriterium, der testes. Ved regeltriage bør den indeholde den gældende regel og relevante fakta. Bevar inputtet ved siden af resultatet, så en gennemgang kan fastslå, hvorfor en beslutning var passende, eller hvilket manglende forhold der skal tilføjes.
", "aboutText": "Kev-4B er en kompakt beslutningsmodel til at besvare typede spørgsmål om en indsendt tilstand. Tilstanden er det dokument eller den post, der vurderes, og hvert spørgsmål definerer de svarmuligheder, modellen kan score. Resultatet er en sandsynlighedsfordeling og en typet beslutningsregistrering, hvilket gør modellen nyttig til dokumentklassifikation, routing, triage, valg ved udtræk og kontroller ud fra angivne kriterier.\n\nModellen kombinerer en frossen Qwen3.5-4B-Base-grundmodel med en LoRA-adapter og et pointer-hoved. Grundmodellen har 32 lag, bestående af 24 Gated DeltaNet-lag og otte full-attention-lag. Adapteren er rettet mod attention-, MLP- og DeltaNet-projektioner; pointer-hovedet scorer de indsendte svarmuligheder og omdanner scorerne til sandsynligheder. Dette er en beslutningsarbejdsgang, som kun udfører prefill, hvor svarmulighederne udgør svarrummet.\n\nTre spørgsmålstyper kan forekomme i samme anmodning. Et choice-spørgsmål accepterer 1–255 navngivne svarmuligheder, eventuelt med beskrivelser, og returnerer den mest sandsynlige mulighed, en separat konfidensværdi og sandsynligheder for mulighederne. Et ja/nej-spørgsmål, kaldet noul i producentens format, returnerer sandsynligheden for ja. Definér betydningen af ja i spørgsmålet frem for at antage, at et højt tal altid betyder et positivt udfald for applikationen.\n\nEt ordnet score-spørgsmål accepterer 1–255 niveauer og returnerer sandsynligheder for niveauerne og deres forventede indeks. Niveauindeks begynder ved nul. Producentens resultatformat indeholder også niveauernes tegnforklaring og en separat konfidensværdi. Et forventet indeks kan have decimaler: Det sammenfatter fordelingen over dine ordnede niveauer frem for at vælge en ny tekstetiket. Gem niveaurækkefølgen og tegnforklaringen sammen med resultatet, så en vurdering kan fortolkes konsekvent.\n\nSpørgsmålene deler samme tilstand, men vurderes uafhængigt. Ét spørgsmål kan ikke læse et andet spørgsmåls svar, og tilstanden beregnes én gang og genbruges. Hvis en senere beslutning afhænger af resultatet fra en tidligere beslutning, skal afhængigheden gøres eksplicit i en efterfølgende tilstand frem for at forvente, at spørgsmålene i én anmodning danner en kæde. Det gør arbejdsgangen med fælles tilstand egnet til flere uafhængige kontroller af samme dokument.\n\nForbered tilstanden med den evidens, spørgsmålene faktisk kræver. Den kan være almindelig tekst eller et JSON-objekt eller -array gengivet som mærket tekst. Hold feltnavne, enheder, regelbetingelser og relevante kildepassager tydelige. Skriv en konkret instruktion til hvert spørgsmål, og giv dets svarmuligheder betydninger, der kan skelnes ud fra posten. Ved en selvstændig supportroutingopgave kan tilstanden indeholde anmodningen og dens kontekst, mens svarmulighederne definerer kategorier for levering, adgang og produktsupport med korte beskrivelser.\n\nEt andet spørgsmål kan vurdere hast, og et ordnet spørgsmål kan vurdere, hvor meget opfølgning anmodningen kræver. Disse besvarer forskellige operationelle spørgsmål, så definér dem hver for sig. Medtag en passende mulighed for gennemgang eller manglende evidens, når valgopgaven har brug for det, og bevar hele fordelingen, når flere kategorier er plausible. Applikationen afgør, hvordan et resultat routes eller gennemgås; modellen leverer den scorede registrering.\n\nKev-4B er beregnet til typede beslutninger over dokumenter på nogle få tusinde tokens. Producentens serveringsprofil accepterer tilstande på op til 65.536 tokens og reserverer yderligere plads til hvert spørgsmål, mens den validerede kontekstlængde for dette checkpoint er 8192 tokens. Det er forskellige grænser: At acceptere en længere tilstand fastslår ikke lige pålidelige beslutninger ved enhver længde. Hold afgørende passager kompakte, og bevar deres etiketter, når du forbereder en lang post til klassifikation.\n\nDen udgivne profil er engelsksproget. Dens nyttige opgaver afhænger af evidens i den indsendte tilstand og de definerede svarmuligheder frem for åben chat, opsummering eller brede vidensbaserede svar. Datoberegning på dagsniveau er en særlig begrænsning: Producenten leverer en separat forbehandler til datofakta, som angiver beregnede intervaller. Ved en fristkontrol skal relevante datoer og beregnede dagintervaller medtages i tilstanden sammen med den regel, der bruger dem.\n\nCheckpointet leveres med tilpasset sandsynlighedskalibrering, men konfidens kan ændre sig med dokumentdomæne og spørgsmålsdesign. Producenten dokumenterer også finjustering af det åbne checkpoint på opgavespecifikke etiketter og tilpasning af sandsynlighedskalibreringen til de pågældende opgaver; det er en separat tilpasningsarbejdsgang i forhold til scoring af en indsendt tilstand. Vælg beslutningstærskler med mærkede eksempler på de faktiske opgaver, og hold usikre tilfælde synlige til gennemgang. Producenten udelukker fuldautomatiske beslutninger med væsentlige konsekvenser for mennesker uden menneskelig gennemgang. Svarmulighedernes rækkefølge kan også påvirke et svar, så bevar en stabil rækkefølge ved sammenligning af resultater. Vurdér den valgte etiket, det separate konfidensfelt og sandsynlighedsfordelingen ud fra den rolle, de hver især spiller i arbejdsgangen.\n\nDen aktuelle Kev-4B-udgivelse beskrevet af producenten tilhører Kev 1.0 og bruger Qwen3.5-grundmodellen. Tidligere Qwen3-baserede udgivelser og udgivelser begrænset til dokumentstadiet er fortsat særskilte versioner. Hold den valgte udgave og spørgsmålsdefinitionerne knyttet til outputtene ved udvikling af en opgavespecifik arbejdsgang frem for at blande resultater fra forskellige profiler.\n\nEt nyttigt endeligt resultat er et navngivet sæt beslutningsregistreringer med de oprindelige spørgsmål, svarmulighedernes definitioner, fordelinger og eventuelle tegnforklaringer til ordnede niveauer. Ved en kontrol af svarkvalitet bør tilstanden indeholde svarforslaget, evidensen og det kriterium, der testes. Ved regeltriage bør den indeholde den gældende regel og relevante fakta. Bevar inputtet ved siden af resultatet, så en gennemgang kan fastslå, hvorfor en beslutning var passende, eller hvilket manglende forhold der skal tilføjes.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "5017ca0b14afe653f46ac5c602fa1022f0441a2dfbbe8455f3f865feeb69f8cb", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "da", "methods": [ { "html": "jaredpalmer/kev-4bKev-4B scorer typede spørgsmål om et indsendt engelsksproget dokument og returnerer kalibrerede sandsynligheder for de svarmuligheder, du definerer. Brug ja/nej-, choice- og ordnede score-spørgsmål til klassifikation, routing, triage og kontroller, der kræver en struktureret beslutning 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.
Kev-4B er en kompakt beslutningsmodel til at besvare typede spørgsmål om en indsendt tilstand. Tilstanden er det dokument eller den post, der vurderes, og hvert spørgsmål definerer de svarmuligheder, modellen kan score. Resultatet er en sandsynlighedsfordeling og en typet beslutningsregistrering, hvilket gør modellen nyttig til dokumentklassifikation, routing, triage, valg ved udtræk og kontroller ud fra angivne kriterier.
Modellen kombinerer en frossen Qwen3.5-4B-Base-grundmodel med en LoRA-adapter og et pointer-hoved. Grundmodellen har 32 lag, bestående af 24 Gated DeltaNet-lag og otte full-attention-lag. Adapteren er rettet mod attention-, MLP- og DeltaNet-projektioner; pointer-hovedet scorer de indsendte svarmuligheder og omdanner scorerne til sandsynligheder. Dette er en beslutningsarbejdsgang, som kun udfører prefill, hvor svarmulighederne udgør svarrummet.
Tre spørgsmålstyper kan forekomme i samme anmodning. Et choice-spørgsmål accepterer 1–255 navngivne svarmuligheder, eventuelt med beskrivelser, og returnerer den mest sandsynlige mulighed, en separat konfidensværdi og sandsynligheder for mulighederne. Et ja/nej-spørgsmål, kaldet noul i producentens format, returnerer sandsynligheden for ja. Definér betydningen af ja i spørgsmålet frem for at antage, at et højt tal altid betyder et positivt udfald for applikationen.
Et ordnet score-spørgsmål accepterer 1–255 niveauer og returnerer sandsynligheder for niveauerne og deres forventede indeks. Niveauindeks begynder ved nul. Producentens resultatformat indeholder også niveauernes tegnforklaring og en separat konfidensværdi. Et forventet indeks kan have decimaler: Det sammenfatter fordelingen over dine ordnede niveauer frem for at vælge en ny tekstetiket. Gem niveaurækkefølgen og tegnforklaringen sammen med resultatet, så en vurdering kan fortolkes konsekvent.
Spørgsmålene deler samme tilstand, men vurderes uafhængigt. Ét spørgsmål kan ikke læse et andet spørgsmåls svar, og tilstanden beregnes én gang og genbruges. Hvis en senere beslutning afhænger af resultatet fra en tidligere beslutning, skal afhængigheden gøres eksplicit i en efterfølgende tilstand frem for at forvente, at spørgsmålene i én anmodning danner en kæde. Det gør arbejdsgangen med fælles tilstand egnet til flere uafhængige kontroller af samme dokument.
Forbered tilstanden med den evidens, spørgsmålene faktisk kræver. Den kan være almindelig tekst eller et JSON-objekt eller -array gengivet som mærket tekst. Hold feltnavne, enheder, regelbetingelser og relevante kildepassager tydelige. Skriv en konkret instruktion til hvert spørgsmål, og giv dets svarmuligheder betydninger, der kan skelnes ud fra posten. Ved en selvstændig supportroutingopgave kan tilstanden indeholde anmodningen og dens kontekst, mens svarmulighederne definerer kategorier for levering, adgang og produktsupport med korte beskrivelser.
Et andet spørgsmål kan vurdere hast, og et ordnet spørgsmål kan vurdere, hvor meget opfølgning anmodningen kræver. Disse besvarer forskellige operationelle spørgsmål, så definér dem hver for sig. Medtag en passende mulighed for gennemgang eller manglende evidens, når valgopgaven har brug for det, og bevar hele fordelingen, når flere kategorier er plausible. Applikationen afgør, hvordan et resultat routes eller gennemgås; modellen leverer den scorede registrering.
Kev-4B er beregnet til typede beslutninger over dokumenter på nogle få tusinde tokens. Producentens serveringsprofil accepterer tilstande på op til 65.536 tokens og reserverer yderligere plads til hvert spørgsmål, mens den validerede kontekstlængde for dette checkpoint er 8192 tokens. Det er forskellige grænser: At acceptere en længere tilstand fastslår ikke lige pålidelige beslutninger ved enhver længde. Hold afgørende passager kompakte, og bevar deres etiketter, når du forbereder en lang post til klassifikation.
Den udgivne profil er engelsksproget. Dens nyttige opgaver afhænger af evidens i den indsendte tilstand og de definerede svarmuligheder frem for åben chat, opsummering eller brede vidensbaserede svar. Datoberegning på dagsniveau er en særlig begrænsning: Producenten leverer en separat forbehandler til datofakta, som angiver beregnede intervaller. Ved en fristkontrol skal relevante datoer og beregnede dagintervaller medtages i tilstanden sammen med den regel, der bruger dem.
Checkpointet leveres med tilpasset sandsynlighedskalibrering, men konfidens kan ændre sig med dokumentdomæne og spørgsmålsdesign. Producenten dokumenterer også finjustering af det åbne checkpoint på opgavespecifikke etiketter og tilpasning af sandsynlighedskalibreringen til de pågældende opgaver; det er en separat tilpasningsarbejdsgang i forhold til scoring af en indsendt tilstand. Vælg beslutningstærskler med mærkede eksempler på de faktiske opgaver, og hold usikre tilfælde synlige til gennemgang. Producenten udelukker fuldautomatiske beslutninger med væsentlige konsekvenser for mennesker uden menneskelig gennemgang. Svarmulighedernes rækkefølge kan også påvirke et svar, så bevar en stabil rækkefølge ved sammenligning af resultater. Vurdér den valgte etiket, det separate konfidensfelt og sandsynlighedsfordelingen ud fra den rolle, de hver især spiller i arbejdsgangen.
Den aktuelle Kev-4B-udgivelse beskrevet af producenten tilhører Kev 1.0 og bruger Qwen3.5-grundmodellen. Tidligere Qwen3-baserede udgivelser og udgivelser begrænset til dokumentstadiet er fortsat særskilte versioner. Hold den valgte udgave og spørgsmålsdefinitionerne knyttet til outputtene ved udvikling af en opgavespecifik arbejdsgang frem for at blande resultater fra forskellige profiler.
Et nyttigt endeligt resultat er et navngivet sæt beslutningsregistreringer med de oprindelige spørgsmål, svarmulighedernes definitioner, fordelinger og eventuelle tegnforklaringer til ordnede niveauer. Ved en kontrol af svarkvalitet bør tilstanden indeholde svarforslaget, evidensen og det kriterium, der testes. Ved regeltriage bør den indeholde den gældende regel og relevante fakta. Bevar inputtet ved siden af resultatet, så en gennemgang kan fastslå, hvorfor en beslutning var passende, eller hvilket manglende forhold der skal tilføjes.
POST /v1/systemonetextdecisions| Felt | Type | Krav | Værdier og grænser | Standard |
|---|---|---|---|---|
Feltmodel | Typestring | KravPåkrævet | Værdier og grænser jaredpalmer/kev-4b | 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.000084 / 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.000084 / 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": "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
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 jaredpalmer/kev-4b
Brug metodestierne vist ovenfor.