Inception: Mercury Decide

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.

État partagé et noms de questions explicites

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.

Noul : une estimation de la réponse positive

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.

Choice : sélectionner une option nommée

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.

Score : une position attendue sur une grille d’évaluation

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.

Préparer un résultat de décision utile

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.

Périmètre et limites de l’interface

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.