Kev-4B est un modèle de décision compact qui répond à des questions typées portant sur un état fourni. L’état est le document ou l’enregistrement évalué, et chaque question définit les options que le modèle peut noter. Son résultat est une distribution de probabilités et un enregistrement de décision typé, ce qui le rend utile pour la classification de documents, le routage, le triage, les choix d’extraction et les vérifications au regard de critères énoncés.
Le modèle associe un backbone Qwen3.5-4B-Base figé à un adaptateur LoRA et à une tête de pointage (pointer head). Le backbone compte 32 couches, dont 24 couches Gated DeltaNet et huit couches d’attention complète. L’adaptateur cible les projections d’attention, MLP et DeltaNet ; la tête de pointage note les options fournies et convertit ces notes en probabilités. Il s’agit d’un processus de décision fonctionnant uniquement en phase de préremplissage (prefill), les options formant l’espace des réponses.
Trois types de questions peuvent figurer dans une même requête. Une question de choix accepte de 1 à 255 options nommées, éventuellement accompagnées de descriptions, et renvoie l’option la plus probable, une valeur de confiance distincte et les probabilités des options. Une question oui/non, appelée noul dans le format du concepteur, renvoie la probabilité de oui. Définissez la signification de oui dans la question plutôt que de supposer qu’une valeur élevée correspond toujours à une issue positive pour l’application.
Une question de score ordonné accepte de 1 à 255 niveaux et renvoie les probabilités des niveaux ainsi que leur indice attendu. Les indices de niveau commencent à zéro. Le format de résultat du concepteur inclut également la légende des niveaux et une valeur de confiance distincte. Un indice attendu peut être fractionnaire : il résume la distribution sur vos niveaux ordonnés plutôt que de sélectionner une nouvelle étiquette textuelle. Conservez l’ordre et la légende des niveaux avec le résultat afin qu’une note puisse être interprétée de manière cohérente.
Les questions partagent le même état mais sont évaluées indépendamment. Une question ne peut pas lire la réponse d’une autre question, et l’état est calculé une seule fois puis réutilisé. Si une décision ultérieure dépend du résultat d’une décision antérieure, rendez cette dépendance explicite dans un état suivant au lieu d’attendre des questions d’une même requête qu’elles forment une chaîne. Ce processus à état partagé convient ainsi à plusieurs vérifications indépendantes sur un même document.
Préparez l’état avec les éléments probants dont les questions ont réellement besoin. Il peut s’agir de texte brut ou d’un objet ou tableau JSON rendu sous forme de texte étiqueté. Gardez clairs les noms de champs, les unités, les conditions des politiques et les passages sources pertinents. Rédigez une instruction précise pour chaque question et donnez à ses options des significations qui puissent être distinguées à partir de l’enregistrement. Pour une tâche originale de routage des demandes d’assistance, l’état peut contenir la demande et son contexte, tandis que les choix définissent des catégories livraison, accès et assistance produit avec de courtes descriptions.
Une deuxième question peut évaluer l’urgence, et une question ordonnée peut noter le degré de suivi nécessaire à la demande. Ces questions répondent à des interrogations opérationnelles différentes : définissez donc chacune séparément. Incluez une option appropriée de revue ou d’éléments manquants lorsque la tâche de choix en a besoin, et conservez la distribution complète lorsque plusieurs catégories sont plausibles. L’application décide comment router ou réviser un résultat ; le modèle fournit l’enregistrement noté.
Kev-4B est conçu pour des décisions typées portant sur des documents de quelques milliers de tokens. Le profil de service de son concepteur accepte des états allant jusqu’à 65 536 tokens et réserve un espace supplémentaire pour chaque question, tandis que la longueur de contexte validée pour ce checkpoint est de 8192 tokens. Ce sont des limites différentes : accepter un état plus long n’établit pas que les décisions sont aussi fiables à toutes les longueurs. Gardez les passages décisifs compacts et préservez leurs étiquettes lorsque vous préparez un long enregistrement pour la classification.
Le profil publié est en anglais. Ses tâches utiles dépendent des éléments probants présents dans l’état fourni et des options définies, plutôt que du chat ouvert, du résumé ou des réponses fondées sur des connaissances générales. L’arithmétique des dates au jour près constitue une limitation particulière : le concepteur fournit un préprocesseur distinct de faits de dates qui produit des intervalles calculés. Pour une vérification d’échéance, incluez dans l’état les dates pertinentes et les intervalles en jours calculés, ainsi que la règle qui les utilise.
Le checkpoint est livré avec un calibrage des probabilités ajusté, mais la confiance peut varier selon le domaine des documents et la conception des questions. Le concepteur documente aussi l’affinage du checkpoint ouvert sur des étiquettes propres à une tâche et l’ajustement de son calibrage des probabilités à cette charge de travail ; il s’agit d’un processus de personnalisation distinct de la notation d’un état fourni. Choisissez les seuils de décision à l’aide d’exemples étiquetés de la charge de travail réelle, et gardez les cas incertains visibles pour la revue. Le concepteur exclut les décisions entièrement automatisées ayant des conséquences pour des personnes sans revue humaine. L’ordre des options peut aussi influer sur une réponse : conservez donc un ordre stable lorsque vous comparez des résultats. Évaluez l’étiquette choisie, le champ de confiance distinct et la distribution de probabilités selon le rôle que chacun joue dans votre flux de travail.
La version actuelle de Kev-4B décrite par le concepteur appartient à Kev 1.0 et repose sur la base Qwen3.5. Les versions antérieures fondées sur Qwen3 et celles limitées à l’étape documentaire restent des versions distinctes. Associez l’édition choisie et les définitions des questions aux sorties lorsque vous développez un flux de travail propre à une tâche, plutôt que de mélanger des résultats issus de profils différents.
Un artefact final utile est un ensemble nommé d’enregistrements de décision comprenant les questions d’origine, les définitions des options, les distributions et, le cas échéant, les légendes des niveaux ordonnés. Pour un contrôle de la qualité d’une réponse, l’état doit inclure la réponse proposée, les éléments probants et le critère testé. Pour un triage au regard de politiques, il doit inclure la règle applicable et les faits pertinents. Conservez cette entrée à côté du résultat afin qu’une revue puisse établir pourquoi une décision était appropriée ou quel fait manquant doit être fourni.
", "aboutText": "Kev-4B est un modèle de décision compact qui répond à des questions typées portant sur un état fourni. L’état est le document ou l’enregistrement évalué, et chaque question définit les options que le modèle peut noter. Son résultat est une distribution de probabilités et un enregistrement de décision typé, ce qui le rend utile pour la classification de documents, le routage, le triage, les choix d’extraction et les vérifications au regard de critères énoncés.\n\nLe modèle associe un backbone Qwen3.5-4B-Base figé à un adaptateur LoRA et à une tête de pointage (pointer head). Le backbone compte 32 couches, dont 24 couches Gated DeltaNet et huit couches d’attention complète. L’adaptateur cible les projections d’attention, MLP et DeltaNet ; la tête de pointage note les options fournies et convertit ces notes en probabilités. Il s’agit d’un processus de décision fonctionnant uniquement en phase de préremplissage (prefill), les options formant l’espace des réponses.\n\nTrois types de questions peuvent figurer dans une même requête. Une question de choix accepte de 1 à 255 options nommées, éventuellement accompagnées de descriptions, et renvoie l’option la plus probable, une valeur de confiance distincte et les probabilités des options. Une question oui/non, appelée noul dans le format du concepteur, renvoie la probabilité de oui. Définissez la signification de oui dans la question plutôt que de supposer qu’une valeur élevée correspond toujours à une issue positive pour l’application.\n\nUne question de score ordonné accepte de 1 à 255 niveaux et renvoie les probabilités des niveaux ainsi que leur indice attendu. Les indices de niveau commencent à zéro. Le format de résultat du concepteur inclut également la légende des niveaux et une valeur de confiance distincte. Un indice attendu peut être fractionnaire : il résume la distribution sur vos niveaux ordonnés plutôt que de sélectionner une nouvelle étiquette textuelle. Conservez l’ordre et la légende des niveaux avec le résultat afin qu’une note puisse être interprétée de manière cohérente.\n\nLes questions partagent le même état mais sont évaluées indépendamment. Une question ne peut pas lire la réponse d’une autre question, et l’état est calculé une seule fois puis réutilisé. Si une décision ultérieure dépend du résultat d’une décision antérieure, rendez cette dépendance explicite dans un état suivant au lieu d’attendre des questions d’une même requête qu’elles forment une chaîne. Ce processus à état partagé convient ainsi à plusieurs vérifications indépendantes sur un même document.\n\nPréparez l’état avec les éléments probants dont les questions ont réellement besoin. Il peut s’agir de texte brut ou d’un objet ou tableau JSON rendu sous forme de texte étiqueté. Gardez clairs les noms de champs, les unités, les conditions des politiques et les passages sources pertinents. Rédigez une instruction précise pour chaque question et donnez à ses options des significations qui puissent être distinguées à partir de l’enregistrement. Pour une tâche originale de routage des demandes d’assistance, l’état peut contenir la demande et son contexte, tandis que les choix définissent des catégories livraison, accès et assistance produit avec de courtes descriptions.\n\nUne deuxième question peut évaluer l’urgence, et une question ordonnée peut noter le degré de suivi nécessaire à la demande. Ces questions répondent à des interrogations opérationnelles différentes : définissez donc chacune séparément. Incluez une option appropriée de revue ou d’éléments manquants lorsque la tâche de choix en a besoin, et conservez la distribution complète lorsque plusieurs catégories sont plausibles. L’application décide comment router ou réviser un résultat ; le modèle fournit l’enregistrement noté.\n\nKev-4B est conçu pour des décisions typées portant sur des documents de quelques milliers de tokens. Le profil de service de son concepteur accepte des états allant jusqu’à 65 536 tokens et réserve un espace supplémentaire pour chaque question, tandis que la longueur de contexte validée pour ce checkpoint est de 8192 tokens. Ce sont des limites différentes : accepter un état plus long n’établit pas que les décisions sont aussi fiables à toutes les longueurs. Gardez les passages décisifs compacts et préservez leurs étiquettes lorsque vous préparez un long enregistrement pour la classification.\n\nLe profil publié est en anglais. Ses tâches utiles dépendent des éléments probants présents dans l’état fourni et des options définies, plutôt que du chat ouvert, du résumé ou des réponses fondées sur des connaissances générales. L’arithmétique des dates au jour près constitue une limitation particulière : le concepteur fournit un préprocesseur distinct de faits de dates qui produit des intervalles calculés. Pour une vérification d’échéance, incluez dans l’état les dates pertinentes et les intervalles en jours calculés, ainsi que la règle qui les utilise.\n\nLe checkpoint est livré avec un calibrage des probabilités ajusté, mais la confiance peut varier selon le domaine des documents et la conception des questions. Le concepteur documente aussi l’affinage du checkpoint ouvert sur des étiquettes propres à une tâche et l’ajustement de son calibrage des probabilités à cette charge de travail ; il s’agit d’un processus de personnalisation distinct de la notation d’un état fourni. Choisissez les seuils de décision à l’aide d’exemples étiquetés de la charge de travail réelle, et gardez les cas incertains visibles pour la revue. Le concepteur exclut les décisions entièrement automatisées ayant des conséquences pour des personnes sans revue humaine. L’ordre des options peut aussi influer sur une réponse : conservez donc un ordre stable lorsque vous comparez des résultats. Évaluez l’étiquette choisie, le champ de confiance distinct et la distribution de probabilités selon le rôle que chacun joue dans votre flux de travail.\n\nLa version actuelle de Kev-4B décrite par le concepteur appartient à Kev 1.0 et repose sur la base Qwen3.5. Les versions antérieures fondées sur Qwen3 et celles limitées à l’étape documentaire restent des versions distinctes. Associez l’édition choisie et les définitions des questions aux sorties lorsque vous développez un flux de travail propre à une tâche, plutôt que de mélanger des résultats issus de profils différents.\n\nUn artefact final utile est un ensemble nommé d’enregistrements de décision comprenant les questions d’origine, les définitions des options, les distributions et, le cas échéant, les légendes des niveaux ordonnés. Pour un contrôle de la qualité d’une réponse, l’état doit inclure la réponse proposée, les éléments probants et le critère testé. Pour un triage au regard de politiques, il doit inclure la règle applicable et les faits pertinents. Conservez cette entrée à côté du résultat afin qu’une revue puisse établir pourquoi une décision était appropriée ou quel fait manquant doit être fourni.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "23732d2a0f5040447410fd33813e0572442406670bbf63956c64bbf8cfcc5c1a", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "fr", "methods": [ { "html": "jaredpalmer/kev-4bKev-4B note des questions typées portant sur un document en anglais fourni et renvoie des probabilités calibrées sur les options que vous définissez. Utilisez des questions oui/non, de choix et de score ordonné pour la classification, le routage, le triage et les vérifications qui exigent une décision structurée plutôt qu’un texte généré.
Cette description présente les capacités du modèle. Les entrées, sorties et options disponibles dans Ailoot pour la méthode sélectionnée figurent ci-dessous.
Kev-4B est un modèle de décision compact qui répond à des questions typées portant sur un état fourni. L’état est le document ou l’enregistrement évalué, et chaque question définit les options que le modèle peut noter. Son résultat est une distribution de probabilités et un enregistrement de décision typé, ce qui le rend utile pour la classification de documents, le routage, le triage, les choix d’extraction et les vérifications au regard de critères énoncés.
Le modèle associe un backbone Qwen3.5-4B-Base figé à un adaptateur LoRA et à une tête de pointage (pointer head). Le backbone compte 32 couches, dont 24 couches Gated DeltaNet et huit couches d’attention complète. L’adaptateur cible les projections d’attention, MLP et DeltaNet ; la tête de pointage note les options fournies et convertit ces notes en probabilités. Il s’agit d’un processus de décision fonctionnant uniquement en phase de préremplissage (prefill), les options formant l’espace des réponses.
Trois types de questions peuvent figurer dans une même requête. Une question de choix accepte de 1 à 255 options nommées, éventuellement accompagnées de descriptions, et renvoie l’option la plus probable, une valeur de confiance distincte et les probabilités des options. Une question oui/non, appelée noul dans le format du concepteur, renvoie la probabilité de oui. Définissez la signification de oui dans la question plutôt que de supposer qu’une valeur élevée correspond toujours à une issue positive pour l’application.
Une question de score ordonné accepte de 1 à 255 niveaux et renvoie les probabilités des niveaux ainsi que leur indice attendu. Les indices de niveau commencent à zéro. Le format de résultat du concepteur inclut également la légende des niveaux et une valeur de confiance distincte. Un indice attendu peut être fractionnaire : il résume la distribution sur vos niveaux ordonnés plutôt que de sélectionner une nouvelle étiquette textuelle. Conservez l’ordre et la légende des niveaux avec le résultat afin qu’une note puisse être interprétée de manière cohérente.
Les questions partagent le même état mais sont évaluées indépendamment. Une question ne peut pas lire la réponse d’une autre question, et l’état est calculé une seule fois puis réutilisé. Si une décision ultérieure dépend du résultat d’une décision antérieure, rendez cette dépendance explicite dans un état suivant au lieu d’attendre des questions d’une même requête qu’elles forment une chaîne. Ce processus à état partagé convient ainsi à plusieurs vérifications indépendantes sur un même document.
Préparez l’état avec les éléments probants dont les questions ont réellement besoin. Il peut s’agir de texte brut ou d’un objet ou tableau JSON rendu sous forme de texte étiqueté. Gardez clairs les noms de champs, les unités, les conditions des politiques et les passages sources pertinents. Rédigez une instruction précise pour chaque question et donnez à ses options des significations qui puissent être distinguées à partir de l’enregistrement. Pour une tâche originale de routage des demandes d’assistance, l’état peut contenir la demande et son contexte, tandis que les choix définissent des catégories livraison, accès et assistance produit avec de courtes descriptions.
Une deuxième question peut évaluer l’urgence, et une question ordonnée peut noter le degré de suivi nécessaire à la demande. Ces questions répondent à des interrogations opérationnelles différentes : définissez donc chacune séparément. Incluez une option appropriée de revue ou d’éléments manquants lorsque la tâche de choix en a besoin, et conservez la distribution complète lorsque plusieurs catégories sont plausibles. L’application décide comment router ou réviser un résultat ; le modèle fournit l’enregistrement noté.
Kev-4B est conçu pour des décisions typées portant sur des documents de quelques milliers de tokens. Le profil de service de son concepteur accepte des états allant jusqu’à 65 536 tokens et réserve un espace supplémentaire pour chaque question, tandis que la longueur de contexte validée pour ce checkpoint est de 8192 tokens. Ce sont des limites différentes : accepter un état plus long n’établit pas que les décisions sont aussi fiables à toutes les longueurs. Gardez les passages décisifs compacts et préservez leurs étiquettes lorsque vous préparez un long enregistrement pour la classification.
Le profil publié est en anglais. Ses tâches utiles dépendent des éléments probants présents dans l’état fourni et des options définies, plutôt que du chat ouvert, du résumé ou des réponses fondées sur des connaissances générales. L’arithmétique des dates au jour près constitue une limitation particulière : le concepteur fournit un préprocesseur distinct de faits de dates qui produit des intervalles calculés. Pour une vérification d’échéance, incluez dans l’état les dates pertinentes et les intervalles en jours calculés, ainsi que la règle qui les utilise.
Le checkpoint est livré avec un calibrage des probabilités ajusté, mais la confiance peut varier selon le domaine des documents et la conception des questions. Le concepteur documente aussi l’affinage du checkpoint ouvert sur des étiquettes propres à une tâche et l’ajustement de son calibrage des probabilités à cette charge de travail ; il s’agit d’un processus de personnalisation distinct de la notation d’un état fourni. Choisissez les seuils de décision à l’aide d’exemples étiquetés de la charge de travail réelle, et gardez les cas incertains visibles pour la revue. Le concepteur exclut les décisions entièrement automatisées ayant des conséquences pour des personnes sans revue humaine. L’ordre des options peut aussi influer sur une réponse : conservez donc un ordre stable lorsque vous comparez des résultats. Évaluez l’étiquette choisie, le champ de confiance distinct et la distribution de probabilités selon le rôle que chacun joue dans votre flux de travail.
La version actuelle de Kev-4B décrite par le concepteur appartient à Kev 1.0 et repose sur la base Qwen3.5. Les versions antérieures fondées sur Qwen3 et celles limitées à l’étape documentaire restent des versions distinctes. Associez l’édition choisie et les définitions des questions aux sorties lorsque vous développez un flux de travail propre à une tâche, plutôt que de mélanger des résultats issus de profils différents.
Un artefact final utile est un ensemble nommé d’enregistrements de décision comprenant les questions d’origine, les définitions des options, les distributions et, le cas échéant, les légendes des niveaux ordonnés. Pour un contrôle de la qualité d’une réponse, l’état doit inclure la réponse proposée, les éléments probants et le critère testé. Pour un triage au regard de politiques, il doit inclure la règle applicable et les faits pertinents. Conservez cette entrée à côté du résultat afin qu’une revue puisse établir pourquoi une décision était appropriée ou quel fait manquant doit être fourni.
POST /v1/systemonetextdecisions| Champ | Type | Exigence | Valeurs et limites | Par défaut |
|---|---|---|---|---|
Champmodel | Typestring | ExigenceObligatoire | Valeurs et limites jaredpalmer/kev-4b | Par défaut— |
Champprovider | Typeschema | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champquestions | Typeobject | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champsession_id | Typestring | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champstate | Typeschema | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champtrace | Typeschema | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champuser | Typestring | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champquestions.<id>.type | Typestring | ExigenceObligatoire | Valeurs et limites noul, choice, score | Par défaut— |
Champquestions.<id>.instructions | Typestring|object|array | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champquestions.<id>.criteria | Typeobject|array | ExigenceFacultatif | Valeurs et limites Conditions: choice/score : obligatoires ; noul : facultatif. Les critères de choice forment un objet ; score est un tableau avec minItems égal à 1. | Par défaut— |
Champquestions.<id>.criteria.true | Typestring|object|array | ExigenceObligatoire | Valeurs et limites S’applique lorsque: objet de critères noul fourni | Par défaut— |
Champquestions.<id>.criteria.false | Typestring|object|array | ExigenceObligatoire | Valeurs et limites S’applique lorsque: objet de critères noul fourni | Par défaut— |
noul · Obligatoire : state, questions.<id>.type=noul, questions.<id>.instructions
choice · Obligatoire : state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Obligatoire : state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Paramètre | Contrat |
|---|---|
Paramètrecontent_type | Contratapplication/json |
Paramètrerequired | Contratmodel, state, questions |
Paramètrematerial_types | Contrattext |
Paramètreoptional_controls | Contratprovider, session_id, trace, user |
Paramètremultimodal_input_binding | Contratnull |
Cycle de vie : synchronous
Envoyez l’identifiant exact du modèle et conservez la réponse native complète.
Les tarifs n’ajoutent pas d’options de requête. Les paramètres pris en charge figurent dans la méthode sélectionnée.
Associez chaque coût aux conditions indiquées. Utilisez un seul tarif pour chaque ensemble de configurations alternatives.
| Configuration | Barème tarifaire | Tokens de contexte, plus de | Tokens de contexte, jusqu’à la limite incluse | Coût |
|---|---|---|---|---|
| ConfigurationTarifs de base des tokens | Barème tarifaireTarif de base | Tokens de contexte, plus de— | Tokens de contexte, jusqu’à la limite incluseSans borne supérieure | Coût Entrée · Tokens en entrée $0.000084 / 1K tokens Sortie · Tokens en sortie $0 / 1K tokens Entrée · Lecture du cache — / 1K tokens Entrée · Écriture dans le cache — / 1K tokens Entrée · Écriture dans le cache, 1 h — / 1K tokens |
| ConfigurationPalier 1 de longueur de requête | Barème tarifaire— | Tokens de contexte, plus de0 | Tokens de contexte, jusqu’à la limite incluseSans borne supérieure | Coût Entrée · Tokens en entrée $0.000084 / 1K tokens Sortie · Tokens en sortie $0 / 1K tokens Entrée · Lecture du cache — / 1K tokens Entrée · Écriture dans le cache — / 1K tokens Entrée · Écriture dans le cache, 1 h — / 1K tokens |
Ailoot réserve un montant estimé avant une requête. Après le résultat, le montant final est débité selon l’utilisation mesurée. Pour le streaming, le montant final à débiter est calculé à partir du relevé final d’utilisation. Fonctionnement de la réservation et du débit →
{\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
Conservez chaque réponse, fichier et partie de contenu renvoyés dans leur intégralité.
Chaque réponse fournie pour un identifiant de question est conservée avec son type exact, sa valeur noul/choice/score, son degré de confiance, ses probabilités et sa légende. L’intégralité du JSON d’origine est enregistrée et renvoyée uniquement après le règlement.
Conservez l’opération d’origine et la réponse complète ou partielle ; ne rejouez pas le POST.
| Champ | Type |
|---|---|
Champmodel | Typestring |
Champid | Typestring |
Champprovider | Typestring |
Champanswers.<id>.type | Typestring |
Champanswers.<id>.noul | Typenumber |
Champanswers.<id>.choice | Typestring |
Champanswers.<id>.score | Typenumber |
Champanswers.<id>.confidence | Typenumber |
Champanswers.<id>.probabilities | Typeobject |
Champanswers.<id>.legend | Typeobject |
Champusage.input_tokens | Typeinteger |
Champusage.output_tokens | Typeinteger |
Champusage.cost | Typenumber |
| Réponse | Condition | Étape suivante |
|---|---|---|
Réponse400 · invalid_request_error | ConditionChamp obligatoire, représentation ou valeur non valide | Étape suivanteCorrigez le champ de requête indiqué. |
Ailoot Ultra jaredpalmer/kev-4b
Utilisez les chemins de méthode indiqués ci-dessus.