- CoRT (Chain of Recursive Thoughts) est un projet dans lequel un modèle d’IA ne fixe pas sa réponse d’un seul coup, mais génère lui-même plusieurs alternatives, les évalue à plusieurs reprises, puis choisit la réponse finale
- Le flux de fonctionnement se compose de la génération d’une réponse initiale, de la détermination du nombre de rounds de réflexion nécessaires, de la génération de 3 alternatives par round, de l’évaluation de l’ensemble des réponses, puis de la sélection de la meilleure réponse
- Lors de tests avec Mistral 3.1 24B, il est indiqué que la qualité des réponses s’est nettement améliorée pour un petit modèle, en particulier sur les tâches de programmation
- La Web UI est encore en phase initiale de développement ; sous Windows, on utilise
start_recthink.bat, et sous Linux le flux d’exécution passe par pip, npm et recthink_web.py
- Les composants clés sont l’auto-évaluation, la génération d’alternatives concurrentes, l’amélioration itérative et la profondeur de réflexion dynamique ; le projet est publié sous licence MIT
Ce que fait CoRT
- CoRT permet à un modèle d’IA de réexaminer récursivement ses propres réponses, de générer des alternatives, puis de sélectionner la meilleure réponse
- L’objectif est d’amener l’IA à ne pas utiliser telle quelle sa première réponse, mais à répéter un processus où elle doute d’elle-même et réessaie
- Le README décrit cela comme une sorte de « AI battle royale », où la réponse survivante parmi plusieurs candidates devient le résultat final
Méthode de génération des réponses
- Le flux de traitement se compose des étapes suivantes
- L’IA génère une réponse initiale
- L’IA détermine le nombre de rounds de réflexion nécessaires
- À chaque round, elle génère 3 réponses alternatives
- Elle évalue toutes les réponses
- Elle sélectionne la meilleure réponse
- La réponse finale est donc le résultat choisi après des cycles répétés de génération d’alternatives et d’évaluation
Tests et exemples
- Des tests ont été menés en appliquant CoRT à Mistral 3.1 24B
- Le README indique que la version avec CoRT a produit de meilleurs résultats que la version sans CoRT, en particulier sur les tâches de programmation
- À titre d’exemple, des images des résultats de Mistral 3.1 24B + CoRT et de Mistral 3.1 24B non CoRT sont incluses
Méthode d’exécution
- La Web UI est encore en phase initiale de développement
- Sous Windows, il est indiqué d’ouvrir
start_recthink.bat et d’attendre la fin de l’installation des dépendances
- La procédure d’exécution sous Linux est la suivante
pip install -r requirements.txt
cd frontend && npm install
cd ..
python ./recthink_web.py
- Dans un nouveau shell, lancer le frontend
cd frontend
npm start
Exécution directe et composants
- Pour une exécution directe, installer les dépendances, définir
OPENROUTER_API_KEY, puis exécuter le script Python
pip install -r requirements.txt
export OPENROUTER_API_KEY="your-key-here"
python recursive-thinking-ai.py
- Les quatre éléments clés mis en avant par le projet sont les suivants
-
Auto-évaluation
- Génération d’alternatives concurrentes
- Amélioration itérative
- Profondeur de réflexion dynamique
- Les contributions sont acceptées via PR, et la licence est MIT
1 commentaires
Avis sur Hacker News
On voit souvent l’idée qu’en mettant plusieurs modèles en compétition ou en les faisant tourner en groupe, une intelligence collective apparaîtra comme par magie, mais après avoir expérimenté moi-même et lu les travaux de l’ASU/Microsoft Research, j’en suis arrivé à une conclusion plus simple : les LLM sont de très mauvais vérificateurs pour d’autres LLM
Dans la présentation de Subbarao Kambhampati, “(How) Do LLMs Reason/Plan?”, GPT-4 produit avec assurance une preuve de coloriage de graphe démontrablement fausse, jusqu’à ce qu’un solveur SAT symbolique intervienne comme arbitre https://www.youtube.com/watch?v=0u2hdSpNS2o
L’article de Stechly et al. quantifie le fait que, lorsqu’on demande à GPT-4 de critiquer sa propre réponse, la précision baisse au contraire, tandis que l’ajout d’un vérificateur externe fiable améliore d’environ 30 points de pourcentage les tâches de planification et d’énigmes dans leur ensemble https://arxiv.org/abs/2402.08115
Autrement dit, pour les modèles autorégressifs actuels, vérifier est plus difficile que générer, et il faut des contrôleurs qui raisonnent réellement sur le monde, comme des compilateurs, des linters, des solveurs SAT ou des jeux de données de réponses correctes
C’est pourquoi empiler plusieurs LLM n’aide généralement pas beaucoup. Le position paper “LLM-Modulo” considère lui aussi que les modèles autorégressifs ne peuvent pas assurer seuls leur propre vérification ni une planification à long terme, et qu’il faut les traiter comme des générateurs d’idées à fort rappel, puis les encapsuler dans un vérificateur unique et fiable https://arxiv.org/abs/2402.01817
Mes propres tests montrent que remplacer un débat entre 5 modèles par un seul modèle fort accompagné d’un vérificateur donne des réponses identiques ou meilleures, avec une latence et une charge d’orchestration bien plus faibles
Les livres ou les films en sont un bon exemple : il est facile de dire qu’un personnage est superficiel, mais créer un personnage profond et intéressant est étonnamment difficile
C’est similaire en génie logiciel : un LLM auquel on demande de chercher des failles de sécurité peut signaler, dans le code généré, des endroits potentiellement vulnérables
Mais si l’on attend d’un autre LLM qu’il trouve des erreurs de raisonnement dans une preuve mathématique, il doit en pratique refaire tout le raisonnement ; il est donc douteux qu’il y ait un gain de performance significatif
Elle est aussi profondément intégrée dans l’évaluation des pipelines RAG au sein de frameworks comme LangChain ou LlamaIndex https://arxiv.org/abs/2411.15594
Je me demande ce que donnerait une approche où l’on demanderait aussi au LLM de créer des tests unitaires pour le code qu’il a généré, puis où l’on exécuterait également tous les tests unitaires existants de l’application
Vérifier que le code compile et que les tests unitaires passent permettrait une certaine forme de validation fondée, et l’IA pourrait lire les résultats des tests pour corriger ses propres erreurs
L’apprentissage sur des données de corpus peut produire des bonds d’un ordre de grandeur à un chiffre, mais l’apprentissage sur des données d’interaction, avec une boucle OODA permettant d’observer et de s’adapter, est bien plus puissant
Si je travaillais dans l’IA, c’est probablement ce que je ferais. En réalité, je construis BrowserBox
Le generate-and-test nécessite un algorithme de test fiable, relativement rapide et efficace en mémoire ; il est particulièrement utile quand un algorithme de génération exact, qui ne produit que des réponses correctes, est lent ou consomme beaucoup de mémoire
Ici, le générateur est le LLM, et le testeur ou « vérificateur » correspond aux compilateurs, linters, solveurs SAT, jeux de données de réponses correctes, etc.
Le generate-and-test est aussi lié aux essais et erreurs, et les essais et erreurs existent probablement depuis le Paléolithique
Une méthode que j’utilise parfois consiste à demander d’abord au modèle de chat IA de répondre au problème, puis de lui faire rédiger un rapport expliquant pourquoi cette réponse est correcte, de façon compréhensible par quelqu’un — ou par une IA — qui ne connaît ni le problème initial ni le domaine technique
Ensuite, je fais évaluer ce rapport par un deuxième modèle d’IA qui ne connaît pas le problème, et je lui demande d’exiger les explications que le modèle d’origine n’a pas fournies, ou de rédiger un rapport pointant les incohérences logiques
Je renvoie ce rapport au modèle initial, je lui fais réécrire sa réponse en intégrant les informations ou corrections nécessaires, puis je répète jusqu’à ce que le deuxième modèle soit convaincu ou que le premier modèle ait pris en compte toutes les demandes de modification
C’est très rudimentaire, mais dans les cas où j’ai essayé, les résultats ont été assez bons
Le plan final est généralement beaucoup plus équilibré et réfléchi
Fait intéressant, cette technique fonctionne aussi bien quand on se l’applique à soi-même. Chercher d’abord les failles avant de revoir un plan aide vraiment
Par exemple, l’un centré sur la technique, un autre sur le marketing, et un autre encore sur les objectifs personnels
Poser la même question dans des chats aux contextes différents revient un peu à examiner le même problème sous plusieurs angles, et les conclusions peuvent varier assez nettement selon le contexte
L’idée semblait assez bonne, mais la consommation de tokens risque d’augmenter fortement
Je crains aussi que si le LLM utilisé comme juge n’est pas capable de produire lui-même une réponse suffisamment bonne au départ, il ait également du mal à l’évaluer correctement
J’aimerais essayer ce genre de chose à plus grande échelle, sous la forme d’un sénat de débat toujours actif
Au lieu de répondre ponctuellement aux prompts, on lui donnerait une liste de tâches, éventuellement avec des échéances, et le sénat travaillerait dessus, se diviserait en groupes pour les sous-tâches, contesterait les résultats et formulerait des propositions
On pourrait même aller plus loin et créer un arbre d’analystes, où un nœud parent ne ferait remonter une proposition que lorsqu’il estime qu’une analyse secondaire est particulièrement perspicace
J’ai clairement constaté que demander à un modèle d’aborder un problème depuis un point de vue donné peut améliorer ou dégrader le résultat. Produire plusieurs perspectives, accompagnées d’une analyse critique de leurs résultats, pourrait donner des résultats impressionnants
Cette approche générerait un nombre énorme de tokens, mais le coût par token évolue dans un sens qui la rend envisageable. On peut aussi imaginer un serveur IRC dédié à l’IA, où chacun pourrait connecter son propre modèle et l’utiliser comme espace de discussion partagé
Quand je prenais le temps d’essayer, que je me retrouvais bloqué et que je revenais, il me répondait légèrement : « Oui, vous avez bien repéré le problème ! Vous y êtes presque ! Les prochaines étapes sont X et Y », puis ressortait le même tutoriel détaillé qu’avant, en ne modifiant qu’à peine les parties incorrectes comme les flags erronés
Cela donne l’impression de gérer un stagiaire trop enthousiaste qui balance des choses sans vérifier son travail, et je pense que placer un deuxième bot devant le premier pour lui demander « tu en es vraiment sûr ? » améliorerait nettement les choses
Je m’étais inspiré du concept des conseillers de Civilization II, et cela fonctionnait plutôt bien, même s’il y avait une certaine limite au fait d’être lié à un seul LLM, Mistral
Et c’était assez lourd pour faire griller mon ordinateur
Avec suffisamment de temps et de tokens, il serait intéressant de voir ce que cela pourrait produire
Une stratégie beaucoup plus simple et limitée, que j’utilise souvent, consiste à ajouter à la fin du message : « avant de répondre, réfléchis une fois dans des balises, fais une autocritique une fois dans des balises, puis rédige enfin la réponse finale »
Cela fonctionne plutôt bien. De même, demander simplement « trouve les 5 plus gros problèmes de cette proposition » marche correctement, même si imposer le nombre 5 pousse généralement le modèle à trouver quelque chose, même lorsque la plupart des points sont peu pertinents
À l’étape 1, je lui fais établir un plan ; à l’étape 2, je lui fais relever les failles du plan ; à l’étape 3, je lui fais mettre à jour le plan en tenant compte de ces failles
D’autres questions que je pose souvent sont du type : « Qu’avons-nous oublié ? », « Quelles sont les considérations en matière de performance, de sécurité, de juridique et de coûts ? »
On peut aussi répéter plusieurs fois des prompts d’incitation comme « Y a-t-il autre chose ? », surtout si l’on guide les sujets à prendre en compte. À chaque fois, je lui fais mettre à jour le plan en intégrant ces considérations
Un peu différent de ce que le titre laissait attendre. Je pensais que ce serait explicitement une procédure contradictoire
Je n’ai pas essayé ça moi-même et je ne sais pas si ça marche. Mais demander séparément à ChatGPT, avec des prompts distincts, « XYZ est vrai, explique pourquoi » et « XYZ est faux, explique pourquoi », puis voir quel côté est le plus convaincant, est utile
https://github.com/evalstate/fast-agent
Je ne sais pas pourquoi quelqu’un pense que c’est nouveau. Ça montre peut-être l’état de HN
L’approche en elle-même semble bonne, mais il ne faut surtout jamais suggérer directement « tu as tort ». En général, il part simplement du principe qu’il s’est trompé
À l’inverse, c’est impressionnant quand, même dans ce cas, il réfute réellement et se défend
Je trouve ce genre d’expériences assez amusantes, donc je suis en train de créer un éditeur de graphes façon blueprints d’Unreal Engine pour permettre aux gens de concevoir ce type de workflows
L’idée est que le prompt utilisateur entre dans un agent qui produit une première tentative, puis l’historique de cette conversation est transmis à un « agent » doté d’un autre prompt système pour jouer le critique impitoyable, émettre un signal de réussite ou d’échec, et boucler jusqu’à ce que le critique estime que c’est validé, avant de renvoyer le résultat à l’utilisateur
L’idéal serait un petit site web permettant d’appeler son propre endpoint LLM et de sauvegarder, charger et partager des graphes de workflow
Mistral Small 3.1 et Gemma 3 me semblent être les premiers modèles à peu près compétents qu’on puisse faire tourner en local, mais cette compétence n’est qu’une graine : il faut un framework pour les garder sur les rails
Si on leur donne le droit d’exécuter Python dans une boucle itérative et qu’on leur demande d’explorer le monde, ils commencent à télécharger et lire des choses comme des actualités
Par exemple, en demandant à GPT d’être méchant, j’ai pu lui faire imiter dans une certaine mesure la capacité de Gemini à repérer les bêtises ou les raisonnements bancals. La politesse semble filtrer beaucoup de choses précieuses
Mais le résultat devient désagréable à lire. Gemini semble résoudre cela en le traitant en deux étapes lors de l’apprentissage, la première devenant une « pensée » privée
Donc ce qu’il faut, à mon avis, c’est une approche en deux étapes qui rende cette sortie « méchante » un peu plus humaine. Travailler comme ça devient assez fatigant au-delà d’un court moment
Une interface de chat de groupe avec différentes personnalités de LLM aurait aussi beaucoup de valeur. Le format des objets de message semble conçu pour plusieurs utilisateurs et plusieurs IA, avec un nom sur chaque message, mais je n’ai pas encore vu d’interface de ce type
Ce serait encore mieux de prendre en charge plusieurs fournisseurs. Leurs points forts diffèrent, un peu comme lorsqu’on demande un second avis
consortium envoie le même prompt à plusieurs modèles en parallèle, puis envoie toutes les réponses à un modèle médiateur pour évaluation. Le médiateur décide s’il faut davantage d’itérations
On peut aussi forcer davantage d’itérations jusqu’à atteindre un seuil de confiance ou un nombre minimal de répétitions
Avec le PR que j’ai fait pour llm-openrouter, on peut enregistrer des alias de modèles incluant plusieurs options de modèle. Par exemple, on peut créer un spécialiste de la recherche en ligne avec
llm openrouter save -m qwen3 -o online -o temperature 0, system "research prompt" --name qwen-researcherUn autre membre peut faire de l’extraction d’entités en mode JSON, et un autre rédiger un brouillon à l’aveugle. Le médiateur utilise tout cela pour synthétiser une bonne réponse
Il faut vite trouver un moyen de faire tourner ces GPU avec de l’électricité verte. Sinon, les IA feront fondre la planète en débattant entre elles de la solution optimale du morpion
C’est parfois le moyen le plus simple de terminer une toute petite tâche, mais l’écart de coût côté backend doit être considérable. Au final, l’utilisateur s’en fiche complètement, parce que ça n’a rien de tangible
Le fait que l’IA doive continuellement tourner contre elle-même est déjà accepté comme une évidence
Je pense que c’est ainsi qu’on peut amener les modèles de machine learning à produire de nouvelles idées
Il s’agit de diagonaliser, par auto-débat, par rapport à toutes les idées déjà essayées puis abandonnées, tout en conservant certaines contraintes de cohérence. Bien sûr, c’est beaucoup moins facile à faire qu’à dire
Ce serait le jeu de la vie de Conway, mais au lieu de carrés colorés avec des règles, des LLM dotés de certains poids n’arrêteraient pas de se parler, et quelque chose émergerait quelque part sous forme de parole ou d’action
https://news.ycombinator.com/item?id=43835798
Jusqu’où cela peut-il aller ? Verra-t-on apparaître des équipes Scrum d’agents IA qui font des stand-up toutes les quelques heures ?
Va-t-on répliquer la bureaucratie gouvernementale avec des agents qui débattent de sujets toute la journée pour trouver le meilleur point de vue ?
Des agents IA avec des rôles différents faisaient tourner une équipe Scrum, et les prompts de chaque agent leur demandaient de contredire tout le monde ou de présenter leur point de vue de façon très critique ; la décision finale était prise par un médiateur, d’après lui
Le présentateur affirmait que cela avait bien fonctionné pour eux
Les humains ont des expériences et des points de vue différents, même si c’est moins vrai pour les LLM. Mais parfois, il suffit d’enfiler un autre chapeau. Comme la différence entre un reviewer de code et un développeur, par exemple
Un jour, il y aura un point où l’effet plafonnera, et il y aura sûrement aussi un comité IA pour déterminer ce point
Parce qu’on ne voudra pas faire bouillir l’océan
C’est bien d’avoir rendu ça facile à forker pour jouer avec
Je viens de commencer mon itération, qui ajoute Nash Equilibrium et reformule le « prompt engineering » comme une négociation multi-agents. Je suis curieux de savoir ce que les autres en pensent
https://github.com/faramarz/NECoRT/
Mon intuition est que les LLM d’entreprise n’auront pas de gros problème avec le coût de calcul supplémentaire, et préféreront ajuster des mécanismes financiers complexes via plusieurs optimisations de modélisation
Je ne suis pas très familier avec les dépôts publics ni les contributions, donc si je m’y prends mal, j’aimerais que quelqu’un me le signale
L’intention est de forker la base de code d’origine pour tester la théorie, puis de soumettre ça en PR au final