Mistral 7B : quand un petit modèle change l'arbitrage
MistralCoûtRoutageArchitecture2023-09-2710 min
La question n'est plus « quel est le meilleur modèle » mais « quelle tâche mérite le grand modèle ». Le routage devient la principale source d'économie.
Ce que démontre un modèle de sept milliards de paramètres
Mistral 7B obtient des résultats comparables à des modèles bien plus gros sur les tâches structurées, et il tient sur une seule carte graphique grand public. C'est cette combinaison, et non le score brut, qui a un effet immédiat sur les architectures d'entreprise.
Jusqu'ici la logique dominante était simple : le plus gros modèle disponible pour tout. Elle était défendable tant que l'écart de qualité justifiait l'écart de prix. Elle cesse de l'être quand un modèle cent fois moins cher fait aussi bien sur quatre-vingts pour cent des appels.
Les tâches concernées sont celles qui composent l'essentiel du volume réel : classer une demande, extraire trois champs d'un document, reformuler un texte, détecter une langue, décider si une question relève du périmètre. Aucune ne demande un raisonnement élaboré.
Pourquoi le routage bat l'optimisation de prompt
Envoyer chaque tâche au plus petit modèle qui la traite correctement réduit la facture d'un facteur cinq à dix, là où l'optimisation de prompt en gagne dix pour cent. C'est le levier le plus rentable d'un système en production, et le moins utilisé.
La mise en œuvre est plus simple qu'attendu. On ne cherche pas à faire décider le modèle : on classe les tâches à l'avance, par type d'appel, dans le code. Une extraction de champs part toujours sur le petit modèle. Une analyse de cohérence contractuelle part toujours sur le grand.
Le cas intermédiaire, laisser un modèle décider de l'escalade, existe, mais il ajoute un appel et une source d'erreur. Je ne le recommande qu'après avoir épuisé le routage statique, qui capte déjà l'essentiel du gain. La couche d'abstraction rend ce routage trivial à mettre en place, ce qui est un argument de plus en sa faveur.
Comment décider quelle tâche va où
- Constituer un jeu de cas par type de tâche, une trentaine suffit, avec la réponse attendue. Voir l'évaluation continue.
- Faire tourner les deux modèles sur ce jeu et comparer, non pas la préférence subjective, mais le taux d'erreur mesuré.
- Fixer un seuil acceptable par tâche. Une classification interne tolère trois pour cent d'erreur ; une extraction qui alimente une facture n'en tolère aucune.
- Rejouer la comparaison à chaque nouvelle version. Un petit modèle qui échouait il y a six mois passe souvent le seuil aujourd'hui, et le gain se reprend sans effort.
Le piège du modèle unique par confort
Beaucoup d'équipes gardent un seul grand modèle pour ne pas gérer deux configurations, et paient cette simplicité très cher. L'argument est recevable au démarrage, quand le volume est faible et que le temps d'ingénierie vaut plus que la facture.
Il cesse de l'être dès que le système traite des milliers d'appels par jour. À ce stade, la différence entre un routage et un modèle unique se compte en milliers d'euros par mois, pour une demi-journée de travail.
Le symptôme à surveiller est simple : si personne dans l'équipe ne sait dire combien coûte une fonctionnalité par mois, le routage n'a pas été instruit. La mesure du coût par appel, posée dans la couche d'abstraction, est le préalable à toute optimisation. Elle est développée dans le coût réel d'un système IA en production.
L'ordre des opérations qui fonctionne
Faire marcher le système avec un grand modèle, mesurer les volumes par type de tâche pendant un mois, puis basculer sur le petit modèle les tâches qui passent le seuil. Optimiser avant de mesurer conduit systématiquement à optimiser le mauvais appel.
Ce que ça change pour l'hébergement interne
Un modèle de sept milliards de paramètres tient sur du matériel accessible, ce qui rend l'auto-hébergement envisageable pour une équipe ordinaire. C'est la seconde conséquence, moins commentée et tout aussi structurante.
Héberger un grand modèle demande plusieurs cartes coûteuses et une compétence d'exploitation rare. Héberger un modèle de cette taille demande une machine, ce qui déplace la décision du comité d'investissement vers l'équipe technique.
Cela ouvre un scénario particulier, utile dans les secteurs contraints : traiter en interne tout ce qui touche à des données sensibles, et n'envoyer à une API externe que ce qui a été préalablement anonymisé ou qui ne relève pas du périmètre protégé. Le cadre de cette décision est posé dans confidentialité : ce qu'on a le droit de mettre dans un prompt.
Questions fréquentes
- Un petit modèle suffit-il pour un système documentaire ?
Pour la récupération et l'extraction, oui, dans la plupart des cas. Pour la synthèse d'un dossier complexe ou l'analyse contractuelle, non. Le routage par type de tâche permet d'utiliser chacun là où il est bon.
- Comment mesurer si un petit modèle est assez bon ?
Sur un jeu de trente cas réels par type de tâche, avec la réponse attendue, en comparant le taux d'erreur au seuil acceptable pour cette tâche. La comparaison subjective ne suffit pas et donne des décisions instables.
- Le routage complique-t-il beaucoup le système ?
Non, s'il est statique : chaque type d'appel part vers un modèle décidé à l'avance dans le code. C'est le routage dynamique, où un modèle décide de l'escalade, qui ajoute de la complexité et une source d'erreur.
- Faut-il refaire le choix quand un nouveau modèle sort ?
Oui, et c'est peu coûteux si le jeu de tests existe. Un petit modèle qui échouait il y a six mois passe souvent le seuil aujourd'hui, et le gain se reprend en rejouant simplement la comparaison.