Méta-curateur et évolution

Deux rôles séparés : kernel et méta-curateur

Le kernel et le méta-curateur font tous deux partie du système, mais tournent comme deux sessions séparées (contextes propres, espaces distincts).

• Le kernel est user-facing : il reçoit la demande, orchestre (spawn de pods + routing des jobs), et possède le substrat mémoire (ingestion + retrieve du RAG).
• Le méta-curateur vit au niveau MÉTA = ANALYSE, pas orchestration de spawn. C’est un LLM-as-judge dans le process et un gardien du sens : il veille à la cohérence et détecte la dérive. Il n’orchestre pas le spawn ni le routing — ça reste le rôle du kernel.

Cette séparation est volontaire : analyser et exécuter sont deux métiers. Les mélanger dans une seule boucle dilue les deux.

Le harnais qui évolue — tous les primitifs, pas seulement les prompts

Erreur fréquente : croire que seule la formulation des prompts évolue. Dans Nika OS, tout le harnais d’une tâche est sujet à évolution, par type de tâche :

Primitif	Ce qui évolue
Prompts	Reformulations, exemples ajoutés, redondances supprimées
Skills	Le corps markdown, les déclencheurs, la composition entre skills
Hooks	Quels événements lifecycle sont câblés, leur logique, leurs seuils
Tools / MCP	Quels outils sont chargés pour une classe de tâche, leur loadout
Mesures de succès	La définition même du succès : critères SQP, rubriques de jugement, seuils des contrôleurs

Le point essentiel : on ne fait pas qu’optimiser comment on demande, on fait aussi évoluer comment on mesure si c’est réussi. Un harnais qui évolue sans revoir ses propres mesures de succès finit par sur-optimiser une métrique obsolète. Chaque type de tâche (recherche, rédaction, génération de code, analyse de données…) a son harnais propre, qui évolue indépendamment.

Le kernel, lui, ne mute jamais. Seul le harnais évolue. Cette frontière protège les invariants de sécurité et les contrats de sortie.

Supervision continue — temps réel

Le méta-curateur observe le système en continu, pendant que les pods travaillent :

• Streame tout ce qui se passe sur tous les pods (observabilité).
• Trie les prompts et les primitives utilisées : les bonnes primitives ont-elles été activées ? y a-t-il des doublons ? la qualité est-elle au rendez-vous ?
• Renvoie un feedback au lanceur du pod — le kernel, ou (selon la profondeur de récursivité) le pod parent qui l’a lancé — pour qu’il ajuste ses déclarations et ses configs.
• Pilote l’apprentissage : il a dans ses outils le lancement du fine-tuning et la gérance du compute GPU/CPU pour l’embedding — il analyse, décide, puis déclenche un ré-entraînement du modèle de retrieval et gère les ressources de calcul.

Il n’orchestre pas le spawn : il analyse et conseille. C’est le kernel qui agit sur ces conseils.

Le rêve — consolidation par matchs

Quand l’activité retombe (cycle nocturne), le kernel et le méta-curateur travaillent ensemble à une consolidation par matchs (tournois, cohérents avec le système d’ELO) :

1. Matière — les épisodes réels de la période (tours de conversation, bus, transcripts) sont rejoués.
2. Challengers — le méta-curateur génère des variantes (prompts, primitives, stratégies) sur les types de tâches observés.
3. Match — duel entre le champion (la primitive en place) et le challenger, rejoué par le kernel sur un échantillon d’épisodes.
4. Arbitrage — le méta-curateur juge (critères SQP + Definition of Done de l’épisode), en regardant l’effect size, pas seulement la p-value.
5. ELO + promotion — le gagnant prend de l’ELO ; il ne détrône le champion que sur preuve chiffrée contre une baseline held-out — jamais sur un « ça paraît mieux ».
6. REX — on garde la leçon (pourquoi ça gagne) et on jette le bruit (principe anti-Funes : se souvenir de tout, c’est ne plus pouvoir penser). Le patch promu rejoint les primitives ; la leçon rejoint le RAG.

La distinction tient en une phrase : la supervision continue donne un feedback immédiat, par pod ; le rêve consolide par lots et par tournois. Les deux sont complémentaires.

Le contrôleur en ligne

Tous les paramètres ne s’optimisent pas par tournoi. Pour ceux qui ont une récompense mesurable au moment de la décision (choix du modèle, concurrence des pods, politique de retry, nombre de chunks RAG), Nika OS utilise un contrôleur en ligne.

Le contrôleur décide combien intervenir sur un paramètre, à partir de trois ingrédients :

1. une estimation de savoir si un changement observé est du bruit ou une dérive réelle ;
2. le coût de l’écart à la cible ;
3. une allocation qui croît avec la confiance — on intervient peu quand le signal est incertain, fermement quand il est franc.

Trois zones émergent :

• Bruit — ne rien faire.
• Doute — correction douce, attendre confirmation.
• Dérive — correction ferme et immédiate.

Ce comportement rend le système antifragile : au lieu d’osciller à chaque bruit, il attend l’information statistique nécessaire avant d’agir. On n’applique pas le contrôleur là où la récompense est subjective (qualité d’un brouillon de mail, par exemple) : ce cas relève du tournoi LLM-as-judge.

Les trois tracks d’évolution

Nika OS distingue trois mécanismes d’évolution, choisis selon ce qu’on peut mesurer :

Track	Cibles	Cadence	Évaluation
Tournoi (GEPA)	Skills, prompts, doctrines	Continue, par tournoi LLM-judge	Pareto multi-objectifs
Ablation + DOE	Hooks, configs MCP, logique de routing	Discrète, par lots	Test non-paramétrique + effect size + bootstrap CI
Contrôleur en ligne	Params online (retry, modèle, concurrence, RAG k)	À chaque décision	Reward signal temps réel

Le track est choisi par la nature du signal : récompense subjective → tournoi ; comparaison contrôlée → DOE ; récompense mesurable en ligne → contrôleur.

Pourquoi cette architecture

Séparer l’analyse (méta-curateur) de l’exécution (kernel) permet d’optimiser chacune pour son métier, sans qu’une boucle d’analyse ralentisse le travail user-facing. La promotion uniquement sur preuve chiffrée évite le risque de shipper un changement qui « paraît mieux » sans l’être. Et le principe anti-Funes — garder la leçon, jeter le bruit — empêche le système de s’effondrer sous le poids de sa propre histoire.

Voir aussi

• Observabilité et contrôleurs — comment le système observe ses pods sans saturer son contexte, et le loss score qui nourrit le contrôleur.
• Doctrines — antifragilité et la doctrine algos comme tools expliquent pourquoi le contrôleur est un outil invoqué, pas un LLM.
• Références — travaux externes qui ont inspiré l’architecture.