Der Gegenschlag der Data Scientists

• Mit dem Aufkommen von LLM-APIs wurden Data Scientists und MLEs zwar aus dem zentralen Pfad zur Einführung von AI ausgeschlossen, doch das Wesen der eigentlichen Arbeit — Versuchsdesign, Metrikmessung und Debugging probabilistischer Systeme — ist nicht verschwunden.
• Sowohl der Codex-Fall von OpenAI als auch Karpathys auto-research-Projekt zeigen, dass ein Harness aus Tests, Metriken und Observability-Stack der Kern ist — und ein großer Teil dieses Harness ist Data Science.
• In der Praxis beeinträchtigen immer wieder fünf Eval-Fallstricke — generische Metriken, nicht validierte Judge-Modelle, schlechtes Versuchsdesign, mangelhafte Daten und Labels sowie zu viel Automatisierung — die Qualität von AI-Systemen.
• Die gemeinsame Ursache aller Fallstricke ist das Fehlen solider Data-Science-Grundlagen; Explorative Datenanalyse, Modellevaluierung, Versuchsdesign, Datenerhebung und Production ML bleiben unverändert die Lösung.
• „Die Daten direkt anzuschauen“ ist die Aktivität mit dem höchsten ROI und wird dennoch am häufigsten ausgelassen; die Rolle von Data Scientists bleibt auch im LLM-Zeitalter zentral.

---

Die Wiederauferstehung des Data Scientists

• Data Scientists galten einst als „der sexieste Job des 21. Jahrhunderts“ und wurden entsprechend hoch bezahlt.
  • Erforderlich waren kombinierte Fähigkeiten wie Predictive Modeling, Messung von Kausalzusammenhängen und das Erkennen von Datenmustern.
  • Später wurde die Arbeit am Predictive Modeling als Machine Learning Engineer (MLE) ausgegliedert.
• Mit dem Aufkommen von LLMs (Large Language Models) hat sich verändert, wie Unternehmen AI bereitstellen: Data Scientists oder MLEs gehören nicht mehr zwingend zum kritischen Pfad.
  • Über Foundation-Model-APIs können Teams AI eigenständig integrieren.
• Doch Modelltraining ist nicht alles, was Data Scientists tun; Versuchsdesign, Debugging und Metrikdesign bleiben zentrale Aufgaben.
  • Diese Arbeit verschwindet nicht dadurch, dass man nur eine LLM-API aufruft.
• Der PyAI-Conf-Vortrag „The Revenge of the Data Scientist“ behandelt das anhand konkreter Beispiele und betont, dass die Rolle der Data Science weiterhin wichtig ist.

Das Wesen des Harness ist Data Science

• OpenAIs Konzept des Harness Engineering beschreibt eine Struktur, in der Agenten in einer von Tests und Spezifikationen umgebenen Umgebung autonom Code entwickeln.
  • Zum Harness gehört ein Observability-Stack mit Logs, Metriken und Traces, sodass der Agent Fehlverhalten selbst erkennen kann.
• Auch Andrej Karpathys auto-research-Projekt zeigt dasselbe Muster: iterative Optimierung anhand der Metrik „validation loss“.
• Dass man „ein LLM per API aufruft“, beseitigt die Arbeit an Versuchsdesign, Debugging und Metrikdesign nicht; ein großer Teil des Harness ist Data Science.
  • Früher floss viel Zeit in Datenprüfung, das Überprüfen der Label-Konsistenz und Metrikdesign.
  • Heute besteht die Tendenz, sich auf das „Bauchgefühl“ des Modells zu verlassen oder Open-Source-Metrikbibliotheken unverändert zu übernehmen.
• Besonders im Bereich RAG (Retrieval-Augmented Generation) und Evals gibt es viele Missverständnisse, weil das Verständnis für Daten fehlt.
• Aussagen wie „RAG is dead, evals are dead“ tauchen auf, obwohl genau die Teams, die das behaupten, Systeme bauen, die auf diesen Konzepten beruhen.
• Gerade im Retrieval- und Eval-Bereich zeigt sich, dass Engineers ohne Datenhintergrund Dinge meiden, die sie nicht verstehen.
• Dass man „ein LLM per API aufruft“, beseitigt die Arbeit an Versuchsdesign, Debugging und Metrikdesign nicht; ein großer Teil des Harness ist Data Science.

Fünf Eval-Fallstricke

• Fallstrick 1: Generische Metriken (Generic Metrics)

  • Generische Metriken wie Helpfulness Score, Coherence Score oder Hallucination Score sind zu breit, um echte Ausfälle in einer Anwendung zu diagnostizieren.
  • Ein Data Scientist würde solche Metriken nicht einfach übernehmen, sondern zuerst Daten und Traces direkt untersuchen, um zu verstehen, was tatsächlich kaputtgeht.
  • „Die Daten anzuschauen“ bedeutet, Traces direkt zu lesen, einen eigenen Trace-Viewer zu bauen und per Error Analysis Fehler zu klassifizieren.
  • Generische Ähnlichkeitsmetriken wie ROUGE oder BLEU passen kaum zu LLM-Outputs; gebraucht werden anwendungsspezifische Metriken wie „Calendar Scheduling Failure“ oder „Failure to Escalate To Human“.
  • Die Daten anzuschauen ist die Aktivität mit dem höchsten ROI und wird am häufigsten ausgelassen.

• Fallstrick 2: Nicht validierte Judge-Modelle (Unverified Judges)

  • Die meisten Teams, die ein LLM als Judge verwenden, haben keine Antwort auf die Frage „Wie vertrauen wir dem Judge?“.
  • Data Scientists behandeln den Judge wie einen Klassifikator: Sie beschaffen menschliche Labels, teilen in Train/Dev/Test und messen die Verlässlichkeit.
    • Few-shot-Beispiele stammen aus dem Trainingssatz, der Dev-Set dient zur Verbesserung des Judge-Prompts, und der Test-Set bleibt zur Kontrolle auf Overfitting reserviert.
  • Beim Reporting sollten statt bloßer Accuracy besser Precision und Recall verwendet werden — selbst wenn ein Fehlermodus nur 5 % ausmacht, kann Accuracy die tatsächliche Leistung verschleiern.
  • Die Validierung von Klassifikatoren ist in moderner AI zu einer verlorenen Kunst geworden.

• Fallstrick 3: Schlechtes Versuchsdesign (Bad Experimental Design)

  • Zusammenstellung des Test-Sets: Die meisten Teams bitten ein LLM einfach darum, „50 Test-Queries zu generieren“, doch so entstehen nicht repräsentative, generische Daten.
    • Ein Data Scientist würde zuerst echte Produktionsdaten betrachten, wichtige Dimensionen identifizieren und dann synthetische Beispiele passend zu diesen Dimensionen erzeugen.
    • Synthetische Daten sollten auf realen Logs oder Traces basieren, und Edge Cases müssen gezielt eingespeist werden.
  • Metrikdesign: Die gesamte Rubrik in einen einzigen LLM-Call zu packen und standardmäßig eine Likert-Skala von 1 bis 5 zu verwenden, verdeckt Mehrdeutigkeiten und verschiebt schwierige Entscheidungen über die Systemleistung.
    • Das sollte durch binäre Pass/Fail-Entscheidungen zu eng abgegrenzten Kriterien ersetzt werden.

• Fallstrick 4: Schlechte Daten und Labels (Bad Data and Labels)

  • Weil Labeling als wenig glamourös gilt, wird es oft an das Entwicklerteam delegiert oder ausgelagert; Data Scientists fordern jedoch, dass Domänenexpert:innen direkt labeln.
  • Neben der Label-Qualität gibt es einen tieferen Grund: das in Arbeiten von Shreya Shankar u. a. belegte Konzept des „criteria drift“ — Nutzende brauchen Kriterien, um Outputs zu bewerten, definieren diese Kriterien aber oft erst während der Bewertung. Mit anderen Worten: Bevor sie den LLM-Output sehen, wissen sie nicht genau, was sie wollen.
  • Domänenexpert:innen und PMs sollten nicht vor Summenscores, sondern vor die Rohdaten gesetzt werden.

• Fallstrick 5: Zu viel Automatisierung (Automating Too Much)

  • LLMs können beim Schreiben von Plumbing-Code, beim Erzeugen von Boilerplate und beim Verdrahten von Evaluierungen helfen.
  • Doch die Arbeit, Daten direkt anzuschauen, lässt sich nicht automatisieren — weil man „vor dem Ansehen des Outputs nicht weiß, was man will“.
  • Weitere erwähnte Fallstricke sind: missbräuchliche Nutzung von Ähnlichkeitsscores, dem Judge vage Fragen wie „Ist das hilfreich?“ zu stellen, Annotator:innen Roh-JSON lesen zu lassen, unkorrigierte Scores ohne Konfidenzintervalle zu berichten, Daten-Drift, Overfitting, fehlerhaftes Sampling und schwer verständliche Dashboards.

Abbildung auf Data-Science-Grundlagen

• Alle fünf Fallstricke haben dieselbe Grundursache: fehlende Data-Science-Basics.
• Zuordnung der einzelnen Fallstricke zu bestehenden Methoden:
  • Traces lesen und Fehler klassifizieren → Explorative Datenanalyse (EDA)
  • LLM-Judges mit menschlichen Labels validieren → Model Evaluation
  • Repräsentative Test-Sets auf Basis von Produktionsdaten erstellen → Experimental Design
  • Labeling durch Domänenexpert:innen → Data Collection
  • Das Verhalten des Produkts in Produktion überwachen → Production ML
• Die Bezeichnungen haben sich geändert, die eigentliche Arbeit ist dieselbe geblieben.
• Python ist weiterhin das beste Toolset, um Daten zu erkunden und zu bearbeiten.
• Über ein Open-Source-Plugin (evals-skills) wurde ein Werkzeug veröffentlicht, mit dem sich Eval-Pipelines analysieren und fehlerhafte Stellen diagnostizieren lassen.

[GN⁺]

Hacker-News-Kommentare

• Das sind gute Best Practices beim Aufbau von GenAI-Lösungen, aber ich glaube nicht, dass dieser Wandel die Nachhaltigkeit des Berufsbilds Data Scientist garantiert
  Früher standen Data Scientists im Fokus, weil sie selbst Modelle bauten und damit geschäftlichen Mehrwert schufen
  Heute wird diese Rolle jedoch von LLM-Anbietern und Ingenieuren übernommen, die APIs aufrufen. Das Verhalten von LLMs zu steuern ist eine Art Black Magic, aber mathematisches Wissen ist dafür nicht zwingend nötig
  Was übrig bleibt, sind Evaluation und Monitoring, und das wirkt aus Business-Sicht nicht wie ein „Kernwert“. In Organisationen, die schnell Prototypen ausrollen wollen, wird es eher als Hindernis gesehen
  Am Ende muss man also argumentieren: „Data Scientists sollten die Gatekeeper beim Aufbau von LLMs sein“ — wie überzeugend diese Logik ist, bleibt fraglich

  • Ich hatte ein ähnliches Gefühl. Für die Nutzung bestehender LLMs braucht man nicht zwingend Data Scientists. Selbst ich als AI-affiner Engineer konnte mich da schnell einarbeiten
    Trotzdem glaube ich, dass es neben LLMs noch viele Bereiche gibt, in denen weiterhin maßgeschneiderte ML-Modelle nötig sind. Zum Beispiel lassen sich das Suchranking von AirBnB oder der Matching-Algorithmus von Uber nicht durch LLMs ersetzen
    Der Markt ist also zwar kleiner geworden, aber nicht vollständig verschwunden
  • Es ist schwer, die Führungsebene zu überzeugen, und tatsächlich wollen viele DS solche Evaluationsarbeit auch gar nicht machen
    Aber genau dieser Prozess zwingt dazu, klar zu definieren, „was eigentlich gelöst werden soll“. Manchmal lautet die Antwort auch: „Dieses Produkt ist den Bau nicht wert“
    Nur wollen das kaum Leute hören
  • Ich verstehe nicht, warum Evaluationsarbeit zwingend in den Zuständigkeitsbereich von Data Scientists fallen sollte
    AI-Ingenieure mit SWE-Hintergrund passen dafür oft besser. Die Denkweise „Evaluation = automatisierte Tests“ liegt ihnen ganz natürlich
    Tatsächlich verschwindet in vielen Agent-Projekten die Rolle von DS fast vollständig
  • Die statistische Strenge, die Data Scientists eingebracht haben, scheint in LLM-basierten Lösungen fast völlig verschwunden zu sein

• Diesen Rat gebe ich Data Scientists oft

  1. Kontextdaten als Trainingsdaten betrachten — ein LLM lernt aus dem gegebenen Kontext
  2. Evaluationsdaten als Testdaten betrachten — sie müssen aus den Ausführungslogs des Agenten gesammelt und manuell gelabelt werden
     Wenn man ein LLM als Bewerter einsetzen will, muss auch dieses Modell letztlich per In-Context-Learning aus guten Beispieldaten lernen
     Mehr dazu habe ich in meinem Buch zusammengefasst
  • Stimme ich komplett zu. „Evaluations = Tests“
    Wenn jedoch ein Modell die Ausgabe eines anderen Modells bewerten soll, wird das zu einer metaartigen Struktur — irgendwo muss man am Ende doch die „echte richtige Antwort“ festnageln

• Ich habe einen Hintergrund in Data Science/Engineering
  AI zu nutzen ist wie den Lösungsraum zu durchsuchen. Es ist ein Prozess, in dem man unter Milliarden von Parameterkombinationen ein Optimum sucht
  Mit Prompts grenzt man den Suchraum ein und versucht mit semantischen Heuristiken bessere Lösungen zu finden
  Oft bleibt man in lokalen Optima stecken oder läuft komplett in die falsche Richtung. Deshalb beginne ich jede Woche die Codebase neu, vereinfache Dinge oder füge Funktionen hinzu. Nur so findet man bessere Lösungen

• Fälle wie das kürzlich erwähnte pg_textsearch sind meiner Meinung nach gute Beispiele dafür, wo diese Art der Entwicklung gut passt
  Wenn es klare Testfälle und Benchmarks gibt, sind die Erfolgschancen hoch
  Bei Greenfield-Entwicklung ist es jedoch oft genauso schwer oder sogar schwerer, Testfälle zu definieren, als den Code zu schreiben
  Außerdem neigen LLMs oft dazu, in lokalen Minima stecken zu bleiben. Wenn sich die Codestruktur einmal verfestigt hat, versuchen sie kaum noch größere Refactorings. Das ist eine Art Effekt, der Overfitting ähnelt

• Es hieß, der Kern von AI-Experimenten sei zu prüfen, wie gut ein Modell auf neue Daten generalisiert, aber in der Praxis fehlt oft der Schritt, überhaupt sauber zu klären, „was die Daten eigentlich sind“
  Denn häufig unterscheiden sich die Daten, die Menschen im Kopf haben, von den tatsächlich vorliegenden Daten

• Ich gewinne deutlich mehr Einsichten daraus, das Verhalten eines Agenten direkt zu beobachten, als komplexe LLM-als-Bewerter-Workflows zu bauen

• Gestern habe ich Karpathys autoresearch-Ansatz auf ein ML-Problem angewendet
  Nach mehreren Experimenten war ich überrascht von den Ergebnissen des Modells. Wenn Kaggle noch so aktiv wäre wie früher, hätte AI die meisten Probleme wohl geschlagen
  Aber in der realen Data-Science-Arbeit gibt es meist viele Leute, die nicht einmal die grundlegenden Werkzeuge richtig kennen. Nur weil man ihnen AI gibt, werden sie nicht plötzlich besser
  Am Ende lassen Experten weiterhin Juniors die Arbeit machen, und Nicht-Experten irren in schlampigen Ergebnissen herum

  • Bei Kaggle-Problemen könnte AI vermutlich ziemlich gut sein
    Aber reale DS-Arbeit besteht meist darin, mit unvollständigen Daten und unklaren Zielen umzugehen
    Ein guter DS muss sagen können: „Das geht nicht.“ Ein LLM hingegen sagt immer nur: „Klar, tolle Idee!“

• Letztlich läuft auch AI-Entwicklung auf eine ähnliche Schleife hinaus — „definieren, was ein gutes Ergebnis ist, die Abweichung dazu messen und iterativ verbessern“
  Wer in solchen Denkmustern lange gearbeitet hat, ist Prompt Engineers weit voraus

[raykim]

Ich weiß nicht, ob sich hier Data Scientists zu Wort gemeldet haben. Es wirkt, als kämen alle Perspektiven von Entwicklern...