Latest / M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch / Microsoft Fabric Notebooks für KI-Training: Modelle direkt auf Lakehouse-Daten trainieren – ohne CSV-Chaos (KI-Synchronfassung)

Transcript

Microsoft Fabric Notebooks für KI-Training: Modelle direkt auf Lakehouse-Daten trainieren – ohne CSV-Chaos (KI-Synchronfassung) · M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch

• 0:00
  Bereit für 10 Tage voller Microsoft 365, Co-Pilot KI-Asherer und den Vordenkern der Arbeitswelt von morgen, Tein.
• 0:07
  Diesen Januar ist die M365 kommt zurück und wir legen noch eine Schippe drauf.
• 0:12
  Seien Sie dabei bei Live-Sessions, Praxis-Demos und Expertenwissen von MVPs und Fachleuten aus aller Welt, A-Elt.
• 0:18
  Keine generischen Folien. Kein endloses Password-Bingo.
• 0:21
  Wir gehen echte Herausforderungen an. Copalut Studio, KI-Agenten, Fabrik, Sicherheit, Governance und Automatisierung.
• 0:28
  Bucket. Egal ob IT-Profi-Entwickler oder Führungskraft-E-Skip-Sessions, die genau auf Sie zugeschnitten sind.
• 0:35
  An 10 vollen Tagen können Sie zahlreiche Technologien erkunden und sich mit der globalen Community vernetzen.
• 0:40
  Schauen Sie live zu und nehmen Sie praktische Erkenntnisse für Ihr Unternehmen mit.
• 0:44
  20. Januar. 10 Tage. Eine Microsoft-Community. Die Anmeldung ist jetzt geöffnet.
• 0:51
  Besuchen Sie mtrenum65.com.net und sichern Sie sich noch heute Ihren Platz.
• 0:55
  Das ist mtrenum55.net.
• 0:59
  Melden Sie sich jetzt unter mtrenum55.net an. Wir sehen uns live.
• 1:03
  Im Januar.
• 1:05
  Haben Sie schon mal versucht, ein KI-Modell auf Ihrem Laptop zu trainieren, nur um zu sehen, wie es stundenlang kriecht oder komplett abstürzt?
• 1:10
  Damit ist nicht allein.
• 1:12
  Die meisten geschäftlichen Datensätze sind unserer lokalen Hardware entwachsen.
• 1:15
  Aber was wäre, wenn Ihr gesamter Multi-Terabyte-Datensatz sofort in Ihrem Trainings-Notebook verfügbar wäre?
• 1:20
  Keine Exporte, kein CSV-Chaos.
• 1:23
  Heute tauchen wir ein in die integrierten Notebooks von Microsoft Fabric, wo das Training Ihres Modells direkt bei Ihren Lakehouse-Daten stattfindet.
• 1:29
  Wir zeigen Ihnen genau, wie dieses Setup tagelange Verarbeitungszeit spart und Sie dabei kompromisslos in Python oder R arbeiten lässt.
• 1:37
  Wenn Big Data den Laptop überfordert, stellen Sie sich vor, der Lüfter dreht, so laut auf, dass er Ihre Besprechung übertönt, während Sie eine Tabelle bearbeiten, bis es.
• 1:47
  Ersetzen Sie diese Tabelle nun durch 12 Terabyte an rohen Kundentransaktionen aus jahrelangen Aktivitäten mit dutzenden Feldern pro Datensatz.
• 1:54
  Schon vor dem Start wissen Sie, dass das wehtun wird.
• 1:58
  Genau in dieser Lage befinden sich viele Marketing-Teams.
• 2:00
  Sie haben eine transaktionale Datenbank, die problemlos das Rückgrat eines fortschrittlichen KI-Projekts bilden könnte.
• 2:05
  Churn-Vorhersage, Zielgruppensegmentierung, Personalisierung, in Echtzeit, doch Ihre Werkzeuge stecken noch auf dem Desktop fest.
• 2:17
  Sie öffnen Dateien in Excel oder lokalen Jupyter-Notebooks, filtern in winzigen Häppchen, um den PC nicht zum Einfrieren zu bringen und hoffen, dass alles lange genug hält, um brauchbare Ergebnisse zu liefern.
• 2:29
  Wenn Teams dies lokal versuchen, zeigen sich schnell die Grenzen.
• 2:32
  Die Verarbeitung kriegt dahin, die Benutzeroberfläche reagiert mit Sekundenverzögerung und Export-Skripte, die früher Minuten brauchten, laufen jetzt stundenlang.
• 2:39
  Noch schlimmer, größere Workloads werden nicht nur langsamer, sie bleiben stehen.
• 2:42
  Weicher Fehler, Festplattenüberlastung oder Kerne Neustarts führen dazu, dass Trainingsläufe nicht nur länger dauern, sondern oft niemals fertig werden.
• 2:49
  Und wenn es um das Training eines KI-Modells geht, ist das verschwendete Rechenleistung, verlorene Zeit und eine verpasste Chance.
• 2:54
  Ein Versuch zur Abwanderungsvorhersage, den ich sah, war als nächtlicher Lauf in einer lokalen Python-Umgebung geplant.
• 3:01
  20 Stunden später schlug der Prozess fehl, weil der letzte Teil des Datensatzes die RAM-Auslastung über das Limit trieb, trieb.
• 3:08
  Das Team verlor einen ganzen Tag, ohne auch nur einen einzigen Trainingsmesswert zurückzuerhalten.
• 3:12
  Falls das extrem klingt, es wird immer häufiger zur Realität.
• 3:16
  Unternehmensmarketing-Datensätze wachsen jährlich an, getrieben durch umfassenderes Tracking, Omnichannel-Erlebnisse und ereignisbasiertes Logging.
• 3:24
  Selbst bei einem Standard-Setup können Kampagnen-Logswap-Analysen und CRM-Daten leicht auf hunderte von Gigabytes anwachsen.
• 3:32
  Große Kunden mit mehreren Produkten gehen in Landen oft im Multi-Terabyte-Bereich.
• 3:35
  Das Problem ist nicht nur die Speicherkapazität.
• 3:38
  Große Modelltrainingslasten stopazieren jede Schwachstelle einer lokalen Maschine.
• 3:42
  CPUs laufen dauerhaft bei 100%, selbst High-End-GPUs bleiben untätig, während Daten nur langsam eintröpfeln.
• 3:48
  Die Festplatten-ISGO wird zum ständigen Flaschenhals, besonders wenn der Datensatz auf einem externen Laufwerk oder Netzlaufwerk liegt.
• 3:57
  Und dann ist da noch die Software-Ebene.
• 3:59
  Sobald Dateien groß genug werden, stößt selbst etwas so vielseitiges wie ein Jupyter-Notebook an seine Grenzen.
• 4:03
  Man kann eine CSV-Datei nicht einfach in den Arbeitsspeicher laden, wenn sie größer als die eigene SSD ist.
• 4:09
  Deshalb versuchen viele Teams, Dateien aufzuteilen, Daten zu samplen oder leichtgewichtige Ersatzdaten für die echten Produktionsdatensätze zu erstellen.
• 4:16
  Es ist ein Kompromiss, der den Laptop am Laufen hält, aber auf kostenwertvolle Erkenntnisse geht.
• 4:20
  Durch Sampling können subtile Muster verloren gehen, die die Modelleistung verbessert hätten.
• 4:24
  Das Aufteilen von Dateien führt zu Inkonsistenzen und macht das erneute Training unnötig mühsam.
• 4:29
  Es gibt einen intelligenteren Weg, um diesen gesamten Download- und Importzyklus zu umgehen.
• 4:34
  Microsoft Fabric verlagert die Schwerstarbeit komplett aus ihrer lokalen Umgebung weg.
• 4:39
  Das Training verlagert sich in die Cloud, wo Rechenressourcen direkt neben den gespeicherten Daten im Lakehouse liegen.
• 4:45
  Sie müssen keine Terabytes hin- und herschieben, sondern senden Ihren Code dorthin, wo die Daten bereits leben.
• 4:50
  Anstatt sich Sorgen zu machen, welcher Teil der Kundenhistorie in den RAM passt, können Sie sich auf die Struktur und Logik Ihres Trainingslaufs konzentrieren.
• 4:57
  Und hier ist der Punkt, den die meisten Teams übersehen.
• 5:01
  Der wahre Vorteil ist nicht nur die zusätzliche Leistung des Cloud-Computings.
• 5:05
  Es ist die Tatsache, dass Sie die Daten überhaupt nicht mehr verschieben müssen.
• 5:08
  Direkter Zugriff auf das Lakehouse, Schluss mit dem CSV-Cast.
• 5:12
  Was wäre, wenn Ihr Notebook Terabytes an Daten sofort laden könnte, ohne dass jemals ein Download-Fortschrittsbalken erscheint?
• 5:18
  Kein Export in CSV, kein Warten mehr auf Ladebalken, die sich über den Bildschirm schleppen.
• 5:22
  Geben Sie einfach die Abfrage ein, führen Sie sie aus und arbeiten Sie direkt mit den Ergebnissen.
• 5:27
  Das ist der Unterschied, wenn die Datenschicht kein externer Schritt ist, sondern in die Umgebung integriert, in der Sie ohnehin programmieren.
• 5:33
  In Fabric ist das Lakehouse nicht nur ein separater Speicher-Bucket, mit dem man sich ab und zu verbindet.
• 5:39
  Nee.
• 5:40
  Es ist die native Datenschicht für Notebooks.
• 5:43
  Das bedeutet, Ihr Code läuft in der selben Umgebung, in der die Daten physisch gespeichert sind.
• 5:47
  Sie übertragen nicht Millionen von Zeilen über das Netzwerk in Ihre Sitzung.
• 5:51
  Sie senden Anweisungen an die Daten an Ihrem Speicherort.
• 5:53
  Die Pipeline für die Modelleingabe ist kein Jonglieren mit Exporten und Importen und Importen.
• 5:58
  Es ist eine direkte Verbindung vom Speicher zu Spark und zu der Python- oder R-Logik, die Sie schreiben.
• 6:02
  Wenn Sie einen traditionellen Arbeitsablauf kennen, sind Ihnen die üblichen Probleme bereits bekannt.
• 6:05
  Jemand erstellt einen Extrakt aus dem Data Warehouse, schreibt ihn in eine CSV-Datei und gibt sie an das Data Science Team weiter, weiter.
• 6:12
  Damit ist das Schema eingefroren.
• 6:14
  In der nächsten Woche ändern sich die Quelldaten und der Extrakt ist bereits veraltet.
• 6:18
  In manchen Fällen erstellen sogar zwei verschiedene Teams ihre eigenen, leicht abweichenden Exporte.
• 6:23
  Und schon haben sie duplizierte Speicher mit widersprüchlichen Definitionen.
• 6:26
  Im besten Fall ist das nur ineffizient.
• 6:28
  Im schlimmsten Fall ist es der Grund, warum zwei auf denselben Daten trainierte Modelle widersprüchliche Vorhersagen liefern.
• 6:33
  Ein Team, mit dem ich gearbeitet habe, benötigte einen gefilterten Satz von Kundenaktivitätsdatensätzen für ein neues Abwanderungsmodell.
• 6:38
  Sie zogen alles aus dem Warehouse in eine lokale SQL-Datenbank, filterten es und exportierten das Ergebnis in eine CSV-Datei für die Trainingsumgebung.
• 6:45
  Das allein nahm fast einen ganzen Tag in Ihrem Netzwerk in Anspruch.
• 6:49
  Als in der nächsten Woche neue Aktivitätsdatensätze geladen wurden, mussten Sie den gesamten Prozess von vorne beginnen.
• 6:54
  Bis Sie mit dem eigentlichen Training beginnen konnten, hatten Sie mehr Zeit mit dem Dateimanagement verbracht als mit dem Programmieren.
• 6:59
  Der Performanceverlust betrifft nicht nur die Zeit für die Übertragungen.
• 7:03
  Untersuchungen in mehreren Unternehmen zeigen konsistente Gewinne, wenn Transformationen dort ausgeführt werden, wo die Daten gespeichert sind.
• 7:09
  Wenn Sie Joints, Filter und Aggregation direkt vor Ort statt nachgelagert durchführen, reduzieren Sie Overhead, Netzwerkhops und redundante Lesevorgänge.
• 7:17
  Fabric Notebooks nutzen im Hintergrund Spark, um dies zu ermöglichen.
• 7:20
  Anstatt also 400 Millionen Zeilen in Ihre Notebook-Sitzung zu laden, führt Spark diese Aggregation innerhalb der Lakehouse-Umgebung aus und liefert nur die Ergebnisse zurück, die Ihr Modell benötigt.
• 7:30
  Ähm.
• 7:32
  Wenn Sie in Python oder R arbeiten, beginnen Sie auch nicht bei Null. Null.
• 7:36
  Fabric enthält eine Reihe von Bibliotheken, die bereits für die Arbeit in großem Maßstab integriert sind.
• 7:41
  Die verteilte Verarbeitung ist also eine Option, sobald Sie ein neues Notebook öffnen.
• 7:49
  Das ist entscheidend, wenn Sie Fakten- und Dimensionstabellen im Bereich von hunderten Gigabytes zusammenführen oder rollierende Zeitfenster über mehrere Jahre Kundenhistorie berechnen müssen.
• 7:59
  Sobald die Abfrage abgeschlossen ist, steht der bereinigte, aggregierte Datensatz direkt für Ihren Feature-Engineering-Prozess bereit.
• 8:06
  Es entfällt die Zwischenphase des Speicherns auf die Festplatte, der Schemaüberprüfung und des erneuten Imports in ein lokales Trainings-Notebook.
• 8:12
  Sie haben eine komplette Vorbereitungsphase übersprung.
• 8:14
  Früher verbrachten Teams Tag ein, Tag aus, damit Spalten anzupassen und Filter neu auszuführen, sobald sich Quelldaten ändern.
• 8:18
  Mit diesem Setup können Sie noch in derselben Stunde, in der die Rohdaten aktualisiert wurden, Feature-Kombinationen für das Modell erkunden.
• 8:24
  Und genau da wird es interessant, denn sobald saubere, massive Datensätze direkt in Ihre Notebook-Sitzung fließen, beginnt sich Ihre Art, Features zu entwickeln, zu verändern, zu verändern.
• 8:36
  Feature-Engineering und Modellauswahl in großem Maßstab.
• 8:39
  Ihr Datensatz mag groß genug sein, um fast alles vorherzusagen, aber das bedeutet nicht, dass jede Spalte darin auch in Ihr Modell gehört.
• 8:45
  Der Unterschied zwischen einem Modell, das aussagekräftige Vorhersagen liefert und einem das nur Rauschen ausgibt, liegt oft darin, wie Sie Ihre Features auswählen und gestalten.
• 8:53
  Skalierung eröffnet Möglichkeiten, vergrößert aber auch Fehler.
• 8:57
  Bei massiven Datensätzen ist es nicht nur unübersichtlich, alle Rohfelder in Ihren Algorithmus zu werfen, es kann die Leistung sogar aktiv verschlechtern.
• 9:05
  Mehr Spalten bedeuten mehr zu schätzende Parameter und mehr Gelegenheiten für Ihr Modell, sich an Eigenheiten der Trainingsdaten anzupassen, die nicht generalisierbar sind.
• 9:14
  Die Overfitting wird einfacher, nicht schwieriger, wenn das Feature-Set aufgebläht ist.
• 9:19
  Obendrein bedeutet jede zusätzliche Variable mehr Rechenaufwand.
• 9:21
  Selbst in einer gut ausgestatteten Cloud-Umgebung verlangsamen 500 Roh-Features das Training, erhöhen den Speicherverbrauch und verkomplizieren jeden nachgelagerten Schritt im Vergleich zu einem schlanken Set von 50 gut entwickelten Features.
• 9:34
  Die versteckten Kosten sind nicht immer sofort auf der Uhr ersichtlich.
• 9:37
  Dieser Durchlauf mit 500 Features mag fehlerfrei beendet werden, könnte Ihnen aber ein Modell hinterlassen, das auf den Trainingsdaten nur geringfügig genauer ist, auf neuen Daten jedoch deutlich schlechter abschneidet.
• 9:45
  Wenn Sie diese Features verkleinern und verfeinern, verwandte Variablen zusammenführen, Kategorien effizienter kodieren oder Aggregate bilden, die Muster anstelle von Rohwerten erfassen, verkürzen Sie die Rechenzeit und verbessern gleichzeitig die Vorhersagequalität des Modells.
• 10:02
  Bestimmte Datenstrukturen erschweren dies.
• 10:06
  Features mit hoher Kardinalität, wie eindeutige Produkt-Schools oder Kunden-IDs, können bei naiver Handhabung in tausende kodierte Spalten explodieren.
• 10:14
  Spärliche Daten, bei denen die meisten Felder für die meisten Datensätze leer sind, können nützliche Signale verbergen, verschwenden aber Ressourcen durch das Speichern und Verarbeiten von überwiegend fehlenden Werten.
• 10:26
  Bei Themen wie der Vorhersage von Kundenabwanderung gibt es zudem oft zeitliche Muster.
• 10:30
  Kaufzyklen, saisonale Aktivitäten oder Onboarding-Phasen, die in gewöhnlichen statischen Feldern nicht auftauchen.
• 10:38
  Feature Engineering in diesem Maßstab erfordert Transformationen, die Muster verdichten und hervorheben, ohne den Datensatz mit Rauschen zu überfluten.
• 10:46
  Genau hier machen sich Automatisierungen und Tools für verteiltes Rechnen bezahlt.
• 10:49
  Bibliotheken wie Feature-Tools können die Erstellung von Aggregaten und rollierenden Merkmalen in großen relationalen Datensätzen automatisieren.
• 10:56
  In Fabric können diese Transformationen auf Spark laufen, sodass Sie die Erstellung hunderter potenzieller Merkmale skalieren können, ohne alles in den Arbeitsspeicher eines einzelnen Rechners laden zu müssen.
• 11:05
  Zeitbasierte Gruppierungen, Aggregator auf Kundenebene oder Verhältnisse zwischen Kennzahlen können iterativ erstellt und getestet werden, ohne Ihren Workflow zu unterbrechen.
• 11:13
  Sobald Sie Ihr Merkmalset kuratiert haben, wird die Modellauswahl zu einem eigenen Balanceakt.
• 11:20
  Verschiedene Algorithmen interagieren auf unterschiedliche Weise mit großen Datenmengen.
• 11:23
  Gradient-Boosting-Frameworks wie XGBoost oder LightGBM können große tabellarische Datensätze effizient verarbeiten,
• 11:29
  zahlen aber bei jedem Merkmal einen Preis an Speicher- und Iterationszeit.
• 11:32
  Logistische Regression skaliert gut und trainiert schnell, kann jedoch komplexe, nicht-lineare Zusammenhänge nur erfassen, wenn Sie diese selbst in die Merkmale einbauen.
• 11:42
  Deep-Learning-Modelle können theoretisch reichhaltigere Muster erkennen, erfordern aber auch mehr Tuning und höhere Rechenleistungen.
• 11:48
  In der Fabrikumgebung können Sie diese bereitstellen, müssen aber abwägen, ob der Nutzen die Trainingskosten rechtfertigt.
• 11:53
  Die gute Nachricht ist, da Fabrik-Notebooks direkt mit Ihrem Lakehouse verbunden sind, können Sie diese Strategien ohne die üblichen Engpässe testen.
• 12:01
  Sie können mehrere Trainingsläufe mit verschiedenen Merkmalsets und Algorithmen auf denselben Daten starten, ohne sie für jeden Versuch neu laden oder umformen zu müssen.
• 12:10
  Diese Fähigkeit zur schnellen Iteration bedeutet, dass Sie nicht auf Vermutungen angewiesen sind, welcher Ansatz am besten funktioniert.
• 12:16
  Sie können messen und entscheiden.
• 12:17
  Gut entwickelte Merkmale, die auf die richtige Modellarchitektur abgestimmt sind, können Laufzeiten deutlich verkürzen, den Speicherbedarf senken und die Genauigkeit bei neuen Daten steigern.
• 12:26
  Sie erhalten schnellere Experimentierzyklen und zuverlässigere Ergebnisse und investieren Ihr Rechenbudget in sinnvolles Training, statt unnötige Daten zu verarbeiten.
• 12:36
  Der nächste Schritt, der diese groß angelegten Läufe produktiv hält, ist die Echtzeitüberwachung und Auswertung, damit Sie genau wissen, was während des Cloud-Trainings passiert.
• 12:47
  Training, Überwachung und Auswertung im Cloud-Maßstab.
• 12:49
  Das Training mit Gigabytes an Daten klingt traumhaft, bis man da sitzt und sich fragt, ob der Job noch läuft oder vor einer Stunde still und heimlich abgestürzt ist, ist.
• 12:57
  Wenn alles in der Cloud abläuft, fehlt das unmittelbare Feedback, das man beim Beobachten der Protokolle in einem lokalen Terminal erhält.
• 13:04
  Das ist in Ordnung, wenn der Job in wenigen Minuten erledigt ist.
• 13:06
  Es wird zum Problem, wenn es Stunden dauert und Sie nicht wissen, ob Sie Fortschritte machen.
• 13:09
  Das Ausführen von Training in einer Remote-Umgebung verändert Ihre Sichtweise auf die Transparenz.
• 13:15
  In einer Lokalsitzung erkennen Sie Probleme sofort.
• 13:18
  Fehlende Werte in einem Feld, ein Datentypfehler oder ein hängender Import.
• 13:23
  In einem Cloud-Cluster kann derselbe Fehler in einer Logdatei vergraben sein, die man erst viel später prüft.
• 13:28
  Die wollen.
• 13:30
  Und da die Ressourcen bereitgestellt werden, während der Prozess technisch läuft, kostet jede Minute eines fehlersbares Geld.
• 13:36
  Die Kosten, wenn man ein Problem zu spät erkennt, summieren sich schnell.
• 13:40
  Ich habe einen Trend-Prediction-Job gesehen, der Freitagabend mit einer geschätzten Laufzeit von 8 Stunden gestartet wurde.
• 13:46
  Am Montagmorgen stellte das Team fest, dass er vor der ersten Epoche abgebrochen war.
• 13:50
  Oder eine Spalte als Text statt als Zahl geladen wurde.
• 13:53
  Die tatsächliche Laufzeit?
• 13:55
  10 Minuten Verschwendung zu Beginn, 8 Stunden auf der Abrechnung.
• 13:58
  Solche Fehler untergraben das Vertrauen in den Prozess und verlangsame Iterationszyklen enorm.
• 14:04
  Fabric geht dies mit Echtzeit-Job-Monitoring an.
• 14:07
  Dass Sie direkt neben Ihrem Notebook öffnen können, äh.
• 14:10
  Sie erhalten Live-Metriken zu Speicherauslastung, CPU-Nutzung und Fortschritt der Trainingsepochen, äh.
• 14:17
  Logs werden während des Jobs gestreamt, sodass Sie Warnungen oder Fehler erkennen, bevor Sie zum kompletten Ausfall führen.
• 14:25
  Wenn etwas nicht stimmt, können Sie den Lauf sofort stoppen, anstatt es später auf die harte Tour zu erfahren.
• 14:29
  Es geht jedoch nicht nur ums Überwachung.
• 14:31
  Sie können Checkpoints während des Trainings einrichten, damit der Modellzustand regelmäßig gespeichert wird.
• 14:35
  Wenn der Job stoppt, sei es durch einen Fehler, ein Ressourcenlimit oder eine Unterbrechung, können Sie beim letzten Checkpoint fortsetzen, statt von vorn anzufangen, statt von vorn anzufangen.
• 14:44
  Auch die Versionierung spielt hier eine Rolle.
• 14:45
  Indem Sie trainierte Modellversionen mit Parametern und Datensplits speichern, können Sie frühere Konfigurationen nutzen, ohne die gesamte Umgebung neu aufbauen zu müssen.
• 14:55
  Zwischenspeicherungen sind nicht nur eine Absicherung, sie machen groß angelegte Experimente erst möglich, äh.
• 15:03
  Sie können von einem vielversprechenden Checkpoint abzweigen und andere Hyperparameter testen, ohne Zeit durch erneutes Laden und Training des Basismodells zu verlieren.
• 15:10
  Bei Datensätzen im Gigabyte-Bereich kann das den Unterschied zwischen drei Experimenten pro Tag oder nur einem bedeuten, bedeuten.
• 15:15
  Wenn das Modell fertig ist, bringt die Evaluierung in diesem Maßstab eigene Herausforderungen mit sich.
• 15:21
  Man kann nicht immer das gesamte Testset in einem Durchgang bewerten, ohne das System massiv auszubremsen.
• 15:26
  Balanced Sampling hilft hier, indem es Klassenverhältnisse beibehält und den Datensatz auf eine schnelle auswertbare Größe reduziert.
• 15:32
  Höhere Genauigkeit ermöglicht die verteilte Evaluierung, die Scoring-Aufgabe auf den Cluster aufzuteilen, wobei die Ergebnisse automatisch aggregiert werden.
• 15:39
  Fabric unterstützt Python-Bibliotheken wie MLIP und verteilte Sick-It-Learn-Workflows, um dies zu ermöglichen.
• 15:46
  Statt darauf zu warten, dass ein einzelner Rechner Metriken für hunderte Millionen Datensätze berechnet,
• 15:51
  können Sie die Aufgabe verteilen und die konsolidierten Werte für Genauigkeit, Präzision, Trefferquote oder F1-Coin einen Bruchteil der Zeit abrufen.
• 15:58
  Die Daten verlassen niemals das Lakehouse, sodass Sie sich nicht mit dem Export von Testdaten oder manuellen Zusammenführungen befassen.