Modèle ReAct (Raisonnement + Action)

1. Aperçu du concept et problème systémique

Avant l'émergence du concept ReAct (publié par des chercheurs de l'Université de Princeton et Google Research en 2022), la communauté était divisée entre deux approches de l'automatisation des LLM :

1. Chain-of-Thought (Pensée seule) : Le modèle génère de longues chaînes de raisonnement, mais n'a pas accès au monde extérieur. En conséquence, la logique semble convaincante, mais elle repose sur des faits inventés et des données obsolètes.
2. Act-Only (Action seule) : Le modèle appelle des API ou exécute des commandes bash sans auto-analyse intermédiaire. Cela conduit à des répétitions chaotiques, à une recherche aveugle de paramètres et à l'incapacité de résoudre même des tâches simples multi-étapes.

Le pattern ReAct (Reasoning + Acting) a fusionné ces deux forces en un cycle itératif unique : le modèle verbalise d'abord ses pensées et planifie la prochaine étape, puis exécute l'action ciblée, analyse le résultat réel de l'environnement (Observation) et ne prend la décision suivante qu'après cela.

2. Taxonomie architecturale et modèle mental

Un cycle classique ReAct se compose de trois états séquentiels :

• 1. Thought (Raisonnement interne) : L'agent analyse l'état actuel de la tâche, formule une hypothèse et définit une intention précise : « Je dois vérifier si le service Redis tourne sur le port 6379 avant de lancer les tests ». Cette étape réduit considérablement la probabilité d'erreurs dans les arguments des outils.
• 2. Action (Appel d'action / outil) : L'agent forme une action concrète avec des paramètres stricts : nom de la fonction et objet JSON valide (par exemple, execute_bash(command="systemctl status redis")).
• 3. Observation (Observation de l'environnement) : Le runtime externe intercepte l'action, l'exécute sur le serveur ou dans la base de données et renvoie la sortie texte brute ou le code d'erreur dans le contexte de l'agent.
• 4. Finish / Final Answer (État final) : Lorsque l'agent constate dans la dernière Observation que l'objectif est atteint, il arrête le cycle et formule la réponse finale pour l'utilisateur.

3. Pipeline technique et mécanique interne

Cycle de vie d'un agent ReAct dans un environnement logiciel :

1. Context & Scratchpad Injection (Préparation du prompt) : Les règles d'interaction, les descriptions des outils disponibles et l'historique des itérations précédentes de la session actuelle (Scratchpad) sont intégrés dans le system prompt.
2. Inference with Tool Delimiter (Génération du raisonnement et de l'intention) : Le LLM génère les tokens de la section Thought. Dès que le modèle arrive à l'appel d'un outil, la génération est suspendue par le client, et les arguments de l'appel sont validés.
3. Execution & Observation Feedback (Exécution dans l'environnement) : L'orchestrateur transmet la commande au sous-système approprié (terminal local, base de données ou navigateur), lit la sortie, limite sa longueur pour économiser des tokens et ajoute le message Observation: ... au contexte.
4. Loop Progression & Termination Check (Vérification de sortie) : Si l'agent a atteint son objectif ou si le compteur max_iterations = 10 est dépassé, le cycle s'interrompt. Sinon, une nouvelle itération commence avec un nouveau bloc Thought.

4. Scénarios d'ingénierie pratiques en production

01. Diagnostic interactif et réparation de l'infrastructure serveur

• Thought : Le service retourne une erreur 502. Je vais d'abord vérifier les logs Nginx des 5 dernières minutes.
• Action : read_logs(service="nginx", lines=20)
• Observation : connect() failed (111: Connection refused) while connecting to upstream 127.0.0.1:3000
• Thought : L'upstream sur le port 3000 est tombé. Il faut vérifier le statut du processus Node.js via PM2.
• Action : execute_cmd(command="pm2 status")
• Observation : app-server: errored (out of memory)
• Thought : Le service a planté par manque de mémoire. Je vais le redémarrer avec une limite heap plus élevée.

02. Recherche itérative dans la documentation et les API

L'agent tente d'appeler un service externe Stripe. À la première étape, il reçoit une erreur invalid_api_key. Grâce au bloc Thought, l'agent se souvient que le mode test nécessite le préfixe sk_test_, récupère la bonne variable d'environnement et crée avec succès une intention de paiement dès la deuxième tentative.

03. Débogage pas à pas des tests unitaires

Un agent de code observe l'échec d'un test dû à une divergence de valeur attendue. Il formule une hypothèse, apporte une modification minimale sur une ligne, relance le test, voit un résultat vert, et seulement alors signale l'accomplissement de la tâche.

5. Pièges, erreurs courantes et sécurité

• Boucle sur une fausse hypothèse (Self-Reinforcing Delusion) : Si le modèle tire une conclusion erronée dès la première étape, il tendra à interpréter toutes les Observations suivantes comme confirmant son erreur. Solution : ajout obligatoire d'une étape de critique (Reflection) après 3 actions échouées consécutives.
• Surcharge du contexte due aux observations brutes : La commande cat huge_file.json retourne 50 000 tokens de bruit, évinçant le system prompt. Limitez toujours la taille de la réponse Observation dans le runtime (par exemple, pas plus de 2000 caractères).
• Appel d'outils inexistants (Action Hallucination) : Le modèle tente d'appeler un outil absent de la liste. Solution : utiliser l'API native Tool Calling plutôt que le parsing brut de texte.