Les leçons d’apprentissage automatique que j’ai apprises ce mois-ci

) dans le travail d’apprentissage automatique sont les mêmes.

Coder, attendre les résultats, les interpréter, revenir au codage. Plus quelques présentations intermédiaires de ses progrès à la direction*. Mais le fait que les choses soient essentiellement les mêmes ne signifie pas qu’il n’y a rien à apprendre. Bien au contraire ! Il y a deux ou trois ans, j’ai commencé à prendre l’habitude quotidienne d’écrire les leçons que j’ai apprises de mon travail de ML. Pourtant, jusqu’à ce jour, chaque mois me laisse une poignée de petites leçons. Voici trois leçons du mois dernier.

Se connecter avec les humains (aucun ML impliqué)

À l’approche des fêtes de Noël, les fêtes de fin d’année commencent. Souvent, ces réunions sont constituées de discussions informelles. Peu de « travail » est fait – ce qui est naturel, car il s’agit généralement d’événements après le travail. Habituellement, je saute de tels événements. Mais pour la période de Noël, je ne l’ai pas fait. J’ai participé à une réunion après le travail au cours des dernières semaines et j’ai juste parlé – rien d’urgent, rien de profond. La socialisation était bonne et je me suis beaucoup amusé.

Cela m’a rappelé que nos projets de travail ne fonctionnent pas uniquement sur du code et du calcul. Ils fonctionnent grâce au carburant de la collaboration avec les autres pendant longtemps. Ici, de petits moments – une blague, une histoire rapide, une plainte partagée concernant des GPU défectueux – peuvent ravitailler le moteur et rendre la collaboration plus fluide lorsque les choses deviennent tendues plus tard.

Pensez-y sous un autre angle : vos collègues doivent vivre avec vous pendant des années. Et toi avec eux. Si cela devait être un « roulement » – non, pas bon. Mais si c’est un « ensemble » – oui, c’est définitivement bien.

Alors, lorsque les invitations à une réunion de votre entreprise ou de votre institut de recherche arrivent dans votre boîte aux lettres : rejoignez-nous.

Copilot ne m’a pas forcément rendu plus rapide

Le mois dernier, j’ai mis en place un nouveau projet et adapté une liste d’algorithmes à un nouveau problème.

Un jour, alors que je perdais inconsidérément du temps sur le Web, je suis tombé sur une étude** du MIT suggérant que l’assistance (lourde) de l’IA, en particulier avant faire le travail – peut réduire considérablement le rappel, réduire l’engagement et affaiblir l’identification avec le résultat. Certes, l’étude a utilisé la rédaction d’essais pour atteindre l’objectif du test, mais coder un algorithme est une tâche tout aussi créative.

J’ai donc essayé quelque chose de simple : j’ai complètement désactivé Copilot dans VS Code.

Après quelques semaines, mes résultats (subjectifs et auto-évalués, donc fortement biaisés) étaient : pas de différence notable pour mes tâches principales.

Pour l’écriture des boucles d’entraînement, les chargeurs, l’anatomie de l’entraînement, je les connais bien. Dans ces cas, les suggestions de l’IA n’ajoutaient pas de vitesse ; ils ajoutaient même parfois des frictions. Pensez juste à corriger les sorties de l’IA qui sont presque correct.

Ce constat contraste un peu avec ce que j’ai ressenti il ​​y a un mois ou deux lorsque j’avais l’impression que Copilot me rendait plus efficace.

En réfléchissant aux différences entre les deux moments, il m’est venu à l’esprit que l’effet semble dépendant du domaine. Lorsque je suis dans un nouveau domaine (par exemple, la planification des charges), l’assistance m’aide à accéder plus rapidement au terrain. Dans mes domaines d’origine, les gains sont marginaux – et peuvent s’accompagner d’inconvénients cachés qu’il faudra des années pour remarquer.

Mon point de vue actuel sur les assistants IA (que je n’ai utilisés que pour le codage via Copilot) : ils sont bons pour rampe en haut vers un territoire inconnu. Pour le travail de base qui définit la majorité de votre salaire, c’est au mieux facultatif.

Ainsi, pour l’avenir, je peux en recommander d’autres à

• Écrivez vous-même le premier passage; utilisez l’IA uniquement pour le peaufinage (nommage, petits refactors, tests).
• Vérifiez honnêtement les avantages proclamés de l’IA : 5 jours avec l’IA désactivée, 5 jours avec celle-ci activée. Entre eux, suivez : les tâches terminées, les bugs trouvés, le temps nécessaire pour terminer, votre capacité à mémoriser et à expliquer le code un jour plus tard.
• Basculez du bout des doigts : associez un raccourci clavier pour activer/désactiver les suggestions. Si vous l’utilisez toutes les minutes, vous l’utilisez probablement de manière trop intensive.

Un pragmatisme soigneusement calibré

En tant que spécialistes du ML, nous pouvons trop réfléchir aux détails. Un exemple est le taux d’apprentissage à utiliser pour la formation. Ou, en utilisant un taux d’apprentissage fixe plutôt que de les décomposer à des étapes fixes. Ou s’il faut utiliser une stratégie de recuit cosinus.

Vous voyez, même pour le simple cas LR, on peut rapidement proposer de nombreuses options ; lequel doit-on choisir ? J’ai tourné en rond sur une version de ceci récemment.

Dans ces moments-là, cela m’a aidé à dézoomer : qu’est-ce que le utilisateur final ça t’intéresse ? Il s’agit principalement de latence, de précision, de stabilité et, souvent, avant tout, de coût. Ils ne se soucient pas de l’horaire LR que vous avez choisi – à moins que cela n’affecte ces quatre-là. Cela suggère une approche ennuyeuse mais utile : choisissez l’option viable la plus simple et respectez-la.

Quelques valeurs par défaut couvrent la plupart des cas. Optimiseur de base. Vanille LR avec un jalon de désintégration. Une règle simple d’arrêt précoce. Si les mesures sont mauvaises, passez à des choix plus sophistiqués. S’ils sont bons, passez à autre chose. Mais ne jetez pas tout sur le problème d’un seul coup.

* Il semble que même à Deepmind, probablement l’institut de recherche pure le plus performant (du moins auparavant), les chercheurs ont du management à satisfaire

** L’étude est disponible sur arXiv à l’adresse : https://arxiv.org/abs/2506.08872