Ingénieur en apprentissage automatique — tâches, une par une

Construire un modèle pour le problème

Deux forces, et une seule est ce que ce site appelle d'ordinaire de l'automatisation. L'outillage a réellement automatisé la recherche — le choix d'architecture et d'hyperparamètres est devenu un travail que l'on configure plutôt que l'on exécute. La force la plus grande est d'une autre nature : énormément de problèmes qui exigeaient d'entraîner quelque chose se règlent désormais en appelant un modèle que quelqu'un d'autre a entraîné. La tâche n'est pas devenue faisable par machine ; son produit est devenu achetable.

Les quatre directions de ce site ne peuvent pas distinguer ces deux mécanismes, et la différence compte pour quiconque planifie à partir de cette page : une tâche devenue achetable peut redevenir non achetable quand le prix, la licence ou la capacité du fournisseur bouge, d'une façon qu'une tâche qu'une machine a apprise à faire ne peut pas. Cela ne dit rien non plus des domaines où un modèle acheté n'est pas une option — étroits, propriétaires, contraints en latence ou réglementés — et ils ne sont pas rares.

Décider ce qui compte comme assez bon

La justesse d'un système appris ne peut pas être définie, seulement mesurée — l'instrument de mesure est donc le livrable, et il doit être bâti par quelqu'un qui sait ce que coûte une erreur ici. Un banc d'essai que le modèle a déjà vu ne mesure rien, ce qui fait de la construction d'un jeu de test honnête un travail adversarial plutôt qu'une collecte de données. C'est la tâche qui s'est raréfiée à mesure que les modèles s'amélioraient, parce que plus la chose jugée est difficile, plus le jugement est difficile.

Un jugement sur la nature du travail, non une mesure de la façon dont il est doté en personnel. Beaucoup d'équipes ne le font pas du tout et mettent en production sur la foi du résultat de référence publié par le fournisseur : c'est exactement la défaillance décrite ici, non une preuve du contraire — mais combien elles sont, personne ne le compte.

Obtenir des données dont la chose puisse apprendre

L'annotation assistée par modèle et la génération synthétique ont retiré l'essentiel du volume ici, et c'est réel : ce qui demandait une équipe pendant des semaines est souvent un premier passage en une après-midi. Ce qui ne s'est pas transféré est de savoir quels exemples la méthode de collecte n'a jamais eu la moindre chance de contenir — une absence est invisible pour tout outil qui ne lit que ce qui est là.

Rien ici ne mesure le temps que cela prend dans une équipe donnée, et la réponse diffère d'un ordre de grandeur entre une équipe dotée d'un actif de données existant et une équipe qui part de rien. Utiliser un modèle pour annoter les données qui entraînent un modèle a aussi des modes de défaillance connus que ce jugement ne pèse pas.

Quand cela cesse discrètement de fonctionner

La détection s'est réellement améliorée : les outils de surveillance font remonter un décalage de distribution mieux et plus tôt qu'une personne qui regarde des tableaux de bord. Décider quoi en faire n'a pas bougé, parce que les options s'échangent en termes d'affaires — réentraîner coûte de l'argent et peut empirer les choses, éteindre a un coût visible aujourd'hui, et ne rien faire est aussi une décision.

Cela ne dit rien de savoir si les équipes surveillent réellement. Un modèle qui tourne sans surveillance pendant un an est courant et ce jugement ne le capture pas — là où personne ne regarde, cette tâche n'est pas conduite par l'humain, elle n'est simplement pas faite.

Façonner les entrées à la main

Celle-ci était largement terminée avant la période que ce site mesure. L'apprentissage de représentations a remplacé les attributs conçus à la main en vision, en parole et en texte au cours des années 2010, et le motif s'est étendu depuis aux problèmes tabulaires et séquentiels. Elle figure sur la page parce que c'est encore ce qu'enseigne une grande part du matériel de formation : les gens arrivent donc en s'attendant à ce que ce soit le métier.

Ce n'est pas du tout une preuve sur la fenêtre 2022-2026 ; c'est plus ancien et c'est consigné ici pour se repérer. La conception d'attributs propres à un domaine reste aussi porteuse dans certains cadres réglementés où une entrée inexplicable n'est pas permise, ce que ce jugement ne sépare pas.

Répondre de ce que cela fait aux personnes

Un travail nouveau, et il arrive de la réglementation plutôt que de la capacité : plusieurs marchés attachent désormais des devoirs aux systèmes utilisés en recrutement, en crédit, en éducation et dans les services publics, y compris l'exigence que celui qui en déploie un veille à ce que ses données d'entrée soient pertinentes et suffisamment représentatives pour la finalité. Un devoir de cette forme doit retomber sur une personne qui comprend ce que le modèle a réellement consommé, et le site détient un enregistrement vérifié d'une telle clause entrée en vigueur — rattaché à la page du déployeur, `business-systems-owner`, parce que c'est lui que la clause nomme.

L'enregistrement vers lequel ce raisonnement pointe n'est pas rattaché à ce métier, et délibérément : l'obligation nomme le déployeur, et la rattacher ici affirmerait qu'elle retombe sur les ingénieurs alors que dans la plupart des organisations personne ne leur a encore dit qu'elle retombait sur eux. C'est donc une inférence sur l'endroit où le travail se situera, non une preuve qu'il s'y situe déjà. Les exigences diffèrent aussi fortement selon le marché et selon l'usage du système.