Votre serveur d'inférence est secrètement un apprenant : Open-source de Reef pour des agents à auto-amélioration continue

Reef est entièrement open source : https://github.com/Human-Agent-Society/reef

1. Avant que le battage médiatique autour du « RSI » ne devienne réalité

Avant que l'enthousiasme actuel autour du RSI ne se concrétise pleinement, nous souhaitons open-sourcer Reef, une infrastructure que nous développons pour le même problème plus large : permettre aux agents (combinaison harnais + modèle) d'évoluer en continu à partir de leur expérience.

L'objectif est de faciliter l'expérimentation de l'auto-amélioration continue par la communauté open source et de lui donner un accès facile à une infrastructure de qualité production pour cela. Nous utilisons l'auto-amélioration continue comme cadre plus large et plus pratique ici, le RSI représentant une forme plus pleinement récursive de la même idée.¹

2. Pourquoi l'auto-amélioration continue nécessite-t-elle une nouvelle infrastructure ?

GIF

La plupart des infrastructures LLM supposent un cycle de vie relativement simple. Nous entraînons un modèle, l'évaluons, le déployons, puis l'utilisons pour l'inférence. Pour les agents qui s'améliorent continuellement, nous pensons que deux hypothèses sous-jacentes à cette configuration commencent à s'effondrer.

Premièrement, l'inférence n'est plus la fin du pipeline. Les agents génèrent une expérience utile pendant qu'ils travaillent, y compris des trajectoires, des résultats d'exécution, des retours d'utilisateurs et d'autres signaux qui peuvent conduire à une amélioration future. Ce qui se passe au moment de l'inférence n'est plus simplement servi et jeté. Cela fait désormais partie du processus d'apprentissage lui-même.

Deuxièmement, le modèle n'est plus la seule chose qui évolue. Un agent est plus qu'un modèle, et l'auto-amélioration continue ne doit pas se limiter aux poids du modèle. Les prompts, la mémoire, les compétences, les outils et la logique d'orchestration peuvent tous potentiellement s'améliorer grâce à l'expérience. Un modèle plus fort étend les capacités de l'agent, tandis qu'un meilleur harnais aide à solliciter ces capacités plus efficacement et à les exercer de manière plus fiable dans des tâches complexes.

Ensemble, ces changements transforment ce qui était autrefois un pipeline principalement séquentiel en une boucle d'évolution continue. Les agents interagissent, génèrent de l'expérience, améliorent différentes parties d'eux-mêmes, évaluent si ces changements valent la peine d'être conservés et reviennent servir en tant que nouvelles versions du système.

C'est aussi pourquoi nous ne considérons pas Reef comme une simple infrastructure d'entraînement. L'entraînement n'est qu'une partie de la boucle. Nous pensons que l'infrastructure pour l'auto-amélioration continue doit partir de l'inférence en direct et soutenir l'évolution de l'agent dans son ensemble.

GIF

3. De quoi une telle infrastructure a-t-elle besoin, et comment Reef la met-il en œuvre ?

Architecture de Reef

L'infrastructure pour l'auto-amélioration continue doit posséder trois choses de bout en bout : l'expérience, l'agent et les mises à jour. Cela signifie (1) apprendre du trafic en direct, (2) mettre à jour à la fois le modèle et le harnais, et (3) évaluer, versionner et contrôler correctement la façon dont les mises à jour sont publiées.

Posséder l'expérience — l'apprentissage doit être construit sur la base du service en direct

L'inférence et l'entraînement ont historiquement été découplés. Certaines infrastructures RL (par exemple, Slime, veRL) intègrent un moteur d'inférence pour générer des données, mais ces systèmes sont conçus pour l'entraînement de modèles plutôt que pour le service de modèles. Nous postulons qu'une infrastructure d'auto-amélioration continue devrait d'abord être une infrastructure d'inférence et construire sa capacité d'entraînement autour de l'inférence en direct : le système sert des applications réelles, collecte l'expérience au moment du test et laisse les recettes d'apprentissage la consommer en continu. Cette conviction conduit à repenser de nombreux choix de conception, y compris la génération de signaux d'entraînement et la sélection d'échantillons d'entraînement.

L'inférence est native dans Reef. Reef expose des points de terminaison d'inférence standard, ce qui facilite son intégration dans les applications existantes et leur transformation en systèmes auto-évolutifs.

1# client = xxx  # initialiser le client httpx vers le point de terminaison de service de Reef
2
3# Appel d'inférence standard via Reef, format OpenAI
4response = client.post(
5        "/v1/chat/completions",
6    json={"model": xxx, "messages": xxx},
7)
8
9# Référence à l'enregistrement d'inférence stocké par Reef
10receipt = response.headers["x-reef-agent-record-id"]

Les applications peuvent également signaler des récompenses, des retours d'évaluateurs ou d'autres signaux associés à des appels d'inférence spécifiques via :

1# Attacher un retour à l'enregistrement d'inférence correspondant
2client.post(
3        "/reef/report",
4    json={"feedback": "wrong answer", "references": [receipt]},
5)

Contrairement aux moteurs d'inférence existants qui restent statiques tout au long de leur cycle de vie, Reef offre une inférence avec état : Reef stocke les traces d'inférence et les retours sous forme de flux d'expérience structuré, gérant des problèmes tels que l'obsolescence hors politique, la fusion de sessions et la déduplication. Les recettes d'apprentissage définissent comment ce flux est traité, quel algorithme d'apprentissage est utilisé et quand les mises à jour sont évaluées et déployées. Cela permet à différentes applications d'évoluer avec leurs propres stratégies d'apprentissage sur la même infrastructure.

Posséder l'agent dans son ensemble - le modèle et le harnais évoluent via l'inférence avec état

Un agent IA capable de fournir des résultats de bout en bout se compose non seulement d'un modèle, mais aussi d'un harnais. Le modèle fournit les capacités sous-jacentes nécessaires pour résoudre les tâches, tandis que le harnais permet une exécution fiable sur des trajectoires complexes et à long terme en gérant les outils, le contexte, la mémoire, les retours et l'orchestration. Les deux sont étroitement couplés : le harnais détermine comment les capacités du modèle sont sollicitées, ancrées et exercées, tandis que le modèle détermine quelles formes d'exécution le harnais peut supporter de manière fiable. Les progrès dans l'un peuvent donc modifier la conception optimale de l'autre. Une infrastructure d'auto-amélioration continue devrait soutenir l'évolution conjointe de l'ensemble de la pile de l'agent, y compris non seulement les poids du modèle, mais aussi les prompts, la mémoire, les compétences, les outils et la logique d'orchestration.

Reef prend en charge les mises à jour à la fois du modèle et du harnais.

Du côté du harnais, Reef utilise Cordis comme « backend d'entraînement ». Une recette d'évolution du harnais analyse généralement les trajectoires et les retours de l'agent, puis propose des modifications du harnais. Ce processus se déroule entièrement dans Reef, et chaque version évoluée du harnais est publiée pour l'utilisateur sous forme de mise à jour installable (en supposant que Reef soit servi sur localhost:8900) :

1curl -fsS -H "Authorization: Bearer $REEF_TOKEN" \
2  'http://localhost:8900/reef/harness/install?adapter=pi' | bash

La commande ci-dessus installe un harnais Pi encapsulé par Reef, à peu près de la même manière qu'un agent de codage typique. Le harnais est configuré pour utiliser le point de terminaison d'inférence avec état de Reef, de sorte que son trafic d'inférence transite par Reef. Pendant que l'utilisateur travaille, Cordis fait évoluer le harnais conformément à la recette d'évolution du harnais configurée, et les nouvelles versions sont mises à disposition via Reef. La prochaine fois que l'utilisateur ouvrira le harnais, il pourra voir :

Du côté du modèle, les recettes d'apprentissage consomment les enregistrements de Reef pour mettre à jour les poids du modèle. L'entraînement s'exécute de manière asynchrone avec le service en direct en utilisant un backend d'entraînement distribué, actuellement adapté de Slime, et produit des mises à jour de poids candidates telles que des points de contrôle ou des adaptateurs LoRA.

Une fois qu'un candidat passe l'évaluation et est approuvé pour le déploiement, Reef le publie en tant que nouvelle version de l'artefact du modèle du scénario et met à jour à chaud le moteur de service en utilisant la synchronisation des poids basée sur NCCL, sans redémarrer le service.

Posséder les mises à jour - les versions évoluées sont évaluées et versionnées

Un agent en évolution continue est sujet à une dégradation de la qualité du service, d'autant plus que l'évolution n'est pas garantie d'apporter une amélioration des performances. En tant que tel, chaque candidat évolué doit être évalué avant sa publication. Reef contrôle si un candidat évolué est autorisé à remplacer l'artefact qui dessert actuellement un scénario. Si le candidat est rejeté, le service reste inchangé. Sinon, Reef le publie en tant que nouvelle version vérifiable.

Tout ce que Reef peut faire évoluer — comme un point de contrôle de modèle, un adaptateur LoRA, un arbre de harnais ou une politique de routage — est représenté comme un artefact géré par un contrôleur de version. Reef adopte Git LFS pour gérer les artefacts, en particulier ceux qui occupent un grand espace disque comme les poids du modèle. Le chemin de publication est :

Chaque scénario a une chaîne de publication en ajout seulement. Reef fait avancer la tête de publication du scénario en utilisant compare-and-swap, de sorte qu'un éditeur obsolète ne peut pas écraser une version plus récente. Le pipeline de publication permet à Reef de suivre efficacement les changements de version continus et les processus de publication.

4. Méthodes d'auto-amélioration continue dans Reef

L'infrastructure ci-dessus fournit les abstractions communes pour l'auto-amélioration continue. La logique réelle de la façon dont un agent s'améliore est implémentée via des recettes d'apprentissage modulaires.

Nous avons vu une ménagerie croissante de méthodes pour transformer les signaux générés au moment du test en de meilleurs agents : apprentissage par renforcement en ligne, entraînement au moment du test, évolution des compétences, évolution du harnais, auto-jeu, et plus encore. Malgré leurs noms et mécanismes différents, ils partagent le même modèle de base : les signaux générés au moment du test sont transformés en mises à jour du système qui génère l'interaction suivante.

Ces recettes diffèrent principalement selon trois dimensions :

Signal d'apprentissage : Quelle forme de signal conduit à l'amélioration, et d'où vient-il ?

Acquisition d'expérience : Comment l'expérience d'apprentissage est-elle générée ? Est-elle recherchée de manière proactive par l'agent, ou générée de manière réactive à partir d'une tâche ou d'une interaction externe ?

Cible d'évolution : Qu'est-ce qui change réellement : le modèle, le harnais, ou les deux ?

Recettes déjà prises en charge ou bientôt disponibles dans Reef

Reef est conçu pour que ces méthodes puissent être largement exprimées via différentes recettes d'apprentissage sur la même infrastructure. L'utilisation d'une recette est simple : choisissez-en une et configurez-la lors du démarrage du service Reef.

1# serve.yaml
2reef:
3  recipe: recipes.sao.recipe:SAORecipe   # Brancher une recette d'évolution
4  batch_size: 1                          # Configuration spécifique à la recette
5  max_staleness: 18

Ensuite, démarrez Reef avec la configuration :

1reef serve -c recipes/sao/examples/sao/serve.yaml

Ci-dessous, nous montrons deux exemples, OpenClaw-RL et TTT-Discover, qui suivent des stratégies d'évolution très différentes mais peuvent tous deux être implémentés dans Reef.

GIF

Le visuel démontre une intégration d'OpenClaw-RL dans Reef. L'utilisateur interagit avec un agent dont le modèle est continuellement amélioré par Reef de manière asynchrone sans interrompre l'utilisateur. Au fur et à mesure que les tours s'accumulent, l'agent apprend progressivement à interpréter correctement la préférence de l'utilisateur et donne une réponse satisfaisante.

GIF

Le visuel démontre comment TTT améliore itérativement une solution Packing 32. Au fur et à mesure que l'optimisation progresse, des solutions de plus en plus efficaces sont découvertes et conservées, conduisant à des scores de conditionnement progressivement plus élevés.

5. Conclusion

Reef est notre tentative de transformer l'idée large de l'auto-amélioration continue en un problème concret de systèmes. En open-sourçant Reef, nous espérons rendre ce problème plus facile à étudier et donner à la communauté une base pratique pour construire des agents qui non seulement servent, mais apprennent et évoluent continuellement de l'expérience.

Nous vous invitons à essayer Reef, à créer vos propres recettes d'apprentissage et à l'intégrer à vos agents. Explorez le code, la documentation et les exemples de recettes sur https://github.com/Human-Agent-Society/reef. Si vous trouvez Reef utile, nous apprécierions une étoile sur le dépôt. Si vous souhaitez construire avec nous ou discuter plus largement de l'auto-amélioration continue, vous êtes plus que bienvenus pour rejoindre notre Discord : https://discord.gg/5y8e5f937k.

1. Nous utilisons l'auto-amélioration continue comme un cadre plus large et plus pratique que le RSI. Il couvre les systèmes qui s'améliorent de manière répétée à partir de l'expérience sans nécessiter la boucle entièrement fermée souvent associée au RSI, où l'IA elle-même participe à la construction et à l'amélioration du système qui produit sa prochaine version. Reef est conçu pour ce problème plus large, tout en laissant la place à des formes plus récursives d'auto-amélioration d'émerger par-dessus.

Liste croissante de contributeurs (par ordre alphabétique) : Chai Wenhao (@wenhaocha1), Ding Shuangrui (@ShuangruiDing), He Hao, He Haoze, Jiang Chonhe (@JiangChonghe), Jiang Nan (@nanjiangwill), Jiang Xuan, Li Xiaochen (@jacobli99), Liang Paul (@pliang279), Liu Bo (@Benjamin_eecs), Long Boyuan, Mang Qiuyang (@MangQiuyang), Qi Zhenting (@ZhentingQi), Qu Ao (@ao_qu18465), Qu Mingruo, Wang Zhaokai, Yan Xuezhi, Yu Hanfei (@yhfchitanda), Yu Haofei (@haofeiyu44), Yu Simon (@simon_ycl), Zheng Han (@hanzheng_7), Zhou Kaichen (@alex_kai2020), Zhou Zijian (@BobbyZhouZijian), Zhu Jiacheng (@JiachengZhu_ML), Zhuang Dingyi