Inception: Mercury Decide (free)

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.

État partagé et noms de questions porteurs de sens

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.

Noul : une réponse positive estimée

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.

Choice : sélectionner une option nommée

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.

Score : une position attendue sur une grille

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.

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

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é.

Périmètre et limites de l’interface

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.