Asana a annoncé que, lors d’une évaluation de son IA d’automatisation des opérations dans un navigateur, elle avait réduit le coût estimé des modèles d’un facteur 76 et multiplié la vitesse de traitement par cinq par rapport à la configuration de production traditionnelle. Avec GPT‑6.1 Sol et une gestion optimisée de l’historique de navigation, chaque traitement a duré environ 4 minutes et coûté en moyenne 0,47 dollar.
Diviser le coût par 76 ne se résume pas à changer de modèle
Le point essentiel dans ces chiffres est qu’ils ne comparent pas les performances des modèles seuls, mais celles d’une combinaison entre un modèle et un processus de traitement. Un agent de navigation est une IA qui lit des pages web et effectue des tâches comme la recherche d’informations ou le remplissage de formulaires. Asana propose l’automatisation de ce type de tâches par l’intermédiaire de StackAI, qu’elle a racheté.
Lors de l’évaluation, l’équipe a recueilli six informations sur chacun des 32 livres présentés dans un catalogue public de démonstration. Elle a effectué 144 essais avec quatre modèles et plusieurs configurations. Avec le modèle B utilisé au départ, le coût estimé par traitement était d’au moins 36,21 dollars. Il est tombé à 1,24 dollar en repensant uniquement le processus de traitement. Avec la configuration optimisée utilisant GPT‑6.1 Sol, il a encore baissé, à 0,47 dollar.
Autrement dit, même en conservant le modèle B, les coûts ont été réduits à environ un vingt-neuvième de leur niveau initial. Derrière le chiffre de 76 fois moins, l’amélioration du processus de traitement — avant même le choix du modèle — a joué un rôle majeur.
La clé des économies : l’historique de navigation transmis à l’IA
Dans la configuration traditionnelle, les instructions fixes étaient mises en cache, mais pas l’historique constitué du contenu des pages et des captures d’écran. Le cache permet de réutiliser une entrée déjà traitée. Sans possibilité de réutiliser l’historique, chaque appel à l’IA renvoie les informations précédentes et entraîne des frais supplémentaires.
De plus, les anciennes images étaient supprimées presque à chaque étape et les textes raccourcis. L’historique étant fréquemment modifié, l’ajout d’un cache à lui seul risquait de produire peu d’effet. Supprimer trop d’informations peut aussi obliger l’agent à consulter de nouveau des pages qu’il a déjà lues.
Asana a donc relevé la limite de conservation de l’historique de 120 000 à 480 000 caractères et ajouté l’historique de navigation au cache. Les captures d’écran sont désormais conservées par lots de 20, puis seule la plus récente est gardée. Plutôt que de nettoyer l’historique à chaque fois, ce nettoyage groupé prolonge la période pendant laquelle les données antérieures peuvent être réutilisées sans modification.
Conserver davantage d’informations peut aussi réduire les coûts
Réduire les informations transmises à l’IA permet de faire des économies. Les résultats de cette évaluation montrent toutefois que cette seule idée ne suffit pas à expliquer le coût des agents. Dans certains cas, conserver les informations pour les réutiliser et éviter des vérifications inutiles revient moins cher à l’échelle de l’ensemble du traitement.
Avec GPT‑6.1 Sol, dans une configuration où la limite de conservation de l’historique avait été relevée, la révision du cache et de la gestion des images a fait passer le coût estimé par traitement de 1,97 à 0,47 dollar. Après optimisation, 89 % des données d’entrée provenaient du cache ; le coût de cette partie représentait 5 % de ce qu’il aurait été sans cache.
La quantité d’informations conservées a également influé sur l’achèvement des tâches. Avec GPT‑6.1 Sol, une réponse a pu être générée dans 3 cas sur 18 lorsque la limite de conservation était faible, contre les 18 cas sur 18 lorsqu’elle était plus élevée. Lors de l’évaluation, les 18 réponses obtenues étaient correctes.
L’IA a aussi servi à tester des pistes d’amélioration
GPT‑6.1 Sol, qui pilotait le navigateur, n’était pas le seul modèle utilisé : GPT‑6 Astra de Codex a servi aux recherches et à l’amélioration du système. Il a examiné la structure du code, repéré les problèmes de gestion de l’historique, remanié le code pour les expériences et testé plusieurs configurations en parallèle.
Cela ne signifie pas que les humains n’ont pas été impliqués. Frank Hidalgo, directeur technique de StackAI, a examiné les propositions et choisi les modifications à tester. Les comptes rendus et les résultats des expériences ont également été évalués lors de sessions avec un autre modèle et conservés dans Command, la plateforme de développement d’Asana. Les modifications ont ensuite été déployées en production après leur passage par des tickets et des demandes de fusion.
Frank Hidalgo estime que des recherches qui auraient pris un à deux mois de travail manuel ont été réalisées en environ une semaine. Cette comparaison repose sur son estimation ; elle ne résulte pas d’une expérience de contrôle où les mêmes tâches auraient été effectuées uniquement par des humains.
Pour décider d’un déploiement, il faut examiner ensemble le coût et le taux d’achèvement
Le montant de 0,47 dollar correspond au coût estimé des modèles, et non au coût total incluant la main-d’œuvre et l’exploitation du système. De plus, certaines configurations de référence ont atteint la limite du nombre de traitements sans achever la tâche : les valeurs d’au moins 36,21 dollars et 22,5 minutes constituent donc des minima. Les principaux chiffres comparatifs sont des moyennes sur trois essais par configuration, et le même taux de réduction ne peut pas être appliqué à toutes les tâches sur le web.
Parmi les configurations optimisées, le modèle C a coûté 0,66 dollar et pris 3,5 minutes, contre 0,47 dollar et environ 4 minutes pour GPT‑6.1 Sol. Pour cette tâche, Sol était moins cher, mais le modèle C était plus rapide : le classement diffère selon que l’on privilégie le coût ou la vitesse.
Asana a intégré ces modifications à la fonction de pilotage du navigateur de StackAI. L’entreprise prévoit désormais d’ajouter l’évaluation à la plateforme, afin que les clients et les équipes internes puissent comparer le coût, le temps d’exécution et la qualité des réponses selon les différentes configurations.
コメント