Aller au contenu

Tester un modèle dans le playground

Rien à installer et rien à créer : le playground est une page web. Vous choisissez un modèle déjà déployé, vous écrivez l’invite, vous lisez la réponse. C’est le moyen le plus court de savoir si un modèle sait faire ce que vous espérez.

  1. Ouvrez le projet Foundry des labs. Si le portail vous demande de vous authentifier, c’est votre compte Qim info.

  2. Vérifiez le projet actif en haut de la page : proj-azurefoundry-lab-szn, le projet partagé. Le sélecteur permet de basculer vers l’un de vos projets si vous en avez déjà un.

  3. Ouvrez le playground. C’est la zone de test du portail, accessible depuis l’accueil du projet comme depuis le volet de gauche.

  4. Choisissez un déploiement dans la liste des modèles. Ce que vous sélectionnez est un déploiement existant, pas un modèle du catalogue : si la liste est vide, aucun modèle n’est déployé dans ce projet, et c’est l’objet de créer mon projet.

  5. Écrivez une invite système avant tout autre réglage : c’est elle qui fixe le rôle, le ton et les limites. Puis posez votre question. La même question sans invite système et avec deux invites systèmes différentes vous en apprend plus que n’importe quel réglage de température.

  6. Récupérez le code de l’appel. Le playground affiche l’équivalent de votre session en Python, C#, TypeScript ou cURL, endpoint et nom de déploiement déjà renseignés. C’est la référence à copier plutôt qu’un exemple pris ailleurs.

Les libellés du portail bougent d’une version à l’autre, et un même écran change de nom entre le français et l’anglais. Le chemin, lui, ne change pas : un projet, un déploiement de modèle, un playground pour l’essayer. Cherchez ces trois objets, pas les mots exacts d’une capture d’écran.

Un petit modèle rapide et un grand modèle coûteux ne se départagent pas sur une impression : posez-leur la même question, avec la même invite système, et regardez les deux réponses côte à côte. Le playground affiche le nombre de jetons consommés à chaque échange, ce qui rend la comparaison chiffrable.

Trois réglages suffisent à couvrir la plupart des tests.

Le réglage Ce qu’il change
L’invite système Le rôle et les contraintes du modèle. C’est le levier le plus puissant, et de loin.
La température La variabilité des réponses. Basse pour de l’extraction ou de la classification, haute pour de la rédaction.
Le nombre maximal de jetons La longueur de la réponse, donc son coût et son délai. Une limite basse tronque la réponse au milieu d’une phrase, ce qui ressemble à un bug sans en être un.
Le symptôme Ce qui se passe
La liste des modèles est vide Aucun déploiement dans le projet affiché. Vérifiez le projet actif, ou déployez le modèle voulu : créer mon projet.
Le portail affiche un autre tenant, ou aucun projet Votre navigateur est connecté avec un autre compte Microsoft. Déconnectez-vous du portail, ou ouvrez-le dans une fenêtre privée avec votre compte Qim info.
« Vous n’avez pas l’autorisation » L’authentification a réussi, c’est l’autorisation qui refuse. Écrivez à lab@qiminfo.ch en indiquant le projet que vous essayez d’ouvrir.
429 ou « trop de requêtes » Le quota de jetons par minute est partagé entre tous les utilisateurs de la ressource. Attendez, réduisez le nombre maximal de jetons, ou espacez vos appels.
La réponse est bloquée ou vidée Les garde-fous de contenu ont filtré l’invite ou la réponse. Reformulez : sur un test légitime, c’est presque toujours une formulation ambiguë.
Le modèle voulu est absent du catalogue Tous les modèles n’existent pas dans toutes les régions, et la Suisse est l’une des plus étroites. Le catalogue indique la disponibilité par région.
La réponse s’arrête au milieu d’une phrase Le nombre maximal de jetons est atteint. Augmentez-le, ou demandez une réponse plus courte.

Le playground suffit pour éprouver une invite. Dès qu’il s’agit d’appeler le modèle depuis du code, de choisir son type de déploiement ou de travailler sans gêner les collègues : créer mon projet et appeler l’API.