La fin de la question posée : on donne des instructions, la réponse vient au passage

Stack Overflow est en train de disparaître, ou en tout cas l’ensemble des métriques qui le constituent : le nombre de visiteurs, le nombre de questions posées, le nombre de nouveaux inscrits. Similarweb mesurait au mois de mars une fréquentation en baisse de 14 % sur un an, et la pente ne s’est pas redressée depuis.

Alors on en tire à peu près partout la même conclusion, et je pense qu’elle est fausse. Elle dit que les modèles de langage sont en train de consommer leur propre donnée. La donnée, pour ces modèles, c’est un peu ce que le pétrole est à l’énergie, et supprimer la source qui permet leur apprentissage, ça semble en effet terrifiant au premier abord.

Sauf que la courbe ne s’est pas retournée fin 2022. Le nombre de questions posées sur Stack Overflow a culminé vers 2014, autour de deux cent mille par mois, et il décline depuis. Une partie de ce déclin vient d’ailleurs de la plateforme elle-même, qui a fini par fermer les questions plus vite qu’elle ne les accueillait. Ce qui se passe cette année n’a donc pas inversé une tendance, ça a accéléré une chute qui avait déjà commencé.

Le symptôme le plus parlant est ailleurs. Au mois de mai, la direction a demandé à ses modérateurs bénévoles d’arrêter de supprimer les réponses générées par un modèle. Ils se sont mis en grève au début du mois de juin, et leur lettre ouverte avait dépassé le millier de signatures en quatre jours. Autrement dit, l’archive se remplissait de ce que produisait la chose même qui est en train de la remplacer.

Il y a donc deux points à regarder. D’abord, pourquoi l’usage d’un forum comme celui-là va probablement continuer de baisser. Ensuite, pourquoi ça ne sera probablement pas un problème pour les modèles de langage, ce qui est le moins intuitif des deux.

Ce qu’un modèle ne sait pas faire

Il serait quand même illusoire de se dire que les modèles vont réussir d’un seul coup à répondre à l’ensemble de nos questions. J’en observe trois types qui leur posent réellement problème.

Le premier, c’est la mise à jour. Un modèle a été entraîné à un instant T, et à partir de là il lui manque tout ce qui est sorti après : une bibliothèque publiée il y a quinze jours, une API dont la signature a changé le mois dernier, une erreur qui n’existait pas au moment de l’entraînement. Il est aveugle là-dessus, et le problème c’est qu’il l’est avec assurance.

Le deuxième, c’est le côté itératif d’une réponse. Dans certains cas une réponse n’est pas un paragraphe qu’on donne, c’est un travail d’investigation : il faut demander à la personne ce qu’elle a déjà essayé, obtenir une trace d’exécution, formuler une hypothèse, la voir tomber, recommencer. Un forum fait ça assez bien, parce qu’il est asynchrone et que plusieurs personnes creusent en parallèle.

Le troisième, c’est tout simplement la complexité. Certaines questions sont peut-être trop complexes pour qu’on puisse y répondre, y compris pour un humain compétent, et il y a là une limite inhérente qui n’a rien à voir avec le fait d’avoir tout lu.

Ces trois limites sont réelles, et je pense quand même qu’elles se referment toutes les trois, chacune à sa manière.

La connaissance fondamentale

La première tombe si on regarde comment ces modèles acquièrent leur connaissance plutôt que la quantité qu’ils en ont.

Une bibliothèque qui vient de sortir arrive certes avec sa propre API, ses propres fonctions, ses propres notions. Mais il y a de grandes chances qu’elle reste finalement une API assez proche des autres, et qu’elle suive certaines conventions, qui reposent elles-mêmes sur d’autres conventions. Quelqu’un qui écrit du code depuis dix ans ouvre une bibliothèque qu’il n’a jamais vue et devine la moitié de son interface avant d’avoir lu la documentation, simplement parce qu’il a vu passer assez de conventions pour deviner celle-là.

C’est ce que j’appellerais la connaissance fondamentale, et c’est en réalité ce qu’on cherche à installer dans un modèle. Ça explique d’ailleurs quelque chose qui serait sinon assez étrange : les entreprises qui entraînent ces modèles utilisent bien sûr des données à jour, mais elles font surtout très attention à la qualité de ce qu’elles y mettent. Des manuels, des essais, des textes présélectionnés comme étant importants à comprendre pour comprendre la réalité. Ce qui compte dans ces textes, c’est moins les réponses qu’ils contiennent que le fait qu’ils permettent de les reconstruire.

Du coup un modèle qui a les conventions n’a pas besoin d’avoir lu la bibliothèque. Il a besoin qu’on la lui mette sous les yeux, et tout ce qui suit vient de cet écart-là.

Le modèle va chercher son contexte

Depuis le mois de juin, on peut décrire des fonctions à un modèle d’OpenAI et le laisser décider lui-même de les appeler. C’est présenté comme une commodité d’intégration, et c’en est une, mais je pense que c’est surtout autre chose.

Un modèle qui dispose de fonctions peut reconnaître qu’il n’a pas la réponse, ou en tout cas qu’il n’y a pas été soumis pendant son entraînement. Il peut alors décider d’aller la chercher : ouvrir la page de la bibliothèque, naviguer dedans, lire lui-même le code source, exécuter un exemple, et se créer son propre contexte avant de répondre. Ce qui referme la deuxième limite en même temps que la première, puisque le travail itératif demande surtout quelqu’un capable de faire plusieurs pas avant de répondre, ce qui n’oblige pas forcément à passer par un forum.

Ce qui m’intéresse le plus là-dedans se trouve du côté de celui qui publie la bibliothèque. Si les modèles vont chercher leur contexte, alors ce qu’ils y trouvent devient une question de conception. On peut imaginer que celui qui met un SDK, un capteur ou une API à disposition d’autres développeurs voudra s’assurer que les modèles savent s’en servir, et qu’il arrêtera d’espérer qu’ils l’aient lu. Il concevra une interface pour eux, comme il écrit aujourd’hui une documentation pour les humains. Et il pourrait apprendre quelque chose au passage, parce que le modèle qui reçoit les questions sait ce que les utilisateurs cherchent réellement, et qu’il peut le lui faire remonter.

Le forum servait à ça aussi, il faut le dire. Il mettait dans la même pièce ceux qui font l’outil et ceux qui s’en servent. Ce que je décris là, c’est la même fonction, avec un intermédiaire au milieu qui ne dort pas et qui parle aux deux.

De la question à l’instruction

Stack Overflow a réagi il y a trois semaines en annonçant sa propre couche de génération, et c’est une réaction assez logique. Ils pourront certes utiliser leur réputation pour proposer un produit. Ce qu’ils viennent de perdre, en revanche, c’est un avantage stratégique majeur : ils avaient la base de données. Cinquante millions de questions et de réponses accumulées sur quinze ans, que personne d’autre ne possédait. Cette base a été complètement ingurgitée, elle est aujourd’hui accessible à travers des modèles que n’importe qui peut appeler, et elle sert des gens qui n’ont jamais mis les pieds sur le site. La plateforme a d’ailleurs annoncé au printemps qu’elle voulait facturer l’accès à ses données aux entreprises qui entraînent ces modèles, ce qui est défendable, mais qui arrive un peu tard.

Il y a quand même une raison plus profonde de ne pas parier sur un meilleur forum. Les projets qui sortent en ce moment ne cherchent plus vraiment à répondre à des questions, ils cherchent à exécuter des tâches. Écris-moi ce module, corrige ce comportement, migre ce projet. On passe en fait d’un paradigme où on posait des questions à un paradigme où on donne des instructions, et où on obtient la réponse au passage, en même temps que la tâche est faite. Et ça, c’est une vraie création de valeur, qu’une version générative d’un forum n’a pas.

Un forum, en réalité, c’est une institution construite autour d’un geste : demander à d’autres, publiquement, et attendre. Si ce geste devient rare, il y a peu de chances que dans dix ou quinze ans on continue à en fabriquer une version plus rapide.

Expérimenter au lieu de lire

Reste la question du début, celle qui a vraiment l’air d’être un problème : si plus personne n’écrit de réponses, avec quoi entraînera-t-on la génération suivante de modèles ?

Ici je fais des pronostics, et je le signale. Ce qu’on observe, c’est que ces modèles sont en train de devenir des agents. Ils ne se contentent plus de produire une sortie, ils prennent une action, changent leur contexte, et décident de la suivante en fonction de ce qu’ils observent. Or on sait faire apprendre quelque chose à un agent qui agit, c’est l’apprentissage par renforcement, avec une dizaine d’années de littérature derrière, d’AlphaGo à AlphaStar, qui attendait de pouvoir s’appliquer à autre chose qu’à des jeux.

On pourrait très bien imaginer des agents déployés dans des dockers, c’est-à-dire des machines virtuelles, avec à chaque fois une tâche à réaliser. Installe telle bibliothèque. Fais passer cette suite de tests. Développe tel projet. Ils vont faire des erreurs, tester de nouvelles hypothèses, et le système saura lequel de leurs essais a fonctionné, parce que la machine, elle, ne ment pas sur le résultat. La connaissance viendrait alors de ce qui a tenu à l’exécution, plutôt que de ce qu’un humain a écrit sur une page.

Si ça marche, ces modèles n’auront plus besoin de Stack Overflow, et pas du tout pour une question de volume de données : ils pourront expérimenter la réponse au lieu d’aller la lire.

Il y a quand même quelque chose qui me gêne là-dedans, et je n’ai pas de solution à proposer. Une archive de questions et de réponses avait un défaut énorme, sa lenteur, et une qualité qu’on ne remarquait pas tant qu’elle était là : elle était dehors. Elle était datée, elle était signée, on pouvait la contredire dans les commentaires, et quelqu’un qui n’avait rien demandé pouvait tomber dessus. Une connaissance acquise en expérimentant des choses dans un conteneur n’est déposée nulle part, elle est dans des poids. Elle marchera potentiellement très bien, et on ne saura plus où aller voir.