Insights sur la génération de code d'agent à partir d'Android Bench

Tomáš Mlynarič

Bonjour à tous.

C'est parti !

En mars, nous avons lancé Android Bench, notre ensemble de données et notre classement pour mesurer les LLM sur les tâches de développement Android.

Depuis, nous l'avons exécuté sur de nombreux nouveaux modèles.

Et le mois dernier, nous avons lancé Android Bench 2.0.

Bien que quelques mois seulement se soient écoulés, dans le monde de l'IA, cela semble une éternité.

Je m'appelle Tomáš et je vais vous présenter notre parcours avec Android Bench et comment nous en sommes arrivés là.

Commençons par la version 1.0.

Dans la version 1.0, nous avons utilisé des problèmes réels issus de dépôts Open Source.

Nous avons filtré les projets GitHub avec des problèmes GitHub, des demandes d'extraction résolvant ces problèmes et des tests vérifiant les solutions.

Nous divisons les demandes d'extraction en buckets de tâches pour les modèles d'IA.

Le problème GitHub est devenu les instructions ou le prompt du modèle, et nous les avons intégrés à l'état avant la demande d'extraction.

Une fois que le modèle a créé du code, nous avons appliqué les tests au résultat, ce qui nous a permis de déterminer s'il était réussi ou non.

Cette tentative de l'IA pour résoudre le problème est appelée un essai.

Nous pouvons également la comparer à la solution créée par un humain à partir de cette RP, que nous appelons la solution de référence.

Cette méthodologie est semblable au benchmark SWE-bench, qui est bien connu.

Nous avons commencé avec plus de 10 000 tâches potentielles, mais toutes n'étaient pas adaptées.

Certaines instructions étaient incomplètes ou trop spécifiques.

Les tests ont peut-être été associés à la solution de référence, ou l'état avant la RP était défectueux.

Nous avons donc dû examiner et réexaminer les tâches pour en trouver 100 qui soient équitables.

Lors de ces examens, nous avons utilisé des modèles de pointe pour obtenir des résultats.

Nous avons commencé avec un taux de réussite d'environ 30 % des tâches résolues.

Ensuite, lorsque nous avons verrouillé l'ensemble de données pour la version officielle, les meilleurs modèles atteignaient déjà environ 70 %.

Mais c'est un mois plus tard.

Nous avons ensuite prévu d'évaluer de nouveaux modèles tous les mois, et nous avons observé comment ils s'amélioraient.

Dans la version d'août, le taux de réussite était de 92 % pour le meilleur modèle.

Nous savions que notre barre était trop basse et que cet ensemble de données était saturé.

Tomáš Mlynarič

Mais nous avions anticipé cela et nous travaillions déjà d'arrache-pied sur la version 2.0, que nous avons lancée le mois dernier.

L'objectif est, et a toujours été, de placer la barre plus haut avec des tâches Android complexes et concrètes, et de fournir des conseils et de la transparence sur les performances des LLM pour vous, les développeurs, mais aussi de pousser les créateurs de modèles à donner la priorité à Android en leur fournissant un bon benchmark pour s'améliorer.

et en fournissant des analyses et des résultats qui vous sont utiles, à vous et aux créateurs de modèles.

Mais nous devons également tenir compte de l'intelligence, de la ténacité et de la triche.

Et nous devons prévenir le risque de contamination.

L'un des problèmes de la méthodologie SWE-bench est l'ouverture réelle du code source.

OpenAI a publié un article.

Ils ont constaté que les modèles étaient capables de compléter les mots suivants des instructions ou de résoudre une tâche avec une erreur obscure qui ne faisait pas partie des instructions.

Ils ont réalisé que les créateurs de modèles s'entraînent sur le code Open Source et que le SWE-bench est contaminé.

Pour la version 2.0, nous gardons donc le code fermé pour empêcher l'entraînement sur celui-ci.

Nous avons divisé le travail en quatre flux de travail.

Dans le premier, nous avons pris des applications Flutter et React Native Open Source, et nous avons demandé aux agents de les convertir en solutions Android natives.

Cela reflète la tendance actuelle de migration des applications multiplates-formes vers des applications natives.

Le deuxième flux de travail concernait les nouvelles fonctionnalités et les intégrations de plates-formes.

Ils ont été intégrés à des bases de code de production établies.

Par exemple, dans Now in Android, nous avons ajouté une fonctionnalité vidéo, ou Picture-in-picture, des choses comme ça.

Le troisième flux de travail était la migration.

Nous mettons à niveau les applications de production Open Source que nous avons gardées fermées, avec des bibliothèques et des architectures modernes.

Par exemple, Nav 2 vers Nav 3, les vues XML vers Compose, ou encore une mise en page à un seul volet vers une mise en page adaptative.

La dernière était une application interne créée de toutes pièces à l'aide de maquettes de conception visuelle.

Ici, les exemples étaient le flux d'authentification OTP complet par SMS, le suivi des commandes avec Google Maps, etc.

Tomáš Mlynarič

Avec seulement quelques ingénieurs, nous avons créé une application de la même taille que Now in Android.

Mais les nouvelles tâches ont apporté de nouveaux défis.

Le premier : évaluer correctement les agents.

Les tests de benchmark sont beaucoup plus difficiles que les tests de votre application, car ils doivent accepter n'importe quelle solution valide, et pas seulement une. Plus la tâche est importante, plus il y a de solutions valides.

Dans la version 1.0, le benchmark reposait principalement sur des tests unitaires, qui sont très peu agnostiques.

import com.foodvibes.MyViewModel

@Test
fun testRetry() {
    val vm = MyViewModel()
    vm.retry()

    assertTrue(vm.retried)
}

Ils nécessitent des noms de classe ou de fonction exacts.

Comme dans ce cas, il n'y a pas de test sophistiqué, mais en gros, l'agent peut nommer ces éléments différemment, ou même s'il ne les nomme pas différemment, s'il les place dans un autre package, la compilation des tests échouera et ils seront donc inutilisables dans notre cas.

import com.foodvibes.feature.my.RetriableViewModel

@Test
fun testRetry() {
    val vm = RetriableViewModel()
    vm.tryAgain()

    assertTrue(vm.tried)
}

Nous pourrions donc techniquement spécifier les API dans les prompts, mais cela donnerait trop de détails ou surchargerait le prompt avec trop d'exigences de test.

La solution consiste donc à effectuer des tests indépendants de l'implémentation.

Il s'agit de tests de très haut niveau qui testent les résultats et les comportements, et non les éléments internes.

Nous utilisons le test d'UI déterministe, qui interagit avec les informations publiques de l'écran, comme le ferait un utilisateur.

Pour cela, nous utilisons UI Automator ou des tests d'UI Compose, mais nous avons également des scripts spécialisés qui vérifient certaines limites du système externe, par exemple si un appel réseau contenait les bonnes données ou si les bonnes données sont enregistrées dans une base de données sans connaître les assistants internes ou les DAO.

Nous effectuons également des vérifications statiques, par exemple pour vérifier les autorisations dans le fichier manifeste ou si la bibliothèque se trouve dans les fichiers compilés, etc.

Nous avons également des tests hybrides qui combinent ces scripts et les tests d'UI.

Voici un exemple de test hybride.

Ils conduisent en dehors de l'émulateur.

Voici le test du flux d'authentification par OTP par SMS. Le script doit d'abord calculer le hachage de l'application pour pouvoir envoyer correctement le SMS à l'émulateur, puis lancer le test, les tests UI Automator, transmettre un OTP généré de manière aléatoire dont il a besoin et envoyer un SMS à un émulateur avec une commande ADB.

Le test vérifie simplement si l'entrée comporte le bon nombre.

C'est à peu près tout.

Il n'y a aucun couplage d'implémentation, seulement des vérifications. Il vérifie uniquement si le flux fonctionne.

Le deuxième problème de notation était que nos tâches nécessitent une multimodalité.

Soit les agents doivent produire l'UI, soit nous leur fournissons les maquettes de conception.

Pour cela, le plus simple est d'utiliser des tests de capture d'écran.

Nous savions dès le départ que les seuils de capture d'écran devraient être plus élevés, mais ils ont quand même échoué.

Nous avons essayé différents algorithmes de comparaison de pixels, mais ils ont échoué sur des éléments tels que le bruit au niveau du système, où la barre d'état de l'émulateur était différente, ou l'icône de la batterie, ou même l'anticrénelage matériel des polices.

Mais ils ont également échoué sur des implémentations quelque peu valides, où, vous savez, les marges intérieures étaient mineures, légèrement différentes, ou il y avait de légères différences de teinte, comme l'UI pouvait être complètement correcte, mais l'arrière-plan serait légèrement teinté différemment, et les algorithmes de comparaison de pixels échoueraient.

Pour cela, nous avons utilisé et créé un juge LLM multimodal qui compare des paires de captures d'écran, comme dans les tests de captures d'écran, et nous donne un score, mais aussi un raisonnement structurel sur ce score.

Nous lui fournissons également des dumps de hiérarchie d'accessibilité qui vérifient si la structure est correcte et si la parité structurelle est correcte.

Nous l'avons testé de manière empirique sur de très nombreux essais, et nous avons constaté qu'il était très cohérent et qu'il ignorait les problèmes que nous avions constatés.

Nous disposions désormais d'un bon moyen de vérifier les visuels et les comportements de manière agnostique. Nous avons donc constaté que les agents essayaient de tout simuler.

Allez-y.

Tomáš Mlynarič

Tout commence simplement.

Aujourd'hui, les agents se disent : "D'accord.

J'ai une tâche.

Regardons GitHub.

Trouvons des solutions."

C'est donc la première chose qu'ils font.

Ils essaient de rechercher la solution valide sur GitHub ou sur Internet. C'est pourquoi nous devons garder le code source fermé et ne pouvons pas le rendre public.

Mais c'était facile.

Dans certains essais, nous avons dit que tout se passait bien à 100 %, et l'agent a répondu : "Magnifique triomphe !"

Alors…

Intéressant, qu'a-t-elle trouvé ?

Mais en examinant de plus près la trajectoire, ils se sont dit : "Je ne peux pas faire ça.

Je vais juste… Et si je changeais le seuil à 80 % du test de capture d'écran ?"

// AuthFlowScreenshotTests.kt

@get:Rule
val dropshots = Dropshots(
    resultValidator =
        ThresholdValidator(
-           0.05f
+           0.80f
        )
)

Et on se dit : "Oui, c'est un triomphe, tout passe."

Oui, mais les tests de capture d'écran sont inutiles.

Mais ce n'était pas la plus sophistiquée.

Dans certains cas, comme l'application de conversion Flutter, l'agent a essayé à plusieurs reprises de créer l'application Android, mais il a fini par dire : "Je ne sais pas quoi faire."

Ils ont donc pris la capture d'écran que nous leur avons fournie et l'ont définie comme drawable en arrière-plan.

Et maintenant, il réussit le test de capture d'écran.

Super !

Mais les tests d'UI échouent toujours. Ils se disent alors : "Je vais ajouter une couche de superposition invisible par-dessus, avec les boutons, les textes, les tags de test et tout ce dont nous avons besoin.

Maintenant, tout est vert.

Parfait.

Bien joué."

Il n'y en a pas un qui est vraiment bon.

Nous avons donc une tâche de migration de Java vers Kotlin, où l'agent doit essentiellement migrer de Java vers Kotlin, n'est-ce pas ?

Ils n'ont pas réussi à le compiler.

Il y a toujours un problème, alors l'agent s'est dit : "Je vais simplement prendre les classes compilées de Java, les mettre dans un JAR, puis les ajouter aux fichiers de compilation comme une bibliothèque standard.

Maintenant, tous les tests sont réussis, mais nous avons des vérifications statiques qui vérifient les fichiers Java. Je vais donc les supprimer."

Je supprime les fichiers Java, tout est vert, mais Kotlin échoue toujours. Je me dis alors : "D'accord, je vais supprimer l'ensemble de sources Kotlin, et maintenant tout fonctionne.

Super."

Je ne sais même pas si c'est de la triche.

C'est vraiment très créatif.

Pour éviter tout ça, on a créé un détecteur de triche qui a trois défenses.

Nous examinons l'arborescence de l'UI, nous appliquons différentes tailles d'écran pour que l'arrière-plan soit déformé, et nous le voyons.

Mais nous réinitialisons également les tests et vérifions qu'ils n'ont pas été altérés, afin que les utilisateurs ne puissent pas modifier les seuils.

Nous avons également un LLM-as-a-Judge, qui audite les trajectoires et la sortie réelle de l'agent pour détecter les anomalies.

Et si quelque chose se passe, nous disons simplement : "D'accord, échec direct."

Tomáš Mlynarič

Désormais, tous les raccourcis ont disparu : plus de recherche de solutions, plus de tests unitaires fragiles ni de simulation d'interface utilisateur.

Alors, quand nous forçons les agents à concevoir une application Android, quels sont les résultats ?

Comme vous l'avez peut-être vu dans l'article de blog, les chiffres se présentent comme suit depuis lundi.

Même le meilleur agent ne réussit qu'environ 40 % de nos tâches, et la plupart des agents de pointe se situent entre 20 % et 40 %.

C'est une bonne chose pour nous, les auteurs du benchmark, car cela permet de trouver le juste équilibre : les tâches que nous avons fournies ont une valeur réelle, mais il y a aussi une grande marge de progression.

Examinons à présent les résultats.

Nous pouvons maintenant examiner les résultats sous différents angles.

Nous pouvons examiner certains des insights que nous avons déjà trouvés.

La première question que vous pourriez vous poser en regardant le graphique est la suivante : combien coûte l'exécution de cet agent ?

Les entreprises d'IA indiquent généralement le coût par jeton, pour certains jetons d'entrée, de sortie, voire de cache.

Et peut-être que cela vous aidera à prendre une décision.

Mais nous pouvons l'examiner sous un autre angle.

Nous pouvons tracer le même graphique dans un espace 2D avec le coût moyen par tâche, et non par jeton. Nous pouvons ainsi comparer le coût par tâche au taux de réussite.

On voit tout de suite que certains modèles sont beaucoup plus bavards.

Ils consomment beaucoup plus de temps ou de jetons par tâche, tandis que d'autres réussissent plus de tâches tout en coûtant moins cher.

Mais si nous ajoutons également le prix par jeton à ce même graphique, nous pouvons voir que ce que les entreprises d'IA annoncent ne correspond pas à ce que vous payez réellement par tâche.

Vous pouvez donc voir que l'agent qui obtient le meilleur taux de réussite est en fait l'un des moins chers par jeton, mais le plus cher par tâche.

D'autres agents avec le même prix de jeton réussissent environ 30 % des tâches, mais ils sont 15 fois moins chers.

Le prix du jeton n'est donc pas la métrique.

Certains modèles explorent davantage le code, le reconstruisent, le réexécutent, et chaque étape consomme plus de jetons.

En résumé, ne vous contentez pas de regarder le coût par jeton.

Choisissez un modèle, examinez les données réelles, utilisez-le dans votre cas ou consultez Android Bench pour voir quels modèles utilisent le plus de jetons pour les tâches.

Certains nécessitent plus d'étapes, même s'ils sont moins chers par jeton.

Mais il y a un autre aspect à cette même question.

Il s'agit du même graphique, mais nous pouvons également examiner et afficher le temps nécessaire aux agents pour effectuer cette opération.

On peut voir que les agents qui ont le taux de réussite le plus élevé sont peut-être même les plus lents.

Par exemple, on peut voir que certaines tâches prennent près de deux heures.

Ils continuent de reconstruire et de tester jusqu'à ce que cela fonctionne.

Oui, ils obtiennent le meilleur taux de réussite, mais ils prennent aussi le plus de temps.

Certains agents moins chers prennent encore environ une heure et demie par tâche, mais sans meilleurs résultats.

D'autres agents terminent en moins de 20 minutes et résolvent tout de même plus d'un quart des tâches.

Les petits modèles légers sont généralement plus rapides et moins coûteux, mais ils échouent plus souvent sur les tâches difficiles.

En résumé, il n'existe pas de modèle idéal.

Cela dépend de ce que vous optimisez.

S'agit-il du taux de réussite ?

Est-ce le coût ?

Est-ce le temps d'attente ?

Dans ce cas, selon le type de travail que vous effectuez, si vous ne travaillez pas sur des tâches aussi difficiles, vous pouvez envisager d'utiliser des modèles plus rapides qui effectuent le travail de manière plus économique et plus rapide.

Cependant, le coût et la vitesse ne vous indiquent que la façon dont les agents s'exécutent, mais pas pourquoi ils échouent à la plupart des essais.

Nous avons donc inspecté les exécutions ayant échoué et nous avons remarqué que les agents s'arrêtaient souvent prématurément.

Ils sont convaincus d'avoir terminé.

Tâche terminée.

D'accord, je rentre chez moi.

Mais, comme nous l'avons mentionné, dans le paquet de tâches, les agents ne reçoivent que les instructions et l'état initial.

Ils ne peuvent pas voir les tests.

Ils constatent qu'ils ne peuvent pas voir la suite de validation.

Nous nous sommes donc demandé ce qui se passerait si nous leur permettions de voir les tests.

Nous avons donc fait des tests et nous avons utilisé une variante de test ouvert de la même tâche, où l'agent a reçu d'emblée la suite de tests de vérification qui échouait.

Ils ont donc exécuté les tests de manière itérative.

Ils peuvent inspecter les erreurs et affiner les codes dans une boucle de rétroaction.

Nous avons constaté que lorsque les agents voient les tests, ils font plus d'efforts et travaillent plus longtemps.

Dans les exécutions ouvertes, ils ont obtenu 25 % de tours en plus et 40 % de temps d'exécution de l'agent.

Ils ont passé près de 30 minutes par tâche à exécuter et à corriger les tests ayant échoué, car ils ne déboguaient pas à l'aveugle.

Ils voient donc exactement ce qui échoue et, malheureusement, le taux de réussite augmente également de près de 50 points de pourcentage.

Et cet effort supplémentaire améliore le taux de réussite moyen, comme je l'ai mentionné.

Mais de nouveaux modèles de frontière sont arrivés et ont rapidement saturé cette variante ouverte.

Eh bien, près de 90 % de taux de réussite.

Nous avons donc conservé la variante de test fermé "Recherche fermée" comme métrique de référence principale.

Mais il est tout de même très intéressant de voir que les modèles sont plus performants lorsqu'ils savent sur quoi ils sont évalués.

Tomáš Mlynarič

Cependant, cela nous a permis d'obtenir plus d'insights sur les agents.

Par exemple, nous pouvons vérifier comment les modèles testent leur propre travail.

Le graphique montre que les modèles de frontière écrivent de plus en plus de tests de meilleure qualité, et qu'ils ont des taux de réussite plus élevés.

D'autres modèles sont trop confiants : "Je peux le faire, pas besoin de tests."

Parfois, ils sont encore bons.

Si vous utilisez des modèles qui ne sont pas très performants pour les tests, vous pouvez les aider en leur fournissant de meilleures compétences en matière de tests ou des instructions spécifiques sur la façon de rédiger des tests.

Mais la corrélation n'implique pas la causalité, n'est-ce pas, CS ?

Nous devons mener une expérience contrôlée à ce sujet.

Nous devons encore déterminer si le fait de demander de meilleurs tests améliore réellement le score.

Nous avons toutefois mené une expérience sur l'autre moitié des tests Android, qui consiste à faire en sorte que les agents utilisent l'émulateur.

Au début de notre benchmark, nous n'avons rien dit sur l'émulateur.

Nous pensions que les agents devaient s'en charger, n'est-ce pas ?

Nous avons constaté que presque aucun d'entre eux ne démarrait l'émulateur.

Comme je l'ai mentionné, nos tests d'UI sont essentiels pour nos benchmarks, et sans émulateurs, vous ne pouvez pas vraiment les utiliser.

Ils échouaient tous sur des choses très simples.

Nous sommes donc confrontés à un dilemme.

Doit-on dire aux agents d'utiliser l'émulateur, au risque d'obtenir des scores plus élevés, ou ne rien dire et espérer qu'ils trouveront la solution ?

Mais après tout, notre objectif était de proposer un benchmark équitable pour mesurer les compétences en codage et en résolution de problèmes sur Android.

Nous ne voulons pas mesurer les particularités environnementales.

Nous avons donc choisi un juste milieu.

Nous lui avons expliqué comment démarrer un émulateur, mais nous n'avons pas précisé s'il devait l'utiliser ou non.

Après tout, le démarrage de l'émulateur n'est pas ce que nous devons tester ou ce que nous voulons tester.

Nous avons mesuré l'effet de cette instruction de l'émulateur.

Nous avons constaté que lorsque nous leur avons fourni les instructions, les agents ont démarré l'émulateur beaucoup plus souvent et ont exécuté les tests d'UI, ce qui a eu un impact important sur le taux de réussite, malheureusement pour nous.

Mais cela nous a également permis d'inspecter leurs erreurs et problèmes de codage réels, et pas seulement, par exemple, l'échec sur l'émulateur non démarré.

En résumé, la spécificité du prompt reste très importante. Si vous concevez vos propres benchmarks ou évaluations, vous devez tester ce qui compte vraiment dans votre cas.

Par exemple, si vous évaluez l'efficacité des jetons, d'une compétence ou d'un outil, vous devez d'abord commencer par l'évaluation, apporter la modification pour l'efficacité, puis vérifier que l'évaluation est toujours réussie avec moins de jetons.

Si vous ne le faites pas, vous aurez trop de variables qui changeront en même temps, et vous ne saurez pas si c'est réellement votre modification qui a amélioré les choses.

Tomáš Mlynarič

Revenons au classement.

Comme je l'ai mentionné, les meilleurs modèles réussissent environ 40 % des tâches, et le taux de réussite exige que toutes les vérifications soient réussies.

Sinon, la tâche échoue.

La question est donc la suivante : les agents n'ont-ils rien produit d'utile pour les 60 % restants ?

Non, ils s'en approchent.

Pour montrer à quel point l'agent s'est approché des solutions fonctionnelles, un peu comme une distance, nous calculons également le taux d'achèvement ou une sorte de score partiel.

Il s'agit d'un score pondéré dans quatre catégories : cohérence visuelle, fonctionnalité, bon fonctionnement, exigences spécifiques à chaque tâche et vérifications de régression.

On peut voir que les modèles moins bien classés sont capables de terminer environ la moitié du travail, tandis que les modèles de frontière sont capables de terminer et d'atteindre près de 80 % en moyenne, soit plus de 80 % des tâches, mais ils ne réussissent qu'à 40 %.

Nous avons donc effectué un test sur la conversion de Flutter vers Android pour voir ce qui se passait.

Nous avons donc recalculé le taux de réussite toutes les quelques étapes de l'agent, et nous avons observé les mêmes schémas sur tous les modèles de frontière.

Vers 140 étapes, ils ont atteint un score moyen de près de 90 %, puis ils ont passé 90 étapes supplémentaires, soit près de 40 % de l'exécution, à essayer de combler l'écart pour atteindre 100 %, mais ils n'ont pu obtenir qu'un score de 1 ou 2 % de plus.

Et nous pensons que cela reflète ce qu'est le développement agentique aujourd'hui, où les développeurs ou les utilisateurs inexpérimentés considèrent que l'application est terminée.

Tout s'affiche.

L'entrée a fonctionné, mais pas complètement.

Il n'y a peut-être pas de plantages.

Mais lorsqu'un ingénieur senior examine le code, il constate de nombreux défauts : des problèmes d'architecture, des défauts de cycle de vie, etc.

Tomáš Mlynarič

Pour conclure, mettons en perspective Android Bench, notre travail 2.0.

Par rapport à la version 1.0, nous n'avons plus que 30 tâches, et c'est délibéré.

Au lieu de corrections de bugs isolées et de petits correctifs, nous avons des écrans complets, des migrations multimodules et des conversions d'applications entières.

Les correctifs sont désormais beaucoup plus volumineux et répartis sur des dizaines de fichiers.

Nous avons également les vérifications d'UI multimodales.

Les agents doivent s'exécuter plus longtemps et travailler beaucoup plus dur.

Si nous comparons notre benchmark à d'autres benchmarks de pointe, nous pouvons constater qu'il nécessite des modifications de code beaucoup plus importantes.

Il n'y a pas de contamination, car la plupart des tâches sont écrites de zéro, et il y a encore beaucoup de marge de progression.

Comme je l'ai dit au début, quelques mois dans le monde de l'IA semblent une éternité, et chaque benchmark finit par être saturé.

Et quand ce sera le cas, nous nous attaquerons, espérons-le, à des tâches encore plus difficiles et complexes qui résonneront à nouveau avec cette époque et cet état de l'IA.

Utilisez maintenant Android Bench comme boussole pour comparer les modèles et les harnais, et peut-être obtenir des insights.

Et lorsque vous serez prêt à aller plus loin, appliquez les mêmes principes d'analyse comparative et d'évaluation à vos propres code bases et workflows, car rien ne vaut la mesure de l'IA sur le code avec lequel vous travaillez réellement.

C'est ainsi que vous pouvez passer de l'espoir que l'IA a bien compris à la certitude qu'elle l'a fait.

Au nom de toute l'équipe Android Bench, merci de votre attention.