Kev-4B est un modèle de décision compact destiné à répondre à des questions typées sur un état fourni. L’état est le document ou le dossier é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 documentaire, l’orientation, le triage, les choix d’extraction et les vérifications selon des critères énoncés.
Le modèle associe une architecture de base Qwen3.5-4B-Base gelée, un adaptateur LoRA et une tête de pointage. L’architecture de base comporte 32 couches, dont 24 couches Gated DeltaNet et huit couches à attention complète. L’adaptateur cible les projections d’attention, de MLP et de DeltaNet ; la tête de pointage évalue les options fournies et convertit ces scores en probabilités. Il s’agit d’un processus de décision limité au préremplissage, les options constituant l’espace des réponses.
Trois types de questions peuvent figurer dans une même requête. Une question choice accepte de 1 à 255 options nommées, éventuellement assorties 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 fabricant, renvoie la probabilité de oui. Définissez le sens de oui dans la question, plutôt que de supposer qu’une valeur élevée signifie 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 des niveaux commencent à zéro. Le format de résultat du fabricant comprend aussi la légende des niveaux et une valeur de confiance distincte. Un indice attendu peut être fractionnaire : il résume la distribution entre vos niveaux ordonnés, plutôt que de sélectionner un nouveau libellé textuel. Gardez l’ordre des niveaux et la légende 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 ; l’état est calculé une fois, puis réutilisé. Si une décision ultérieure dépend du résultat d’une décision antérieure, explicitez cette dépendance dans un état ultérieur, plutôt que d’attendre des questions d’une même requête qu’elles forment une chaîne. Cela rend le processus à état partagé adapté à plusieurs vérifications indépendantes sur le même document.
Préparez l’état avec les éléments réellement nécessaires aux questions. Il peut s’agir de texte brut ou d’un objet ou tableau JSON rendu sous forme de texte étiqueté. Gardez clairs les noms des champs, les unités, les conditions des règles et les passages sources pertinents. Rédigez une instruction précise pour chaque question et attribuez à ses options des sens que le dossier permet de distinguer. Pour une tâche originale d’orientation de demandes d’assistance, l’état peut contenir la demande et son contexte, tandis que les choix définissent des catégories de livraison, d’accès et d’assistance produit, accompagnées de courtes descriptions.
Une deuxième question peut évaluer l’urgence, et une question ordonnée peut noter l’ampleur du suivi nécessaire pour la demande. Elles répondent à des questions opérationnelles différentes ; définissez donc chacune séparément. Incluez une option appropriée de vérification ou d’éléments manquants lorsque la tâche de choix en nécessite une, et conservez toute la distribution lorsque plusieurs catégories sont plausibles. L’application décide comment orienter ou vérifier un résultat ; le modèle fournit l’enregistrement évalué.
Kev-4B est destiné aux décisions typées sur des documents de quelques milliers de tokens. Le profil de service de son fabricant accepte des états pouvant atteindre 65 536 tokens et réserve un espace supplémentaire à chaque question, tandis que la longueur de contexte validée pour cette version est de 8192 tokens. Ces limites sont différentes : accepter un état plus long n’établit pas des décisions d’une fiabilité équivalente à toute longueur. Gardez les passages décisifs compacts et préservez leurs libellés lorsque vous préparez un long dossier pour la classification.
Le profil publié est anglophone. Ses tâches utiles dépendent des éléments de l’état fourni et des options définies, plutôt que du chat ouvert, du résumé ou de réponses générales fondées sur des connaissances. L’arithmétique des dates au jour près constitue une limite particulière : le fabricant fournit un préprocesseur distinct de faits temporels, qui apporte des intervalles calculés. Pour vérifier une échéance, incluez dans l’état les dates pertinentes et les intervalles calculés en jours, ainsi que la règle qui les utilise.
La version est fournie avec un calibrage ajusté des probabilités, mais la confiance peut varier selon le domaine documentaire et la conception des questions. Le fabricant documente aussi l’ajustement du modèle ouvert sur des libellés propres à la tâche et l’adaptation de son calibrage des probabilités à cette activité ; il s’agit d’un processus de personnalisation distinct de l’évaluation d’un état fourni. Choisissez les seuils de décision à partir d’exemples annotés de l’activité réelle et gardez les cas incertains visibles pour vérification. Le fabricant exclut les décisions entièrement automatisées ayant des conséquences pour des personnes sans vérification humaine. L’ordre des options peut aussi influencer une réponse ; conservez donc un ordre stable lorsque vous comparez des résultats. Évaluez le libellé choisi, le champ de confiance distinct et la distribution de probabilités selon le rôle de chacun dans votre processus.
La publication actuelle de Kev-4B décrite par le fabricant appartient à Kev 1.0 et utilise la base Qwen3.5. Les publications antérieures fondées sur Qwen3 et celles limitées au stade documentaire restent des versions distinctes. Gardez l’édition choisie et les définitions des questions associées aux sorties lorsque vous développez un processus propre à une tâche, plutôt que de mélanger des résultats 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 les éventuelles légendes de niveaux ordonnés. Pour un contrôle de qualité d’une réponse, l’état doit inclure la réponse proposée, les éléments et le critère testé. Pour un triage selon des règles, il doit inclure la règle applicable et les faits pertinents. Conservez cette entrée avec le résultat, afin qu’une vérification 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 destiné à répondre à des questions typées sur un état fourni. L’état est le document ou le dossier é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 documentaire, l’orientation, le triage, les choix d’extraction et les vérifications selon des critères énoncés.\n\nLe modèle associe une architecture de base Qwen3.5-4B-Base gelée, un adaptateur LoRA et une tête de pointage. L’architecture de base comporte 32 couches, dont 24 couches Gated DeltaNet et huit couches à attention complète. L’adaptateur cible les projections d’attention, de MLP et de DeltaNet ; la tête de pointage évalue les options fournies et convertit ces scores en probabilités. Il s’agit d’un processus de décision limité au préremplissage, les options constituant l’espace des réponses.\n\nTrois types de questions peuvent figurer dans une même requête. Une question choice accepte de 1 à 255 options nommées, éventuellement assorties 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 fabricant, renvoie la probabilité de oui. Définissez le sens de oui dans la question, plutôt que de supposer qu’une valeur élevée signifie 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 des niveaux commencent à zéro. Le format de résultat du fabricant comprend aussi la légende des niveaux et une valeur de confiance distincte. Un indice attendu peut être fractionnaire : il résume la distribution entre vos niveaux ordonnés, plutôt que de sélectionner un nouveau libellé textuel. Gardez l’ordre des niveaux et la légende 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 ; l’état est calculé une fois, puis réutilisé. Si une décision ultérieure dépend du résultat d’une décision antérieure, explicitez cette dépendance dans un état ultérieur, plutôt que d’attendre des questions d’une même requête qu’elles forment une chaîne. Cela rend le processus à état partagé adapté à plusieurs vérifications indépendantes sur le même document.\n\nPréparez l’état avec les éléments réellement nécessaires aux questions. Il peut s’agir de texte brut ou d’un objet ou tableau JSON rendu sous forme de texte étiqueté. Gardez clairs les noms des champs, les unités, les conditions des règles et les passages sources pertinents. Rédigez une instruction précise pour chaque question et attribuez à ses options des sens que le dossier permet de distinguer. Pour une tâche originale d’orientation de demandes d’assistance, l’état peut contenir la demande et son contexte, tandis que les choix définissent des catégories de livraison, d’accès et d’assistance produit, accompagnées de courtes descriptions.\n\nUne deuxième question peut évaluer l’urgence, et une question ordonnée peut noter l’ampleur du suivi nécessaire pour la demande. Elles répondent à des questions opérationnelles différentes ; définissez donc chacune séparément. Incluez une option appropriée de vérification ou d’éléments manquants lorsque la tâche de choix en nécessite une, et conservez toute la distribution lorsque plusieurs catégories sont plausibles. L’application décide comment orienter ou vérifier un résultat ; le modèle fournit l’enregistrement évalué.\n\nKev-4B est destiné aux décisions typées sur des documents de quelques milliers de tokens. Le profil de service de son fabricant accepte des états pouvant atteindre 65 536 tokens et réserve un espace supplémentaire à chaque question, tandis que la longueur de contexte validée pour cette version est de 8192 tokens. Ces limites sont différentes : accepter un état plus long n’établit pas des décisions d’une fiabilité équivalente à toute longueur. Gardez les passages décisifs compacts et préservez leurs libellés lorsque vous préparez un long dossier pour la classification.\n\nLe profil publié est anglophone. Ses tâches utiles dépendent des éléments de l’état fourni et des options définies, plutôt que du chat ouvert, du résumé ou de réponses générales fondées sur des connaissances. L’arithmétique des dates au jour près constitue une limite particulière : le fabricant fournit un préprocesseur distinct de faits temporels, qui apporte des intervalles calculés. Pour vérifier une échéance, incluez dans l’état les dates pertinentes et les intervalles calculés en jours, ainsi que la règle qui les utilise.\n\nLa version est fournie avec un calibrage ajusté des probabilités, mais la confiance peut varier selon le domaine documentaire et la conception des questions. Le fabricant documente aussi l’ajustement du modèle ouvert sur des libellés propres à la tâche et l’adaptation de son calibrage des probabilités à cette activité ; il s’agit d’un processus de personnalisation distinct de l’évaluation d’un état fourni. Choisissez les seuils de décision à partir d’exemples annotés de l’activité réelle et gardez les cas incertains visibles pour vérification. Le fabricant exclut les décisions entièrement automatisées ayant des conséquences pour des personnes sans vérification humaine. L’ordre des options peut aussi influencer une réponse ; conservez donc un ordre stable lorsque vous comparez des résultats. Évaluez le libellé choisi, le champ de confiance distinct et la distribution de probabilités selon le rôle de chacun dans votre processus.\n\nLa publication actuelle de Kev-4B décrite par le fabricant appartient à Kev 1.0 et utilise la base Qwen3.5. Les publications antérieures fondées sur Qwen3 et celles limitées au stade documentaire restent des versions distinctes. Gardez l’édition choisie et les définitions des questions associées aux sorties lorsque vous développez un processus propre à une tâche, plutôt que de mélanger des résultats 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 les éventuelles légendes de niveaux ordonnés. Pour un contrôle de qualité d’une réponse, l’état doit inclure la réponse proposée, les éléments et le critère testé. Pour un triage selon des règles, il doit inclure la règle applicable et les faits pertinents. Conservez cette entrée avec le résultat, afin qu’une vérification 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": "9b2a5ada17f3bcd5b2715f0e7b00efe5cb40bff51ecbbbbeaf3cfe5df85582a4", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "fr-ch", "methods": [ { "html": "jaredpalmer/kev-4bKev-4B évalue des questions typées sur un document anglais fourni et renvoie des probabilités calibrées pour les options que vous définissez. Utilisez des questions oui/non, de choix et de score ordonné pour la classification, l’orientation, le triage et les contrôles nécessitant 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 destiné à répondre à des questions typées sur un état fourni. L’état est le document ou le dossier é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 documentaire, l’orientation, le triage, les choix d’extraction et les vérifications selon des critères énoncés.
Le modèle associe une architecture de base Qwen3.5-4B-Base gelée, un adaptateur LoRA et une tête de pointage. L’architecture de base comporte 32 couches, dont 24 couches Gated DeltaNet et huit couches à attention complète. L’adaptateur cible les projections d’attention, de MLP et de DeltaNet ; la tête de pointage évalue les options fournies et convertit ces scores en probabilités. Il s’agit d’un processus de décision limité au préremplissage, les options constituant l’espace des réponses.
Trois types de questions peuvent figurer dans une même requête. Une question choice accepte de 1 à 255 options nommées, éventuellement assorties 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 fabricant, renvoie la probabilité de oui. Définissez le sens de oui dans la question, plutôt que de supposer qu’une valeur élevée signifie 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 des niveaux commencent à zéro. Le format de résultat du fabricant comprend aussi la légende des niveaux et une valeur de confiance distincte. Un indice attendu peut être fractionnaire : il résume la distribution entre vos niveaux ordonnés, plutôt que de sélectionner un nouveau libellé textuel. Gardez l’ordre des niveaux et la légende 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 ; l’état est calculé une fois, puis réutilisé. Si une décision ultérieure dépend du résultat d’une décision antérieure, explicitez cette dépendance dans un état ultérieur, plutôt que d’attendre des questions d’une même requête qu’elles forment une chaîne. Cela rend le processus à état partagé adapté à plusieurs vérifications indépendantes sur le même document.
Préparez l’état avec les éléments réellement nécessaires aux questions. Il peut s’agir de texte brut ou d’un objet ou tableau JSON rendu sous forme de texte étiqueté. Gardez clairs les noms des champs, les unités, les conditions des règles et les passages sources pertinents. Rédigez une instruction précise pour chaque question et attribuez à ses options des sens que le dossier permet de distinguer. Pour une tâche originale d’orientation de demandes d’assistance, l’état peut contenir la demande et son contexte, tandis que les choix définissent des catégories de livraison, d’accès et d’assistance produit, accompagnées de courtes descriptions.
Une deuxième question peut évaluer l’urgence, et une question ordonnée peut noter l’ampleur du suivi nécessaire pour la demande. Elles répondent à des questions opérationnelles différentes ; définissez donc chacune séparément. Incluez une option appropriée de vérification ou d’éléments manquants lorsque la tâche de choix en nécessite une, et conservez toute la distribution lorsque plusieurs catégories sont plausibles. L’application décide comment orienter ou vérifier un résultat ; le modèle fournit l’enregistrement évalué.
Kev-4B est destiné aux décisions typées sur des documents de quelques milliers de tokens. Le profil de service de son fabricant accepte des états pouvant atteindre 65 536 tokens et réserve un espace supplémentaire à chaque question, tandis que la longueur de contexte validée pour cette version est de 8192 tokens. Ces limites sont différentes : accepter un état plus long n’établit pas des décisions d’une fiabilité équivalente à toute longueur. Gardez les passages décisifs compacts et préservez leurs libellés lorsque vous préparez un long dossier pour la classification.
Le profil publié est anglophone. Ses tâches utiles dépendent des éléments de l’état fourni et des options définies, plutôt que du chat ouvert, du résumé ou de réponses générales fondées sur des connaissances. L’arithmétique des dates au jour près constitue une limite particulière : le fabricant fournit un préprocesseur distinct de faits temporels, qui apporte des intervalles calculés. Pour vérifier une échéance, incluez dans l’état les dates pertinentes et les intervalles calculés en jours, ainsi que la règle qui les utilise.
La version est fournie avec un calibrage ajusté des probabilités, mais la confiance peut varier selon le domaine documentaire et la conception des questions. Le fabricant documente aussi l’ajustement du modèle ouvert sur des libellés propres à la tâche et l’adaptation de son calibrage des probabilités à cette activité ; il s’agit d’un processus de personnalisation distinct de l’évaluation d’un état fourni. Choisissez les seuils de décision à partir d’exemples annotés de l’activité réelle et gardez les cas incertains visibles pour vérification. Le fabricant exclut les décisions entièrement automatisées ayant des conséquences pour des personnes sans vérification humaine. L’ordre des options peut aussi influencer une réponse ; conservez donc un ordre stable lorsque vous comparez des résultats. Évaluez le libellé choisi, le champ de confiance distinct et la distribution de probabilités selon le rôle de chacun dans votre processus.
La publication actuelle de Kev-4B décrite par le fabricant appartient à Kev 1.0 et utilise la base Qwen3.5. Les publications antérieures fondées sur Qwen3 et celles limitées au stade documentaire restent des versions distinctes. Gardez l’édition choisie et les définitions des questions associées aux sorties lorsque vous développez un processus propre à une tâche, plutôt que de mélanger des résultats 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 les éventuelles légendes de niveaux ordonnés. Pour un contrôle de qualité d’une réponse, l’état doit inclure la réponse proposée, les éléments et le critère testé. Pour un triage selon des règles, il doit inclure la règle applicable et les faits pertinents. Conservez cette entrée avec le résultat, afin qu’une vérification 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 : obligatoire ; noul : facultatif. Les critères de choice forment un objet ; score est un tableau avec minItems1. | 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 niveau 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 la facturation définitive.
Conservez l’opération d’origine et la réponse complète ou partielle ; ne répétez 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 invalide | Étape suivanteCorrigez le champ indiqué dans la requête. |
Ailoot Ultra jaredpalmer/kev-4b
Utilisez les chemins de méthode indiqués ci-dessus.