Kev-4B è un modello decisionale compatto per rispondere a domande tipizzate su uno stato fornito. Lo stato è il documento o il record da valutare, e ogni domanda definisce le opzioni a cui il modello può assegnare un punteggio. Il risultato è una distribuzione di probabilità e un record decisionale tipizzato, utile per la classificazione di documenti, l'instradamento, il triage, le scelte di estrazione e le verifiche rispetto a criteri dichiarati.
Il modello combina una rete di base Qwen3.5-4B-Base congelata con un adattatore LoRA e una testa a puntatore. La rete di base ha 32 livelli, di cui 24 livelli Gated DeltaNet e otto livelli ad attenzione completa. L'adattatore agisce sulle proiezioni di attenzione, MLP e DeltaNet; la testa a puntatore assegna un punteggio alle opzioni fornite e converte tali punteggi in probabilità. Si tratta di un flusso decisionale basato esclusivamente sulla fase di prefill, in cui le opzioni costituiscono lo spazio delle risposte.
Nella stessa richiesta possono comparire tre tipi di domanda. Una domanda di scelta accetta da 1 a 255 opzioni denominate, facoltativamente con descrizioni, e restituisce l'opzione più probabile, un valore di confidenza separato e le probabilità delle opzioni. Una domanda sì/no, chiamata noul nel formato del produttore, restituisce la probabilità del sì. Definisci nella domanda il significato del sì invece di presumere che un numero elevato indichi sempre un esito positivo per l'applicazione.
Una domanda a punteggio ordinato accetta da 1 a 255 livelli e restituisce le probabilità dei livelli e il loro indice atteso. Gli indici dei livelli partono da zero. Il formato del risultato del produttore riporta anche la legenda dei livelli e un valore di confidenza separato. Un indice atteso può essere frazionario: riassume la distribuzione sui livelli ordinati che hai definito anziché selezionare una nuova etichetta testuale. Conserva l'ordine dei livelli e la legenda insieme al risultato, in modo che una valutazione possa essere interpretata in modo coerente.
Le domande condividono lo stesso stato ma vengono valutate in modo indipendente. Una domanda non può leggere la risposta di un'altra, e lo stato viene calcolato una sola volta e riutilizzato. Se una decisione successiva dipende dal risultato di una decisione precedente, rendi esplicita questa dipendenza in uno stato successivo invece di aspettarti che le domande di una stessa richiesta formino una catena. Ciò rende il flusso a stato condiviso adatto a più verifiche indipendenti sullo stesso documento.
Prepara lo stato con le prove di cui le domande hanno effettivamente bisogno. Può essere testo semplice oppure un oggetto o un array JSON reso come testo etichettato. Mantieni chiari i nomi dei campi, le unità, le condizioni delle policy e i passaggi di origine pertinenti. Scrivi un'istruzione specifica per ogni domanda e assegna alle sue opzioni significati distinguibili in base al record. Per un'attività originale di instradamento dell'assistenza, lo stato può contenere la richiesta e il suo contesto, mentre le scelte definiscono le categorie consegna, accesso e supporto al prodotto con brevi descrizioni.
Una seconda domanda può valutare l'urgenza, e una domanda ordinata può valutare quanto seguito richieda la richiesta. Queste rispondono a domande operative diverse, quindi definisci ciascuna separatamente. Includi un'opzione appropriata per la revisione o per le prove mancanti quando l'attività di scelta ne ha bisogno, e conserva l'intera distribuzione quando più categorie sono plausibili. L'applicazione decide come instradare o rivedere un risultato; il modello fornisce il record con i punteggi.
Kev-4B è pensato per decisioni tipizzate su documenti di qualche migliaio di token. Il profilo di servizio del produttore accetta stati fino a 65.536 token e riserva spazio aggiuntivo per ogni domanda, mentre la lunghezza di contesto convalidata per questo checkpoint è di 8192 token. Si tratta di limiti diversi: accettare uno stato più lungo non garantisce decisioni ugualmente affidabili a ogni lunghezza. Mantieni compatti i passaggi decisivi e conserva le loro etichette quando prepari un record lungo per la classificazione.
Il profilo rilasciato è in inglese. Le sue attività utili dipendono dalle prove presenti nello stato fornito e dalle opzioni definite, non da chat aperte, riepiloghi o risposte basate su conoscenze generali. L'aritmetica delle date a livello di giorno è una limitazione specifica: il produttore fornisce un preprocessore separato per i fatti sulle date che fornisce gli intervalli calcolati. Per una verifica di scadenza, includi nello stato le date pertinenti e gli intervalli in giorni calcolati, insieme alla regola che li utilizza.
Il checkpoint include una calibrazione delle probabilità già adattata, ma la confidenza può variare in base al dominio del documento e alla progettazione della domanda. Il produttore documenta anche il fine-tuning del checkpoint aperto su etichette specifiche dell'attività e l'adattamento della calibrazione delle probabilità a quel carico di lavoro; si tratta di un flusso di personalizzazione distinto dall'assegnazione di punteggi a uno stato fornito. Scegli le soglie decisionali usando esempi etichettati del carico di lavoro reale e mantieni visibili i casi incerti per la revisione. Il produttore esclude decisioni completamente automatizzate con conseguenze rilevanti sulle persone senza revisione umana. Anche l'ordine delle opzioni può influire su una risposta, quindi mantieni un ordinamento stabile quando confronti i risultati. Valuta l'etichetta scelta, il campo di confidenza separato e la distribuzione di probabilità in base al ruolo che ciascuno svolge nel tuo flusso di lavoro.
L'attuale versione di Kev-4B descritta dal produttore appartiene a Kev 1.0 e usa la base Qwen3.5. Le versioni precedenti basate su Qwen3 e quelle limitate alla sola fase sui documenti restano versioni distinte. Mantieni l'edizione scelta e le definizioni delle domande associate agli output quando sviluppi un flusso di lavoro specifico per un'attività, invece di mescolare risultati di profili diversi.
Un artefatto finale utile è un insieme denominato di record decisionali con le domande originali, le definizioni delle opzioni, le distribuzioni e le eventuali legende dei livelli ordinati. Per una verifica della qualità di una risposta, lo stato deve includere la risposta proposta, le prove e il criterio da verificare. Per il triage delle policy, deve includere la regola applicabile e i fatti pertinenti. Conserva quell'input accanto al risultato, in modo che una revisione possa stabilire perché una decisione era appropriata o quale fatto mancante occorre fornire.
", "aboutText": "Kev-4B è un modello decisionale compatto per rispondere a domande tipizzate su uno stato fornito. Lo stato è il documento o il record da valutare, e ogni domanda definisce le opzioni a cui il modello può assegnare un punteggio. Il risultato è una distribuzione di probabilità e un record decisionale tipizzato, utile per la classificazione di documenti, l'instradamento, il triage, le scelte di estrazione e le verifiche rispetto a criteri dichiarati.\n\nIl modello combina una rete di base Qwen3.5-4B-Base congelata con un adattatore LoRA e una testa a puntatore. La rete di base ha 32 livelli, di cui 24 livelli Gated DeltaNet e otto livelli ad attenzione completa. L'adattatore agisce sulle proiezioni di attenzione, MLP e DeltaNet; la testa a puntatore assegna un punteggio alle opzioni fornite e converte tali punteggi in probabilità. Si tratta di un flusso decisionale basato esclusivamente sulla fase di prefill, in cui le opzioni costituiscono lo spazio delle risposte.\n\nNella stessa richiesta possono comparire tre tipi di domanda. Una domanda di scelta accetta da 1 a 255 opzioni denominate, facoltativamente con descrizioni, e restituisce l'opzione più probabile, un valore di confidenza separato e le probabilità delle opzioni. Una domanda sì/no, chiamata noul nel formato del produttore, restituisce la probabilità del sì. Definisci nella domanda il significato del sì invece di presumere che un numero elevato indichi sempre un esito positivo per l'applicazione.\n\nUna domanda a punteggio ordinato accetta da 1 a 255 livelli e restituisce le probabilità dei livelli e il loro indice atteso. Gli indici dei livelli partono da zero. Il formato del risultato del produttore riporta anche la legenda dei livelli e un valore di confidenza separato. Un indice atteso può essere frazionario: riassume la distribuzione sui livelli ordinati che hai definito anziché selezionare una nuova etichetta testuale. Conserva l'ordine dei livelli e la legenda insieme al risultato, in modo che una valutazione possa essere interpretata in modo coerente.\n\nLe domande condividono lo stesso stato ma vengono valutate in modo indipendente. Una domanda non può leggere la risposta di un'altra, e lo stato viene calcolato una sola volta e riutilizzato. Se una decisione successiva dipende dal risultato di una decisione precedente, rendi esplicita questa dipendenza in uno stato successivo invece di aspettarti che le domande di una stessa richiesta formino una catena. Ciò rende il flusso a stato condiviso adatto a più verifiche indipendenti sullo stesso documento.\n\nPrepara lo stato con le prove di cui le domande hanno effettivamente bisogno. Può essere testo semplice oppure un oggetto o un array JSON reso come testo etichettato. Mantieni chiari i nomi dei campi, le unità, le condizioni delle policy e i passaggi di origine pertinenti. Scrivi un'istruzione specifica per ogni domanda e assegna alle sue opzioni significati distinguibili in base al record. Per un'attività originale di instradamento dell'assistenza, lo stato può contenere la richiesta e il suo contesto, mentre le scelte definiscono le categorie consegna, accesso e supporto al prodotto con brevi descrizioni.\n\nUna seconda domanda può valutare l'urgenza, e una domanda ordinata può valutare quanto seguito richieda la richiesta. Queste rispondono a domande operative diverse, quindi definisci ciascuna separatamente. Includi un'opzione appropriata per la revisione o per le prove mancanti quando l'attività di scelta ne ha bisogno, e conserva l'intera distribuzione quando più categorie sono plausibili. L'applicazione decide come instradare o rivedere un risultato; il modello fornisce il record con i punteggi.\n\nKev-4B è pensato per decisioni tipizzate su documenti di qualche migliaio di token. Il profilo di servizio del produttore accetta stati fino a 65.536 token e riserva spazio aggiuntivo per ogni domanda, mentre la lunghezza di contesto convalidata per questo checkpoint è di 8192 token. Si tratta di limiti diversi: accettare uno stato più lungo non garantisce decisioni ugualmente affidabili a ogni lunghezza. Mantieni compatti i passaggi decisivi e conserva le loro etichette quando prepari un record lungo per la classificazione.\n\nIl profilo rilasciato è in inglese. Le sue attività utili dipendono dalle prove presenti nello stato fornito e dalle opzioni definite, non da chat aperte, riepiloghi o risposte basate su conoscenze generali. L'aritmetica delle date a livello di giorno è una limitazione specifica: il produttore fornisce un preprocessore separato per i fatti sulle date che fornisce gli intervalli calcolati. Per una verifica di scadenza, includi nello stato le date pertinenti e gli intervalli in giorni calcolati, insieme alla regola che li utilizza.\n\nIl checkpoint include una calibrazione delle probabilità già adattata, ma la confidenza può variare in base al dominio del documento e alla progettazione della domanda. Il produttore documenta anche il fine-tuning del checkpoint aperto su etichette specifiche dell'attività e l'adattamento della calibrazione delle probabilità a quel carico di lavoro; si tratta di un flusso di personalizzazione distinto dall'assegnazione di punteggi a uno stato fornito. Scegli le soglie decisionali usando esempi etichettati del carico di lavoro reale e mantieni visibili i casi incerti per la revisione. Il produttore esclude decisioni completamente automatizzate con conseguenze rilevanti sulle persone senza revisione umana. Anche l'ordine delle opzioni può influire su una risposta, quindi mantieni un ordinamento stabile quando confronti i risultati. Valuta l'etichetta scelta, il campo di confidenza separato e la distribuzione di probabilità in base al ruolo che ciascuno svolge nel tuo flusso di lavoro.\n\nL'attuale versione di Kev-4B descritta dal produttore appartiene a Kev 1.0 e usa la base Qwen3.5. Le versioni precedenti basate su Qwen3 e quelle limitate alla sola fase sui documenti restano versioni distinte. Mantieni l'edizione scelta e le definizioni delle domande associate agli output quando sviluppi un flusso di lavoro specifico per un'attività, invece di mescolare risultati di profili diversi.\n\nUn artefatto finale utile è un insieme denominato di record decisionali con le domande originali, le definizioni delle opzioni, le distribuzioni e le eventuali legende dei livelli ordinati. Per una verifica della qualità di una risposta, lo stato deve includere la risposta proposta, le prove e il criterio da verificare. Per il triage delle policy, deve includere la regola applicabile e i fatti pertinenti. Conserva quell'input accanto al risultato, in modo che una revisione possa stabilire perché una decisione era appropriata o quale fatto mancante occorre fornire.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "9a59077b897a800ac862c675f344183e3065101354a6ca60b3a6855ced8ab8eb", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "it", "methods": [ { "html": "jaredpalmer/kev-4bKev-4B assegna punteggi a domande tipizzate su un documento in inglese fornito e restituisce probabilità calibrate sulle opzioni che definisci. Usa domande sì/no, di scelta e a punteggio ordinato per classificazione, instradamento, triage e verifiche che richiedono una decisione strutturata anziché prosa generata.
Questa descrizione illustra le funzionalità del modello. Gli input, gli output e le opzioni disponibili in Ailoot per il metodo selezionato sono elencati di seguito.
Kev-4B è un modello decisionale compatto per rispondere a domande tipizzate su uno stato fornito. Lo stato è il documento o il record da valutare, e ogni domanda definisce le opzioni a cui il modello può assegnare un punteggio. Il risultato è una distribuzione di probabilità e un record decisionale tipizzato, utile per la classificazione di documenti, l'instradamento, il triage, le scelte di estrazione e le verifiche rispetto a criteri dichiarati.
Il modello combina una rete di base Qwen3.5-4B-Base congelata con un adattatore LoRA e una testa a puntatore. La rete di base ha 32 livelli, di cui 24 livelli Gated DeltaNet e otto livelli ad attenzione completa. L'adattatore agisce sulle proiezioni di attenzione, MLP e DeltaNet; la testa a puntatore assegna un punteggio alle opzioni fornite e converte tali punteggi in probabilità. Si tratta di un flusso decisionale basato esclusivamente sulla fase di prefill, in cui le opzioni costituiscono lo spazio delle risposte.
Nella stessa richiesta possono comparire tre tipi di domanda. Una domanda di scelta accetta da 1 a 255 opzioni denominate, facoltativamente con descrizioni, e restituisce l'opzione più probabile, un valore di confidenza separato e le probabilità delle opzioni. Una domanda sì/no, chiamata noul nel formato del produttore, restituisce la probabilità del sì. Definisci nella domanda il significato del sì invece di presumere che un numero elevato indichi sempre un esito positivo per l'applicazione.
Una domanda a punteggio ordinato accetta da 1 a 255 livelli e restituisce le probabilità dei livelli e il loro indice atteso. Gli indici dei livelli partono da zero. Il formato del risultato del produttore riporta anche la legenda dei livelli e un valore di confidenza separato. Un indice atteso può essere frazionario: riassume la distribuzione sui livelli ordinati che hai definito anziché selezionare una nuova etichetta testuale. Conserva l'ordine dei livelli e la legenda insieme al risultato, in modo che una valutazione possa essere interpretata in modo coerente.
Le domande condividono lo stesso stato ma vengono valutate in modo indipendente. Una domanda non può leggere la risposta di un'altra, e lo stato viene calcolato una sola volta e riutilizzato. Se una decisione successiva dipende dal risultato di una decisione precedente, rendi esplicita questa dipendenza in uno stato successivo invece di aspettarti che le domande di una stessa richiesta formino una catena. Ciò rende il flusso a stato condiviso adatto a più verifiche indipendenti sullo stesso documento.
Prepara lo stato con le prove di cui le domande hanno effettivamente bisogno. Può essere testo semplice oppure un oggetto o un array JSON reso come testo etichettato. Mantieni chiari i nomi dei campi, le unità, le condizioni delle policy e i passaggi di origine pertinenti. Scrivi un'istruzione specifica per ogni domanda e assegna alle sue opzioni significati distinguibili in base al record. Per un'attività originale di instradamento dell'assistenza, lo stato può contenere la richiesta e il suo contesto, mentre le scelte definiscono le categorie consegna, accesso e supporto al prodotto con brevi descrizioni.
Una seconda domanda può valutare l'urgenza, e una domanda ordinata può valutare quanto seguito richieda la richiesta. Queste rispondono a domande operative diverse, quindi definisci ciascuna separatamente. Includi un'opzione appropriata per la revisione o per le prove mancanti quando l'attività di scelta ne ha bisogno, e conserva l'intera distribuzione quando più categorie sono plausibili. L'applicazione decide come instradare o rivedere un risultato; il modello fornisce il record con i punteggi.
Kev-4B è pensato per decisioni tipizzate su documenti di qualche migliaio di token. Il profilo di servizio del produttore accetta stati fino a 65.536 token e riserva spazio aggiuntivo per ogni domanda, mentre la lunghezza di contesto convalidata per questo checkpoint è di 8192 token. Si tratta di limiti diversi: accettare uno stato più lungo non garantisce decisioni ugualmente affidabili a ogni lunghezza. Mantieni compatti i passaggi decisivi e conserva le loro etichette quando prepari un record lungo per la classificazione.
Il profilo rilasciato è in inglese. Le sue attività utili dipendono dalle prove presenti nello stato fornito e dalle opzioni definite, non da chat aperte, riepiloghi o risposte basate su conoscenze generali. L'aritmetica delle date a livello di giorno è una limitazione specifica: il produttore fornisce un preprocessore separato per i fatti sulle date che fornisce gli intervalli calcolati. Per una verifica di scadenza, includi nello stato le date pertinenti e gli intervalli in giorni calcolati, insieme alla regola che li utilizza.
Il checkpoint include una calibrazione delle probabilità già adattata, ma la confidenza può variare in base al dominio del documento e alla progettazione della domanda. Il produttore documenta anche il fine-tuning del checkpoint aperto su etichette specifiche dell'attività e l'adattamento della calibrazione delle probabilità a quel carico di lavoro; si tratta di un flusso di personalizzazione distinto dall'assegnazione di punteggi a uno stato fornito. Scegli le soglie decisionali usando esempi etichettati del carico di lavoro reale e mantieni visibili i casi incerti per la revisione. Il produttore esclude decisioni completamente automatizzate con conseguenze rilevanti sulle persone senza revisione umana. Anche l'ordine delle opzioni può influire su una risposta, quindi mantieni un ordinamento stabile quando confronti i risultati. Valuta l'etichetta scelta, il campo di confidenza separato e la distribuzione di probabilità in base al ruolo che ciascuno svolge nel tuo flusso di lavoro.
L'attuale versione di Kev-4B descritta dal produttore appartiene a Kev 1.0 e usa la base Qwen3.5. Le versioni precedenti basate su Qwen3 e quelle limitate alla sola fase sui documenti restano versioni distinte. Mantieni l'edizione scelta e le definizioni delle domande associate agli output quando sviluppi un flusso di lavoro specifico per un'attività, invece di mescolare risultati di profili diversi.
Un artefatto finale utile è un insieme denominato di record decisionali con le domande originali, le definizioni delle opzioni, le distribuzioni e le eventuali legende dei livelli ordinati. Per una verifica della qualità di una risposta, lo stato deve includere la risposta proposta, le prove e il criterio da verificare. Per il triage delle policy, deve includere la regola applicabile e i fatti pertinenti. Conserva quell'input accanto al risultato, in modo che una revisione possa stabilire perché una decisione era appropriata o quale fatto mancante occorre fornire.
POST /v1/systemonetextdecisions| Campo | Tipo | Requisito | Valori e limiti | Predefinito |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObbligatorio | Valori e limiti jaredpalmer/kev-4b | Predefinito— |
Campoprovider | Tiposchema | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campoquestions | Tipoobject | RequisitoObbligatorio | Valori e limiti | Predefinito— |
Camposession_id | Tipostring | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campostate | Tiposchema | RequisitoObbligatorio | Valori e limiti | Predefinito— |
Campotrace | Tiposchema | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campouser | Tipostring | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campoquestions.<id>.type | Tipostring | RequisitoObbligatorio | Valori e limiti noul, choice, score | Predefinito— |
Campoquestions.<id>.instructions | Tipostring|object|array | RequisitoObbligatorio | Valori e limiti | Predefinito— |
Campoquestions.<id>.criteria | Tipoobject|array | RequisitoFacoltativo | Valori e limiti Condizioni: choice/score: obbligatori; noul: facoltativo. I criteri di choice sono un oggetto; score è un array con minItems1. | Predefinito— |
Campoquestions.<id>.criteria.true | Tipostring|object|array | RequisitoObbligatorio | Valori e limiti Si applica quando: Oggetto criteria noul fornito | Predefinito— |
Campoquestions.<id>.criteria.false | Tipostring|object|array | RequisitoObbligatorio | Valori e limiti Si applica quando: Oggetto criteria noul fornito | Predefinito— |
noul · Obbligatorio: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Obbligatorio: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Obbligatorio: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parametro | Contratto |
|---|---|
Parametrocontent_type | Contrattoapplication/json |
Parametrorequired | Contrattomodel, state, questions |
Parametromaterial_types | Contrattotext |
Parametrooptional_controls | Contrattoprovider, session_id, trace, user |
Parametromultimodal_input_binding | Contrattonull |
Ciclo di vita: synchronous
Invia l'ID esatto del modello e conserva l'intera risposta nativa.
Le tariffe non aggiungono opzioni alla richiesta. I parametri supportati sono elencati nel metodo selezionato.
Associa ogni costo alle condizioni indicate. Usa una sola tariffa per ogni insieme di configurazioni alternative.
| Configurazione | Listino delle tariffe | Token di contesto, più di | Token di contesto, fino al limite incluso | Costo |
|---|---|---|---|---|
| ConfigurazioneTariffe di base dei token | Listino delle tariffeTariffa base | Token di contesto, più di— | Token di contesto, fino al limite inclusoNessun limite superiore | Costo Input · Token in input $0.000084 / 1K token Output · Token in output $0 / 1K token Input · Lettura dalla cache — / 1K token Input · Scrittura nella cache — / 1K token Input · Scrittura nella cache, 1 ora — / 1K token |
| ConfigurazioneFascia 1 di lunghezza della richiesta | Listino delle tariffe— | Token di contesto, più di0 | Token di contesto, fino al limite inclusoNessun limite superiore | Costo Input · Token in input $0.000084 / 1K token Output · Token in output $0 / 1K token Input · Lettura dalla cache — / 1K token Input · Scrittura nella cache — / 1K token Input · Scrittura nella cache, 1 ora — / 1K token |
Ailoot prenota un importo stimato prima di una richiesta. Dopo il risultato, addebita il costo finale in base all’utilizzo misurato. Per lo streaming, l’addebito usa il record finale di utilizzo. Come funzionano la prenotazione e l’addebito finale →
{\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
Conserva ogni risposta, file e parte di contenuto restituiti per intero.
Viene conservata ogni risposta associata all'ID della domanda fornito, con il tipo esatto, il valore noul/choice/score, la confidenza, le probabilità e la legenda. L'intero JSON originale viene memorizzato e restituito solo dopo il conguaglio dell'addebito.
Conserva l'operazione originale e la risposta completa o parziale; non ripetere POST.
| Campo | Tipo |
|---|---|
Campomodel | Tipostring |
Campoid | Tipostring |
Campoprovider | Tipostring |
Campoanswers.<id>.type | Tipostring |
Campoanswers.<id>.noul | Tiponumber |
Campoanswers.<id>.choice | Tipostring |
Campoanswers.<id>.score | Tiponumber |
Campoanswers.<id>.confidence | Tiponumber |
Campoanswers.<id>.probabilities | Tipoobject |
Campoanswers.<id>.legend | Tipoobject |
Campousage.input_tokens | Tipointeger |
Campousage.output_tokens | Tipointeger |
Campousage.cost | Tiponumber |
| Risposta | Condizione | Passaggio successivo |
|---|---|---|
Risposta400 · invalid_request_error | CondizioneCampo obbligatorio, rappresentazione o valore non valido | Passaggio successivoCorreggi il campo della richiesta indicato. |
Ailoot Ultra jaredpalmer/kev-4b
Usa i percorsi dei metodi indicati sopra.