Vrashank Jain de Dell Technologies sur le problème des données qui pourrait faire échouer votre IA

Transcription

Welcome to East Speaks, where we explore the technology shaping the future of enterprise IT. I'm your host, Corey Nolles, and in today's episode, we'll explore the data challenges that can make or break AI initiatives, how enterprises can simplify their data environments, and what organizations need to consider as AI workloads continue to evolve. Joining us today to talk about these challenges is Versank Jin, lead product manager for Dell's AI data platform.

Versank works at the intersection of product innovation and enterprise strategy, helping organizations rethink how they manage data to support AI at scale. Versank, welcome to the podcast. >> Corey, it's lovely to be here. Thank you. >> Awesome. Awesome. We're so glad to have you. I I guess to start off, a lot of organizations say they want to do AI, but they quickly run into data issues. From your perspective working on Dell's AI data platform, what's the most common data problem that stalls AI initiatives today? >> I think a lot of people do say, you know, data is the problem, but uh we need to add more color to that question.

So, the number one thing that I really see stalling AI projects isn't the model. It's not a model problem anymore. It's really data readiness. And it's not just the data. It's actually the readiness and the ability to go and find it. So every organization, especially large ones, have uh enormous amounts of data, but it's fragmented across systems. Some on prem, some in the cloud, some in databases, some in Salesforce and Service Now and and streaming sources, etc.

None of these were ever designed to talk to each other. And you've got structured data living in a warehouse. You have unstructured data. think images, video, emails sitting in a object storage or a file share. You got logs coming in from all over the place from your edge and so none of it is in a state where the model can actually consume it. And the second layer I feel is the metadata or the lineage. This is becoming way more important now in the last maybe year or so than ever before.

Teams spend weeks just trying to understand what data they have, whether it's clean, whether they're even allowed to use it for a given AI use case. And by the time they've answered those questions, the project has lost momentum. And what separates people from fast to slow are the ones who usually have a great way of understanding governance and cataloging of all their data before they really started to chase AI. >> That makes sense. And that's definitely a thing that has to be has to be fixed up front.

So for companies that have that data scattered all across clouds and on-prim systems, edge devices, what makes building a reliable AI data pipeline so difficult? >> Yeah, I think the the first thing we have to do is make sure that we distinguish between what are AI pipelines and AI data pipelines. AI pipelines can sometimes be confused with agent workflows that are now becoming very popular with, you know, uh uh anthropic and and uh lang chain and and those types of things.

Yeah, >> the AI data pipeline very specifically is about how to make sure that the models get the right amount of data at the right time at the right place. >> And the core challenge I think there is because is the fact that we've thought about AI data pipelines traditionally in the same way that we thought of ETL pipelines which are batch oriented. They are relatively predictable. They can afford latency. And AI pipelines on the other hand are are much more throughput hungry.

They are latency sensitive. they they need data in a specific format and are often different from how it's stored operationally. >> And so when you add multicloud and edge to that mix because the data is all over the place, you're not just dealing with data silos. You're basically dealing with network physics now. Moving large data sets from a cloud bucket to a GPU cluster on prem for training. That has a real cost and latency implication. And the consistency problem is significant, too.

I mean, if you're training data and you're inferencing, inference time data are coming from different systems that aren't synchronized, your model starts behaving in ways that are really hard to debug, especially because now the models are non-deterministic, meaning you can ask the same question to the model a couple of times, you might get a slightly different answer. And so, it's very hard to trace back where the source of the the prediction was.

Um, and so the pipeline actually becomes a source of model error that will feel like it's a model problem when in reality it's a data problem. Oh wow, that's really interesting. So, everyone says AI needs good data, but that phrase can mean a lot of different things in practice. What separates data that's actually useful for AI from data that just sits in storage? >> This one's not that hard to answer because it's we're I think we're have to go back to basics here and we we did this, you know, maybe a decade or so ago.

The phrase good data, to your point, does get thrown around a lot. uh but I break it down into basically three things roughly. The first I think is relevance. >> Mhm. >> Even if you have a lot of data, does the does the data you have actually represent the problem domain? A lot of enterprises have like huge archives of historical data that is technically clean but it doesn't reflect current operational reality though. >> Yeah. >> So that's one. Number two is completeness and consistency. meaning you might have missing values, you might have schema drift over time, you might have inconsistent labels to the PDFs or the emails. >> Um, so that's problem number two.

Problem number three is accessibility. This might not be the case for relatively smaller organizations, but for large or even mediumsiz organizations, even if you have high quality data that's that's maybe if it's use, you know, useful, if the retrieval path to get that data is really slow or the format isn't compatible, it's useless. And so it's the combination of is it relevant, is it complete, and is it accessible in the right way at the right time is sort of the the thing that differentiates good data from any other data. >> And the one thing I'd add is >> AI specifically, it's all about representational diversity.

I mean, your chat bots will do a better job if you're feeding it not just an email conversation, but also allowing it to go query a database to doublech checkck, you know, what it actually has come up with. So reasoning models are now trained to ask questions, double check their answers, which means every time it does that. It would be really good if it had access to a lot of really good data. >> Yeah, it would. Yeah, it would. So we're talking here essentially about the idea of of bringing data closer to insights, which sounds simple, but technically is quite the challenge.

I understand. Why does data location matter so much for AI performance? And what problems arise when data and compute are too far apart? Yeah, it this is a it goes back to that old adage of uh moving your insights closer to the data rather than the data closer to the insights because frankly data has way more gravity than anything else anything else in the entire organization. So, and this is again where physics maybe reasserts itself. GPUs are very fast, but they're only fast when they're fed fast.

If they're left hungry, that's money left on the table. Y >> and so if your storage can't keep up with the throughput demands of a GPU cluster, which let's be frank, it's becoming double, triple, quadruple every year, uh we're starting to talk about hundreds of gigabits per second, you end up with GPU starvation, and that's the most expensive line item in your entire IT budget right now. So, it's one of the most common costly infrastructure mistakes we see, which is we jump to the latest and greatest GPU and we underinvest in storage and storage throughput.

And this is especially important when you're talking about inferencing for large number of people with bigger and bigger models, right? If if your model has to reach out to a remote store to pick up context or embeddings or even look at old tokens that is already generated, you're adding network round trips back and forth and what should be a net net subund millisecond adds up and starts to become a a you know a 1second latency which is frankly untenable.

Um so this is where we really start talking about data locality meaning if your data if your most closely guarded data sets are on premise it would be much more feasible to bring that compute closer to that storage potentially in the same data center maybe even in the same cluster subnet and that's really where our storage solutions like power scale are designed for that kind of sustained high throughput when it's living side by side with the GPU cluster if that makes sense. >> That makes a lot of sense.

It does. It does. And it sounds like a lot of money left on the table if you're not careful. So enterprises aren't just running one AI workload anymore. They're experimenting with training, fine-tuning, inference, analytics, and even more. How is this growing diversity of workloads changing what companies need from their data infrastructure? Yeah, this this is a really hard one because I mean like maybe even two years ago when we said AI, we really had just one or two use cases in production and they were primarily inferencing because we were just we were just wowed by the fact that an LLM can start to do things in natural language. >> Yeah. >> Now fast forward even a midsize organization is likely running training jobs because the the models have become so good and so small but yet so powerful.

They're running fine-tuning pipelines. They're running batch inferencing. They're doing real time inferencing. And don't forget, they're still running old analytics. That has always been the case. >> And so each of these workloads have a very different IO profile. Um training is sequential and throughput hungry. You really need to push a lot of data very quickly. Realtime inference is random access, right? It could ping any object, any file, anywhere.

And it's very latency sensitive. analytics might need a big scan across really old archive data um to find that needle in the haststack. And so what I'm basically going towards is there's no single storage tier that's actually optimal for all of them. And so the infrastructure question becomes how do you build something that's intelligent enough but capable enough to serve all of these patterns without forcing any one of these teams to compromise for somebody else?

And how do you do this without maintaining five different storage systems? That's the big part of where our our AI data platform is focused because we're trying to give them a semblance of a unified data platform but with the ability to have diversity for workloads uh without exploding the operational complexity of how to stand this up and run this over time. >> Yeah. So a lot of the conversation around AI focuses on models and GPUs. But in in your experience for Shank, is data infrastructure actually becoming the bigger bottleneck in enterprise adoption? >> Honestly, yes.

And if you look at GTC this year where Jensen uh talked about Nvidia's investments in QDF and QVS, I take that as a message from Jensen to his investors which are frankly everybody at this point that data is a big problem and if Nvidia is focused on solving it, it's a pretty good sign that it's it's happening all over the world. You know, for the last few years, you're right, the do the conversation was dominated with models uh GPU procurement. I mean just in the last one year we've had six or seven different models become number one at various points of the year >> and so I think customers are now starting to see that the models are getting good enough but the investments are flowing now to vector databases data orchestration feature stores it's the stuff that has always been on our road map we just never got to it because we never had a killer use case we finally have a killer use case >> and once people have gone beyond the GPU shortage that gets a lot of press uh they're going to start to talk about the bottleneck of data architecture because you just cannot feed these GPUs well enough right now. >> Agreed.

Agreed. And it's not going to slow down. Many IT teams feel overwhelmed by the number of tools involved in modern AI pipelines like data lakes and vector databases and feature stores and orchestration tools. What does simplifying data management for AI actually look like in practice? Oh, it's the million-dollar question. Um, there's a very maybe a trillion. I agree. Um, there's a VC uh investor, his name is Matt Turk, and every year he does a a MAD landscape.

It's called a machine learning, analytics, and data landscape. And he started about maybe five or six years ago. And that was like a, you know, a handful of logos, maybe about 50. you look at the latest one and you have to basically scroll through the page to go through all of the logos at this point. So it is a very fragmented very diversified market. I don't think that's the problem in itself. I don't think it's the fact that we have variety of technologies.

The real problem I think is reducing the number of handoffs between uh a data scientist or an ML engineer who has to navigate this tool landscape. Right? In a lot of enterprises today, you have data sets being getting ready using six or eight different tools that don't necessarily talk to each other. So a data catalog, a Spark engine, a feature store, a vector database, a pipeline orchestration layer, an observability tool, a monitoring system. The problem is all of these things, they sounds really good when they look at them individually.

They sound like a nightmare when you have to manage this at scale. So, in my view, simplification doesn't necessarily remove all of these tools or condense them into one because let's be real, it's never going to happen. >> Um, I think it really looks like a unified metadata lineage layer that's sort of sensing things as they're going from tool to tool so that you as a steward or as a as a data owner, you're not worried about which tool the data is going into.

You're just worried about making sure that you know at all times which tool the data is getting into, what's happening to it, how it's reporting back. So it's so it's really all about not losing track of where the data came from, where it's going, and where it's headed next across the tools that will always be there. >> Good unified logs kind of. >> Yeah, agreed. Some people say we need a unified tool. I wish there's a tool hood that does everything for me.

One, that's a pipe dream and two that is a recipe for a significant vendor lock in. So yeah, >> you've worked with large enterprises and Fortune 500 organizations for years. >> What are some patterns you're seeing among companies that are successfully scaling AI versus those that are still struggling? >> I think there are some good companies and maybe there are some companies that have struggled and I've started to get some patterns, right? So the companies that have usually done this well.

I think they do a few things really well. Number one, they've always treated data as a first class product, not as an afterthought. meaning they have robust organizational guidelines or or structures in place so that there are SLAs on data quality. There are data owners. There are pipelines that are monitored in the same way that you monitor production software. So they have the hygiene right. Second is that they've built for iteration not for perfection.

By that I mean you start with imperfect data, you invest in feedback loops and you basically let it grow to better quality over time rather than not getting off the ground because you don't have the perfect data set which frankly never materializes. And the third thing they do really well is that they make deliberate choices about where AI workloads live. Meaning they're not just lifting and shifting it to the cloud because that is a cloud mandate.

They're thinking about data gravity. They're thinking about regulatory. They're thinking about cost per inference. And so the more intelligence you put into the process and the more decisions, small decisions you make, the more nimble you are. On the other hand, if you look at the ones that are that struggle, I feel like they're either trying to boil the ocean, right? They go into this 2year, threeyear big data transformation journey that never materializes or that they're running too many maybe isolated experiments, right? which are an idea here and an idea there, but they've never really connected the dots to say, are we thinking of a coherent platform here, or are we just trying to solve one thing at at a time?

So, those are the two kinds of patterns that I think I've seen between the the good and the bad. >> That really lines up with what you might expect. So, let's talk a little about AI transformation. It's not solely a technology shift. This is this is a thing that often requires new collaborations between data engineers, ML teams, and IT infrastructure teams. How are you seeing organizations adapt their teams and workflows to handle this new datadriven AI environment we live in? >> It goes back to like the teams that are doing doing this really well.

One thing I I forgot to mention is they've always they've also broken down the walls within which each role lives any longer. If you go back a few years ago, we knew exactly what a data engineer did versus an ML engineer versus a data analyst and a and an AI engineer. Now, there's no such lines anymore. Everybody can build anything. >> Which means the companies that have been able to be nimble and said, "Hey, your job isn't just to do data engineering.

Your job is to think about AI at scale so that you're building the right pipelines for AI in mind." They are forced to think about beyond what they're doing on a day-to-day basis. So at at scale I think it requires much tighter collaboration and so the good organizations are ones that are combining an AI function into like every single skill set that they have rather than still siloing them into you know what they were traditionally doing. This does require a technology answer I will say which means you do need the tools to allow people to go think about other things.

Um but largely I think you're right this is a this is an organizational workflow question rather than a technology question and I'm also seeing machine learning engineers just maturing very quickly and the MLOps tools are becoming much better too right they've all started to call themselves agent ops or or you know AI ops for a good reason because they're seeing that traditional ML is >> is still there it's just being repackaged into a bigger AI project >> of which ML is now a smaller part not not the big Yeah.

Yeah. It's more like the root. >> Exactly. >> If we fast forward, let's say three to five years from now, how do you expect enterprise AI data platforms to evolve as models get larger and workloads expand, real time AI becomes a lot more common? >> I think the few things I'm fairly confident about is I think we've already talked about this, the the line between compute and storage I think is going to blur. uh we're already seeing processing coming to where the data lives.

We're seeing tremendous investments in on-prem compute for GPUs. I mean, you can see Dell's results, but that's an indication of where the market's going. And I think that trend will accelerate because models are going to get larger and better. Um, and so they're going to become much more dependent on real-time data that needs to live right next door. >> I think the second thing that's going to happen is 20% of data that is accessible today, which is unstructured data, really becomes a first class citizen. and it starts dominating.

By that I mean we'll expand our definition of what a system of record is for a company from just a a data warehouse to this well-labeled highquality multimodal data set which is inclusive of text images video and audio and because these things are going to need multiple technologies to go through I think it requires a different management paradigm and a different technology. Maybe the third thing is the tighter integration between data and the orchestration around the data.

Meaning this is already happening in the AI world, right? First we built the models, then we built an agent framework, and now we're automating the agents because the agents are becoming autonomous. >> The same thing is going to happen in data. First, we built the data platforms, then we built the data pipelines, now we're going to be building an orchestration which will automate the data pipelines. uh not just becoming a a passive thing, but a more an active thing as when a reasoning model thinks I need answers, the pipeline should kick in. >> More of a thing you're monitoring than a thing you're doing. >> Exactly.

More more a thing that you're letting a model dictate what it needs at the time. And all your job to your point is making sure that the pipelines are good. They are, you know, they're not slowing down and they're secure. >> Yeah. And then agents to fix those. >> And then agents to fix those as well. Exactly. It's a it's an agent 8 agent world. >> It is. It is. Well, Versank, thank you so much for joining us today and sharing your insights on the the vital role data infrastructure plays in the age of AI. >> Oh, thanks for having me, Corey.

I loved it. >> Excellent. Well, as AI adoption accelerates across industries, one thing is becoming increasingly clear. Success is about more than building smarter models. It's about ensuring those models have access to the right data in the right place at the right time. For many organizations, solving the data challenge may ultimately determine how far their AI strategies can go. Thanks so much for listening to ES Speaks and we'll see you next time.

This transcript was generated automatically from the video's captions and may contain errors.

Sponsorisé par Dell AI Factory with NVIDIA Logo

The following is sponsored content. It may not reflect the views of our editorial staff.

May 29, 2026

17 minute read

Transcription française – formatée avec noms des intervenants

Corey Knowles : « Bienvenue dans eSpeaks, où nous explorons les technologies qui façonneront l’avenir de l’informatique d’entreprise. Je suis votre hôte, Corey Knowles. Dans l’épisode d’aujourd’hui, nous allons aborder les défis liés aux données qui peuvent faire réussir ou échouer les initiatives d’IA, la façon dont les entreprises peuvent simplifier leurs environnements de données, et ce que les organisations doivent prendre en compte à mesure que les charges de travail liées à l’IA évoluent.

Notre invité aujourd’hui est Vrashank Jain, Lead Product Manager pour la Dell AI Data Platform, qui va nous en dire davantage sur ces défis. Vrashank travaille à l’intersection de l’innovation produit et de la stratégie d’entreprise. Il aide les organisations à repenser la gestion de leurs données afin de soutenir l’IA à grande échelle. Vrashank, bienvenue dans le podcast. »

Vrashank Jain : « Corey, c’est un plaisir d’être ici. Merci. »

Corey : « Génial. Nous sommes ravis de vous accueillir. Commençons directement. De nombreuses organisations disent vouloir se lancer dans l’IA, mais elles se heurtent rapidement à des problèmes de données. De votre point de vue, notamment avec votre travail sur la Dell AI Data Platform, quel est aujourd’hui le problème lié aux données le plus courant qui freine les initiatives d’IA ? »

Vrashank : « Beaucoup d’organisations disent que le problème, ce sont les données, mais je pense qu’il faut être plus précis. Selon moi, le principal facteur qui freine les projets d’IA n’est pas le modèle. Ce n’est plus un problème de modèle. C’est un problème de préparation des données.

Et il ne s’agit pas seulement des données en elles-mêmes. Il s’agit de leur disponibilité et de la capacité à les trouver. Chaque organisation, en particulier les grandes entreprises, possède d’énormes volumes de données, mais celles-ci sont fragmentées entre différents systèmes : certaines sur site, d’autres dans le cloud, d’autres encore dans des bases de données, dans Salesforce, dans ServiceNow, dans des sources de streaming, etc. Aucun de ces éléments n’a été conçu pour communiquer avec les autres.

Vous avez des données structurées dans un entrepôt de données. Vous avez des données non structurées, comme des images, des vidéos et des e-mails, dans un stockage objet ou sur un partage de fichiers. Vous avez des journaux qui arrivent de partout depuis la périphérie. Dans cet état, ces données ne peuvent pas réellement être exploitées par un modèle.

L’autre dimension importante concerne les métadonnées ou le lignage des données. Elles sont devenues plus importantes que jamais au cours de la dernière année environ. Les équipes passent des semaines simplement à comprendre quelles données elles possèdent, si elles sont propres et si elles ont même le droit de les utiliser pour un cas d’usage d’IA donné. Et le temps qu’elles répondent à ces questions, le projet a déjà perdu son élan.

Ce qui distingue les organisations rapides des organisations lentes, c’est que les plus rapides disposent généralement d’une excellente compréhension de la gouvernance et du catalogage de leurs données avant même de commencer à se lancer pleinement dans l’IA. »

Corey : « C’est logique. Et c’est assurément quelque chose qu’il faut régler en amont. Pour les entreprises dont les données sont réparties entre le cloud, les systèmes sur site et les appareils en périphérie, qu’est-ce qui rend si difficile la création d’un pipeline de données d’IA fiable ? »

Vrashank : « La première chose à faire est de bien distinguer les pipelines d’IA des pipelines de données d’IA. Les pipelines d’IA peuvent parfois être confondus avec les workflows d’agents, qui sont aujourd’hui très courants, avec Anthropic, LangChain et d’autres approches similaires. Un pipeline de données d’IA consiste plus précisément à s’assurer que les modèles reçoivent la bonne quantité de données, au bon moment et au bon endroit.

Le principal défi, à mon avis, est que nous avons historiquement construit les pipelines de données de la même manière que les pipelines ETL : ils sont orientés batch, relativement prévisibles et peuvent tolérer une certaine latence.

Les pipelines d’IA, eux, exigent beaucoup plus de débit. Ils sont sensibles à la latence. Ils ont besoin de données dans un format spécifique, souvent différent de celui dans lequel les données sont stockées opérationnellement. Si l’on ajoute à cela le multicloud et la périphérie, parce que les données sont dispersées partout, on ne parle plus seulement de silos de données. On parle, en quelque sorte, de physique des réseaux.

Déplacer de grands ensembles de données d’un bucket cloud vers un cluster GPU sur site pour l’entraînement a de réelles implications en termes de coût et de latence. Le problème de cohérence est également important. Si les données d’entraînement et les données d’inférence proviennent de systèmes différents qui ne sont pas synchronisés, votre modèle commence à se comporter de manière très difficile à déboguer.

C’est particulièrement vrai parce que les modèles sont désormais non déterministes. Cela signifie que vous pouvez poser plusieurs fois la même question au modèle et obtenir des réponses légèrement différentes. Il devient donc très difficile de remonter à la source de la prédiction. C’est ainsi que le pipeline devient une source d’erreurs du modèle, alors que cela ressemble à un problème de modèle mais qu’il s’agit en réalité d’un problème de données. »

Corey : « C’est vraiment intéressant. Tout le monde dit que l’IA a besoin de “bonnes données”, mais cette expression peut vouloir dire beaucoup de choses. En pratique, qu’est-ce qui distingue les données réellement utiles pour l’IA des données qui occupent simplement de l’espace de stockage ? »

Vrashank : « C’est une question assez simple, parce qu’elle nous ramène aux fondamentaux. C’est exactement le type de sujet que nous abordions déjà il y a une dizaine d’années. L’expression “bonnes données” est effectivement utilisée très souvent. Je la décompose généralement en trois grands points.

Le premier est la pertinence. Même si vous disposez de beaucoup de données, représentent-elles réellement le domaine du problème ? De nombreuses entreprises possèdent d’immenses archives de données historiques qui sont techniquement propres, mais qui ne reflètent plus leur réalité opérationnelle actuelle. C’est donc le premier point.

Le deuxième est la complétude et la cohérence. Il peut manquer des valeurs, votre schéma peut dériver au fil du temps, ou vos fichiers PDF et vos e-mails peuvent être étiquetés de manière incohérente. C’est le deuxième problème.

Le troisième est l’accessibilité. Cela concerne peut-être moins les petites organisations, mais dans les grandes et moyennes entreprises, même si vous disposez de données de haute qualité, et même si ces données sont utiles, elles deviennent inutilisables si le chemin pour les récupérer est trop lent ou si leur format est incompatible.

Il s’agit donc d’une combinaison : les données doivent être pertinentes, complètes et accessibles de la bonne manière, au bon moment. C’est ce qui distingue les bonnes données des autres.

J’ajouterais aussi qu’avec l’IA, en particulier, la diversité représentative est essentielle. Les chatbots feront un meilleur travail si on ne leur donne pas seulement une conversation par e-mail, mais si on leur permet aussi d’interroger une base de données pour vérifier les détails sous-jacents de leur résultat. Les modèles de raisonnement sont désormais entraînés à poser des questions et à vérifier leurs réponses. Cela signifie qu’à chaque fois qu’ils le font, il est très utile qu’ils puissent accéder à beaucoup de données réellement fiables. »

Corey : « Oui, tout à fait. Nous parlons ici, au fond, de rapprocher les données des insights, ce qui paraît simple, mais qui est techniquement très difficile, si je comprends bien. Pourquoi l’emplacement des données est-il si important pour les performances de l’IA ? Et quels problèmes apparaissent lorsque les données et la puissance de calcul sont trop éloignées ? »

Vrashank : « Cela nous ramène à ce vieil adage : rapprocher les insights des données, plutôt que les données des insights. Parce que, très franchement, les données ont beaucoup plus de poids que tout le reste dans l’entreprise. Et c’est là, encore une fois, que la physique entre en jeu.

Les GPU sont très rapides, mais ils ne sont rapides que s’ils sont alimentés rapidement. S’ils restent affamés, c’est de l’argent qui est gaspillé. Si votre stockage ne parvient pas à suivre les exigences de débit d’un cluster GPU — et, soyons honnêtes, ces exigences doublent, triplent ou quadruplent chaque année —, on parle désormais de centaines de gigabits par seconde. Vous vous retrouvez alors avec des GPU sous-alimentés. Et c’est aujourd’hui l’un des postes les plus coûteux de tout le budget informatique.

L’une des erreurs d’infrastructure les plus coûteuses que nous observons consiste à acheter les GPU les plus récents et les plus performants, tout en sous-investissant dans le stockage et dans le débit du stockage.

C’est particulièrement important lorsqu’on parle d’inférence pour un grand nombre d’utilisateurs avec des modèles de plus en plus grands. Si votre modèle doit communiquer avec un stockage distant pour récupérer du contexte ou des embeddings, voire consulter d’anciens tokens déjà générés, vous ajoutez des allers-retours réseau. Ce qui devrait être une latence inférieure à 100 millisecondes finit par devenir une latence d’une seconde, ce qui est tout simplement intenable.

C’est ici qu’intervient la notion de localité des données. Si vos jeux de données les plus sensibles sont stockés sur site, il est beaucoup plus logique de rapprocher la puissance de calcul de ce stockage — potentiellement dans le même centre de données, voire dans le même sous-réseau de cluster. C’est là que des solutions de stockage comme PowerScale entrent en jeu : elles sont conçues pour fournir un débit élevé et soutenu lorsqu’elles sont déployées à proximité du cluster GPU, lorsque cela a du sens. »

Corey : « C’est très clair. Et cela donne vraiment l’impression que les entreprises peuvent perdre beaucoup d’argent si elles ne font pas attention. Les entreprises n’exécutent plus une seule charge de travail d’IA. Elles expérimentent avec l’entraînement, l’affinage, l’inférence, l’analytique, et bien plus encore. Comment cette diversité croissante des charges de travail change-t-elle ce que les entreprises attendent de leur infrastructure de données ? »

Vrashank : « C’est une question difficile, parce qu’il y a peut-être encore deux ans, lorsque nous parlions d’IA, nous avions surtout un ou deux cas d’usage en production. Ils concernaient principalement l’inférence, parce que nous étions simplement impressionnés par le fait qu’un LLM puisse effectuer des tâches en langage naturel.

Aujourd’hui, même les organisations de taille moyenne exécutent probablement des tâches d’entraînement, parce que les modèles sont devenus très bons, plus petits, mais aussi extrêmement puissants. Elles exécutent des pipelines d’affinage, de l’inférence par lots et de l’inférence en temps réel. Et il ne faut pas oublier qu’elles continuent aussi à faire de l’analytique traditionnelle, comme elles l’ont toujours fait.

Chacune de ces charges de travail a un profil d’E/S très différent. L’entraînement est séquentiel et exige un débit élevé. Il faut déplacer beaucoup de données très rapidement. L’inférence en temps réel relève de l’accès aléatoire : n’importe quel objet ou fichier peut être sollicité n’importe où, et elle est extrêmement sensible à la latence. L’analytique peut nécessiter de vastes analyses de données archivées très anciennes pour trouver l’aiguille dans la botte de foin.

Ce que j’essaie de dire, au fond, c’est qu’aucun niveau de stockage unique n’est optimal pour tous ces cas. La question d’infrastructure devient donc : comment construire quelque chose d’assez intelligent et d’assez performant pour prendre en charge tous ces schémas, sans forcer une équipe à faire des compromis au profit d’une autre ? Et comment faire cela sans devoir gérer cinq systèmes de stockage différents ?

C’est un axe essentiel de notre AI Data Platform. Nous essayons de fournir une plateforme de données aussi unifiée que possible, tout en offrant la capacité de prendre en charge des charges de travail variées sans faire exploser la complexité opérationnelle liée à sa mise en place et à son exploitation dans la durée. »

Corey : « Une grande partie des discussions sur l’IA se concentre sur les modèles et les GPU. Mais d’après votre expérience, Vrashank, l’infrastructure de données est-elle en train de devenir le principal goulot d’étranglement pour l’adoption de l’IA en entreprise ? »

Vrashank : « Honnêtement, oui. Si l’on regarde la GTC de cette année, lorsque Jensen a parlé des investissements de NVIDIA dans cuDF et cuVS, j’y vois un message de Jensen à ses investisseurs — qui, très franchement, incluent à peu près tout le monde à ce stade — pour dire que les données sont un problème majeur. Et si NVIDIA cherche à résoudre ce problème, c’est un signal assez clair que cela se produit partout dans le monde.

Ces dernières années, comme vous l’avez dit, les discussions étaient dominées par les modèles et par l’approvisionnement en GPU. Rien que l’an dernier, six ou sept modèles différents ont été considérés comme numéro un à différents moments de l’année. Je pense que les clients commencent maintenant à voir que les modèles deviennent suffisamment bons. Les investissements se déplacent désormais vers les bases de données vectorielles, l’orchestration des données et les feature stores.

Tout cela a toujours figuré sur notre feuille de route. Nous ne nous y étions simplement pas encore vraiment consacrés, parce qu’il manquait un cas d’usage suffisamment convaincant. Aujourd’hui, ce cas d’usage existe. Une fois que les entreprises auront dépassé la pénurie de GPU dont on parle tant, elles commenceront à parler du goulot d’étranglement lié à l’architecture des données, parce qu’à l’heure actuelle, ces GPU ne peuvent tout simplement pas être alimentés en données de manière suffisamment efficace. »

Corey : « C’est vrai. Et cela ne va pas ralentir. De nombreuses équipes informatiques se sentent dépassées par le nombre d’outils impliqués dans les pipelines d’IA modernes : data lakes, bases de données vectorielles, feature stores et outils d’orchestration. À quoi ressemble concrètement la simplification de la gestion des données pour l’IA ? »

Vrashank : « C’est la question à un million de dollars. »

Corey : « Peut-être plutôt à mille milliards. »

Vrashank : « Oui, peut-être même à mille milliards. Il existe un investisseur en capital-risque nommé Matt Turck, qui publie chaque année une carte du paysage MAD — machine learning, analytics and data. Il a commencé il y a environ cinq ou six ans avec une poignée de logos, peut-être une cinquantaine. Dans la version la plus récente, il faut littéralement faire défiler toute la page pour parcourir tous les logos.

C’est donc un marché très fragmenté et très diversifié. Mais je ne pense pas que ce soit le problème en soi. Je ne pense pas que la variété des technologies soit le véritable problème. Le vrai problème consiste plutôt à réduire le nombre de passages de relais qu’un data scientist ou un ingénieur en machine learning doit gérer lorsqu’il navigue dans cet univers d’outils.

Dans beaucoup d’entreprises aujourd’hui, les jeux de données sont préparés à l’aide de six ou huit outils différents qui ne communiquent pas nécessairement entre eux : un catalogue de données, un moteur Spark, un feature store, une base de données vectorielle, une couche d’orchestration de pipeline, un outil d’observabilité, un système de supervision.

Le problème, c’est que tous ces outils paraissent excellents lorsqu’on les considère individuellement. Mais lorsqu’il faut les gérer à grande échelle, cela devient un cauchemar. À mon sens, simplifier ne signifie donc pas nécessairement supprimer tous ces outils ou les condenser en un seul outil — soyons réalistes, cela n’arrivera jamais.

Je pense qu’il faut plutôt une couche unifiée de métadonnées et de lignage, capable de suivre en quelque sorte les données lorsqu’elles passent d’un outil à l’autre. En tant que responsable ou propriétaire des données, vous n’avez alors pas à vous inquiéter de l’outil dans lequel les données circulent. Vous devez simplement vous assurer de toujours savoir dans quel outil elles vont, ce qui leur arrive et comment les retours d’information sont produits.

Au fond, il s’agit donc de ne jamais perdre le fil : d’où viennent les données, où vont-elles, et vers quel outil iront-elles ensuite dans cette chaîne d’outils qui existera toujours. »

Corey : « En somme, de bons journaux unifiés. »

Vrashank : « Oui, exactement. Certains disent que nous avons besoin d’un outil unifié, qu’ils aimeraient qu’un seul outil fasse tout pour eux. Premièrement, c’est un rêve irréaliste. Deuxièmement, c’est une recette pour une forte dépendance à un fournisseur. »

Corey : « C’est vrai. Vous travaillez depuis des années avec de grandes entreprises, notamment des entreprises du Fortune 500. Quels schémas observez-vous chez les entreprises qui réussissent à déployer l’IA à grande échelle, par rapport à celles qui rencontrent encore des difficultés ? »

Vrashank : « Je pense qu’il y a des entreprises qui s’en sortent bien et d’autres qui rencontrent des difficultés avec l’IA. Et oui, certains schémas se dégagent. Les entreprises qui réussissent généralement font quelques choses très bien.

Premièrement, elles traitent toujours les données comme un produit de premier plan, et non comme une réflexion après coup. Cela signifie qu’elles ont des politiques ou des structures organisationnelles solides, des SLA sur la qualité des données, des propriétaires de données, et des pipelines qui sont surveillés de la même façon que des logiciels de production. Elles ont donc une bonne hygiène des données.

Deuxièmement, elles conçoivent leur approche pour l’itération, pas pour la perfection. Elles commencent avec des données imparfaites, investissent dans des boucles de rétroaction et améliorent la qualité au fil du temps, au lieu de rester bloquées parce qu’elles n’ont pas un jeu de données parfait — ce qui, franchement, n’arrive jamais.

Troisièmement, elles prennent des décisions délibérées sur l’endroit où les charges de travail d’IA doivent s’exécuter. Elles ne se contentent pas de tout transférer dans le cloud parce qu’un mandat cloud l’exige. Elles réfléchissent à la gravité des données, aux contraintes réglementaires et au coût par inférence.

Plus vous introduisez d’intelligence dans ce processus et plus vous prenez de petites décisions intentionnelles, plus vous devenez agile. À l’inverse, les entreprises qui rencontrent des difficultés donnent souvent l’impression de vouloir faire bouillir l’océan. Elles lancent un grand programme de transformation des données sur deux ou trois ans qui ne se concrétise jamais, ou bien elles mènent trop d’expérimentations isolées.

Elles ont une idée ici, une idée là, mais elles ne relient jamais vraiment les points pour se demander : sommes-nous en train de construire une plateforme cohérente, ou essayons-nous simplement de résoudre un problème à la fois ? Ce sont les deux schémas que j’observe entre les entreprises qui réussissent et celles qui peinent encore. »

Corey : « Cela correspond assez bien à ce que l’on pourrait attendre. Parlons de transformation par l’IA. Il ne s’agit pas seulement d’un changement technologique. Cela exige souvent de nouvelles formes de collaboration entre les ingénieurs de données, les équipes de machine learning et les équipes d’infrastructure informatique. Comment voyez-vous les organisations adapter leurs équipes et leurs workflows pour réussir dans ce nouvel environnement d’IA piloté par les données ? »

Vrashank : « Il faut revenir aux équipes qui font cela très bien. Une chose que j’ai oublié de mentionner, c’est qu’elles ont aussi abattu les murs entre les rôles. Il y a quelques années, nous savions exactement ce que faisait un ingénieur de données, ce que faisait un ingénieur en machine learning, ce que faisait un analyste de données et ce que faisait un ingénieur IA. Aujourd’hui, ces frontières ne sont plus aussi nettes.

Tout le monde peut construire un peu de tout. Les entreprises agiles disent donc : votre travail ne consiste pas seulement à faire de l’ingénierie des données. Votre travail consiste à réfléchir à l’IA à grande échelle, afin de construire les bons pipelines avec l’IA en tête.

Les équipes doivent penser au-delà de leurs tâches quotidiennes. À grande échelle, cela nécessite une collaboration beaucoup plus étroite. Les bonnes organisations intègrent une fonction IA dans chaque ensemble de compétences dont elles disposent, au lieu de continuer à les cloisonner dans des rôles traditionnels.

Cela appelle aussi une réponse technologique, bien sûr. Il faut des outils qui permettent aux équipes de penser au-delà de leur domaine immédiat. Mais, dans l’ensemble, vous avez raison : c’est davantage une question de workflows organisationnels qu’une simple question de technologie.

Je vois aussi les ingénieurs en machine learning mûrir très rapidement, et les outils MLOps s’améliorer fortement. Beaucoup commencent à se présenter comme AgentOps ou AIOps, et ce n’est pas sans raison. Ils constatent que le machine learning traditionnel existe toujours, mais qu’il est désormais réintégré dans un projet d’IA plus vaste, dont il n’est plus qu’une partie. Ce n’est plus la partie dominante. »

Corey : « Oui, plutôt la racine. »

Vrashank : « Exactement. »

Corey : « Si l’on se projette dans trois à cinq ans, comment pensez-vous que les plateformes de données d’IA en entreprise vont évoluer à mesure que les modèles deviennent plus grands, que les charges de travail s’étendent et que l’IA en temps réel se généralise ? »

Vrashank : « Je peux le résumer en deux ou trois points. Certains me viendront peut-être en parlant. Il y a quelques éléments dont je suis assez certain. Le premier — et je crois que nous en avons déjà parlé — est que la frontière entre calcul et stockage va s’estomper. Nous voyons déjà le traitement se rapprocher de l’endroit où se trouvent les données. Nous voyons d’importants investissements dans le calcul sur site pour les GPU. Les résultats de Dell le montrent aussi, et c’est un signe de la direction que prend le marché.

Je pense que cette tendance va s’accélérer, parce que les modèles vont devenir plus grands et meilleurs. Ils dépendront donc encore davantage de données en temps réel situées à proximité.

Le deuxième point est que les 20 % de données qui sont accessibles aujourd’hui — les données non structurées — vont devenir des données de premier plan et commencer à dominer. Par là, je veux dire que nous allons élargir notre définition de ce qu’est un système d’enregistrement pour une entreprise. Ce ne sera plus seulement un entrepôt de données, mais un jeu de données multimodal, bien étiqueté et de grande qualité, comprenant du texte, des images, de la vidéo et de l’audio.

Comme ces données devront traverser plusieurs technologies pour être exploitées, cela nécessitera, selon moi, un paradigme de gestion différent et une technologie différente.

Le troisième point concerne peut-être l’intégration plus étroite entre les données et l’orchestration autour de ces données. C’est déjà ce qui se passe dans le monde de l’IA. Nous avons d’abord construit les modèles, puis les frameworks d’agents, et maintenant nous automatisons les agents parce qu’ils deviennent autonomes. La même chose va se produire avec les données.

Nous avons commencé par construire des plateformes de données. Ensuite, nous avons construit des pipelines de données. Maintenant, nous allons construire une orchestration qui automatisera ces pipelines. Ce ne sera pas quelque chose de passif, mais plutôt quelque chose d’actif : lorsqu’un modèle de raisonnement estime qu’il a besoin de réponses, le pipeline devrait se mettre en marche. »

Corey : « Ce serait donc davantage quelque chose que l’on surveille qu’une tâche que l’on exécute soi-même. »

Vrashank : « Exactement. Il s’agit davantage de laisser un modèle dicter ce dont il a besoin à un moment donné. Votre travail consiste alors, pour revenir à votre remarque, à vous assurer que les pipelines sont performants, qu’ils ne ralentissent rien et qu’ils sont sécurisés. »

Corey : « Oui. Et ensuite des agents pour corriger tout cela. »

Vrashank : « Et ensuite des agents pour corriger tout cela également. Exactement. C’est un monde d’agents. »

Corey : « Vrashank, merci beaucoup de nous avoir rejoints aujourd’hui et d’avoir partagé vos perspectives sur le rôle essentiel de l’infrastructure de données à l’ère de l’IA. Nous avons été ravis de vous recevoir. »

Vrashank : « Merci de m’avoir invité, Corey. J’ai beaucoup apprécié cet échange. »

Corey : « Alors que l’adoption de l’IA s’accélère dans tous les secteurs, une chose devient de plus en plus claire : le succès ne consiste pas seulement à construire des modèles plus intelligents. Il s’agit de s’assurer que ces modèles ont accès aux bonnes données, au bon endroit et au bon moment. Pour de nombreuses organisations, résoudre ce défi lié aux données déterminera finalement jusqu’où leurs stratégies d’IA pourront aller. Merci d’avoir écouté eSpeaks, et à la prochaine. »

Vrashank Jain de Dell Technologies sur le problème des données qui pourrait faire échouer votre IA

Transcription

Transcription française – formatée avec noms des intervenants

Entreprise

Catégories