Corey Knowles: „Willkommen bei eSpeaks, wo wir die Technologien erkunden, die die Zukunft der Unternehmens-IT prägen. Ich bin Ihr Moderator, Corey Knowles. In der heutigen Folge erkunden wir die Datenherausforderungen, die KI-Initiativen zum Erfolg oder Scheitern bringen können, wie Unternehmen ihre Datenumgebungen vereinfachen können und was Unternehmen beachten müssen, wenn sich KI-Workloads weiterentwickeln. Unser heutiger Gast ist Vrashank Jain, Lead Product Manager für die Dell AI Data Platform, der uns mehr über diese Herausforderungen erzählen wird.
Vrashank arbeitet an der Schnittstelle von Produktinnovation und Unternehmensstrategie. Er hilft Unternehmen dabei, Datenmanagement neu zu definieren, um KI in großem Maßstab zu unterstützen. Vrashank, willkommen beim Podcast.“
Vrashank Jain: „Ich freue mich, hier zu sein. Vielen Dank.“
Corey: „Großartig. Wir freuen uns sehr, dich hier zu haben. Lass uns direkt starten: Viele Unternehmen sagen, sie möchten KI einführen, stoßen aber schnell auf Datenprobleme. Was ist aus deiner Sicht, insbesondere mit Blick auf die Dell AI Data Platform, das häufigste Datenproblem, das KI-Initiativen heute ausbremst?“
Vrashank: „Das ist eine großartige Frage. Viele Unternehmen sagen, dass Daten das Problem sind, aber ich denke, wir müssen da genauer hinschauen. Der Hauptgrund, aus dem KI-Projekte ins Stocken geraten, liegt nicht am Modell. Es ist kein Modellproblem mehr. Es geht vielmehr um Datenbereitschaft. Und es geht nicht nur um die Daten selbst, sondern darum, ob sie verfügbar sind und ob man sie finden kann. Jedes Unternehmen, insbesondere große Unternehmen, verfügt über enorme Datenmengen, aber diese sind über verschiedene Systeme verteilt.
Ein Teil liegt on-premises, ein Teil in der Cloud, ein Teil in Datenbanken, ein Teil in Salesforce, ServiceNow, Streamingquellen und so weiter. Nichts davon wurde ursprünglich dafür entwickelt, miteinander zu kommunizieren. Unternehmen haben strukturierte Daten in einem Warehouse. Sie haben unstrukturierte Daten — etwa Bilder, Videos und E-Mails — in einem Objektspeicher oder einer Dateifreigabe. Protokolle kommen von verschiedensten Edge-Standorten herein. In diesem Zustand kann das Modell diese Daten nicht wirklich nutzen.
Die zweite Ebene betrifft aus meiner Sicht Metadaten oder Datenherkunft. Das ist in den letzten etwa zwölf Monaten wichtiger geworden als je zuvor. Teams verbringen Wochen damit, überhaupt zu verstehen, welche Daten sie haben, ob diese bereinigt sind und ob sie sie für einen bestimmten KI-Anwendungsfall überhaupt verwenden dürfen. Und bis sie diese Fragen beantwortet haben, hat das Projekt bereits an Schwung verloren.
Der Unterschied zwischen schnellen und langsamen Unternehmen besteht meistens darin, dass die schnellen Unternehmen bereits ein gutes Verständnis von Governance und Katalogisierung ihrer Daten haben, bevor sie überhaupt anfangen, KI intensiv voranzutreiben.“
Corey: „Das macht Sinn. Und das ist definitiv etwas, das im Vorfeld geklärt werden muss. Was macht es für Unternehmen, deren Daten über Clouds, On-Premise-Systeme und Edge-Geräte verteilt sind, so schwierig, eine zuverlässige KI-Datenpipeline aufzubauen?“
Vrashank: „Ich denke, zuerst müssen wir sicherstellen, dass wir zwischen KI-Pipelines und KI-Datenpipelines unterscheiden. KI-Pipelines werden manchmal mit Agenten-Workflows verwechselt, die inzwischen sehr verbreitet sind, etwa mit Anthropic, LangChain und ähnlichen Ansätzen. Bei einer KI-Datenpipeline geht es ganz konkret darum sicherzustellen, dass Modelle die richtige Menge an Daten zur richtigen Zeit am richtigen Ort erhalten.
Die zentrale Herausforderung besteht darin, dass wir KI-Datenpipelines traditionell ähnlich betrachtet haben wie ETL-Pipelines. Diese sind batchorientiert, relativ vorhersehbar und können Latenz verkraften.
KI-Pipelines hingegen benötigen deutlich mehr Durchsatz. Sie sind latenzsensitiv. Sie benötigen Daten in einem bestimmten Format, das sich oft davon unterscheidet, wie die Daten operativ gespeichert werden. Wenn dann noch Multi-Cloud- und Edge-Umgebungen hinzukommen, weil die Daten überall verteilt sind, hat man es nicht nur mit Datensilos zu tun.
Man hat es im Grunde mit Netzwerkphysik zu tun. Große Datensätze aus einem Cloud-Bucket in einen On-Premise-GPU-Cluster für das Training zu verschieben, verursacht reale Kosten und hat Auswirkungen auf die Latenz. Auch das Konsistenzproblem ist erheblich. Wenn Trainingsdaten und Inferenzdaten aus verschiedenen Systemen stammen, die nicht synchronisiert sind, verhält sich das Modell auf eine Weise, die sehr schwer zu debuggen ist — vor allem, weil die Modelle inzwischen nicht deterministisch sind.
Das bedeutet, dass man dem Modell dieselbe Frage mehrmals stellen kann und leicht unterschiedliche Antworten erhält. Dadurch wird es sehr schwierig, zurückzuverfolgen, woher eine bestimmte Vorhersage stammt. Die Pipeline wird dann tatsächlich zur Quelle von Modellfehlern, die wie Modellprobleme wirken, in Wirklichkeit aber Datenprobleme sind.“
Corey: „Das ist wirklich interessant. Alle sagen, KI brauche gute Daten, aber dieser Ausdruck kann vieles bedeuten. Was unterscheidet in der Praxis Daten, die tatsächlich für KI nützlich sind, von Daten, die einfach nur Speicherplatz belegen?“
Vrashank: „Diese Frage ist gar nicht so schwer zu beantworten, weil wir hier wieder zu den Grundlagen zurückkommen. Genau damit haben wir uns schon vor etwa zehn Jahren beschäftigt. Der Ausdruck gute Daten wird, wie du sagst, sehr oft verwendet. Ich teile das grob in drei Dinge auf. Der erste Punkt ist Relevanz.
Selbst wenn man viele Daten hat, stellt sich die Frage, ob diese Daten den Problembereich tatsächlich abbilden. Viele Unternehmen verfügen über riesige Archive historischer Daten, die technisch gesehen sauber sind, aber nicht mehr die aktuelle betriebliche Realität widerspiegeln. Das ist also der erste Punkt.
Der zweite Punkt ist Vollständigkeit und Konsistenz. Das bedeutet, dass Werte fehlen können, dass sich Schemas im Laufe der Zeit verändern oder dass PDFs oder E-Mails uneinheitlich benannt sind. Das ist Problem Nummer zwei. Problem Nummer drei ist Zugänglichkeit.
Das betrifft kleinere Unternehmen vielleicht weniger, aber bei großen oder mittelständischen Unternehmen gilt: Selbst wenn hochwertige Daten vorhanden sind und diese an sich nützlich wären, sind sie nutzlos, wenn der Abrufpfad zu langsam ist oder das Format nicht kompatibel ist. Es geht also um die Kombination: Sind die Daten relevant, vollständig und auf die richtige Weise zur richtigen Zeit zugänglich? Das unterscheidet gute Daten von beliebigen anderen Daten.
Einen Punkt würde ich noch hinzufügen: Gerade bei KI geht es besonders um repräsentative Vielfalt. Chatbots erledigen ihre Aufgabe besser, wenn sie nicht nur mit einer E-Mail-Unterhaltung gefüttert werden, sondern auch eine Datenbank abfragen können, um ihre Ergebnisse zu überprüfen. Reasoning-Modelle werden inzwischen darauf trainiert, Fragen zu stellen und ihre Antworten zu prüfen. Das bedeutet, dass es jedes Mal sehr hilfreich wäre, wenn sie Zugriff auf viele wirklich gute Daten hätten.“
Corey: „Ja, das wäre es. Wir sprechen hier im Grunde über die Idee, Daten näher an Erkenntnisse heranzubringen. Das klingt einfach, ist technisch aber eine große Herausforderung, soweit ich weiß. Warum ist der Datenstandort für die KI-Leistung so wichtig, und welche Probleme entstehen, wenn Daten und Compute zu weit voneinander entfernt sind?“
Vrashank: „Das geht auf die alte Weisheit zurück, Erkenntnisse näher an die Daten zu bringen, statt die Daten näher an die Erkenntnisse. Denn ganz ehrlich: Daten haben viel mehr Gewicht als alles andere im gesamten Unternehmen. Und auch hier setzt sich gewissermaßen wieder die Physik durch. GPUs sind sehr schnell, aber sie sind nur dann schnell, wenn sie schnell mit Daten versorgt werden. Wenn sie hungrig bleiben, bleibt Geld auf dem Tisch liegen.
Wenn Ihr Speicher also nicht mit den Durchsatzanforderungen eines GPU-Clusters mithalten kann — und seien wir ehrlich, diese Anforderungen verdoppeln, verdreifachen oder vervierfachen sich jedes Jahr —, sprechen wir inzwischen über Hunderte Gigabyte pro Sekunde. Dann kommt es zu GPU-Starvation, und das ist derzeit der teuerste Posten im gesamten IT-Budget. Einer der häufigsten und kostspieligsten Infrastrukturfehler, die wir sehen, besteht darin, die neuesten und besten GPUs anzuschaffen, aber zu wenig in Speicher und Speicherdurchsatz zu investieren.
Das ist besonders wichtig, wenn es um Inferenz für eine große Anzahl von Nutzern mit immer größeren Modellen geht. Wenn Ihr Modell auf einen entfernten Speicher zugreifen muss, um Kontext oder Embeddings abzurufen, oder sogar auf bereits generierte alte Tokens schauen muss, fügen Sie Netzwerk-Roundtrips hinzu.
Was eigentlich eine Latenz von unter 100 Millisekunden sein sollte, summiert sich dann und wird zu einer Latenz von einer Sekunde — und das ist schlicht nicht tragbar. Genau hier sprechen wir über Datenlokalität. Wenn Ihre am strengsten geschützten Datensätze on-premises liegen, ist es deutlich sinnvoller, die Rechenleistung näher an diesen Speicher zu bringen, potenziell im selben Rechenzentrum, vielleicht sogar im selben Cluster-Subnetz.
Genau dafür sind Storage-Lösungen wie PowerScale ausgelegt: für anhaltend hohen Durchsatz, wenn sie sinnvollerweise direkt neben dem GPU-Cluster betrieben werden.“
Corey: „Das macht absolut Sinn. Es klingt, als ließe man sehr viel Geld liegen, wenn man nicht vorsichtig ist. Unternehmen betreiben heute nicht mehr nur eine einzige KI-Workload. Sie experimentieren mit Training, Feinabstimmung, Inferenz, Analysen und vielem mehr. Wie verändert diese wachsende Vielfalt an Workloads die Anforderungen an die Dateninfrastruktur?“
Vrashank: „Das ist eine wirklich schwierige Frage, denn vielleicht noch vor zwei Jahren hatten wir, wenn wir über KI gesprochen haben, nur ein oder zwei produktive Anwendungsfälle. Diese drehten sich vor allem um Inferenz, weil wir einfach begeistert davon waren, dass ein LLM Aufgaben in natürlicher Sprache ausführen kann. Heute hingegen führen selbst mittelständische Unternehmen wahrscheinlich Trainingsjobs aus, weil die Modelle so gut und so klein, aber dennoch so leistungsstark geworden sind.
Sie betreiben Feinabstimmungspipelines, Batch-Inferenz und Echtzeit-Inferenz. Und nicht zu vergessen: Sie führen weiterhin klassische Analysen durch, wie sie es schon immer getan haben. Jede dieser Workloads hat ein sehr unterschiedliches I/O-Profil. Training ist sequenziell und durchsatzintensiv. Man muss sehr viele Daten sehr schnell bewegen. Echtzeit-Inferenz ist Random Access: Jedes Objekt und jede Datei kann irgendwo abgefragt werden, und sie ist extrem latenzsensitiv.
Analysen können große Scans über sehr alte Archivdaten erfordern, um die Nadel im Heuhaufen zu finden. Worauf ich im Grunde hinauswill: Es gibt keinen einzelnen Storage-Tier, der für all diese Fälle optimal ist. Die Infrastrukturfrage lautet daher: Wie baut man etwas, das intelligent genug und leistungsfähig genug ist, um all diese Muster zu unterstützen, ohne ein Team zu zwingen, für ein anderes Team Kompromisse einzugehen? Und wie macht man das, ohne fünf verschiedene Speichersysteme verwalten zu müssen?
Das ist ein zentraler Fokus unserer AI Data Platform. Wir wollen so etwas wie eine einheitliche Datenplattform bereitstellen, aber mit der Fähigkeit, vielfältige Workloads zu unterstützen, ohne die betriebliche Komplexität beim Aufbau und Betrieb explodieren zu lassen.“
Corey: „Viele Gespräche über KI drehen sich um Modelle und GPUs. Wird deiner Erfahrung nach, Vrashank, die Dateninfrastruktur tatsächlich zum größeren Engpass bei der Einführung von KI in Unternehmen?“
Vrashank: „Ehrlich gesagt: ja. Wenn man sich die GTC in diesem Jahr ansieht, wo Jensen über NVIDIAs Investitionen in cuDF und cuVS gesprochen hat, dann verstehe ich das als Botschaft von Jensen an seine Investoren — und das sind derzeit offen gesagt fast alle —, dass Daten ein großes Problem sind. Und wenn NVIDIA sich darauf konzentriert, dieses Problem zu lösen, ist das ein ziemlich deutliches Signal, dass es überall auf der Welt passiert.
In den letzten Jahren wurden die Gespräche, da hast du recht, von Modellen und GPU-Beschaffung dominiert. Allein im letzten Jahr hatten wir sechs oder sieben verschiedene Modelle, die zu unterschiedlichen Zeitpunkten als Nummer eins galten. Ich denke, Kunden erkennen jetzt, dass die Modelle gut genug werden. Die Investitionen fließen nun in Vektordatenbanken, Datenorchestrierung und Feature-Stores. Das sind Dinge, die schon immer auf unserer Roadmap standen.
Wir sind nur nie dazu gekommen, weil es keinen wirklich überzeugenden Anwendungsfall gab. Jetzt haben wir endlich diesen überzeugenden Anwendungsfall. Und sobald Unternehmen über die GPU-Knappheit hinaus sind, über die so viel berichtet wird, werden sie über den Engpass der Datenarchitektur sprechen. Denn im Moment können diese GPUs schlicht nicht gut genug mit Daten versorgt werden.“
Corey: „Stimmt. Und das wird sich nicht verlangsamen. Viele IT-Teams fühlen sich von der Anzahl der Tools überfordert, die für moderne KI-Pipelines nötig sind — Data Lakes, Vektordatenbanken, Feature-Stores und Orchestrierungstools. Wie sieht Vereinfachung des Datenmanagements für KI in der Praxis tatsächlich aus?“
Vrashank: „Das ist die Millionen-Dollar-Frage.“
Corey: „Vielleicht eher die Billionen-Dollar-Frage.“
Vrashank: „Da stimme ich zu. Es gibt einen Venture-Capital-Investor namens Matt Turck, der jedes Jahr eine MAD-Landschaft veröffentlicht. Das steht für Machine Learning, Analytics und Data. Er hat vor etwa fünf oder sechs Jahren damit begonnen, und damals waren es vielleicht eine Handvoll Logos, ungefähr 50.
Wenn man sich die neueste Version ansieht, muss man im Grunde die ganze Seite herunterscrollen, um alle Logos zu sehen. Der Markt ist also sehr fragmentiert und sehr diversifiziert. Aber ich glaube nicht, dass das an sich das Problem ist. Ich glaube nicht, dass die Vielfalt der Technologien das Problem ist.
Das eigentliche Problem besteht aus meiner Sicht darin, die Anzahl der Übergaben zu reduzieren, die ein Data Scientist oder ML Engineer bewältigen muss, während er sich durch diese Tool-Landschaft bewegt. In vielen Unternehmen werden Datensätze heute mit sechs oder acht verschiedenen Tools vorbereitet, die nicht unbedingt miteinander kommunizieren: ein Datenkatalog, eine Spark-Engine, ein Feature-Store, eine Vektordatenbank, eine Pipeline-Orchestrierungsschicht, ein Observability-Tool, ein Monitoring-System.
Das Problem ist: All diese Dinge klingen sehr gut, wenn man sie einzeln betrachtet. Aber sie klingen wie ein Albtraum, wenn man sie im großen Maßstab verwalten muss. Aus meiner Sicht bedeutet Vereinfachung daher nicht unbedingt, all diese Tools zu entfernen oder sie in einem einzigen Tool zusammenzufassen — seien wir realistisch, das wird nicht passieren. Ich glaube, es geht eher um eine einheitliche Metadaten- und Herkunftsschicht, die gewissermaßen erkennt, wie Daten von Tool zu Tool wandern.
Als Data Steward oder Dateneigentümer muss man sich dann nicht darum sorgen, in welches Tool die Daten gerade fließen. Man muss nur sicherstellen, dass jederzeit klar ist, in welches Tool die Daten gelangen, was dort mit ihnen geschieht und wie Rückmeldungen erfolgen. Im Kern geht es also darum, nicht den Überblick darüber zu verlieren, woher die Daten kommen, wohin sie gehen und wohin sie als Nächstes weitergeleitet werden — über all die Tools hinweg, die immer vorhanden sein werden.“
Corey: „Gute, einheitliche Protokolle.“
Vrashank: „Ja, genau. Manche sagen, wir brauchen ein einheitliches Tool. Ich wünschte, es gäbe ein Tool, das alles für mich erledigt. Erstens ist das ein Wunschtraum. Und zweitens ist es ein Rezept für erhebliche Anbieterabhängigkeit.“
Corey: „Das ist es wirklich. Du arbeitest seit Jahren mit großen Unternehmen und Fortune-500-Organisationen zusammen. Welche Muster erkennst du bei Unternehmen, die KI erfolgreich skalieren, im Vergleich zu denen, die noch Schwierigkeiten haben?“
Vrashank: „Ich denke, es gibt einige Unternehmen, die das gut machen, und einige, die Schwierigkeiten haben. Und ich habe dabei bestimmte Muster erkannt. Die Unternehmen, die das normalerweise gut machen, tun ein paar Dinge besonders gut. Erstens behandeln sie Daten immer als erstklassiges Produkt und nicht als Nebengedanken. Das bedeutet, dass sie robuste organisatorische Richtlinien oder Strukturen haben: Es gibt SLAs für Datenqualität, es gibt Dateneigentümer.
Es gibt Pipelines, die so überwacht werden wie Produktionssoftware. Sie haben also die nötige Datenhygiene. Zweitens bauen sie auf Iteration statt auf Perfektion. Damit meine ich: Sie beginnen mit unvollkommenen Daten, investieren in Feedbackschleifen und lassen die Qualität im Laufe der Zeit wachsen, statt gar nicht erst zu starten, weil kein perfekter Datensatz vorhanden ist — der sich ehrlich gesagt nie materialisiert.
Der dritte Punkt, den sie sehr gut machen, ist, dass sie bewusst entscheiden, wo KI-Workloads laufen. Sie verschieben nicht einfach alles in die Cloud, nur weil es ein Cloud-Mandat gibt.
Sie denken über Datengravitation nach. Sie denken über regulatorische Anforderungen nach. Sie denken über Kosten pro Inferenz nach. Je mehr Intelligenz man in den Prozess einbringt und je mehr kleine Entscheidungen man bewusst trifft, desto wendiger wird man. Bei den Unternehmen, die Schwierigkeiten haben, sehe ich hingegen oft, dass sie versuchen, den Ozean zum Kochen zu bringen.
Sie starten eine zwei- oder dreijährige Big-Data-Transformationsreise, die nie Realität wird, oder sie führen zu viele isolierte Experimente durch — eine Idee hier, eine Idee dort —, ohne die Punkte miteinander zu verbinden und zu fragen: Denken wir hier über eine kohärente Plattform nach, oder versuchen wir nur, ein Problem nach dem anderen zu lösen? Das sind die beiden Muster, die ich zwischen erfolgreichen und weniger erfolgreichen Unternehmen beobachtet habe.“
Corey: „Das ist interessant. Und es entspricht ziemlich genau dem, was man erwarten würde. Lass uns über KI-Transformation sprechen. Es geht nicht nur um einen Technologiewechsel. Oft erfordert das neue Formen der Zusammenarbeit zwischen Data Engineers, ML-Teams und IT-Infrastrukturteams. Wie siehst du, dass Unternehmen ihre Teams und Workflows anpassen, um mit dieser neuen datengesteuerten KI-Umgebung zurechtzukommen?“
Vrashank: „Das führt zurück zu den Teams, die das wirklich gut machen. Einen Punkt habe ich vorhin vergessen: Sie haben auch die Mauern zwischen den einzelnen Rollen eingerissen. Vor ein paar Jahren wussten wir genau, was ein Data Engineer im Vergleich zu einem ML Engineer, einem Datenanalysten oder einem AI Engineer tut. Heute gibt es diese klaren Grenzen nicht mehr. Jeder kann alles entwickeln. Das bedeutet: Die Unternehmen, die wendig sind, sagen nicht mehr nur: Deine Aufgabe ist Data Engineering.
Sie sagen: Deine Aufgabe ist es, über KI im großen Maßstab nachzudenken, damit du die richtigen Pipelines mit Blick auf KI entwickelst. Die Menschen müssen über das hinausdenken, was sie tagtäglich tun. Im großen Maßstab erfordert das eine viel engere Zusammenarbeit. Gute Organisationen integrieren eine KI-Funktion in jede einzelne Kompetenz, die sie haben, statt sie weiterhin in traditionellen Aufgabenbereichen zu isolieren.
Das erfordert auch eine technologische Antwort, das will ich nicht ausklammern. Man braucht Tools, die es Menschen ermöglichen, über andere Dinge nachzudenken. Aber im Wesentlichen hast du recht: Das ist eher eine Frage der organisatorischen Workflows als eine reine Technologiefrage.
Außerdem sehe ich, dass Machine-Learning-Engineers sehr schnell reifen und dass auch die MLOps-Tools deutlich besser werden. Viele nennen sich inzwischen aus gutem Grund AgentOps oder AIOps, weil sie erkennen, dass traditionelles maschinelles Lernen weiterhin existiert. Es wird nur in ein größeres KI-Projekt eingebettet, in dem ML nun ein kleinerer Teil ist — nicht mehr der große Teil.“
Corey: „Ja, eher so etwas wie die Wurzel.“
Vrashank: „Genau.“
Corey: „Wenn wir drei bis fünf Jahre in die Zukunft springen: Wie werden sich Enterprise-KI-Datenplattformen deiner Meinung nach entwickeln, wenn Modelle größer werden, Workloads zunehmen und Echtzeit-KI deutlich verbreiteter wird?“
Vrashank: „Ich würde es vielleicht in zwei oder drei Punkten zusammenfassen. Einige davon werden mir beim Sprechen einfallen. Bei ein paar Dingen bin ich ziemlich sicher. Erstens — und darüber haben wir, glaube ich, schon gesprochen — wird die Grenze zwischen Compute und Storage verschwimmen. Wir sehen bereits, dass Verarbeitung dorthin verlagert wird, wo die Daten liegen. Wir sehen enorme Investitionen in On-Premise-Compute für GPUs. Man kann das auch an den Ergebnissen von Dell ablesen; das ist ein Hinweis darauf, wohin sich der Markt entwickelt.
Ich glaube, dieser Trend wird sich beschleunigen, weil Modelle größer und besser werden. Dadurch werden sie stärker von Echtzeitdaten abhängig, die direkt in der Nähe liegen müssen. Der zweite Punkt ist, dass die 20 Prozent der Daten, die heute zugänglich sind — also unstrukturierte Daten — zu Daten erster Klasse werden und zunehmend dominieren.
Damit meine ich, dass wir unser Verständnis davon erweitern werden, was für ein Unternehmen ein System of Record ist. Es wird nicht mehr nur ein Data Warehouse sein, sondern ein gut gekennzeichneter, hochwertiger, multimodaler Datensatz, der Text, Bilder, Video und Audio einschließt. Weil diese Daten mehrere Technologien durchlaufen müssen, erfordert das meiner Ansicht nach ein anderes Managementparadigma und eine andere Technologie.
Der dritte Punkt ist vielleicht die engere Integration zwischen Daten und der Orchestrierung rund um diese Daten. Das passiert bereits in der KI-Welt. Zuerst haben wir Modelle gebaut, dann haben wir Agenten-Frameworks gebaut, und jetzt automatisieren wir die Agenten, weil Agenten autonom werden. Dasselbe wird auch mit Daten passieren.
Zuerst haben wir Datenplattformen gebaut, dann Datenpipelines. Als Nächstes werden wir eine Orchestrierung bauen, die Datenpipelines automatisiert. Das wird nicht nur eine passive Sache sein, sondern etwas Aktives: Wenn ein Reasoning-Modell denkt, dass es Antworten braucht, sollte die Pipeline anspringen.“
Corey: „Also eher etwas, das man überwacht, als etwas, das man selbst ausführt.“
Vrashank: „Genau. Es geht eher darum, einem Modell zu erlauben, vorzugeben, was es in diesem Moment braucht. Deine Aufgabe ist dann, wie du gesagt hast, sicherzustellen, dass die Pipelines gut sind, dass sie nichts verlangsamen und dass sie sicher sind.“
Corey: „Ja. Und dann Agenten, die das beheben.“
Vrashank: „Und dann Agenten, die das ebenfalls beheben. Genau. Es ist eine Agentenwelt.“
Corey: „Vrashank, vielen Dank, dass du heute bei uns warst und deine Einblicke in die wichtige Rolle der Dateninfrastruktur im Zeitalter der KI geteilt hast. Ich habe mich sehr gefreut, dich hier zu haben.“
Vrashank: „Vielen Dank für die Einladung, Corey. Es hat mir viel Spaß gemacht.“
Corey: „Da die KI-Einführung branchenübergreifend immer schneller voranschreitet, wird eines immer deutlicher: Erfolg bedeutet mehr, als nur intelligentere Modelle zu entwickeln. Es geht darum sicherzustellen, dass diese Modelle Zugriff auf die richtigen Daten am richtigen Ort und zur richtigen Zeit haben. Für viele Unternehmen wird die Lösung dieser Datenherausforderung letztlich darüber entscheiden, wie weit ihre KI-Strategien gehen können. Vielen Dank fürs Zuhören bei eSpeaks, und bis zum nächsten Mal.“
