Le Chemin Critique pour l’Automatisation du Développement de Modèles

Le prochain jalon important pour la recherche en intelligence artificielle est d’automatiser le développement de modèles. Chaque progrès dans le raisonnement, le langage et la perception est, d’une certaine manière, un pas vers cet objectif. Cependant, le chemin vers l’automatisation des modèles nécessite de résoudre un ensemble de défis fondamentaux qui doivent être résolus en premier lieu.

Le pont vers cet objectif passe directement par l’ingénierie de l’apprentissage automatique (ML). Une idée fausse commune est que le ML est une technologie précurseure de l’IA moderne et que les modèles de fondation l’ont simplement remplacé. Cela méconnaît la relation. En tant que discipline académique, le ML englobe tous les aspects de la formation de modèles, y compris la formation de modèles de fondation au centre de l’IA actuelle. Cependant, il y a une différence significative en termes d’échelle et de complexité des données.

Les modèles de ML traditionnels sont généralement formés sur des ensembles de données soigneusement sélectionnés, spécifiques à un domaine, contenant des milliers ou des millions d’exemples. Les modèles de fondation, en revanche, sont formés sur des milliers d’ensembles de données simultanément, issus de sources très différentes avec des formats, des provenances et des qualités incohérents. Cette différence d’échelle et d’hétérogénéité des données est une raison fondamentale pour laquelle la gestion des données devient beaucoup plus difficile et plus importante à mesure que les modèles deviennent plus puissants.

Cela rend la compréhension des données un goulet d’étranglement central dans l’automatisation du développement de modèles. Un système d’IA capable d’interpréter des données hétérogènes et d’améliorer les pipelines construits autour de lui pourrait, en principe, améliorer son propre processus de formation et aider à construire de meilleurs modèles. Une fois que l’IA peut améliorer le processus par lequel elle est formée, les améliorations se propagent en aval à chaque domaine où l’IA est appliquée.

Trois Barrières sur le Chemin

La première barrière est la fragmentation du contexte. Dans presque toutes les organisations, les signaux, les expériences, les définitions de fonctionnalités et les connaissances institutionnelles pertinentes pour un problème de modélisation donné sont dispersés dans des entrepôts de données, des cahiers et des pipelines qui n’ont jamais été conçus pour communiquer les uns avec les autres. Considérons un système de santé qui construit un modèle de détection de la sepsis. Les critères cliniques pertinents pour ce problème, tels que les seuils vitaux, les valeurs de laboratoire et les normes de documentation, peuvent vivre dans des modules entièrement distincts d’un système d’enregistrement électronique de santé.

La deuxième barrière est l’ambiguïté sémantique. Le sens n’est pas inhérent aux données, mais est plutôt contextuel et organisationnel. Le même nom de champ dans deux bases de données différentes peut faire référence à des choses légèrement différentes. Des concepts comme les revenus, les utilisateurs actifs et la rotation ont régulièrement plusieurs définitions valides au sein d’une même entreprise. Même un concept apparemment simple comme « revenu » peut causer des problèmes. Une équipe de vente peut définir les revenus comme la valeur totale des contrats signés ce trimestre, tandis que l’équipe financière les définit comme l’argent réellement reçu. L’équipe produit a une autre compréhension, car elle définit le terme pour signifier les revenus reconnus répartis sur une période d’abonnement. Les trois équipes tirent de champs littéralement nommés « revenu » dans leurs systèmes respectifs, mais un rapport inter-équipes les combinant mélangera silencieusement trois nombres incompatibles.

La troisième et plus systématique barrière est l’absence de mémoire organisationnelle documentée. La résolution des incohérences, le suivi de la provenance et le maintien de signaux de qualité à travers autant de sources est un problème non résolu, même pour les équipes humaines. Sans une mémoire institutionnelle de ce qui a été essayé et de la manière dont ces approches ont fonctionné, tout mécanisme d’automatisation de modèle continuera à redécouvrir les mêmes impasses, gaspillant du temps et des ressources.

Considérons une équipe de science des données dans une entreprise de détail qui construit un modèle de prévision de la demande. Au cours de trois ans, une douzaine d’analystes ont chacun découvert de manière indépendante que les données brutes sur le temps dégradent les performances du modèle pendant les semaines de vacances, qu’un flux d’inventaire d’un fournisseur particulier contient un décalage systématique et que l’approche standard pour gérer les événements promotionnels provoque une fuite de cible. Lorsque les analystes originaux sont passés à d’autres équipes ou ont quitté l’entreprise, les connaissances sont parties avec eux. Sans un enregistrement institutionnel de ce qui a été essayé, de ce qui a échoué et pourquoi, un mécanisme d’automatisation de modèle ne peut pas s’appuyer sur l’expérience accumulée. Il commence simplement à zéro, encore et encore, gaspillant inutilement du temps.

Ce qu’une Vraie Solution Exige

L’histoire de l’automatisation du ML est une histoire de solutions partielles. L’AutoML a résolu le problème étroit de l’ajustement des hyperparamètres, mais ne pouvait pas gérer les discordances d’objectifs ou raisonner sur l’intention organisationnelle. Le MLOps a rendu les pipelines de production plus robustes et plus faciles à surveiller, mais les outils MLOps exécutent une stratégie plutôt que de la définir. Les agents de codage plus récents représentent un véritable progrès, mais ils ont hérité du même angle mort. Ils génèrent du code bien tout en opérant sans contexte organisationnel ni mémoire institutionnelle.

Un système capable d’une véritable ingénierie de ML autonome aurait besoin de capacités que aucun outil existant ne fournit en combinaison. Il devrait mapper les objectifs commerciaux aux objectifs de modèle, ce qui est une traduction qui ne peut pas être déduite des données seules. Il devrait découvrir des données pertinentes à travers des systèmes fragmentés avec des schémas incohérents, tout en adhérant automatiquement aux contraintes de conformité, de gouvernance et de sécurité, plutôt que de demander aux humains de les gérer comme un processus distinct. Il devrait avoir une mémoire institutionnelle pour faire surface du travail existant, comprendre pourquoi les expériences passées ont été abandonnées et s’appuyer sur ce que les collègues savent déjà.

Des traces d’audit rigoureuses qui suivent la provenance à travers les versions de données, les définitions de fonctionnalités et les validations de code devraient être un mécanisme central pour ancrer le système dans ce qui s’est réellement passé. Et un tel système nécessiterait une conception réfléchie de l’interaction humaine dans la boucle. Non pas un choix binaire entre une automatisation complète et un contrôle manuel complet, mais un support pour des niveaux d’interaction variables en fonction de la tâche, des enjeux et de la confiance du système à chaque point de décision. L’automatisation qui contourne le jugement humain aux moments critiques n’est pas une fonctionnalité d’un système d’IA bien conçu ; c’est plutôt un mode de défaillance.

Ce que aucun laboratoire n’a encore résolu est la création d’une compréhension sémantique des données organisationnelles qui comprenne ce que les données signifient dans un contexte institutionnel spécifique. Le MCP résout le problème de connectivité. Il ne résout pas encore le problème de signification. Cela reste la frontière de recherche ouverte.

Ce qui Devient Possible

Les implications économiques de la résolution de ces problèmes sont importantes. Le développement de ML personnalisé nécessite aujourd’hui des praticiens spécialisés et des semaines d’itération, même pour des problèmes bien définis. Un système qui pourrait naviguer dans l’ensemble du flux de travail de manière autonome, de la définition du problème à la découverte de données, au développement de modèles et à l’évaluation de modèles, changerait dramatiquement cette équation, en compressant les délais et en ouvrant des cas d’utilisation à forte valeur qui sont actuellement trop intensifs en ressources pour être poursuivis. Les projets qui nécessitaient autrefois des équipes avec une expertise approfondie en ML travaillant pendant des semaines peuvent maintenant être terminés en quelques jours sans avoir à utiliser autant de temps d’experts en ML rares.

Les défis de la fragmentation du contexte, de l’ambiguïté sémantique et de la mémoire organisationnelle manquante ne sont pas uniques à l’entreprise de ML. Ils se manifestent sous des contraintes différentes dans la construction de pipelines de formation de modèles de fondation, où des milliers d’ensembles de données hétérogènes doivent être agrégés, filtrés et raffinés de manière itérative. Même si les deux contextes diffèrent en structure et en objectif, les deux sont limités par le même goulet d’étranglement sous-jacent : l’absence de systèmes qui peuvent récupérer de manière fiable le contexte, suivre la provenance et s’appuyer sur le travail antérieur à travers les itérations. L’automatisation du développement de modèles dans l’entreprise est donc une étape critique sur le chemin vers des systèmes d’IA capables de s’améliorer eux-mêmes.