Häufige Fallstricke für Data Scientists (und wie man aufhört, sie zu wiederholen)

Ich habe beobachtet, wie sich dasselbe Muster auf drei verschiedenen Teams abgespielt hat. Ein neuer Data Scientist tritt ein, liefert in sechs Monaten ein sauberes erstes Modell und bekommt den obligatorischen Applaus im All-Hands. Dann, irgendwo um Monat neun oder zwölf, stehen die Räder still. Die Beförderung kommt nicht. Der PM wird still. Eine Neuorganisation landet sie in einem „weniger strategischen" Team, und sie verbringen das nächste Jahr damit, sich zu fragen, was passiert ist.

Fast jedes Mal ist es einer von sieben Fehlern. Manchmal zwei oder drei gleichzeitig.

Das hier ist keine „Top-Fehler zu vermeiden"-Liste. Es ist eine Liste der konkreten Dinge, die DS-Karrieren zwischen Monat 6 und 18 zum Erliegen bringen, wenn der Neulings-Goodwill erschöpft ist und Stakeholder tatsächliche geschäftliche Auswirkungen erwarten. Jeder Fallstrick kommt mit einem Symptom, das Sie an sich selbst erkennen können, einer echten Zahl, die die Kosten konkret macht, und einer Lösung, die Sie diese Woche umsetzen können.

Warum das jetzt wichtig ist

Im ersten Jahr bekommen Sie einen Freifahrtschein. Die Leute sind geduldig. Sie erwarten eine Einarbeitungszeit. Sie können ein Notebook einreichen und es als lieferbar bezeichnen.

Im zweiten und dritten Jahr ist das vorbei. Sie werden an gelieferten Geschäftsergebnissen gemessen: Modelle in der Produktion, veränderte Entscheidungen, gesparte oder verdiente Dollar. Der Data Scientist, der in 2-3 Jahren Senior wird, gegenüber dem, der auf IC2-Niveau stagniert: Der Unterschied liegt selten an IQ oder statistischem Know-how. Fast jeder auf diesem Level hat die technische Grundlage. Der Unterschied liegt darin, ob sie diese Liste vermieden haben.

Wenn Sie 6-18 Monate dabei sind und etwas sich falsch anfühlt, ohne dass Sie es benennen können, beginnen Sie hier.

Fallstrick 1: Mit dem Modell beginnen, nicht mit dem Problem

Symptom. Sie haben ein Notebook geöffnet und damit begonnen, Daten zu ziehen, bevor Sie aufgeschrieben haben, welche Entscheidung das Modell unterstützen sollte. Vielleicht haben Sie XGBoost bereits ausgewählt. Vielleicht überlegen Sie, ob Sie einen Transformer ausprobieren. Der Slack-Thread mit dem Stakeholder hat drei Nachrichten.

Die Kosten. Gartner und VentureBeat haben seit Jahren dieselbe deprimierende Zahl veröffentlicht: 60-70% der ML-Projekte erreichen nie die Produktion. Die technische Arbeit bringt sie meist nicht zum Scheitern. Die meisten sterben, weil niemand die Geschäftsentscheidung formuliert hat, die das Modell informieren sollte, sodass das Modell, wenn es „fertig" ist, keinen Platz hat, sich einzufügen. Das Dashboard, das niemand öffnet. Der Score, auf den niemand reagiert. Sechs Monate Ihres Lebens.

Die Lösung. Bevor Sie ein Notebook öffnen, schreiben Sie ein einseitiges Problem-Briefing. Keine Confluence-Abhandlung. Eine Seite.

Welche Entscheidung wird getroffen, und von wem
Was die aktuelle Baseline ist (Regelwerk, Bauchgefühl, Durchschnitt des letzten Quartals)
Wie „besser" in Dollar oder einem Geschäfts-KPI aussieht
Wer auf die Modellausgabe reagiert, und über welche Oberfläche (Dashboard, Alert, API-Aufruf, E-Mail)
Was die Kosten des Falschliegen sind, in beiden Richtungen

Wenn Sie nicht alle fünf beantworten können, haben Sie noch kein Projekt. Sie haben ein Wissenschaftsprojekt. Gehen Sie zurück zum Stakeholder und führen Sie das Gespräch.

Fallstrick 2: Im Notebook bauen und über die Mauer werfen

Symptom. Ihr Übergabedokument ist ein Jupyter-Notebook mit hartkodierten Pfaden und einer Zelle, die lautet df = pd.read_csv('/Users/IhrName/Downloads/data_v3_FINAL.csv'). Engineering schätzt 6-8 Wochen für die „Produktionierung". Die Hälfte ihres Aufwands geht in das Umschreiben Ihres Codes in etwas, das tatsächlich planmäßig ausgeführt werden kann.

Die Kosten. Anacondas State of Data Science Survey hat seit Jahren etwa 38% der DS-Zeit auf Datenvorbereitung und Deployment-Reibung angesetzt. Notebook-zu-Produktions-Umschreibungen sind der größte Anteil dieser Deployment-Reibung. Jedes Mal, wenn Engineering Ihr Notebook in Produktionscode übersetzen muss, haben Sie Wochen zum Zeitplan hinzugefügt und das Engineering-Team weniger begeistert gemacht, nächstes Quartal mit Ihnen zusammenzuarbeiten.

Die Lösung. Schreiben Sie von Woche eins eines Projekts an Code, als ob ein Teamkollege ihn morgen auf einem anderen Rechner ausführen würde. Das ist kein DevOps. Das ist grundlegende Hygiene.

Ziehen Sie Bereinigungslogik und Feature-Logik in importierbare .py-Module. Das Notebook ruft sie auf. Es definiert sie nicht neu.
Fixieren Sie Abhängigkeiten in einer requirements.txt oder pyproject.toml. Nicht „was auch immer im März auf meinem Laptop war."
Parametrisieren Sie Pfade und Datumsangaben. Kein /Users/IhrName/. Kein hartkodiertes 2024-Q3.
Verwenden Sie eine Konfigurationsdatei oder Umgebungsvariablen für alles, was sich zwischen Entwicklung und Produktion ändert.
Führen Sie Ihren eigenen Code in einer neuen Umgebung aus, bevor Sie ihn übergeben. Wenn er bei Ihnen bei einer sauberen Installation abbricht, wird er auch für Engineering abbrechen.

Sie brauchen kein Kubernetes. Sie brauchen Code, den jemand anderes ausführen kann, ohne ein Zoom-Meeting anzusetzen.

Fallstrick 3: Produktionsüberwachung überspringen

Symptom. Das Modell wurde ausgeliefert. Sie sind zum nächsten Projekt weitergegangen. Drei Monate später steigen die Support-Tickets. Customer Success ist in Aufruhr. Sie verbringen zwei Tage mit der Analyse und stellen fest, dass das Modell seit Woche vier still driftet.

Die Kosten. Branchenstudien setzen den Modelleistungsverfall bei typischen Business-Modellen ohne Neutraining konsistent auf 20-40% innerhalb von 6-12 Monaten. Nutzerverhalten verschiebt sich. Vorgelagerte Datenquellen ändern Schemata ohne Benachrichtigung. Ein neues Produktfeature ändert die Eingabeverteilung. Ohne Überwachung erfahren Sie es von den Betroffenen: Ihren Kunden und Ihrem Stakeholder.

Die Lösung. Liefern Sie in derselben Woche, in der Sie das Modell liefern, ein Überwachungs-Dashboard. Nicht „nach dem nächsten Sprint." Dieselbe Woche.

Verfolgen Sie den Population Stability Index (PSI) für Ihre Top-5-10-Features. Alert, wenn PSI > 0,2.
Verfolgen Sie die Vorhersageverteilung von Tag zu Tag. Eine plötzliche Verschiebung des Mittelwerts oder der Form ist ein Frühindikator.
Verfolgen Sie den Geschäfts-KPI, mit dem das Modell verbunden ist (Conversion-Rate, Abwanderungsrate, Betrugserkennungsrate). Wenn der KPI driftet, müssen Sie es wissen, bevor der VP es weiß.
Legen Sie eine Neutrainings-Kadenz fest. Quartalsweise ist die Untergrenze für die meisten Business-Modelle, monatlich für alles in einem sich schnell entwickelnden Bereich.
Setzen Sie Ihren Namen und Ihre Kontaktdaten auf das Dashboard. Übernehmen Sie die Verantwortung.

Ein Modell ohne Überwachung ist eine Verbindlichkeit, kein Vermögenswert. Behandeln Sie es so.

Fallstrick 4: Features über-engineern

Symptom. Ihre finale Pipeline hat 200 Features und eine 12-stufige Vorverarbeitungskette. Der AUC stieg von 0,81 auf 0,83. Sie sind stolz darauf. Ihr Stakeholder bemerkt den Unterschied nicht.

Die Kosten. Diese zusätzlichen 180 Features haben die Trainingszeit verdoppelt, die Fehlerfläche in der Produktion verdreifacht (jedes Feature ist ein potenzielles Null, Schema-Break oder vorgelagerter Vorfall) und der Lift, den Sie „gewonnen" haben, liegt im Rauschband Ihres Testsets. Sie sind jetzt verantwortlich für die Wartung einer fragilen Pipeline für einen 2%-AUC-Sprung, den niemand verlangt hat.

Die Lösung. Starten Sie schlank. Ergänzen Sie nur, wenn die Mathematik es rechtfertigt.

Beginnen Sie mit 10-20 Features. Den Merkmalen, die ein Domänenexperte in einem Meeting benennen würde.
Ergänzen Sie ein Feature nur, wenn SHAP oder Permutationswichtigkeit zeigt, dass es auf einem zurückgehaltenen Set mehr als 1% Lift bringt.
Ergänzen Sie ein Feature nur, wenn dem Stakeholder dieser 1% wichtig ist. Wenn 1% der Abwanderung 50.000 $bedeutet, gut. Wenn es 500$ sind, lassen Sie es fallen.
Jedes Feature, das Sie ergänzen, ist ein Wartungsversprechen. Wenn Sie sich nicht zu dessen Wartung verpflichten können, fügen Sie es nicht hinzu.
Im Zweifel ablieren. Lassen Sie die Features mit geringster Wichtigkeit weg und schauen Sie, ob tatsächlich etwas kaputt geht.

Die Senior-DS-Messlatte ist nicht „höchster AUC." Sie ist „höchste geschäftliche Auswirkung pro Einheit Pipeline-Komplexität."

Fallstrick 5: AUC ohne Geschäftsmetrik berichten

Symptom. Ihre Präsentationsfolie lautet „AUC 0,87, F1 0,74, Log-Loss 0,21." Ihr Stakeholder nickt höflich. Er vergisst das Projekt bis zum nächsten Quartalsreview.

Die Kosten. Null direkte Dollar, aber das Projekt hört auf, finanziert zu werden, weil niemand es dem VP erklären kann. Sie haben etwas gebaut, das funktioniert, und niemand weiß, dass es funktioniert. Sechs Monate später, wenn das Budget knapp wird, ist das Projekt, dessen Wert „wir eigentlich nicht wirklich artikulieren konnten," das erste, das gestrichen wird.

Die Lösung. Jeder Modellbericht beginnt mit der Geschäftsmetrik. Immer.

Beginnen Sie mit den Dollar oder dem KPI: „2,1 Mio. $ an gespartem Churn bei diesem Schwellenwert," „14% Präzisions-Lift gegenüber der Regelmaschine," „23% Rückgang bei Betrugsbuchungen."
Zeigen Sie die Tradeoff-Kurve in Geschäftsbegriffen. „Bei Schwellenwert 0,4 erkennen wir 80% des Betrugs und markieren 3% der legitimen Transaktionen. Bei Schwellenwert 0,6 erkennen wir 60% und markieren 0,5%. Hier sind die Kosten für jeden Fall."
Verknüpfen Sie die Metrik mit einer Zahl, die dem Stakeholder bereits wichtig ist. Wenn sie nach ARR leben, formulieren Sie es in ARR. Wenn sie nach NPS leben, formulieren Sie es in NPS.
AUC, F1 und Log-Loss kommen in den Anhang. Sie sind für Sie und Ihren DS-Reviewer, nicht für den VP.
Enden Sie mit der Entscheidung, die das Modell ermöglicht, nicht mit dem Modell selbst.

Ein Modellbericht, der nicht mit Geschäftswert beginnt, ist ein Status-Update, kein Ergebnis.

Fallstrick 6: Datenqualität an der Quelle ignorieren

Symptom. Ihr Notebook hat 400 Zeilen Bereinigungscode, weil „die Daten unordentlich sind." Sie haben das in den letzten drei Standups erklärt. Sie fangen an, sich als die Person zu betrachten, die weiß, wo die Leichen in der Kunden-Events-Tabelle begraben sind.

Die Kosten. IBMs alte Zahl bezifferte die Kosten schlechter Daten auf 3,1 Billionen Dollar pro Jahr in der US-Wirtschaft. Auf Unternehmensebene zeigen Umfragen konsistent, dass DS-Teams 40-60% ihrer Zeit mit Bereinigung verbringen. Das ist Ihre Zeit. Ihr Gehalt. Und jede Bereinigungsregel, die Sie in Ihrem Notebook schreiben, ist eine Regel, die still verfaulen wird, wenn sich das vorgelagerte Schema das nächste Mal ändert, weil niemand sonst weiß, dass sie existiert.

Die Lösung. Behandeln Sie jede Bereinigungsregel als Fehlerbericht, den Sie dem Data-Engineering-Team schulden.

Melden Sie den Fehler. Einmal. Mit einer klaren Reproduktion und den Auswirkungen („das betrifft drei Produktionsmodelle").
Hören Sie auf, es in Ihrem Notebook zu korrigieren. Korrigieren Sie es vorgelagert, in der Quell-Pipeline, wo jeder nachgelagerte Konsument profitiert.
Setzen Sie sich für Datenverträge bei den Tabellen ein, von denen Sie abhängen. Schema, Nullbarkeit, Frische-SLA, Eigentümer.
Machen Sie Datenqualität zu einer gemeinsamen Metrik. Wenn Ihr Team und Data Engineering beide „Datenfrische" oder „Schema-Break-Rate" auf einem Dashboard haben, werden Korrekturen schneller.
Wenn Engineering zurückweist („diese Quartal keine Priorität"), kommen Sie mit den Kosten in Dollar: verschwendete DS-Stunden, degradierte Modelle, blockierte Entscheidungen.

Die Notebook-Korrektur ist eine Steuer, die Sie für immer zahlen. Die vorgelagerte Korrektur ist eine einmalige Investition. Zahlen Sie sie einmal.

Fallstrick 7: „Das Modell ist in Ordnung, die Daten sind falsch" sagen ohne die Daten zu korrigieren

Symptom. Sie haben eine Version dieses Satzes in 3+ Standups verwendet: „Das Modell funktioniert. Die Trainingsdaten sind einfach schlecht." Sie haben es auch im letzten Review gesagt. Der Stakeholder wurde still.

Die Kosten. Sie persönlich. Innerhalb von etwa sechs Monaten leiten Stakeholder die Arbeit um Sie herum zu einem Data Scientist weiter, der „tatsächlich liefert." Sie werden nicht in das nächste strategische Projekt einbezogen. Sie bekommen kein Beförderungsgespräch. Das Modell, das „in Ordnung" ist, ist das Modell, dem niemand in der Produktion vertraut, was bedeutet, dass es nicht in Ordnung ist.

Die Lösung. Übernehmen Sie die Verantwortung für die gesamte Pipeline. Punkt.

Das Modell liegt in Ihrer Verantwortung, und das Modell schließt die Daten ein, die es speisen. Es gibt keine saubere Linie, wo „Ihr Job" aufhört und „Data Engs Job" anfängt, wenn die Ausgabe fehlerhaft ist.
Wenn die Daten falsch sind, eskalieren Sie. Nicht im Passiv-Slack. In einer E-Mail mit einem Namen darin und einer Deadline.
Schreiben Sie die Spezifikation, wie „richtig" aussieht. Numerische Bereiche, Frische, Schema. Lassen Sie keinen Interpretationsspielraum.
Nehmen Sie am Engineering-Review teil, wenn die Korrektur geplant wird. Stellen Sie sicher, dass sie das richtige Problem lösen.
Lassen Sie es nicht fallen, bis es in der Produktion behoben und in Ihrem Überwachungs-Dashboard verifiziert ist.

„Nicht mein Problem" ist ein Satz, der auf dieser Stufe Karrieren beendet. Das Modell ist nicht in Ordnung, wenn es in der Produktion nicht funktioniert. Es in der Produktion zum Funktionieren zu bringen ist Ihr Job.

Das Muster hinter allen sieben

Lesen Sie die sieben Fallstricke nochmals. Jeder ist derselbe Fehler.

Datenwissenschaft als Modellierungsjob zu behandeln statt als Job mit Geschäftsergebnissen.

Fallstrick 1 ist „Ich habe mich auf das Modell konzentriert, nicht auf die Entscheidung." Fallstrick 2 ist „Ich habe mich auf das Modell konzentriert, nicht auf die Übergabe." Fallstrick 3 ist „Ich habe mich auf das Modell konzentriert, nicht auf das, was nach dem Launch passiert." Vier ist „das Modell, nicht die Wartungskosten." Fünf ist „das Modell, nicht die Dollar." Sechs ist „das Modell, nicht die Daten, die es speisen." Sieben ist „das Modell, nicht das System darum herum."

Die Senior-DS-Messlatte ist „liefert messbare geschäftliche Auswirkungen." Die IC2-für-immer-Messlatte ist „produziert genaue Modelle, die niemand benutzt." Schauen Sie sich jeden Data Scientist in Ihrem Team an, der in 2-3 Jahren Senior geworden ist. Dann schauen Sie sich einen an, der vier Jahre lang IC2 war. Der Unterschied liegt fast nie in der Mathematik. Er liegt darin, ob sie das Modell als das Lieferobjekt behandelt haben oder als eine Komponente eines Systems, das tatsächlich für das Unternehmen funktionieren muss.

Selbstaudit

Wenden Sie das auf Ihre letzten 2-3 Projekte an. Seien Sie ehrlich. Der Punkt ist nicht, sich schlecht zu fühlen, sondern zu wissen, wo Sie stehen.

Fragen Sie für jedes Projekt:

Habe ich ein einseitiges Problem-Briefing geschrieben, bevor ich ein Notebook geöffnet habe?
War meine Übergabe an Engineering sauberer Code in importierbaren Modulen, kein Notebook mit hartkodierten Pfaden?
Habe ich in derselben Woche, in der ich das Modell geliefert habe, auch Überwachung geliefert?
Habe ich Features schlank gehalten und nur ergänzt, wenn SHAP es rechtfertigte UND der Stakeholder sich darum kümmerte?
Hat mein Bericht mit der Geschäftsmetrik begonnen, mit AUC im Anhang?
Habe ich vorgelagerte Datenqualitätsprobleme gemeldet oder es einfach in meinem Notebook bereinigt?
Als die Daten falsch waren, habe ich die Korrektur von Anfang bis Ende übernommen?

Zählen Sie die Neins.

0-1 Neins: Sie sind auf Kurs. Machen Sie weiter so.
2-3 Neins: Korrigieren Sie jetzt. Wählen Sie das mit der höchsten Hebelwirkung und korrigieren Sie es in Ihrem nächsten Projekt.
4+ Neins: Führen Sie diese Woche ein echtes Gespräch mit Ihrem Manager. Sie sind eine Neuorganisation von einem weniger strategischen Team entfernt und Sie spüren es wahrscheinlich schon.

Wie „gut" aussieht

Der Data Scientist, der in 2-3 Jahren Senior wird, ist nicht klüger als Sie. Er hat nur eine andere Definition des Jobs verinnerlicht.

Er beginnt jedes Projekt mit einem Problem-Briefing, nicht mit einem Notebook. Er schreibt Code von Woche eins an, als ob Engineering ihn am Montag ausführen würde. Er liefert Überwachung in derselben Woche wie das Modell und überprüft sie wöchentlich. Er hält Features schlank und abliert rücksichtslos. Er führt Berichte mit Dollar, nicht mit AUC. Er meldet Datenqualitätsprobleme vorgelagert und verfolgt sie. Wenn die Daten falsch sind, übernimmt er die Korrektur, bis sie ausgerollt ist.

Diese Person liefert weniger Notebooks und mehr ausgelieferte, überwachte, geschäftswirksame Systeme. Stakeholder ziehen sie in das nächste strategische Projekt, bevor das aktuelle endet. Das Beförderungspaket schreibt sich von selbst, weil jedes Projekt eine saubere „Ich habe X geliefert, das Y an Geschäftswert erzeugt hat, hier ist das Dashboard"-Geschichte hat.

Sie können diese Person sein. Der größte Teil des Abstands sind Gewohnheiten, keine Gehirnleistung.

Data-Scientist-Playbooks