Technical Tutorials

Les grands modèles de langage (LLM) ont évolué rapidement, passant de simples générateurs de texte à des agents autonomes capables d'interagir avec des systèmes externes. Cependant, l'écart entre un modèle capable de « discuter » et un agent capable d'exécuter des workflows complexes de manière fiable est immense. En tant que développeurs, nous dépassons la simple ingénierie de prompts pour entrer dans l'ère des workflows agents. Le défi critique n'est plus de construire ces agents, mais d'évaluer rigoureusement leur capacité à utiliser des outils — API, bases de données et interpréteurs de code — dans des environnements réels et imprévisibles.

La complexité de l'évaluation de l'utilisation d'outils

Évaluer un agent LLM est fondamentalement différent d'évaluer un modèle de QA statique. Dans les benchmarks traditionnels, le contexte est statique. Dans les workflows agents, le contexte est dynamique. Un agent doit non seulement comprendre l'intention de l'utilisateur, mais aussi sélectionner le bon outil, formater correctement les arguments, gérer les échecs d'API et enchaîner plusieurs appels d'outils pour atteindre un objectif multi-étapes.

Les métriques clés pour cette évaluation incluent :

Pass@K : L'agent peut-il résoudre la tâche au moins une fois sur K tentatives ?
Taux de succès d'exécution : L'action finale correspond-elle au résultat attendu ?
Efficacité : Combien d'étapes l'agent a-t-il effectuées ? Moins d'étapes indiquent souvent un meilleur raisonnement.
Coût : L'utilisation de tokens est corrélée à la complexité du processus de sélection d'outils.

Conception de scénarios réalistes

Pour véritablement tester un agent, vous devez aller au-delà des ensembles de données synthétiques. Les scénarios réels impliquent du bruit, des limites de taux (rate limits) et des instructions ambiguës. Une suite d'évaluation robuste devrait inclure :

Appels d'outils en une seule étape : Tester si l'agent peut correctement formater une requête pour une API simple, comme la récupération des informations météorologiques.
Enchaînement multi-étapes : Des tâches qui nécessitent de lire des données depuis un outil pour les utiliser comme entrée dans un autre (par exemple, « Trouver le client avec la créance la plus élevée et lui envoyer un email de facture »).
Récupération d'erreurs : Introduire intentionnellement des échecs (par exemple, une erreur 500) pour voir si l'agent peut réessayer ou fournir une réponse de repli pertinente.

Exemple pratique : Requête automatisée de e-commerce

Considérons un agent chargé de récupérer les détails d'une commande. Une implémentation naïve pourrait échouer s'il ne parvient pas à analyser la réponse JSON ou s'il sélectionne le mauvais point de terminaison d'API. Voici un exemple Python simplifié utilisant un framework d'agent hypothétique pour illustrer comment nous pourrions structurer un cas de test d'évaluation.

import unittest
from agent_framework import Agent, Tool

class TestEcommerceAgent(unittest.TestCase):
    def setUp(self):
        self.agent = Agent(
            model="gpt-4-turbo",
            tools=[Tool("get_order", args=["order_id"])]
        )
        
    def test_successful_order_lookup(self):
        # Étant donné un ID de commande valide, l'agent devrait retourner les détails formatés
        response = self.agent.run("Quel est le statut de la commande #12345 ?")
        
        # Vérifier que l'agent a appelé le bon outil
        self.assertIn("get_order", response.used_tools)
        
        # Vérifier que la sortie contient les mots-clés attendus
        self.assertTrue(any(keyword in response.final_output 
                            for keyword in ["expédiée", "livrée", "en cours de traitement"]))

    def test_fallback_on_missing_tool(self):
        # Si l'utilisateur pose une question que l'agent ne peut pas traiter,
        # il devrait décliner poliment plutôt que d'halluciner.
        response = self.agent.run("Composez un haïku sur les pommes.")
        
        # L'agent ne devrait pas tenter d'utiliser 'get_order'
        self.assertNotIn("get_order", response.used_tools)
        self.assertIn("haiku", response.final_output.lower())

Conclusion

Évaluer les agents LLM sur l'utilisation d'outils en conditions réelles n'est pas un événement ponctuel, mais un processus continu. À mesure que le paysage des API disponibles et des intentions des utilisateurs évolue, vos métriques d'évaluation doivent également s'adapter. En vous concentrant sur des scénarios dynamiques et multi-étapes, et en intégrant des tests de gestion d'erreurs, vous pouvez construire des agents qui ne sont pas seulement intelligents, mais aussi résilients et fiables. L'avenir de l'IA réside dans sa capacité à agir, et notre responsabilité en tant qu'ingénieurs est de garantir que ces actions soient correctes, sûres et efficaces.