Créer des flux de travail d’IA est simple. Les rendre fiables est l’ingénierie des systèmes

Créer la première version d’un workflow d’IA est généralement simple.

1. Connectez un LLM à quelques outils.
2. Ajoutez quelques instructions.
3. Laissez le modèle décider quoi faire ensuite.
4. Exécutez la démo.
5. Ça marche.

Le problème commence plus tard, lorsque ce flux de travail devient partie intégrante d’un processus réel.

Soudain, les questions importantes ne concernent plus l’invite.

Ils parlent de fiabilité.

• Que se passe-t-il lorsqu'un outil tombe en panne ?
• Que se passe-t-il lorsque le modèle réessaye la mauvaise chose ?
• Que se passe-t-il lorsque le workflow change d'état mais que l'agent déclare toujours un échec ?
• Que se passe-t-il lorsque l'agent revendique le succès mais qu'aucun outil n'est réellement exécuté ?
• Que se passe-t-il lorsqu'un agent transmet un mauvais contexte à un autre agent ?

C’est là que les flux de travail de l’IA cessent d’être une ingénierie rapide.

Ils deviennent Ingénierie Systèmes.

La démo n'est pas le système

De nombreuses démonstrations de flux de travail d'IA sont optimisées pour le chemin heureux.

1. L'utilisateur demande quelque chose.
2. L'agent réfléchit.
3. L'agent appelle un outil.
4. L'outil renvoie un résultat.
5. L'agent résume le résultat.
6. Tout le monde applaudit.

Mais les flux de production ne suivent pas une voie heureuse.

Ils vivent dans la réalité désordonnée de :

• Échecs partiels
• Mauvaises entrées
• Erreurs de délai d'attente
• Réponses d'outil non valides
• Nouvelles tentatives en double
• Contexte manquant
• Refus d'autorisation
• Incohérences d'état
• Limites de coûts
• Approbations humaines
• Chemins de récupération

La première version prouve que l’idée est possible.

La version de production doit prouver que le système est fiable.

Ce sont des objectifs très différents.

Les invites peuvent guider le raisonnement. Ils ne peuvent pas gérer la fiabilité.

Les invites sont importantes.

Ils aident le modèle à comprendre :

• Quel rôle il joue
• Quel objectif doit-il poursuivre
• Comment ça devrait raisonner
• Quel ton devrait-il utiliser
• Quelles contraintes il devrait prendre en compte

Mais les invites ne devraient pas être responsables de la fiabilité de l’ensemble du flux de travail.

Une invite ne devrait pas être la seule chose à empêcher une action dangereuse.

Une invite ne doit pas être la seule chose à rappeler quelle étape déjà terminée.

Une invite ne devrait pas être le seul élément déterminant si une nouvelle tentative est sûre.

Une invite ne doit pas être la seule preuve qu’...
[Courte citation de 8% de l'article original]