Lorsque les entreprises déploient des outils d'IA d'entreprise, elles constatent souvent que leur lac de données est peut-être profond, mais qu'il est désordonné. Même si elles commencent avec des données soigneusement curatées, une mauvaise gestion des changements de données peut avoir de graves conséquences en aval.
Chad Sanderson est le PDG et fondateur de Gable.ai, où il aide les organisations à améliorer la qualité des données à grande échelle.
J'ai pu discuter avec lui de l'importance de la qualité des données et de la manière dont les contrats de données peuvent garantir que les applications basées sur de grandes quantités de données conservent leur intégrité.
Q : Vous êtes journaliste de formation. Pouvez-vous nous dire comment vous vous êtes retrouvé dans le domaine des données et comment vous vous êtes passionné pour la science des données et la qualité des données ?
Chad Sanderson : "La science des données est quelque chose que j'ai commencé à pratiquer en tant que journaliste parce que je gérais mon propre site web et que j'avais besoin de mettre en place des analyses web. J'ai appris tous les GA4, j'ai commencé à faire des tests A-B, une science des données très basique. Et puis j'ai tellement aimé ça que j'en ai fait mon travail à plein temps, j'ai appris les statistiques moi-même, et j'ai fini par travailler pour Oracle en tant qu'analyste et data scientist.
Ensuite, j'ai commencé à gérer des équipes dans le domaine des données. Au début, il s'agissait plutôt d'équipes d'expérimentation et d'analyse. Puis j'ai commencé à m'intéresser à l'ingénierie des données et enfin à l'infrastructure, aux plates-formes d'infrastructure de données.
J'ai donc travaillé sur la plateforme d'intelligence artificielle de Microsoft. J'ai également dirigé la plateforme d'IA et de données d'une entreprise de technologie de transport de marchandises en phase finale de développement, Convoy.
Q : Vous avez récemment parlé à MDS Fest des contrats de données et de la manière dont ils permettent aux entreprises d'avoir une gouvernance fédérée des données. Pouvez-vous nous expliquer brièvement de quoi il s'agit ?
Chad Sanderson : "Les contrats de données sont une sorte de mécanisme de mise en œuvre de la gouvernance et de la gestion fédérées des données.
Fondamentalement, dans l'ancien monde, donc dans le monde hérité, on-prem, il y a 20 ans, vous aviez des architectes de données qui construisaient tout l'écosystème de données d'une entreprise, en commençant par les bases de données transactionnelles, les systèmes ETL, tous les divers mécanismes qui transforment les données et les préparent essentiellement pour l'analyse, la science des données et l'IA.
Toutes ces données ont été fournies aux scientifiques par une équipe centralisée. C'est un peu comme si un bibliothécaire s'occupait d'une bibliothèque.
Ils s'assurent de l'entrée et de la sortie des livres, de leur organisation, ce qui permet aux chercheurs de trouver facilement les informations dont ils ont besoin pour leurs projets.
Mais ce qui s'est passé 15 ans plus tard, 20 ans plus tard, c'est que nous sommes passés à l'informatique en nuage et aux ingénieurs en logiciel, et que le logiciel a mangé le monde, comme le dit Mark Andreessen, et que chaque entreprise a décidé de devenir une entreprise de logiciels. La façon dont les entreprises géraient les activités logicielles consistait à laisser les équipes d'ingénieurs aller aussi vite que possible pour créer des applications de façon très itérative et expérimentale.
Cela signifie que toutes les données générées par ces applications n'étaient plus soumises à l'architecte de données qui planifiait la structure et la manière dont elle était conçue et organisée. Il suffisait de prendre toutes ces informations et de les jeter dans un endroit appelé lac de données. Et ce lac de données était très désordonné.
La responsabilité de donner un sens à toutes ces informations marécageuses incombait à l'ingénieur des données. On vit donc un peu dans les deux mondes, avec une couche d'application décentralisée et totalement fédérée, une couche de données très, très centralisée et des équipes d'ingénierie des données qui font de leur mieux pour donner un sens à tout cela.
Le contrat de données est un mécanisme permettant aux équipes de données en aval et aux équipes d'ingénierie des données de dire, hé, nous commençons à utiliser ces données d'une manière particulière.
Nous avons des attentes à leur égard. Cela signifie que les ingénieurs qui créent les données se les approprient de la même manière qu'un architecte de données se serait approprié l'ensemble du système un an auparavant. C'est ce qui permet à la gouvernance de s'étendre, à la qualité de s'étendre.
Sans cela, on se retrouve dans une situation très chaotique".
Q : Il s'agit d'une situation de type "garbage in garbage out". Si vous modifiez un tout petit élément de vos données, cela peut avoir de profondes ramifications en aval.
Chad Sanderson : "Oui, c'est tout à fait exact. Et il y a beaucoup d'entreprises dont les modèles d'IA ont eu des impacts vraiment malheureux à cause de changements relativement mineurs que les développeurs d'applications ne considèrent pas comme un problème majeur.
Par exemple, disons que vous collectez l'anniversaire d'une personne pour lui envoyer automatiquement un message d'anniversaire très sympathique.
Il se peut que vous stockiez les informations relatives à l'anniversaire sous la forme de trois colonnes (mois d'anniversaire, année d'anniversaire et date d'anniversaire). Vous prenez toutes ces informations et vous pouvez les utiliser à votre guise. Mais si l'ingénieur dit, vous savez quoi, diviser ces informations en trois colonnes différentes est stupide.
Je veux juste une colonne pour la date. Cela ne pose aucun problème. Et c'est ce qu'ils vont faire parce que cela rend leur application plus facile à utiliser.
Mais toute personne en aval qui utilise ces données s'attend à ce qu'il y ait trois colonnes. Si demain, ils n'en obtiennent qu'une seule et que les deux colonnes qu'ils utilisaient ont disparu, tout ce qu'ils avaient construit sera réduit à néant.
C'est le genre de choses qui se produisent constamment dans les entreprises".
Q : Vous êtes le PDG d'une entreprise appelée Gable. Quels sont les principaux défis auxquels les entreprises sont confrontées et que vous espérez résoudre ? Comment votre plateforme répond-elle à certains de ces problèmes ?
Chad Sanderson : " Le plus grand défi que nous avons entendu de la part de la plupart des entreprises qui se lancent dans l'espace de l'IA et de la ML, au moins du côté des données, est en fait de deux ordres. La première est la propriété. Cela signifie que si je suis quelqu'un qui construit des systèmes d'IA, je construis les modèles, j'ai besoin de quelqu'un qui prenne en charge les données que j'utilise et qui s'assure que ces données sont traitées comme une API.
Si vous êtes un ingénieur logiciel et que vous vous appuyez sur l'application de quelqu'un d'autre, vous le faites par l'intermédiaire d'une interface. Cette interface est bien documentée. Ses attentes sont très claires.
Il existe des accords de niveau de service. Le système est censé fonctionner pendant un certain temps. S'il y a des bogues, quelqu'un les corrige.
C'est la raison pour laquelle vous pouvez vous sentir à l'aise lorsque vous dépendez d'applications qui ne sont pas seulement celles que vous avez construites. Dans le domaine des données, c'est ce que nous faisons lorsque nous extrayons des données de l'ensemble des données de quelqu'un d'autre, comme une base de données par exemple. Nous construisons ensuite un modèle au-dessus de ces données.
Nous dépendons d'une interface, mais aujourd'hui il n'y a pas beaucoup de propriété sur cette interface. Il n'y a pas de véritable accord de niveau de service. Il n'y a pas beaucoup de documentation.
Elle peut changer à tout moment. Si c'est ainsi que fonctionnent les API, tout l'écosystème de l'internet serait en proie au chaos. Rien ne fonctionnerait.
C'est donc ce que beaucoup d'entreprises et d'équipes chargées des données recherchent en ce moment, c'est-à-dire la possibilité d'avoir confiance dans le fait que les données qu'elles utilisent seront les mêmes demain que celles d'hier. C'est un premier élément. L'un des résultats essentiels est la qualité des données.
Nous tenons à ce que les données correspondent à nos attentes. Supposons que je travaille sur des données d'expédition et que je consomme des informations sur les distances d'expédition pour le fret. Je m'attendrais toujours à ce que cette caractéristique de distance d'expédition signifie la chose que j'attends qu'elle signifie et ne signifie pas soudainement une chose différente, n'est-ce pas ?
Si je dis qu'il s'agit d'une distance d'expédition en miles, je ne veux pas que demain cela signifie soudainement des kilomètres parce que l'IA ne va pas savoir qu'elle est passée de miles à kilomètres. Elle n'a pas le contexte pour le comprendre.
L'objectif de Gable est de s'assurer que des attentes et des accords de niveau de service très clairs sont en place, que toutes les données utilisées par les équipes pour l'IA sont clairement détenues, et que l'ensemble de l'organisation comprend comment les différentes personnes au sein de l'entreprise utilisent les données et où l'amour et l'attention sont réellement nécessaires".
Q : L'accent est mis sur la qualité des données pour permettre l'IA, mais l'IA vous permet-elle de mieux faire cela ?
Chad Sanderson : "L'IA est géniale, franchement. Je pense que nous sommes au milieu d'un cycle d'engouement, sans aucun doute, 100%.
Les gens vont donc faire des affirmations farfelues sur ce que l'IA peut faire. Mais je pense que si l'on est réaliste et que l'on se concentre sur ce que l'IA peut faire à l'heure actuelle, il y a déjà beaucoup de valeur ajoutée pour notre entreprise en particulier. La principale valeur ajoutée de Gable, ce que nous faisons différemment des autres, c'est l'interprétation des codes.
Gable n'est pas un outil de données. Nous sommes un outil d'ingénierie logicielle conçu pour les complexités des données. Et nous pouvons interpréter le code qui produit finalement des données pour comprendre ce que fait ce code.
Si j'ai, disons, un événement émis par un système frontal, et que chaque fois que quelqu'un clique sur un bouton, il y a un code qui dit, hé, ce bouton a été cliqué. Je veux envoyer un événement appelé bouton cliqué dans une base de données. Puis, à partir de cette base de données, nous allons l'envoyer à notre lac de données.
Puis, à partir de notre lac de données, nous l'envoyons à la formation de modèles pour un système d'IA. Et ce que Gable peut faire, c'est dire que si un ingénieur logiciel décide de modifier la structure de l'événement "bouton cliqué" dans le code, ce qui aurait un impact sur tout le monde en aval, nous pouvons reconnaître que cela s'est produit au cours du processus DevOps.
Ainsi, lorsqu'un ingénieur logiciel consulte GitHub et apporte des modifications à son code, vous pouvez dire, oh, attendez une seconde, avant que vous n'apportiez cette modification, nous avons détecté que quelque chose n'allait pas ici.
Nous avons développé une grande partie de l'interprétation du code en utilisant davantage de méthodes basées sur l'apprentissage automatique et l'analyse statique.
Mais l'IA, qui est très douée pour reconnaître les conventions, comme les schémas de codage courants, est très efficace pour fournir un contexte sur les raisons qui poussent les gens à modifier leur code ou sur leurs intentions. Il y a donc de nombreuses façons intéressantes d'appliquer l'IA à notre produit en particulier".
Q : Si les entreprises veulent tirer parti de l'IA, elles auront besoin de données. Quelles sont, selon vous, les plus grandes opportunités pour les entreprises en matière de gestion et de développement de leurs données ? Comment peuvent-elles en tirer parti et s'y préparer ?
Chad Sanderson : "Je pense donc que toute entreprise qui souhaite tirer parti de l'IA doit élaborer une stratégie en matière de données. Et je pense qu'il y aura deux stratégies de données qui seront hyper pertinentes pour chaque entreprise.
La première est qu'à l'heure actuelle, les grands modèles itératifs, les LLM, les LLM publics que nous connaissons tous, comme les OpenAI, Cloud, Gemini, AnthropicIls utilisent tous principalement des données accessibles au public, des données que l'on peut obtenir sur l'internet.
Et cela est certainement utile pour un modèle large et général. Mais l'un des défis posés par ces LLM est ce que l'on appelle les fenêtres contextuelles, c'est-à-dire que plus ils ont d'informations à raisonner, moins ils sont performants. Par conséquent, plus la tâche est restreinte et plus le contexte est limité, plus ils sont efficaces.
C'est un peu comme une personne, n'est-ce pas ? Si je vous donne les informations d'un livre et que je vous interroge sur un paragraphe très précis de la page 73, votre capacité à vous en souvenir sera probablement faible. En revanche, si je ne vous donne qu'un seul chapitre à lire, il est probable que vous ferez un bien meilleur travail.
C'est pourquoi je pense que beaucoup de ces modèles généraux ne seront pas aussi utiles pour les grandes entreprises. Nous allons commencer à voir des modèles de plus en plus petits qui sont davantage axés sur le contexte. Ils sont donc basés sur des contextes plus restreints.
Et la façon d'obtenir un contexte finement ajusté et de haute qualité est d'obtenir d'excellentes données sur cette chose spécifique, quelle qu'elle soit, que vous regardez. Je pense que les données vont devenir le fossé concurrentiel de la plupart des entreprises.
Je pense donc qu'il s'agira d'un investissement considérable que beaucoup d'entreprises devront faire. Nous devons collecter autant de données de haute qualité que possible afin de pouvoir les introduire dans ces modèles et ne pas utiliser des modèles plus larges avec des fenêtres contextuelles plus larges.
Q : Comment des éléments tels que le GDPR et le CCPA en Californie vont-ils affecter la manière dont les personnes ou les entreprises gèrent la qualité et la sécurité des données ?
Chad Sanderson : "Je pense que le GDPR et le CCPA sont de très bons exemples de la raison pour laquelle de nombreuses entreprises s'inquiètent de ce à quoi ressemblera la réglementation de ces modèles génératifs à l'avenir.
Même si les États-Unis disent "Hé, c'est bon", si l'UE décide que ce n'est pas le cas, en fin de compte, vous devez appliquer ces normes à tout le monde, n'est-ce pas ? Le gros problème avec le GDPR, c'est que vous ne pouvez pas vraiment savoir si un client qui accède à votre site web vient d'Europe ou des États-Unis.
Et bien sûr, vous pouvez faire de la géolocalisation et des choses comme ça. Mais vous pouvez avoir un Européen aux États-Unis qui utilise votre application et le GDPR ne fait pas de discrimination entre cette personne et quelqu'un qui vit en Europe. Vous devez être en mesure de les traiter de la même manière.
Cela signifie que vous devez traiter tous les clients de la même manière, car vous ne savez pas qui est la personne qui se trouve de l'autre côté. Et cela nécessite beaucoup de gouvernance, beaucoup d'innovations technologiques très intéressantes, beaucoup de changements dans la façon dont vous traitez le marketing et d'autres choses de ce genre. Et je pense que nous verrons probablement quelque chose de similaire avec l'IA lorsque la réglementation commencera vraiment à se mettre en place.
L'Europe commence déjà à faire pression en ce sens. C'est pourquoi il est plus sûr pour beaucoup d'entreprises de faire leurs propres affaires, n'est-ce pas ? J'ai mon propre jardin clos.
Je n'utilise que les données que je collecte à partir de nos propres applications. Et ces données ne partent pas. Nous ne suivons pas les clients sur Internet.
Nous nous contentons d'étudier les schémas d'utilisation de nos services. Je pense que cela va devenir très important. L'autre élément qui, selon moi, va prendre de l'ampleur, ce sont les fournisseurs de données.
Les vendeurs de données existent donc depuis très longtemps, ou les données en tant que service, où vous dites, écoutez, je vais vous fournir des informations de dernière minute sur la météo, et vous me payez pour avoir accès à ces informations. Et c'est moi qui ai déjà franchi les obstacles de la sécurité, de l'accessibilité et de la fiabilité des données. Et je m'assure de la qualité des données.
C'est déjà le cas. Mais je pense que cela va exploser au cours des cinq à dix prochaines années si vous avez besoin de données que vous ne pouvez pas collecter à partir de vos propres applications internes. Et je pense que dans ce monde, le concept de ces contrats va devenir encore plus important.
Et cela sera lié à un contrat littéral. Si je paie pour que les données aient une certaine apparence, j'ai certaines attentes à leur égard.
Je ne m'attends pas à ce que ces données changent soudainement entre la dernière fois que vous me les avez fournies et aujourd'hui, parce qu'elles peuvent maintenant avoir un impact sur mon modèle d'apprentissage automatique, qui a un impact sur mon résultat net.
Nous interagissons quotidiennement avec des outils d'IA, mais nous ne pensons presque jamais aux données sur lesquelles ces modèles s'appuient. La curation et la gestion des données seront cruciales, en particulier pour les entreprises qui déploient l'IA en interne."
La curation, la gestion de la qualité et le contrôle des données vont devenir de plus en plus cruciaux à mesure que les entreprises construisent des produits qui dépendent de données de qualité constante.
Si vous souhaitez en savoir plus sur les contrats de données et sur la manière de tirer le meilleur parti des données de votre entreprise, vous pouvez contacter Chad Sanderson ou en savoir plus sur Gable.ai.
