Comment savoir si un modèle de langage que vous avez entraîné est bon?

À la fin de l’entraînement, vous avez un fichier de nombres et une ligne qui descend sur un graphique. Ni l’un ni l’autre ne vous dit si le modèle est bon. Tester un modèle maison demande plus que les vérifications faites sur un assistant commercial, car vous devez aussi savoir si l’entraînement lui-même a fonctionné.

Chacun des quatre niveaux ci-dessous répond à une question différente, et ils repèrent des échecs différents. Faites-les dans l’ordre, car les premiers coûtent peu.

Niveau 1 : a-t-il appris à prédire un texte jamais vu?

La perte (loss) mesure à quel point le prochain jeton surprend le modèle. La perte d’entraînement se mesure sur le texte sur lequel il s’est exercé, et la perte de validation sur la tranche mise de côté. Une perte d’entraînement qui baisse et une perte de validation plate ou en hausse indiquent un surapprentissage : le modèle mémorise au lieu d’apprendre. C’est la première comparaison à regarder.

La perte seule se compare mal, car elle dépend du découpeur en jetons (tokenizer). Deux conversions aident :

• La perplexité est l’exponentielle de la perte : à peu près le nombre de jetons entre lesquels le modèle hésite à chaque étape.
• Les bits par octet (bits per byte, bpb) divisent par le nombre d’octets par jeton, pour qu’on puisse comparer des modèles aux découpeurs différents. Plus bas, c’est mieux. nanochat en fait son chiffre principal.

import math

loss_nats = 2.05        # perte de validation par jeton, tirée de votre journal d'entraînement
bytes_per_token = 3.1   # moyenne, mesurée sur votre texte de validation
print("perplexité", round(math.exp(loss_nats), 1))
print("bits par octet", round(loss_nats / math.log(2) / bytes_per_token, 3))

Ces valeurs d’exemple donnent une perplexité de 7,8 et 0,954 bit par octet. Pour situer, les meilleures exécutions de niveau GPT-2 au classement de nanochat tournent autour de 0,72. La perte est en « nats », ce que donne la fonction d’entropie croisée standard de PyTorch, et la division par le logarithme naturel de 2 convertit en bits. Comparez seulement des exécutions notées sur le même texte de validation.

Niveau 2 : à quoi cela ressemble-t-il?

Gardez une feuille fixe d’une vingtaine de prompts et exécutez-la à chaque point de contrôle : un début d’histoire, un fait, une addition, une question à prémisse fausse, une en français si cela vous importe. Utilisez les mêmes réglages chaque fois et lisez les résultats côte à côte. Vous remarquerez la répétition, le non-sens et les faits inventés qu’aucun chiffre ne montre. Rappelez-vous qu’un modèle préentraîné sans entraînement au clavardage ne fait que prolonger le texte : donnez-lui donc le début d’une phrase plutôt qu’une question.

Niveau 3 : comment se compare-t-il aux modèles connus?

Un banc d’essai est un examen standard dont on connaît les résultats pour d’autres modèles. Trois choses le rendent équitable : les mêmes questions, le même format et la même notation. Deux outils s’en occupent.

Les tests intégrés de nanochat sont les plus simples si vous l’avez utilisé pour l’entraînement. Son évaluation du préentraînement comprend CORE, une moyenne sur 22 bancs d’essai du projet de recherche DCLM, recalibrée pour que le hasard donne près de zéro et qu’un résultat parfait donne 1. Le CORE de GPT-2 est de 0,2565, et les récentes exécutions au classement de nanochat vont de 0,2571 à 0,2690. Ses tests de clavardage couvrent des tâches comme les sciences à choix multiple et les mathématiques scolaires :

python -m scripts.base_eval
python -m scripts.chat_eval -i sft

Sur plusieurs GPU, lancez-les avec torchrun, comme le fait le script speedrun du projet.

lm_eval d’EleutherAI est l’outil général, qui fonctionne avec tout modèle au format de Hugging Face, sur le Hub ou dans un dossier local. Un point de contrôle de nanochat utilise son propre format et devrait d’abord être converti.

pip install "lm_eval[hf]"
lm_eval --model hf \
    --model_args pretrained=./my-model \
    --tasks hellaswag \
    --device cuda:0 \
    --batch_size 8

Utilisez lm-eval ls tasks pour voir les noms offerts. À titre de repère, les auteurs de DCLM rapportent 64 % au MMLU, un vaste examen à choix multiple, pour un modèle de 7 milliards de paramètres avec 5 exemples résolus par question. Notez la façon de poser la question : des résultats avec des nombres d’exemples différents ne se comparent pas.

Les bancs d’essai ont leurs limites. Des questions se retrouvent dans les données d’entraînement : un résultat élevé peut donc refléter de la mémorisation. Un banc d’essai public dit aussi peu de choses sur une tâche précise, et un banc d’essai en anglais ne dit rien du français.

Niveau 4 : fait-il le travail pour lequel vous l’avez bâti?

Seuls vos propres tests peuvent y répondre. Notre guide pour bâtir un ensemble d’évaluation à partir de votre travail couvre la méthode, et le guide LoRA présente un script avant-après. Trois ajouts s’imposent pour un modèle entraîné par vous-même :

Quelle doit être la taille d’un écart pour que vous y croyiez?

Plus grande que la plupart des gens ne le pensent. Un résultat de banc d’essai tiré d’un échantillon de questions a une marge d’erreur, que vous pouvez estimer rapidement :

import math

def margin(p, n):
    return 1.96 * math.sqrt(p * (1 - p) / n)

print(round(margin(0.30, 500) * 100, 1))   # 4.0
print(round(margin(0.30, 100) * 100, 1))   # 9.0

À 30 % d’exactitude sur 500 questions, l’échantillon par défaut de nanochat par tâche CORE pendant l’entraînement, la marge à 95 % est d’environ 4 points de pourcentage de chaque côté. Ainsi, 31 % contre 30 % sur une tâche ne veut rien dire. Sur 100 questions, la marge est de 9 points. La moyenne de nombreuses tâches la réduit, mais son auteur prévient quand même que CORE peut être un peu bruyant, et c’est pourquoi le classement demande aussi les bits par octet de validation.

Trois habitudes aident. Exécutez le banc d’essai complet pour toute comparaison que vous comptez publier. Entraînez deux fois avec des germes aléatoires différents si votre budget le permet : si deux exécutions d’une même recette diffèrent autant que votre « amélioration », vous n’avez pas démontré d’amélioration. Et changez une chose à la fois, pour pouvoir dire ce qui a causé l’écart. Quand vous publiez, indiquez les noms des bancs d’essai, la taille des échantillons et les réglages à côté des résultats.