Kev-4B is een compact beslissingsmodel voor het beantwoorden van getypeerde vragen over een aangeleverde toestand. De toestand is het document of record dat wordt beoordeeld, en elke vraag definieert de opties die het model kan scoren. Het resultaat is een kansverdeling met een getypeerd beslissingsrecord, wat het model bruikbaar maakt voor documentclassificatie, routering, triage, extractiekeuzes en controles aan de hand van vastgelegde criteria.
Het model combineert een bevroren Qwen3.5-4B-Base-backbone met een LoRA-adapter en een pointer head. De backbone heeft 32 lagen, bestaande uit 24 Gated DeltaNet-lagen en acht full-attention-lagen. De adapter richt zich op de projecties van attention, MLP en DeltaNet; de pointer head scoort de aangeleverde opties en zet die scores om in kansen. Dit is een beslissingsworkflow die uitsluitend uit prefill bestaat, waarbij de opties de antwoordruimte vormen.
Drie vraagtypen kunnen in hetzelfde verzoek voorkomen. Een keuzevraag accepteert 1–255 benoemde opties, eventueel met beschrijvingen, en geeft de meest waarschijnlijke optie, een afzonderlijke betrouwbaarheidswaarde en kansen voor de opties terug. Een ja/nee-vraag, in het formaat van de maker noul genoemd, geeft de kans op ja terug. Definieer in de vraag wat ja betekent, in plaats van aan te nemen dat een hoog getal voor de applicatie altijd een positieve uitkomst betekent.
Een geordende scorevraag accepteert 1–255 niveaus en geeft kansen voor de niveaus en hun verwachte index terug. Niveau-indices beginnen bij nul. Het resultaatformaat van de maker bevat ook de niveaulegenda en een afzonderlijke betrouwbaarheidswaarde. Een verwachte index kan fractioneel zijn: deze vat de verdeling over je geordende niveaus samen in plaats van een nieuw tekstueel label te kiezen. Bewaar de volgorde van de niveaus en de legenda bij het resultaat, zodat een beoordeling consistent kan worden geïnterpreteerd.
Vragen delen dezelfde toestand maar worden onafhankelijk geëvalueerd. De ene vraag kan het antwoord van een andere vraag niet lezen, en de toestand wordt één keer berekend en hergebruikt. Als een latere beslissing afhangt van het resultaat van een eerdere beslissing, maak die afhankelijkheid dan expliciet in een volgende toestand, in plaats van te verwachten dat de vragen in één verzoek een keten vormen. Daardoor is de workflow met een gedeelde toestand geschikt voor meerdere onafhankelijke controles op hetzelfde document.
Bereid de toestand voor met het bewijs dat de vragen werkelijk nodig hebben. Dat kan platte tekst zijn of een JSON-object of -array dat als gelabelde tekst wordt weergegeven. Houd veldnamen, eenheden, beleidsvoorwaarden en de relevante bronpassages duidelijk. Schrijf voor elke vraag een specifieke instructie en geef de opties betekenissen die op basis van het record van elkaar te onderscheiden zijn. Bij een eigen voorbeeldtaak voor supportroutering kan de toestand het verzoek en de context ervan bevatten, terwijl de keuzes categorieën voor levering, toegang en productondersteuning met korte beschrijvingen definiëren.
Een tweede vraag kan de urgentie beoordelen, en een geordende vraag kan aangeven hoeveel opvolging het verzoek nodig heeft. Deze vragen beantwoorden verschillende operationele vragen, dus definieer ze afzonderlijk. Neem een geschikte optie voor review of ontbrekend bewijs op wanneer de keuzetaak die nodig heeft, en bewaar de volledige verdeling wanneer meerdere categorieën aannemelijk zijn. De applicatie beslist hoe een resultaat wordt gerouteerd of beoordeeld; het model levert het gescoorde record.
Kev-4B is bedoeld voor getypeerde beslissingen over documenten van enkele duizenden tokens. Het serveerprofiel van de maker accepteert toestanden tot 65.536 tokens en reserveert extra ruimte voor elke vraag, terwijl de gevalideerde contextlengte voor dit checkpoint 8192 tokens is. Dat zijn verschillende grenzen: dat een langere toestand wordt geaccepteerd, betekent niet dat beslissingen op elke lengte even betrouwbaar zijn. Houd doorslaggevende passages compact en behoud hun labels bij het voorbereiden van een lang record voor classificatie.
Het uitgebrachte profiel is Engelstalig. De bruikbare taken hangen af van het bewijs in de aangeleverde toestand en van de gedefinieerde opties, niet van open chat, samenvatten of het beantwoorden van vragen op basis van brede kennis. Rekenen met datums op dagniveau is een specifieke beperking: de maker levert een afzonderlijke preprocessor voor datumfeiten die berekende intervallen aanlevert. Neem bij een controle op een deadline de relevante datums en de berekende intervallen in dagen op in de toestand, samen met de regel die ze gebruikt.
Het checkpoint wordt geleverd met een gefitte kanskalibratie, maar de betrouwbaarheid kan veranderen met het documentdomein en het ontwerp van de vragen. De maker documenteert ook het finetunen van het open checkpoint op taakspecifieke labels en het fitten van de kanskalibratie op die workload; dat is een afzonderlijke aanpassingsworkflow, los van het scoren van een aangeleverde toestand. Kies beslissingsdrempels met gelabelde voorbeelden uit de werkelijke workload en houd onzekere gevallen zichtbaar voor review. De maker sluit volledig geautomatiseerde ingrijpende beslissingen over mensen zonder menselijke review uit. De volgorde van de opties kan ook een antwoord beïnvloeden, dus houd een stabiele volgorde aan bij het vergelijken van resultaten. Beoordeel het gekozen label, het afzonderlijke betrouwbaarheidsveld en de kansverdeling op basis van de rol die elk ervan in je workflow speelt.
De huidige Kev-4B-release die de maker beschrijft, hoort bij Kev 1.0 en gebruikt de Qwen3.5-basis. Eerdere releases op basis van Qwen3 en releases met alleen de documentfase blijven afzonderlijke versies. Houd de gekozen editie en de vraagdefinities gekoppeld aan de uitvoer bij het ontwikkelen van een taakspecifieke workflow, in plaats van resultaten van verschillende profielen te mengen.
Een bruikbaar eindartefact is een benoemde set beslissingsrecords met de oorspronkelijke vragen, optiedefinities, verdelingen en eventuele legenda's van geordende niveaus. Bij een controle van de antwoordkwaliteit bevat de toestand het voorgestelde antwoord, het bewijs en het geteste criterium. Bij beleidstriage bevat de toestand de toepasselijke regel en de relevante feiten. Bewaar die invoer naast het resultaat, zodat een review kan vaststellen waarom een beslissing passend was of welk ontbrekend feit nog moet worden aangeleverd.
", "aboutText": "Kev-4B is een compact beslissingsmodel voor het beantwoorden van getypeerde vragen over een aangeleverde toestand. De toestand is het document of record dat wordt beoordeeld, en elke vraag definieert de opties die het model kan scoren. Het resultaat is een kansverdeling met een getypeerd beslissingsrecord, wat het model bruikbaar maakt voor documentclassificatie, routering, triage, extractiekeuzes en controles aan de hand van vastgelegde criteria.\n\nHet model combineert een bevroren Qwen3.5-4B-Base-backbone met een LoRA-adapter en een pointer head. De backbone heeft 32 lagen, bestaande uit 24 Gated DeltaNet-lagen en acht full-attention-lagen. De adapter richt zich op de projecties van attention, MLP en DeltaNet; de pointer head scoort de aangeleverde opties en zet die scores om in kansen. Dit is een beslissingsworkflow die uitsluitend uit prefill bestaat, waarbij de opties de antwoordruimte vormen.\n\nDrie vraagtypen kunnen in hetzelfde verzoek voorkomen. Een keuzevraag accepteert 1–255 benoemde opties, eventueel met beschrijvingen, en geeft de meest waarschijnlijke optie, een afzonderlijke betrouwbaarheidswaarde en kansen voor de opties terug. Een ja/nee-vraag, in het formaat van de maker noul genoemd, geeft de kans op ja terug. Definieer in de vraag wat ja betekent, in plaats van aan te nemen dat een hoog getal voor de applicatie altijd een positieve uitkomst betekent.\n\nEen geordende scorevraag accepteert 1–255 niveaus en geeft kansen voor de niveaus en hun verwachte index terug. Niveau-indices beginnen bij nul. Het resultaatformaat van de maker bevat ook de niveaulegenda en een afzonderlijke betrouwbaarheidswaarde. Een verwachte index kan fractioneel zijn: deze vat de verdeling over je geordende niveaus samen in plaats van een nieuw tekstueel label te kiezen. Bewaar de volgorde van de niveaus en de legenda bij het resultaat, zodat een beoordeling consistent kan worden geïnterpreteerd.\n\nVragen delen dezelfde toestand maar worden onafhankelijk geëvalueerd. De ene vraag kan het antwoord van een andere vraag niet lezen, en de toestand wordt één keer berekend en hergebruikt. Als een latere beslissing afhangt van het resultaat van een eerdere beslissing, maak die afhankelijkheid dan expliciet in een volgende toestand, in plaats van te verwachten dat de vragen in één verzoek een keten vormen. Daardoor is de workflow met een gedeelde toestand geschikt voor meerdere onafhankelijke controles op hetzelfde document.\n\nBereid de toestand voor met het bewijs dat de vragen werkelijk nodig hebben. Dat kan platte tekst zijn of een JSON-object of -array dat als gelabelde tekst wordt weergegeven. Houd veldnamen, eenheden, beleidsvoorwaarden en de relevante bronpassages duidelijk. Schrijf voor elke vraag een specifieke instructie en geef de opties betekenissen die op basis van het record van elkaar te onderscheiden zijn. Bij een eigen voorbeeldtaak voor supportroutering kan de toestand het verzoek en de context ervan bevatten, terwijl de keuzes categorieën voor levering, toegang en productondersteuning met korte beschrijvingen definiëren.\n\nEen tweede vraag kan de urgentie beoordelen, en een geordende vraag kan aangeven hoeveel opvolging het verzoek nodig heeft. Deze vragen beantwoorden verschillende operationele vragen, dus definieer ze afzonderlijk. Neem een geschikte optie voor review of ontbrekend bewijs op wanneer de keuzetaak die nodig heeft, en bewaar de volledige verdeling wanneer meerdere categorieën aannemelijk zijn. De applicatie beslist hoe een resultaat wordt gerouteerd of beoordeeld; het model levert het gescoorde record.\n\nKev-4B is bedoeld voor getypeerde beslissingen over documenten van enkele duizenden tokens. Het serveerprofiel van de maker accepteert toestanden tot 65.536 tokens en reserveert extra ruimte voor elke vraag, terwijl de gevalideerde contextlengte voor dit checkpoint 8192 tokens is. Dat zijn verschillende grenzen: dat een langere toestand wordt geaccepteerd, betekent niet dat beslissingen op elke lengte even betrouwbaar zijn. Houd doorslaggevende passages compact en behoud hun labels bij het voorbereiden van een lang record voor classificatie.\n\nHet uitgebrachte profiel is Engelstalig. De bruikbare taken hangen af van het bewijs in de aangeleverde toestand en van de gedefinieerde opties, niet van open chat, samenvatten of het beantwoorden van vragen op basis van brede kennis. Rekenen met datums op dagniveau is een specifieke beperking: de maker levert een afzonderlijke preprocessor voor datumfeiten die berekende intervallen aanlevert. Neem bij een controle op een deadline de relevante datums en de berekende intervallen in dagen op in de toestand, samen met de regel die ze gebruikt.\n\nHet checkpoint wordt geleverd met een gefitte kanskalibratie, maar de betrouwbaarheid kan veranderen met het documentdomein en het ontwerp van de vragen. De maker documenteert ook het finetunen van het open checkpoint op taakspecifieke labels en het fitten van de kanskalibratie op die workload; dat is een afzonderlijke aanpassingsworkflow, los van het scoren van een aangeleverde toestand. Kies beslissingsdrempels met gelabelde voorbeelden uit de werkelijke workload en houd onzekere gevallen zichtbaar voor review. De maker sluit volledig geautomatiseerde ingrijpende beslissingen over mensen zonder menselijke review uit. De volgorde van de opties kan ook een antwoord beïnvloeden, dus houd een stabiele volgorde aan bij het vergelijken van resultaten. Beoordeel het gekozen label, het afzonderlijke betrouwbaarheidsveld en de kansverdeling op basis van de rol die elk ervan in je workflow speelt.\n\nDe huidige Kev-4B-release die de maker beschrijft, hoort bij Kev 1.0 en gebruikt de Qwen3.5-basis. Eerdere releases op basis van Qwen3 en releases met alleen de documentfase blijven afzonderlijke versies. Houd de gekozen editie en de vraagdefinities gekoppeld aan de uitvoer bij het ontwikkelen van een taakspecifieke workflow, in plaats van resultaten van verschillende profielen te mengen.\n\nEen bruikbaar eindartefact is een benoemde set beslissingsrecords met de oorspronkelijke vragen, optiedefinities, verdelingen en eventuele legenda's van geordende niveaus. Bij een controle van de antwoordkwaliteit bevat de toestand het voorgestelde antwoord, het bewijs en het geteste criterium. Bij beleidstriage bevat de toestand de toepasselijke regel en de relevante feiten. Bewaar die invoer naast het resultaat, zodat een review kan vaststellen waarom een beslissing passend was of welk ontbrekend feit nog moet worden aangeleverd.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "54bba4c1255ff4957f2fd104f8ab45e983678c2434b4fe4ed38fb0bd42f63263", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "nl", "methods": [ { "html": "jaredpalmer/kev-4bKev-4B scoort getypeerde vragen over een aangeleverd Engelstalig document en geeft gekalibreerde kansen terug over de opties die je definieert. Gebruik ja/nee-vragen, keuzevragen en geordende scorevragen voor classificatie, routering, triage en controles die een gestructureerde beslissing vereisen in plaats van gegenereerde lopende tekst.
Deze beschrijving gaat over de mogelijkheden van het model. De via Ailoot beschikbare invoer, uitvoer en opties staan hieronder voor de geselecteerde methode.
Kev-4B is een compact beslissingsmodel voor het beantwoorden van getypeerde vragen over een aangeleverde toestand. De toestand is het document of record dat wordt beoordeeld, en elke vraag definieert de opties die het model kan scoren. Het resultaat is een kansverdeling met een getypeerd beslissingsrecord, wat het model bruikbaar maakt voor documentclassificatie, routering, triage, extractiekeuzes en controles aan de hand van vastgelegde criteria.
Het model combineert een bevroren Qwen3.5-4B-Base-backbone met een LoRA-adapter en een pointer head. De backbone heeft 32 lagen, bestaande uit 24 Gated DeltaNet-lagen en acht full-attention-lagen. De adapter richt zich op de projecties van attention, MLP en DeltaNet; de pointer head scoort de aangeleverde opties en zet die scores om in kansen. Dit is een beslissingsworkflow die uitsluitend uit prefill bestaat, waarbij de opties de antwoordruimte vormen.
Drie vraagtypen kunnen in hetzelfde verzoek voorkomen. Een keuzevraag accepteert 1–255 benoemde opties, eventueel met beschrijvingen, en geeft de meest waarschijnlijke optie, een afzonderlijke betrouwbaarheidswaarde en kansen voor de opties terug. Een ja/nee-vraag, in het formaat van de maker noul genoemd, geeft de kans op ja terug. Definieer in de vraag wat ja betekent, in plaats van aan te nemen dat een hoog getal voor de applicatie altijd een positieve uitkomst betekent.
Een geordende scorevraag accepteert 1–255 niveaus en geeft kansen voor de niveaus en hun verwachte index terug. Niveau-indices beginnen bij nul. Het resultaatformaat van de maker bevat ook de niveaulegenda en een afzonderlijke betrouwbaarheidswaarde. Een verwachte index kan fractioneel zijn: deze vat de verdeling over je geordende niveaus samen in plaats van een nieuw tekstueel label te kiezen. Bewaar de volgorde van de niveaus en de legenda bij het resultaat, zodat een beoordeling consistent kan worden geïnterpreteerd.
Vragen delen dezelfde toestand maar worden onafhankelijk geëvalueerd. De ene vraag kan het antwoord van een andere vraag niet lezen, en de toestand wordt één keer berekend en hergebruikt. Als een latere beslissing afhangt van het resultaat van een eerdere beslissing, maak die afhankelijkheid dan expliciet in een volgende toestand, in plaats van te verwachten dat de vragen in één verzoek een keten vormen. Daardoor is de workflow met een gedeelde toestand geschikt voor meerdere onafhankelijke controles op hetzelfde document.
Bereid de toestand voor met het bewijs dat de vragen werkelijk nodig hebben. Dat kan platte tekst zijn of een JSON-object of -array dat als gelabelde tekst wordt weergegeven. Houd veldnamen, eenheden, beleidsvoorwaarden en de relevante bronpassages duidelijk. Schrijf voor elke vraag een specifieke instructie en geef de opties betekenissen die op basis van het record van elkaar te onderscheiden zijn. Bij een eigen voorbeeldtaak voor supportroutering kan de toestand het verzoek en de context ervan bevatten, terwijl de keuzes categorieën voor levering, toegang en productondersteuning met korte beschrijvingen definiëren.
Een tweede vraag kan de urgentie beoordelen, en een geordende vraag kan aangeven hoeveel opvolging het verzoek nodig heeft. Deze vragen beantwoorden verschillende operationele vragen, dus definieer ze afzonderlijk. Neem een geschikte optie voor review of ontbrekend bewijs op wanneer de keuzetaak die nodig heeft, en bewaar de volledige verdeling wanneer meerdere categorieën aannemelijk zijn. De applicatie beslist hoe een resultaat wordt gerouteerd of beoordeeld; het model levert het gescoorde record.
Kev-4B is bedoeld voor getypeerde beslissingen over documenten van enkele duizenden tokens. Het serveerprofiel van de maker accepteert toestanden tot 65.536 tokens en reserveert extra ruimte voor elke vraag, terwijl de gevalideerde contextlengte voor dit checkpoint 8192 tokens is. Dat zijn verschillende grenzen: dat een langere toestand wordt geaccepteerd, betekent niet dat beslissingen op elke lengte even betrouwbaar zijn. Houd doorslaggevende passages compact en behoud hun labels bij het voorbereiden van een lang record voor classificatie.
Het uitgebrachte profiel is Engelstalig. De bruikbare taken hangen af van het bewijs in de aangeleverde toestand en van de gedefinieerde opties, niet van open chat, samenvatten of het beantwoorden van vragen op basis van brede kennis. Rekenen met datums op dagniveau is een specifieke beperking: de maker levert een afzonderlijke preprocessor voor datumfeiten die berekende intervallen aanlevert. Neem bij een controle op een deadline de relevante datums en de berekende intervallen in dagen op in de toestand, samen met de regel die ze gebruikt.
Het checkpoint wordt geleverd met een gefitte kanskalibratie, maar de betrouwbaarheid kan veranderen met het documentdomein en het ontwerp van de vragen. De maker documenteert ook het finetunen van het open checkpoint op taakspecifieke labels en het fitten van de kanskalibratie op die workload; dat is een afzonderlijke aanpassingsworkflow, los van het scoren van een aangeleverde toestand. Kies beslissingsdrempels met gelabelde voorbeelden uit de werkelijke workload en houd onzekere gevallen zichtbaar voor review. De maker sluit volledig geautomatiseerde ingrijpende beslissingen over mensen zonder menselijke review uit. De volgorde van de opties kan ook een antwoord beïnvloeden, dus houd een stabiele volgorde aan bij het vergelijken van resultaten. Beoordeel het gekozen label, het afzonderlijke betrouwbaarheidsveld en de kansverdeling op basis van de rol die elk ervan in je workflow speelt.
De huidige Kev-4B-release die de maker beschrijft, hoort bij Kev 1.0 en gebruikt de Qwen3.5-basis. Eerdere releases op basis van Qwen3 en releases met alleen de documentfase blijven afzonderlijke versies. Houd de gekozen editie en de vraagdefinities gekoppeld aan de uitvoer bij het ontwikkelen van een taakspecifieke workflow, in plaats van resultaten van verschillende profielen te mengen.
Een bruikbaar eindartefact is een benoemde set beslissingsrecords met de oorspronkelijke vragen, optiedefinities, verdelingen en eventuele legenda's van geordende niveaus. Bij een controle van de antwoordkwaliteit bevat de toestand het voorgestelde antwoord, het bewijs en het geteste criterium. Bij beleidstriage bevat de toestand de toepasselijke regel en de relevante feiten. Bewaar die invoer naast het resultaat, zodat een review kan vaststellen waarom een beslissing passend was of welk ontbrekend feit nog moet worden aangeleverd.
POST /v1/systemonetextdecisions| Veld | Type | Vereiste | Waarden en limieten | Standaard |
|---|---|---|---|---|
Veldmodel | Typestring | VereisteVereist | Waarden en limieten jaredpalmer/kev-4b | Standaard— |
Veldprovider | Typeschema | VereisteOptioneel | Waarden en limieten | Standaard— |
Veldquestions | Typeobject | VereisteVereist | Waarden en limieten | Standaard— |
Veldsession_id | Typestring | VereisteOptioneel | Waarden en limieten | Standaard— |
Veldstate | Typeschema | VereisteVereist | Waarden en limieten | Standaard— |
Veldtrace | Typeschema | VereisteOptioneel | Waarden en limieten | Standaard— |
Velduser | Typestring | VereisteOptioneel | Waarden en limieten | Standaard— |
Veldquestions.<id>.type | Typestring | VereisteVereist | Waarden en limieten noul, choice, score | Standaard— |
Veldquestions.<id>.instructions | Typestring|object|array | VereisteVereist | Waarden en limieten | Standaard— |
Veldquestions.<id>.criteria | Typeobject|array | VereisteOptioneel | Waarden en limieten Voorwaarden: choice/score: vereist; noul: optioneel. De criteria voor choice zijn een object; score is een array met minItems1. | Standaard— |
Veldquestions.<id>.criteria.true | Typestring|object|array | VereisteVereist | Waarden en limieten Geldt wanneer: Object met noul-criteria opgegeven | Standaard— |
Veldquestions.<id>.criteria.false | Typestring|object|array | VereisteVereist | Waarden en limieten Geldt wanneer: Object met noul-criteria opgegeven | Standaard— |
noul · Vereist: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Vereist: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Vereist: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, state, questions |
Parametermaterial_types | Contracttext |
Parameteroptional_controls | Contractprovider, session_id, trace, user |
Parametermultimodal_input_binding | Contractnull |
Levenscyclus: synchronous
Verstuur de exacte model-ID en bewaar het volledige native antwoord.
Tariefverwijzingen voegen geen verzoekopties toe. Ondersteunde parameters staan bij de geselecteerde methode.
Koppel elke kostenpost aan de getoonde voorwaarden. Gebruik één tarief voor elke groep alternatieve configuraties.
| Configuratie | Tariefstaffel | Contexttokens, meer dan | Contexttokens, tot en met | Kosten |
|---|---|---|---|---|
| ConfiguratieBasistarieven voor tokens | TariefstaffelBasistarief | Contexttokens, meer dan— | Contexttokens, tot en metGeen bovengrens | Kosten Invoer · Invoertokens $0.000084 / 1K tokens Uitvoer · Uitvoertokens $0 / 1K tokens Invoer · Cache lezen — / 1K tokens Invoer · Cache schrijven — / 1K tokens Invoer · Cache schrijven, 1 uur — / 1K tokens |
| ConfiguratieNiveau 1 voor aanvraaglengte | Tariefstaffel— | Contexttokens, meer dan0 | Contexttokens, tot en metGeen bovengrens | Kosten Invoer · Invoertokens $0.000084 / 1K tokens Uitvoer · Uitvoertokens $0 / 1K tokens Invoer · Cache lezen — / 1K tokens Invoer · Cache schrijven — / 1K tokens Invoer · Cache schrijven, 1 uur — / 1K tokens |
Ailoot reserveert vóór een verzoek een geschat bedrag. Na het resultaat worden de uiteindelijke kosten afgerekend op basis van het gemeten verbruik. Bij streaming gebeurt de afrekening op basis van de definitieve verbruiksregistratie. Zo werken reservering en afrekening →
{\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
Bewaar elk volledig teruggegeven antwoord, bestand en inhoudsonderdeel.
Elk aangeleverd antwoord op een vraag-ID blijft behouden met het exacte type, de noul/choice/score-waarde, zekerheid, waarschijnlijkheden en legenda. De volledige oorspronkelijke JSON wordt opgeslagen en pas na afrekening geretourneerd.
Bewaar de oorspronkelijke operatie en het volledige of gedeeltelijke antwoord; herhaal POST niet.
| Veld | Type |
|---|---|
Veldmodel | Typestring |
Veldid | Typestring |
Veldprovider | Typestring |
Veldanswers.<id>.type | Typestring |
Veldanswers.<id>.noul | Typenumber |
Veldanswers.<id>.choice | Typestring |
Veldanswers.<id>.score | Typenumber |
Veldanswers.<id>.confidence | Typenumber |
Veldanswers.<id>.probabilities | Typeobject |
Veldanswers.<id>.legend | Typeobject |
Veldusage.input_tokens | Typeinteger |
Veldusage.output_tokens | Typeinteger |
Veldusage.cost | Typenumber |
| Antwoord | Voorwaarde | Volgende stap |
|---|---|---|
Antwoord400 · invalid_request_error | VoorwaardeOngeldig vereist veld, ongeldige weergave of waarde | Volgende stapCorrigeer het aangegeven verzoekveld. |
Ailoot Ultra jaredpalmer/kev-4b
Gebruik de hierboven getoonde methodepaden.