Infrastructure pour la recherche sur l’auto-amélioration récursive : exécuter et évaluer des agents qui s’améliorent

Un agent de recherche modifie un outil de recherche dans son propre code. Il réussit une tâche sur laquelle il échouait. Peut-il maintenant en résoudre d’autres ? Cette nouvelle version peut-elle trouver à son tour une modification utile ? Pour le vérifier, il faut modifier des programmes, lancer des expériences et comparer les résultats à plusieurs reprises. Beeuni fournit un ordinateur où les agents peuvent faire ce travail avec votre code, vos outils et vos scripts d’évaluation.

L’auto-amélioration récursive, ou RSI, étudie si un système peut s’améliorer, y compris dans sa façon de produire de nouvelles améliorations. Dans une expérience sur les agents, cela peut consister à modifier le code, les instructions ou les outils de l’agent, tester le changement et repartir d’une version réussie pour la tentative suivante. Une expérience sur un outil de recherche nous permettra d’expliquer concrètement comment Beeuni aide à chaque étape.

Donnez à Beeuni le code et une question précise

Connectez le dépôt qui contient votre agent et ses tests. Indiquez à Beeuni comment l’installer, quelle commande lance l’évaluation et quelle partie il peut modifier. Pour commencer, posez une question précise : l’outil de recherche peut-il renvoyer la fonction utile sans envoyer tout le fichier au modèle ?

La question de recherche détermine ce que l’agent peut modifier. Vous pouvez étudier si d’autres instructions améliorent la planification, si une nouvelle recherche évite des lectures inutiles ou si une autre gestion de la mémoire aide les tâches suivantes. Distinguez ces expériences. Modifier les poids du modèle demande un autre protocole, avec sa propre méthode d’entraînement et ses besoins de calcul.

Inspect the file-search tool in this repository.
Run the existing coding-task tests before changing it.
Try returning matching functions with their file paths and line numbers.
Keep the model and test settings unchanged.
Run the same tests again. Save the patch, raw logs, and a comparison report.
Do not change the tests or merge the code.

Beeuni peut lire le code, exécuter les commandes d’installation et lancer vos tests dans le terminal. S’il manque une dépendance ou si un test plante, l’agent peut examiner l’erreur et chercher sa cause. Vous pouvez suivre le travail dans la session et ouvrir les fichiers produits.

Testez l’outil d’origine avant sa nouvelle version

Demandez d’abord à Beeuni de lancer l’agent sans le modifier. Enregistrez les tâches réussies, les échecs et les erreurs. Si votre outil de test mesure l’utilisation du modèle, les appels d’outils ou la durée, conservez aussi ces valeurs. Vous aurez ainsi des résultats précis à comparer à ceux de la version modifiée.

Laissez ensuite l’agent modifier l’outil de recherche et relancer la même commande. Gardez le même modèle, les mêmes tâches et les mêmes limites. Demandez-lui d’expliquer chaque résultat qui a changé, avec le journal correspondant. Une baisse du nombre de tokens mérite d’être examinée, tout comme une tâche qui échoue désormais parce que le résultat de recherche abrégé omet du code important.

Vous demandez à l’agent de produire ces fichiers à partir de vos scripts. Beeuni ne fournit pas le banc d’essai de recherche et ne décide pas de ce qui constitue un progrès. Vous apportez les tâches et le code de notation ; l’agent aide à les exécuter et à examiner les résultats.

Choisissez la modification suivante à partir des échecs

Supposons que la nouvelle version fonctionne bien sur les petits fichiers, mais échoue lorsqu’une fonction appelle une fonction auxiliaire située ailleurs. Demandez à Beeuni d’examiner cette tâche, de trouver le contexte manquant et de proposer une modification ciblée. Vous pourriez ajouter les noms des fonctions liées au résultat de recherche, plutôt que de renvoyer de nouveau tous les fichiers en entier.

Examinez la modification et le rapport avant de les accepter. Testez ensuite sur d’autres tâches. Réussir l’exemple à l’origine de la modification est moins révélateur que réussir des tâches auxquelles l’agent n’a pas adapté son code. Gardez les tests de notation finale hors des fichiers qu’il peut modifier.

La même démarche convient à un agent de navigation. Donnez à Beeuni une application de test et une tâche, par exemple trouver une commande et modifier sa note de livraison. L’agent peut utiliser le navigateur, vérifier le résultat et conserver les éléments qui montrent un échec. Réinitialisez les données de l’application avant de comparer une autre version : les deux doivent partir de la même commande.

Organisez les expériences successives avec votre propre programme

Pour répéter les expériences, un contrôleur est le programme qui organise les essais. Il choisit une version de l’agent, demande une modification, lance les tests et décide quoi essayer ensuite. Le candidat est la version modifiée testée lors de cet essai. Votre contrôleur peut utiliser l’API ou le SDK TypeScript pour démarrer et consulter des sessions Beeuni. Les règles de sélection restent dans votre code de recherche.

Chaque session possède son propre environnement d’exécution. Vous pouvez tester deux implémentations d’un outil sans qu’elles écrasent les mêmes fichiers ou dépendances. Le programme testé doit démarrer avec la révision de code prévue. Si un script ne charge son code qu’au démarrage, relancez-le après la modification pour que le test utilise bien la nouvelle implémentation.

Commencez avec une petite file d’expériences. Fixez dans le contrôleur des limites de tentatives, de sessions simultanées, de durée et d’utilisation du modèle. Lorsqu’une limite est atteinte, faites arrêter le travail concerné et vérifiez que les processus se sont terminés. Ces règles fixent l’effort de recherche autorisé avant de choisir une version.

Testez chaque version dans les mêmes conditions

Un agent capable de consulter le corrigé ou de modifier les tests pourrait augmenter son score sans mieux réaliser la tâche. Exécutez la notation finale séparément, gardez les réponses cachées hors des fichiers accessibles à l’agent et empêchez-le de modifier le code de notation. Beeuni peut exécuter les tests de développement et recueillir les résultats ; votre programme d’évaluation peut les noter séparément. Pour les expériences dans le navigateur, réinitialisez les données partagées entre les versions : un nouvel ordinateur voit toujours les enregistrements laissés dans la même application externe.

Comparez les réussites, les erreurs, la durée, les appels d’outils et l’utilisation du modèle lorsque votre outil de test les mesure. Gardez des tâches, paramètres de modèle et limites d’exécution comparables. Répétez les essais dont le résultat est incertain. Une modification peut réduire les tokens lus mais manquer une fonction auxiliaire, ou réussir plus de tâches en multipliant les appels au modèle. Le rapport doit montrer ce compromis.

Mesurez aussi le coût de la recherche de la modification. Enregistrez séparément les tentatives nécessaires pour proposer et tester les versions, et le coût d’exécution de la version retenue. Un agent peut coûter moins cher par tâche tout en ayant demandé une recherche coûteuse. Ces deux mesures comptent pour évaluer l’expérience.

Conservez de quoi expliquer un essai raté

Une tâche mal exécutée et une API de modèle indisponible ne demandent pas le même suivi. Demandez à Beeuni de conserver les erreurs et journaux bruts avant de les résumer. Vos résultats peuvent distinguer réponses incorrectes, dépendances manquantes, échecs de requêtes au modèle et dépassements de durée. Décidez explicitement quels échecs justifient une nouvelle tentative, au lieu de tout relancer en silence jusqu’à obtenir une réussite.

Enregistrez les révisions du code avant et après modification, les instructions, les commandes de lancement, les dépendances, les versions des tests et du code de notation, ainsi que les résultats par tâche. Notez de quelle version précédente vient chaque modification. Beeuni peut rédiger ce compte rendu avec le correctif et les journaux. Vous pourrez examiner pourquoi une version a été retenue ou écartée.

Enregistrez les modifications et rapports utiles dans votre dépôt ou votre espace de stockage avant de supprimer l’ordinateur de l’expérience. Vous pourrez ainsi retrouver le code et la commande à l’origine d’un résultat, y compris pour les tentatives écartées.

Vérifiez si les tentatives suivantes d’amélioration deviennent meilleures

Après avoir choisi une version, évaluez-la sur des tâches qui n’ont pas guidé les modifications. Utilisez-la ensuite pour chercher d’autres améliorations et comparez ces tentatives à celles de l’agent d’origine. Trouve-t-elle plus souvent une modification utile, avec moins d’essais ou moins de régressions pour le même budget ? Réussir davantage de tâches est un premier résultat. Améliorer la façon de produire les progrès suivants est la question supplémentaire posée par la recherche RSI.

L’article sur la Darwin Gödel Machine étudie des agents qui modifient leur propre code et testent les changements. Self-Refine étudie la révision d’une réponse à partir de retours, sans entraînement supplémentaire. Cette différence aide à définir votre expérience : cherchez-vous à améliorer une réponse, la façon de travailler de l’agent ou sa capacité à trouver l’amélioration suivante ? Beeuni peut aider à modifier le code, exécuter les commandes et examiner les résultats. Vous concevez la méthode de recherche. Si l’expérience nécessite un entraînement du modèle, consultez le guide pour réaliser un fine-tuning avec Beeuni.

Pour essayer cette modification de l’outil de recherche, commencez avec un dépôt et une commande de test qui fonctionne. Le guide Computer explique comment examiner l’environnement et la sortie des programmes pendant que Beeuni travaille.