Das Problem: ML ist kein einmaliges Projekt

Die meisten ML-Projekte scheitern nicht an der Modellierung, sondern an der Erwartung, dass ein einmal trainiertes Modell “fertig” ist.

Typischer Ablauf (der scheitert):

  1. Daten sammeln ✓
  2. Modell trainieren ✓
  3. Deployen ✓
  4. …und dann?

Was passiert in der Realität:

  • Daten ändern sich (Data Drift)
  • Neue Edge Cases tauchen auf
  • Performance degradiert über Zeit
  • Niemand weiß, wie man das Modell verbessert

Das Factory Model: ML als Produktionssystem

Das Factory Model beschreibt ML-Entwicklung als kontinuierlichen, zyklischen Prozess – wie eine Fabrik, die immer bessere Produkte herstellt.

┌─────────────────────────────────────────────────────────────────┐
│                    THE ML FACTORY                                │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│    ┌──────────────┐                                             │
│    │ 1. COLLECT   │ ◄────────────────────────────────┐         │
│    │    Data      │                                   │         │
│    └──────┬───────┘                                   │         │
│           │                                           │         │
│           ▼                                           │         │
│    ┌──────────────┐                                   │         │
│    │ 2. LABEL     │                                   │         │
│    │    Data      │                                   │         │
│    └──────┬───────┘                                   │         │
│           │                                           │         │
│           ▼                                           │         │
│    ┌──────────────┐                                   │         │
│    │ 3. TRAIN     │                                   │         │
│    │    Model     │                                   │         │
│    └──────┬───────┘                                   │         │
│           │                                           │         │
│           ▼                                           │         │
│    ┌──────────────┐                                   │         │
│    │ 4. EVALUATE  │                                   │         │
│    │    Model     │                                   │         │
│    └──────┬───────┘                                   │         │
│           │                                           │         │
│           ▼                                           │         │
│    ┌──────────────┐                                   │         │
│    │ 5. ANALYZE   │───────────────────────────────────┘         │
│    │  Shortcomings│                                             │
│    └──────────────┘                                             │
│                                                                  │
│    ═══════════════════════════════════════════════════════      │
│    Jede Iteration → Besseres Modell                             │
│    ═══════════════════════════════════════════════════════      │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Der Zyklus im Detail

1. Collect Data

  • Sammle Daten aus der realen Anwendung
  • Fokus auf Bereiche, wo das Modell schwach ist
  • Systematisches Logging von Edge Cases

2. Label Data

  • Annotiere gesammelte Daten
  • Priorisiere nach Schwächen des aktuellen Modells
  • Qualitätskontrolle der Labels

3. Train Model

  • Trainiere auf erweitertem Datensatz
  • Experimentiere mit Architekturen
  • Vergleiche mit vorheriger Version

4. Evaluate Model

  • Teste auf Hold-out Set
  • Analysiere Per-Class Performance
  • Identifiziere systematische Fehler

5. Analyze Shortcomings

  • Wo versagt das Modell?
  • Welche Daten fehlen?
  • Zurück zu Schritt 1

Warum das Factory Model funktioniert

Der Virtuous Loop

Version 1: 70% Accuracy
    │
    ├── Fehleranalyse: "Modell verwechselt Katzen mit Hunden"
    ├── Aktion: Mehr Katze/Hund-Bilder sammeln
    │
    ▼
Version 2: 82% Accuracy
    │
    ├── Fehleranalyse: "Modell versagt bei schlechter Beleuchtung"
    ├── Aktion: Bilder mit verschiedenen Lichtverhältnissen sammeln
    │
    ▼
Version 3: 89% Accuracy
    │
    ├── Fehleranalyse: "Seltene Rassen werden nicht erkannt"
    ├── Aktion: Long-tail Klassen gezielt erweitern
    │
    ▼
Version 4: 94% Accuracy
    ...

Jede Iteration ist gezielt: Man verbessert nicht blind, sondern adressiert spezifische Schwächen.


Die Infrastruktur der ML-Factory

Das Factory Model erfordert Investition in Infrastruktur – aber diese zahlt sich exponentiell aus.

Notwendige Komponenten

┌─────────────────────────────────────────────────────────────────┐
│  ML FACTORY INFRASTRUCTURE                                       │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐ │
│  │ Data Pipeline   │  │ Label Platform  │  │ Model Registry  │ │
│  │                 │  │                 │  │                 │ │
│  │ - Ingestion     │  │ - Annotation UI │  │ - Versioning    │ │
│  │ - Validation    │  │ - QA Workflow   │  │ - Experiments   │ │
│  │ - Storage       │  │ - Active Learn. │  │ - Comparison    │ │
│  └─────────────────┘  └─────────────────┘  └─────────────────┘ │
│                                                                  │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐ │
│  │ Training Infra  │  │ Eval Pipeline   │  │ Monitoring      │ │
│  │                 │  │                 │  │                 │ │
│  │ - GPU Cluster   │  │ - Test Sets     │  │ - Production    │ │
│  │ - Hyperparams   │  │ - Metrics       │  │ - Data Drift    │ │
│  │ - Automation    │  │ - Error Analysi │  │ - Alerting      │ │
│  └─────────────────┘  └─────────────────┘  └─────────────────┘ │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

ROI der Infrastruktur

Investition Einmalig Laufender Nutzen
Data Pipeline 2-4 Wochen Automatische Datenerfassung
Label Platform 1-2 Wochen 10x schnelleres Labeling
Model Registry 1 Woche Reproduzierbare Experimente
Eval Pipeline 2 Wochen Automatische Fehleranalyse
Monitoring 1 Woche Früherkennung von Problemen

Ohne Infrastruktur: Jede Iteration ist manueller Aufwand. Mit Infrastruktur: Der Zyklus läuft semi-automatisch.


Praktisches Beispiel: Autonomes Fahren

Die Factory in Aktion

┌─────────────────────────────────────────────────────────────────┐
│  ADAS FACTORY CYCLE                                              │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ITERATION 1                                                     │
│  ├── Collect: 100.000 km Testfahrten                            │
│  ├── Label: Verkehrsschilder annotieren                         │
│  ├── Train: CNN auf 50.000 Bilder                               │
│  ├── Evaluate: 92% Accuracy                                     │
│  └── Shortcoming: Versagt bei Nacht                             │
│                                                                  │
│  ITERATION 2                                                     │
│  ├── Collect: 50.000 km Nachtfahrten (gezielt!)                 │
│  ├── Label: Nacht-Szenarien priorisieren                        │
│  ├── Train: Erweiterter Datensatz                               │
│  ├── Evaluate: 95% Accuracy, Nacht 88% → 94%                    │
│  └── Shortcoming: Versagt bei Regen + Nacht                     │
│                                                                  │
│  ITERATION 3                                                     │
│  ├── Collect: Regen-Nacht-Szenarien aus Simulation (CARLA)      │
│  ├── Label: Automatisch aus Simulation                          │
│  ├── Train: Real + Synthetic Data                               │
│  ├── Evaluate: 97% Accuracy, Edge Cases abgedeckt               │
│  └── Shortcoming: Neue Schildertypen in anderem Land            │
│                                                                  │
│  ... und so weiter                                               │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Schlüssel-Einsichten

  1. Gezielte Datensammlung: Nicht mehr Daten, sondern die richtigen Daten
  2. Simulation als Multiplikator: Synthetic Data für seltene Edge Cases
  3. Kontinuierliche Verbesserung: Modell wird mit jeder Iteration robuster

Anti-Patterns: Was die Factory sabotiert

1. “Fire and Forget”

❌ Modell einmal trainieren und deployen
✅ Kontinuierliches Monitoring und Iteration

2. “Mehr Daten = Besser”

❌ Blind mehr Daten sammeln
✅ Gezielt Daten für identifizierte Schwächen

3. “Accuracy ist alles”

❌ Nur auf Gesamtgenauigkeit schauen
✅ Per-Class Analyse, Edge Cases, Failure Modes

4. “Labeling ist ein einmaliger Aufwand”

❌ Einmal labeln, dann fertig
✅ Kontinuierliches Labeling als Teil des Prozesses

5. “Infrastruktur kommt später”

❌ Erst Modell, dann Pipeline
✅ Pipeline früh aufbauen, dann skalieren

Wie man startet: Minimal Viable Factory

Du brauchst nicht alles auf einmal. Starte mit dem Minimum:

Phase 1: Der manuelle Loop (Woche 1-2)

1. Sammle erste Daten (manuell)
2. Labele in Spreadsheet/Tool
3. Trainiere erstes Modell
4. Evaluiere auf Test Set
5. Dokumentiere Fehler in Notion/Confluence
6. → Zurück zu 1

Ziel: Den Zyklus einmal durchlaufen, Schwächen verstehen.

Phase 2: Semi-Automatisierung (Monat 1-2)

1. Data Pipeline aufsetzen (S3 + DVC)
2. Label-Tool einführen (Label Studio)
3. Training automatisieren (MLflow)
4. Eval-Dashboard bauen (Streamlit)
5. Error Analysis standardisieren

Ziel: Iteration beschleunigen, von Wochen auf Tage.

Phase 3: Vollständige Factory (Monat 3+)

1. Production Monitoring
2. Automatic Data Collection
3. Active Learning für Labeling
4. CI/CD für Modelle
5. A/B Testing in Production

Ziel: Kontinuierliche Verbesserung mit minimalem manuellem Aufwand.


Tools für die ML-Factory

Komponente Open Source Cloud
Data Pipeline DVC, Airflow AWS S3 + Glue
Labeling Label Studio Scale AI, Labelbox
Experiment Tracking MLflow, W&B SageMaker, Vertex
Model Registry MLflow SageMaker Registry
Monitoring Evidently, Grafana Arize, Fiddler
Orchestration n8n, Prefect Step Functions

Key Takeaways

Das Factory Model in einem Satz

“ML ist keine einmalige Entwicklung, sondern ein kontinuierlicher Produktionsprozess, bei dem jede Iteration das Modell gezielt verbessert.”

Die 5 Prinzipien

  1. Zyklisch denken: Plane von Anfang an für Iteration
  2. Fehler sind Daten: Jeder Fehler zeigt, welche Daten fehlen
  3. Infrastruktur früh: Pipeline-Investment zahlt sich aus
  4. Gezielt sammeln: Die richtigen Daten > mehr Daten
  5. Automatisieren: Je schneller der Zyklus, desto besser das Modell

Wann das Factory Model anwenden?

Szenario Factory Model?
Einmaliges Forschungsprojekt Nein
Kaggle Competition Nein
Produkt mit ML-Komponente Ja
Autonomes Fahren / ADAS Ja
Recommendation System Ja
Content Moderation Ja

Fazit

Das Factory Model ist kein fancy Framework – es ist die Realität, wie erfolgreiche ML-Systeme in der Industrie gebaut werden.

Der Unterschied zwischen Hobbyist und Profi:

  • Hobbyist: “Mein Modell hat 95% Accuracy, fertig!”
  • Profi: “Mein Modell hat 95% Accuracy. Wo versagt es? Welche Daten brauche ich?”

Die initiale Investition in Infrastruktur und Prozesse ist nicht trivial. Aber sobald die Factory läuft, wird sie zum Flywheel: Jede Iteration macht das System besser, schneller und robuster.


Inspiriert von: Andrej Karpathy’s Konzept der “Factory Model of Machine Learning”


Du willst robuste ML-Pipelines und skalierbare KI-Systeme in deinem Unternehmen aufbauen? Dann schreib mir einfach auf LinkedIn oder buche direkt einen kostenlosen Call.