Le point principal du papier n'est pas inattendu évidemment, c'est juste une preuve mathématique que faire réapprendre un LLM à partir de données générées par un ou d'autres LLM mène inévitablement à un effondrement.
Le post dit : "AI Cannot Self Improve and Math behind PROVES IT!".
Ce qui ne découle pas du tout du résultat du papier. Pour être cash : de la désinformation.
Dans le papier en lui-même, pas grand chose de nouveau effectivement : le phénomène de "model collapse" est vieux, étudié depuis un moment maintenant.
Pour faire simple, si tu fais (schematiquement) while True: model = train(synthetic_data(model)), tu es en plein dans le model collapse. Ce nouveau papier le montre formellement, ce qui est un résultat intéressant mathématiquement/théoriquement. En pratique, aucun intérêt : les données synthétiques ne sont pas utilisées de la sorte, mais plutôt comme ça : while True: model = train(initial_nonsynthetic_data + synthetic_data(model)). Et https://arxiv.org/abs/2404.01413 montre que cette méthode évite le model collapse.
Pire, de manière moderne, on l’utilise plutôt comme ça :
def verified_synthetic_data(model):
verified_data = []
while True:
(problem, verifier) = create_problem_and_verifier(model)
(trace, solution) = solve_problem(model)
if verifier(solution) == "correct":
verified_data.push(trace)
return verified_data
while True: model = train(initial_nonsynthetic_data + verified_synthetic_data(model))
(tous mes while True signifient : "pour un nombre d'itérations décidées par le développeur)
Et dans ce contexte, le modèle peut clairement "découvrir" de "nouvelles" informations qui améliorent la qualité du modèle suivant (problème ouvert : définir ça en termes rigoureux), pour peu que le choix du problème soit non-trivial et judicieux (résolution plus difficile que vérification) et que le verifier soit honnête et correct (et le commentaire que tu pointes note même qu’il n’est pas certain qu’il y ait besoin d’aller aussi loin qu’un couple generator/solver/verifier, juste générer un programme non-trivial, le lancer, et ajouter sa sortie génère des données hors-distribution et devrait éviter le modèle collapse. Je n’ai pas connaissance de papier étudiant si ça permet réellement des gains de performance, ceci dit).
et cite le papier From Entropy to Epiplexity: Rethinking Information for Computationally Bounded Intelligence, qui discute entre autre de comment maximiser l'utilité du modèle à ressource computationnelle contrainte étant donné les jeux d'apprentissages, en disant dépasser les pures notion de théorie de la complexité de l'information utilisées dans l'autre papier.
[^] # Re: Fil mastodon qui discute le papier
Posté par Moonz . En réponse au lien AI Cannot Self Improve and Math behind PROVES IT!. Évalué à 7 (+5/-0).
Le post dit : "AI Cannot Self Improve and Math behind PROVES IT!".
Ce qui ne découle pas du tout du résultat du papier. Pour être cash : de la désinformation.
Dans le papier en lui-même, pas grand chose de nouveau effectivement : le phénomène de "model collapse" est vieux, étudié depuis un moment maintenant.
Pour faire simple, si tu fais (schematiquement)
while True: model = train(synthetic_data(model)), tu es en plein dans le model collapse. Ce nouveau papier le montre formellement, ce qui est un résultat intéressant mathématiquement/théoriquement. En pratique, aucun intérêt : les données synthétiques ne sont pas utilisées de la sorte, mais plutôt comme ça :while True: model = train(initial_nonsynthetic_data + synthetic_data(model)). Et https://arxiv.org/abs/2404.01413 montre que cette méthode évite le model collapse.Pire, de manière moderne, on l’utilise plutôt comme ça :
(tous mes
while Truesignifient : "pour un nombre d'itérations décidées par le développeur)Et dans ce contexte, le modèle peut clairement "découvrir" de "nouvelles" informations qui améliorent la qualité du modèle suivant (problème ouvert : définir ça en termes rigoureux), pour peu que le choix du problème soit non-trivial et judicieux (résolution plus difficile que vérification) et que le verifier soit honnête et correct (et le commentaire que tu pointes note même qu’il n’est pas certain qu’il y ait besoin d’aller aussi loin qu’un couple generator/solver/verifier, juste générer un programme non-trivial, le lancer, et ajouter sa sortie génère des données hors-distribution et devrait éviter le modèle collapse. Je n’ai pas connaissance de papier étudiant si ça permet réellement des gains de performance, ceci dit).
Quelques références :
Je j’avais pas vu passer celui là, extrêmement intéressant, merci pour la référence. Sans y répondre directement, ça fait écho à cette revue de littérature d’il y a quelques jours : https://www.lesswrong.com/posts/zcGmdQHX66NhC69v6/the-other-paper-that-killed-deep-learning-theory