WEBVTT 00:00:00.270 --> 00:00:07.030 Bereit für 10 Tage voller Microsoft 365, Co-Pilot KI-Asherer und den Vordenkern der Arbeitswelt von morgen, Tein. 00:00:07.850 --> 00:00:11.930 Diesen Januar ist die M365 kommt zurück und wir legen noch eine Schippe drauf. 00:00:12.870 --> 00:00:18.050 Seien Sie dabei bei Live-Sessions, Praxis-Demos und Expertenwissen von MVPs und Fachleuten aus aller Welt, A-Elt. 00:00:18.670 --> 00:00:21.090 Keine generischen Folien. Kein endloses Password-Bingo. 00:00:21.410 --> 00:00:28.350 Wir gehen echte Herausforderungen an. Copalut Studio, KI-Agenten, Fabrik, Sicherheit, Governance und Automatisierung. 00:00:28.350 --> 00:00:34.270 Bucket. Egal ob IT-Profi-Entwickler oder Führungskraft-E-Skip-Sessions, die genau auf Sie zugeschnitten sind. 00:00:35.410 --> 00:00:39.950 An 10 vollen Tagen können Sie zahlreiche Technologien erkunden und sich mit der globalen Community vernetzen. 00:00:40.890 --> 00:00:44.310 Schauen Sie live zu und nehmen Sie praktische Erkenntnisse für Ihr Unternehmen mit. 00:00:44.850 --> 00:00:50.490 20. Januar. 10 Tage. Eine Microsoft-Community. Die Anmeldung ist jetzt geöffnet. 00:00:51.690 --> 00:00:55.530 Besuchen Sie mtrenum65.com.net und sichern Sie sich noch heute Ihren Platz. 00:00:55.530 --> 00:00:58.750 Das ist mtrenum55.net. 00:00:59.990 --> 00:01:03.250 Melden Sie sich jetzt unter mtrenum55.net an. Wir sehen uns live. 00:01:03.850 --> 00:01:04.430 Im Januar. 00:01:05.230 --> 00:01:10.090 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? 00:01:10.790 --> 00:01:11.650 Damit ist nicht allein. 00:01:12.350 --> 00:01:15.210 Die meisten geschäftlichen Datensätze sind unserer lokalen Hardware entwachsen. 00:01:15.210 --> 00:01:20.290 Aber was wäre, wenn Ihr gesamter Multi-Terabyte-Datensatz sofort in Ihrem Trainings-Notebook verfügbar wäre? 00:01:20.930 --> 00:01:22.550 Keine Exporte, kein CSV-Chaos. 00:01:23.170 --> 00:01:29.390 Heute tauchen wir ein in die integrierten Notebooks von Microsoft Fabric, wo das Training Ihres Modells direkt bei Ihren Lakehouse-Daten stattfindet. 00:01:29.390 --> 00:01:37.390 Wir zeigen Ihnen genau, wie dieses Setup tagelange Verarbeitungszeit spart und Sie dabei kompromisslos in Python oder R arbeiten lässt. 00:01:37.390 --> 00:01:46.670 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. 00:01:47.710 --> 00:01:53.670 Ersetzen Sie diese Tabelle nun durch 12 Terabyte an rohen Kundentransaktionen aus jahrelangen Aktivitäten mit dutzenden Feldern pro Datensatz. 00:01:54.950 --> 00:01:57.390 Schon vor dem Start wissen Sie, dass das wehtun wird. 00:01:58.210 --> 00:02:00.210 Genau in dieser Lage befinden sich viele Marketing-Teams. 00:02:00.990 --> 00:02:05.350 Sie haben eine transaktionale Datenbank, die problemlos das Rückgrat eines fortschrittlichen KI-Projekts bilden könnte. 00:02:05.350 --> 00:02:15.050 Churn-Vorhersage, Zielgruppensegmentierung, Personalisierung, in Echtzeit, doch Ihre Werkzeuge stecken noch auf dem Desktop fest. 00:02:17.620 --> 00:02:28.080 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. 00:02:29.460 --> 00:02:32.140 Wenn Teams dies lokal versuchen, zeigen sich schnell die Grenzen. 00:02:32.140 --> 00:02:38.680 Die Verarbeitung kriegt dahin, die Benutzeroberfläche reagiert mit Sekundenverzögerung und Export-Skripte, die früher Minuten brauchten, laufen jetzt stundenlang. 00:02:39.420 --> 00:02:41.820 Noch schlimmer, größere Workloads werden nicht nur langsamer, sie bleiben stehen. 00:02:42.440 --> 00:02:47.840 Weicher Fehler, Festplattenüberlastung oder Kerne Neustarts führen dazu, dass Trainingsläufe nicht nur länger dauern, sondern oft niemals fertig werden. 00:02:49.100 --> 00:02:54.260 Und wenn es um das Training eines KI-Modells geht, ist das verschwendete Rechenleistung, verlorene Zeit und eine verpasste Chance. 00:02:54.260 --> 00:03:00.640 Ein Versuch zur Abwanderungsvorhersage, den ich sah, war als nächtlicher Lauf in einer lokalen Python-Umgebung geplant. 00:03:01.980 --> 00:03:07.860 20 Stunden später schlug der Prozess fehl, weil der letzte Teil des Datensatzes die RAM-Auslastung über das Limit trieb, trieb. 00:03:08.400 --> 00:03:11.680 Das Team verlor einen ganzen Tag, ohne auch nur einen einzigen Trainingsmesswert zurückzuerhalten. 00:03:12.260 --> 00:03:14.220 Falls das extrem klingt, es wird immer häufiger zur Realität. 00:03:16.280 --> 00:03:23.520 Unternehmensmarketing-Datensätze wachsen jährlich an, getrieben durch umfassenderes Tracking, Omnichannel-Erlebnisse und ereignisbasiertes Logging. 00:03:24.760 --> 00:03:30.940 Selbst bei einem Standard-Setup können Kampagnen-Logswap-Analysen und CRM-Daten leicht auf hunderte von Gigabytes anwachsen. 00:03:32.160 --> 00:03:35.260 Große Kunden mit mehreren Produkten gehen in Landen oft im Multi-Terabyte-Bereich. 00:03:35.840 --> 00:03:37.280 Das Problem ist nicht nur die Speicherkapazität. 00:03:38.040 --> 00:03:40.800 Große Modelltrainingslasten stopazieren jede Schwachstelle einer lokalen Maschine. 00:03:42.420 --> 00:03:48.240 CPUs laufen dauerhaft bei 100%, selbst High-End-GPUs bleiben untätig, während Daten nur langsam eintröpfeln. 00:03:48.240 --> 00:03:56.560 Die Festplatten-ISGO wird zum ständigen Flaschenhals, besonders wenn der Datensatz auf einem externen Laufwerk oder Netzlaufwerk liegt. 00:03:57.480 --> 00:03:58.720 Und dann ist da noch die Software-Ebene. 00:03:59.320 --> 00:04:03.940 Sobald Dateien groß genug werden, stößt selbst etwas so vielseitiges wie ein Jupyter-Notebook an seine Grenzen. 00:04:03.940 --> 00:04:08.960 Man kann eine CSV-Datei nicht einfach in den Arbeitsspeicher laden, wenn sie größer als die eigene SSD ist. 00:04:09.380 --> 00:04:15.660 Deshalb versuchen viele Teams, Dateien aufzuteilen, Daten zu samplen oder leichtgewichtige Ersatzdaten für die echten Produktionsdatensätze zu erstellen. 00:04:16.280 --> 00:04:19.860 Es ist ein Kompromiss, der den Laptop am Laufen hält, aber auf kostenwertvolle Erkenntnisse geht. 00:04:20.560 --> 00:04:23.640 Durch Sampling können subtile Muster verloren gehen, die die Modelleistung verbessert hätten. 00:04:24.600 --> 00:04:29.960 Das Aufteilen von Dateien führt zu Inkonsistenzen und macht das erneute Training unnötig mühsam. 00:04:29.960 --> 00:04:34.180 Es gibt einen intelligenteren Weg, um diesen gesamten Download- und Importzyklus zu umgehen. 00:04:34.860 --> 00:04:38.180 Microsoft Fabric verlagert die Schwerstarbeit komplett aus ihrer lokalen Umgebung weg. 00:04:39.180 --> 00:04:44.100 Das Training verlagert sich in die Cloud, wo Rechenressourcen direkt neben den gespeicherten Daten im Lakehouse liegen. 00:04:45.180 --> 00:04:49.840 Sie müssen keine Terabytes hin- und herschieben, sondern senden Ihren Code dorthin, wo die Daten bereits leben. 00:04:50.720 --> 00:04:57.020 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. 00:04:57.020 --> 00:05:01.080 Und hier ist der Punkt, den die meisten Teams übersehen. 00:05:01.800 --> 00:05:04.660 Der wahre Vorteil ist nicht nur die zusätzliche Leistung des Cloud-Computings. 00:05:05.480 --> 00:05:07.700 Es ist die Tatsache, dass Sie die Daten überhaupt nicht mehr verschieben müssen. 00:05:08.940 --> 00:05:11.180 Direkter Zugriff auf das Lakehouse, Schluss mit dem CSV-Cast. 00:05:12.120 --> 00:05:17.500 Was wäre, wenn Ihr Notebook Terabytes an Daten sofort laden könnte, ohne dass jemals ein Download-Fortschrittsbalken erscheint? 00:05:18.780 --> 00:05:22.140 Kein Export in CSV, kein Warten mehr auf Ladebalken, die sich über den Bildschirm schleppen. 00:05:22.660 --> 00:05:26.520 Geben Sie einfach die Abfrage ein, führen Sie sie aus und arbeiten Sie direkt mit den Ergebnissen. 00:05:27.360 --> 00:05:32.860 Das ist der Unterschied, wenn die Datenschicht kein externer Schritt ist, sondern in die Umgebung integriert, in der Sie ohnehin programmieren. 00:05:33.940 --> 00:05:38.500 In Fabric ist das Lakehouse nicht nur ein separater Speicher-Bucket, mit dem man sich ab und zu verbindet. 00:05:39.120 --> 00:05:39.260 Nee. 00:05:40.220 --> 00:05:42.100 Es ist die native Datenschicht für Notebooks. 00:05:43.080 --> 00:05:46.800 Das bedeutet, Ihr Code läuft in der selben Umgebung, in der die Daten physisch gespeichert sind. 00:05:47.800 --> 00:05:50.700 Sie übertragen nicht Millionen von Zeilen über das Netzwerk in Ihre Sitzung. 00:05:51.220 --> 00:05:53.800 Sie senden Anweisungen an die Daten an Ihrem Speicherort. 00:05:53.800 --> 00:05:58.040 Die Pipeline für die Modelleingabe ist kein Jonglieren mit Exporten und Importen und Importen. 00:05:58.360 --> 00:06:01.940 Es ist eine direkte Verbindung vom Speicher zu Spark und zu der Python- oder R-Logik, die Sie schreiben. 00:06:02.440 --> 00:06:05.740 Wenn Sie einen traditionellen Arbeitsablauf kennen, sind Ihnen die üblichen Probleme bereits bekannt. 00:06:05.740 --> 00:06:12.120 Jemand erstellt einen Extrakt aus dem Data Warehouse, schreibt ihn in eine CSV-Datei und gibt sie an das Data Science Team weiter, weiter. 00:06:12.600 --> 00:06:14.060 Damit ist das Schema eingefroren. 00:06:14.640 --> 00:06:17.640 In der nächsten Woche ändern sich die Quelldaten und der Extrakt ist bereits veraltet. 00:06:18.440 --> 00:06:22.260 In manchen Fällen erstellen sogar zwei verschiedene Teams ihre eigenen, leicht abweichenden Exporte. 00:06:23.120 --> 00:06:25.980 Und schon haben sie duplizierte Speicher mit widersprüchlichen Definitionen. 00:06:26.400 --> 00:06:27.680 Im besten Fall ist das nur ineffizient. 00:06:28.320 --> 00:06:33.000 Im schlimmsten Fall ist es der Grund, warum zwei auf denselben Daten trainierte Modelle widersprüchliche Vorhersagen liefern. 00:06:33.000 --> 00:06:38.180 Ein Team, mit dem ich gearbeitet habe, benötigte einen gefilterten Satz von Kundenaktivitätsdatensätzen für ein neues Abwanderungsmodell. 00:06:38.820 --> 00:06:45.380 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. 00:06:45.920 --> 00:06:48.660 Das allein nahm fast einen ganzen Tag in Ihrem Netzwerk in Anspruch. 00:06:49.300 --> 00:06:53.740 Als in der nächsten Woche neue Aktivitätsdatensätze geladen wurden, mussten Sie den gesamten Prozess von vorne beginnen. 00:06:54.400 --> 00:06:58.760 Bis Sie mit dem eigentlichen Training beginnen konnten, hatten Sie mehr Zeit mit dem Dateimanagement verbracht als mit dem Programmieren. 00:06:59.680 --> 00:07:02.260 Der Performanceverlust betrifft nicht nur die Zeit für die Übertragungen. 00:07:03.480 --> 00:07:08.740 Untersuchungen in mehreren Unternehmen zeigen konsistente Gewinne, wenn Transformationen dort ausgeführt werden, wo die Daten gespeichert sind. 00:07:09.740 --> 00:07:16.560 Wenn Sie Joints, Filter und Aggregation direkt vor Ort statt nachgelagert durchführen, reduzieren Sie Overhead, Netzwerkhops und redundante Lesevorgänge. 00:07:17.740 --> 00:07:20.680 Fabric Notebooks nutzen im Hintergrund Spark, um dies zu ermöglichen. 00:07:20.680 --> 00:07:30.220 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. 00:07:30.560 --> 00:07:30.820 Ähm. 00:07:32.100 --> 00:07:35.520 Wenn Sie in Python oder R arbeiten, beginnen Sie auch nicht bei Null. Null. 00:07:36.560 --> 00:07:41.280 Fabric enthält eine Reihe von Bibliotheken, die bereits für die Arbeit in großem Maßstab integriert sind. 00:07:41.280 --> 00:07:48.420 Die verteilte Verarbeitung ist also eine Option, sobald Sie ein neues Notebook öffnen. 00:07:49.640 --> 00:07:59.100 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. 00:07:59.100 --> 00:08:05.580 Sobald die Abfrage abgeschlossen ist, steht der bereinigte, aggregierte Datensatz direkt für Ihren Feature-Engineering-Prozess bereit. 00:08:06.500 --> 00:08:12.100 Es entfällt die Zwischenphase des Speicherns auf die Festplatte, der Schemaüberprüfung und des erneuten Imports in ein lokales Trainings-Notebook. 00:08:12.600 --> 00:08:14.160 Sie haben eine komplette Vorbereitungsphase übersprung. 00:08:14.520 --> 00:08:18.500 Früher verbrachten Teams Tag ein, Tag aus, damit Spalten anzupassen und Filter neu auszuführen, sobald sich Quelldaten ändern. 00:08:18.900 --> 00:08:24.940 Mit diesem Setup können Sie noch in derselben Stunde, in der die Rohdaten aktualisiert wurden, Feature-Kombinationen für das Modell erkunden. 00:08:24.940 --> 00:08:35.560 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. 00:08:36.700 --> 00:08:38.660 Feature-Engineering und Modellauswahl in großem Maßstab. 00:08:39.560 --> 00:08:44.760 Ihr Datensatz mag groß genug sein, um fast alles vorherzusagen, aber das bedeutet nicht, dass jede Spalte darin auch in Ihr Modell gehört. 00:08:45.920 --> 00:08:53.020 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. 00:08:53.020 --> 00:08:56.380 Skalierung eröffnet Möglichkeiten, vergrößert aber auch Fehler. 00:08:57.640 --> 00:09:03.680 Bei massiven Datensätzen ist es nicht nur unübersichtlich, alle Rohfelder in Ihren Algorithmus zu werfen, es kann die Leistung sogar aktiv verschlechtern. 00:09:05.120 --> 00:09:13.920 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. 00:09:14.420 --> 00:09:18.340 Die Overfitting wird einfacher, nicht schwieriger, wenn das Feature-Set aufgebläht ist. 00:09:19.120 --> 00:09:21.880 Obendrein bedeutet jede zusätzliche Variable mehr Rechenaufwand. 00:09:21.880 --> 00:09:33.540 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. 00:09:34.460 --> 00:09:36.600 Die versteckten Kosten sind nicht immer sofort auf der Uhr ersichtlich. 00:09:37.160 --> 00:09:45.980 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. 00:09:45.980 --> 00:10:02.480 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. 00:10:02.480 --> 00:10:05.900 Bestimmte Datenstrukturen erschweren dies. 00:10:06.840 --> 00:10:14.480 Features mit hoher Kardinalität, wie eindeutige Produkt-Schools oder Kunden-IDs, können bei naiver Handhabung in tausende kodierte Spalten explodieren. 00:10:14.480 --> 00:10:25.020 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. 00:10:26.020 --> 00:10:30.120 Bei Themen wie der Vorhersage von Kundenabwanderung gibt es zudem oft zeitliche Muster. 00:10:30.380 --> 00:10:36.260 Kaufzyklen, saisonale Aktivitäten oder Onboarding-Phasen, die in gewöhnlichen statischen Feldern nicht auftauchen. 00:10:38.610 --> 00:10:45.010 Feature Engineering in diesem Maßstab erfordert Transformationen, die Muster verdichten und hervorheben, ohne den Datensatz mit Rauschen zu überfluten. 00:10:46.070 --> 00:10:49.190 Genau hier machen sich Automatisierungen und Tools für verteiltes Rechnen bezahlt. 00:10:49.970 --> 00:10:55.710 Bibliotheken wie Feature-Tools können die Erstellung von Aggregaten und rollierenden Merkmalen in großen relationalen Datensätzen automatisieren. 00:10:56.030 --> 00:11:04.230 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. 00:11:05.870 --> 00:11:13.710 Zeitbasierte Gruppierungen, Aggregator auf Kundenebene oder Verhältnisse zwischen Kennzahlen können iterativ erstellt und getestet werden, ohne Ihren Workflow zu unterbrechen. 00:11:13.710 --> 00:11:19.410 Sobald Sie Ihr Merkmalset kuratiert haben, wird die Modellauswahl zu einem eigenen Balanceakt. 00:11:20.150 --> 00:11:23.090 Verschiedene Algorithmen interagieren auf unterschiedliche Weise mit großen Datenmengen. 00:11:23.670 --> 00:11:28.830 Gradient-Boosting-Frameworks wie XGBoost oder LightGBM können große tabellarische Datensätze effizient verarbeiten, 00:11:29.010 --> 00:11:32.310 zahlen aber bei jedem Merkmal einen Preis an Speicher- und Iterationszeit. 00:11:32.310 --> 00:11:41.710 Logistische Regression skaliert gut und trainiert schnell, kann jedoch komplexe, nicht-lineare Zusammenhänge nur erfassen, wenn Sie diese selbst in die Merkmale einbauen. 00:11:42.990 --> 00:11:47.310 Deep-Learning-Modelle können theoretisch reichhaltigere Muster erkennen, erfordern aber auch mehr Tuning und höhere Rechenleistungen. 00:11:48.530 --> 00:11:53.150 In der Fabrikumgebung können Sie diese bereitstellen, müssen aber abwägen, ob der Nutzen die Trainingskosten rechtfertigt. 00:11:53.150 --> 00:12:00.190 Die gute Nachricht ist, da Fabrik-Notebooks direkt mit Ihrem Lakehouse verbunden sind, können Sie diese Strategien ohne die üblichen Engpässe testen. 00:12:01.590 --> 00:12:09.570 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. 00:12:10.850 --> 00:12:15.350 Diese Fähigkeit zur schnellen Iteration bedeutet, dass Sie nicht auf Vermutungen angewiesen sind, welcher Ansatz am besten funktioniert. 00:12:16.150 --> 00:12:17.150 Sie können messen und entscheiden. 00:12:17.150 --> 00:12:25.370 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. 00:12:26.750 --> 00:12:35.570 Sie erhalten schnellere Experimentierzyklen und zuverlässigere Ergebnisse und investieren Ihr Rechenbudget in sinnvolles Training, statt unnötige Daten zu verarbeiten. 00:12:36.730 --> 00:12:45.390 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. 00:12:47.150 --> 00:12:49.330 Training, Überwachung und Auswertung im Cloud-Maßstab. 00:12:49.970 --> 00:12:56.750 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. 00:12:57.750 --> 00:13:03.690 Wenn alles in der Cloud abläuft, fehlt das unmittelbare Feedback, das man beim Beobachten der Protokolle in einem lokalen Terminal erhält. 00:13:04.170 --> 00:13:06.090 Das ist in Ordnung, wenn der Job in wenigen Minuten erledigt ist. 00:13:06.650 --> 00:13:09.930 Es wird zum Problem, wenn es Stunden dauert und Sie nicht wissen, ob Sie Fortschritte machen. 00:13:09.930 --> 00:13:15.030 Das Ausführen von Training in einer Remote-Umgebung verändert Ihre Sichtweise auf die Transparenz. 00:13:15.950 --> 00:13:17.930 In einer Lokalsitzung erkennen Sie Probleme sofort. 00:13:18.810 --> 00:13:22.490 Fehlende Werte in einem Feld, ein Datentypfehler oder ein hängender Import. 00:13:23.350 --> 00:13:28.750 In einem Cloud-Cluster kann derselbe Fehler in einer Logdatei vergraben sein, die man erst viel später prüft. 00:13:28.930 --> 00:13:29.250 Die wollen. 00:13:30.450 --> 00:13:36.430 Und da die Ressourcen bereitgestellt werden, während der Prozess technisch läuft, kostet jede Minute eines fehlersbares Geld. 00:13:36.430 --> 00:13:39.770 Die Kosten, wenn man ein Problem zu spät erkennt, summieren sich schnell. 00:13:40.630 --> 00:13:45.030 Ich habe einen Trend-Prediction-Job gesehen, der Freitagabend mit einer geschätzten Laufzeit von 8 Stunden gestartet wurde. 00:13:46.590 --> 00:13:50.030 Am Montagmorgen stellte das Team fest, dass er vor der ersten Epoche abgebrochen war. 00:13:50.270 --> 00:13:52.710 Oder eine Spalte als Text statt als Zahl geladen wurde. 00:13:53.950 --> 00:13:54.710 Die tatsächliche Laufzeit? 00:13:55.250 --> 00:13:57.850 10 Minuten Verschwendung zu Beginn, 8 Stunden auf der Abrechnung. 00:13:58.770 --> 00:14:02.810 Solche Fehler untergraben das Vertrauen in den Prozess und verlangsame Iterationszyklen enorm. 00:14:04.170 --> 00:14:06.290 Fabric geht dies mit Echtzeit-Job-Monitoring an. 00:14:07.170 --> 00:14:09.590 Dass Sie direkt neben Ihrem Notebook öffnen können, äh. 00:14:10.510 --> 00:14:16.050 Sie erhalten Live-Metriken zu Speicherauslastung, CPU-Nutzung und Fortschritt der Trainingsepochen, äh. 00:14:17.890 --> 00:14:23.930 Logs werden während des Jobs gestreamt, sodass Sie Warnungen oder Fehler erkennen, bevor Sie zum kompletten Ausfall führen. 00:14:25.290 --> 00:14:28.930 Wenn etwas nicht stimmt, können Sie den Lauf sofort stoppen, anstatt es später auf die harte Tour zu erfahren. 00:14:29.750 --> 00:14:30.950 Es geht jedoch nicht nur ums Überwachung. 00:14:31.170 --> 00:14:35.110 Sie können Checkpoints während des Trainings einrichten, damit der Modellzustand regelmäßig gespeichert wird. 00:14:35.110 --> 00:14:44.170 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. 00:14:44.410 --> 00:14:45.670 Auch die Versionierung spielt hier eine Rolle. 00:14:45.670 --> 00:14:55.090 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. 00:14:55.090 --> 00:15:02.350 Zwischenspeicherungen sind nicht nur eine Absicherung, sie machen groß angelegte Experimente erst möglich, äh. 00:15:03.090 --> 00:15:09.990 Sie können von einem vielversprechenden Checkpoint abzweigen und andere Hyperparameter testen, ohne Zeit durch erneutes Laden und Training des Basismodells zu verlieren. 00:15:10.990 --> 00:15:15.550 Bei Datensätzen im Gigabyte-Bereich kann das den Unterschied zwischen drei Experimenten pro Tag oder nur einem bedeuten, bedeuten. 00:15:15.550 --> 00:15:20.310 Wenn das Modell fertig ist, bringt die Evaluierung in diesem Maßstab eigene Herausforderungen mit sich. 00:15:21.430 --> 00:15:25.570 Man kann nicht immer das gesamte Testset in einem Durchgang bewerten, ohne das System massiv auszubremsen. 00:15:26.910 --> 00:15:32.050 Balanced Sampling hilft hier, indem es Klassenverhältnisse beibehält und den Datensatz auf eine schnelle auswertbare Größe reduziert. 00:15:32.690 --> 00:15:39.550 Höhere Genauigkeit ermöglicht die verteilte Evaluierung, die Scoring-Aufgabe auf den Cluster aufzuteilen, wobei die Ergebnisse automatisch aggregiert werden. 00:15:39.550 --> 00:15:46.150 Fabric unterstützt Python-Bibliotheken wie MLIP und verteilte Sick-It-Learn-Workflows, um dies zu ermöglichen. 00:15:46.930 --> 00:15:50.930 Statt darauf zu warten, dass ein einzelner Rechner Metriken für hunderte Millionen Datensätze berechnet, 00:15:51.490 --> 00:15:57.710 können Sie die Aufgabe verteilen und die konsolidierten Werte für Genauigkeit, Präzision, Trefferquote oder F1-Coin einen Bruchteil der Zeit abrufen. 00:15:58.270 --> 00:16:03.350 Die Daten verlassen niemals das Lakehouse, sodass Sie sich nicht mit dem Export von Testdaten oder manuellen Zusammenführungen befassen.