> # TL;DR
>
> - Construire des agents LLM/IA consiste à
> - toujours partir de la simplicité comme principe de base, et n’ajouter de la complexité qu’en cas de nécessité
> - « comprendre en profondeur les frameworks avant de les adopter », « combiner et tester les workflows et les patterns d’agents (chaining, routing, parallélisation, évaluateur-optimiseur, etc.) en fonction de l’environnement réel et des objectifs, tout en concevant soigneusement les outils (API), leur documentation et leurs tests ».
1. Principes de conception d’agents LLM réussis
- Se concentrer sur la simplicité : les implémentations les plus réussies ont tendance à s’appuyer sur des patterns simples et composables, plutôt que sur des frameworks complexes.
- N’ajouter de la complexité que si nécessaire : il est plus efficace de concevoir une structure de base aussi simple que possible, puis d’introduire de la complexité uniquement lorsqu’elle devient indispensable.
- (Texte original : « Les implémentations les plus réussies ne dépendaient pas de bibliothèques spécialisées ni de frameworks complexes… Elles étaient construites sur des patterns simples, mais combinables de façon modulaire. »)
2. Différence entre workflows et agents
- Workflows : le LLM et les outils traitent les tâches selon une route prédéfinie (chemin de code).
- Agents : le LLM gère lui-même dynamiquement les tâches et l’usage des outils (c’est le LLM qui prend les décisions).
- (Texte original : « Les workflows coordonnent le LLM et les outils selon des chemins de code prédéfinis… les agents permettent au LLM de diriger dynamiquement son propre processus et sa manière d’utiliser les outils. »)
3. Critères pour décider d’introduire des agents
- Méthode simple d’abord → complexification progressive si nécessaire : commencer par de simples appels au LLM, de la recherche, etc., puis introduire progressivement des Workflows/Agents si cela ne suffit pas.
- Prévisibilité / cohérence importantes → les workflows sont adaptés
- Grande flexibilité / prise de décision pilotée par le modèle nécessaires → les agents sont plus appropriés
4. Principes d’adoption des frameworks
- Il existe divers outils/frameworks comme LangGraph, Bedrock, Rivet et Vellum, mais
- il est recommandé de commencer par utiliser directement l’API du LLM, puis de n’adopter un framework qu’en cas de besoin.
- En utilisant un framework, une compréhension approfondie de son fonctionnement interne est indispensable (l’abstraction peut compliquer la résolution de problèmes).
- (Texte original : « Nous recommandons aux développeurs de commencer d’abord par utiliser directement l’API du LLM. »)
5. Workflows pratiques par pattern et exemples
- LLM augmenté (Augmented LLM) : ajout de fonctions d’extension intégrées comme la recherche, la connexion à des outils, la mémoire, etc. (la conception détaillée de l’interface et la documentation sont importantes)
- Prompt chaining : diviser une tâche en plusieurs appels au LLM (étapes) pour gagner en clarté et en précision.
- Ex. : génération de copy marketing → traduction, brouillon de document → relecture → rédaction
- Routing : classer les entrées puis les diriger vers le traitement ou l’outil approprié
- Ex. : routage selon le type de demande client, transfert des questions difficiles uniquement vers un modèle plus performant
- Parallélisation :
- Sectioning : découper une tâche en plusieurs sous-tâches traitées simultanément
- Voting : exécuter plusieurs fois la même tâche pour déterminer le meilleur résultat
- Ex. : revue de vulnérabilités de code, automatisation de l’évaluation de LLM
- Orchestrator-Workers : un agent maître distribue et agrège les sous-tâches.
- Ex. : distribution en temps réel des seules parties nécessaires dans des tâches de code complexes, collecte et intégration de plusieurs sources de données
- Evaluator-Optimizer : un LLM produit une réponse, puis un autre LLM l’évalue et fournit un feedback pour l’améliorer de manière itérative
- Ex. : amélioration itérative de résultats de traduction, collecte d’informations complexes
6. Cas d’usage réels dans l’industrie
- Support client : intégration chatbot + outils, automatisation des opérations liées aux données clients / commandes / remboursements, avec un critère de succès clairement défini par la « résolution du problème ». Références d’entreprises avec, par exemple, une tarification basée sur l’usage.
- Agents de code : itération et amélioration basées sur le feedback de tests automatisés, validées notamment sur SWE-bench. Le domaine du problème et la qualité du résultat peuvent être mesurés clairement. Cependant, une revue finale humaine reste toujours nécessaire.
7. Conseils de prompt engineering pour les outils (annexe 2)
- Recommander un format facile à utiliser pour le LLM et une allocation de tokens suffisante
- Décrire clairement les outils (usage, exemples, edge cases, définition des limites, etc.)
- Tester ⇒ améliorer en observant l’usage réel du modèle (à l’aide d’un workbench, etc.)
- Concevoir selon une approche poka-yoke pour éviter même les erreurs mineures
- (Texte original : « Une bonne définition d’outil devrait inclure des exemples d’usage, des edge cases, des exigences de format d’entrée, ainsi que des frontières claires avec les autres outils. »)
8. Principes clés
- Préserver la simplicité (Keep it simple)
- La transparence du processus de planification de l’agent est indispensable
- Documentation claire et tests des outils et des interfaces
- Les frameworks sont utiles pour accélérer le démarrage, mais il est recommandé de minimiser l’abstraction et de garder un contrôle direct
Aucun commentaire pour le moment.