Dans le domaine en constante évolution de l’intelligence artificielle conversationnelle, l’optimisation des performances des agents est un défi majeur. Un tweet récent de Thariq (@trq212), ingénieur travaillant sur Claude Code, a mis en lumière une technique essentielle : le prompt caching. Cette méthode permet de réutiliser des calculs précédents, réduisant considérablement la latence et les coûts.
Cet article explore en détail le prompt caching, son fonctionnement et les leçons tirées de son optimisation à grande échelle, en s’appuyant sur l’expérience de Claude Code. Nous verrons comment cette technique impacte directement la performance des agents conversationnels et comment l’implémenter efficacement.
Le prompt caching, qu’est-ce que c’est ?
Le prompt caching repose sur le principe de la correspondance de préfixes. L’API conserve en cache tout, du début de la requête jusqu’à chaque point de contrôle cache_control. L’ordre des informations dans le prompt devient donc crucial pour maximiser les correspondances et réutiliser les calculs.
L’ordre idéal du prompt pour une mise en cache optimale
La stratégie optimale consiste à placer le contenu statique en premier et le contenu dynamique en dernier. Pour Claude Code, cela se traduit par l’ordre suivant :
- Prompt système statique et outils (mis en cache globalement)
- Claude.MD (mis en cache au sein d’un projet)
- Contexte de la session (mis en cache au sein d’une session)
- Messages de la conversation
Cependant, cet ordre peut être facilement perturbé, par exemple en incluant un horodatage précis dans le prompt système statique ou en modifiant l’ordre des définitions d’outils de manière non déterministe.
Optimiser le prompt caching : les leçons de Claude Code
L’équipe de Claude Code a tiré des leçons précieuses de l’optimisation du prompt caching à grande échelle :
Utiliser les messages pour les mises à jour
Lorsque des informations dans le prompt deviennent obsolètes (date, modification d’un fichier par l’utilisateur), il est tentant de mettre à jour le prompt lui-même. Cependant, cela entraînerait un échec de la mise en cache et augmenterait les coûts. La solution consiste à transmettre ces informations via les messages lors du tour suivant, par exemple, en utilisant une balise <system-reminder>.
Ne pas changer de modèle en cours de session
Les caches de prompts sont spécifiques à chaque modèle. Changer de modèle en cours de session peut être contre-productif. Par exemple, passer d’Opus à Haiku pour une question simple peut s’avérer plus coûteux en raison de la nécessité de reconstruire le cache pour Haiku. Si un changement de modèle est nécessaire, il est préférable d’utiliser des sous-agents.
Ne jamais ajouter ou supprimer d’outils en cours de session
Modifier l’ensemble d’outils en cours de conversation est une erreur courante qui invalide le cache. Bien qu’il semble logique de ne fournir au modèle que les outils nécessaires à un moment donné, les outils font partie du préfixe mis en cache. La solution consiste à concevoir des fonctionnalités qui tiennent compte de cette contrainte.
Concevoir autour du cache : l’exemple du mode plan
Le mode plan de Claude Code illustre parfaitement cette approche. Au lieu de remplacer l’ensemble d’outils par des outils en lecture seule lorsque l’utilisateur active le mode plan (ce qui briserait le cache), tous les outils sont conservés en permanence. Les outils EnterPlanMode et ExitPlanMode sont utilisés pour indiquer au modèle qu’il est en mode plan.
Décaler la recherche d’outils au lieu de supprimer les outils inutiles
De même, au lieu de supprimer des outils inutiles, Claude Code utilise des stubs légers (nom de l’outil et defer_loading: true) que le modèle peut découvrir via un outil de recherche d’outils. Les schémas complets des outils ne sont chargés que lorsque le modèle les sélectionne.
Forking de contexte et compaction : un défi pour le prompt caching
La compaction (résumé de la conversation lorsque la fenêtre de contexte est pleine) présente des défis spécifiques pour le prompt caching. Pour éviter un échec de la mise en cache, il est essentiel d’utiliser les mêmes paramètres (prompt système, contexte utilisateur, contexte système, définitions d’outils) que la conversation parente. Le prompt de compaction est ajouté comme un nouveau message utilisateur à la fin de la conversation parente.
Heureusement, l’API Anthropic intègre désormais la compaction, facilitant ainsi l’application de ces techniques.
Conclusion : le prompt caching, un impératif pour les agents performants
Le prompt caching est un élément fondamental pour construire des agents conversationnels efficaces et rentables. En comprenant son fonctionnement et en appliquant les leçons tirées de l’expérience de Claude Code, il est possible d’optimiser significativement les performances de ces agents.
Les points clés à retenir :
- Le prompt caching est basé sur la correspondance de préfixes.
- L’ordre des informations dans le prompt est crucial.
- Utiliser les messages pour les mises à jour.
- Ne pas changer d’outils ou de modèles en cours de session.
- Concevoir les fonctionnalités en tenant compte du cache.
- Surveiller le taux d’utilisation du cache.
- Les opérations de forking doivent partager le préfixe parent.
Comme le souligne Thariq, Claude Code a été conçu autour du prompt caching dès le premier jour. Si vous développez un agent conversationnel, vous devriez en faire autant.
Laisser un commentaire