Claude 3.5 : quand le palier intermédiaire dépasse l'ancien palier haut
ClaudeRoutageCoûtÉvaluation2024-06-2010 min
Le palier intermédiaire d'une nouvelle génération dépasse le palier supérieur de la précédente. Toute répartition figée devient un surcoût silencieux.
Ce que la nouvelle génération déplace
Le palier intermédiaire de Claude 3.5 dépasse le palier supérieur de la génération précédente, à un coût plusieurs fois inférieur. Ce recouvrement entre générations est devenu la règle, et il rend obsolète toute répartition figée.
Une équipe qui a décidé six mois plus tôt d'envoyer ses analyses complexes au palier supérieur continue de le faire. Elle paie désormais cinq fois trop cher pour une qualité identique, et rien dans son tableau de bord ne le signale.
C'est le coût le plus discret d'un système d'IA en production : non pas une erreur, mais une décision correcte qui a cessé de l'être. Elle ne produit aucun incident, aucune plainte, aucune alerte, seulement une facture qui aurait pu être divisée.
Pourquoi personne ne reprend la décision
Rejouer la répartition demande un jeu de tests ; sans lui, la reprise devient un projet, et un projet ne se lance pas pour une économie qu'on ne sait pas chiffrer. C'est le vrai blocage, et il est organisationnel.
La séquence est toujours la même. Quelqu'un lit l'annonce, propose de tester, et se heurte à trois questions : tester sur quoi, comparer à quoi, décider selon quel critère. Faute de réponse, la proposition s'éteint.
Avec un jeu de tests, la même reprise prend deux heures : on change l'identifiant du modèle, on relance, on compare les taux d'erreur, on décide. Le coût d'entrée est celui du jeu de tests, construit une fois. C'est ce qui fait de l'évaluation continue le composant le plus rentable d'un système en production, loin devant toute optimisation de prompt.
Le protocole de reprise, à chaque génération
- Relancer le jeu de tests sur le nouveau palier intermédiaire, pour chaque type de tâche actuellement servi par le palier supérieur.
- Comparer au seuil d'erreur fixé pour cette tâche, pas au modèle précédent. Le critère est absolu, pas relatif.
- Basculer par paliers : dix pour cent du trafic, mesure du taux de correction humaine, puis élargissement. Voir migrer un agent sans régression.
- Consigner la décision avec sa date et ses chiffres, pour que la reprise suivante parte d'un état connu.
L'effet moins visible sur les cas limites
Une nouvelle génération améliore surtout les cas moyens ; les cas limites qui échouaient continuent souvent d'échouer. C'est la nuance qui évite les déceptions après une bascule.
Les progrès annoncés portent sur des moyennes, et une moyenne s'améliore en traitant mieux ce qui était déjà à peu près correct. Les cas véritablement difficiles, une question ambiguë, un document contradictoire, une formulation inhabituelle, résistent plus longtemps.
La conséquence pratique est que le jeu de tests doit contenir des cas limites, et pas seulement des cas représentatifs. Un jeu composé uniquement de questions bien posées donnera un feu vert sur un modèle qui décevra en production, parce que les utilisateurs réels posent des questions mal formées.
Je recommande une composition explicite : deux tiers de cas courants, un tiers de cas limites choisis parmi les échecs réels observés. Cette proportion donne une prédiction fiable du comportement après bascule.
Le rendez-vous à inscrire dans le calendrier
Une revue de répartition par trimestre, une demi-journée, avec le jeu de tests existant. C'est le seul rituel d'exploitation qui se rembourse à chaque itération, et le seul qui empêche une architecture de vieillir sans qu'on s'en aperçoive.
Ce que ça change dans la relation au fournisseur
Un rythme de génération de six mois transforme le choix d'un modèle en décision périssable, ce qui rend la couche d'abstraction obligatoire. Ce n'est plus une bonne pratique : c'est une condition de survie du système.
Une équipe qui a codé contre un modèle particulier subit chaque génération comme une perturbation. Une équipe qui a isolé l'appel en profite comme d'une amélioration gratuite. La différence d'effort initial se compte en heures ; la différence sur trois ans se compte en mois.
Ce cadre est développé dans la couche qui rend le modèle remplaçable, et il devient d'autant plus rentable que le rythme s'accélère.
Le signal qui doit alerter
Une facture stable sur douze mois, sur un système dont l'usage a progressé, signale une répartition qui n'a pas été reprise. C'est contre-intuitif et pourtant fiable.
Sur un système sain, deux forces s'opposent : l'usage augmente, ce qui pousse la facture à la hausse, et les paliers deviennent meilleurs à coût constant, ce qui la pousse à la baisse. Une facture parfaitement plate signifie en général que la seconde force n'a pas été exploitée.
Le test tient en une question posée en revue : quelle est la date de la dernière bascule de palier ? Si la réponse dépasse six mois, l'économie disponible est probablement supérieure à tout ce que l'équipe cherche par ailleurs.
Questions fréquentes
- Faut-il changer de modèle à chaque nouvelle génération ?
Pas systématiquement, mais il faut rejouer la comparaison. Le palier intermédiaire d'une nouvelle génération dépasse souvent le palier supérieur de la précédente, ce qui divise le coût à qualité constante.
- Comment savoir si une bascule est sans risque ?
En la mesurant sur un jeu de tests contenant un tiers de cas limites, puis en basculant dix pour cent du trafic et en surveillant le taux de correction humaine avant d'élargir.
- Pourquoi les cas limites résistent-ils aux nouvelles générations ?
Parce que les progrès annoncés portent sur des moyennes, qui s'améliorent surtout en traitant mieux ce qui était déjà à peu près correct. Les questions ambiguës et les documents contradictoires résistent plus longtemps.
- À quelle fréquence reprendre la répartition ?
Une fois par trimestre suffit, en une demi-journée si le jeu de tests existe. Sans ce rituel, une architecture vieillit silencieusement et paie pendant deux ans un choix valable six mois.