Machine Learning auf Big Data

Wir entwerfen ML-Plattformen auf Basis einiger weniger Prinzipien: Features sollten einmal definiert und wiederverwendet werden; Experimente sollten standardmäßig reproduzierbar sein; Modelle sollten versioniert und registriert werden, bevor sie in Produktion gehen; und Inferenzpfade sollten auf die gleiche Weise beobachtbar sein wie die zugrunde liegenden Dienste. Die Prinzipien sind nicht neu; die Disziplin ihrer konsequenten Anwendung trennt Plattformen, die sich kumulativ verbessern, von solchen, die erstarren.

Unser bevorzugtes Toolkit variiert je nach Umgebung. Wir haben auf verwalteten Angeboten wie Databricks, SageMaker, Vertex AI und Azure ML aufgebaut, auf Open-Source-Stacks (MLflow, Feast, Ray, Kubeflow, Argo) auf Kubernetes und auf Hybriden aus beiden. Die Wahl wird durch Ihre bestehenden Investitionen, den operativen Komfort Ihres Teams und das Latenzprofil der jeweiligen Workloads bestimmt.

Bei all dem bestehen wir auf einigen nicht verhandelbaren Punkten: Jedes Artefakt (Datensatz, Feature-Set, Modell) wird durch einen inhaltsadressierbaren Hash identifiziert; jede Beförderung zwischen Umgebungen wird mit der Herkunft der Eingaben und den Testergebnissen, die sie gerechtfertigt haben, protokolliert; und jedes Modell in Produktion wird mit einem Monitor gekoppelt, der weiß, wie „gut“ aussieht.

• Reproduzierbare Trainings-Pipelines
• Feature Stores mit Online- und Offline-Parität
• Vektor-Stores für Abruf und Ähnlichkeit
• Modell-Registry, Staging und Rollback
• Drift-, Performance- und Kostenüberwachung
• Kostenbewusstes Training und Inferenz

Verteiltes Training wird seltener gerechtfertigt, als es versucht wird. Viele unserer Kunden kommen mit der Überzeugung, dass sie einen Multi-Node-Cluster benötigen, nur um festzustellen, dass ein gut abgestimmtes Gradient-Boosted-Modell auf einer einzigen großen Maschine es mit weniger Kosten und weniger operativem Aufwand übertrifft. Wir beginnen mit der Etablierung einer starken Einzelmaschinen-Basislinie und skalieren nur dann, wenn die Daten, die Modellarchitektur oder die Latenzziele dies eindeutig erfordern.

Wenn eine Verteilung wirklich erforderlich ist – für das Fine-Tuning von Basismodellen, für verteilte Deep-Recommender oder für sehr große Feature-Räume –, verwenden wir Ray, PyTorch DDP, DeepSpeed, Spark MLlib oder Horovod nach Bedarf und achten dabei genau auf den Datenpfad. Verteiltes Training, das durch Speicher oder Shuffle ausgebremst wird, ist ein deprimierend häufiger Fehlerfall, dessen Heilung selten mehr GPUs beinhaltet.

Reproduzierbarkeit wird als Eigenschaft der Trainings-Pipeline behandelt, nicht als vage Hoffnung. Zufällige Seeds, Bibliotheksversionen, Umgebungsdefinitionen, Daten-Snapshots und Hyperparameter werden alle automatisch erfasst und an das resultierende Modellartefakt gebunden. Drei Monate später, wenn ein Regulierer oder Analyst fragt, warum sich das Modell so verhält, ist die Spur intakt.

“Mehr GPUs sind selten die Antwort; bessere Dateninfrastruktur ist es meistens.”

Die Inferenzarchitektur wird vom Konsumenten diktiert, nicht vom Modell. Eine Risiko-Score, die eine einmal täglich stattfindende Batch-Entscheidung beeinflusst, benötigt eine andere Plattform als eine Echtzeit-Empfehlung, die im 99. Perzentil unter zehn Millisekunden bereitgestellt wird. Wir entwerfen Bereitstellungspfade entsprechend den Latenz-, Durchsatz- und Aktualitätsanforderungen des Konsumenten und scheuen uns nicht, Infrastruktur bei Bedarf über Anwendungsfälle hinweg wiederzuverwenden.

Für Echtzeit-Inferenz verwenden wir typischerweise eine Kombination aus einem Feature Store mit Online-Serving, einem Modellserver (Triton, BentoML, KServe oder ein verwaltetes Äquivalent) und einem anforderungsseitigen Cache, wo angemessen. Für Batch-Inferenz stützen wir uns auf denselben Trainingscluster, mit deterministischer Fensterung und denselben Herkunftskontrollen wie in Upstream-Pipelines. Für Streaming-Inferenz integrieren wir das Modell direkt in die Stream-Verarbeitungs-Topologie und bewerten Ereignisse im Fluss.

Wir achten bei dieser Schicht genau auf die Kosten, da hier ML-Projekte am zuverlässigsten teuer werden. Quantisierung, Destillation, Batching, Anforderungsbündelung, automatische Skalierung basierend auf realen Nachfragesignalen und die Bereitschaft, kleinere Modelle zu verwenden, wenn sie ausreichen, senken die Inferenzkosten routinemäßig um eine Größenordnung ohne messbaren Genauigkeitsverlust.

Ein Modell in Produktion ist ein lebendiges Artefakt. Daten verschieben sich, Konzepte ändern sich, Upstream-Dienste ändern sich, und Downstream-Verbraucher finden neue Wege, die Ausgabe zu nutzen. Wir entwerfen ML-Systeme mit der Erwartung, dass sie über ihre Nutzungsdauer hinweg Dutzende Male neu trainiert werden, wobei jedes Retraining denselben kontrollierten, überprüfbaren Pfad wie die erste Bereitstellung durchläuft.

Drifterkennung ist standardmäßig integriert – sowohl Feature-Drift als auch Label-Drift, wo Labels verfügbar sind – und ist mit expliziten Schwellenwerten für Maßnahmen gekoppelt. Einige Modelle trainieren nach einem Zeitplan neu; andere trainieren bei Signal neu; die Wahl hängt davon ab, wie Labels ankommen und wie kostspielig ein veraltetes Modell ist. So oder so produziert das Retraining einen neuen Kandidaten, der mit dem amtierenden Modell auf demselben Bewertungsgerüst konkurriert, und der Gewinner wird unter denselben Freigabekontrollen befördert, die ursprünglich verwendet wurden.

Wo Modelle adversen Bedingungen ausgesetzt sind – Betrug, Missbrauch, Manipulation – fügen wir Red-Teaming und Shadow-Deployment als Standardpraxis hinzu. Produktionsverkehr fließt sowohl zum Live-Modell als auch zu einem Kandidaten, und das Verhalten des Kandidaten wird vor der Beförderung detailliert verglichen. Die Disziplin ist alltäglich und die dadurch gebotene Sicherheit erheblich.

Bei all unseren Projekten ist das beständigste Ergebnis nicht ein einzelnes Modell – es ist eine messbare Beschleunigung des ML-Lebenszyklus. Kunden, die Monate brauchten, um ein Modell vom Notebook in die Produktion zu bringen, schaffen dies zuverlässig in Wochen. Modelle, die zuvor ein dediziertes Team zum Betrieb erforderten, laufen nun leise zwischen Routineprüfungen. Die Kapazität, die zuvor für die Wartung des Bestehenden aufgewendet wurde, wird freigesetzt, um Neues zu entwickeln.

Das zweite beständige Ergebnis ist eine verteidigungsfähige Kostenkurve. Da Feature-Arbeit wiederverwendet wird, die Inferenz richtig dimensioniert ist und die Rechenleistung als erstklassiges Anliegen überwacht wird, sinken die Grenzkosten des nächsten ML-Anwendungsfalls. Dies ist die Eigenschaft, die eine Plattform von einem Portfolio von Pilotprojekten unterscheidet.