원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Le micro-sharding poussé par les anciens LangChain ou AutoGPT a échoué. Diviser les étapes en dizaines de segments peut donner l'illusion d'une chaîne logique sophistiquée, mais en réalité, cela fragmente le contexte à chaque appel et ne fait qu'augmenter l'indéterminisme. Avec des LLM dont les capacités de raisonnement ont fait un bond prodigieux, comme Claude 3.5 ou le futur modèle 4, il faut changer de stratégie. Ne luttez plus avec des nœuds fragmentés. Intégrez-les plutôt dans une structure de gestion d'état centralisée contrôlée par un Planner.
Pour une transition d'architecture réussie, commencez par regrouper les micro-tâches existantes sous forme de méthodes au sein d'une seule classe afin de les encapsuler dans une boîte à outils (Tool Box). Définissez ensuite un objet State unique auquel tous les agents se réfèrent. Celui-ci doit impérativement contenir les champs plan (planification étape par étape), history (log d'exécution des outils) et artifacts (données générées).
Exploitez la fonction de réduction (reducer) de LangGraph pour que chaque agent mette à jour cet état partagé une fois sa tâche terminée. En bloquant physiquement la rupture de contexte, vous éliminez l'envoi de tokens redondants. Les équipes étant passées à cette structure ont constaté une réduction immédiate de plus de 30 % de leurs coûts d'API.
Le jugement subjectif selon lequel le résultat d'un agent "semble correct" est une bombe à retardement en environnement de production. Adoptez le pattern LLM-as-a-Judge, mais imposez-le impérativement au niveau du code. L'agent Evaluator doit décomposer la production du Generator en quatre indicateurs précis — exactitude, cohérence, lisibilité et efficacité — et les convertir en chiffres.
Utilisez la bibliothèque Pydantic pour forcer les résultats d'évaluation à suivre un schéma JSON spécifique.
RubricScore et définissez chaque indicateur comme un champ entier compris entre 1 et 5.Merge Block pour interrompre automatiquement le déploiement dans le pipeline CI/CD et envoyer un signal de retravail.La mise en place d'un tel système de vérification automatisé réduit à moins de 10 minutes une tâche de validation qui prenait autrefois 5 heures à un humain. La notation mécanique est froide, mais elle accroît d'autant la prédictibilité du système.
Dès qu'une boucle d'agents s'enclenche, les tokens s'accumulent à une vitesse effrayante. Renvoyer systématiquement les instructions système et les définitions d'outils revient à jeter de l'argent par les fenêtres. Le cache de prompts de Claude ne facture les tokens mis en cache qu'à hauteur de 10 % environ du tarif normal. Pour en bénéficier, vous devez adopter une stratégie de correspondance de préfixes en disposant la structure du prompt de la partie statique vers la partie dynamique (Tools → System → Messages).
cache_control.<system-reminder> à l'intérieur des messages utilisateur pour insérer des informations variables. C'est la condition sine qua non pour ne pas briser le cache du préfixe supérieur.Une stratégie de mise en cache bien conçue peut réduire les coûts d'appel API jusqu'à 90 %. La vitesse de réponse s'en trouve également améliorée de manière sensible. C'est le seul moyen de gagner à la fois sur le plan financier et temporel.
Si le Generator et l'Evaluator campent sur leurs positions sans parvenir à un accord, l'agent tombe dans une impasse (deadlock). Ce n'est pas une simple erreur, mais un désastre entraînant une explosion des coûts. Pour éviter cela, un coupe-circuit multicouche surveillant le nombre d'itérations et la similitude des réponses est nécessaire. En particulier, si la similitude cosinus entre la réponse précédente et la réponse actuelle est supérieure ou égale à 0,95, c'est le signe clair que l'agent tourne bêtement en boucle en répétant la même chose.
Donner les pleins pouvoirs à un agent n'est pas courageux, c'est irresponsable. Il vaut mieux ne pas exploiter de système d'agents sans dispositifs de sécurité.
Le processus de collaboration entre trois agents est une boîte noire. Sans savoir où se situent les goulots d'étranglement, aucune amélioration n'est possible. Connectez un système de traçage respectant les standards OpenTelemetry pour visualiser le flux de messages entre les agents. En implémentant un checkpointing basé sur Redis, vous pourrez reprendre le travail au dernier point de succès sans avoir à tout recommencer en cas de crash du système.
Extrayez la valeur cache_read_input_tokens des en-têtes de réponse API pour l'afficher sur votre tableau de bord. Un faible taux de réussite du cache (cache hit rate) prouve que la structure de votre prompt est inadaptée. De plus, en mesurant la vitesse de convergence de la boucle sous forme d'indicateur, vous pourrez prouver par les chiffres les résultats de votre ingénierie de prompt. En stockant les ID de session et les versions d'artefacts dans PostgreSQL, vous pourrez analyser précisément les points de blocage passés de votre équipe d'agents. Un agent qui n'enregistre rien ne deviendra jamais plus intelligent.