Mercury Decide est le modèle d’Inception destiné aux décisions structurées sur des éléments fournis. Il combine un état partagé avec des questions nommées et renvoie des réponses typées accompagnées de probabilités. Le résultat peut être une catégorie sélectionnée, une probabilité oui/non estimée ou une position sur une échelle définie. Ce profil sert une décision fermée que le logiciel peut interpréter ; son interface documentée ne génère pas de réponse de chat libre.
La requête de l’éditeur contient un modèle, un état et un dictionnaire de questions non vide. Les noms des questions sont conservés dans le dictionnaire des réponses. Fournissez les informations nécessaires pour juger chaque question, et nommez les questions d’après les résultats qu’exploite le flux de travail, par exemple category, priority ou needs_follow_up. Plusieurs questions évaluent les mêmes éléments de manière indépendante. Leur présence dans une même requête ne rend pas une question ultérieure dépendante d’une réponse antérieure.
L’exemple d’Inception utilise un objet JSON pour l’état. Le guide autorise également des chaînes, des objets ou des tableaux dans l’état, les instructions et les descriptions de critères, les instructions étant facultatives ou null. Préservez une structure utile lorsque les éléments se présentent déjà sous forme de champs, et gardez un document ou un message identifiable lorsque vous fournissez du texte. Pour un cas d’assistance, incluez la demande réelle et les faits pertinents plutôt qu’une demande de déduire le contexte manquant.
Une question noul représente une condition oui/non. Sa sortie est une probabilité comprise entre 0 et 1 que la réponse positive s’applique. Des descriptions true et false facultatives peuvent préciser ce qui relève de chaque côté de la question. Par exemple, demandez si un message réclame explicitement un remplacement et distinguez ce cas d’une plainte générale concernant l’article. La probabilité fournit un jugement numérique ; l’application choisit le seuil et l’action du flux de travail qui en découle.
Gardez une condition suffisamment étroite pour que les éléments permettent de la trancher. Si une question mélange le fait que l’utilisateur souhaite de l’aide, que l’article est défectueux et que le cas est urgent, séparez ces conditions. Conservez la probabilité renvoyée avec la définition de la question afin qu’un relecteur ultérieur puisse savoir ce que mesure réellement le nombre.
Une question Choice utilise un dictionnaire contenant d’une à 255 paires de noms d’options et de descriptions ; les descriptions peuvent valoir null. Le choix renvoyé est l’option fournie ayant la probabilité la plus élevée. Le résultat contient également une probabilité pour chaque option et une confiance. Définissez des significations distinctes pour les catégories, et incluez une catégorie de repli lorsque certaines entrées sortiront des options spécifiques. Des clés de sortie courtes peuvent identifier les catégories, tandis que des descriptions plus complètes établissent les frontières entre elles.
Une consigne de routage peut distinguer un problème d’accès, une question sur un produit et un défaut signalé. Énoncez la signification de chaque option et fournissez le message à router. La sortie est une catégorie sélectionnée accompagnée d’une distribution, et non une instruction ayant déjà modifié une file d’attente ou contacté un autre système. Examinez les probabilités concurrentes lorsqu’un cas est ambigu plutôt que d’interpréter l’étiquette gagnante comme une preuve de certitude.
Une question Score utilise un tableau ordonné contenant d’une à dix descriptions de niveaux, en commençant au niveau 0. Son score est la moyenne des indices de niveau pondérée par les probabilités et peut se situer entre deux niveaux. La réponse contient la légende, les probabilités par niveau et la confiance. Définissez l’ordre et les critères de chaque niveau, par exemple aucun impact immédiat, un problème disposant d’une alternative praticable et une tâche totalement bloquée.
Un score attendu fractionnaire est utile pour la priorisation ou l’agrégation. Il diffère du choix du seul niveau le plus probable. Conservez la légende avec le nombre afin qu’un score ne soit pas interprété sur une échelle sans rapport. La confiance pour Choice et Score est indiquée séparément, entre 0 et 1 ; le guide concerné ne la définit pas comme identique à la probabilité d’option la plus élevée et ne fournit pas de formule universelle pour la reconstituer.
Un même élément probant peut étayer des questions indépendantes de catégorie, d’urgence et de condition. Une tâche de revue de documents peut demander si un sujet requis est présent, choisir sa catégorie et noter sa pertinence sur des niveaux décrits. Utilisez uniquement le contenu source disponible dans l’état, avec des critères liés à la décision dont le flux de travail a besoin ensuite. Si une action requiert un résultat antérieur, rendez ce résultat explicite dans les éléments de l’étape suivante au lieu de supposer que les questions forment une séquence cachée.
La réponse renvoie le nom du modèle et un dictionnaire de réponses indexé par les noms de questions fournis. Les probabilités Choice utilisent les noms des options ; les probabilités Score utilisent des indices sous forme de chaînes, la légende expliquant ces indices. Conservez associés l’identifiant de l’état, les définitions des questions et les réponses typées. Vous obtenez ainsi un artefact de classification ou de notation interprétable plutôt qu’un nombre détaché des faits qui l’ont produit.
Inception documente Mercury Decide via son interface de décision dédiée. Celle-ci ne prend pas en charge les interfaces de complétion de chat, de streaming ou d’appel d’outils du concepteur ; les capacités des profils Mercury de raisonnement, de voix et de génération de code ne doivent donc pas être transposées à ce modèle. Le guide de décision précise le nombre d’options et de niveaux, mais n’indique aucune limite numérique de tokens pour l’état ni de plafond du nombre de questions ; gardez les éléments partagés centrés sur les questions évaluées.
Évaluez les probabilités et les frontières entre catégories sur des données étiquetées représentatives de la tâche visée. Examinez les réponses limites au regard de l’état et conservez la trace des informations manquantes plutôt que de les remplacer par des faits inventés. Un résultat Mercury Decide utile fournit une décision fermée, ses probabilités et les définitions nécessaires pour la comprendre ; l’application environnante détermine comment ce résultat se traduit en routage, en priorisation ou en issue de revue.
", "aboutText": "Mercury Decide est le modèle d’Inception destiné aux décisions structurées sur des éléments fournis. Il combine un état partagé avec des questions nommées et renvoie des réponses typées accompagnées de probabilités. Le résultat peut être une catégorie sélectionnée, une probabilité oui/non estimée ou une position sur une échelle définie. Ce profil sert une décision fermée que le logiciel peut interpréter ; son interface documentée ne génère pas de réponse de chat libre.\n\n### État partagé et noms de questions explicites\n\nLa requête de l’éditeur contient un modèle, un état et un dictionnaire de questions non vide. Les noms des questions sont conservés dans le dictionnaire des réponses. Fournissez les informations nécessaires pour juger chaque question, et nommez les questions d’après les résultats qu’exploite le flux de travail, par exemple category, priority ou needs_follow_up. Plusieurs questions évaluent les mêmes éléments de manière indépendante. Leur présence dans une même requête ne rend pas une question ultérieure dépendante d’une réponse antérieure.\n\nL’exemple d’Inception utilise un objet JSON pour l’état. Le guide autorise également des chaînes, des objets ou des tableaux dans l’état, les instructions et les descriptions de critères, les instructions étant facultatives ou null. Préservez une structure utile lorsque les éléments se présentent déjà sous forme de champs, et gardez un document ou un message identifiable lorsque vous fournissez du texte. Pour un cas d’assistance, incluez la demande réelle et les faits pertinents plutôt qu’une demande de déduire le contexte manquant.\n\n### Noul : une estimation de la réponse positive\n\nUne question noul représente une condition oui/non. Sa sortie est une probabilité comprise entre 0 et 1 que la réponse positive s’applique. Des descriptions true et false facultatives peuvent préciser ce qui relève de chaque côté de la question. Par exemple, demandez si un message réclame explicitement un remplacement et distinguez ce cas d’une plainte générale concernant l’article. La probabilité fournit un jugement numérique ; l’application choisit le seuil et l’action du flux de travail qui en découle.\n\nGardez une condition suffisamment étroite pour que les éléments permettent de la trancher. Si une question mélange le fait que l’utilisateur souhaite de l’aide, que l’article est défectueux et que le cas est urgent, séparez ces conditions. Conservez la probabilité renvoyée avec la définition de la question afin qu’un relecteur ultérieur puisse savoir ce que mesure réellement le nombre.\n\n### Choice : sélectionner une option nommée\n\nUne question Choice utilise un dictionnaire contenant d’une à 255 paires de noms d’options et de descriptions ; les descriptions peuvent valoir null. Le choix renvoyé est l’option fournie ayant la probabilité la plus élevée. Le résultat contient également une probabilité pour chaque option et une confiance. Définissez des significations distinctes pour les catégories, et incluez une catégorie de repli lorsque certaines entrées sortiront des options spécifiques. Des clés de sortie courtes peuvent identifier les catégories, tandis que des descriptions plus complètes établissent les frontières entre elles.\n\nUne consigne de routage peut distinguer un problème d’accès, une question sur un produit et un défaut signalé. Énoncez la signification de chaque option et fournissez le message à router. La sortie est une catégorie sélectionnée accompagnée d’une distribution, et non une instruction ayant déjà modifié une file d’attente ou contacté un autre système. Examinez les probabilités concurrentes lorsqu’un cas est ambigu plutôt que d’interpréter l’étiquette gagnante comme une preuve de certitude.\n\n### Score : une position attendue sur une grille d’évaluation\n\nUne question Score utilise un tableau ordonné contenant d’une à dix descriptions de niveaux, en commençant au niveau 0. Son score est la moyenne des indices de niveau pondérée par les probabilités et peut se situer entre deux niveaux. La réponse contient la légende, les probabilités par niveau et la confiance. Définissez l’ordre et les critères de chaque niveau, par exemple aucun impact immédiat, un problème disposant d’une alternative praticable et une tâche totalement bloquée.\n\nUn score attendu fractionnaire est utile pour la priorisation ou l’agrégation. Il diffère du choix du seul niveau le plus probable. Conservez la légende avec le nombre afin qu’un score ne soit pas interprété sur une échelle sans rapport. La confiance pour Choice et Score est indiquée séparément, entre 0 et 1 ; le guide concerné ne la définit pas comme identique à la probabilité d’option la plus élevée et ne fournit pas de formule universelle pour la reconstituer.\n\n### Préparer un résultat de décision utile\n\nUn même élément probant peut étayer des questions indépendantes de catégorie, d’urgence et de condition. Une tâche de revue de documents peut demander si un sujet requis est présent, choisir sa catégorie et noter sa pertinence sur des niveaux décrits. Utilisez uniquement le contenu source disponible dans l’état, avec des critères liés à la décision dont le flux de travail a besoin ensuite. Si une action requiert un résultat antérieur, rendez ce résultat explicite dans les éléments de l’étape suivante au lieu de supposer que les questions forment une séquence cachée.\n\nLa réponse renvoie le nom du modèle et un dictionnaire de réponses indexé par les noms de questions fournis. Les probabilités Choice utilisent les noms des options ; les probabilités Score utilisent des indices sous forme de chaînes, la légende expliquant ces indices. Conservez associés l’identifiant de l’état, les définitions des questions et les réponses typées. Vous obtenez ainsi un artefact de classification ou de notation interprétable plutôt qu’un nombre détaché des faits qui l’ont produit.\n\n### Périmètre et limites de l’interface\n\nInception documente Mercury Decide via son interface de décision dédiée. Celle-ci ne prend pas en charge les interfaces de complétion de chat, de streaming ou d’appel d’outils du concepteur ; les capacités des profils Mercury de raisonnement, de voix et de génération de code ne doivent donc pas être transposées à ce modèle. Le guide de décision précise le nombre d’options et de niveaux, mais n’indique aucune limite numérique de tokens pour l’état ni de plafond du nombre de questions ; gardez les éléments partagés centrés sur les questions évaluées.\n\nÉvaluez les probabilités et les frontières entre catégories sur des données étiquetées représentatives de la tâche visée. Examinez les réponses limites au regard de l’état et conservez la trace des informations manquantes plutôt que de les remplacer par des faits inventés. Un résultat Mercury Decide utile fournit une décision fermée, ses probabilités et les définitions nécessaires pour la comprendre ; l’application environnante détermine comment ce résultat se traduit en routage, en priorisation ou en issue de revue.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "d6aa3741b15580b371eeef418eea34f6fa3a428d5eaa6bbbc17e4221b0512d1f", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "fr", "methods": [ { "html": "inception/mercury-decideMercury Decide évalue des éléments textuels ou JSON partagés au regard de questions nommées et renvoie des choix typés, des probabilités oui/non ou des scores fractionnaires sur une grille d’évaluation. Inception documente un processus de décision dédié prenant en charge jusqu’à 255 options Choice et dix niveaux Score.
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.
Mercury Decide est le modèle d’Inception destiné aux décisions structurées sur des éléments fournis. Il combine un état partagé avec des questions nommées et renvoie des réponses typées accompagnées de probabilités. Le résultat peut être une catégorie sélectionnée, une probabilité oui/non estimée ou une position sur une échelle définie. Ce profil sert une décision fermée que le logiciel peut interpréter ; son interface documentée ne génère pas de réponse de chat libre.
La requête de l’éditeur contient un modèle, un état et un dictionnaire de questions non vide. Les noms des questions sont conservés dans le dictionnaire des réponses. Fournissez les informations nécessaires pour juger chaque question, et nommez les questions d’après les résultats qu’exploite le flux de travail, par exemple category, priority ou needs_follow_up. Plusieurs questions évaluent les mêmes éléments de manière indépendante. Leur présence dans une même requête ne rend pas une question ultérieure dépendante d’une réponse antérieure.
L’exemple d’Inception utilise un objet JSON pour l’état. Le guide autorise également des chaînes, des objets ou des tableaux dans l’état, les instructions et les descriptions de critères, les instructions étant facultatives ou null. Préservez une structure utile lorsque les éléments se présentent déjà sous forme de champs, et gardez un document ou un message identifiable lorsque vous fournissez du texte. Pour un cas d’assistance, incluez la demande réelle et les faits pertinents plutôt qu’une demande de déduire le contexte manquant.
Une question noul représente une condition oui/non. Sa sortie est une probabilité comprise entre 0 et 1 que la réponse positive s’applique. Des descriptions true et false facultatives peuvent préciser ce qui relève de chaque côté de la question. Par exemple, demandez si un message réclame explicitement un remplacement et distinguez ce cas d’une plainte générale concernant l’article. La probabilité fournit un jugement numérique ; l’application choisit le seuil et l’action du flux de travail qui en découle.
Gardez une condition suffisamment étroite pour que les éléments permettent de la trancher. Si une question mélange le fait que l’utilisateur souhaite de l’aide, que l’article est défectueux et que le cas est urgent, séparez ces conditions. Conservez la probabilité renvoyée avec la définition de la question afin qu’un relecteur ultérieur puisse savoir ce que mesure réellement le nombre.
Une question Choice utilise un dictionnaire contenant d’une à 255 paires de noms d’options et de descriptions ; les descriptions peuvent valoir null. Le choix renvoyé est l’option fournie ayant la probabilité la plus élevée. Le résultat contient également une probabilité pour chaque option et une confiance. Définissez des significations distinctes pour les catégories, et incluez une catégorie de repli lorsque certaines entrées sortiront des options spécifiques. Des clés de sortie courtes peuvent identifier les catégories, tandis que des descriptions plus complètes établissent les frontières entre elles.
Une consigne de routage peut distinguer un problème d’accès, une question sur un produit et un défaut signalé. Énoncez la signification de chaque option et fournissez le message à router. La sortie est une catégorie sélectionnée accompagnée d’une distribution, et non une instruction ayant déjà modifié une file d’attente ou contacté un autre système. Examinez les probabilités concurrentes lorsqu’un cas est ambigu plutôt que d’interpréter l’étiquette gagnante comme une preuve de certitude.
Une question Score utilise un tableau ordonné contenant d’une à dix descriptions de niveaux, en commençant au niveau 0. Son score est la moyenne des indices de niveau pondérée par les probabilités et peut se situer entre deux niveaux. La réponse contient la légende, les probabilités par niveau et la confiance. Définissez l’ordre et les critères de chaque niveau, par exemple aucun impact immédiat, un problème disposant d’une alternative praticable et une tâche totalement bloquée.
Un score attendu fractionnaire est utile pour la priorisation ou l’agrégation. Il diffère du choix du seul niveau le plus probable. Conservez la légende avec le nombre afin qu’un score ne soit pas interprété sur une échelle sans rapport. La confiance pour Choice et Score est indiquée séparément, entre 0 et 1 ; le guide concerné ne la définit pas comme identique à la probabilité d’option la plus élevée et ne fournit pas de formule universelle pour la reconstituer.
Un même élément probant peut étayer des questions indépendantes de catégorie, d’urgence et de condition. Une tâche de revue de documents peut demander si un sujet requis est présent, choisir sa catégorie et noter sa pertinence sur des niveaux décrits. Utilisez uniquement le contenu source disponible dans l’état, avec des critères liés à la décision dont le flux de travail a besoin ensuite. Si une action requiert un résultat antérieur, rendez ce résultat explicite dans les éléments de l’étape suivante au lieu de supposer que les questions forment une séquence cachée.
La réponse renvoie le nom du modèle et un dictionnaire de réponses indexé par les noms de questions fournis. Les probabilités Choice utilisent les noms des options ; les probabilités Score utilisent des indices sous forme de chaînes, la légende expliquant ces indices. Conservez associés l’identifiant de l’état, les définitions des questions et les réponses typées. Vous obtenez ainsi un artefact de classification ou de notation interprétable plutôt qu’un nombre détaché des faits qui l’ont produit.
Inception documente Mercury Decide via son interface de décision dédiée. Celle-ci ne prend pas en charge les interfaces de complétion de chat, de streaming ou d’appel d’outils du concepteur ; les capacités des profils Mercury de raisonnement, de voix et de génération de code ne doivent donc pas être transposées à ce modèle. Le guide de décision précise le nombre d’options et de niveaux, mais n’indique aucune limite numérique de tokens pour l’état ni de plafond du nombre de questions ; gardez les éléments partagés centrés sur les questions évaluées.
Évaluez les probabilités et les frontières entre catégories sur des données étiquetées représentatives de la tâche visée. Examinez les réponses limites au regard de l’état et conservez la trace des informations manquantes plutôt que de les remplacer par des faits inventés. Un résultat Mercury Decide utile fournit une décision fermée, ses probabilités et les définitions nécessaires pour la comprendre ; l’application environnante détermine comment ce résultat se traduit en routage, en priorisation ou en issue de revue.
POST /v1/systemonetextdecisions| Champ | Type | Exigence | Valeurs et limites | Par défaut |
|---|---|---|---|---|
Champmodel | Typestring | ExigenceObligatoire | Valeurs et limites inception/mercury-decide | 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.00008 / 1K tokens Sortie · Tokens en sortie $0 / 1K tokens Entrée · Lecture du cache $0 / 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.00008 / 1K tokens Sortie · Tokens en sortie $0 / 1K tokens Entrée · Lecture du cache $0 / 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": "inception/mercury-decide",\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']='inception/mercury-decide'\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 inception/mercury-decide
Utilisez les chemins de méthode indiqués ci-dessus.