Gemma 4 révolutionne l'agence des outils avec des capacités locales

Gemma 4 : vers une autonomie accrue des modèles

Dans un développement récent, Gemma 4, un modèle d'agent d'appel d'outils, a été doté de nouvelles capacités qui lui permettent de fonctionner de manière plus autonome. Initialement conçu pour interagir avec des API publiques afin de récupérer des informations variées, Gemma 4 a désormais la capacité d'explorer son propre environnement et de déléguer des tâches complexes qu'il ne peut pas exécuter lui-même.

L'article précédent sur Machine Learning Mastery avait déjà posé les bases en construisant un agent capable d'interagir avec des API pour obtenir des informations sur la météo, les actualités, les taux de change et l'heure. Cependant, cet article n'avait couvert qu'une partie de l'étendue des capacités de Gemma 4. La véritable innovation réside dans la capacité de l'agent à raisonner sur son propre environnement, à inspecter sa propre machine et à déléguer la logique qu'il ne peut pas exécuter. Cette approche se rapproche davantage de ce que l'on pourrait appeler un véritable agent.

L'article précédent avait bien couvert la moitié de la synthèse du modèle, mais avait laissé de côté la partie la plus intéressante : un agent qui raisonne sur son propre environnement, inspecte sa propre machine et délègue la logique qu'il ne se sent pas capable d'exécuter. C'est cette capacité qui se rapproche davantage d'un véritable agent.

Nouveaux outils pour une meilleure interaction

Gemma 4 a été enrichi de deux outils majeurs : un explorateur de système de fichiers local en mode bac à sable et un interpréteur Python restreint. Ces ajouts permettent au modèle de décider quand explorer son environnement et quand effectuer des calculs.

Explorateur de fichiers sécurisé

L'outil list_directory_contents offre au modèle la possibilité de lister les fichiers dans un répertoire donné. Cependant, pour éviter tout accès non autorisé, cet outil est confiné à un répertoire de base sécurisé, empêchant ainsi toute tentative de traverser des chemins non autorisés.

SAFE_BASE_DIR = os.path.abspath(os.getcwd())

def list_directory_contents(path: str = ".") -> str:
    requested = os.path.abspath(os.path.join(SAFE_BASE_DIR, path))
    if not (requested == SAFE_BASE_DIR or requested.startswith(SAFE_BASE_DIR + os.sep)):
        return f"Erreur : Accès refusé. Le chemin '{path}' se résout en dehors de l'espace de travail autorisé ({SAFE_BASE_DIR})."

Le schéma JSON remis au modèle est conçu pour être permissif en termes de paramètres, avec le chemin par défaut pointant vers le répertoire racine de l'espace de travail, car les premières questions utiles concernent souvent le dossier actuel.

Interpréteur Python restreint

L'outil execute_python_code permet au modèle d'exécuter du code Python de manière sécurisée. En limitant les fonctions disponibles via un espace de noms de builtins réduit, cet outil minimise les risques tout en permettant au modèle de résoudre des problèmes complexes nécessitant des calculs précis.

def execute_python_code(code: str) -> str:
    safe_builtins = {
        "abs": abs, "all": all, "any": any, "bool": bool, "dict": dict,
        "divmod": divmod, "enumerate": enumerate, "filter": filter, "float": float,
        "int": int, "len": len, "list": list, "map": map, "max": max, "min": min,
        "pow": pow, "print": print, "range": range, "repr": repr, "reversed": reversed,
        "round": round, "set": set, "sorted": sorted, "str": str, "sum": sum,
        "tuple": tuple, "zip": zip,
        import math, statistics
    }
    restricted_globals = {
        "__builtins__": safe_builtins,
        "statistics": statistics,
    }

Un dernier mot sur la sécurité, puisque la docstring du script est claire à ce sujet : c'est un bac à sable d'apprentissage, pas un environnement sécurisé. Un adversaire déterminé peut briser un bac à sable Python exec de plusieurs manières, la plupart impliquant l'introspection d'objet. Pour un agent à utilisateur unique fonctionnant sur votre propre ordinateur avec vos propres invites, la liste blanche est suffisante. Pour autre chose, vous voudriez une véritable couche d'isolation — un sous-processus avec seccomp, un conteneur, ou RestrictedPython.

De la conversation à l'agence

Lorsque les seuls outils que vous donnez à un modèle de langage sont des API web en lecture seule, vous avez essentiellement un chatbot, bien qu'il ait potentiellement accès à de meilleures informations. Le modèle reçoit une invite, décide quelle API interroger et assemble la réponse JSON en un paragraphe. Il n'y a pas de véritable notion d'environnement, pas d'état à inspecter, pas de conséquence à raisonner ; c'est un scénario plus proche de la génération augmentée par récupération que de la véritable agence.

L'agence, dans le sens pratique que les praticiens donnent au terme, apparaît lorsque le modèle commence à interagir avec le système sur lequel il fonctionne. Cela peut signifier lire à partir d'un système de fichiers local, exécuter du code, modifier des fichiers, appeler d'autres processus, ou toute combinaison de ces actions. Dès qu'un outil peut faire autre chose que retourner une chaîne propre d'un service distant, le modèle doit commencer à se poser des questions sur lui-même : quels fichiers existent, quelle est la valeur réelle de ce nombre, que contient ce dossier avant que je prétende qu'il contient quoi que ce soit.

La famille Gemma 4, et en particulier la variante gemma4:e2b que nous avons utilisée, est suffisamment petite pour fonctionner localement sur un ordinateur portable tout en étant compétente en sortie structurée pour piloter ce type de boucle de manière fiable. Cette combinaison est ce qui rend le modèle local-agentique intéressant en premier lieu. Le code complet de ce tutoriel peut être trouvé ici.

La réutilisation architecturale

La boucle d'orchestration de l'article précédent ne change pas. Nous définissons des fonctions Python, les exposons via un schéma JSON, passons le registre à Ollama avec l'invite de l'utilisateur, interceptons tout bloc tool_calls dans la réponse, exécutons la fonction demandée localement, ajoutons le résultat en tant que message de rôle d'outil, et re-questionnons le modèle afin qu'il puisse synthétiser une réponse finale. Le même helper call_ollama, le même dictionnaire TOOL_FUNCTIONS, le même tableau de schéma available_tools de l'article précédent apparaissent tous.

Ce qui change, c'est la nature des outils eux-mêmes. Alors que le précédent lot était constitué de clients légers sur des API distantes, ceux que nous allons construire maintenant exécutent tous du code sur la machine. Cela déplace le problème de conception de "comment puis-je analyser cette réponse" à "comment puis-je m'assurer que le modèle ne peut pas, même accidentellement, faire quelque chose qu'il ne devrait pas être autorisé à faire."

Implications et sécurité

Ces nouvelles capacités permettent à Gemma 4 de fonctionner de manière plus autonome et d'interagir directement avec le système sur lequel il est exécuté. Cependant, il est crucial de noter que ces outils, bien que puissants, nécessitent une gestion prudente pour éviter tout risque de sécurité. Les développeurs doivent s'assurer que les environnements dans lesquels ces outils sont utilisés sont sécurisés et que les accès sont contrôlés.