Workflows de codage agentiques avec de petits modèles

Très bien.

Bonjour,

Je m'appelle Jose, et je suis ici avec Ian et Zoe.

Nous connaissons tous les LLM.

Nous les utilisons pour tout : trouver des recettes, résumer des vidéos YouTube et coder.

Il existe de très grands LLM, comme les modèles Gemini, qui sont capables de choses vraiment incroyables, mais dans cette présentation, nous allons parler des petits modèles de langage.

Ce sont aussi des LLM, car un modèle avec quatre milliards de paramètres ne peut pas être petit. Mais nous ferons désormais cette distinction : les modèles de frontière et les petits modèles de langage, la fusée et le vélo.

Nous n'aborderons pas les petits modèles comme une alternative aux modèles de frontière, mais plutôt comme un complément.

Nous allons explorer tous les avantages des petits modèles de langage, en particulier lorsqu'ils sont ouverts, qu'ils ont des pondérations ouvertes et qu'ils sont téléchargeables, mais penchons-nous d'abord sur les coûts.

Pour cette présentation, j'ai exécuté de nombreux benchmarks, dont un ensemble de données de 200 tâches moyennes et difficiles utilisant près de 131 millions de jetons pour moins de 9 $.

J'ai utilisé Gemma 4 pour cela. J'aurais donc pu simplement le télécharger et l'exécuter sans frais sur mon propre matériel, mais je l'ai exécuté sur une passerelle commerciale juste pour une comparaison équitable.

Alors, combien coûterait un modèle de frontière ?

Environ 20 à 200 fois plus, selon la mise en cache des jetons et d'autres facteurs.

Le vélo n'est peut-être pas le moyen de transport le plus rapide, mais c'est sans aucun doute le plus efficace.

C'est vrai.

La question évidente est donc : quelle est la différence en termes de qualité et de précision ?

Dans cet ensemble de données particulier, Gemma 4 peut résoudre 53 % des tâches.

Cela signifie deux choses.

Si vous utilisez un modèle de frontière pour exécuter les tâches de gauche, cela peut être excessif.

Si vous utilisez un petit modèle pour exécuter les tâches de droite, vous devrez le guider vers une solution ou utiliser un modèle plus grand.

Dans cette présentation, nous voulons vous aider à tirer le meilleur parti de chaque jeton.

Zoe vous expliquera comment choisir un petit modèle, et Ian vous parlera des modèles Gemma pour que vous compreniez comment réfléchir à ce qu'ils peuvent permettre.

Ensuite, je vous montrerai rapidement comment essayer Gemma 4 dans Android Studio. Enfin, nous vous montrerons comment intégrer de petits modèles dans vos workflows quotidiens, ainsi que des benchmarks de développement Android réels pour vous aider à vous faire une idée de ce qu'ils peuvent faire.

Je laisse maintenant la parole à Zoe.

Merci beaucoup, Jose.

Utiliser un seul modèle pour tout, c'est un peu comme utiliser un marteau-piqueur pour casser une noix, n'est-ce pas ?

C'est efficace, mais un peu disproportionné.

Envisager les petits modèles, c'est un peu comme élargir votre ensemble d'outils.

Pour savoir ce que vous devez intégrer à vos workflows, vous devez ouvrir l'ensemble d'outils, voir ce qui est disponible, quelles sont leurs spécifications et à quoi ils servent.

Pour choisir des petits modèles, vous devez donc les connaître.

Le type de modèle auquel la plupart des gens pensent lorsqu'ils pensent à un modèle de langage est un modèle de langage autorégressif.

Il est autorégressif, car il choisit le prochain jeton le plus probable dans une liste de candidats, en fonction d'une entrée divisée en jetons.

Ensuite, le jeton suivant le plus probable qui a été choisi est réinjecté dans l'entrée, et ainsi de suite. Cela permet de produire des réponses cohérentes et intelligentes, mais cela présente certaines limites, y compris, mais sans s'y limiter, le fait de fonctionner de manière linéaire.

Nous pouvons donc travailler de manière non linéaire.

Un modèle de diffusion adopte la même approche, mais il traite un bloc de jetons à la fois.

C'est un peu comme un croquis qui se précise.

Dans ce cas, DiffusionGemma traite des fragments de 256 jetons à la fois.

En gros, vous obtenez un pass qui fonctionne sur l'ensemble du bloc, ce qui vous permet de générer des résultats avec moins de latence.

Notre ensemble d'outils comprend donc des modèles capables d'écrire, n'est-ce pas ?

Faux.

En gros, les modèles d'embeddings transforment des objets comme une image, du texte ou tout autre concept en vecteur.

Cela nous fournit un mappage de coordonnées dans un espace à haute dimension qui nous permet de comparer deux choses d'un point de vue conceptuel.

Par exemple, si un hot-dog est un sandwich, ils seront probablement proches ou se retrouveront dans un espace proche.

Par conséquent, pour vérifier si deux concepts sont liés, il suffit de faire un peu de maths au lieu d'effectuer une passe de modèle (qui est aussi un peu de maths, mais bon). Ce paradigme va encore plus loin, n'est-ce pas ?

Il existe également des modèles plus petits et spécialisés, capables d'effectuer une seule tâche, mais de manière très efficace.

Par exemple, nous avons des modèles de fonction qui convertissent le langage naturel en appels d'API, des modèles de vision (dont vous connaissez sûrement les capacités d'après leur nom) ou, par exemple, des classificateurs qui peuvent attribuer des scores à une entrée en fonction de certains paramètres.

Vous n'avez que l'embarras du choix, n'est-ce pas ?

Il existe de nombreux types de modèles, avec des dimensions, des tailles, des fenêtres de contexte, des capacités et des espaces mémoire utilisés différents. Une fois que vous ouvrez la boîte à outils et que vous tenez compte de toutes les possibilités, les options augmentent de manière exponentielle, au point que tout fan de bricolage serait absolument ravi ou paralysé par l'indécision.

Alors, comment choisir un petit modèle ?

Commençons par ouvrir une boîte à outils de petits modèles ouverts pouvant s'exécuter localement : les modèles Gemma.

À toi, Ian.

Merci, Zoe.

Comme l'a mentionné Jose au début, un petit modèle de langage peut effectuer environ 50 % des tâches sans configuration préalable.

Mais pourquoi choisir un modèle local ?

Cela se résume à quatre points.

Le premier est la confidentialité.

Par exemple, vous pouvez avoir des clés API, du code propriétaire ou des éléments qui ne peuvent littéralement pas quitter votre ordinateur portable.

Le deuxième est la latence.

Ainsi, lorsque le modèle est chargé en mémoire (mémoire graphique ou mémoire unifiée), vous obtenez une réponse dès que le calcul est terminé.

Ainsi, il n'y a pas de délai aller-retour vers les serveurs, ni de coût de latence supplémentaire.

Le facteur suivant est le coût marginal nul.

Les modèles sont donc rentables lorsque vous pouvez contrôler l'endroit où ils s'exécutent.

Par exemple, si vous exécutez une tâche sur une machine locale, elle peut effectuer des tentatives supplémentaires dans une boucle d'erreur.

Cela ne vous coûte rien, et il n'y a pas de frais d'API surprises pour cette partie.

Enfin, la quatrième est l'accès hors connexion.

Imaginez que vous puissiez l'utiliser dans un avion, un train, un bus ou le métro, en fait partout où le modèle s'exécute sur votre matériel.

C'est une bonne chose, mais nous devons prendre en compte deux facteurs majeurs lorsque nous prenons ces décisions.

Le premier est la mémoire, et le second est la vitesse.

Si vous regardez ce diagramme, vous verrez que les deux modèles du bas, le 26B et le 31B, nécessitent tous deux plus de 50 Go de RAM vidéo pour s'exécuter en BF16, qui est une quantification 16 bits.

Le problème, c'est que cela ne conviendrait pas à de nombreux matériels.

Nous utilisons donc un processus appelé "quantification", qui réduit cette précision à un float de 4 bits.

C'est un peu plus raisonnable.

On parle de 14 Go et 17 Go, n'est-ce pas ?

Cela pourrait désormais tenir sur un Mac à mémoire unifiée.

Le problème avec la quantification post-entraînement normale, c'est que lorsque vous compressez ces pondérations, vous perdez un peu de la précision du modèle de base. Nous disposons d'une technique pour y remédier.

C'est ce qu'on appelle l'entraînement basé sur la quantification.

Lorsque nous procédons ainsi, le modèle est entraîné en sachant qu'il sera utilisé sur ces tailles plus petites, ce qui réduit la perte.

Nous obtenons ainsi une réduction de 75 % des besoins en RAM, et le modèle peut désormais tenir sur ces appareils.

Et nous allons encore plus loin.

Les approches de quantification mobile que nous utilisons sur de nombreux téléphones mobiles peuvent réduire encore davantage ces modèles en comprenant le fonctionnement de toutes les différentes couches et les tailles auxquelles elles peuvent fonctionner.

Nous avons donc une sorte de sac de quantification mixte.

Nous passons donc d'un modèle Gemma E2B de 11,4 Go à un modèle de 1,1 Go.

Désormais, les téléphones de milieu et haut de gamme sont beaucoup plus abordables.

Le deuxième, c'est la vitesse.

Lorsque vous utilisez un modèle autorégressif, comme l'a mentionné Zoe, vous prédisez l'ensemble de jetons suivant.

Ainsi, dans une tâche de codage, vous constaterez peut-être que beaucoup de ces jetons sont en fait assez prévisibles, comme la fin d'une signature de méthode, ou une accolade ouvrante ou fermante.

Pour cela, vous pouvez utiliser une technique appelée "décodage spéculatif".

Cette technique utilise un modèle de rédaction plus petit pour prédire un certain nombre de jetons, qui sont ensuite validés par un modèle plus grand.

Et si cela fonctionne dans l'architecture Gemma 4, c'est parce qu'ils partagent le même cache KV.

Considérez cela comme la mémoire à court terme du modèle.

Un petit modèle de rédaction va donc prédire trois ou quatre jetons à l'avance, et le modèle plus grand va ensuite examiner ce même cache KV et valider le résultat.

Cela peut multiplier par trois les performances, sans perte de qualité de la sortie du modèle, car il se contente de prédire des éléments, puis de décider s'ils sont corrects ou non.

Là encore, cela dépend un peu de la tâche que vous effectuez.

Cette méthode ne fonctionne donc pas très bien pour des tâches comme l'écriture créative, car il y a plus de variabilité, mais elle fonctionne très bien pour des tâches prévisibles comme les structures JSON et le codage.

Alors, comment évaluer l'un de ces modèles ?

La chose la plus évidente à faire est de consulter un benchmark comme LiveCodeBench ou MMLU, et de regarder le score.

Mais cela ne vous donnera qu'un indicateur général des capacités du modèle.

Ce que vous devez vraiment faire, c'est évaluer l'ensemble de la pile dans laquelle elle s'exécute.

Il s'agit donc du modèle que vous utilisez, des pondérations et de l'approche de quantification, de l'inférence de l'environnement d'exécution (vous pouvez utiliser un outil comme llama.cpp, Ollama ou LiteRT), du harnais d'agent que vous utilisez (comme Pi, OpenCode ou Antigravity), puis de la fenêtre de contexte, qui est en quelque sorte l'espace pour toutes les données que vous souhaitez que votre modèle puisse traiter.

La combinaison de tous ces éléments détermine si le projet est viable ou non.

Pour vous donner un exemple rapide, nous avons effectué des tests avec Gemma 4 sur Android Bench et nous avons exécuté une version d'Ollama avec un contexte par défaut de 32 000.

Nous avons constaté que, dans l'un des tests, où il recherchait un bug, la compression du harnais d'agent déplaçait ce fichier hors de la mémoire, et le modèle ne pouvait alors pas terminer la tâche et échouait.

En augmentant le contexte de 32k à 256k, le modèle peut désormais le garder en mémoire et réussir ce test particulier.

et nous avons constaté un doublement du taux de réussite pour cette tâche.

Cela montre que même un seul de ces petits facteurs peut avoir un impact important sur la pertinence de ce modèle.

Alors, comment réaliser vos propres évaluations ?

Voici trois suggestions rapides.

Vous pouvez par exemple prendre un historique Git, c'est-à-dire un ensemble de demandes d'extraction réussies, et les utiliser comme entrées de prompt pour le modèle afin de voir comment il se comporte.

Ensuite, vous avez besoin d'un évaluateur déterministe qui vous aidera à évaluer si la sortie du modèle est correcte ou non.

Nous avons deux très bons exemples de cela.

Nous avons un compilateur et des tests unitaires.

Quel que soit le résultat généré, vous pouvez l'exécuter via ce système, qui vous indiquera si vous avez réussi ou non la tâche en question.

Le troisième est l'enregistrement des trajectoires.

Ainsi, lorsque vous exécutez un agent, vous voulez pouvoir suivre ses différents comportements, voir où il réussit et où il échoue, et vous pouvez utiliser ces informations pour évaluer la capacité du modèle à interagir et à utiliser des outils.

Et je voudrais que vous essayiez de changer votre façon de poser la question. Au lieu de vous demander si ce modèle est aussi intelligent que ce grand modèle de frontière,

"Cette tâche est-elle possible sur ce matériel avec cette configuration particulière ?"

Pour répondre à cette question, nous avons inventé un framework appelé "Atteignons-nous nos objectifs ?".

Ou AWTY.

Le principe de ce framework est de noter toutes ces différentes tâches sur cet axe en termes de préparation.

Le modèle lui-même, le moteur d'inférence que vous utilisez, le harness et la configuration matérielle.

Cela vous permettra de savoir si vous êtes prêt.

Par exemple, vous pouvez examiner la fiabilité de cette tâche spécifique.

Si vous l'exécutez, disons, 10 fois de suite, fait-il la même chose à chaque fois ?

Vous examinez peut-être la latence.

Vous avez peut-être besoin d'une réponse en temps réel.

Quels sont vos seuils pour la vitesse d'exécution de la tâche ?

Vous pouvez également examiner les exigences en matière de RAM.

Il ne s'agit donc pas seulement de la RAM de l'appareil, mais de la RAM de l'appareil, de la part que vous pouvez utiliser, ainsi que des autres applications et outils que vous devrez également exécuter sur ce matériel.

Pouvez-vous utiliser 50 % de la RAM ou seulement 10 % ?

Vous obtenez ainsi ce score d'aptitude final.

S'il est vert, cela signifie que la configuration est prête.

S'il est orange, jaune ou rouge, cela signifie que vous devez peut-être modifier la configuration.

Vous avez peut-être besoin d'un accélérateur plus rapide pour réduire la latence, ou d'un modèle plus grand et plus performant.

Je vous suggère donc d'y jeter un œil.

Nous proposons actuellement une version preview et nous aimerions savoir si vous trouvez cet outil utile.

Zoe vous expliquera plus en détail comment nous avons configuré certaines des évaluations, mais je vais maintenant laisser la parole à Jose, qui va vous montrer un moyen très rapide de commencer à utiliser Gemma 4.

Merci, Ian.

Donc, oui, le moyen le plus rapide d'essayer Gemma 4 aujourd'hui est probablement d'utiliser Android Studio.

Je vais vous montrer comment.

Passons à l'ordinateur portable, s'il vous plaît.

Voilà.

Si je vais sur la page des fournisseurs de modèles dans les paramètres et que je sélectionne Gemma, vous pouvez voir clairement la taille de chaque modèle.

Il me suffit de télécharger les modèles sur mon disque dur.

Cela ouvre ou démarre un serveur llama.cpp, qui est correctement configuré pour vous dès le départ.

Mais vous pouvez aussi utiliser votre propre serveur llama.cpp, Ollama ou LM Studio, comme vous voulez.

Pour cela, il vous suffit d'ajouter un fournisseur local.

De plus, il est tout à fait logique d'utiliser de petits modèles via un fournisseur distant.

Vous pouvez donc en ajouter un ici. Tant qu'il est compatible avec OpenAI ou Anthropic, vous pouvez vous y connecter.

Voyons voir.

Pour sélectionner un modèle dans Android Studio, vous devez utiliser ce menu déroulant.

J'ai sélectionné Gemma 4 26B et je peux demander : "Qu'est-ce qu'un ViewModel ?"

OK.

Il est donc très important de se rappeler que, chaque fois que vous changez de modèle, l'intégralité de la conversation est renvoyée au nouveau modèle depuis le début.

Donc, si vous générez une très longue conversation avec un modèle et que vous souhaitez passer à un autre, vous devriez probablement démarrer une nouvelle conversation, la compacter ou autre.

Revenons maintenant aux diapositives et à Zoé pour découvrir les différents workflows que vous pouvez exécuter avec de petits modèles.

Merci beaucoup, Jose, et merci, Ian, pour la présentation des modèles Gemma et pour nous avoir dit si nous y sommes déjà ou non.

Nous avons vu les types de modèles disponibles et leurs spécifications. Il s'agit maintenant de comprendre les types de tâches que vous pouvez leur confier.

Le premier type de tâches que vous effectuez probablement déjà concerne les workflows de codage, comme le débogage ou le dépannage, ou encore une tâche que tout le monde, ou du moins moi, regrettera de ne plus faire manuellement, à savoir l'augmentation de la couverture des tests.

Vous me suivez ?

Ce sont des choses que tout le monde fait déjà, probablement sans s'en rendre compte.

Mais je voudrais vous encourager à aller au-delà de ça.

Sachant que les petits modèles peuvent être à pondération ouverte et s'exécuter localement, qu'est-ce qui pourrait vous faire gagner du temps ?

Vous me suivez ?

Nous parlons de ne pas utiliser la fusée, alors pourquoi utilisons-nous un cerveau pour cela ?

Si nous pouvions aller au-delà, que pourraient faire les petits modèles ?

Dans quels workflows pourriez-vous les intégrer pour vous faciliter la vie et vous libérer du temps pour faire des choses que vous aimeriez peut-être faire plus souvent ?

Par exemple, vous pouvez vous assurer que votre documentation est toujours à jour par rapport aux modifications que vous avez apportées, ou que vous disposez de tests de régression automatiques qui font partie d'un hook de pré-commit, ou même que le contexte que votre agent reçoit dans le cadre de vos workflows est optimisé pour lui et qu'il fonctionne encore plus rapidement.

Voici quelques exemples.

En fin de compte, les possibilités sont infinies, ou plutôt limitées par l'architecture, et il existe de nombreuses façons d'implémenter cette solution.

Mais même avec les spécifications, les outils et les workflows, vous ne savez toujours pas par où commencer ?

C'est là que les benchmarks entrent en jeu.

Et, comme l'a dit Ian, un classement générique, en particulier pour Python, ne vous dira pas grand-chose sur l'utilité d'un petit modèle pour vos workflows Android.

De la même manière qu'une perceuse pour cloison sèche ne vous en dira pas beaucoup sur une perceuse pour béton.

Mais vous devriez investir dans vos propres évaluations.

Vous devez investir dans le test de votre propre architecture, mais avant cela, vous ne voudrez peut-être pas y consacrer toutes vos ressources.

Cela prend du temps, de l'argent et des efforts. Par conséquent, l'examen des benchmarks accessibles au public peut vous donner une idée et une liste restreinte avant de décider d'investir dans vos propres évaluations.

Trois éléments sont à prendre en compte lorsque vous évaluez le benchmark, n'est-ce pas ?

C'est un peu méta, mais en gros, la première chose à faire est de déterminer le type de tâche que ce modèle effectue.

Le niveau de spécification.

Ressemble-t-il au type de tâche que vous lui confierez ?

Le second serait la portée de la tâche.

S'agit-il de rédiger de la documentation, de résoudre une demande d'extraction ou d'effectuer une tâche qui ressemble à votre travail ?

Enfin, la complexité du système est-elle similaire à celle que vous allez fournir ?

C'est là que nous pouvons voir pourquoi un benchmark Python ne sera pas très représentatif d'Android.

C'est pourquoi nous avons créé Android Bench, un benchmark qui capture l'écosystème Android et le travail sur Android.

La première version comporte 100 tâches Android de la taille d'une demande d'extraction. Vous pouvez l'exécuter vous-même dès aujourd'hui via Harbor pour vérifier n'importe quelle combinaison d'agent, de modèle et de compétence.

Nous lançons la version 2.0 avec des tâches de longue durée plus complexes pour comprendre les capacités des modèles de frontière à effectuer des tâches comme celles que vous leur confiez aujourd'hui.

Je vais maintenant laisser la parole à Jose, qui va vous présenter les résultats que nous avons obtenus et vous expliquer comment optimiser l'utilisation de petits modèles.

D'accord, merci, Zoe.

Voyons maintenant les tâches qu'un petit modèle peut résoudre et celles où il commence à rencontrer des difficultés.

Définissons arbitrairement quatre catégories de tâches : petites, moyennes, grandes et à long horizon.

Les tâches à long horizon sont des tâches qui peuvent prendre des jours ou des semaines à un humain.

Par exemple, une migration ou une refactorisation importante. Et attention, spoiler : vous ne pouvez pas faire cela avec un petit modèle.

Du moins, pas en une seule fois.

Nous en reparlerons plus tard.

D'accord, de petites tâches.

Il s'agit de jobs qui nécessitent de lire et d'écrire un ou deux fichiers, et qui ne nécessitent pas beaucoup de connaissances.

Par exemple, les petits modèles sont plutôt bons pour Compose, du moins pour les bases de Compose.

Par exemple, il doit y avoir 8 dp entre les éléments, ou il faut utiliser un thème au lieu de couleurs codées en dur, ou encore extraire des chaînes.

Un petit modèle peut facilement les gérer.

Cependant, celui-ci couvre un sujet plus avancé, mais la tâche reste simple.

@Composable
 fun AnimatedDrawer() {
   val offsetX = remember { Animatable(0f) }
-  Box(modifier = Modifier.offset(x = offsetX.value.dp)) {}
+  Box(modifier = Modifier.graphicsLayer { translationX = offsetX.value }) {}
 }

La difficulté, dans ce cas, concerne le champ d'application, et non les connaissances.

Le prompt nous indique donc quel composable optimiser et quel est le problème : il se recompose à chaque frame.

Cela facilite donc la tâche, même pour un petit modèle comme Gemma 4.

Dans ce cas, cela a pris trois minutes et il s'agit d'une modification d'une seule ligne.

Très bien.

Je pense que nous avons une idée assez précise de ce qu'est un petit modèle.

Voyons ce qu'est une petite tâche.

Examinons les tâches de taille moyenne.

Les petits modèles devraient pouvoir effectuer la plupart d'entre elles.

Dans cette tâche, l'user-agent est manquant dans une requête de l'application Pocket Casts, et il y a également une erreur dans la logique de nouvelle tentative.

Cette tâche est un peu plus difficile, car nous demandons deux choses à la fois, et il n'y a aucune indication sur l'emplacement de ces éléments dans la base de code.

Mais c'est passé.

Cela a pris 10 minutes.

Il a modifié trois fichiers.

Et, au passage, cela a coûté 6 centimes via OpenRouter.

Examinons maintenant une tâche qui a échoué à partir du même ensemble de données.

Voici un exemple de Now in Android avec un rapport ou un prompt assez complet, mais qui ne mentionne pas de nom de classe ni de fichier. L'agent doit donc faire plus d'efforts pour comprendre l'architecture de l'application, la couche de données, le mécanisme de synchronisation, etc. Dans ce cas, l'exécution a échoué.

Tout a été implémenté presque correctement, mais il a simplement supposé que la valeur de la synchronisation initiale serait -1, alors qu'elle est en réalité de 0.

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

Et voilà !

Ce bug aurait été détecté si l'agent avait simplement exécuté les tests unitaires existants.

Cela montre que les modèles plus petits ont généralement tendance à s'arrêter un peu plus tôt que les modèles de pointe.

Nous avons simplement demandé à l'agent de résoudre le problème, pas de le vérifier.

Nous devrions peut-être modifier la tâche pour qu'elle contienne une étape de validation.

Nous en parlerons également dans un instant.

Parlons maintenant des tâches volumineuses.

Environ la moitié des tâches importantes, dans cette définition, sont réussies à chaque fois.

Certaines des requêtes qui échouent sont en fait trop longues et complexes pour un petit modèle. Il n'y a pas grand-chose à faire dans ce cas.

Mais pour d'autres, quand on regarde ce qui s'est réellement passé, on se rend compte que le modèle était à 90 % de la réalité.

Choisissons-en un.

J'ai choisi celui-ci, car il est instable.

Il réussit environ la moitié du temps.

Je considère donc que nous sommes à la limite de ce qu'un petit modèle peut faire.

Ou, du moins, un modèle d'avril.

Il s'agit de l'analyse d'URL incorrectes dans la bibliothèque Coil.

Comme vous pouvez le constater, la description de la demande d'extraction est assez complète, ce qui est une bonne chose, mais elle ne répond pas à une exigence.

Voyons cela rapidement.

Toutes les exécutions ont vérifié les encodages d'URL et les erreurs standards, mais seulement la moitié d'entre elles ont ajouté des tests pour les caractères mal encodés, d'où ce scénario de test.

Les autres ont échoué à l'évaluation.

Toutes les exécutions sont donc presque parfaites, mais cela montre une fois de plus que les petits modèles ne vont pas toujours jusqu'au bout.

Ils suivent les instructions, mais n'essaient pas de vous impressionner comme le font les modèles de frontière.

Vous savez comment définir l'effort dans un agent de nos jours ?

Sachez simplement qu'il est défini sur une valeur trop faible lorsque vous utilisez un petit modèle.

Définissons donc les tâches complexes comme celles qui peuvent être effectuées par de petits modèles environ 50 % du temps, ce que Gemma 4 31B peut atteindre avec l'ensemble de données Android Bench v1, dont Zoe a parlé précédemment.

Avant de parler des tâches à long horizon, pouvons-nous faire quelque chose pour aider les petits modèles à les accomplir ?

Absolument, et ces choses ne demandent aucun effort.

Tout d'abord, si vous utilisez un modèle comme Gemma 4 en local, comme l'a mentionné Ian, assurez-vous qu'il est correctement configuré.

Par exemple, si vous utilisez Ollama pour diffuser Gemma 4, la fenêtre de contexte par défaut est de 32 000 jetons, alors qu'il en accepte huit fois plus.

Bien sûr, si vous utilisez Gemma 4 via Android Studio, vous n'avez pas besoin de le configurer.

Il est correctement configuré par défaut.

Dans notre ensemble d'évaluations, l'activation du contexte complet a permis de faire passer les résultats de 26 % à 53 %.

Ensuite, utilisez Android CLI, l'outil de CLI Android, en particulier pour rechercher de la documentation.

Ce n'est pas toujours le cas, car les modèles sont plutôt bons pour les bases, mais chaque fois que vous utilisez une API nouvelle ou de niche, il est essentiel de disposer de la documentation.

D'après notre expérience, c'est bien mieux que d'utiliser des outils de recherche sur le Web.

Ensuite, ajoutez des indices de validation.

On en a parlé.

Indiquez au modèle comment exécuter les tests, quels types de tests sont disponibles, comment gérer les émulateurs, etc. Vous pouvez le faire dans un fichier AGENTS.md, ce qui rendra les instructions disponibles pour tous les agents, mais c'est une bonne chose.

Vous devriez l'avoir.

Mais attention aux fichiers AGENTS.md très longs, car si vous essayez différents agents, vous verrez que certains d'entre eux ont des prompts système et des descriptions d'outils très volumineux, et qu'ils semblent dégrader les performances des petits modèles.

Nous avons essayé d'exécuter ces benchmarks avec OpenCode, et ses performances étaient bien inférieures à celles de pi, probablement parce qu'il utilise des descriptions d'outils et des requêtes système plus volumineuses.

Ensuite, ajoutez des compétences, mais supprimez-en également.

Les petits modèles peuvent avoir besoin d'un coup de pouce lorsqu'ils utilisent des API nouvelles et de niche, mais il est préférable de ne pas remplir leur contexte avec des compétences Compose générales, par exemple.

Qu'en est-il des tâches à long horizon ?

Il s'agit de tâches qui s'étendent sur des dizaines de fichiers, nécessitent des décisions architecturales importantes et sont normalement gérées par un modèle de raisonnement qui crée un plan et lance un essaim de sous-agents qui exécutent les différentes tâches.

Par exemple, migrer une application entière de XML vers Compose, créer une application complexe de zéro ou convertir des applications multiplates-formes en applications Android natives sont des tâches à long horizon.

Si nous examinons les résultats d'Android Bench V2, qui se concentre exclusivement sur les tâches à long horizon, nous constatons que les modèles de frontière obtiennent un score de 3 à 40 %.

On peut donc dire que les petits modèles ne sont pas à la hauteur.

Cependant, il serait bien plus efficace en termes de jetons et de crédits de faire passer l'analyse initiale par un modèle de frontière, puis de confier les tâches plus simples à des modèles plus petits.

Voyons comment procéder.

Revenons à Zoé.

Merci beaucoup, Jose.

Nous allons aborder la cascade, mais avant de vous montrer quelques méthodes ou d'approfondir le sujet, je voudrais prendre un peu de recul et vous montrer d'autres façons dont l'orchestration de différents modèles peut vous aider.

L'orchestration peut, par exemple, vous aider à ne jamais être bloqué.

Ainsi, si un fournisseur est indisponible, si vous atteignez une limite de débit d'API, ou si vous êtes dans un avion ou un train, comme le disait Ian, vous pouvez configurer un modèle de remplacement et faire en sorte que, que ce soit en ligne ou localement, vous puissiez continuer si un problème survient.

L'orchestration vous permet également d'obtenir de meilleures réponses.

Par exemple, vous pouvez faire travailler un petit modèle seul et appeler un conseiller chaque fois qu'il a besoin d'un peu d'aide.

Vous pouvez également configurer un conseil dans lequel différents types de modèles, ou différents modèles, exécutent tous la même tâche en même temps. Vous pouvez ensuite évaluer les différentes réponses et l'impact des pondérations et des biais de chaque modèle sur le résultat.

Vous pouvez également utiliser un modèle distinct pour les tests.

C'est un peu comme une évaluation par les pairs.

Et vous pouvez le voir à travers cela.

Enfin, l'orchestration peut vous aider à optimiser les coûts grâce à un système comme cette cascade.

En gros, vous pouvez le configurer manuellement. Vous pouvez donc définir un modèle pour la planification, un autre pour l'exécution et un autre pour les tests.

Il existe plusieurs façons de procéder, soit dans le cloud, soit en configurant un proxy LiteLLM pour le faire localement.

Vous pouvez aussi utiliser un classificateur pour l'acheminer automatiquement vers le bon type de modèle en fonction de la requête. C'est l'idée du proxy dont Ian a parlé, mais de manière automatique.

Pour conclure, revenons à la question que Jose a posée au début de la présentation : quelle est la différence de qualité et de précision entre les petits modèles et les modèles de frontière ?

Comme pour beaucoup de choses en informatique, la réponse est : "ça dépend".

Cependant, j'aimerais vous rappeler que vous pouvez concevoir ce genre de choses.

Vous pouvez faire la différence en fonction de la façon dont vous le configurez et dont vous jouez avec les pièces.

La première étape consiste à choisir le bon outil.

Il existe plusieurs types d'outils.

Apprenez à les connaître, explorez-les, d'accord ?

Ensuite, découvrez pour quels emplois ils sont adaptés ou même quels emplois ils pourraient exercer.

La deuxième consiste à s'assurer d'ajuster le champ d'application du modèle pour qu'il puisse effectuer la tâche.

Par exemple, les instructions pour la tâche, la fourniture du contexte approprié pour la tâche (et uniquement du contexte approprié) et les moyens de vérifier son propre travail.

Ensuite, bien sûr, vous devez tester l'ensemble de la configuration, et pas seulement le modèle de manière isolée, car cela fera une différence. Les résultats que vous obtenez pourraient être ajustés si vous les configurez avec, disons, une configuration d'éléments différente.

Enfin, vous devez configurer ou créer vos propres évaluations.

Enfin, vous pouvez orchestrer le vélo et la fusée pour ne jamais avoir à choisir entre l'un ou l'autre et dépenser efficacement.

Mais surtout, vous pouvez continuer à explorer, à créer et à vous amuser, n'est-ce pas ?

Vous pouvez commencer dès aujourd'hui en établissant une liste de modèles à l'aide d'Android Bench et des résultats que vous obtenez, ou en commençant avec Gemma 4 sur Android Studio.

Merci beaucoup.