Comment faire évoluer les agents d'IA en séparant la logique et la recherche pour de meilleures performances

La séparation de la logique et de l'inférence améliore Évolutivité des agents d'IA en dissociant les flux de travail principaux des stratégies d'exécution.

La transition des prototypes d'IA générative aux agents de qualité industrielle introduit un obstacle d'ingénierie spécifique : fiabilitéLes LLM sont par nature stochastiques. Une requête qui fonctionne une fois peut échouer à la deuxième tentative. Pour pallier ce problème, les équipes de développement encapsulent souvent la logique métier principale dans des boucles de gestion d'erreurs complexes, des tentatives de nouvelle exécution et des chemins d'accès conditionnels.

Cette approche engendre un problème de maintenance. Le code définissant les actions d'un agent se retrouve inextricablement mêlé au code gérant l'imprévisibilité du modèle. Un nouveau cadre de travail a été proposé par des chercheurs de Asari IA, MIT CSAIL, et Caltech suggère qu'une norme architecturale différente est nécessaire pour l'échelle flux de travail agents dans l'entreprise.

La recherche introduit un modèle de programmation appelé Non-déterminisme angélique probabiliste (PAN) et une implémentation Python nommée ENGLOBERCette méthode permet aux développeurs de définir le fonctionnement nominal du flux de travail d'un agent tout en confiant les stratégies d'inférence (comme la recherche par faisceau ou le retour arrière) à un moteur d'exécution distinct. Cette séparation des responsabilités offre une voie potentielle pour réduire la dette technique tout en améliorant les performances des tâches automatisées.

Le problème d'enchevêtrement dans la conception d'agents

Les approches actuelles de la programmation d'agents confondent souvent deux aspects de conception distincts. Le premier est le logique de flux de travail de base, ou la séquence d'étapes nécessaires à l'accomplissement d'une tâche commerciale. La seconde est la stratégie d'inférence au moment de l'inférence, qui détermine comment le système gère l'incertitude, par exemple en générant plusieurs brouillons ou en vérifiant les résultats par rapport à une grille d'évaluation.

Lorsque ces éléments sont combinés, le code résultant devient fragile. La mise en œuvre d'une stratégie comme l'échantillonnage « meilleur parmi N » nécessite d'encapsuler l'intégralité de la fonction de l'agent dans une boucle. Le passage à une stratégie plus complexe, telle que la recherche arborescente ou le raffinement, requiert généralement une refonte structurelle complète du code de l'agent.

Les chercheurs affirment que cette intrication limite l'expérimentation. Si une équipe de développement souhaite passer d'un échantillonnage simple à une stratégie de recherche par faisceau pour améliorer la précision, elle doit souvent repenser le flux de contrôle de l'application.

Ce coût élevé de l'expérimentation fait que les équipes se contentent souvent de stratégies de fiabilité sous-optimales pour éviter les frais généraux d'ingénierie.

Découpler la logique de la recherche pour améliorer l'évolutivité des agents d'IA

Le framework ENCOMPASS remédie à cela en permettant aux programmeurs de marquer « zones à risque » dans leur code en utilisant une primitive appelée point de branchement().

Ces marqueurs indiquent l'emplacement d'un appel LLM et les points de divergence possibles de l'exécution. Le développeur écrit le code comme si l'opération allait réussir. À l'exécution, le framework interprète ces points de branchement pour construire un arbre de recherche des chemins d'exécution possibles.

Cette architecture permet ce que les auteurs appellent agents « programme-contrôleur »Contrairement aux systèmes « LLM contrôlés », où le modèle détermine l'intégralité de la séquence d'opérations, les agents contrôlés par programme opèrent au sein d'un flux de travail défini par le code. Le LLM n'est sollicité que pour exécuter des sous-tâches spécifiques. Cette structure est généralement privilégiée en entreprise pour sa prévisibilité et sa traçabilité accrues par rapport aux agents entièrement autonomes.

En traitant les stratégies d'inférence comme une recherche sur les chemins d'exécution, le cadre permet aux développeurs d'appliquer différents algorithmes, tels que : recherche en profondeur d'abord, recherche par faisceau, ou Recherche arborescente Monte Carlo – sans modifier la logique métier sous-jacente.

Impact sur la migration des systèmes existants et la traduction du code

L'utilité de cette approche est manifeste dans les flux de travail complexes tels que la migration de code existant. Les chercheurs ont appliqué ce cadre à un Agent de traduction Java vers PythonLe processus consistait à traduire un référentiel fichier par fichier, à générer des entrées et à valider la sortie par exécution.

Dans une implémentation Python standard, l'ajout d'une logique de recherche à ce flux de travail nécessitait la définition d'une machine à états. Ce processus masquait la logique métier et rendait le code difficile à lire et à analyser. La mise en œuvre de la recherche par faisceau exigeait du programmeur qu'il décompose le flux de travail en étapes individuelles et gère explicitement l'état à travers un dictionnaire de variables.

En utilisant le cadre proposé pour améliorer l'évolutivité des agents d'IA, l'équipe a mis en œuvre les mêmes stratégies de recherche en insérant point de branchement() Les instructions précédant les appels LLM étaient conservées. La logique principale restait linéaire et lisible. L'étude a démontré que l'application de la recherche par faisceau, tant au niveau du fichier que de la méthode, surpassait les stratégies d'échantillonnage plus simples.

Les données indiquent que la prise en compte séparée de ces problématiques permet d'obtenir de meilleures lois d'échelle. Les performances s'améliorent linéairement avec le logarithme du coût d'inférence.

La stratégie la plus efficace trouvée – recherche de faisceau à grain fin – était également celle qui aurait été la plus complexe à mettre en œuvre en utilisant les méthodes de codage traditionnelles.

Efficacité des coûts et mise à l'échelle des performances

La maîtrise du coût de l'inférence est une préoccupation majeure pour les responsables des données en charge du compte de résultat des projets d'IA. La recherche démontre que des algorithmes de recherche sophistiqués peuvent donner de bons résultats. de meilleurs résultats à moindre coût par rapport à une simple augmentation du nombre de boucles de rétroaction.

Dans une étude de cas portant sur le modèle d'agent « Réflexion » (où un LLM critique sa propre production), les chercheurs ont comparé l'augmentation du nombre d'itérations d'amélioration à l'utilisation d'un algorithme de recherche du meilleur d'abord. L'approche basée sur la recherche a obtenu des performances comparables à la méthode d'amélioration standard, mais à un coût inférieur. coût réduit par tâche.

Ce résultat suggère que le choix de la stratégie d'inférence est un facteur d'optimisation des coûts. En externalisant cette stratégie, les équipes peuvent ajuster le compromis entre le budget de calcul et la précision requise sans réécrire l'application. Un outil interne à faible enjeu pourrait utiliser une stratégie de recherche économique et gourmande en ressources, tandis qu'une application destinée aux clients pourrait privilégier une recherche plus coûteuse et exhaustive, le tout s'exécutant sur la même base de code.

L'adoption de cette architecture exige une évolution de la façon dont les équipes de développement conçoivent la construction des agents. Le framework est conçu pour fonctionner en conjonction avec des bibliothèques existantes telles que… Chaîne de LangIl ne les remplace pas. Il se situe à un niveau différent de la pile, gérant le flux de contrôle plutôt que l'ingénierie rapide ou les interfaces d'outils.

Défis et considérations d'ingénierie

Cette approche n'est toutefois pas sans défis d'ingénierie. Si le cadre réduit le code nécessaire à la mise en œuvre de la recherche, il n'automatise pas la conception de l'agent lui-même. Les ingénieurs doivent toujours identifier les emplacements pertinents des points de branchement et définir des indicateurs de succès vérifiables.

L'efficacité de toute fonction de recherche repose sur la capacité du système à score un chemin spécifiqueDans l'exemple de la traduction automatique, le système pourrait exécuter des tests unitaires pour vérifier l'exactitude du code. Dans des domaines plus subjectifs, comme la synthèse ou la création de contenu, la définition d'une fonction d'évaluation fiable demeure un goulot d'étranglement.

De plus, le modèle repose sur la possibilité de copier l'état du programme aux points de branchement. Bien que le framework gère la portée des variables et la gestion de la mémoire, les développeurs doivent veiller à ce que les effets de bord externes — tels que les écritures dans la base de données ou les appels d'API — soient correctement gérés afin d'éviter les actions redondantes lors du processus de recherche.

Implications pour l'évolutivité des agents d'IA

Le changement représenté par PAN et ENCOMPASS s'aligne sur des principes plus généraux d'ingénierie logicielle. modularitéÀ mesure que les flux de travail automatisés deviennent essentiels aux opérations, leur maintenance exigera la même rigueur que celle appliquée aux logiciels traditionnels.

L'intégration directe de la logique probabiliste dans les applications métier crée dette techniqueCela complique les tests, les audits et les mises à jour des systèmes. Dissocier la stratégie d'inférence de la logique du flux de travail permet d'optimiser indépendamment les deux.

Cette séparation facilite également une meilleure gouvernance. Si une stratégie de recherche spécifique produit des résultats aberrants ou erronés, elle peut être ajustée globalement sans avoir à évaluer le code source de chaque agent. Elle simplifie le versionnage des comportements de l'IA, une exigence pour les secteurs réglementés où le « comment » d'une décision est aussi important que le résultat.

Les recherches indiquent que, à mesure que la puissance de calcul au moment de l'inférence augmente, la complexité de la gestion des chemins d'exécution s'accroît. Les architectures d'entreprise qui isolent cette complexité se révéleront probablement plus robustes que celles qui la laissent imprégner la couche applicative.