ReActEngine v1 : traitement des erreurs Assurer la continuité du raisonnement

, par Bertrand Degoy

Dans un agent de type ReAct, le raisonnement est construit étape par étape. Si une étape échoue, le LLM doit avoir des informations suffisantes pour reprendre le raisonnement, ou sinon risque de s’arrêter simplement, de façon silencieuse.
L’enjeu du traitement des erreurs est de toujours fournir au LLM de quoi construire une nouvelle étape de raisonnement.
Dans l’état actuel des modules LlamaIndex, trop d’erreurs sont simplement levées avec une classe d’exception "pythonique", en dehors de tout processus de reprise. C’est un problème assez général, que l’on retrouve dans les plus grands chatbots, se traduisant alors par un silence, un abandon ou un blocage.

Le traitement des erreurs dans ReActEngine

Dans ReActEngine, les erreurs sont traitées de deux manières, à deux niveaux et de façon indépendante : les exceptions et les Thoughts injectés.

Exceptions Pour corriger la sortie ReAct mal formée avant même qu’elle n’entre dans le flux. Exceptions = correction structurelle.

Exemples : • Action Input manquant • Thought sans Action • JSON invalide • protocole violé • output tronqué en streaming Dans ces cas, le LLM reçoit les informations nécessaires pour régénérer une étape ReAct correcte.

Thought injecté Pour corriger le raisonnement, pas la forme. Thought = correction cognitive

Exemples : • bouclage sur un outil en erreur • observation vide ( pertinente ou résultant d’une erreur ) • itérations excessives • action répétée • modèle qui "tourne en rond" Dans ces cas, on veut reprendre le flux, pas relancer le LLM.

Les deux modes influencent le raisonnement, mais à des niveaux différents du pipeline. La différence entre ces deux modes et leur indépendance apparaît clairement dans ce diagramme :

PNG - 1.5 Mo
ReActEngine : Traitement des erreurs

Les exceptions RetryException et ForceFinalizeException agissent entre 3 et 7 ( interne au ReActAgent ), l’insertion des Thoughts entre 8 et 12 ( le niveau d(orchestration par le Finalizer).

Conclusion : La règle d’or :

Erreur de protocole ReAct (la forme est invalide) → Exception → nouveau message LLM

Erreur de raisonnement (le contenu est problématique) → nouveau Thought

Est-ce suffisant ?

S’agissant de la boucle ReAct (les exceptions), le traitement peut être amélioré en remontant explicitement dans un arbre de raisonnement (Backtracking) en cas d’erreur. Il s’agit de quitter ou corriger la branche courante :

  • le moteur revient à un état antérieur du raisonnement,

  • demande au modèle de réessayer une nouvelle étape.

C’est déjà fait partiellement via RetryException, mais ce n’est pas encore du vrai backtracking, car :

  • on n’a pas un historique structuré des états (stack des ReasoningSteps)

  • on ne revient pas à un état antérieur du raisonnement,

  • on ne supprime pas la branche fautive,

  • on ne modifie pas le contexte du modèle.

à suivre...