Les modèles plus intelligents réduiront-ils l’importance des outils d’agent ou en feront-ils une priorité encore plus grande ?

Qu’est-ce que le harness, et qu’est-ce qu’il n’est pas

Le point important est qu’un framework n’a pas pour but de rendre le modèle plus intelligent. Son objectif est de créer un système qui soit plus performant, plus fiable et plus sûr dans son ensemble. Prenons l’exemple du texte vers SQL : un modèle sait déjà peut-être comment écrire une requête. Le framework lui fournit le schéma, lui permet d’examiner les métadonnées des tables, exécute la requête, détecte les erreurs, renvoie le résultat ou le message d’erreur, déclenche une tentative de réexécution si nécessaire et aide à juger si la réponse finale est suffisamment bonne. Le modèle raisonne ; le framework fournit le mécanisme qui entoure ce processus de raisonnement. Ce mécanisme devient essentiel dès que le modèle fait plus que produire du texte.

Pour en savoir plus sur la répartition des responsabilités entre le modèle et l’outil d’accompagnement au sein d’un seul agent, consultez d’où provient réellement un comportement fiable de l’IA. L’objectif ici est d’examiner comment cette répartition évolue avec le temps.

Le cas pour un outil d’accompagnement plus léger

Il est tout à fait logique de penser que des modèles plus performants ont besoin de moins d’éléments de soutien. Imaginez un modèle capable d’accomplir de manière fiable tout ce qui suit :

• Suivre des instructions complexes.
• Conserver ce qui est pertinent.
• Choisir l’outil approprié.
• Planifier des tâches composées de plusieurs étapes.
• S’adapter en cas d’échec.
• Vérifier ses propres résultats.
• Reconnaître lorsqu’il est incertain.
• Gérer l’état au cours de travaux prolongés.

Avec un tel modèle, une grande partie de l’orchestration actuelle semble redondante. Un raisonnement plus puissant réduit le besoin de couches de planification explicites. Une utilisation plus efficace des outils natifs diminue la nécessité d’une logique manuelle de sélection des outils. Une meilleure gestion des contextes longs réduit le besoin de systèmes de mémoire complexes. Une auto-évaluation fiable diminue le besoin de pipelines de validation externes.

Cela pourrait vraiment se produire, et c’est déjà le cas dans certains domaines : les astuces liées aux prompts et les solutions de parsing qui étaient essentielles pour les modèles précédents sont souvent inutiles aujourd’hui. Il est plausible que les meilleures solutions de l’avenir soient bien plus légères que celles développées actuellement. Cependant, ce n’est qu’une partie de l’image.

Les capacités élargissent le champ d’action

Lorsqu’un modèle devient beaucoup plus performant, les équipes n’utilisent rarement ces capacités simplement pour effectuer le même travail à moindre coût. Elles les orientent vers des problèmes plus difficiles.

• Un modèle capable de résumer un document sera bientôt sollicité pour analyser cent documents.
• Un modèle capable d’écrire une seule requête SQL sera chargé d’étudier une question métier impliquant plusieurs systèmes.
• Un modèle capable d’appeler une seule API se verra confier un environnement logiciel complet.

L’étendue des tâches augmente avec les capacités du modèle, ce qui modifie la fonction du système qui le gère. La question passe de savoir si le modèle peut répondre à une demande à savoir si le système permet au modèle d’atteindre un objectif de manière sûre et fiable. Il s’agit là de problèmes d’ingénierie différents : le premier concerne l’intelligence, tandis que le second porte sur le contrôle, la confiance et la responsabilité.

Des agents capables soulèvent des questions sur les systèmes

Supposons qu’un agent de plus en plus performant dispose d’un navigateur, d’une base de données, d’API internes, de fichiers, de la capacité d’exécuter du code, d’outils de messagerie et d’une mémoire à long terme. L’intelligence n’est plus le facteur limitant. Il devient alors nécessaire de répondre à des questions telles que :

• Quelles actions l’agent est-il autorisé à entreprendre ?
• Quelles informations peut-il lire ?
• Quand doit-il demander une autorisation ?
• Que se passe-t-il lorsque un outil échoue ?
• Comment éviter les boucles et les actions redondantes ?
• Comment quelqu’un peut-il reconstituer les raisons d’une décision particulière ?
• Comment évaluer un flux de travail qui dure 30 minutes plutôt que de produire une seule réponse ?
• Que se passe-t-il lorsque le modèle est erroné mais convaincu de sa justesse ?

Aucun de ces problèmes ne peut être résolu par un modèle plus intelligent. Un modèle plus performant risque même d’aggraver le dernier problème, car les erreurs commises avec aisance et assurance sont plus difficiles à détecter. Il s’agit de problèmes systémiques, et c’est là que l’outil d’intégration devient essentiel plutôt que superflu.

De l’orchestration à la conception de l’environnement

De nombreux frameworks d’agents actuels se concentrent sur l’orchestration : décider de ce qui se passe ensuite, quel outil doit être appelé et quoi retourner au modèle. À mesure que les modèles deviennent plus capables de planifier par eux-mêmes, cette logique de séquencement est celle qui a le plus de chances de disparaître. Ce qui reste, et qui se développe, relève davantage de la conception de l’environnement. L’outil d’intégration définit :

• Les outils : avec lesquels l’agent peut interagir.
• Le contexte : les informations qui lui sont présentées.
• L’état : ce qu’il se souvient entre les différentes étapes.
• Les permissions : ce qu’il est autorisé à modifier.

Retour d’information : comment le système sait qu’il y a eu une erreur.

Évaluation : comment le succès est mesuré.

Limites : quand il doit s’arrêter ou transférer le contrôle à une personne.

Dans cette approche, le modèle acquiert de l’autonomie tandis que le cadre de contrôle devient la limite entourant cette autonomie. On cesse d’écrire le parcours suivi par l’agent pour commencer à façonner l’espace dans lequel il se déplace.

La complexité a tendance à changer de place, pas à disparaître

L’ingénierie logicielle présente un schéma familier : lorsque une couche devient plus simple, la complexité se déplace généralement plutôt que de disparaître. Les abstractions cachent la complexité ; elles ne la suppriment pas. Les bases de données gérées n’ont pas éliminé la nécessité de comprendre les index, et les plateformes cloud n’ont pas supprimé la nécessité de planifier la capacité.

Les agents suivront probablement le même chemin. De meilleurs modèles pourraient rendre inutile une partie de la logique d’agent développée manuellement, tout en augmentant simultanément la nécessité d’une évaluation plus rigoureuse, de mesures de sécurité renforcées, d’une meilleure observabilité, de gestion de la mémoire, de contrôle des coûts, d’ingénierie de fiabilité et de soutien pour les tâches à long terme. Ce cadre d’encadrement pourrait devenir moins visible pour le développeur d’applications, peut-être parce que les fournisseurs et les frameworks s’en chargent, tout en devenant plus central dans le fonctionnement du système. Une expérience de développement simplifiée ne signifie pas pour autant une architecture plus simple en dessous.

Moins important à certains égards, plus important à d’autres

La réponse honnête est qu’il ne s’agit ni de l’un ni de l’autre. Le framework perd en importance en tant que moyen de compenser manuellement les modèles faibles. Il gagne en importance en servant de base qui permet aux modèles performants d’agir dans le monde réel sans devenir dangereux, peu fiables ou gaspilleurs. Les frameworks futurs pourraient offrir une orchestration moins rigide ainsi qu’une évaluation, des permissions, un suivi de l’état, des retours d’information, une observabilité et un contrôle environnemental considérablement plus sophistiqués.

Une évolution approximative se présente comme suit :

• Auparavant : le modèle était connecté presque directement à l’application.
• Aujourd’hui : le modèle passe par des prompts, RAG, des outils, des agents et des mécanismes d’évaluation avant d’atteindre l’application.
• Dans le futur : le modèle et le framework forment ensemble un système autonome.

La dernière étape est celle qui compte vraiment. Lorsque l’IA passe de la génération de réponses à l’exécution d’actions, la question clé n’est plus seulement le degré d’intelligence du modèle, mais aussi la qualité de la conception de l’environnement qui l’entoure.

Un test pratique pour votre propre système

Pour déterminer où investir, classez chaque composant de votre système dans l’un des deux groupes suivants :

• Les éléments compensatoires existent parce que le modèle actuel présente des faiblesses dans certains domaines : planificateurs rigides étape par étape, logiques complexes de traitement et de correction des résultats, orientation des outils basée sur des mots-clés, solutions de contournement pour les instructions. Gardez-les simples et faciles à supprimer, et rétestez-les à chaque mise à jour des modèles, car ce sont ceux qui ont le plus de chances de devenir inutiles.

Des composants durables existent parce que la tâche a des conséquences dans le monde réel : permissions et environnements isolés, mécanismes d’approbation, journaux d’audit et traçabilité, limites de coût et de boucles, suites d’évaluation, persistance de l’état. Il convient d’investir correctement dans ces éléments, car un modèle plus performant augmente plutôt que de diminuer leur valeur.

Un indicateur utile consiste à se demander si un composant resterait nécessaire même si le modèle était parfaitement capable de raisonner. Si la réponse est oui, comme c’est le cas pour le contrôle d’accès, l’auditable et la mesure du succès, il fait partie du noyau durable de l’ensemble.

Points clés

• Un ensemble de composants ne rend pas le modèle plus intelligent ; il rend l’ensemble du système plus performant, fiable et sûr.
• Des modèles améliorés réduiront probablement la complexité de l’orchestration et des logiques de contournement, ce qui mérite d’être pris en compte dans la planification.
• Des capacités accrues ouvrent la voie à des projets de plus grande envergure, ce qui soulève des questions concernant les permissions, la gestion des pannes, l’évaluation et la responsabilité auxquelles aucune amélioration du modèle ne répond.
• L’approche évolue d’une exécution étape par étape via des scripts vers la conception d’un environnement complet : outils, contexte, état, permissions, retours d’information, évaluation et limites.
• Anticipez que la complexité se déplacera vers l’infrastructure plutôt que de disparaître, et concevez les éléments durables de votre système en tenant cela à l’esprit.