Drex 1.5 est le modèle de décision textuelle de Nace.AI. Il évalue des faits fournis au regard de questions fermées et renvoie des réponses numériques typées, plutôt qu’une réponse écrite ouverte. Une requête associe un état à des questions nommées, et le résultat identifie chaque réponse par le même nom de question. Le processus dispose ainsi d’une catégorie, d’une probabilité ou d’une position concrète sur une grille à exploiter, tandis que l’action prise sur ce résultat reste du ressort de l’application.
L’état contient les informations concernées par chaque question. Drex accepte une chaîne JSON, un objet, un tableau, un nombre, un booléen ou null, le champ state étant obligatoire. Fournissez des éléments porteurs de sens, même si null passe la validation du producteur. 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 matériau est long. Gardez un format d’entrée stable lors de l’interprétation des seuils de probabilité, car un changement de représentation peut modifier la réponse.
Drex 1.5 lit uniquement du texte. L’interface documentée rejette les images, l’audio, la vidéo et le contenu 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, du texte documentaire reconnu ou une transcription avant d’utiliser ce matériau comme élément à évaluer. Une adresse textuelle 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, plutôt qu’une référence à du matériau que le modèle n’a pas reçu.
Une question noul demande si une condition est satisfaite et renvoie un nombre de 0 à 1 représentant la probabilité estimée de oui. Définissez la question par des instructions non vides ou par au moins un critère true/false non vide. Par exemple, demandez si un message signale une fonctionnalité défaillante et précisez si un fonctionnement lent compte comme une défaillance. Drex n’impose aucun seuil oui/non intégré ; le processus qui utilise le résultat choisit comment interpréter la probabilité.
Une question choice sélectionne un libellé fourni dans un ensemble non ordonné et renvoie une probabilité pour chaque libellé. Les critères sont un objet dont les clés sont les libellés renvoyés et dont chaque description est 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 illustrative d’orientation peut distinguer un problème d’accès, un défaut produit et une question générale, avec une catégorie « autre » pour les messages qui ne correspondent pas. Le libellé sélectionné est utile pour l’orientation ; la distribution aide à identifier les cas dans lesquels deux options restent difficiles à séparer.
Une question score utilise un tableau ordonné de libellés de niveaux. Les indices commencent à 0, et le score renvoyé est la somme des indices de chaque niveau multipliés par leur probabilité. Il peut donc se situer entre des niveaux nommés. Pour une échelle de gravité, définissez ce qui distingue un problème esthétique, un problème avec un contournement et une tâche entièrement bloquée. Le résultat comprend la légende des niveaux et leurs probabilités, ainsi que le score attendu. Gardez 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.
Le producteur autorise d’une à 512 questions sur le même état. Donnez à chacune un identifiant non vide et porteur de sens, tel que category ou severity, afin que la réponse correspondante soit compréhensible sans rechercher une question numérotée. Séparez les préoccupations indépendantes dans leurs propres questions, plutôt que de réunir plusieurs exigences en un critère flou. Un même message peut servir à un choix de catégorie, à un score de gravité et à une vérification de condition, chacun conservant son propre sens.
Les réponses choice et score comprennent la confiance séparément de leurs distributions de probabilités. Le producteur distingue explicitement la confiance de la probabilité maximale d’une option ; ne calculez pas l’une à partir de l’autre. Pour une décision oui/non, conservez la probabilité brute avec l’issue choisie. Pour un choix incertain, examinez les probabilités concurrentes, plutôt que de traiter le seul libellé gagnant comme une preuve de certitude. Définissez les seuils de vérification selon les conséquences d’un faux résultat positif ou négatif et utilisez des cas annotés représentatifs pour les évaluer.
Drex 1.5 documente un budget d’état de 131 072 tokens et un budget de ligne de 139 264 tokens. Le budget de ligne concerne l’état et la plus longue question individuelle, y compris ses instructions et ses options ; il ne correspond pas à la somme de toutes les questions de la requête. L’état sérialisé et les questions réunis doivent aussi tenir 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 version 1.5.
Nace documente drex-v1.5 comme un identifiant versionné du producteur, tandis que drex-latest est un alias évolutif. Explicitez l’édition visée lorsqu’un processus dépend de ses limites. Une question mal formée, un état manquant ou une entrée trop volumineuse constituent des problèmes de validation nécessitant une entrée corrigée, plutôt qu’une catégorie modifiée ou une réponse devinée. Préparez les critères autour d’éléments observables et gardez ensemble le résultat typé, les faits d’origine et la définition de la question. La décision devient ainsi utilisable pour l’orientation, la priorisation ou la vérification, sans confondre une probabilité avec un verdict garanti.
", "aboutText": "Drex 1.5 est le modèle de décision textuelle de Nace.AI. Il évalue des faits fournis au regard de questions fermées et renvoie des réponses numériques typées, plutôt qu’une réponse écrite ouverte. Une requête associe un état à des questions nommées, et le résultat identifie chaque réponse par le même nom de question. Le processus dispose ainsi d’une catégorie, d’une probabilité ou d’une position concrète sur une grille à exploiter, tandis que l’action prise sur ce résultat reste du ressort de l’application.\n\n### Préparer l’état\n\nL’état contient les informations concernées par chaque question. Drex accepte une chaîne JSON, un objet, un tableau, un nombre, un booléen ou null, le champ state étant obligatoire. Fournissez des éléments porteurs de sens, même si null passe la validation du producteur. 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 matériau est long. Gardez un format d’entrée stable lors de l’interprétation des seuils de probabilité, car un changement de représentation peut modifier la réponse.\n\nDrex 1.5 lit uniquement du texte. L’interface documentée rejette les images, l’audio, la vidéo et le contenu 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, du texte documentaire reconnu ou une transcription avant d’utiliser ce matériau comme élément à évaluer. Une adresse textuelle 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, plutôt qu’une référence à du matériau que le modèle n’a pas reçu.\n\n### Probabilité oui/non, choix ou score\n\nUne question noul demande si une condition est satisfaite et renvoie un nombre de 0 à 1 représentant la probabilité estimée de oui. Définissez la question par des instructions non vides ou par au moins un critère true/false non vide. Par exemple, demandez si un message signale une fonctionnalité défaillante et précisez si un fonctionnement lent compte comme une défaillance. Drex n’impose aucun seuil oui/non intégré ; le processus qui utilise le résultat choisit comment interpréter la probabilité.\n\nUne question choice sélectionne un libellé fourni dans un ensemble non ordonné et renvoie une probabilité pour chaque libellé. Les critères sont un objet dont les clés sont les libellés renvoyés et dont chaque description est 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 illustrative d’orientation peut distinguer un problème d’accès, un défaut produit et une question générale, avec une catégorie « autre » pour les messages qui ne correspondent pas. Le libellé sélectionné est utile pour l’orientation ; la distribution aide à identifier les cas dans lesquels deux options restent difficiles à séparer.\n\nUne question score utilise un tableau ordonné de libellés de niveaux. Les indices commencent à 0, et le score renvoyé est la somme des indices de chaque niveau multipliés par leur probabilité. Il peut donc se situer entre des niveaux nommés. Pour une échelle de gravité, définissez ce qui distingue un problème esthétique, un problème avec un contournement et une tâche entièrement bloquée. Le résultat comprend la légende des niveaux et leurs probabilités, ainsi que le score attendu. Gardez 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.\n\n### Éléments partagés et lecture du résultat\n\nLe producteur autorise d’une à 512 questions sur le même état. Donnez à chacune un identifiant non vide et porteur de sens, tel que category ou severity, afin que la réponse correspondante soit compréhensible sans rechercher une question numérotée. Séparez les préoccupations indépendantes dans leurs propres questions, plutôt que de réunir plusieurs exigences en un critère flou. Un même message peut servir à un choix de catégorie, à un score de gravité et à une vérification de condition, chacun conservant son propre sens.\n\nLes réponses choice et score comprennent la confiance séparément de leurs distributions de probabilités. Le producteur distingue explicitement la confiance de la probabilité maximale d’une option ; ne calculez pas l’une à partir de l’autre. Pour une décision oui/non, conservez la probabilité brute avec l’issue choisie. Pour un choix incertain, examinez les probabilités concurrentes, plutôt que de traiter le seul libellé gagnant comme une preuve de certitude. Définissez les seuils de vérification selon les conséquences d’un faux résultat positif ou négatif et utilisez des cas annotés représentatifs pour les évaluer.\n\n### Version et limites de taille\n\nDrex 1.5 documente un budget d’état de 131 072 tokens et un budget de ligne de 139 264 tokens. Le budget de ligne concerne l’état et la plus longue question individuelle, y compris ses instructions et ses options ; il ne correspond pas à la somme de toutes les questions de la requête. L’état sérialisé et les questions réunis doivent aussi tenir 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 version 1.5.\n\nNace documente drex-v1.5 comme un identifiant versionné du producteur, tandis que drex-latest est un alias évolutif. Explicitez l’édition visée lorsqu’un processus dépend de ses limites. Une question mal formée, un état manquant ou une entrée trop volumineuse constituent des problèmes de validation nécessitant une entrée corrigée, plutôt qu’une catégorie modifiée ou une réponse devinée. Préparez les critères autour d’éléments observables et gardez ensemble le résultat typé, les faits d’origine et la définition de la question. La décision devient ainsi utilisable pour l’orientation, la priorisation ou la vérification, sans confondre une probabilité avec un verdict garanti.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "528befdd0765f22ca974c32d2616010c4f0e424485f9ec79cb36dc46ada9eb89", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "fr-be", "methods": [ { "html": "nace-ai/drex-v1.5Drex 1.5 évalue du texte ou du JSON fourni à l’aide de questions typées et renvoie des probabilités, un libellé choisi ou un score fractionnaire sur une grille d’évaluation. Nace.AI documente des décisions exclusivement textuelles pour la classification, l’orientation et la priorisation, avec des limites d’état et de requête propres à chaque version.
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.
Drex 1.5 est le modèle de décision textuelle de Nace.AI. Il évalue des faits fournis au regard de questions fermées et renvoie des réponses numériques typées, plutôt qu’une réponse écrite ouverte. Une requête associe un état à des questions nommées, et le résultat identifie chaque réponse par le même nom de question. Le processus dispose ainsi d’une catégorie, d’une probabilité ou d’une position concrète sur une grille à exploiter, tandis que l’action prise sur ce résultat reste du ressort de l’application.
L’état contient les informations concernées par chaque question. Drex accepte une chaîne JSON, un objet, un tableau, un nombre, un booléen ou null, le champ state étant obligatoire. Fournissez des éléments porteurs de sens, même si null passe la validation du producteur. 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 matériau est long. Gardez un format d’entrée stable lors de l’interprétation des seuils de probabilité, car un changement de représentation peut modifier la réponse.
Drex 1.5 lit uniquement du texte. L’interface documentée rejette les images, l’audio, la vidéo et le contenu 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, du texte documentaire reconnu ou une transcription avant d’utiliser ce matériau comme élément à évaluer. Une adresse textuelle 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, plutôt qu’une référence à du matériau que le modèle n’a pas reçu.
Une question noul demande si une condition est satisfaite et renvoie un nombre de 0 à 1 représentant la probabilité estimée de oui. Définissez la question par des instructions non vides ou par au moins un critère true/false non vide. Par exemple, demandez si un message signale une fonctionnalité défaillante et précisez si un fonctionnement lent compte comme une défaillance. Drex n’impose aucun seuil oui/non intégré ; le processus qui utilise le résultat choisit comment interpréter la probabilité.
Une question choice sélectionne un libellé fourni dans un ensemble non ordonné et renvoie une probabilité pour chaque libellé. Les critères sont un objet dont les clés sont les libellés renvoyés et dont chaque description est 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 illustrative d’orientation peut distinguer un problème d’accès, un défaut produit et une question générale, avec une catégorie « autre » pour les messages qui ne correspondent pas. Le libellé sélectionné est utile pour l’orientation ; la distribution aide à identifier les cas dans lesquels deux options restent difficiles à séparer.
Une question score utilise un tableau ordonné de libellés de niveaux. Les indices commencent à 0, et le score renvoyé est la somme des indices de chaque niveau multipliés par leur probabilité. Il peut donc se situer entre des niveaux nommés. Pour une échelle de gravité, définissez ce qui distingue un problème esthétique, un problème avec un contournement et une tâche entièrement bloquée. Le résultat comprend la légende des niveaux et leurs probabilités, ainsi que le score attendu. Gardez 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.
Le producteur autorise d’une à 512 questions sur le même état. Donnez à chacune un identifiant non vide et porteur de sens, tel que category ou severity, afin que la réponse correspondante soit compréhensible sans rechercher une question numérotée. Séparez les préoccupations indépendantes dans leurs propres questions, plutôt que de réunir plusieurs exigences en un critère flou. Un même message peut servir à un choix de catégorie, à un score de gravité et à une vérification de condition, chacun conservant son propre sens.
Les réponses choice et score comprennent la confiance séparément de leurs distributions de probabilités. Le producteur distingue explicitement la confiance de la probabilité maximale d’une option ; ne calculez pas l’une à partir de l’autre. Pour une décision oui/non, conservez la probabilité brute avec l’issue choisie. Pour un choix incertain, examinez les probabilités concurrentes, plutôt que de traiter le seul libellé gagnant comme une preuve de certitude. Définissez les seuils de vérification selon les conséquences d’un faux résultat positif ou négatif et utilisez des cas annotés représentatifs pour les évaluer.
Drex 1.5 documente un budget d’état de 131 072 tokens et un budget de ligne de 139 264 tokens. Le budget de ligne concerne l’état et la plus longue question individuelle, y compris ses instructions et ses options ; il ne correspond pas à la somme de toutes les questions de la requête. L’état sérialisé et les questions réunis doivent aussi tenir 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 version 1.5.
Nace documente drex-v1.5 comme un identifiant versionné du producteur, tandis que drex-latest est un alias évolutif. Explicitez l’édition visée lorsqu’un processus dépend de ses limites. Une question mal formée, un état manquant ou une entrée trop volumineuse constituent des problèmes de validation nécessitant une entrée corrigée, plutôt qu’une catégorie modifiée ou une réponse devinée. Préparez les critères autour d’éléments observables et gardez ensemble le résultat typé, les faits d’origine et la définition de la question. La décision devient ainsi utilisable pour l’orientation, la priorisation ou la vérification, sans confondre une probabilité avec un verdict garanti.
POST /v1/systemonetextdecisions| Champ | Type | Exigence | Valeurs et limites | Par défaut |
|---|---|---|---|---|
Champmodel | Typestring | ExigenceObligatoire | Valeurs et limites nace-ai/drex-v1.5 | 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 : obligatoire ; noul : facultatif. Les critères choice forment un objet ; score est un tableau avec minItems1. | 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’ID 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 — / 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 — / 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": "nace-ai/drex-v1.5",\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']='nace-ai/drex-v1.5'\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 ID de question est conservée avec son type exact, sa valeur noul/choice/score, son niveau de confiance, ses probabilités et sa légende. L’intégralité du JSON d’origine est stockée et renvoyée uniquement après le règlement.
Conservez l’opération d’origine ainsi que 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 invalide | Étape suivanteCorrigez le champ indiqué de la requête. |
Ailoot Ultra nace-ai/drex-v1.5
Utilisez les chemins de méthode indiqués ci-dessus.