Votre agent IA n'a pas besoin d'être plus intelligent. Il doit être idempotent
La plupart des agents IA en production n'échouent pas à cause d'un mauvais raisonnement. Ils échouent à cause d'erreurs réseau.
Le modèle choisit le bon outil. Il remplit les bons détails. Ensuite, il facture un client deux fois.
Cela arrive parce que les agents capables d'écriture évoluent dans des réseaux peu fiables.
- Les requêtes expirent (timeout).
- Les connexions sont interrompues.
- Les frameworks réessaient des étapes déjà terminées.
Pour un agent en lecture seule, une tentative de réexécution est gratuite. Pour un agent capable d'écriture, une tentative de réexécution est une seconde action irréversible.
La solution est l'idempotence.
Considérez cet échec courant :
- L'agent appelle une fonction pour envoyer une facture.
- Le service crée la facture.
- La connexion est coupée avant que la réponse n'atteigne l'agent.
- L'agent constate un délai d'attente dépassé et réessaie.
- Désormais, vous avez deux factures.
Un modèle plus intelligent ne résoudra pas ce problème. Un modèle plus intelligent pourrait même l'aggraver en étant plus agressif lors des tentatives de réexécution.
Vous pouvez vous inspirer des systèmes de paiement comme Stripe. Ils utilisent une Idempotency-Key. Le serveur enregistre le résultat de la première requête. Si le client renvoie la même clé, le serveur renvoie le résultat stocké au lieu d'exécuter l'action une seconde fois.
Pour un agent IA, vous devez dériver cette clé de l'intention.
N'utilisez pas d'identifiants aléatoires. Utilisez un hash du nom de l'outil et de ses paramètres stables.
Exemple :
- Outil :
charge_customer - Paramètres :
{customer_id: 42, amount: 500} - Clé :
hash(tool + params)
Si l'agent réessaie exactement le même débit, la clé reste la même. Le système la reconnaît et empêche un débit en double.
Un mot de mise en garde : votre clé n'est aussi bonne que votre définition d'une action unique.
- Si vous incluez un horodatage (timestamp) dans votre hash, chaque tentative recevra une nouvelle clé. Votre protection échoue.
- Si vous incluez un corps de message écrit par un LLM, le modèle pourrait changer un seul mot. Cela crée une nouvelle clé et une action en double.
Basez toujours votre clé sur des données stables comme les identifiants clients ou les identifiants de facture. Excluez tout ce que le modèle pourrait modifier.
Arrêtez d'essayer de corriger la fiabilité des agents avec de meilleurs prompts.
La fiabilité consiste à rendre le coût d'une décision répétée nul. Si votre agent effectue la même action deux fois, rien ne devrait casser.
Optional learning community: https://t.me/GyaanSetuAi