Accuracy von 99 Prozent klingt erstrebenswert. Bei seltenen Ereignissen ist sie oft die trügste Kennzahl überhaupt.

Accuracy und Recall versprechen beide eine einzige Zahl für Modellqualität – deshalb werden sie verwechselt. Accuracy zählt nur, wie oft das Modell richtig liegt – nicht, was es verpasst.

Accuracy ist der Anteil korrekt klassifizierter Beispiele, egal welcher Art die Fehler sind. Bei 99 Prozent normalen Transaktionen und einem Prozent Betrug sagt ein Modell einfach immer „kein Betrug“ – und erreicht 99 Prozent Accuracy, ohne einen einzigen Betrugsfall zu erkennen. Genau daran zeigt sich, dass die Kennzahl über die Qualität täuscht.

Precision und Recall blicken stattdessen auf die seltene Klasse. Precision ist der Anteil der als positiv vorhergesagten Beispiele, die tatsächlich positiv sind – also: Wie viele Alarme waren berechtigt? Recall ist der Anteil der tatsächlich positiven Fälle, die gefunden wurden – also: Wie viele echte Betrügereien wurden entdeckt? Beide stammen aus der Konfusionsmatrix, die richtig positive, falsch positive, richtig negative und falsch negative Vorhersagen zählt.

Accuracy misst Gesamttreffer, Precision und Recall messen die seltene Klasse gezielt. Der F1-Wert, das harmonische Mittel beider, bestraft ein starkes Ungleichgewicht, weil er nahe am kleineren Wert liegt.

Faustregel: Zuerst prüfen, wie die Klassen verteilt sind und was ein trivialer Baseline-Klassifikator wie scikit-learns DummyClassifier erreicht. Bei teuren Folgen übersehener Fälle, etwa einer nicht erkannten Krankheit, führt Recall; bei teuren Fehlalarmen, etwa gesperrten Konten, zählt Precision.

Accuracy sagt also nicht „das Modell erkennt Betrug“, sondern nur „das Modell liegt oft richtig“. Bei seltenen Klassen entscheiden Precision, Recall und F1 – nicht die Accuracy.

📌 Accuracy vs. Recall · Konfusionsmatrix · F1-Wert

📚 KI von Grund auf · Tag 6 von 30
#machinelearning #Evaluation #ki

Viele reden von Containern, meinen aber das Image – und umgekehrt. Dabei ist der Unterschied so klar wie der zwischen Backrezept und Kuchen.

Die Verwechslung liegt an der Sprache: Docker nennt beides fast gleich, und die Begriffe treten immer paarweise auf. Ein Fehler im laufenden Container zeigt sich erst später als verlorene Arbeit.

Ein Image ist eine unveränderliche Vorlage: eine Datei-Sammlung, in der Anwendung, Laufzeit-Umgebung, Bibliotheken und Konfiguration fest eingefroren sind. Nach dem Bau wird es nicht mehr geändert, sondern nur durch ein neues ersetzt – das Prinzip heißt Immutable Infrastructure. Beschrieben wird der Bau in einem Dockerfile, einer Schritt-für-Schritt-Anleitung. Beispiel: Ein Image enthält Python in einer festen Version plus den eigenen Anwendungscode.

Ein Container ist die laufende Instanz, die aus genau diesem Image gestartet wird. Er verpackt die Anwendung mit ihren Abhängigkeiten und teilt sich den Kernel (den Kern) des Host-Betriebssystems, startet dadurch schneller als eine virtuelle Maschine. Aus ein und demselben Image lassen sich beliebig viele Container starten, die alle identisch beginnen. Beispiel: Drei Container aus demselben Python-Image laufen gleichzeitig auf drei Rechnern.

Das Image bleibt unverändert, der Container ist vergänglich. Jede Änderung am laufenden Container verliert mit dessen Löschung ihre Spur.

Faustregel: Änderungen gehören immer in ein neues Image, das man über das Dockerfile baut – niemals in den laufenden Container.

Ein Image ist die Vorlage, ein Container deren laufende Kopie. Wer am Container schraubt, arbeitet im Sandkasten; wer am Image baut, arbeitet für jeden künftigen Start.

📌 Image = Vorlage · Container = Instanz · Änderungen ins Dockerfile

📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #kubernetes

Viele Anfänger trainieren, testen und wundern sich dann, dass die tollen Ergebnisse in der Praxis schwinden. Der Fehler liegt fast immer an denselben Daten, die zweimal benutzt wurden.

Viele denken, alles verfügbare Datenmaterial gehöre ins Training und der Rest sei egal für die Bewertung. Das klingt plausibel, weil mehr Daten meist bessere Modelle ergeben. Auch erscheint es naheliegend, mehrere Varianten am Testdatensatz zu vergleichen und die beste Zahl zu veröffentlichen.

Die Trainingsmenge passt die Parameter, also die vom Modell selbst gelernten Gewichte. Die Validierungsmenge dient der Auswahl zwischen Varianten und dem Abstimmen von Hyperparametern wie Lernrate oder Epochenanzahl, die vorab festgelegt werden. Die Testmenge liefert genau einmal eine unverfälschte Schätzung.

Der Irrtum entsteht, weil die drei Mengen im Code wie ein Datensatz wirken. Ein Split, also die Aufteilung des Gesamtbestands in feste Anteile, wirkt im Code wie eine Nebensache, und das Testergebnis wie eine freie Rückmeldung.

Ein Beispiel: Bei einem E-Mail-Spamfilter werden Hyperparameter mit der Validierungsmenge abgestimmt, etwa die Zahl der Trainingsepochen. Überwacht man dort den Fehler, stoppt man rechtzeitig, sobald er trotz sinkendem Trainingsfehler zu stagnieren beginnt. Erst am Schluss wird die Testmenge einmal geprüft.

Woran man es erkennt: Die Testmenge wurde mehr als einmal angefasst, etwa für Vergleiche oder Vorberechnungen. Ein Datenleck (Leakage) entsteht schon dadurch, dass über alle Daten vor dem Split normalisiert wird, statt die Werte nur auf den Trainingsdaten zu berechnen.

Test heißt nicht nochmal vergleichen, sondern einmal ehrlich messen. Wer die Testmenge wiederholt für Entscheidungen nutzt, verwandelt sie in eine Validierungsmenge, und die berichtete Leistung fällt zu optimistisch aus.

📌 Generalisierung · Leakage · Testmenge

📚 KI von Grund auf · Tag 3 von 30
#machinelearning #Evaluation #ki

Epoche und Batch klingen nach Zeitplänen. Dabei regeln sie nur, wie ein Modell seine Trainingsdaten portioniert.

Beide Begriffe tauchen in jeder Trainingsschleife auf und werden oft verwechselt: Einsteiger halten eine Epoche gern für einen einzelnen Trainingsschritt. Tatsächlich besteht eine Epoche aus vielen Schritten.

Die Epoche ist ein vollständiger Durchlauf durch alle Trainingsdaten. Das Modell sieht jedes Beispiel genau einmal pro Epoche. Hat der Datensatz 1000 Beispiele, endet die Epoche erst, wenn alle 1000 durchgerechnet sind. Eine Epoche allein reicht aber praktisch nie, weil das Lernen aus vielen kleinen Wiederholungen besteht. Typisch sind daher mehrere bis viele Epochen, bis der Verlust (der gemessene Fehler) stabil niedrig ist.

Der Batch ist die Teilmenge der Daten, nach der die Parameter jeweils aktualisiert werden. Der Batch wird durchgerechnet, die Verlustfunktion misst den Fehler, dann werden die Parameter einmal angepasst. Bei 1000 Beispielen und einer Batch-Größe von 100 gibt es also zehn Updates pro Epoche. Vor jeder neuen Epoche werden die Daten meist neu gemischt, damit keine feste Reihenfolge auswendiggelernt wird.

Die Epoche zählt, wie oft das Modell alle Daten sieht. Der Batch legt fest, wie oft pro Durchlauf die Parameter neu justiert werden. Beide sind Hyperparameter – Einstellungen, die vor dem Training festgelegt werden.

Faustregel: Die Batch-Größe wählt man klein genug für den Speicher und groß genug für ruhige Updates; die Anzahl der Epochen so hoch, bis der Verlust nicht mehr sinnvoll sinkt.

Epoche heißt nicht „ein Schritt“, sondern ein ganzer Durchlauf – der Batch macht daraus viele kleine.

📌 Epoche · Batch · Parameterupdate

📚 KI von Grund auf · Tag 2 von 30
#machinelearning #deeplearning #ki

Das Training läuft endlos, der Verlust aber geht nicht zurück. Dabei verrät der Verlustverlauf meist genau, was nicht stimmt.

Der Verlust (ein Maß dafür, wie weit Vorhersagen vom richtigen Ergebnis entfernt sind) schwankt wild oder bleibt auf hoher Ebene stehen. Statt zu lernen, springt das Modell scheinbar ziellos umher.

Beim Gradientenabstieg verändert das Training die Parameter schrittweise, und zwar in die Richtung, in der der Verlust am stärksten abnimmt. Parameter (Gewichte) sind die Zahlen im Modell, die aus den Daten gelernt werden. Der Gradient sagt, wie stark und in welche Richtung sich der Verlust ändert, wenn man einen Parameter ein wenig verschiebt. Die Lernrate bestimmt, wie groß jeder einzelne Schritt ist – und sie ist ein Hyperparameter: eine Einstellung, die vor dem Training von Hand festgelegt wird.

Ist die Lernrate zu groß, springen die Parameter über das beste Ergebnis hinweg; der Verlust pendelt, statt zu sinken. Ist sie zu klein, dauert das Training unverhältnismäßig lange, weil jeder Fortschritt winzig ist. Das Bild ist eine gebirgige Landschaft: Höhe entspricht Verlust, Position entspricht Parametern, und der Algorithmus läuft wie ein Wanderer im Nebel Schritt für Schritt bergab.

So prüft man es: Den Verlust über die Trainingsschritte aufzeichnen und den Verlauf ansehen. Schwankt er stark, die Lernrate verringern; sinkt er quälend langsam, sie erhöhen und erneut laufen.

Gradientenabstieg senkt den Verlust in vielen kleinen Schritten, nicht auf einen Schlag. Er findet ein Tal in der Nähe des Startpunkts – ob es das tiefste ist, ist nicht garantiert.

📌 Gradientenabstieg · Lernrate · Verlustfunktion

📚 KI von Grund auf · Tag 2 von 30
#machinelearning #deeplearning #ki

Viele glauben, das Training stelle das ganze Modell ein. Dabei werden nur die Parameter verändert – die Einstellungen stehen vorher fest.

Viele Einsteiger nehmen an, ein Modell lerne während des Trainings alles – auch seine Konfiguration. Schließlich gehört beides irgendwie zum Modell.

Tatsächlich sind Parameter und Hyperparameter zwei verschiedene Dinge. Parameter sind Zahlen im Modell selbst, etwa die Gewichte, mit denen ein Neuron (eine kleine Recheneinheit) seine Eingaben multipliziert. Hyperparameter sind Einstellungen wie Lernrate oder Anzahl der Epochen, die vor dem Training festgelegt werden. Nur die Parameter werden während des Trainings aus den Daten gelernt.

Der Irrtum entsteht, weil beide Begriffe ähnlich klingen und selten getrennt erklärt werden. Dazu kommt: Auch Hyperparameter beeinflussen das Ergebnis deutlich, nur eben auf Umwegen über den Trainingsablauf.

Ein Beispiel ist die Lernrate, die Schrittweite beim Gradientenabstieg – jenem Verfahren, das die Parameter in die Richtung verändert, in der die Verlustfunktion (das Maß für den Fehler) am stärksten sinkt. Ist die Lernrate zu groß, springen die Parameter über das beste Ergebnis hinweg. Ist sie zu klein, dauert das Training unverhältnismäßig lange. Eine Epoche ist ein vollständiger Durchlauf durch alle Trainingsdaten; auch ihre Anzahl wählt man vorher.

Woran man es erkennt: Parameter stehen nach dem Training als Zahlen im Modell und wandern mit ihm in die Inferenz (die Anwendung auf neue Eingaben). Hyperparameter steuern nur den Ablauf und tauchen im fertigen Modell nicht mehr auf.

„Parameter“ heißt nicht „alle Einstellungen eines Modells“, sondern nur die gelernten Zahlen. „Hyperparameter“ heißt nicht „besonders wichtige Parameter“, sondern die vorab gewählten Regeln fürs Training.

📌 Parameter (gelernt) · Hyperparameter (gewählt) · Lernrate

📚 KI von Grund auf · Tag 2 von 30
#machinelearning #deeplearning #ki

Solarbetriebener Umweltsensor seit 6 Monaten autark auf dem Dach: Temperatur, Luftfeuchtigkeit, Feinstaub (PM2.5/PM10), UV-Index. 6W Solarpanel, 18650-Akku mit TP4056-Laderegler, ESP32 im Deep Sleep. Die Daten gehen per LoRa an meinen Gateway und von dort ins Grafana-Dashboard. Hat den kompletten Winter ohne Batteriewechsel überstanden. #solar #umweltmonitoring #iot

RPA-Bot für die Buchhaltung: 200 Rechnungen pro Monat automatisch verarbeitet. Der Bot extrahiert Daten aus PDFs (OCR + Regex), prüft gegen Bestellungen, kategorisiert nach Kostenstelle und erstellt den Buchungssatz in DATEV. Fehlerquote von 8% (manuell) auf 0.3% (automatisiert). Jährliche Ersparnis: ca. 25.000 EUR an Personalkosten. #rpa #automation #buchhaltung

MLOps Pipeline mit MLflow + Kubeflow komplett aufgebaut. Vom Jupyter-Notebook-Chaos zu reproduzierbaren, versionierten ML-Experimenten. Jedes Training wird getrackt: Hyperparameter, Metriken, Artefakte, sogar die Git-Revision des Trainingscodes.

Model Registry mit Staging/Production-Stages, automatische A/B-Tests bei neuem Modell, und ein Rollback-Mechanismus der in unter 2 Minuten zum vorherigen Modell zurückwechselt. Endlich Ordnung im ML-Chaos. #mlops #mlflow #kubeflow

Automatische Bewässerung v2.0 fertig: ESP32-S3, 4 kapazitive Bodenfeuchtesensoren, Magnetventile, Solarpanel. Das System entscheidet selbst wann und wie lange bewässert wird - basierend auf Bodenfeuchte, Wettervorhersage (API-Abfrage alle 6h) und Pflanzenprofilen.

Wasserverbrauch gegenüber Zeitschaltuhr um 45% reduziert. Pflanzen sehen besser aus als je zuvor. Alles per MQTT an Home Assistant angebunden, Verlauf in Grafana. Das vollständige Tutorial kommt nächste Woche. #smarthome #esp32 #automation