Mesurer les petits modèles de langage signifie prouver qu’un modèle moins cher et plus rapide effectue une tâche spécifique assez bien, et montrer les économies en chiffres. Les petits modèles comme Microsoft Phi, Google Gemma, les variantes plus petites de Llama de Meta et Mistral Small peuvent fonctionner à moindre coût via une API ou sur votre propre matériel. Les KPI qui comptent sont la qualité de la tâche, la latence, le coût par tâche et le résultat commercial que la tâche soutient.
Pourquoi les petits modèles de langage ont-ils besoin de leur propre mesure ?
Les grands modèles sont souvent choisis pour leur réputation. Les petits modèles sont choisis sur un compromis : vous acceptez une certaine perte de capacité générale pour la vitesse, le coût et le contrôle. Ce compromis n’est sûr que lorsque vous pouvez le voir. Sans mesure, une équipe paie soit trop cher pour un grand modèle sur des tâches simples, soit déploie discrètement un petit modèle qui se trompe une fois sur dix.
Les petits modèles ont également tendance à être plus étroits. Un modèle qui étiquette bien les tickets de support peut rédiger une mauvaise publicité. La mesure doit se faire par tâche, et non par modèle.
Que devriez-vous mesurer en premier ?
Commencez par quatre groupes de métriques. Chacun répond à une question différente d’une personne différente dans l’entreprise.
- Qualité : le résultat est-il conforme à la norme ? Mesuré par rapport à un ensemble de test étiqueté.
- Latence : combien de temps prend une réponse ? Mesuré en médiane et en 95e percentile de temps.
- Coût : combien coûte une tâche terminée, y compris les tentatives et les corrections humaines ?
- Impact commercial : le KPI en aval a-t-il bougé, comme le temps de réponse, la conversion ou les heures économisées ?
La qualité et le coût sont généralement les plus importants pour les équipes marketing. La latence est importante pour tout ce sur quoi un client attend, comme le chat ou la recherche sur site.
Métriques de qualité par type de tâche
La métrique de qualité dépend du travail. Pour les tâches de classification telles que le scoring de leads, l’étiquetage d’intention ou le sentiment, utilisez la précision et le rappel par rapport aux étiquettes attribuées par un humain. Pour les tâches d’extraction, comptez la part des champs remplis correctement. Pour les tâches d’écriture, utilisez une rubrique notée par des personnes ou par un modèle plus fort agissant en tant que juge, avec un échantillon vérifié par des personnes pour confirmer que le juge est d’accord.
Coût par tâche, pas coût par jeton
Les prix des jetons semblent minuscules et trompeurs. Calculez le coût par tâche terminée : jetons par tâche multipliés par le prix, plus le coût des tentatives, plus les minutes qu’une personne passe à corriger les mauvais résultats. Un petit modèle qui nécessite des corrections fréquentes peut coûter plus cher au total qu’un modèle plus grand qui n’en a pas besoin.
Comment construire un ensemble d’évaluation ?
Un ensemble d’évaluation est une collection fixe d’entrées réelles avec des résultats connus comme bons. C’est la base de chaque chiffre sur votre tableau de bord.
- Collectez 100 à 300 exemples réels de la tâche, pas des exemples inventés.
- Demandez à une personne d’étiqueter ou d’écrire le résultat correct pour chacun.
- Incluez des cas difficiles : fautes de frappe, langues mixtes, catégories limites.
- Gelez l’ensemble et donnez-lui un numéro de version.
- Exécutez chaque modèle candidat et prompt par rapport au même ensemble.
Gardez un petit ensemble séparé de nouveaux exemples collectés chaque mois. Si les performances sur les données fraîches chutent alors que l’ensemble gelé reste stable, vos entrées réelles ont changé et le modèle ou le prompt doit être mis à jour.
À quoi ressemble un tableau de bord utile ?
Un tableau de bord pour les petits modèles de langage doit tenir sur un écran et répondre à trois questions : est-ce que ça marche, est-ce bon marché et est-ce que ça aide ? Looker Studio, Power BI ou Grafana fonctionnent tous ; ce qui compte, ce sont les données derrière.
Ligne du haut : santé
Requêtes par jour, taux d’erreur, médiane et 95e percentile de latence. Ceux-ci proviennent directement des journaux d’application. Un changement soudain ici signifie généralement un problème technique plutôt qu’un problème de modèle.
Ligne du milieu : qualité
Dernier score sur l’ensemble d’évaluation gelé, score sur l’échantillon frais mensuel et le taux de remplacement humain, qui est la part des résultats qu’une personne a modifiés avant utilisation. Le taux de remplacement est souvent le signal de qualité le plus honnête que vous ayez en production.
Ligne du bas : valeur
Coût par tâche au fil du temps, heures économisées par mois (tâches multipliées par minutes économisées par tâche, mesuré une fois en chronométrant les personnes) et le KPI métier lié à la tâche. Pour un modèle d’étiquetage de leads, cela pourrait être le temps entre le remplissage du formulaire et le premier contact commercial.
Comment comparer un petit modèle avec un grand ?
Exécutez les deux sur le même ensemble d’évaluation avec la même structure de prompt. Tracez la qualité par rapport au coût par tâche. Souvent, le résultat est clair : le petit modèle atteint la majeure partie du score du grand modèle à une fraction du coût sur des tâches étroites, et prend beaucoup de retard sur l’écriture ou le raisonnement ouvert. Décidez ensuite par tâche.
Une configuration de routage est courante : le petit modèle gère la tâche en premier, et les cas où il signale une faible confiance, ou où une règle simple signale un doute, vont au modèle plus grand. Mesurez la part du trafic routé vers le haut ; si elle augmente, le petit modèle n’est plus adapté.
Comment Alien Road applique les petits modèles de langage et les mesure
Dans un engagement typique, notre équipe AI Optimization liste les tâches IA du client et leur modèle actuel, puis choisit les tâches à haut volume et étroites comme candidates pour un petit modèle, telles que l’extraction d’attributs de produits, l’étiquetage d’avis ou la classification de leads.
Nous construisons l’ensemble d’évaluation avec les propres données du client, testons deux ou trois petits modèles par rapport à l’actuel et configurons la journalisation pour la latence, le coût et les remplacements. Le tableau de bord est livré dans l’outil BI du client afin qu’il ne dépende pas de nous.
Le reporting est mensuel : qualité sur les ensembles gelés et frais, coût par tâche, taux de remplacement et le KPI métier lié, avec une courte note sur tout changement de modèle ou de prompt effectué ce mois-là.
Quelles erreurs rendent les chiffres trompeurs ?
La plus courante est de tester sur des exemples inventés, qui sont plus propres que les données réelles et gonflent les scores. La deuxième est d’ignorer le temps de correction humaine, ce qui cache le coût réel. La troisième est de changer le prompt et le modèle en même temps, donc personne ne sait quel changement a aidé. Changez une chose par test.
Un autre piège est de laisser un modèle en juger un autre sans vérifications. Un modèle juge a ses propres biais, y compris une préférence pour les réponses plus longues. Vérifiez un échantillon de ses scores à la main chaque mois.
Par où commencer cette semaine
Choisissez une tâche à haut volume que votre équipe exécute déjà via un grand modèle. Tirez 100 entrées réelles avec leurs résultats acceptés, exécutez un petit modèle par rapport à elles avec le même prompt, et comparez la précision et le coût par tâche dans une simple feuille de calcul. Cette seule comparaison vous dit si un tableau de bord vaut la peine d’être construit ensuite.
Continuer la lecture : Optimisation par IA · Optimisation par IA