Comment Nommer Vos Tenseurs Pour Déboguer Zéro Stress

Avouons-le — débugger du code de réseau de neurones, c'est déjà assez difficile sans se battre contre des noms de variables incompréhensibles. Vous connaissez sûrement ça : vous regardez outputs, et vous vous demandez si c'est batch en premier ou en dernier, si la dimension séquence est incluse, ou si quelqu'un a reshapé ça quelque part sans vous prévenir.

Il y a mieux. Et c'est simplissime.

Les Shape Suffixes, Késako ?

Les shape suffixes, c'est des lettres minuscules ajoutées aux noms de vos variables tensorielles pour décrire leurs dimensions. Au lieu de outputs, vous écrivez outputs_bc. Au lieu de activations, vous écrivez activations_bcn.

Premier réflexe : "Encore du travail en plus ?" Spoiler : c'est exactement l'inverse. C'est une des conventions les plus rentables pour vos projets machine learning.

Le Dico Des Dimensions

Voici l'alphabet standard :

• b — dimension batch
• p — position ou index dans la séquence
• n — dimension neurone (généralement le résultat d'une multiplication matricielle)
• c — dimension channel
• h — hauteur (pour les tenseurs image)
• w — largeur (pour les tenseurs image)
• d — profondeur (pour la donnée 3D)
• k — dimension kernel

Donc logits_bc vous dit immédiatement que c'est un batch de logits avec des channels — idéal pour de la classification. positional_embeddings_bpn signifie batch, position, puis neurones dans cet ordre.

Pourquoi Ça Change Tout

Contexte instantané. Quand vous voyez probs_bc, vous savez instantanément que ce sont des probabilités organisées par batch et par classe. Pas de devinette, pas de recherche dans la doc.

Détection d'erreurs intégrée. Là ça devient puissant. Si vous écrivez outputs_bc = torch.matmul(activations_bcn, weights_bcn), l'incohérence vous saute aux yeux. Votre matrice de poids devrait être weights_nc pour multiplier proprement avec activations_bcn. Les noms eux-mêmes deviennent un vérificateur de types statique pour vos formes de tenseurs.

Documentation qui ne devient jamais obsolète. Les commentaires finissent par dater. Personne ne les met à jour après un refactor. Mais embeddings_bpn reste précis tant que vous tenez la convention — parce que le nom de la variable EST la documentation.

Reviews plus fluides. Les reviewers repèrent les incohérences de dimensions dans les pull requests sans exécuter le code ni tracer les appels de fonctions. Tout le monde y gagne, et les bugs sont capturés plus tôt.

Patterns Pratiques À Adopter

Pour les concaténations et stacks : Quand vous combinez des tenseurs, ajustez le suffixe pour refléter la nouvelle structure. Vous stackez deux tenseurs features_bc le long d'un nouvel axe ? Maintenant c'est features_bck ou features_bkc selon l'axe choisi.

Pour les réductions : Vous sumez sur la dimension position et votre inputs_bp devient inputs_b. Vous faites un argmax à travers les channels et logits_bc devient logits_b. Le suffixe rétrécit pour correspondre à la réalité.

Pour les tenseurs complexes : Vous pouvez empiler plusieurs codes : attention_bpp pour des scores d'attention sur des paires de positions, ou gradients_bpn pour des gradients organisés par batch, position et neurone.

Pour Que Ça Reste

Le secret c'est la constance. Choisissez la convention, appliquez-la partout — inputs, outputs, et chaque tenseur intermédiaire. Oui, même ce nom de variable d'une ligne que vous avez créé pour débugger un truc vite fait.

Votre vous du futur vous en sera reconnaissant. Vos collègues aussi.

Si vous bossez sur des applications ML et que vous voulez du code propre et maintenable qui scale avec votre équipe, ces petites conventions se cumulent en gains de productivité massifs. C'est le même principe qu'un bon naming n'importe où en développement — faites en sorte que le code se lise comme de la documentation.

Testez une semaine sur votre prochain projet. J'ai un doute qu'après ça, vous vous demandiez comment vous faisiez avant.