Deutsch

AI im Data-Scientist-Workflow: Was automatisieren, was niemals anfassen

Als Copilot mir zum ersten Mal einen Spaltennamen halluzinierte, trainierte das Modell trotzdem. Der Pull Request verknüpfte customer_id mit einer Spalte namens customer_uuid, die in der rechten Tabelle gar nicht existierte. Pandas tat, was Pandas eben tut: Es produzierte still NaN-Werte für jede Zeile, warf keinen Fehler, und der Join „lief durch." Das nachgelagerte Modell passte problemlos. Der Validierungs-AUC sah normal aus. Ich entdeckte den Fehler erst drei Tage später, weil ein Stakeholder fragte, warum eine bestimmte Kohorte aus dem Output verschwunden war.

Niemand warnt Sie vor diesem Fehlermuster. Das Marketing für AI-gestützte Datenwissenschaft ist voller Demos, in denen das Modell ein fehlerfreies pd.merge gegen einen sauberen Spielzeugdatensatz schreibt. Der tatsächliche Fehlerfall ist lautlos. Der Code läuft, die Ergebnisse wirken plausibel, und der Fehler taucht auf, nachdem Sie das Diagramm bereits präsentiert haben.

Hier ist also die Grenze, die ich nach etwa achtzehn Monaten täglicher Nutzung dieser Tools gezogen habe, geschrieben für arbeitende Data Scientists, die sowohl den Hype als auch die reflexartige Ablehnung satt haben. Beide Extreme liegen falsch. Es gibt einen Mittelweg, der schneller liefert, ohne dass Ihre Modellqualität nachlässt, und dieser Leitfaden versucht, ihn konkret zu beschreiben.

Warum das jetzt wichtig ist (und warum die meisten „AI in DS"-Inhalte verwirrend sind)

Es gibt zwei völlig verschiedene Dinge, die Menschen meinen, wenn sie „AI in der Datenwissenschaft" sagen, und wer sie vermischt, bekommt inkohärente Ratschläge.

Das erste ist AI als Workflow-Beschleuniger für den bestehenden Data-Scientist-Job: Boilerplate-Code, EDA-Skripte, Docstrings, Präsentationsentwürfe. Das ist es, was Ihr IDE-Copilot, Cursor und Claude tun. Die Aufgabe bleibt das Bauen und Erklären von Modellen. AI ist eine schnellere Schreibmaschine.

Das zweite ist der Aufbau von LLM-gestützten Anwendungen: RAG-Systeme, Agent-Pipelines, Evaluierungsrahmen für generative Ausgaben. Das ist eine andere Aufgabe. Die Fähigkeiten überschneiden sich zwar (Sie brauchen noch immer Statistik, Sie müssen noch immer über Evaluation nachdenken), aber die Fehlermuster, die Toolchain und die tägliche Arbeit unterscheiden sich stark vom Training eines XGBoost-Modells.

Wenn die Führungsebene sagt „fügen Sie AI in Ihren Workflow ein," meinen sie meist das Erste. Wenn sie sagt „bauen Sie ein AI-Feature," meinen sie meist das Zweite. Wer das nicht trennt, verschwendet ein Quartal damit, RAG-Muster auf ein Abwanderungsvorhersageproblem anzuwenden, oder, schlimmer noch, liefert einen Chatbot auf Basis von XGBoost-Intuition und wundert sich, warum die Auswertungen nicht funktionieren.

Der Rest dieses Leitfadens befasst sich hauptsächlich mit dem Ersten. Gegen Ende gibt es einen Abschnitt zum Zweiten.

Wo AI wirklich hilft (täglich nutzen)

Das sind die Stellen, an denen ich AI täglich erste Entwürfe schreiben lasse, mit kurzem Review:

Boilerplate-Code. Pandas-Umformungen, die ich hundertmal geschrieben habe: pivot, melt, groupby-Ketten. Sklearn Pipeline und ColumnTransformer-Gerüste. Matplotlib-Subplot-Raster. Das mechanische Zeug, bei dem die Struktur feststeht und nur die Spaltennamen variieren. Cursor oder Copilot treffen das zu 90 % richtig, und die 10 %, bei denen sie falsch liegen, sind schnell zu entdecken, weil Sie bereits wissen, wie das Ergebnis aussehen soll.

EDA-Skripte. Erstdurchlauf-Verteilungsplots, Null-Zählungen, Korrelations-Heatmaps, Value Counts für jedes kategoriale Merkmal. Der „gib mir die Gestalt dieses Datensatzes"-Durchlauf. AI ist hierbei gut, weil die Muster formelhaft sind und die Ausgabe visuell ist, sodass Sie sofort sehen, wenn etwas nicht stimmt. Den zweiten EDA-Durchlauf schreibe ich immer noch selbst, denn da findet das eigentliche Denken statt.

Docstrings und Type Hints. Wenn Sie bereits wissen, was die Funktion tut, und nur noch eine Dokumentation benötigen. Markieren Sie die Funktion, geben Sie das Prompt „schreibe einen Numpy-style Docstring mit Beispielen" ein, und prüfen Sie. Spart zwanzig Minuten pro Modul in einer echten Codebase.

Präsentationsentwürfe und Stakeholder-Zusammenfassungen. Nur Erstversionen. Ich schreibe einen Absatz mit Stichpunkten, was das Modell macht und wie das Ergebnis war, dann bitte ich Claude, daraus drei Folien für ein Nicht-ML-Publikum zu machen. Danach überarbeite ich etwa 60 % davon. Der erste Entwurf ist das Langweilige: Struktur, Übergänge, Wiederholungen zur Betonung. Die Überarbeitung ist der Teil, bei dem ich die Dinge ergänze, die wirklich zählen.

Literaturrecherche-Zusammenfassungen. Ich füge fünf Paper-Abstracts ein und frage: „Welche davon sind relevant für die Vorhersage von Kundenabwanderung aus Event-Stream-Daten, und was ist die Kernmethode in jedem?" Die Ausgabe ist eine Sortierliste. Dann lese ich die Paper, die ich tatsächlich lesen muss. Das ist Zusammenfassung, keine Interpretation, und es funktioniert, weil es nachprüfbar ist. Wenn die Zusammenfassung sagt, Paper 3 verwendet Transformer, kann ich das überprüfen.

Das Muster bei all diesen Fällen: AI ist gut bei den Teilen, bei denen Sie bereits wissen, wie „richtig" aussieht, sodass Sie Fehler erkennen können. Es ist ein Tipp-Beschleuniger, kein Denkersatz.

Wo AI versagt (niemals delegieren)

Das sind die Teile, die ich AI nicht anfassen lasse, mit Erklärung für jeden:

Kausale Inferenz. Konfundierungsvariablen, Selektionsbias, Identifikationsstrategie, die Frage, ob ein Regressionskoeffizient kausale Bedeutung hat. LLMs schreiben Ihnen bereitwillig ein Propensity-Score-Modell für eine Frage, die ein Difference-in-Differences-Design benötigt. Sie kennen Ihren datengenerierenden Prozess nicht. Sie wissen nicht, welche Variablen Post-Treatment sind. Sie wissen nicht, dass Ihre „Kontrollgruppe" nach dem Ergebnis ausgewählt wurde. Eine selbstsicher falsche Kausalaussage ist schlimmer als gar keine, und AI ist sehr gut darin, bei diesem Thema selbstsicher falsch zu sein.

Modellierungsentscheidungen. Welcher Algorithmus, welche Verlustfunktion, welches Validierungsschema, wie mit Datenleckage umgehen. Das sind Urteilsfragen, die vom Geschäftskontext, der Datenform und dem Zweck des Modells abhängen. Copilot schlägt für alles Random Forests vor, weil Random Forests in den Trainingsdaten am häufigsten vorkommen. Es weiß nicht, dass Ihr Problem eine temporale Datenleckage hat, die jedes Kreuzvalidierungsschema außer einer Forward-Chaining-Variante zerstört. Diese Entscheidungen müssen Sie selbst treffen.

Feature-Interpretation. Was ein SHAP-Wert in diesem Geschäftskontext bedeutet. AI kann den SHAP-Plot erstellen. Es kann abstrakt erklären, was SHAP-Werte sind. Es kann Ihnen nicht sagen, ob „Tenure hat einen hohen SHAP-Wert" bedeutet, dass Tenure kausal wichtig ist, oder ob Tenure nur als Proxy für etwas anderes dient, das Sie nicht messen. Das erfordert Geschäftskenntnis.

Geschäftliche Rahmung. „Das Modell sagt, die Abwanderungswahrscheinlichkeit für dieses Segment beträgt 0,73" in „wir sollten den Verlängerungsrhythmus für Accounts über 50.000 $ anpassen" zu übersetzen. Das ist eine entscheidungsorientierende Übersetzung, und wenn man sie falsch macht, verliert die Datenwissenschaft an Glaubwürdigkeit. Das LLM kennt weder die Risikobereitschaft Ihres Unternehmens noch, welche Stakeholder gegenüber Datenarbeit skeptisch sind und mehr Belege benötigen, noch, dass der letzte ähnliche Vorschlag gescheitert ist.

Kurzformel: AI ist in Ordnung für das Was. Nutzen Sie es nie für das Warum oder das Was bedeutet das.

Der Tech-Stack, der wirklich funktioniert

Nach dem Testen der meisten Optionen ist das der Stack, bei dem ich als arbeitender Data Scientist im Jahr 2026 lande:

Cursor für Code. Es ist VS Code mit besserer LLM-Integration. Das Composer-Feature (Sie beschreiben eine Mehrfachdateiänderung und lassen Bearbeitungsvorschläge machen) ist für das Refactoring einer Feature-Pipeline über drei Dateien hinweg wirklich nützlich. Ich lasse die Autovervollständigung für Boilerplate-Aufgaben an und schalte sie aus, wenn ich über Logik nachdenke. Der Moduswechsel ist entscheidend.

Claude (oder ähnliches) für Code-Reviews. Bevor ich einen PR öffne, füge ich den Diff in Claude ein mit einem Prompt wie: „Überprüfe das auf Korrektheit, nicht auf Stil. Fokus auf: Spaltenreferenzen, Off-by-one-Fehler, Datenleckage, veraltete APIs und Edge Cases bei Null-Handling." Es findet Dinge. Nicht immer, aber oft genug, dass ich weitermache. Es ist ein zweites Augenpaar, das um 23 Uhr vor einer Deadline verfügbar ist.

Notebook-native AI (Hex Magic, Deepnote AI) mit kurzer Leine. Diese sind hervorragend für den EDA-Durchlauf: „zeige mir die Verteilung jeder numerischen Spalte" oder „finde Korrelationen über 0,7." Ich lasse sie nicht die finale Analyse schreiben. Die kurze Leine bedeutet: alles, was sie generieren, wird in einem sauberen Notebook neu ausgeführt, bevor es meinen Laptop verlässt, und ich lese jede Zeile des generierten SQL. Der Komfort ist real, das Vertrauen ist begrenzt.

Der Grund, warum ein Paar von Tools besser ist als ein einzelnes: Jedes hat andere blinde Flecken. Cursor ist gut beim lokalen Kontext (die Datei, in der Sie arbeiten), aber schlecht dabei zu verstehen, wie Ihre Daten tatsächlich aussehen. Claude ist gut beim übergeordneten Denken („macht das Sinn?"), hat aber keinen IDE-Kontext. Notebook-Tools sind gut für schnelle Datendurchsichten, tendieren aber dazu, Wegwerfcode zu schreiben. Sie wollen verschiedene Tools für verschiedene Aufgaben, nicht ein Tool, das alle drei schlecht erledigt.

Die Falle: „Das LLM hat die Analyse geschrieben"

Das ist das Fehlermuster, das ich bei Junior- und Mid-Level-Data-Scientists am häufigsten sehe, und zunehmend auch bei Senior-Data-Scientists, die es besser wissen sollten.

Das Muster: Sie haben die Modellierung abgeschlossen, Sie haben eine Ergebnistabelle, Sie fügen sie in ChatGPT ein und fragen „fasse die wichtigsten Erkenntnisse zusammen." Es schreibt eine selbstsichere, artikulierte, gut strukturierte Erzählung. Sie bearbeiten sie leicht, fügen sie in den Bericht ein und versenden ihn.

Das Problem ist, dass das LLM Mustererkennung darauf anwendet, wie Datenwissenschafts-Schlussfolgerungen normalerweise klingen, nicht darauf, was Ihre Daten tatsächlich zeigen. Es wird Dinge sagen wie „das Modell zeigt starke Vorhersageleistung, wobei die Merkmalswichtigkeit darauf hindeutet, dass Kundenbindung der primäre Treiber ist." Dieser Satz ist strukturell korrekt und kann vollständig falsch sein. Das Modell könnte nur wegen eines undichten Features gut abschneiden. „Kundenbindung" könnte nur deshalb hohe Wichtigkeit haben, weil es ein nahezu Duplikat des Zielmerkmals ist.

Das ist das moderne Äquivalent von p-Hacking. P-Hacking drehte sich darum, durch ausreichend Suchen eine Geschichte zu finden, die zu den Daten passt. Die LLM-Analyse-Falle dreht sich darum, eine Geschichte für die Daten schreiben zu lassen, ohne zu prüfen, ob sie wahr ist. Die Geschichte ist plausibel, der Text ist sauber, und die zugrunde liegende Behauptung ist falsch.

Woran Sie erkennen, dass Sie in die Falle getappt sind: Wenn Sie nicht Satz für Satz auf die konkrete Zahl in den Ergebnissen zeigen können, die jeden Satz der Zusammenfassung belegt, sind Sie in der Falle. Der Ausweg besteht darin, die Analyse selbst zu schreiben und dann das LLM zu bitten, sie auf Klarheit hin zu bearbeiten. Einen Entwurf zu bearbeiten, den Sie selbst geschrieben haben, ist grundlegend anders als einen Entwurf aus Zahlen zu generieren, auch wenn die finale Wortzahl identisch ist.

AI für ML versus LLM-Apps bauen

Eine kurze Klarstellung, weil das Teamgespräche ständig verwirrt.

Ein Data Scientist, der Copilot nutzt, um ein Abwanderungsmodell zu bauen, betreibt klassisches ML mit einem AI-gestützten IDE. Das Modell ist XGBoost oder ein neuronales Netz. Die Evaluation ist AUC, Kalibrierung, geschäftliche Auswirkung. Der Einsatz ist ein Batch-Scoring-Job oder eine Echtzeit-API. Die Fehlermuster sind Datenleckage, Drift und Fehlkalibrierung.

Ein Data Scientist, der ein RAG-System oder einen LLM-Agenten aufbaut, tut etwas anderes. Das „Modell" ist ein Foundation-Modell, das Sie nicht trainiert haben. Die Evaluation ist qualitativ oder LLM-richter-basiert, nicht AUC. Der Einsatz ist ein Service mit Prompt-Templates, Retrieval-Indizes und Guardrails. Die Fehlermuster sind Halluzination, Prompt Injection und unkontrollierte Kosten.

Beides ist legitime Arbeit. Beides kann auf dem Tisch eines Data Scientists liegen. Aber es sind nicht dieselben Fähigkeiten, und ein erfahrener Data Scientist, der beim Ersten hervorragend ist, kann beim Zweiten mittelmäßig sein, bis er genug Praxis aufgebaut hat. Wenn die Führungsebene sagt „füge AI zum Produkt hinzu," fragen Sie, welches der beiden sie meinen. Wenn sie es nicht wissen, ist das das erste Gespräch, keine Coding-Aufgabe.

Optionales ACE Framework-Tagging

Wenn Ihr Team das ACE Framework (Ingest, Analyze, Predict, Generate, Execute) nutzt, liegt die meiste klassische DS-Arbeit in Analyze und Predict. LLM-Apps zu bauen liegt in Generate. Das ist nicht nur Vokabular. Es ist eine Möglichkeit, Gegendruck zu erzeugen, wenn der Scope sich ausdehnt. Wenn ein PM fragt „können Sie dem Abwanderungsmodell ein generatives AI-Feature hinzufügen," können Sie sagen: „Das Abwanderungsmodell ist eine Predict-Fähigkeit; was Sie beschreiben, ist eine Generate-Fähigkeit, ein anderes System mit anderer Evaluation. Lassen Sie uns diese separat einplanen." Das Framework gibt Ihnen Worte für die Grenze, die Sie bereits kennen.

Der 30-Tage-Adoptionsplan

Hier ist der Plan, den ich fahren würde, wenn ich von vorne beginnen oder einen Junior-Data-Scientist in AI-gestützte Arbeit einführen würde:

Woche 1: Nur Boilerplate und Docstrings. Installieren Sie Cursor und richten Sie ein Claude-Konto ein. Nutzen Sie sie ausschließlich für Code-Vervollständigung bei mechanischen Aufgaben (Pandas-Umformungen, Sklearn-Pipelines) und für das Schreiben von Docstrings zu Funktionen, die Sie bereits geschrieben haben. Führen Sie eine laufende Notiz (nur eine Textdatei) jedes Mal, wenn der Vorschlag falsch war. Bis zum Ende der Woche sollten Sie etwa 20 Beispiele für Fehlermuster Ihrer spezifischen Codebase haben. Das sind Kalibrierungsdaten. Sie zeigen Ihnen, wann Sie dem Tool vertrauen können und wann Sie es ignorieren sollten.

Woche 2: EDA-Unterstützung hinzufügen. Wählen Sie ein abgeschlossenes Projekt, bei dem Sie bereits wissen, was der EDA-Durchlauf hätte zeigen sollen. Führen Sie den EDA-Durchlauf mit AI-Unterstützung erneut durch und vergleichen Sie ihn mit Ihrer ursprünglichen Arbeit. Notieren Sie konkret, was AI übersehen hat (es übersieht oft den Kontextbezug, wie „diese Variable sieht normal aus, ist aber eigentlich ein Leak aus der Zukunft") und was es schneller gefunden hätte als Sie. Bis zum Ende der Woche sollten Sie eine schriftliche Regel haben, wann AI-EDA nützlich ist und wann nicht.

Woche 3: Code-Review-Schleife. Für jeden PR, den Sie öffnen, fügen Sie den Diff zuerst mit einem Code-Review-Prompt in Claude ein. Protokollieren Sie: Für wie viele PRs hat Claude nützliche Kommentare gemacht? Wie viele Fehler hat Claude gefunden, die die Reviewer Ihres Teams übersehen hätten? Wie viele False Positives? Nach einer Woche haben Sie ein Gespür dafür, ob diese Schleife es wert ist, beizubehalten. Für mich war es das, aber die Kalibrierung ist teamabhängig.

Woche 4: Schreiben Sie das „Wo wir AI nutzen / wo wir es nicht nutzen"-Dokument für Ihr Team. Eine Seite. Listen Sie die Aufgaben auf, bei denen AI das Standard-Tool ist. Listen Sie die Aufgaben auf, bei denen AI verboten ist. Listen Sie die Aufgaben auf, bei denen AI erlaubt ist, aber jede Ausgabe ein menschliches Review erhält, bevor sie gemergt wird. Holen Sie die Genehmigung Ihres Managers ein. Der Sinn des Aufschreibens ist, dass es das Gespräch erzwingt, das Meinungsverschiedenheiten aufdeckt, von denen Sie nicht wussten, dass sie bestehen.

Häufige Fallstricke

Eine kurze Liste, geordnet danach, wie oft ich gesehen habe, dass sie in der Produktion explodieren:

  1. Halluzinierten Spaltennamen vertrauen. Prüfen Sie immer, ob die in AI-generiertem Code referenzierten Spalten im DataFrame vorhanden sind. df.columns.tolist() ist Ihr Freund.
  2. Eine Modellempfehlung ohne zweite Meinung akzeptieren. Wenn Copilot sagt „verwenden Sie hier Random Forest," fragen Sie sich warum, und bitten Sie Claude separat, diese Wahl zu kritisieren. Meinungsverschiedenheit ist Information.
  3. AI die Executive Summary schreiben lassen. Bereits besprochen. Tun Sie es nicht.
  4. LLMs für Kausalbehauptungen nutzen. Sie werden Ihnen eine selbstsichere Antwort geben. Die Antwort ist unkorreliert mit der Wahrheit.
  5. Vergessen, dass Prompt-Kontextfenster Ihren DataFrame kürzen. Wenn Sie 50 Zeilen einfügen und fragen „gibt es ein Ausreißermuster," sieht das LLM nur 50 Zeilen. Es wird den langen Schwanz nicht kennen. Der Ratschlag, den es gibt, ist für die vollständigen Daten falsch.
  6. Denselben Prompt ohne Nachkalibrierung projektenübergreifend einzusetzen. Ihre Codebase hat Konventionen. Generische Code-Review-Prompts erkennen Ihre team-spezifischen Muster nicht.

Templates und Tools

Ein funktionierendes Starter-Kit:

  • Cursor-Regeldatei für DS-Arbeit. Teilt Cursor die Konventionen Ihres Teams mit: Welche Sklearn-Version Sie nutzen, ob Sie Polars statt Pandas verwenden (oder umgekehrt), dass alle Features einen Datenleckage-Kommentar benötigen.
  • Claude-Code-Review-Prompt-Template. „Überprüfe diesen Diff auf: Spaltenreferenz-Korrektheit, Datenleckage, veraltete APIs, Edge Cases bei Nulls und Konsistenz mit dem Rest der Codebase. Kommentiere nicht zu Stil."
  • AI-Nutzungsrichtlinie als Einseiter. Ein buchstäblich einseitiges Google-Doc, das Ihr Team unterzeichnet. Drei Spalten: Aufgabe, AI erlaubt?, Review erforderlich? Hängen Sie es in Ihrem Team-Channel auf.
  • EDA-Verifizierungs-Checkliste. Wenn AI eine EDA generiert, prüfen Sie: Hat es Nulls korrekt gezählt? Hat es das kategoriale Merkmal mit 10.000 eindeutigen Werten erwischt? Hat es die Datumsspalte mit Zeitzonenproblemen bemerkt? Wenn eines davon übersehen wurde, ist der Rest der Ausgabe verdächtig.

Messen, ob das funktioniert

Drei Signale, in der Reihenfolge ihrer Bedeutung:

  1. Die Zeit bis zum ersten Modell auf einem neuen Datensatz sinkt messbar. Wenn ein Junior-Data-Scientist früher drei Tage brauchte, um zu einem Basismodell zu kommen, und jetzt einen, ist das die gesuchte Verbesserung. Wenn die Zeit nicht gesunken ist, nutzen Sie AI nicht wirklich für die Teile, bei denen es hilft.
  2. PR-Review-Kommentare zu „falsche Spalte" oder „veraltete API" gehen auf null. Das sind die einfachen Fehler. Wenn sie noch auftauchen, fängt die Code-Review-Schleife aus Woche 3 sie nicht ab.
  3. Das Team hat eine schriftliche Richtlinie und bezieht sich darauf. Nicht nur ein Dokument, das existiert, sondern eines, das in PRs und Design-Reviews zitiert wird. „Wir nutzen AI dafür nicht wegen Abschnitt 3 der Richtlinie" ist der Hinweis, dass die Grenze real ist.

Das negative Signal, das mehr zählt als all diese: Niemand im Team hat eine LLM-geschriebene Analyse als eigene Arbeit eingereicht. Wenn das jemals passiert, und es wird irgendwann passieren, haben Sie kein AI-Richtlinien-Problem, sondern ein Glaubwürdigkeitsproblem, und die Lösung ist ein Gespräch, keine Tool-Änderung.

Die Grenze zwischen „AI hilft mir, schneller zu liefern" und „AI hat eine falsche Analyse unter meinem Namen veröffentlicht" ist dünner als das Marketing suggeriert. Ziehen Sie sie explizit, schreiben Sie sie auf, und überprüfen Sie sie jeden Quartal, wenn sich die Tools ändern.

Mehr erfahren