Mercury Decide est le modèle d’Inception pour les décisions structurées portant sur des éléments fournis. Il associe un état partagé à des questions nommées et renvoie des réponses typées assorties 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 délimitée qu’un logiciel peut interpréter ; son interface documentée ne génère pas de réponse de chat libre.
La requête du producteur contient un modèle, un état et une table non vide de questions. Les noms des questions sont préservés dans la table de réponses. Fournissez les informations nécessaires pour juger chaque question et nommez les questions selon les résultats utilisés par le processus, par exemple category, priority ou needs_follow_up. Plusieurs questions évaluent les mêmes éléments indépendamment. 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 aussi des chaînes, des objets ou des tableaux dans l’état, les instructions et les descriptions des critères, les instructions étant facultatives ou pouvant valoir null. Préservez les structures utiles lorsque les éléments se composent déjà de champs et gardez un document ou un message identifiable lorsque vous fournissez du texte. Pour un dossier d’assistance, incluez la demande réelle et les faits pertinents, plutôt que de demander d’inférer un contexte manquant.
Une question noul représente une condition oui/non. Sa sortie est une probabilité de 0 à 1 que la réponse positive s’applique. Des descriptions facultatives true et false peuvent préciser ce qui compte de chaque côté de la question. Par exemple, demandez si un message sollicite explicitement un remplacement et distinguez cela d’une plainte générale sur l’article. La probabilité fournit un jugement numérique ; l’application choisit le seuil et l’action du processus qui en découle.
Gardez la condition assez précise pour que les éléments puissent la trancher. Si une même question mélange le fait que l’utilisateur souhaite de l’aide, qu’un article soit défectueux et que le dossier soit urgent, séparez ces conditions. Conservez la probabilité renvoyée avec la définition de la question, afin qu’une personne vérifiant le résultat ultérieurement puisse comprendre ce que mesure réellement le nombre.
Une question Choice utilise une table d’un à 255 noms d’options et de descriptions ; les descriptions peuvent valoir null. Le choix renvoyé est l’option fournie dont la probabilité est la plus élevée. Le résultat contient aussi une probabilité pour chaque option et la confiance. Définissez des sens distincts pour les catégories et incluez une catégorie de repli lorsque certaines entrées se situeront en dehors des options précises. Des clés de sortie courtes peuvent identifier les catégories, tandis que des descriptions plus complètes établissent leurs frontières.
Un cahier des charges d’orientation pourrait distinguer un problème d’accès, une question produit et un défaut signalé. Énoncez le sens de chaque option et fournissez le message à orienter. La sortie est une catégorie sélectionnée avec une distribution, et non une instruction qui aurait déjà modifié une file ou contacté un autre système. Examinez les probabilités concurrentes lorsqu’un cas est ambigu, plutôt que d’interpréter le libellé gagnant comme une preuve de certitude.
Une question Score utilise un tableau ordonné d’une à dix descriptions de niveaux, en commençant au niveau 0. Son score est la moyenne des indices des niveaux pondérée par les probabilités et peut se situer entre des niveaux. La réponse contient la légende, les probabilités de chaque niveau et la confiance. Définissez l’ordre et les critères de chaque niveau, par exemple aucun impact immédiat, un problème avec une solution de remplacement utilisable et une tâche entièrement 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. Gardez la légende avec le nombre, afin qu’un score ne soit pas interprété selon une échelle sans rapport. La confiance de Choice et de Score est rapportée séparément entre 0 et 1 ; le guide pertinent ne la définit pas comme identique à la probabilité maximale d’une option et ne fournit pas de formule universelle pour la reconstruire.
Un même ensemble d’éléments peut servir à des questions indépendantes de catégorie, d’urgence et de condition. Une tâche de vérification documentaire peut demander si un sujet requis est présent, choisir sa catégorie et noter sa pertinence selon des niveaux décrits. Utilisez uniquement les sources disponibles dans l’état, avec des critères liés à la prochaine décision nécessaire au processus. Si une action nécessite un résultat antérieur, explicitez ce résultat dans les éléments de l’étape suivante, plutôt que de supposer que les questions forment une séquence cachée.
La réponse renvoie le nom du modèle et une table answers dont les clés sont les noms des questions fournis. Les probabilités Choice utilisent les noms des options ; les probabilités Score utilisent des indices sous forme de chaînes, avec une légende expliquant ces indices. Gardez associés l’identifiant de l’état, les définitions des questions et les réponses typées. Cela produit un artefact de classification ou de notation interprétable, plutôt qu’un nombre détaché des faits qui l’ont généré.
Inception documente Mercury Decide via son interface de décision dédiée. Il ne prend pas en charge les interfaces de chat-completion, de streaming ou d’appels d’outils du fabricant ; les capacités des profils Mercury de raisonnement, de voix et de génération de code ne doivent donc pas être transférées à ce modèle. Le guide de décision spécifie les nombres d’options et de niveaux, mais ne donne aucune limite numérique de tokens pour l’état ni aucun plafond de 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 du matériau annoté représentatif de la tâche visée. Examinez les réponses limites au regard de l’état et préservez les informations manquantes, plutôt que de les remplacer par des faits inventés. Un résultat utile de Mercury Decide fournit une décision fermée, ses probabilités et les définitions nécessaires à sa compréhension ; l’application environnante détermine comment ce résultat devient une orientation, une priorisation ou une issue de vérification.
", "aboutText": "Mercury Decide est le modèle d’Inception pour les décisions structurées portant sur des éléments fournis. Il associe un état partagé à des questions nommées et renvoie des réponses typées assorties 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 délimitée qu’un 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 porteurs de sens\n\nLa requête du producteur contient un modèle, un état et une table non vide de questions. Les noms des questions sont préservés dans la table de réponses. Fournissez les informations nécessaires pour juger chaque question et nommez les questions selon les résultats utilisés par le processus, par exemple category, priority ou needs_follow_up. Plusieurs questions évaluent les mêmes éléments indépendamment. 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 aussi des chaînes, des objets ou des tableaux dans l’état, les instructions et les descriptions des critères, les instructions étant facultatives ou pouvant valoir null. Préservez les structures utiles lorsque les éléments se composent déjà de champs et gardez un document ou un message identifiable lorsque vous fournissez du texte. Pour un dossier d’assistance, incluez la demande réelle et les faits pertinents, plutôt que de demander d’inférer un contexte manquant.\n\n### Noul : une réponse positive estimée\n\nUne question noul représente une condition oui/non. Sa sortie est une probabilité de 0 à 1 que la réponse positive s’applique. Des descriptions facultatives true et false peuvent préciser ce qui compte de chaque côté de la question. Par exemple, demandez si un message sollicite explicitement un remplacement et distinguez cela d’une plainte générale sur l’article. La probabilité fournit un jugement numérique ; l’application choisit le seuil et l’action du processus qui en découle.\n\nGardez la condition assez précise pour que les éléments puissent la trancher. Si une même question mélange le fait que l’utilisateur souhaite de l’aide, qu’un article soit défectueux et que le dossier soit urgent, séparez ces conditions. Conservez la probabilité renvoyée avec la définition de la question, afin qu’une personne vérifiant le résultat ultérieurement puisse comprendre ce que mesure réellement le nombre.\n\n### Choice : sélectionner une option nommée\n\nUne question Choice utilise une table d’un à 255 noms d’options et de descriptions ; les descriptions peuvent valoir null. Le choix renvoyé est l’option fournie dont la probabilité est la plus élevée. Le résultat contient aussi une probabilité pour chaque option et la confiance. Définissez des sens distincts pour les catégories et incluez une catégorie de repli lorsque certaines entrées se situeront en dehors des options précises. Des clés de sortie courtes peuvent identifier les catégories, tandis que des descriptions plus complètes établissent leurs frontières.\n\nUn cahier des charges d’orientation pourrait distinguer un problème d’accès, une question produit et un défaut signalé. Énoncez le sens de chaque option et fournissez le message à orienter. La sortie est une catégorie sélectionnée avec une distribution, et non une instruction qui aurait déjà modifié une file ou contacté un autre système. Examinez les probabilités concurrentes lorsqu’un cas est ambigu, plutôt que d’interpréter le libellé gagnant comme une preuve de certitude.\n\n### Score : une position attendue sur une grille\n\nUne question Score utilise un tableau ordonné d’une à dix descriptions de niveaux, en commençant au niveau 0. Son score est la moyenne des indices des niveaux pondérée par les probabilités et peut se situer entre des niveaux. La réponse contient la légende, les probabilités de chaque niveau et la confiance. Définissez l’ordre et les critères de chaque niveau, par exemple aucun impact immédiat, un problème avec une solution de remplacement utilisable et une tâche entièrement 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. Gardez la légende avec le nombre, afin qu’un score ne soit pas interprété selon une échelle sans rapport. La confiance de Choice et de Score est rapportée séparément entre 0 et 1 ; le guide pertinent ne la définit pas comme identique à la probabilité maximale d’une option et ne fournit pas de formule universelle pour la reconstruire.\n\n### Préparer un résultat de décision utile\n\nUn même ensemble d’éléments peut servir à des questions indépendantes de catégorie, d’urgence et de condition. Une tâche de vérification documentaire peut demander si un sujet requis est présent, choisir sa catégorie et noter sa pertinence selon des niveaux décrits. Utilisez uniquement les sources disponibles dans l’état, avec des critères liés à la prochaine décision nécessaire au processus. Si une action nécessite un résultat antérieur, explicitez ce résultat dans les éléments de l’étape suivante, plutôt que de supposer que les questions forment une séquence cachée.\n\nLa réponse renvoie le nom du modèle et une table answers dont les clés sont les noms des questions fournis. Les probabilités Choice utilisent les noms des options ; les probabilités Score utilisent des indices sous forme de chaînes, avec une légende expliquant ces indices. Gardez associés l’identifiant de l’état, les définitions des questions et les réponses typées. Cela produit un artefact de classification ou de notation interprétable, plutôt qu’un nombre détaché des faits qui l’ont généré.\n\n### Périmètre et limites de l’interface\n\nInception documente Mercury Decide via son interface de décision dédiée. Il ne prend pas en charge les interfaces de chat-completion, de streaming ou d’appels d’outils du fabricant ; les capacités des profils Mercury de raisonnement, de voix et de génération de code ne doivent donc pas être transférées à ce modèle. Le guide de décision spécifie les nombres d’options et de niveaux, mais ne donne aucune limite numérique de tokens pour l’état ni aucun plafond de 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 du matériau annoté représentatif de la tâche visée. Examinez les réponses limites au regard de l’état et préservez les informations manquantes, plutôt que de les remplacer par des faits inventés. Un résultat utile de Mercury Decide fournit une décision fermée, ses probabilités et les définitions nécessaires à sa compréhension ; l’application environnante détermine comment ce résultat devient une orientation, une priorisation ou une issue de vérification.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "7a885d2993f351e179bba0bc51b3ce9ba92241b5238c97cf54ccc129f9829ccf", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "fr-be", "methods": [ { "html": "inception/mercury-decideMercury Decide évalue des éléments textuels ou JSON partagés à l’aide de questions nommées et renvoie des choix typés, des probabilités oui/non ou des scores fractionnaires sur une grille. Inception documente un processus de décision dédié avec 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 pour les décisions structurées portant sur des éléments fournis. Il associe un état partagé à des questions nommées et renvoie des réponses typées assorties 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 délimitée qu’un logiciel peut interpréter ; son interface documentée ne génère pas de réponse de chat libre.
La requête du producteur contient un modèle, un état et une table non vide de questions. Les noms des questions sont préservés dans la table de réponses. Fournissez les informations nécessaires pour juger chaque question et nommez les questions selon les résultats utilisés par le processus, par exemple category, priority ou needs_follow_up. Plusieurs questions évaluent les mêmes éléments indépendamment. 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 aussi des chaînes, des objets ou des tableaux dans l’état, les instructions et les descriptions des critères, les instructions étant facultatives ou pouvant valoir null. Préservez les structures utiles lorsque les éléments se composent déjà de champs et gardez un document ou un message identifiable lorsque vous fournissez du texte. Pour un dossier d’assistance, incluez la demande réelle et les faits pertinents, plutôt que de demander d’inférer un contexte manquant.
Une question noul représente une condition oui/non. Sa sortie est une probabilité de 0 à 1 que la réponse positive s’applique. Des descriptions facultatives true et false peuvent préciser ce qui compte de chaque côté de la question. Par exemple, demandez si un message sollicite explicitement un remplacement et distinguez cela d’une plainte générale sur l’article. La probabilité fournit un jugement numérique ; l’application choisit le seuil et l’action du processus qui en découle.
Gardez la condition assez précise pour que les éléments puissent la trancher. Si une même question mélange le fait que l’utilisateur souhaite de l’aide, qu’un article soit défectueux et que le dossier soit urgent, séparez ces conditions. Conservez la probabilité renvoyée avec la définition de la question, afin qu’une personne vérifiant le résultat ultérieurement puisse comprendre ce que mesure réellement le nombre.
Une question Choice utilise une table d’un à 255 noms d’options et de descriptions ; les descriptions peuvent valoir null. Le choix renvoyé est l’option fournie dont la probabilité est la plus élevée. Le résultat contient aussi une probabilité pour chaque option et la confiance. Définissez des sens distincts pour les catégories et incluez une catégorie de repli lorsque certaines entrées se situeront en dehors des options précises. Des clés de sortie courtes peuvent identifier les catégories, tandis que des descriptions plus complètes établissent leurs frontières.
Un cahier des charges d’orientation pourrait distinguer un problème d’accès, une question produit et un défaut signalé. Énoncez le sens de chaque option et fournissez le message à orienter. La sortie est une catégorie sélectionnée avec une distribution, et non une instruction qui aurait déjà modifié une file ou contacté un autre système. Examinez les probabilités concurrentes lorsqu’un cas est ambigu, plutôt que d’interpréter le libellé gagnant comme une preuve de certitude.
Une question Score utilise un tableau ordonné d’une à dix descriptions de niveaux, en commençant au niveau 0. Son score est la moyenne des indices des niveaux pondérée par les probabilités et peut se situer entre des niveaux. La réponse contient la légende, les probabilités de chaque niveau et la confiance. Définissez l’ordre et les critères de chaque niveau, par exemple aucun impact immédiat, un problème avec une solution de remplacement utilisable et une tâche entièrement 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. Gardez la légende avec le nombre, afin qu’un score ne soit pas interprété selon une échelle sans rapport. La confiance de Choice et de Score est rapportée séparément entre 0 et 1 ; le guide pertinent ne la définit pas comme identique à la probabilité maximale d’une option et ne fournit pas de formule universelle pour la reconstruire.
Un même ensemble d’éléments peut servir à des questions indépendantes de catégorie, d’urgence et de condition. Une tâche de vérification documentaire peut demander si un sujet requis est présent, choisir sa catégorie et noter sa pertinence selon des niveaux décrits. Utilisez uniquement les sources disponibles dans l’état, avec des critères liés à la prochaine décision nécessaire au processus. Si une action nécessite un résultat antérieur, explicitez ce résultat dans les éléments de l’étape suivante, plutôt que de supposer que les questions forment une séquence cachée.
La réponse renvoie le nom du modèle et une table answers dont les clés sont les noms des questions fournis. Les probabilités Choice utilisent les noms des options ; les probabilités Score utilisent des indices sous forme de chaînes, avec une légende expliquant ces indices. Gardez associés l’identifiant de l’état, les définitions des questions et les réponses typées. Cela produit un artefact de classification ou de notation interprétable, plutôt qu’un nombre détaché des faits qui l’ont généré.
Inception documente Mercury Decide via son interface de décision dédiée. Il ne prend pas en charge les interfaces de chat-completion, de streaming ou d’appels d’outils du fabricant ; les capacités des profils Mercury de raisonnement, de voix et de génération de code ne doivent donc pas être transférées à ce modèle. Le guide de décision spécifie les nombres d’options et de niveaux, mais ne donne aucune limite numérique de tokens pour l’état ni aucun plafond de 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 du matériau annoté représentatif de la tâche visée. Examinez les réponses limites au regard de l’état et préservez les informations manquantes, plutôt que de les remplacer par des faits inventés. Un résultat utile de Mercury Decide fournit une décision fermée, ses probabilités et les définitions nécessaires à sa compréhension ; l’application environnante détermine comment ce résultat devient une orientation, une priorisation ou une issue de vérification.
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 : obligatoire ; noul : facultatif. Les critères 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’ID 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 ID 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 stockée et renvoyée uniquement après le règlement.
Conservez l’opération d’origine ainsi que 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 invalide | Étape suivanteCorrigez le champ indiqué de la requête. |
Ailoot Ultra inception/mercury-decide
Utilisez les chemins de méthode indiqués ci-dessus.