Claude 3 : choisir le palier, pas le modèle
ClaudeRoutageCoûtArchitecture2024-03-0410 min
Trois modèles d'une même famille, même interface, coûts séparés par un facteur soixante. La question devient : quelle tâche mérite quel palier.
Une famille plutôt qu'un modèle
Claude 3 est publié en trois tailles partageant la même interface, avec des tarifs séparés par un facteur d'environ soixante entre les extrêmes. Cette structure en paliers est la véritable nouveauté pour qui construit des systèmes.
Un fournisseur qui propose un seul modèle impose une décision binaire : l'utiliser ou non. Une famille de trois transforme cette décision en répartition. Chaque appel du système peut aller au palier qui lui convient, sans changer une ligne d'intégration.
C'est ce partage d'interface qui rend le routage praticable. Passer d'un palier à l'autre revient à changer un identifiant, ce qui permet de tester la bascule sur un jeu de cas sans réécrire quoi que ce soit.
Comment répartir sans dégrader la qualité perçue
Descendre de palier ne se décide jamais sur une impression, mais sur un taux d'erreur mesuré contre un seuil fixé par tâche. C'est la seule méthode qui tienne dans la durée.
La démarche est courte. Pour chaque type d'appel du système, on constitue une trentaine de cas réels avec la réponse attendue. On fait tourner les trois paliers. On compare le taux d'erreur au seuil qu'on s'est fixé pour cette tâche, trois pour cent pour une classification interne, zéro pour une extraction qui alimente une facture.
Ce qui rend l'exercice rentable est sa réutilisabilité. Le jeu de cas construit une fois sert à chaque nouvelle version de modèle, et le gain se reprend automatiquement. Sans lui, chaque évolution du catalogue produit une discussion d'opinion.
J'ajoute une règle qui évite les mauvaises surprises : ne jamais descendre de palier sur les cas limites sans les avoir explicitement inclus dans le jeu de tests. C'est là que les petits modèles échouent, et ce sont ces échecs-là que les utilisateurs remarquent.
La répartition qui fonctionne dans la plupart des cas
- Palier rapide : classification, détection de langue, filtrage de périmètre, extraction de champs simples. Volume élevé, enjeu faible par appel.
- Palier intermédiaire : rédaction, reformulation, réponse documentaire courante. C'est le palier par défaut de la plupart des systèmes.
- Palier supérieur : analyse contractuelle, synthèse de dossier, raisonnement en plusieurs étapes. Volume faible, enjeu élevé.
- Mesurer avant de figer. Le bon palier par tâche se déplace à chaque génération. Voir Mistral 7B et l'arbitrage par le routage.
L'erreur symétrique : le palier haut par précaution
Choisir systématiquement le palier supérieur pour éviter tout risque coûte beaucoup et n'améliore souvent rien. C'est le réflexe le plus fréquent, et il est compréhensible.
Sur les tâches structurées, l'écart de qualité entre paliers est faible ou nul. Un modèle rapide classe correctement une demande de congé, extrait une date d'un contrat, détecte qu'une question sort du périmètre. Le palier supérieur fait la même chose, plus lentement et soixante fois plus cher.
L'écart se manifeste ailleurs : dans les tâches qui exigent de tenir plusieurs contraintes simultanément, de suivre un raisonnement long, ou de repérer une incohérence subtile. Ces tâches existent dans tout système, mais elles représentent rarement plus de dix pour cent des appels.
La règle que j'applique : partir du palier intermédiaire pour tout, puis descendre là où le jeu de tests le permet et monter là où il l'exige. Ce réglage donne systématiquement un meilleur rapport coût-qualité que le choix unique, comme le montre l'analyse dans le coût réel d'un système IA en production.
Le chiffre à connaître avant d'arbitrer
Le coût mensuel de chaque type d'appel, mesuré séparément. Sans ce chiffre, le routage se décide au jugé et porte presque toujours sur le mauvais appel, celui qui est visible, pas celui qui pèse.
Ce que cette structure annonce
La famille de paliers devient le format standard chez tous les fournisseurs, et cela change la nature du travail d'architecture. Le choix ne porte plus sur un modèle mais sur une politique de répartition.
Cette politique est un objet durable : elle survit aux changements de génération, contrairement au choix d'un modèle particulier. Une équipe qui a écrit « les extractions vont au palier rapide, les analyses au palier supérieur, avec ces seuils » possède quelque chose de réutilisable.
Elle suppose deux prérequis, toujours les mêmes : une couche d'abstraction qui rend le palier configurable, et un jeu de tests qui rend la décision mesurable. Ces deux éléments coûtent une journée au démarrage et déterminent l'essentiel du coût d'exploitation sur trois ans.
Cette politique de répartition mérite d'être écrite noir sur blanc et relue chaque trimestre. Sans document, elle vit dans la tête d'une personne et disparaît avec elle, un cas particulier de la dette technique d'un système d'IA, et l'un des plus faciles à éviter.
Questions fréquentes
- Comment choisir entre trois paliers d'une même famille ?
Par la mesure, tâche par tâche : une trentaine de cas réels avec réponse attendue, un seuil d'erreur acceptable fixé par tâche, et la comparaison des trois paliers sur ce jeu.
- Le palier supérieur est-il toujours meilleur ?
Sur les tâches structurées, l'écart est faible ou nul, pour un coût pouvant être soixante fois supérieur. L'écart se manifeste sur le raisonnement long et les contraintes multiples, qui représentent rarement plus de dix pour cent des appels.
- Faut-il refaire la répartition à chaque nouvelle version ?
Oui, et c'est rapide si le jeu de tests existe. Le palier suffisant pour une tâche descend à chaque génération, et le gain se reprend en rejouant simplement la comparaison.
- Quel palier prendre par défaut ?
L'intermédiaire, puis descendre là où le jeu de tests le permet et monter là où il l'exige. Partir du palier supérieur par précaution coûte cher sans améliorer les tâches qui composent l'essentiel du volume.