Jedes Data-Science-Projekt beginnt mit derselben, oft unterschätzten Frage: Wo fängt man eigentlich an? Die Antwort ist fast immer: beim Datensatz.
Bevor ein Machine-Learning-Algorithmus zum Einsatz kommt, muss man die Daten verstehen — inhaltlich wie explorativ. Wie sehen sie aus? Wie ist die Verteilung? Gibt es Auffälligkeiten? Dieser Schritt ist keine Pflichtübung, sondern die Grundlage für jede spätere Entscheidung.
In diesem Artikel gehe ich den vollständigen Workflow an einem konkreten Beispiel durch: von der Explorativen Datenanalyse (EDA) über die Datenaufbereitung bis zum Prototyping mit AutoML. Mit PyCaret – einem Tool, das verschiedene Algorithmen automatisch vergleicht – lässt sich schnell herausfinden, welcher Ansatz am besten zu den Daten passt.
Wenn Sie einen praxisnahen Einstieg in ein Data-Science-Projekt suchen, sind Sie hier richtig. Und wenn Sie wissen wollen, warum 100 % Accuracy kein Grund zum Feiern ist, sondern eher ein Warnsignal – dann erst recht.
Ein Modell ist nur so gut wie das Verständnis der Daten, auf denen es aufbaut. Nicht der Algorithmus macht den Unterschied, sondern die Analyse davor und die Prüfung danach.
Dieser Artikel zeigt den kompletten Weg von den Rohdaten zum Prototyp — und die Stelle, an der ein scheinbar perfektes Modell scheitert.
Das Ziel
Das Ziel war ein vollständiger Machine-Learning-Workflow – nicht isolierter Code, sondern der gesamte Prozess vom Rohdatensatz bis zum bewerteten Prototyp.
Die Aufgabe: ein Modell, das 20 verschiedene Fruchtarten erkennt – also unterscheidet, ob ein Apfel, eine Banane oder eine Wassermelone vorliegt, basierend auf Eigenschaften wie Größe, Gewicht und Farbe.
Der Tech-Stack:
- Python als Programmiersprache
- Jupyter Notebooks zum Experimentieren
- PyCaret für schnelles Prototyping
- pandas, numpy, matplotlib, seaborn und scikit-learn für Datenverarbeitung und Modelle
Die Daten: Was steckt drin?
Bevor man etwas baut, muss man wissen, womit man arbeitet. Der Datensatz stammt von Kaggle und enthält 10.000 Einträge zu 20 verschiedenen Früchten.
Was ist über jede Frucht bekannt?
- Wie groß sie ist (in cm)
- Wie schwer sie ist (in Gramm)
- Was sie kostet
- Welche Farbe sie hat
- Welche Form (rund, oval, länglich)
- Wie sie schmeckt (süß, sauer, usw.)
Das fällt sofort auf: Die Daten sind verdächtig sauber. Keine fehlenden Werte, alles ausgefüllt. In der echten Welt ist das selten – vermutlich wurde der Datensatz synthetisch erzeugt. Für eine saubere Demonstration des Workflows ist das jedoch ideal.
Schritt 1: Die Daten kennenlernen (EDA)
EDA steht für “Explorative Datenanalyse”. Klingt aufwendig, bedeutet aber einfach: Sich die Daten genau anschauen, bevor man loslegt.
Sind alle Früchte gleich oft vertreten? Bei 9.000 Äpfeln und nur 10 Bananen entstünde ein Problem: Das Modell würde einfach immer “Apfel” raten und läge trotzdem oft richtig. Im Machine Learning bezeichnet man dieses Phänomen als Data Imbalance – eine der wichtigen ersten Analysen.
Abbildung 1: Klassenverteilung
Zum Glück: Jede Fruchtart kommt etwa 500 Mal vor. Die rote Linie zeigt die perfekte Balance.
Wie sehen die Werte aus? Hier geht es darum, wie Größe, Gewicht und Preis verteilt sind:
Abbildung 2: Numerische Verteilungen
Was sofort auffällt: Es gibt mehrere Gipfel in den Diagrammen. Das ergibt Sinn – eine Blaubeere wiegt eben nicht so viel wie eine Wassermelone. Diese Unterschiede sind wertvoll: Sie helfen dem Modell später, die Früchte zu unterscheiden.
Hängen die Eigenschaften zusammen?
Abbildung 3: Korrelationsmatrix
Die Heatmap zeigt: Größe und Gewicht hängen stark zusammen (0.92 von 1.0). Logisch – größere Früchte sind schwerer. Das ist nicht schlimm, aber gut zu wissen.
Lassen sich die Früchte überhaupt unterscheiden? Die wichtigste Frage: Bilden die Daten im Diagramm klare Gruppen?
Abbildung 4: Pairplot
Ja. Jede Farbe steht für eine Fruchtart, und sie bilden klar getrennte Wolken. Wassermelonen (die großen, schweren) sind eindeutig von Trauben (klein, leicht) unterscheidbar. Ein gutes Zeichen – besonders für baumbasierte Methoden.
Schritt 2: Welche Eigenschaften kommen ins Modell?
Nach der EDA war klar: Alle Eigenschaften können helfen, die Früchte zu unterscheiden. Eine wirft allerdings Fragen auf.
Der Preis: Ist er wirklich nützlich? Preise ändern sich je nach Land und Jahr. Ein Modell, das auf indischen Preisen trainiert wurde, würde in Deutschland nicht funktionieren.
Genau solche Überlegungen gehören an den Anfang eines Projekts – die Daten nicht nur technisch, sondern auch inhaltlich verstehen.
Hier bleibt der Preis bewusst im Datensatz. In einem produktiven Projekt würde ich ihn wahrscheinlich entfernen.
Schritt 3: Das Modell bauen
Jetzt zur eigentlichen Modellierung – aber welchen Algorithmus nimmt man? Die Antwort: Prototyping.
Die Abkürzung: AutoML. Statt jeden Algorithmus einzeln auszuprobieren, übernimmt PyCaret den Vergleich – automatisch, über verschiedene Ansätze hinweg.
from pycaret.classification import setup, compare_models
# Daten vorbereiten
clf = setup(data=df, target='fruit_name')
# Alle Modelle vergleichen
best_model = compare_models()
Der Fokus lag auf baumbasierten Algorithmen – Decision Tree, Random Forest und ähnliche. Der Grund: Die EDA hat gezeigt, dass die Früchte klar trennbare Gruppen bilden. Genau dafür sind Entscheidungsbäume ideal: Sie lernen Regeln wie “Wenn größer als 20 cm und schwerer als 2 kg → Wassermelone”.
Ein paar Zeilen Code – und PyCaret testet alles durch.
Das Ergebnis:
| Modell | Erkennungsrate |
|---|---|
| Decision Tree | 100 % |
| Random Forest | 100 % |
100 % bei allen? Das klingt zu gut, um wahr zu sein. Und genau das war es auch.
Warum 100 % ein Problem ist
Ein perfektes Ergebnis sollte misstrauisch machen. Hat das Modell wirklich verstanden, was eine Birne ist? Oder hat es sich nur gemerkt: “Wenn grün und oval, dann Birne”?
Der Test: Ich habe neue Testdaten erzeugt und einzelne Eigenschaften leicht verändert:
- Birnen, die gelb statt grün sind
- Kiwis, die grün statt braun sind
Das Ergebnis war ernüchternd:
| Testdaten | Erkennungsrate |
|---|---|
| Original (wie Trainingsdaten) | 100 % |
| Mit leichten Abweichungen | 35 % |
Von 100 % auf 35 %. Das Modell hat nicht “Frucht erkennen” gelernt, sondern nur die exakten Muster aus den Trainingsdaten auswendig gelernt. In der Fachsprache heißt das Overfitting – das Modell ist zu stark auf die Trainingsdaten spezialisiert.
Ein perfektes Ergebnis ist ein Grund zur Skepsis, nicht zur Freude. Erreicht ein Modell 100 %, hat es die Trainingsdaten meist auswendig gelernt — verstanden hat es nichts.
Abbildung 5: Feature Importance
Das Diagramm zeigt, worauf das Modell am meisten achtet. Form und Größe sind wichtig – aber auch Farbe. Und genau da liegt das Problem: Eine gelbe Birne? Kennt das Modell nicht.
Die Lösung: Was passiert, wenn man die problematischen Eigenschaften (Farbe, Form, Geschmack) weglässt und nur Größe, Gewicht und Preis verwendet?
| Ansatz | Erkennungsrate |
|---|---|
| Alle Eigenschaften | 35 % |
| Nur Zahlen | 93 % |
Ohne die “unzuverlässigen” Eigenschaften funktioniert es deutlich besser. Hier ließe sich weitermachen: verschiedene Kombinationen testen, Farbe vielleicht drin lassen und nur Form weglassen. Im Fokus stand jedoch der grundlegende Workflow, nicht das perfekt optimierte Modell.
Die wichtigsten Erkenntnisse
Datenqualität schlägt Algorithmus. Ob Decision Tree oder Random Forest – beide hatten dasselbe Problem. Die Lösung lag nicht im Modell, sondern in den Daten. Auch stundenlanges Feintuning an den Modell-Einstellungen hätte hier nichts gebracht.
100 % sollte skeptisch machen. Perfekte Ergebnisse bedeuten oft: Das Modell hat auswendig gelernt statt verstanden. Immer mit realistischen Testdaten prüfen.
Die richtigen Eigenschaften entscheiden. Welche Eigenschaften ins Modell einfließen, macht einen enormen Unterschied – hier: 35 % gegenüber 93 %.
Zeit in die Datenanalyse zahlt sich aus. Ohne EDA wären die Probleme erst viel später aufgefallen. Zeit fürs “Daten anschauen” ist nie verschwendet.
AutoML beschleunigt das Prototyping. PyCaret zeigt in Minuten, was funktioniert – ein effizienter Startpunkt, von dem aus man gezielt tiefer einsteigen kann.
Fazit
Dieses Projekt durchläuft einen vollständigen ML-Workflow vom Rohdatensatz bis zum bewerteten Prototyp – und zeigt dabei eine der häufigsten Fallen der Praxis: Ein Modell mit 100 % Genauigkeit hatte nichts verstanden, sondern auswendig gelernt. Erst die richtige Auswahl der Eigenschaften und die Prüfung mit realistischen Testdaten machten den Unterschied.
Mögliche nächste Schritte:
- Mehr Variationen in die Trainingsdaten bringen
- Weitere Algorithmen und Feature-Kombinationen testen
Die zentrale Erkenntnis: Bei Klassifikationsproblemen entscheidet selten der Algorithmus, sondern das Verständnis der Daten – die Analyse zu Beginn und die Prüfung mit realistischen Testdaten am Ende.
Code & Ressourcen
Wenn Sie selbst reinschauen möchten – der komplette Code ist auf GitLab:
🔗 https://git.tellaev.de/stellaev/fruit-classification
Dort finden Sie:
- Notebooks – alle Jupyter Notebooks
- Umgebung – Umgebungsdateien zum Nachbauen
- Visualisierungen – sämtliche Visualisierungen
Kontakt
Fragen? Feedback? Eigene Erfahrungen teilen? Schreiben Sie mir gerne: