Je bosse sur PHLAME, le remplaçant de Glamin.
Ça, ça va vous plaire.
Je suis en train d’entraîner un petit réseau de neurones pour qu’il se comporte comme un compilateur. Il prend du code et le transforme en un framework qu’un agent peut utiliser pour exécuter des opérations nativement, via des poids gelés et des représentations apprises.
C’était fascinant de voir Glamin tourner. L’agent traitait cette fonctionnalité comme un réflexe.
Le problème, c’est que Glamin utilisait des vecteurs mutables, ce qui rendait tout débogage a posteriori impossible.
Architecturalement, c’était une impasse.
PHLAME est ma deuxième tentative de langage AI-native, en intégrant les leçons du projet précédent.
J’en suis encore aux tests de faisabilité, je peaufine la mécanique avec un parseur basique et des réseaux de neurones qui font le gros du boulot.
Un langage nul en maths
Les premiers échantillons compilent. C’est là que j’ai fait une découverte majeure.
Il pense que 2 + 2 = 6.
Mais il continue sa route, arrive à 8, et réalise que quelque chose a foiré.
Et voilà, mes amis, j’ai inventé le premier langage de programmation nul en maths.
Est-ce que ça compte pour quelque chose ?
Je parie que non.
En fait, le système n’est pas mauvais, il manquait juste une décision architecturale.
Je vais donc intégrer un mécanisme de requête asynchrone directement dans l’architecture d’exécution apprise. Le système n’a pas besoin de faire des maths, ou d’autres fonctions déterministes clés, il a surtout besoin de savoir QUAND les appeler.
Représentations et comportement
Allez, place à la théorie de la compilation !
Certaines idées architecturales viennent de mon travail sur Ruby Tumbler, un compilateur expérimental de Ruby vers native que j’écris. Là-bas, j’explore des moyens de traduire différentes représentations intermédiaires sans rien casser.
Tant que je peux préserver et vérifier le comportement pertinent des deux côtés, les représentations elles-mêmes peuvent être totalement différentes.
Ce qui ouvre des possibilités intéressantes. Trop cool !
Mettre la fluidité sur la bonne couche
Une autre erreur que j’ai faite avec Glamin, c’était de vouloir inventer un langage totalement nouveau. Et pas n’importe lequel, mais un truc tellement alien qu’il fallait être soit un LLM, soit titulaire d’un doctorat pour comprendre ce qui se passait.
C’est un problème parce que les vecteurs ne réfléchissent pas en termes d’arbres logiques comme les programmeurs. Ils réfléchissent en termes de distance.
Le faire comme ça a ses avantages. La complexité cyclomatique tombe à zéro, mais on se tape la courbe d’apprentissage.
C’est pour ça que, cette fois, je voulais faire différemment. Puisqu’on a retenu la leçon sur les représentations intermédiaires, on peut maintenant créer quelque chose qu’un humain peut analyser et trouver confortable, tout en profitant des priors de l’agent et en donnant au système un outil utilisable.
Le code source peut avoir une syntaxe conventionnelle, des fonctions, des classes et un flux de contrôle.
Le backend peut utiliser des associations apprises et des distances vectorielles pour sélectionner des comportements, avec une machinerie déterministe pour fournir les opérations et les garde-fous.
Deux mondes très différents, reliés par un seul système.
Probablement.
Je bosse encore dessus.