Au-delà du portable : 4 modèles architecturaux pour les agents IA prêts pour la production

Ceci est une soumission pour le Google AI Agents Writing Challenge : Learning Reflections.

Introduction

L'écart entre un agent « Hello World » exécuté dans un ordinateur portable Jupyter et un système fiable de niveau production n'est pas une étape : c'est un gouffre (et ce n'est pas facile à franchir).

J'ai récemment eu le privilège de participer au cours intensif de 5 jours sur les agents IA avec Google et Kaggle. Après avoir terminé les cours et finalisé le projet de synthèse, j'ai réalisé qu'au-delà des nombreuses choses précieuses que nous avons appréciées dans ce cours (livres blancs très précieux, cahiers soigneusement conçus et panels d'experts exceptionnels lors des sessions en direct), le véritable trésor n'était pas seulement l'apprentissage de la syntaxe ADK : il s'agissait des modèles architecturaux subtilement intégrés dans les leçons.

En tant qu'architecte de systèmes de production depuis plus de 20 ans, y compris des flux de travail multi-agents et des intégrations d'entreprise, j'ai pu constater par moi-même où les agents théoriques s'effondrent sous les contraintes du monde réel.

Nous passons d’une ère de « l’ingénierie rapide » à une « architecture d’agents » où « l’ingénierie contextuelle » est la clé. Comme pour tout autre paradigme architectural émergent, ce changement exige des plans garantissant la fiabilité, l’efficacité et la sécurité éthique. Sans eux, nous risquons d’avoir des agents qui se dégradent silencieusement, violent la vie privée des utilisateurs ou exécutent des actions irréversibles sans surveillance.

S'appuyant sur le cours et sur ma propre expérience en tant qu'architecte IA, j'ai distillé le programme en quatre modèles essentiels qui transforment des prototypes fragiles en systèmes de production robustes :

Les 4 modèles de base

1. Hiérarchie d'évaluation Outside-In : déplacement de l'attention de la réponse finale vers la trajectoire de prise de décision.
2. Architecture de mémoire double couche : équilibrer le contexte de session éphémère avec des connaissances persistantes et consolidées.
3. Interopérabilité axée sur les protocoles : découplage des agents des outils utilisant des protocoles standardisés tels que MCP et A2A.
4. Opérations de longue durée et reprise : gestion de l'état pour les tâches asynchrones et les flux de travail humains dans la boucle.

Tout au long de cette analyse, j'appliquerai un cadre en 6 points fondé sur les principes des Principia Agentica, garantissant que ces modèles respectent la souveraineté humaine, la responsabilité fiduciaire et un contrôle humain significatif.

Le cadre d'analyse

1. Le problème de production : pourquoi les approches naïves échouent à grande échelle.
2. La solution architecturale : le modèle de conception spécifique enseigné dans le cours.
3. Détails de mise en œuvre clés : informations concrètes au niveau du code à partir des blocs-notes ADK.
4. Considérations sur la production : implications de déploiement dans le monde réel (latence, coût, échelle).
5. Connexion à la conception éthique : comment le modèle soutient la souveraineté humaine, la responsabilité fiduciaire ou l'architecture des agents éthiques. J'inclurai un « scénario d'échec » dans lequel j'essaierai d'illustrer ce qui pourrait arriver sans la garantie éthique.
6. Points clés à retenir : un résumé distillé du principe de production de chaque modèle, des conseils de mise en œuvre et de l'ancrage éthique, conçu pour servir de référence rapide aux architectes passant du prototype à la production.

Faisons ça !

Modèle 1 : Hiérarchie d’évaluation de l’extérieur vers l’intérieur (la trajectoire comme vérité)

Dans les logiciels traditionnels, si le résultat est correct, le test réussit. Dans l’IA agentique, une réponse correcte dérivée d’une hallucination ou d’un chemin logique dangereux est une bombe à retardement.

1. Le problème de la production

Les stratégies d'évaluation naïves échouent souvent en production en raison de la nature non déterministe des LLM. Nous sommes confrontés à deux pièges spécifiques :

• Le piège du « Lucky Guess » : imaginez qu'un agent demande « obtenir la météo à Tokyo ». Un mauvais agent pourrait halluciner "Il fait beau à Tokyo" sans appeler l'outil météo. S'il fait beau, un traditionnelaffirmer le résultat == attendules tests réussissent. Cela cache un échec critique de la logique qui se brisera dès que le temps changera.
• L'« échec silencieux » de l'efficacité : un agent peut résoudre une demande d'utilisateur mais prendre 25 étapes pour faire ce qui aurait dû prendre 3. Cela gonfle les coûts et la latence des jetons - un mode d'échec que les contrôles de sortie booléennes ignorent complètement.

2. La solution architecturale

Le quatrième jour du cours a introduit le concept d'évaluation en boîte de verre. Nous passons d’une simple vérification des résultats à une approche hiérarchique :

1. Niveau 1 : Boîte noire (de bout en bout) : l'utilisateur a-t-il obtenu le bon résultat ?
2. Niveau 2 : Boîte de Verre (Trajectoire) : L'agent a-t-il utilisé les bons outils dans le bon ordre ?
3. Niveau 3 : Composante (Unité) : Les outils individuels ont-ils fonctionné comme prévu ?

Ce déplacement traite la trajectoire (Pensée → Action → Observation) comme l'unité de vérité. En évaluant la trajectoire, nous nous assurons que l'agent n'a pas seulement de la chance, mais qu'il raisonne correctement.

3. Détails de mise en œuvre : notes de terrain de l'ADK

L'ADK fournit des primitives spécifiques pour capturer et évaluer ces trajectoires sans écrire d'analyseurs personnalisés pour chaque test.

Depuisadk webàevalset.jsonAu lieu d'écrire manuellement des cas de test, l'ADK encourage un flux de travail « Capturer et rejouer ». Pendant le développement (en utilisantadk web), lorsque vous repérez une interaction réussie, vous pouvez conserver cet état de session. Cela génère unevalset.jsonqui capture non seulement les entrées/sorties, mais aussi les appels d'outils attendus.

Ce JSON représente unEnsemble d'évaluationcontenant unEvalCase. ChaqueEvalCasea unnom,données(qui est une liste d'invocations) et un facultatifsession_initiale. Chaque invocation dans ledonnéesla liste comprend unrequête,attendu_tool_use,attendu_intermediate_agent_responses, et unréférenceréponse.

LeEnsemble d'évaluationl'objet lui-même comprend égalementeval_set_id,nom,description,eval_cases, etcréation_timestampchamps.

Configuration du juge

Dans letest_config.json, nous pouvons aller au-delà de la simple correspondance de chaînes. Le cours a démontré la configuration des évaluateurs LLM-as-a-Judge.

• Approche naïve : utilise un évaluateur de correspondance exacte (fragile, échoue en cas de différences de formulation).
• Approche architecturale : usagesÉvaluation de la trajectoireaux côtésSimilitude sémantique. L'ADK nous permet de définir des « Golden Sets » où le chemin de raisonnement est la norme, permettant au juge LLM de pénaliser les agents qui sautent des étapes ou hallucinent des données, même si le texte final semble plausible.

Composants de configuration de base

Pour configurer efficacement un LLM-as-a-Judge, vous devez construire une charge utile d'entrée spécifique avec quatre composants :

1. Résultat de l'agent : réponse réelle générée par l'agent que vous testez.
2. L'invite d'origine : l'instruction ou la requête spécifique fournie par l'utilisateur.
3. La réponse « en or » : une réponse de référence ou une vérité terrain pour servir de référence.
4. Une grille d'évaluation détaillée : des critères spécifiques (par exemple, "Évaluer l'utilité sur une échelle de 1 à 5") et des exigences pour que le juge explique son raisonnement.

Évaluateurs par défaut ADK

Le cadre d'évaluation ADK comprend plusieurs évaluateurs par défaut, accessibles via leMetricEvaluatorRegistre:

• RougeÉvaluateur: utilise la métrique ROUGE-1 pour évaluer la similarité entre la réponse finale d'un agent et une réponse idéale.
• FinalResponseMatchV2Evaluateur: Utilise une approche LLM en tant que juge pour déterminer si la réponse d'un agent est valide.
• Évaluation de la trajectoire: évalue l'exactitude des trajectoires d'utilisation des outils d'un agent en comparant la séquence d'appels d'outils aux appels attendus. Il prend en charge différents types de correspondance (EXACT,EN ORDRE,ANY_ORDER).
• Évaluateur de sécuritéV1 : évalue la sécurité (innocuité) de la réponse d'un agent, en déléguant au SDK Vertex Gen AI Eval.
• HallucinationsV1Évaluateur: Vérifie si une répons...
  [Courte citation de 8% de l'article original]