Microsoft-Decision-1 est conçu pour prendre des décisions sur un contenu fourni : sélectionner une étiquette, vérifier une condition ou attribuer une note. Microsoft a post-entraîné Qwen3.5-9B pour cette tâche de notation ciblée. Le résultat est un jugement numérique qu’une application peut utiliser directement, plutôt qu’une conversation, un document ou une explication rédigée.
Le fabricant décrit trois types de questions. Une question binaire renvoie une probabilité comprise entre 0 et 1 pour une condition définie. Une question de choix sélectionne une option et renvoie une probabilité pour chaque candidat. Une question de notation situe un élément sur une échelle ordonnée et renvoie une valeur pondérée par les probabilités, qui peut se situer entre les niveaux de l’échelle.
Utilisez une question binaire lorsqu’un flux de travail doit vérifier une condition, par exemple si une réponse contient une action promise. Utilisez une question de choix pour affecter une demande à une catégorie connue. Utilisez un score pour ordonner une file de revue ou évaluer une réponse au regard d’une grille d’évaluation définie. Ces tâches diffèrent par le résultat dont votre application a besoin : sélectionnez donc le type de question avant de préparer l’entrée.
Le modèle lit un état fourni, exprimé en texte ou en JSON, accompagné de questions fermées et d’instructions. Incluez le contenu qui détermine la décision et définissez clairement les critères. Pour un classifieur de tickets, fournissez le message et des descriptions explicites des destinations autorisées. Pour un contrôle qualité, fournissez la réponse candidate, la tâche d’origine et la grille d’évaluation plutôt que de demander une note de qualité générale non expliquée.
Plusieurs questions peuvent partager les mêmes éléments probants. Un même ticket peut nécessiter une destination, un niveau d’urgence et une vérification de contact répété. Rattacher ces décisions au même contenu fourni facilite l’interprétation du résultat. La formulation de la question et la distinction entre les options restent néanmoins importantes : des étiquettes qui se recoupent ou des éléments manquants peuvent produire un score apparemment précis pour une tâche mal définie.
Microsoft considère les probabilités comme des signaux de confiance utiles pour décider d’agir, de différer ou de demander une revue. Fixez les seuils à l’aide de cas étiquetés représentatifs de votre propre charge de travail. Le seuil d’acceptation d’une affectation de catégorie sans conséquence peut différer du seuil appliqué à une action dont un faux positif coûte cher. Une option explicite d’incertitude permet à un classifieur d’éviter d’imposer un choix non étayé.
Pour un score ordonné, utilisez le résultat pour comparer des éléments ou appliquer un seuil mesuré ; il ne s’agit pas d’une note absolue de qualité validée de manière indépendante. Vérifiez si la paraphrase d’une question ou la modification de l’ordre des options change la décision. La signification d’un score renvoyé devient ainsi concrète pour l’application qui l’exploite.
Un agent peut s’appuyer sur une décision fermée pour choisir sa prochaine action, un flux documentaire peut classer les contenus entrants, et une étape d’évaluation peut accepter, réviser ou faire remonter un résultat généré. Microsoft cite également l’analyse d’intention, le routage d’incidents, la pertinence de recherche et l’étiquetage de données comme applications. Un modèle génératif reste le composant approprié lorsque l’artefact requis est un résumé, une explication, un texte réécrit ou du code ; le modèle de décision peut sélectionner l’étape de traitement suivante.
Pour un projet reposant sur l’Ailoot API, commencez par une décision précise et définissez les éléments probants, les réponses autorisées et l’action associée à chaque issue. Tenez compte de la sensibilité documentée du modèle à la formulation et de l’absence de justification rédigée. Évaluez les décisions au regard des étiquettes réelles de la tâche et examinez les cas incertains avant de considérer la confiance comme une autorisation automatique d’agir.
", "aboutText": "Microsoft-Decision-1 est conçu pour prendre des décisions sur un contenu fourni : sélectionner une étiquette, vérifier une condition ou attribuer une note. Microsoft a post-entraîné Qwen3.5-9B pour cette tâche de notation ciblée. Le résultat est un jugement numérique qu’une application peut utiliser directement, plutôt qu’une conversation, un document ou une explication rédigée.\n\n### Choix fixes et types de questions clairs\n\nLe fabricant décrit trois types de questions. Une question binaire renvoie une probabilité comprise entre 0 et 1 pour une condition définie. Une question de choix sélectionne une option et renvoie une probabilité pour chaque candidat. Une question de notation situe un élément sur une échelle ordonnée et renvoie une valeur pondérée par les probabilités, qui peut se situer entre les niveaux de l’échelle.\n\nUtilisez une question binaire lorsqu’un flux de travail doit vérifier une condition, par exemple si une réponse contient une action promise. Utilisez une question de choix pour affecter une demande à une catégorie connue. Utilisez un score pour ordonner une file de revue ou évaluer une réponse au regard d’une grille d’évaluation définie. Ces tâches diffèrent par le résultat dont votre application a besoin : sélectionnez donc le type de question avant de préparer l’entrée.\n\n### Préparer les éléments probants et les options\n\nLe modèle lit un état fourni, exprimé en texte ou en JSON, accompagné de questions fermées et d’instructions. Incluez le contenu qui détermine la décision et définissez clairement les critères. Pour un classifieur de tickets, fournissez le message et des descriptions explicites des destinations autorisées. Pour un contrôle qualité, fournissez la réponse candidate, la tâche d’origine et la grille d’évaluation plutôt que de demander une note de qualité générale non expliquée.\n\nPlusieurs questions peuvent partager les mêmes éléments probants. Un même ticket peut nécessiter une destination, un niveau d’urgence et une vérification de contact répété. Rattacher ces décisions au même contenu fourni facilite l’interprétation du résultat. La formulation de la question et la distinction entre les options restent néanmoins importantes : des étiquettes qui se recoupent ou des éléments manquants peuvent produire un score apparemment précis pour une tâche mal définie.\n\n### Confiance et pilotage du flux de travail\n\nMicrosoft considère les probabilités comme des signaux de confiance utiles pour décider d’agir, de différer ou de demander une revue. Fixez les seuils à l’aide de cas étiquetés représentatifs de votre propre charge de travail. Le seuil d’acceptation d’une affectation de catégorie sans conséquence peut différer du seuil appliqué à une action dont un faux positif coûte cher. Une option explicite d’incertitude permet à un classifieur d’éviter d’imposer un choix non étayé.\n\nPour un score ordonné, utilisez le résultat pour comparer des éléments ou appliquer un seuil mesuré ; il ne s’agit pas d’une note absolue de qualité validée de manière indépendante. Vérifiez si la paraphrase d’une question ou la modification de l’ordre des options change la décision. La signification d’un score renvoyé devient ainsi concrète pour l’application qui l’exploite.\n\n### Usages concrets d’un modèle de décision\n\nUn agent peut s’appuyer sur une décision fermée pour choisir sa prochaine action, un flux documentaire peut classer les contenus entrants, et une étape d’évaluation peut accepter, réviser ou faire remonter un résultat généré. Microsoft cite également l’analyse d’intention, le routage d’incidents, la pertinence de recherche et l’étiquetage de données comme applications. Un modèle génératif reste le composant approprié lorsque l’artefact requis est un résumé, une explication, un texte réécrit ou du code ; le modèle de décision peut sélectionner l’étape de traitement suivante.\n\nPour un projet reposant sur l’Ailoot API, commencez par une décision précise et définissez les éléments probants, les réponses autorisées et l’action associée à chaque issue. Tenez compte de la sensibilité documentée du modèle à la formulation et de l’absence de justification rédigée. Évaluez les décisions au regard des étiquettes réelles de la tâche et examinez les cas incertains avant de considérer la confiance comme une autorisation automatique d’agir.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "1fb4705f910683114cd4bfb4822010df4cdecdd9ac1e5b8301d53517b200eb19", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "fr", "methods": [ { "html": "microsoft/microsoft-decision-1Microsoft-Decision-1 est le modèle de notation décisionnelle de Microsoft pour la classification, le routage, la priorisation et l’évaluation. Il lit un texte ou un JSON fourni et renvoie des probabilités, une option sélectionnée ou un score ordonné, offrant à la logique applicative un résultat structuré 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.
Microsoft-Decision-1 est conçu pour prendre des décisions sur un contenu fourni : sélectionner une étiquette, vérifier une condition ou attribuer une note. Microsoft a post-entraîné Qwen3.5-9B pour cette tâche de notation ciblée. Le résultat est un jugement numérique qu’une application peut utiliser directement, plutôt qu’une conversation, un document ou une explication rédigée.
Le fabricant décrit trois types de questions. Une question binaire renvoie une probabilité comprise entre 0 et 1 pour une condition définie. Une question de choix sélectionne une option et renvoie une probabilité pour chaque candidat. Une question de notation situe un élément sur une échelle ordonnée et renvoie une valeur pondérée par les probabilités, qui peut se situer entre les niveaux de l’échelle.
Utilisez une question binaire lorsqu’un flux de travail doit vérifier une condition, par exemple si une réponse contient une action promise. Utilisez une question de choix pour affecter une demande à une catégorie connue. Utilisez un score pour ordonner une file de revue ou évaluer une réponse au regard d’une grille d’évaluation définie. Ces tâches diffèrent par le résultat dont votre application a besoin : sélectionnez donc le type de question avant de préparer l’entrée.
Le modèle lit un état fourni, exprimé en texte ou en JSON, accompagné de questions fermées et d’instructions. Incluez le contenu qui détermine la décision et définissez clairement les critères. Pour un classifieur de tickets, fournissez le message et des descriptions explicites des destinations autorisées. Pour un contrôle qualité, fournissez la réponse candidate, la tâche d’origine et la grille d’évaluation plutôt que de demander une note de qualité générale non expliquée.
Plusieurs questions peuvent partager les mêmes éléments probants. Un même ticket peut nécessiter une destination, un niveau d’urgence et une vérification de contact répété. Rattacher ces décisions au même contenu fourni facilite l’interprétation du résultat. La formulation de la question et la distinction entre les options restent néanmoins importantes : des étiquettes qui se recoupent ou des éléments manquants peuvent produire un score apparemment précis pour une tâche mal définie.
Microsoft considère les probabilités comme des signaux de confiance utiles pour décider d’agir, de différer ou de demander une revue. Fixez les seuils à l’aide de cas étiquetés représentatifs de votre propre charge de travail. Le seuil d’acceptation d’une affectation de catégorie sans conséquence peut différer du seuil appliqué à une action dont un faux positif coûte cher. Une option explicite d’incertitude permet à un classifieur d’éviter d’imposer un choix non étayé.
Pour un score ordonné, utilisez le résultat pour comparer des éléments ou appliquer un seuil mesuré ; il ne s’agit pas d’une note absolue de qualité validée de manière indépendante. Vérifiez si la paraphrase d’une question ou la modification de l’ordre des options change la décision. La signification d’un score renvoyé devient ainsi concrète pour l’application qui l’exploite.
Un agent peut s’appuyer sur une décision fermée pour choisir sa prochaine action, un flux documentaire peut classer les contenus entrants, et une étape d’évaluation peut accepter, réviser ou faire remonter un résultat généré. Microsoft cite également l’analyse d’intention, le routage d’incidents, la pertinence de recherche et l’étiquetage de données comme applications. Un modèle génératif reste le composant approprié lorsque l’artefact requis est un résumé, une explication, un texte réécrit ou du code ; le modèle de décision peut sélectionner l’étape de traitement suivante.
Pour un projet reposant sur l’Ailoot API, commencez par une décision précise et définissez les éléments probants, les réponses autorisées et l’action associée à chaque issue. Tenez compte de la sensibilité documentée du modèle à la formulation et de l’absence de justification rédigée. Évaluez les décisions au regard des étiquettes réelles de la tâche et examinez les cas incertains avant de considérer la confiance comme une autorisation automatique d’agir.
POST /v1/systemonetextdecisions| Champ | Type | Exigence | Valeurs et limites | Par défaut |
|---|---|---|---|---|
Champmodel | Typestring | ExigenceObligatoire | Valeurs et limites microsoft/microsoft-decision-1 | Par défaut— |
Champprovider | Typeschema | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champquestions | Typeobject | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champsession_id | Typestring | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champstate | Typeschema | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champtrace | Typeschema | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champuser | Typestring | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champquestions.<id>.type | Typestring | ExigenceObligatoire | Valeurs et limites noul, choice, score | Par défaut— |
Champquestions.<id>.instructions | Typestring|object|array | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champquestions.<id>.criteria | Typeobject|array | ExigenceFacultatif | Valeurs et limites Conditions: choice/score : obligatoires ; noul : facultatif. Les critères de choice forment un objet ; score est un tableau avec minItems égal à 1. | Par défaut— |
Champquestions.<id>.criteria.true | Typestring|object|array | ExigenceObligatoire | Valeurs et limites S’applique lorsque: objet de critères noul fourni | Par défaut— |
Champquestions.<id>.criteria.false | Typestring|object|array | ExigenceObligatoire | Valeurs et limites S’applique lorsque: objet de critères noul fourni | Par défaut— |
noul · Obligatoire : state, questions.<id>.type=noul, questions.<id>.instructions
choice · Obligatoire : state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Obligatoire : state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Paramètre | Contrat |
|---|---|
Paramètrecontent_type | Contratapplication/json |
Paramètrerequired | Contratmodel, state, questions |
Paramètrematerial_types | Contrattext |
Paramètreoptional_controls | Contratprovider, session_id, trace, user |
Paramètremultimodal_input_binding | Contratnull |
Cycle de vie : synchronous
Envoyez l’identifiant exact du modèle et conservez la réponse native complète.
Les tarifs n’ajoutent pas d’options de requête. Les paramètres pris en charge figurent dans la méthode sélectionnée.
Associez chaque coût aux conditions indiquées. Utilisez un seul tarif pour chaque ensemble de configurations alternatives.
| Configuration | Barème tarifaire | Tokens de contexte, plus de | Tokens de contexte, jusqu’à la limite incluse | Coût |
|---|---|---|---|---|
| ConfigurationTarifs de base des tokens | Barème tarifaireTarif de base | Tokens de contexte, plus de— | Tokens de contexte, jusqu’à la limite incluseSans borne supérieure | Coût Entrée · Tokens en entrée $0.000084 / 1K tokens Sortie · Tokens en sortie $0 / 1K tokens Entrée · Lecture du cache — / 1K tokens Entrée · Écriture dans le cache — / 1K tokens Entrée · Écriture dans le cache, 1 h — / 1K tokens |
| ConfigurationPalier 1 de longueur de requête | Barème tarifaire— | Tokens de contexte, plus de0 | Tokens de contexte, jusqu’à la limite incluseSans borne supérieure | Coût Entrée · Tokens en entrée $0.000084 / 1K tokens Sortie · Tokens en sortie $0 / 1K tokens Entrée · Lecture du cache — / 1K tokens Entrée · Écriture dans le cache — / 1K tokens Entrée · Écriture dans le cache, 1 h — / 1K tokens |
Ailoot réserve un montant estimé avant une requête. Après le résultat, le montant final est débité selon l’utilisation mesurée. Pour le streaming, le montant final à débiter est calculé à partir du relevé final d’utilisation. Fonctionnement de la réservation et du débit →
{\n "model": "microsoft/microsoft-decision-1",\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']='microsoft/microsoft-decision-1'\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 microsoft/microsoft-decision-1
Utilisez les chemins de méthode indiqués ci-dessus.