Votre travail n’a peut-être pas besoin du modèle le plus performant
Votre travail n'a peut-être pas besoin du modèle d'IA le plus performant, par Waldek Mastykarz
Votre travail n’a peut-être pas besoin du modèle le plus performant. Face à l’engouement suscité par GPT-6 Astra, il est facile d’en faire votre choix par défaut et de s’attendre à obtenir le meilleur résultat à chaque fois. Cette attente mérite d’être remise en question, car l’amélioration apportée à votre travail doit justifier le coût. Même lorsque l’entreprise prend en charge les frais d’utilisation, les choix effectués par les développeurs tout au long de la journée finissent par peser lourd dans la balance.
Pour une équipe qui doit décider comment dépenser son budget alloué aux agents, la question pertinente est la suivante : quel est le modèle minimal viable pour notre travail ? Trouver le modèle le moins cher qui réponde à vos exigences commence par la sélection de candidats, ce à quoi un classement peut vous aider. Évaluer ces candidats sur vos propres tâches vous permettra de déterminer lequel soutient le mieux le flux de travail de votre équipe.
Ce que vous apporte la mise à niveau
Lors d’une précédente comparaison de modèles, un modèle plus récent a suivi les instructions de mise à niveau explicites de manière plus fiable, tandis que le modèle plus ancien a produit une architecture plus idiomatique dans les scénarios que nous avons mesurés. L’utilité de la mise à niveau dépendait du type de travail que nous lui confions. Les benchmarks publics mesurent leur propre ensemble de tâches dans un environnement particulier ; vos dépôts et la configuration de vos agents peuvent donc produire des résultats différents.
Pour voir à quoi ressemblait ce compromis pour Astra, nous l’avons comparé à Claude Sonnet 4.6, un modèle couramment utilisé, dans trois scénarios de mise à niveau de code. Les deux modèles ont été exécutés dans GitHub Copilot Chat au sein de Visual Studio Code sous Windows avec la même configuration de scénario, et nous avons exécuté chaque profil cinq fois. Vous trouverez ci-dessous une comparaison appariée pour chaque scénario, avec des scores de qualité arrondis et des coûts par exécution basés sur la tarification de GitHub Copilot au moment de la rédaction :
Dans ces configurations, le coût plus élevé d’Astra nous a valu un score inférieur sur une tâche, un score similaire sur une autre et une légère amélioration sur la troisième. Claude Sonnet 4.6 sert ici de point de comparaison familier, et cinq exécutions par profil nous donnent un premier aperçu des performances. Déterminer si une différence d’un point est fiable nécessiterait une évaluation plus approfondie.
La comparaison avec le JDK s’est avérée très différente sans les extensions ajoutées : Astra a obtenu un score de 93 % contre 76 % pour Sonnet, à 8,59 $ contre 1,68 $ par exécution. L’ajout de la compétence de migration a inversé la comparaison en termes de qualité et augmenté les coûts pour les deux modèles ; les directives utilisées par votre équipe doivent donc être prises en compte dans l’évaluation au même titre que le modèle.
Seriez-vous prêt à payer plus de cinq fois plus cher pour un point supplémentaire ? La réponse dépend des contrôles qui se sont améliorés et de ce que ces améliorations signifient pour votre travail. Un score de qualité global mesure les performances par rapport aux critères d’évaluation, tandis que l’évaluation du risque d’actions destructrices nécessite des preuves concernant ces défaillances spécifiques. Pour les tâches ayant des conséquences importantes, ces preuves doivent s’accompagner de mesures de sécurité appropriées et d’une validation humaine.
Déterminez votre modèle minimal viable
Avant de lancer l’évaluation, définissez ce que le modèle doit absolument réussir et quel niveau d’échec votre équipe est en mesure de tolérer. Ces exigences déterminent quels modèles sont viables pour le travail à réaliser, ce qui vous permet ensuite de comparer leurs coûts. Fixer la barre dès le départ vous aide également à juger les résultats indépendamment de toute préférence pour un modèle particulier.
Le montant que vous êtes prêt à payer pour une amélioration dépendra des conséquences d’un échec. Hypothétiquement, une amélioration d’un point à un prix dix fois plus élevé pourrait être difficile à justifier pour un travail de routine, tandis qu’une amélioration de dix points à un prix deux fois plus élevé pourrait en valoir la peine si les contrôles améliorés permettent de remédier à des défaillances ayant des conséquences en aval. Se mettre d’accord sur ces compromis avant de commencer donne à l’équipe une base pour décider de la suite à donner aux résultats.
Une fois ces exigences définies, comparez les modèles à l’aide des mêmes scénarios et critères d’évaluation, en conservant l’espace de travail et la configuration des agents inchangés. Les différences entre les systèmes d’exploitation ou les configurations des agents peuvent influencer les résultats ; l’environnement doit donc refléter le travail de votre équipe et rester cohérent tout au long de la comparaison. Pour obtenir des conseils sur la définition des critères et l’évaluation des exécutions répétées, consultez l’article « Créer des évaluations AX qui fonctionnent réellement ».
Un modèle par défaut peut tout de même être la bonne réponse
Supposons que votre évaluation montre que cinq modèles excellent chacun dans un type de tâche différent, mais que les différences sont négligeables. Payer 0,02 $ de plus par tâche pour utiliser un seul modèle pour toutes pourrait s’avérer plus avantageux, offrant aux développeurs un workflow prévisible et un modèle par défaut à prendre en charge. Cette commodité peut l’emporter sur les maigres économies réalisées en choisissant un modèle pour chaque tâche, tandis qu’une amélioration significative sur une tâche particulière pourrait justifier une exception. Utilisez les résultats pour mettre en balance les avantages et la décision supplémentaire que les développeurs doivent prendre, et gardez la sélection des modèles aussi simple que le permet le travail.
Votre choix a une date d’expiration
Une fois que vous avez choisi un modèle par défaut, une mise à jour de l’agent ou une nouvelle extension peut modifier son efficacité sur la même tâche. Les nouveaux modèles vous offrent davantage d’options, et les changements de tarification modifient le rapport qualité-prix même lorsque la qualité reste stable. Une décision qui était la bonne le mois dernier peut aujourd’hui s’avérer inutilement coûteuse ou exposer l’équipe à davantage d’échecs.
Pour que ce choix reste d’actualité, conservez un petit ensemble de scénarios représentatifs et réexécutez-les à mesure que votre équipe met à jour ses agents et ses extensions. Les modifications apportées aux modèles ou aux tarifs constituent également des raisons de réexaminer la comparaison. À quelle fréquence devez-vous l’effectuer ? Aussi souvent que vous pouvez donner suite aux conclusions, en laissant à l’équipe le temps d’étudier les résultats et de mettre à jour sa recommandation.
Les évaluations ont un coût et leur maintenance demande des efforts, mais le partage des conclusions permet à toute l’équipe de bénéficier de cet investissement. Que Astra justifie son surcoût par rapport à votre travail ou que votre modèle actuel réponde déjà à vos besoins, vous disposerez de données probantes pour orienter l’affectation du budget. Évaluez votre travail, puis financez les améliorations que vous pouvez justifier.
Source : Your work might not need the smartest model
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi :
Répondre avec citation
Partager