Deux réglages, un même GPU, une décision que vous pouvez expliquer.

1. Écrivez la question avant de préparer les variantes

Une comparaison utile répond à une décision précise : augmenter la longueur maximale évite-t-il les réponses coupées ? Un niveau de détail conserve-t-il les contours nécessaires ? Un groupe plus grand termine-t-il sans erreur ? Choisissez une question et un seul paramètre. « Trouver les meilleurs réglages » est trop large pour une première séance.

Appelez A la référence et B la variante. Notez la valeur exacte modifiée. Changer à la fois le modèle, les dimensions et le nombre de passes peut produire un résultat différent, sans révéler quelle modification l’explique. Gardez ces essais pour des comparaisons séparées.

2. Figez un petit corpus et les règles de jugement

Réunissez les mêmes entrées pour A et B. Une douzaine de cas peut suffire à une première décision bornée si elle comprend les difficultés du projet : texte fin dans une image, document long, donnée manquante ou format inhabituel. Ce nombre est un choix pratique, pas une garantie statistique. Évitez de n’inclure que les exemples qui réussissaient déjà.

Pour chaque entrée, écrivez avant le test les conditions de réussite. Distinguez une préférence de présentation d’un défaut bloquant. Dans un assistant documentaire, une réponse plus agréable peut rester refusée si elle invente une règle. Pour un visuel produit, une couleur séduisante ne compense pas la disparition d’un élément important.

Fixez aussi le nombre minimal de cas acceptés, les défauts interdits et le temps maximal de contrôle. Ces seuils propres au projet doivent rester identiques lorsque vous examinez les résultats.

3. Gardez la même séance et les mêmes dépendances

Conservez le modèle, sa version, les extensions, le moteur de calcul et les autres paramètres. Utilisez le même environnement et le même GPU, sans lancer un autre traitement entre les deux variantes. Notez ce que vous ne pouvez pas contrôler : activité concurrente visible, changement de version imposé ou chargement différent. Une comparaison affectée par ces changements demande plus de prudence.

Si l’outil utilise une graine aléatoire et permet de la fixer, conservez la valeur pour chaque paire de passages. Cela facilite une comparaison, mais ne promet pas une sortie identique partout. PyTorch indique que la reproductibilité complète n’est pas garantie entre versions ou plateformes, même avec une graine identique.

Créez deux dossiers, A et B, avec la même liste d’identifiants. Conservez les sorties brutes avant toute correction manuelle. Une retouche après coup doit apparaître comme une opération supplémentaire, avec son temps de travail, et non être attribuée au réglage qui a produit le fichier initial.

4. Faites un passage de contrôle, puis comparez les paires

Vérifiez d’abord qu’une entrée simple va jusqu’au fichier ou à la réponse récupérés. Ce passage contrôle la méthode. Signalez séparément un premier chargement ou une préparation particulière : ne comparez pas le démarrage complet de A avec un passage B dont tous les éléments sont déjà chargés.

Exécutez les mêmes cas pour A et B. Alternez l’ordre si l’outil le permet, puis rejouez quelques paires décisives dans l’ordre inverse. Vérifiez qu’un résultat isolé ou un avantage d’ordre ne commande pas toute la conclusion.

Consignez aussi les erreurs et les sorties refusées. Si B échoue sur une grande entrée, ne la retirez pas du tableau pour améliorer sa moyenne. Corrigez éventuellement la cause dans un essai B2 distinct. Vous conservez ainsi une comparaison lisible au lieu d’un dossier où la variante change au fil des difficultés.

5. Séparez le résultat accepté et le temps observé

Examinez d’abord la qualité à la taille ou dans l’outil d’usage. Si possible, masquez temporairement les noms A et B au moment du jugement. Une personne peut simplement consulter les sorties dans un ordre mélangé, puis rétablir leur correspondance. Gardez les critères annoncés et un motif court pour chaque refus.

Pour le temps, choisissez une définition unique : par exemple du lancement jusqu’à la sortie complète enregistrée. Séparez ensuite le contrôle humain et les corrections. Un chronomètre autour d’un appel GPU n’est pas toujours une mesure du calcul terminé : avec PyTorch/CUDA, les opérations peuvent être asynchrones. Utilisez la méthode de mesure documentée par l’outil si vous voulez isoler le calcul.

Si les répétitions se chevauchent ou si le chronométrage reste approximatif, notez « différence de durée non concluante ». Un petit écart sur une seule exécution ne justifie pas un pourcentage de gain présenté comme certain.

Exemple : 128 ou 256 nouveaux tokens pour un assistant documentaire

Une petite équipe veut des réponses complètes sur douze questions fixes. Elle garde le même modèle, les mêmes documents, la même consigne et le même GPU. Seule la limite de réponse change : A autorise 128 nouveaux tokens, B en autorise 256. Dans Transformers, max_new_tokens borne la génération sans compter les tokens du texte d’entrée. Un token n’est pas un mot : la limite ne définit pas un nombre exact de phrases.

Avant l’essai, l’équipe fixe une règle illustrative : au moins dix réponses acceptées sur douze et aucune règle inventée. Le tableau ci-dessous est un scénario fictif de lecture des résultats. Il ne décrit pas un assistant mesuré et ne prédit pas l’effet de ces valeurs sur votre modèle.

A atteint le minimum, B obtient davantage de réponses acceptées mais conserve un défaut critique. La décision est de garder A pour ce périmètre, avec relecture des réponses, et de rechercher la cause du défaut de B avant une autre comparaison. La longueur supérieure n’est ni une preuve de qualité ni la cause certaine de l’invention.

L’équipe rejoue les questions qui différencient A et B et deux questions déjà réussies. Si le défaut apparaît aussi avec A, elle suspend le verdict : le corpus initial n’avait pas suffi à établir la stabilité. Elle conserve la trace des deux passages au lieu de ne garder que le plus favorable.

Évitez les conclusions que votre test ne permet pas

Ne choisissez pas B parce qu’une de ses sorties est spectaculaire alors que les autres se dégradent. Ne changez pas le corpus en cours de route, ne comptez pas deux reprises comme deux entrées différentes et n’effacez pas un échec du dénominateur. Douze entrées présentées restent douze cas à expliquer, même si certains n’ont produit aucun fichier.

Le réglage retenu vaut pour les entrées, versions et critères examinés. Il peut ne plus convenir à un document dix fois plus long ou à des images différentes. Ajoutez progressivement des cas représentatifs. Cette progression étend le contrôle ; elle ne transforme pas un petit test en certification du système.

Conservez une décision courte et la prochaine vérification

Votre dossier final contient le corpus, les deux configurations, les sorties, les verdicts par identifiant et quelques lignes de conclusion. Indiquez le réglage retenu, la raison et la limite : « A conservé sur ces douze questions ; deux réponses restent à revoir ; les documents longs supplémentaires ne sont pas couverts ». Une autre personne doit pouvoir comprendre le choix sans assister à la séance.

Conservez A comme témoin pour le prochain diagnostic. Si aucune variante ne satisfait les critères, n’en retenez aucune pour la livraison ; formulez une nouvelle hypothèse. Réservez le temps de copie et de contrôle avant de lancer cette suite. Un essai terminé avec une limite claire apporte déjà une décision ; il n’oblige pas à poursuivre jusqu’à trouver un gagnant.