Rapport final

readme.md

@@ -52,3 +52,63 @@ Tu as aussi des rapports de chaque semaine de stage dans le dossier `rapports_re
 En plus de ces rapports, tu as une base de données de ce qui a été fait, en plus détaillé, avec l'outil "search_in_files".
 Bon couraj, il y a 25 semaines différentes, essaie de les regrouper en groupes de 5 pour aller plus vite. Regarde en particulier le fichier 'rapports_resumes/rapport_outils.txt' qui te donne une liste des outils utilisés.
 ```
+
+## Rapport du projet
+### Roadmap
+J'ai préparé la Roadmap comme une sorte de TODO liste, qui répertorie toutes les étapes nécéssaires à la mise en place du système. J'y ai donc noté tout ce qui a été fait et implémenté. J'ai aussi séparé les étapes en grands thèmes, séparant les différentes phases de création de l'agent.
+
+### Workflow
+Au départ, le système vérifie si le dossier `AgentReact/rapports_resumes/` existe. S'il n'est pas présent, une première étape de préparation est lancée.
+Un premier nœud va injecter un `HumanMessage` qui donnera les ordres au système de préparation, qui aura ensuite pour objectif de préparer la liste des tâches exécutées et des outils, techniques, entreprises, ... utilisés tout au long du stage, en utilisant des outils dédiés.
+Une fois cette première étape terminée, le contexte est réduit, avant de passer à la partie principale.
+
+La partie principale vise à suivre le plan définit dans `skills.md`, en utilisant les outils à disposition, et réduisant la taille du contexte chaque fois que nécessaire. Le système revient vers le nœud *user_prompt* chaque fois que le modèle a besoin d'un prompt, où l'utilisateur peut décider de répondre pour relancer la machine, ou d'envoyer `exit` pour terminer le programme.
+
+### Architecture
+Je me suis reposé sur l'architecture du TP3 que nous avions fait en cours. L'idée étant de séparer proprement les outils, les nodes, le `State`, et les différents utilitaires, j'ai pensé que cette lisibilité serait bénéfique pour un projet donc la complexité peut viter augmenter.
+
+Aussi, j'ai repris une approche de mes anciens projets, où j'ai implémenté des classes utilitaires pour représenter certaines choses (`TodoElement`, `InterruptPayload`), ce qui me fournit une interface propre pour travailler avec les TODO, ou la fonction `interrupt()`. Le `State`, ou `interrupt()` ne peuvent prendre que des données sérializables, et j'ai donc implémenté des méthodes pour exporter et importer les objets dans le format *JSON*.
+
+La base de données vectorielle est implémentée dans `VectorDatabase.py`, ce qui permet de facilement changer de source de données, et d'obtenir un poitn d'accès aux données depuis n'importe quel emplacement du programme.
+
+L'affichage des messages/du graphe est fait via `StreamGraph.py`, une fonction d'affichage récursive capable de gérer les interuptions et reprises, tout en gardant une trace du parcours des messages pour ne jamais afficher deux fois le même. Cette fonction a aussi un réglage pour dissimuler l'affichage des messages Système et des outils.
+
+Le fichier `nodes.py` contient des paramètres sur le graphe, tel que la taille maximale du contexte (avant réduction), le système de résumé, ou le prompt anti-injections. Tous les nœuds y sont définits. 
+
+### State
+Le `State` contient trois variables:
+- **todo**, une liste de tâches à faire, au format JSON, pouvant être reformées vers de vraies instances avec `TodoElement.fromJSON(...)`. Ces tâches sont injectables avant chaque prompt de l'utilisateur via un message système injecté dans l'appel au LLM.
+- **lastSummarizedMessage**: Pour éviter de résumer des messages déjà résumés, le système garde une trace d'où l'on s'était arrêté lors du dernier appel au nœud de gestion du contexte.
+- **stop**: Passera à `True` si l'utilisateur écrit `exit` dans le prompt, mettant fin à l'exécution.
+
+### Outils
+Plusieurs jeux d'outils sont disponibles, permettant de lister des fichiers, rechercher sur internet, ou dans la base vectorielle, de lire des fichiers locaux, de gérer les tâches en cours (*désactivé dans la dernière version, instable*), ou de récupérer un skill de `skills.md`.
+
+Un jeu d'outils réservé au LLM en charge du résumé de éléments du stage est disponible, avec un outil pour écrire le résumé d'une semaine, un pour faire un rapport sur les outils utilisés par le stagiaire, une recherche internet, ou dans la base vectorielle.
+
+Toutes les recherches dans la base vectorielle (outil `search_in_files`) sont reliées à un *cross-encodeur*, qui vérifie si les documents retrouvés correspondent à la requête. Si besoin, une IA va reformuler la question pour recommencer la recherche.
+
+La philosophie derrière la mise en place des outils était de ne pas laisser d'outils trop généralistes ou dangereux. Il n'y a donc pas d'outil pour écrire dans un fichier de façon générale, uniquement `append_part_to_report` qui ajoute une partie dans le rapport de stage, après validation humaine.
+
+### Gestion du contexte
+Le contexte est maintenu en-dessous d'une certaine limite par le nœud `context_shortener`. Il permet de faire un résumé de tous les messages qui en ont besoin, sans repasser deux fois sur le même; tandis que les retours des appels aux outils sont placés dans des fichiers et remplacés par le chemin vers le fichier créé.
+La limite de taille du contexte est définie dans `nodes.py`.
+
+La taille du contexte est vérifiée après les résultats des outils. Si besoin, le LLM peut toujours retrouver le résultat des outils en allant lire le fichier généré.
+
+### Human In The Loop
+La classe `InterruptPayload` est dédiée à cette partie. L'idée est que l'on puisse placer un `interrupt()` à n'importe quel endroit du workflow, pour y passer un une requête à l'utilisateur. Cette requête peut être des arguments d'un appel de fonction, ou une demande de prompt.
+
+Dans les outils, `InterruptPayload` peut prendre les arguments d'appel dans un dictionnaire, les convertir en JSON pour être passés dans l'`interrupt()` puis réassemblés de l'autre côté. L'affichage utilisateur implémenté dans cette classe permet ensuite d'accepter, de refuser ou de modifier une demande de lancement d'outil.
+
+Dans le nœud `user_prompt`, `InterruptPayload` peut demander le prompt à l'utilisateur, toujours en le sérialisant en JSON, pour le renvoyer dans le workflow.
+
+Les outils de recherche internet, et d'écriture dans le rapport de stage sont protégés par `InterruptPayload`, et l'utilisateur pourra toujours voir la requête du LLM avant qu'elle ne soit exécutée.
+
+Aussi,`StreamGraph.py`, qui affiche le graphe dans une boucle récursive, est compatible avec `InterruptPayload` pour l'affichage et la gestion du retour utilisateur.
+
+### Observabilité
+Lors du lancement du programme, tous les messages sont affichés dans la console. Il est possible de cacher les messages système et d'outils dans les paramètres de `StreamGraph.py` (appelé depuis `start.py`) pour augmenter la lisibilité.
+Aussi, lors du dévelopement, *Mlflow* a été utilisé pour analyser l'évolution du `State`  et les arguments d'appel exacts pour le LLM.
+
+Aussi, *Mlflow* ne semble pas apprécier l'appel aux `interrupt()` dans le code, considérant cela comme un plantage du système, sans qu'une solution a ce problème n'a pu être trouvée. Cela ne concerne que *Mlflow* et n'a aucun impact sur l'agent IA créé.