Pourquoi nous entraînons nos propres modèles
Tout ce que Nostyss génère aujourd'hui vient d'un modèle généraliste derrière une API. C'était la seule façon raisonnable de démarrer, et ce n'est pas là que nous comptons rester. Ceci est une note d'étape sur un travail réellement inachevé.
L'écrire maintenant plutôt qu'à la fin est délibéré. Annoncer une chose terminée, c'est du marketing. Décrire une chose inachevée, y compris ce qui ne marche pas, est la seule version qui mérite d'être lue — et c'est celle que nous voudrions lire chez quelqu'un d'autre.
Ce pour quoi un modèle généraliste est optimisé, et pourquoi ce n'est pas ça
Un modèle généraliste est entraîné à être serviable, prudent et globalement acceptable sur toutes les tâches qu'on pourrait lui apporter. Ce sont les bons objectifs pour un assistant. Ils cadrent étrangement avec la fiction.
Les penchants se voient vite dès qu'on lit assez de chapitres générés. Il cherche la résolution propre. Il explique ce qu'il vient de montrer. Il lisse le conflit au lieu de le laisser peser. Il a un style maison qui remonte quelle que soit la voix demandée — et au bout de quarante chapitres, ce style maison est la seule voix qui reste dans le livre.
Un prompt peut demander à un modèle d'arrêter quelque chose. Il ne peut pas faire de cet arrêt son comportement par défaut.
Cet écart est tout l'argument. Un prompt est une requête formulée au moment de la génération contre toute une vie d'entraînement qui dit le contraire ; il tient quelques chapitres, puis l'entraînement gagne. Changer le comportement par défaut est un problème d'entraînement, pas de formulation.
L'autre raison : une API ne vous appartient pas
Il y a un argument moins romantique, et c'est lui qui impose réellement le calendrier.
Les modèles sont retirés. Celui sur lequel ce produit a été construit a une fin de vie publiée, et une date sur la page d'un fournisseur devient une migration dans votre agenda, que vous ayez prévu quelque chose ce trimestre ou non. Tout ce qui se trouve en aval bouge avec : l'écriture change, donc toute mesure de qualité prise avant la bascule décrit un système qui n'existe plus, et la comparaison que vous meniez soigneusement est à recommencer.
On y survit une fois. C'est une mauvaise fondation pour un produit dont la promesse entière est de se comporter de façon constante sur la durée. Un modèle que nous hébergeons ne peut pas être déprécié sous nos pieds, et son coût par chapitre est un nombre que nous décidons plutôt qu'un nombre que nous subissons.
Ce qui est réellement difficile
Trois choses, par ordre croissant de ce qu'elles nous ont coûté.
Les données sont l'essentiel du travail. Pas les rassembler : décider ce qu'est un exemple d'entraînement. Un roman est bien plus long que ce sur quoi on entraîne directement, il faut donc le découper — et l'endroit où l'on coupe, comme le contexte qui accompagne chaque morceau, change le résultat davantage que la plupart des décisions concernant le modèle lui-même. Presque tout l'effort se situe en amont de ce qui ressemble à de l'apprentissage automatique.
L'évaluation est plus dure que l'entraînement. Les métriques standard de génération de texte comparent la sortie à une réponse de référence et notent la proximité. La fiction n'a pas de réponse de référence. Il n'existe pas de chapitre suivant correct : une métrique qui récompense la proximité à un chapitre précis mesure donc la conformité, soit à peu près l'inverse de ce que nous voulons. La perplexité vous dit que le modèle est confiant, pas que le chapitre est bon. Construire une façon honnête de dire cette version est meilleure que celle-là nous a pris plus de temps que de faire aboutir les entraînements.
Savoir quand s'arrêter. Sans métrique nette, il est facile de continuer à régler vers ce qui plaît à l'œil cette semaine-là. S'en prémunir suppose de figer ce que l'on mesure avant de regarder les résultats : c'est ingrat, et c'est la différence entre une amélioration et une dérive.
Où nous en sommes
Inachevé, et nous n'y mettrons pas de date. Le statut honnête : le côté entraînement tourne, et c'est le côté mesure qui fait barrage. Nous produisons des modèles candidats plus vite que nous ne savons décider raisonnablement s'ils sont meilleurs, et en livrer un que nous ne savons pas évaluer reviendrait à échanger une quantité connue contre une inconnue, sur une intuition.
Rien de ce que vous lisez aujourd'hui sur Nostyss ne vient d'un modèle que nous avons entraîné. Quand cela changera, ce sera parce que nous aurons pu montrer qu'il est meilleur, pas parce qu'il est à nous.
La tenue sur la durée est tout le sujet de ce blog ; pour commencer, lisez pourquoi les histoires IA oublient.
Questions
Pourquoi entraîner un modèle plutôt que lui écrire un prompt ?
Parce qu'un prompt est une requête formulée contre tout ce que le modèle a appris à faire, et qu'il tient quelques chapitres avant que l'entraînement ne l'emporte. Changer le comportement par défaut d'un modèle, comme son goût pour les résolutions propres ou son style maison, est un problème d'entraînement.
Nostyss utilise-t-il son propre modèle aujourd'hui ?
Non. Tout ce que Nostyss génère aujourd'hui vient d'un modèle généraliste derrière une API. Nos propres modèles sont en cours d'entraînement, et l'un d'eux ne le remplacera que quand nous pourrons montrer qu'il écrit mieux.
Pourquoi est-il si difficile d'évaluer un modèle de fiction ?
Les métriques standard comparent la sortie à une réponse de référence, et la fiction n'en a pas : il n'existe pas de chapitre suivant correct. Une métrique qui récompense la proximité à un chapitre mesure la conformité, pas la qualité ; une évaluation honnête doit donc être construite pour l'usage.
Vérifiez si le monde se souvient vraiment
Dix mondes que vous pouvez lancer sans compte. Jouez quelques chapitres, contredisez quelque chose que vous aviez établi plus tôt, et regardez ce que le monde en fait. C'est la façon honnête de juger tout cela.
Choisir un monde