d1 est le modèle de décision hébergé de Liquid AI destiné aux tâches fermées de classification, de routage et de notation. Ce profil couvre son processus de décision textuelle : fournissez les éléments probants sous forme d’état, définissez une ou plusieurs questions et recevez des réponses numériques typées portant sur des issues connues. Liquid décrit ces décisions comme des évaluations qui renvoient directement des probabilités, avec zéro token de sortie généré. Le résultat utile est une décision définie et son incertitude, plutôt qu’un passage de texte nouvellement rédigé.
Fournissez le texte qui rend la décision possible, ainsi que le contexte nécessaire pour l’interpréter. Séparez l’état des instructions décrivant ce qu’il faut évaluer. Un message d’assistance peut nécessiter la description d’un produit ou d’un problème ; un passage de document peut nécessiter la question de recherche de l’utilisateur. Définissez l’ensemble des réponses avant de poser la question, et donnez à chaque option une signification adaptée au flux de travail visé. Des étiquettes courtes peuvent servir de clés de sortie stables, tandis que les descriptions précisent les frontières entre elles.
Utilisez des questions nommées sur un état partagé. Un nom clair comme intent, urgency ou relevant maintient la sortie associée à la décision qu’elle représente. Par exemple, un message signalant qu’une page ne fonctionne pas peut étayer un choix d’intention, une grille d’urgence et une vérification oui/non d’un défaut signalé. Chaque question doit conserver son propre critère au lieu de combiner les trois jugements dans une seule étiquette ambiguë.
Une question choice sélectionne une étiquette dans un ensemble non ordonné et renvoie la distribution sur les options nommées. Définissez les options au moyen de descriptions de critères ; le résultat comprend le choix sélectionné, les probabilités et la confiance. Pour l’organisation de documents, définissez les dossiers ou sujets possibles et indiquez quel contenu relève de chacun. Pour le routage des demandes, décrivez les destinations qui existent réellement. Une application peut utiliser l’étiquette obtenue pour choisir son étape suivante tout en conservant les probabilités concurrentes en vue d’une revue.
Une tâche de classement illustrative peut séparer une question sur un produit, un problème d’intégration et un problème d’accès, avec une option other pour les contenus hors de ces définitions. Gardez des frontières concrètes : un message signalant l’impossibilité de s’authentifier diffère d’un message demandant comment configurer une fonctionnalité. L’étiquette renvoyée sélectionne parmi les significations fournies ; elle ne crée pas une destination manquante et n’exécute aucune modification dans un autre système.
Une question noul renvoie une probabilité comprise entre 0 et 1 que la condition oui/non définie soit remplie. Liquid présente des vérifications binaires pour la revue de contenu et la pertinence de passages. Énoncez précisément la condition et choisissez la manière dont la probabilité obtenue sera utilisée : signaler une correspondance probable, filtrer un passage ou transmettre un cas incertain en revue. Le seuil relève de la tâche consommatrice, et une probabilité ne doit pas être traitée comme un verdict factuel garanti.
Pour le filtrage par pertinence, fournissez à la fois la requête et le passage candidat. Demandez si ce passage aide à répondre à la requête, puis conservez le passage d’origine avec sa probabilité. Cela permet de sélectionner des contenus sources pour une réponse ultérieure sans demander à d1 de rédiger lui-même cette réponse. Si la pertinence exige plusieurs degrés plutôt qu’une condition oui/non, définissez une grille ordonnée et utilisez une question score.
Une question score situe l’état sur une grille d’évaluation aux niveaux ordonnés et décrits. Les indices de niveau commencent à 0, et le score correspond à leur position pondérée par les probabilités, qui peut se situer entre deux niveaux. Le résultat comprend également la distribution des niveaux et la confiance. Pour l’urgence, définissez ce qui distingue un problème sans impact immédiat, un désagrément notable et une tâche bloquée. Une grille à quatre niveaux a donc les indices 0 à 3 ; son score attendu ne correspond pas automatiquement à une catégorie numérotée de 1 à 4.
Utilisez le score fractionnaire pour ordonner ou agréger lorsque c’est le résultat visé, et conservez la distribution complète lorsque l’ambiguïté compte. Les catégories telles que les services n’ont pas d’ordre naturel et relèvent d’une question choice. La confiance résume le caractère tranché de la réponse renvoyée dans l’interface documentée ; elle doit rester distincte du score recherché par la tâche et de toute garantie supposée de l’exactitude de la décision.
Plusieurs questions peuvent évaluer le même état en un seul appel à l’interface de l’éditeur, chacune conservant son type et ses probabilités. Les exemples textuels de Liquid comprennent le filtrage de tickets d’assistance, le classement de documents dans une arborescence de dossiers, la sélection de chemins de recherche de code, le choix parmi les actions disponibles d’un agent et la décision du contenu de sortie d’outil à conserver. Tous ces flux de travail comportent une décision suivante fermée. Une étape de recherche de code peut sélectionner un dossier prometteur à partir de ses descriptions ; une étape de sélection de contenu peut choisir keep, trim ou drop pour le contenu fourni. L’application environnante obtient toujours les données sources et effectue l’opération sélectionnée.
Les primitives documentées conviennent aux issues connues, aux notations sur grille et aux vérifications de conditions. Un nouveau texte rédigé, des résumés, du code et une conversation ouverte nécessitent un processus de génération ; ils ne découlent pas du résultat de décision de d1. Préparez une question autour d’éléments observables et conservez les définitions de cette question avec la sortie, afin qu’une étiquette ou un score puisse être interprété ultérieurement.
Maintenez chaque état centré sur les éléments qui répondent à ses questions définies, et séparez les tâches de décision sans rapport afin que leurs critères restent clairs. Gardez des contenus sources pertinents, définissez des significations de repli lorsque la couverture des catégories est incomplète et évaluez les seuils de probabilité à l’aide d’exemples étiquetés de la tâche. Un artefact utile enregistre la catégorie sélectionnée ou le score attendu, accompagné de sa distribution, de l’identité de la question et des éléments probants d’origine.
", "aboutText": "d1 est le modèle de décision hébergé de Liquid AI destiné aux tâches fermées de classification, de routage et de notation. Ce profil couvre son processus de décision textuelle : fournissez les éléments probants sous forme d’état, définissez une ou plusieurs questions et recevez des réponses numériques typées portant sur des issues connues. Liquid décrit ces décisions comme des évaluations qui renvoient directement des probabilités, avec zéro token de sortie généré. Le résultat utile est une décision définie et son incertitude, plutôt qu’un passage de texte nouvellement rédigé.\n\n### Préparer ensemble les éléments probants et la question\n\nFournissez le texte qui rend la décision possible, ainsi que le contexte nécessaire pour l’interpréter. Séparez l’état des instructions décrivant ce qu’il faut évaluer. Un message d’assistance peut nécessiter la description d’un produit ou d’un problème ; un passage de document peut nécessiter la question de recherche de l’utilisateur. Définissez l’ensemble des réponses avant de poser la question, et donnez à chaque option une signification adaptée au flux de travail visé. Des étiquettes courtes peuvent servir de clés de sortie stables, tandis que les descriptions précisent les frontières entre elles.\n\nUtilisez des questions nommées sur un état partagé. Un nom clair comme intent, urgency ou relevant maintient la sortie associée à la décision qu’elle représente. Par exemple, un message signalant qu’une page ne fonctionne pas peut étayer un choix d’intention, une grille d’urgence et une vérification oui/non d’un défaut signalé. Chaque question doit conserver son propre critère au lieu de combiner les trois jugements dans une seule étiquette ambiguë.\n\n### Le type choice pour les catégories et le routage\n\nUne question choice sélectionne une étiquette dans un ensemble non ordonné et renvoie la distribution sur les options nommées. Définissez les options au moyen de descriptions de critères ; le résultat comprend le choix sélectionné, les probabilités et la confiance. Pour l’organisation de documents, définissez les dossiers ou sujets possibles et indiquez quel contenu relève de chacun. Pour le routage des demandes, décrivez les destinations qui existent réellement. Une application peut utiliser l’étiquette obtenue pour choisir son étape suivante tout en conservant les probabilités concurrentes en vue d’une revue.\n\nUne tâche de classement illustrative peut séparer une question sur un produit, un problème d’intégration et un problème d’accès, avec une option other pour les contenus hors de ces définitions. Gardez des frontières concrètes : un message signalant l’impossibilité de s’authentifier diffère d’un message demandant comment configurer une fonctionnalité. L’étiquette renvoyée sélectionne parmi les significations fournies ; elle ne crée pas une destination manquante et n’exécute aucune modification dans un autre système.\n\n### Le type noul pour les vérifications de conditions et la pertinence\n\nUne question noul renvoie une probabilité comprise entre 0 et 1 que la condition oui/non définie soit remplie. Liquid présente des vérifications binaires pour la revue de contenu et la pertinence de passages. Énoncez précisément la condition et choisissez la manière dont la probabilité obtenue sera utilisée : signaler une correspondance probable, filtrer un passage ou transmettre un cas incertain en revue. Le seuil relève de la tâche consommatrice, et une probabilité ne doit pas être traitée comme un verdict factuel garanti.\n\nPour le filtrage par pertinence, fournissez à la fois la requête et le passage candidat. Demandez si ce passage aide à répondre à la requête, puis conservez le passage d’origine avec sa probabilité. Cela permet de sélectionner des contenus sources pour une réponse ultérieure sans demander à d1 de rédiger lui-même cette réponse. Si la pertinence exige plusieurs degrés plutôt qu’une condition oui/non, définissez une grille ordonnée et utilisez une question score.\n\n### Le type score pour les niveaux ordonnés\n\nUne question score situe l’état sur une grille d’évaluation aux niveaux ordonnés et décrits. Les indices de niveau commencent à 0, et le score correspond à leur position pondérée par les probabilités, qui peut se situer entre deux niveaux. Le résultat comprend également la distribution des niveaux et la confiance. Pour l’urgence, définissez ce qui distingue un problème sans impact immédiat, un désagrément notable et une tâche bloquée. Une grille à quatre niveaux a donc les indices 0 à 3 ; son score attendu ne correspond pas automatiquement à une catégorie numérotée de 1 à 4.\n\nUtilisez le score fractionnaire pour ordonner ou agréger lorsque c’est le résultat visé, et conservez la distribution complète lorsque l’ambiguïté compte. Les catégories telles que les services n’ont pas d’ordre naturel et relèvent d’une question choice. La confiance résume le caractère tranché de la réponse renvoyée dans l’interface documentée ; elle doit rester distincte du score recherché par la tâche et de toute garantie supposée de l’exactitude de la décision.\n\n### Questions multiples et applications de l’éditeur\n\nPlusieurs questions peuvent évaluer le même état en un seul appel à l’interface de l’éditeur, chacune conservant son type et ses probabilités. Les exemples textuels de Liquid comprennent le filtrage de tickets d’assistance, le classement de documents dans une arborescence de dossiers, la sélection de chemins de recherche de code, le choix parmi les actions disponibles d’un agent et la décision du contenu de sortie d’outil à conserver. Tous ces flux de travail comportent une décision suivante fermée. Une étape de recherche de code peut sélectionner un dossier prometteur à partir de ses descriptions ; une étape de sélection de contenu peut choisir keep, trim ou drop pour le contenu fourni. L’application environnante obtient toujours les données sources et effectue l’opération sélectionnée.\n\n### Périmètre et artefact de décision utile\n\nLes primitives documentées conviennent aux issues connues, aux notations sur grille et aux vérifications de conditions. Un nouveau texte rédigé, des résumés, du code et une conversation ouverte nécessitent un processus de génération ; ils ne découlent pas du résultat de décision de d1. Préparez une question autour d’éléments observables et conservez les définitions de cette question avec la sortie, afin qu’une étiquette ou un score puisse être interprété ultérieurement.\n\nMaintenez chaque état centré sur les éléments qui répondent à ses questions définies, et séparez les tâches de décision sans rapport afin que leurs critères restent clairs. Gardez des contenus sources pertinents, définissez des significations de repli lorsque la couverture des catégories est incomplète et évaluez les seuils de probabilité à l’aide d’exemples étiquetés de la tâche. Un artefact utile enregistre la catégorie sélectionnée ou le score attendu, accompagné de sa distribution, de l’identité de la question et des éléments probants d’origine.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "47d8e09ab32c3639c2c8276b6f6ea701480f591ef36e9469b0b1ef22a8206876", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "fr", "methods": [ { "html": "liquid/d1Le processus de décision textuelle de Liquid AI d1 évalue les éléments fournis au regard d’issues fixes et renvoie des probabilités, un choix de catégorie ou un score sur une grille d’évaluation. Il prend en charge la classification, le routage, le filtrage par pertinence et la priorisation sans générer de réponse rédigée.
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.
d1 est le modèle de décision hébergé de Liquid AI destiné aux tâches fermées de classification, de routage et de notation. Ce profil couvre son processus de décision textuelle : fournissez les éléments probants sous forme d’état, définissez une ou plusieurs questions et recevez des réponses numériques typées portant sur des issues connues. Liquid décrit ces décisions comme des évaluations qui renvoient directement des probabilités, avec zéro token de sortie généré. Le résultat utile est une décision définie et son incertitude, plutôt qu’un passage de texte nouvellement rédigé.
Fournissez le texte qui rend la décision possible, ainsi que le contexte nécessaire pour l’interpréter. Séparez l’état des instructions décrivant ce qu’il faut évaluer. Un message d’assistance peut nécessiter la description d’un produit ou d’un problème ; un passage de document peut nécessiter la question de recherche de l’utilisateur. Définissez l’ensemble des réponses avant de poser la question, et donnez à chaque option une signification adaptée au flux de travail visé. Des étiquettes courtes peuvent servir de clés de sortie stables, tandis que les descriptions précisent les frontières entre elles.
Utilisez des questions nommées sur un état partagé. Un nom clair comme intent, urgency ou relevant maintient la sortie associée à la décision qu’elle représente. Par exemple, un message signalant qu’une page ne fonctionne pas peut étayer un choix d’intention, une grille d’urgence et une vérification oui/non d’un défaut signalé. Chaque question doit conserver son propre critère au lieu de combiner les trois jugements dans une seule étiquette ambiguë.
Une question choice sélectionne une étiquette dans un ensemble non ordonné et renvoie la distribution sur les options nommées. Définissez les options au moyen de descriptions de critères ; le résultat comprend le choix sélectionné, les probabilités et la confiance. Pour l’organisation de documents, définissez les dossiers ou sujets possibles et indiquez quel contenu relève de chacun. Pour le routage des demandes, décrivez les destinations qui existent réellement. Une application peut utiliser l’étiquette obtenue pour choisir son étape suivante tout en conservant les probabilités concurrentes en vue d’une revue.
Une tâche de classement illustrative peut séparer une question sur un produit, un problème d’intégration et un problème d’accès, avec une option other pour les contenus hors de ces définitions. Gardez des frontières concrètes : un message signalant l’impossibilité de s’authentifier diffère d’un message demandant comment configurer une fonctionnalité. L’étiquette renvoyée sélectionne parmi les significations fournies ; elle ne crée pas une destination manquante et n’exécute aucune modification dans un autre système.
Une question noul renvoie une probabilité comprise entre 0 et 1 que la condition oui/non définie soit remplie. Liquid présente des vérifications binaires pour la revue de contenu et la pertinence de passages. Énoncez précisément la condition et choisissez la manière dont la probabilité obtenue sera utilisée : signaler une correspondance probable, filtrer un passage ou transmettre un cas incertain en revue. Le seuil relève de la tâche consommatrice, et une probabilité ne doit pas être traitée comme un verdict factuel garanti.
Pour le filtrage par pertinence, fournissez à la fois la requête et le passage candidat. Demandez si ce passage aide à répondre à la requête, puis conservez le passage d’origine avec sa probabilité. Cela permet de sélectionner des contenus sources pour une réponse ultérieure sans demander à d1 de rédiger lui-même cette réponse. Si la pertinence exige plusieurs degrés plutôt qu’une condition oui/non, définissez une grille ordonnée et utilisez une question score.
Une question score situe l’état sur une grille d’évaluation aux niveaux ordonnés et décrits. Les indices de niveau commencent à 0, et le score correspond à leur position pondérée par les probabilités, qui peut se situer entre deux niveaux. Le résultat comprend également la distribution des niveaux et la confiance. Pour l’urgence, définissez ce qui distingue un problème sans impact immédiat, un désagrément notable et une tâche bloquée. Une grille à quatre niveaux a donc les indices 0 à 3 ; son score attendu ne correspond pas automatiquement à une catégorie numérotée de 1 à 4.
Utilisez le score fractionnaire pour ordonner ou agréger lorsque c’est le résultat visé, et conservez la distribution complète lorsque l’ambiguïté compte. Les catégories telles que les services n’ont pas d’ordre naturel et relèvent d’une question choice. La confiance résume le caractère tranché de la réponse renvoyée dans l’interface documentée ; elle doit rester distincte du score recherché par la tâche et de toute garantie supposée de l’exactitude de la décision.
Plusieurs questions peuvent évaluer le même état en un seul appel à l’interface de l’éditeur, chacune conservant son type et ses probabilités. Les exemples textuels de Liquid comprennent le filtrage de tickets d’assistance, le classement de documents dans une arborescence de dossiers, la sélection de chemins de recherche de code, le choix parmi les actions disponibles d’un agent et la décision du contenu de sortie d’outil à conserver. Tous ces flux de travail comportent une décision suivante fermée. Une étape de recherche de code peut sélectionner un dossier prometteur à partir de ses descriptions ; une étape de sélection de contenu peut choisir keep, trim ou drop pour le contenu fourni. L’application environnante obtient toujours les données sources et effectue l’opération sélectionnée.
Les primitives documentées conviennent aux issues connues, aux notations sur grille et aux vérifications de conditions. Un nouveau texte rédigé, des résumés, du code et une conversation ouverte nécessitent un processus de génération ; ils ne découlent pas du résultat de décision de d1. Préparez une question autour d’éléments observables et conservez les définitions de cette question avec la sortie, afin qu’une étiquette ou un score puisse être interprété ultérieurement.
Maintenez chaque état centré sur les éléments qui répondent à ses questions définies, et séparez les tâches de décision sans rapport afin que leurs critères restent clairs. Gardez des contenus sources pertinents, définissez des significations de repli lorsque la couverture des catégories est incomplète et évaluez les seuils de probabilité à l’aide d’exemples étiquetés de la tâche. Un artefact utile enregistre la catégorie sélectionnée ou le score attendu, accompagné de sa distribution, de l’identité de la question et des éléments probants d’origine.
POST /v1/systemonetextdecisions| Champ | Type | Exigence | Valeurs et limites | Par défaut |
|---|---|---|---|---|
Champmodel | Typestring | ExigenceObligatoire | Valeurs et limites liquid/d1 | 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.00008 / 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.00008 / 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": "liquid/d1",\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']='liquid/d1'\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 liquid/d1
Utilisez les chemins de méthode indiqués ci-dessus.