Nace.AI: Drex v1.5

Drex 1.5 est le modèle de décision textuelle de Nace.AI. Il évalue les faits fournis au regard de questions fermées et renvoie des réponses numériques typées plutôt qu’une réponse rédigée ouverte. Une requête combine un état unique avec des questions nommées, et le résultat identifie chaque réponse par le nom de la question correspondante. Un flux de travail dispose ainsi d’une catégorie, d’une probabilité ou d’une position concrète sur une grille d’évaluation à exploiter, l’action à mener sur ce résultat restant du ressort de l’application.

Préparer l’état

L’état est l’information sur laquelle portent toutes les questions. Drex accepte une valeur JSON de type chaîne, objet, tableau, nombre, booléen ou null, le champ state étant obligatoire. Fournissez des éléments probants significatifs, même si null passe la validation de l’éditeur. Une chaîne convient à un message, un document ou une transcription ; un objet convient à des faits déjà organisés en champs. Conservez les informations qui influent sur la décision et omettez les champs sans rapport lorsque le contenu est long. Maintenez un format d’entrée stable lors de l’interprétation des seuils de probabilité, car modifier la représentation peut modifier la réponse.

Drex 1.5 lit uniquement du texte. L’interface documentée rejette les contenus image, audio, vidéo et PDF dans l’état comme dans les questions, y compris les médias encodés et les objets de contenu multimédia. Préparez une légende, le texte reconnu d’un document ou une transcription avant d’utiliser ce contenu comme élément probant. Une adresse sous forme de texte n’est pas un document ou une image récupérés : le modèle ne peut pas l’ouvrir. Pour une demande d’assistance, l’état utile est le message réel et le contexte pertinent, et non une référence à un contenu que le modèle n’a pas reçu.

Probabilité oui/non, choix ou score

Une question noul demande si une condition est remplie et renvoie un nombre compris entre 0 et 1 représentant la probabilité estimée de oui. Définissez la question au moyen d’instructions non vides ou d’au moins un critère vrai/faux non vide. Par exemple, demandez si un message signale une fonctionnalité défaillante et précisez si la lenteur compte comme une défaillance. Drex n’impose aucun seuil oui/non intégré ; le flux de travail consommateur choisit comment interpréter la probabilité.

Une question de choix sélectionne une étiquette fournie dans un ensemble non ordonné et renvoie une probabilité pour chaque étiquette. Les critères forment un objet dont les clés sont les étiquettes renvoyées, chaque description étant une chaîne ou null. Utilisez des clés courtes et stables et décrivez clairement les frontières entre catégories. Une tâche de routage illustrative peut distinguer un problème d’accès, un défaut du produit et une question générale, avec une catégorie other pour les messages qui ne correspondent à aucune d’elles. L’étiquette sélectionnée est utile pour le routage ; la distribution aide à repérer les cas où deux options restent difficiles à départager.

Une question de score utilise un tableau ordonné d’étiquettes de niveaux. Les indices commencent à 0, et le score renvoyé est la somme des indices de niveau multipliés par leur probabilité. Il peut donc se situer entre deux niveaux nommés. Pour une échelle de gravité, définissez ce qui distingue un problème cosmétique, un problème disposant d’une solution de contournement et une tâche totalement bloquée. Le résultat comprend la légende des niveaux et les probabilités ainsi que le score attendu. Conservez le score fractionnaire pour les moyennes ou les tendances ; sélectionner le niveau le plus probable et arrondir le score attendu répondent à des questions différentes.

Éléments partagés et lecture du résultat

L’éditeur autorise entre une et 512 questions sur le même état. Donnez à chacune un identifiant non vide et explicite, tel que category ou severity, afin que la réponse correspondante soit compréhensible sans avoir à retrouver une question numérotée. Séparez les préoccupations indépendantes en questions distinctes plutôt que de combiner plusieurs exigences dans un critère flou. Un seul message peut étayer un choix de catégorie, un score de gravité et une vérification de condition, chacun conservant sa propre signification.

Les réponses de choix et de score comportent une confiance distincte de leurs distributions de probabilités. L’éditeur distingue explicitement la confiance de la probabilité de l’option la plus élevée ; ne calculez pas l’une à partir de l’autre. Pour une décision oui/non, conservez la probabilité brute avec l’issue retenue. Pour un choix incertain, examinez les probabilités concurrentes au lieu de considérer la seule étiquette gagnante comme une preuve de certitude. Définissez les seuils de revue en fonction des conséquences d’un faux positif ou d’un faux négatif et évaluez-les à l’aide de cas étiquetés représentatifs.

Limites de version et de taille

Drex 1.5 documente une capacité d’état de 131 072 tokens et une capacité par ligne de 139 264 tokens. La capacité par ligne porte sur l’état plus la question individuelle la plus longue, instructions et options comprises ; il ne s’agit pas de la somme de toutes les questions de la requête. L’état et les questions sérialisés doivent également tenir ensemble dans 1 048 576 octets UTF-8. Une requête peut respecter la limite en octets tout en dépassant une limite en tokens. L’ancienne édition 1.0 indique séparément 32 768 tokens pour l’état comme pour la ligne ; ses limites ne doivent donc pas être reportées sur la 1.5.

Nace documente drex-v1.5 comme un identifiant versionné de l’éditeur, tandis que drex-latest est un alias évolutif. Indiquez explicitement l’édition visée lorsqu’un flux de travail dépend de ses limites. Une question mal formée, un état manquant ou une entrée trop volumineuse constituent un problème de validation qui appelle une entrée corrigée, et non une catégorie modifiée ou une réponse devinée. Préparez les critères autour d’éléments observables et conservez ensemble le résultat typé, les faits d’origine et la définition de la question. La décision devient ainsi exploitable pour le routage, la priorisation ou la revue, sans confondre une probabilité avec un verdict garanti.