LO
Être averti quand un dossier vérifié arrive sur ce métier →
Ingénieur en apprentissage automatique
Livre des systèmes dont le comportement est appris plutôt qu'écrit — ce qui veut dire que personne ne peut dire ligne à ligne pourquoi ils font ce qu'ils font, et que quelqu'un doit tout de même décider s'ils sont assez bons pour être utilisés sur des personnes.
Ce n'est pas une probabilité de perdre votre emploi. Il combine la part de la charge de tâches du poste exposée à l'automatisation avec le chemin réellement parcouru par l'adoption — utile pour comparer des métiers sur une même base cohérente, et pour rien d'autre.
Écrit pour les ingénieurs qui construisent, évaluent et exploitent des systèmes appris — recommandation, classement, vision, parole, fraude, prévision, et de plus en plus des applications bâties sur un modèle acheté. Cette page se situe à part des autres pages informatiques sur un autre axe : celles-là coupent par couche ou par séniorité, celle-ci par ce que vous livrez. Les chercheurs qui produisent de nouvelles méthodes, et ceux qui sont responsables du déploiement de l'IA dans une entreprise, sont d'autres métiers avec leurs propres pages — `ai-researcher` et `ai-implementation-lead`.
La base de preuves contient des dossiers vérifiés pour d'autres métiers, mais aucun encore pour celui-ci. En attendant, l'analyse ci-dessous est un raisonnement sur la structure des tâches et sur des capacités techniques connues — pour ce métier en particulier elle n'est pas appuyée par des sources traçables, et nous préférons le dire plutôt que citer des choses que nous n'avons pas vérifiées. Une section vide ici est un trou dans notre couverture, non un constat sur le travail.
Ce qui change réellement#
L'unité d'analyse est la tâche, non l'intitulé du poste. Un poste n'est pas remplacé — sa composition en tâches se déplace.
C'est votre métier ? Dites-le et cette page se resserre sur votre part de celui-ci.
Un intitulé de poste est un paquet de tâches achetées ensemble, et deux personnes n'ont jamais le même paquet. Rien n'est envoyé où que ce soit — cela reste dans ce navigateur.
Construire un modèle pour le problème
En cours d'automatisation≈ Estimation de la plateformeChoisir une architecture, l'entraîner sur vos données, la régler jusqu'à ce que les chiffres bougent.
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
Encore menée par des humains≈ Estimation de la plateformeBâtir le jeu de test, choisir la métrique, et dire si cette chose peut déjà être utilisée sur de vraies personnes.
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é. Beaucoup d'équipes ne le font pas du tout et livrent sur un banc d'essai publié par un fournisseur, ce qui est la défaillance décrite ici plutôt qu'une preuve contraire — mais nous ne détenons aucun enregistrement qui en compte le nombre.
Obtenir des données dont la chose puisse apprendre
Augmentée≈ Estimation de la plateformeCollecter, annoter, nettoyer et décider ce qu'on laisse de côté — et remarquer quand les données disent autre chose que le monde.
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
Augmentée≈ Estimation de la plateformeLa dérive, une entrée modifiée en amont, un motif saisonnier que les données d'entraînement n'ont jamais vu — et la décision de réentraîner, de revenir en arrière, ou d'éteindre.
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
En cours d'automatisation≈ Estimation de la plateformeConcevoir à la main, depuis un savoir métier, les signaux dérivés dont un modèle apprend.
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
Nouvelle tâche≈ Estimation de la plateformeExpliquer une décision que le système a prise sur quelqu'un, montrer que les entrées étaient adaptées à la finalité, et être la personne nommée quand c'est contesté.
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.
Quelles technologies comptent ici#
Quatre signaux distincts. Ils ne sont délibérément pas additionnés — un métier exposé à deux technologies n'est pas deux fois plus exposé.
Comment on en est arrivé là#
L'indice n'est pas un nombre figé. Voici où il se serait situé à chaque jalon de capacité depuis ChatGPT — reconstitué, et étiqueté comme tel.
● 1 événement vérifié pour ce métier, placé à la date où il s'est produit — les parties de la courbe proches d'un repère sont ancrées à quelque chose de vérifiable.
La seule courbe de ce site qui monte vite puis redescend, et les deux moitiés ont un mécanisme identifié. Elle part haut parce que les caractéristiques conçues à la main étaient déjà déplacées avant le début de cette période — l'apprentissage de représentations a fait cela dans les années 2010, pas l'IA générative. La montée abrupte de 2023-2024 n'est pas une machine qui apprend à faire ce métier : c'est une large part des problèmes qui acquiert un substitut achetable, donc l'objet sur mesure a cessé d'être nécessaire. La baisse depuis 2025 est l'autre moitié du même mouvement — une fois le modèle acheté, ce qui reste est de juger s'il marche sur votre problème, et cela est devenu plus difficile à mesure que les systèmes gagnaient en capacité, parce qu'une réponse fausse mais plausible est plus dure à attraper qu'une réponse manifestement fausse. Lisez le pic comme le moment où l'ensemble de tâches classique était le moins cher à remplacer, non comme un maximum vers lequel ce métier serait en train de revenir.
Une courbe plate n'est pas une prévision de sécurité. Elle dit quelles tâches l'automatisation a atteintes jusqu'ici — les métiers qui ont le moins bougé ici sont ceux où la contrainte est physique ou réglementaire, et les deux peuvent changer.
Changements récents#
Soixante-quinze compétitions Kaggle d'ingénierie de l'apprentissage automatique — entraîner des modèles, préparer des jeux de données, mener des expériences — notées face aux références humaines du classement public de chaque compétition : la comparaison se fait donc avec les gens qui ont réellement concouru. Le montage le plus performant au moment de la rédaction (o1-preview avec l'échafaudage AIDE) a atteint au moins le bronze dans 16.9 % des compétitions ; les auteurs rapportent aussi que la mise à l'échelle des ressources et la contamination du pré-entraînement modifient l'une comme l'autre ce chiffre, et le banc d'essai est en source ouverte, donc n'importe qui peut le relancer sur un modèle plus récent. Deux limites sont structurelles plutôt qu'accessoires : une compétition Kaggle arrive avec le problème déjà posé, la métrique déjà choisie et les données déjà collectées, ce qui est justement la part de ce métier que le banc d'essai ne peut pas tester ; et OpenAI a construit le banc d'essai et vend des modèles qu'il mesure.
Une démonstration, un référentiel ou un article montre que la tâche peut être faite. Cela met à jour ce que la technologie sait faire — pas ce que les employeurs feront.
Ce que cela veut dire pour vous#
L'essentiel de ce qu'un cours enseigne — architectures, réglage, conception d'attributs — est la part que cette page marque comme déplacée, et l'une d'elles l'a été avant que vous ne commenciez vos études. La part rare est celle pour laquelle les cours ne savent pas facilement donner de devoirs : construire un test que le modèle n'a pas déjà vu, et dire à voix haute que quelque chose n'est pas encore assez bon. Approchez un système qui tourne sur de vraies personnes, même petit, plus tôt que cela ne paraît raisonnable.
Si votre valeur était de savoir quel modèle prendre, ce savoir s'est déprécié vite et continue de se déprécier. Si c'est de savoir comment ce domaine casse — ce que coûte ici une mauvaise réponse, quelles entrées manquent, ce que veut dire un chiffre plausible quand la population a changé — c'est la moitié qui s'est raréfiée, parce que la chose à juger est devenue plus difficile à juger. La version inconfortable : une grande part du recrutement récent du domaine porte sur des gens capables de bien appeler une interface de programmation, ce qui est un autre métier avec un autre plafond.
Vos options#
Quatre directions, chacune avec ses contraintes réelles et une chose que vous pouvez tester cette semaine. Continuer comme aujourd'hui est un choix légitime — il faut simplement que ce soit un choix.
Détenez l'instrument de mesure
Quand le modèle est acheté, l'évaluation est la seule chose qui reste vôtre — et un jeu de test bâti depuis vos propres échecs n'est pas quelque chose qu'un fournisseur peut livrer.
C'est un travail adversarial dirigé contre le produit de votre propre équipe, ce qui coûte socialement dans une entreprise qui mesure le progrès par les lancements.
Prenez le banc d'essai que votre équipe cite et découvrez si ses données pouvaient se trouver dans le jeu d'entraînement du modèle. Si vous ne pouvez pas l'exclure, le chiffre veut dire moins que l'équipe ne le pense.
Allez là où un modèle ne peut pas s'acheter
Domaines étroits, données propriétaires, budgets de latence serrés, et cadres où une entrée inexplicable n'est pas permise — dans tous, le substitut achetable n'existe pas, et le savoir-faire classique reste le savoir-faire.
Ces domaines récompensent une profondeur dans autre chose que l'apprentissage automatique — physique, médecine, marchés, matériel — et cette profondeur prend des années qu'on ne raccourcit pas.
Trouvez dans votre industrie un problème où un modèle généraliste fait mesurablement moins bien qu'un petit modèle spécifique, et écrivez pourquoi. Si vous n'en trouvez pas, c'est aussi une réponse.
Prenez l'obligation avant qu'elle ne soit attribuée
Des devoirs s'attachent aux systèmes appris utilisés sur des personnes, et ils exigent quelqu'un capable de montrer ce que le modèle a consommé et pourquoi c'était adapté à la finalité. Dans la plupart des équipes, cette personne n'existe pas encore.
C'est une responsabilité avant d'être un intitulé, et les exigences diffèrent selon le marché — la prendre suppose de lire le texte réel d'une obligation, non son résumé.
Choisissez un modèle que votre entreprise fait tourner sur de vraies personnes et écrivez, en une page, sur quelles données il a été entraîné et qui a décidé que c'était approprié. Remarquez le temps que prennent les blancs.
Questions fréquentes#
Les parties bougent ici en sens opposés, ce qu'un chiffre unique cacherait. Entraîner un modèle sur mesure est déplacé pour une grande part des problèmes, et non par une machine qui a appris à le faire — par le produit devenu achetable, soit un déplacement réversible. Juger si un système appris est assez bon est devenu plus difficile et plus rare en même temps. Un signal vérifiable par vous : sur vos trois derniers travaux, combien ont fini en modèle entraîné et combien en jugement sur un modèle entraîné par quelqu'un d'autre. Le second chiffre est la direction que prend le métier.
En partie, et il vaut la peine d'être précis sur quelle partie, parce que le mécanisme est inhabituel. Ce qui a disparu est l'objet sur mesure, non une capacité humaine : votre problème a désormais un substitut achetable. Ce genre de perte s'inverse — le prix, la licence, la limite d'usage ou la capacité d'un fournisseur bouge et le travail revient — ce qui n'est pas vrai d'un travail qu'une machine a réellement appris à exécuter. Ce qui n'a pas disparu est de savoir dire si le substitut fonctionne réellement sur votre problème, et cela est devenu plus difficile dans le même mouvement.
Poser cela comme un choix entre deux savoir-faire est ce qui rend la question difficile. La position durable dans les deux est la même : être la personne dont le jugement sur le bon fonctionnement de la chose est écouté. Ce qui diffère est le prix d'entrée — construire par-dessus n'en a presque aucun aujourd'hui, raison pour laquelle cette voie est encombrée et pour laquelle son plafond est fixé par votre capacité à distinguer un bon résultat d'un résultat plausible. Si vous ne pouvez bien faire qu'une chose, faites le jugement.
La demande et l'exposition sont deux questions différentes et cette page ne répond qu'à la seconde, ce qui mérite d'être dit parce qu'on les confond couramment. L'observation honnête est que l'intitulé couvre désormais deux métiers aux plafonds différents — l'un qui entraîne et évalue des systèmes, l'autre qui assemble des applications sur un modèle acheté — et les offres les distinguent rarement. Avant d'accepter un poste, demandez ce que l'équipe a livré le trimestre dernier et si quelqu'un lui a bâti un jeu de test. La réponse vous dit lequel des deux métiers l'intitulé désigne là-bas.
Vous étudiez pour cela ?
Ces filières mènent ici. Leurs pages détaillent lesquelles de leurs compétences se transfèrent et ce qui manque généralement aux diplômés.
Méthode et sources#
- Date d'évaluation
- 2026-09-12
- Fondement des jugements de tâche
- 0 appuyés sur des preuves · 6 inférence de plateforme · 0 preuves insuffisantes
- Événements vérifiés
- 1