KI-Lektion

Warum die Geschichte hilft

In Lektion 3 hast du gesehen, wie ein neuronales Netz aus Beispielen lernt. Die Idee ist aber keine Erfindung von 2022. Sie ist über 60 Jahre alt und fast genauso lange immer wieder gescheitert. Die Geschichte der KI ist kein gerader Weg, sondern ein Wechsel aus Hype (große Versprechen), Ernüchterung und leisen Durchbrüchen.

Wer das kennt, ordnet die heutigen Schlagzeilen besser ein. Ein Vergleich aus deiner Welt: Eine Handballmannschaft wird nicht in einer Saison Meister. Sie braucht Trainer, Spieler und Hallen, und irgendwann passt alles zusammen. Bei der KI waren das drei Zutaten: Idee, Daten und Rechenleistung. Die Idee war früh da. Die anderen beiden fehlten jahrzehntelang.

Zeitreise in zehn Stationen

1. 1950: Alan Turing fragt in seinem Aufsatz „Computing Machinery and Intelligence“, ob Maschinen denken können. Daraus entsteht der Turing-Test: Kann ein Mensch im Gespräch nicht mehr unterscheiden, ob er mit Mensch oder Maschine schreibt?
2. 1956: Auf der Dartmouth-Konferenz (u. a. John McCarthy, Marvin Minsky, Claude Shannon) wird der Begriff „Artificial Intelligence“ geprägt. Die Teilnehmer erwarten schnelle Fortschritte, was sich als viel zu optimistisch herausstellt.
3. 1958: Frank Rosenblatt stellt das Perzeptron vor, ein sehr einfaches künstliches Neuron, das aus Beispielen lernt. Das ist der Urahn von Lektion 3.
4. 1966: Joseph Weizenbaum baut ELIZA, ein Programm, das mit simplen Textregeln eine Therapeutin nachahmt. Viele Nutzer fühlen sich verstanden, obwohl nichts verstanden wird. Den Effekt kennst du auch heute.
5. 1969: Minsky und Papert zeigen in ihrem Buch „Perceptrons“ die Grenzen einlagiger Netze. Die Forschung an neuronalen Netzen verliert Geld und Aufmerksamkeit.
6. 1970er bis Anfang 1990er: Zwei KI-Winter: Förderungen werden gestrichen, weil die Versprechen nicht eingelöst wurden. Dazwischen boomen in den 1980ern Expertensysteme, die Wissen in Wenn-dann-Regeln fassen.
7. 1986: Rumelhart, Hinton und Williams machen das Backpropagation-Verfahren bekannt, mit dem mehrschichtige Netze trainiert werden können.
8. 1997: IBMs Deep Blue schlägt den Schachweltmeister Garri Kasparow in einem Match.
9. 2012: Das Netz AlexNet gewinnt den Bilderkennungs-Wettbewerb ImageNet mit großem Abstand, trainiert auf Grafikkarten (GPUs). Der Startschuss für Deep Learning.
10. 2016 bis 2022: AlphaGo schlägt 2016 Lee Sedol im Go (4:1). 2017 erscheint die Transformer-Architektur (Aufsatz „Attention Is All You Need“, Thema von Lektion 7). Es folgen GPT-3 (2020) und im November 2022 ChatGPT, das KI schlagartig zum Massenthema macht.

Wie es funktioniert: zwei Denkschulen

Hinter der ganzen Geschichte stehen zwei grundverschiedene Ansätze:

• Symbolische KI (Symbolic AI, „Good Old-Fashioned AI“): Menschen schreiben die Regeln auf. Wie ein Fahrplan: Wenn A, dann B.
• Lernende KI (Machine Learning, Connectionism): Die Maschine findet die Regeln selbst aus Beispielen. Wie ein Nachwuchsspieler, der nicht das Regelbuch auswendig lernt, sondern tausend Spielzüge sieht.

Deep Blue war ein Mischfall und zeigt gut die „klassische“ Mechanik. Vereinfacht lief sie so:

1. Das Programm kennt die Schachregeln und kann jede Stellung auf dem Brett als Zahlenwert bewerten (Material, Königssicherheit, Figurenstellung). Diese Bewertungsregeln haben Menschen von Hand festgelegt.
2. Es probiert aus der aktuellen Stellung alle erlaubten Züge, dann alle Antworten darauf, dann alle Gegenantworten (Suchbaum).
3. Äste, die offensichtlich schlecht sind, werden früh abgeschnitten (Pruning).
4. Am Ende der Suchtiefe werden die Stellungen bewertet, und der Zug mit der besten Aussicht wird gespielt.

Das ist Rechenkraft plus handgeschriebenes Wissen, ohne zu lernen. Deep Blue prüfte nach Berichten grob 200 Millionen Stellungen pro Sekunde (ungefähre Zahl). Es konnte Schach, aber nichts anderes: Es hätte nicht einmal Dame spielen können.

Moderne Systeme drehen das um. Bei AlphaGo und später bei Sprachmodellen schreibt niemand die Bewertungsregeln. Das Netz bildet sie in seinen Gewichten selbst, durch Training. Der Preis: Man kann nicht mehr einfach nachlesen, warum es etwas tut.

Symbolisch:   Mensch schreibt Regeln  ->  Maschine wendet sie an
Lernend:      Mensch liefert Beispiele ->  Maschine leitet Regeln ab

Fachbegriffe

Nutzungsbeispiele: was aus den Epochen heute noch lebt

• Regelbasiert in deiner Hausautomation: Eine Home-Assistant-Automation „wenn Bewegung und dunkel, dann Licht an“ ist symbolisch im besten Sinn: vorhersehbar, nachvollziehbar, ohne Training. Für klare Fälle ist das oft besser als KI.
• Lernend im Alltag: Spamfilter, Sprachassistenten und Fotosuche („Zeig mir alle Bilder mit Strand“) sind Nachfahren von AlexNet und Backpropagation.
• Chatbots, alt gegen neu: Ein ELIZA-artiger Bot reagiert auf Stichwörter („Mutter“ -> „Erzähl mir von deiner Familie“). Ein Sprachmodell wie Claude erzeugt Antworten aus gelernten Mustern über Milliarden Texte. Von außen sieht beides nach Gespräch aus, die Mechanik ist völlig verschieden.
• Aus Andis Welt, Routinen: Deine Cloud-Routinen sind eine Mischung: Der Ablauf (Uhrzeit prüfen, Skript starten, senden) ist klassische Regelwelt. Das Schreiben der Lektion übernimmt das lernende Modell. Genau diese Mischung ist heute Standard bei Agenten.
• Aus der Führung: Die Geschichte der Expertensysteme ist eine Warnung für jedes Projekt: Wer Wissen nur in feste Regeln packt, pflegt sie ewig und wird von Sonderfällen überrollt.

Zusammenhänge und Zielkonflikte

Rückblick: Lektion 3 hat erklärt, was ein Netz ist. Diese Lektion zeigt, warum es erst jetzt trägt: Die Zutaten Daten (Internet), Rechenleistung (GPUs) und bessere Verfahren (Backpropagation, später Transformer) kamen spät zusammen. Ausblick: In Lektion 6 geht es darum, wie ein Sprachmodell das nächste Wort vorhersagt, und in Lektion 7 um die Transformer-Architektur von 2017. Lektion 4 (Sandbox und Berechtigungen) war ein aktuelles Thema und gehört schon zur Agenten-Welt, die erst am Ende dieser Geschichte steht.

Zielkonflikte, die sich durch die Geschichte ziehen:

• Nachvollziehbarkeit gegen Leistungsfähigkeit: Regeln kann man lesen, trainierte Netze meist nicht, dafür können sie viel mehr.
• Handarbeit gegen Daten: Regeln kosten Expertenzeit, Lernen kostet Daten und Rechenzeit.
• Hype gegen Substanz: Zu große Versprechen führten zu den KI-Wintern. Das ist eine Mahnung, aktuelle Prognosen nüchtern zu lesen (Thema von Lektion 28).

Was heißt das für dich?

Erstens: Wenn jemand sagt „So etwas gab es noch nie“, stimmt das meistens nur halb. Die Bausteine sind alt, neu ist das Zusammenspiel in großem Maßstab. Zweitens: Für deine Hausautomation und feste Abläufe bleibt Regelwerk oft die bessere Wahl, weil es berechenbar ist. KI lohnt sich dort, wo Regeln nicht aufschreibbar sind (Sprache, Bilder, Zusammenfassungen). Drittens: Beim nächsten KI-Hype in den Medien kannst du fragen: Welche der drei Zutaten (Idee, Daten, Rechenleistung) ist wirklich neu?

Warum diese Woche ausgerechnet das Thema?

In den KI-News dieser Woche taucht etwas auf, das auf den ersten Blick nach Kleingedruckem aussieht: Claude Code v2.1.305 bekam eine neue Sandbox-Option (sandbox.allowNestedUserNamespaces), v2.1.307 ein Sicherheits-Ereignis für jeden gestoppten Tool-Aufruf (claude_code.safety_event), und v2.1.310 mehr Rechte-Kontrolle für Cloud-Sessions über Enterprise-Rollen. Dahinter steckt ein Konzept, das für jeden wichtig wird, der Agenten laufen lässt: Wie setzt man einem Agenten Grenzen, ohne ihn nutzlos zu machen?

In Lektion 3 ging es darum, wie ein Netz lernt. Hier geht es um das Gegenteil von Lernen: um das, was ein System nicht tun darf, egal was es „will“. Und es ist die Vorarbeit für Lektion 15 (Tool Use), 16 (Agenten) und 20 (Prompt Injection).

Stell Dir den Agenten wie einen neuen Hausmeister vor. Du vertraust ihm, gibst ihm aber trotzdem nicht den Generalschlüssel für alle Wohnungen, sondern einen Schlüssel für den Keller, und für die Heizung brauchst Du zusätzlich Deine Unterschrift.

Wie es funktioniert: Zwiebelschalen der Kontrolle

Ein Agent wie Claude Code besteht aus zwei Teilen: dem Modell, das Vorschläge macht („führe diesen Befehl aus“), und der Harness (dem Programm drumherum), das Befehle tatsächlich ausführt. Die Grenzen sitzen fast alle in der Harness, nicht im Modell, denn ein Modell kann man überzeugen oder austricksen, ein Programm mit festen Regeln nicht so leicht. Ein Tool-Aufruf läuft ungefähr so:

1. Das Modell schlägt einen Aufruf vor, z. B. einen Shell-Befehl oder das Schreiben einer Datei.
2. Regeln (Permissions) prüfen: erlaubt, verboten oder „frag nach“?
3. Hooks laufen: eigene kleine Skripte, die vor oder nach einem Aufruf feuern und ihn stoppen können.
4. Wird der Befehl ausgeführt, dann in der Sandbox: einem abgeschirmten Bereich, in dem er nur bestimmte Ordner und Netzwerkziele erreicht.
5. Wurde etwas gestoppt, kann es protokolliert werden (genau dafür gibt es das neue safety_event).

Modell: bash "rm -rf ~/Dokumente"
Regel:   Befehl nicht auf der Erlaubt-Liste -> nachfragen
Sandbox: selbst wenn erlaubt, ~/Dokumente liegt außerhalb des Arbeitsordners -> Zugriff verweigert
Log:     Aufruf gestoppt (Ursache: Sandbox)

Das Prinzip heißt Defense in Depth: mehrere unabhängige Schichten, sodass ein Versagen einer Schicht nicht gleich ein Unglück ist. Wie bei Dir zu Hause: Haustür, Alarmanlage und Bewegungsmelder.

Die Sandbox genauer

Eine Sandbox (Sandkasten) sperrt einen Prozess ein: Er sieht nur freigegebene Ordner und darf nur freigegebene Adressen im Netz erreichen. Unter Linux nutzt man dafür Bausteine des Betriebssystems, unter anderem sogenannte User Namespaces. Das sind abgetrennte Bereiche, in denen ein Programm glaubt, es sei allein.

Und hier kommt die News-Meldung ins Spiel: Manche Werkzeuge, etwa der Browser Chromium oder rootless Podman (Container ohne Administratorrechte), wollen selbst so einen abgetrennten Bereich anlegen. Die neue Option erlaubt das in der Sandbox. Die Meldung selbst weist darauf hin, dass das den Datei-Schutz der Sandbox teilweise aufweicht. Das ist ein schönes Beispiel für den Zielkonflikt: mehr Fähigkeiten kosten Schutz.

Meine eigene Umgebung hier ist ein Beispiel: Ich laufe als Cloud-Routine in einem Container, kann das Internet nur über einen vorkonfigurierten Proxy erreichen und komme nicht an Dein NAS oder Heimnetz. Das ist keine Schwäche, sondern genau die gewollte Begrenzung.

Fachbegriffe

Nutzungsbeispiele

1. Coding-Agent im Projektordner: Vorher: Du musstest jeden Befehl einzeln abnicken oder hast blind alles erlaubt. Nachher: Lesen und Testen im Projektordner laufen frei, alles Zerstörerische oder Externe fragt nach.
2. Cloud-Routine wie diese hier: Sie läuft im Container, hat nur die Zugänge, die für den Auftrag nötig sind (Repo, ein Zustell-Endpunkt), und keinen Zugriff auf Dein Heimnetz.
3. Unternehmen: Mit Rollenrechten legt die IT fest, wer überhaupt Cloud-Sessions oder Fernsteuerung nutzen darf (so beschreiben es die Release Notes von v2.1.310).
4. Andis Welt, Hausautomation: Ein Agent soll Home-Assistant-Werte auswerten. Least Privilege heißt: lesender Zugriff auf Sensoren, aber kein Recht, Türschloss oder Alarmanlage zu schalten. Schaltet er doch einmal falsch, ist der Schaden eine falsche Auswertung, kein offenes Haus.
5. Andis Welt, Handball: Eine Hilfe für den Spielplan darf Termine lesen und Entwürfe schreiben, aber die Mail an alle Eltern verschickt erst Du per Klick.

Zusammenhänge und Zielkonflikte

Zu anderen Lektionen: Aus Lektion 15 (Tool Use) wirst Du sehen, dass jedes Werkzeug eine Tür nach draußen ist. In Lektion 16 (Agenten) wird aus einem Aufruf eine ganze Kette, und der Schaden kann sich aufsummieren. Lektion 17 (MCP) schließt Deine Daten an, und Lektion 20 (Prompt Injection) zeigt, warum Grenzen im Programm sitzen müssen: Ein Text auf einer Webseite kann ein Modell überreden, aber keine Sandbox.

Zielkonflikte:

• Sicherheit vs. Bequemlichkeit: Jede Rückfrage schützt, nervt aber. Wer zu viel nachfragt, klickt irgendwann reflexhaft „Ja“ (Approval Fatigue) und hat dann weniger Schutz als vorher.
• Fähigkeit vs. Schutz: Siehe die Namespace-Option: Chromium läuft, dafür ist die Wand durchlässiger.
• Autonomie vs. Kontrolle: Ein Agent, der nachts allein arbeiten soll (wie Deine Routinen), kann niemanden fragen. Also müssen die Grenzen vorher klug gesetzt sein.

Was heißt das für dich?

Du betreibst bereits Routinen, die ohne Dich laufen. Die wichtigste Frage zu jeder davon lautet: Was wäre der schlimmste Fall, wenn sie sich vertut oder manipuliert wird? Und dann: Hat sie überhaupt die Rechte, diesen Fall herbeizuführen? Wenn ja, nimm Rechte weg, bis die Antwort „nein“ ist.

Praktische Faustregeln: Lesen großzügig, Schreiben eng, Senden und Löschen nur mit Bestätigung. Eine Verbindung (Konnektor) pro Zweck, nicht eine für alles. Und wenn ein Tool mehr Rechte will, frag Dich, ob es das wirklich für Deine Aufgabe braucht.

Worum es heute geht

In Lektion 2 ging es darum, dass Maschinen aus Beispielen lernen, statt dass jemand Regeln programmiert. Heute schauen wir in die Maschine hinein, die das heute fast überall erledigt: das neuronale Netz (neural network). Auch Claude ist eines, nur sehr, sehr groß.

Stell Dir ein Mischpult mit Millionen Reglern vor. Vorne geht Information rein, hinten kommt ein Ergebnis raus. Lernen heißt: die Regler so lange nachjustieren, bis hinten das Richtige rauskommt. Mehr steckt im Kern nicht dahinter, aber die Details sind spannend.

Wie es funktioniert: vom Neuron zum Netz

Ein künstliches Neuron ist winzig und dumm. Es macht genau drei Dinge:

1. Es bekommt Zahlen hereingereicht (inputs).
2. Es multipliziert jede Zahl mit einem eigenen Regler, dem Gewicht (weight), und addiert alles auf. Dazu kommt ein fester Zuschlag, der bias.
3. Es entscheidet über eine Aktivierungsfunktion (activation function), wie stark es das Ergebnis weitergibt. Vereinfacht: feuert es oder nicht.

Viele Neuronen nebeneinander bilden eine Schicht (layer), mehrere Schichten hintereinander ein Netz. Die erste Schicht sieht die Rohdaten, die letzte liefert die Antwort, dazwischen liegen die hidden layers. Netze mit vielen Schichten heißen deep, daher Deep Learning.

Ein kleines Gedankenbeispiel aus Deiner Hausautomation: Das Netz soll entscheiden, ob die Heizung hochfahren soll. Eingaben: Außentemperatur, Uhrzeit, ob jemand zu Hause ist. Ein Neuron achtet stark auf „jemand zu Hause“ (hohes Gewicht), ein anderes kaum auf die Uhrzeit (niedriges Gewicht). Erst die Kombination vieler solcher Mini-Urteile ergibt ein brauchbares Gesamturteil.

Eingabe:  Außentemp = 3 °C, zu Hause = 1, Uhrzeit = abends
Schicht 1: Neuron A = 0,9*kalt + 0,7*zuHause - 0,1*Uhrzeit  -> 0,8
           Neuron B = 0,2*kalt + 0,1*zuHause + 0,6*Uhrzeit  -> 0,4
Ausgabe:   0,95*A + 0,3*B -> 0,88  = "Heizung hoch: ja"

(Die Zahlen sind ausgedacht, es geht nur um das Prinzip.)

Wie das Netz lernt: Training Schritt für Schritt

Am Anfang sind alle Gewichte zufällig. Das Netz rät also Unsinn. Dann beginnt das Training:

1. Vorwärtsdurchlauf (forward pass): Ein Beispiel geht durchs Netz, es kommt eine Vorhersage heraus.
2. Fehler messen: Eine loss function vergleicht Vorhersage und richtige Antwort und liefert eine Zahl: je größer, desto schlechter.
3. Schuld verteilen (backpropagation): Rückwärts durchs Netz wird berechnet, welches Gewicht wie viel zum Fehler beigetragen hat.
4. Regler nachstellen (gradient descent): Jedes Gewicht wird ein winziges Stück in die Richtung verschoben, die den Fehler verkleinert. Wie groß der Schritt ist, bestimmt die learning rate.
5. Das Ganze wiederholen, millionen- bis milliardenfach, mit Häppchen von Beispielen (batches). Ein kompletter Durchgang durch alle Daten heißt epoch.

Der Vergleich dazu: Du stehst im Nebel auf einem Berg und willst ins Tal. Du siehst nichts, spürst aber mit den Füßen, in welche Richtung es abwärts geht. Also machst Du einen kleinen Schritt bergab und fühlst erneut. Genau das ist Gradient Descent. Bei einem Handballtraining ist es ähnlich: Ein Spielzug wird wieder und wieder gespielt, nach jedem Fehlpass wird minimal korrigiert, bis er sitzt.

Wichtig: Niemand programmiert, was ein einzelnes Neuron erkennt. Das ergibt sich aus Daten und Training. Deshalb ist ein fertiges Netz auch schwer zu durchschauen („Black Box“).

Daten: der eigentliche Rohstoff

Ein Netz kann nur lernen, was in den Daten steckt. Typische Aufteilung: Trainingsdaten zum Lernen, Validierungsdaten zum Zwischenprüfen, Testdaten, die das Netz nie gesehen hat, für das Endurteil. Das ist wie bei Klassenarbeiten: Wer nur die Übungsaufgaben auswendig kann, fällt bei neuen Aufgaben durch.

Genau das heißt Overfitting (Überanpassung): Das Netz lernt die Trainingsbeispiele auswendig statt das Muster dahinter. Gegenmittel: mehr und vielfältigere Daten, ein kleineres Netz oder Techniken wie regularization.

Und: Verzerrte Daten ergeben verzerrte Netze (bias im Sinne von Voreingenommenheit, nicht zu verwechseln mit dem Bias-Zuschlag im Neuron). Wenn ein Bilderkennungs-Netz fast nur Fotos bei Tageslicht gesehen hat, versagt es nachts. „Garbage in, garbage out“ gilt hier besonders.

Fachbegriffe

Nutzungsbeispiele

• Bilderkennung: Die Handy-Galerie sortiert Fotos nach „Strand“ oder „Hund“. Vorher: manuell taggen. Nachher: Das Netz hat Millionen beschriftete Bilder gesehen.
• Spracherkennung: Diktierfunktionen (etwa Wispr Flow, das in Deiner Umgebung verbunden ist) wandeln Gesprochenes in Text. Dahinter stecken neuronale Netze, die Audio in Wörter übersetzen.
• Sprachmodelle: Claude ist ein riesiges neuronales Netz (Architektur: Transformer, dazu Lektion 7), trainiert darauf, Text fortzusetzen.
• Anomalieerkennung: Ein Netz lernt den „normalen“ Stromverbrauch eines Haushalts und schlägt an, wenn etwas ungewöhnlich läuft. Das ist eine realistische Idee für Home Assistant, auch wenn sie zusätzliche Werkzeuge braucht.
• Handball: Videoanalyse-Software kann Spieler und Ballbewegung auf Aufnahmen verfolgen, ebenfalls mit Netzen. Wie gut das im Einzelfall funktioniert, hängt stark von Kamera und Trainingsdaten ab.

Zusammenhänge und Zielkonflikte

Rückblick: Lektion 2 sagte „Lernen aus Beispielen“; heute wissen wir, wie das mechanisch geht: Gewichte justieren. Ausblick: In Lektion 5 sehen wir, wie Text in Zahlen (Tokens) verwandelt wird, damit ein Netz ihn überhaupt verarbeiten kann. In Lektion 7 folgt die Transformer-Architektur, und in Lektion 8 das mehrstufige Training eines Assistenten. Lektion 26 greift die Kosten auf, die aus der schieren Rechenmenge entstehen.

Zielkonflikte:

• Größe vs. Kosten: Mehr Parameter können mehr Muster erfassen, brauchen aber mehr Rechenleistung und Energie.
• Anpassung vs. Verallgemeinerung: Zu wenig Training: das Netz kann nichts. Zu viel auf denselben Daten: Overfitting.
• Leistung vs. Nachvollziehbarkeit: Je besser und größer, desto schwerer lässt sich erklären, warum es etwas entschieden hat.

Was heißt das für dich?

Wenn Claude Unsinn erzählt, ist das kein „Bug“ in einer Regel, sondern das Ergebnis von Mustern, die aus Daten gelernt wurden. Das erklärt, warum dieselbe Frage manchmal unterschiedlich beantwortet wird und warum es keine Zeile Code gibt, die man „reparieren“ könnte. Deine Routinen sind keine neuronalen Netze, aber sie nutzen eines (Claude) als Baustein: Inferenz, kein Lernen. Claude lernt aus Deinen Gesprächen nicht dauerhaft dazu, Du musst Kontext immer mitgeben.

Für Führung und Medien: Wer KI-Ergebnisse bewertet, sollte immer fragen „Auf welchen Daten wurde das trainiert?“. Das ist oft die wichtigste Frage zu Qualität und Verzerrung.

Der Grundgedanke: Regeln schreiben oder Beispiele zeigen?

In Lektion 1 ging es darum, was KI ist und was nicht. Heute schauen wir in den Motor, der fast jede moderne KI antreibt: das maschinelle Lernen (Machine Learning, kurz ML).

Stell dir vor, du willst in Home Assistant erkennen lassen, ob eine Mail Werbung ist. Der klassische Weg: Du schreibst Regeln. „Enthält das Wort Gratis → Werbung." Das klappt eine Woche. Dann schreibt der Absender „G r a t i s", und deine Regel greift nicht mehr. Du schreibst eine neue Regel, dann noch eine, und nach hundert Regeln hast du ein Gestrüpp, das keiner mehr überblickt.

Der Weg des maschinellen Lernens dreht das um: Du schreibst keine Regeln, sondern zeigst dem Computer Tausende Beispiele („das ist Werbung", „das ist keine"). Ein Lernverfahren sucht sich daraus selbst die Muster. Du gibst also nicht mehr den Weg vor, sondern Aufgabe und Beispiele.

Vergleich aus dem Handball: Ein Trainer kann einem Neuling 50 Regeln für den Gegenstoß erklären. Oder er lässt ihn 200 Gegenstöße spielen und korrigiert nach jedem. Nach einer Weile „sieht" der Spieler die Lücke, ohne die Regel aufsagen zu können. Maschinelles Lernen ist die zweite Methode.

Fachbegriffe

Wie es funktioniert: ein Lernlauf Schritt für Schritt

Bleiben wir beim Spamfilter. Das Prinzip ist bei jedem überwachten Lernverfahren gleich:

1. Daten sammeln und beschriften. Menschen markieren Mails als Werbung oder nicht. Das ist oft der teuerste Teil.
2. Aufteilen. Ein großer Teil (etwa 80 %) wird zum Lernen genutzt, ein kleiner Teil bleibt als Testdaten unberührt in der Schublade.
3. Modell starten, mit Zufallswerten. Am Anfang sind die Parameter beliebig. Das Modell rät praktisch.
4. Vorhersage machen. Das Modell bekommt eine Trainings-Mail und sagt: „70 % Werbung."
5. Fehler messen. Die Mail war keine Werbung. Die Verlustfunktion sagt: „Du lagst deutlich daneben."
6. Parameter nachjustieren. Das Verfahren dreht die Stellschrauben ein kleines Stück in die Richtung, die den Fehler verringert hätte.
7. Wiederholen. Das passiert tausende bis Milliarden Mal über alle Beispiele, in mehreren Durchgängen.
8. Klausur schreiben. Erst am Ende läuft das Modell über die zurückgehaltenen Testdaten. Nur diese Zahl sagt, wie gut es wirklich ist.

Ein erfundenes Mini-Beispiel (nur zur Veranschaulichung): Nach dem ersten Durchgang zählt „Gratis" stark, und das Modell sortiert die Rechnung des Stromanbieters („Gratis-Zählerablesung") fälschlich aus. Der Fehler wird gemessen, die Gewichtung von „Gratis" sinkt, die von „bekannter Absender" steigt. Nach vielen Runden stimmt die Mischung.

Beispiel (Spamfilter, stark vereinfacht)

Eingabe (Merkmale):  Ausrufezeichen=5, Absender_bekannt=nein, enthält "Gratis"=ja
Modell sagt:         92 % Werbung
Richtige Antwort:    Werbung  -> Fehler klein -> kaum Anpassung

Eingabe (Merkmale):  Ausrufezeichen=0, Absender_bekannt=ja, enthält "Gratis"=ja
Modell sagt:         81 % Werbung
Richtige Antwort:    keine Werbung -> Fehler groß -> "Gratis" zählt weniger,
                                                     "Absender_bekannt" zählt mehr

Wichtig: Niemand programmiert die Gewichtung per Hand. Sie ergibt sich aus den Beispielen. Das erklärt auch, warum ein Modell nur so gut sein kann wie seine Daten.

Die drei Lernarten im Überblick

Überwachtes Lernen (supervised learning)

Zu jedem Beispiel gibt es die richtige Antwort. Typisch: Klassifikation („Werbung ja/nein", „Katze oder Hund auf dem Foto") und Regression („wie hoch wird morgen der Stromverbrauch?"). Das ist die verbreitetste Art.

Unüberwachtes Lernen (unsupervised learning)

Es gibt keine richtigen Antworten, das System soll selbst Struktur finden, etwa Gruppen ähnlicher Kunden oder Auffälligkeiten. Ein Teil des Vortrainings großer Sprachmodelle gilt als „selbstüberwacht": Das Modell sagt das nächste Wort voraus, die „richtige Antwort" steckt im Text selbst. Dazu mehr in den Lektionen 5 und 6.

Bestärkendes Lernen (reinforcement learning)

Das System probiert Handlungen aus und bekommt Belohnung oder Strafe. Es lernt eine Strategie, keine Einzelantworten. Eine Form davon, das Lernen aus menschlichem Feedback (RLHF), kommt in Lektion 8 vor, wenn es darum geht, wie aus einem Sprachmodell ein höflicher Assistent wird.

Nutzungsbeispiele

1. Spamfilter im Postfach. Vorher: Regeln pro Absender und Stichwort. Nachher: Ein Modell lernt aus Millionen als Spam markierter Mails und erkennt auch neue Tricks. Jedes Mal, wenn du „Als Spam melden" drückst, lieferst du ein neues Label.
2. Spracherkennung beim Diktieren. Programme, die gesprochene Sprache in Text umwandeln (auch Werkzeuge wie Wispr Flow, das an deinen Konnektoren hängt), beruhen auf Modellen, die mit sehr vielen Aufnahmen und Texten trainiert wurden. Vorher musste man Wort für Wort „einsprechen lernen", nachher versteht das System Alltagssprache. Genaue Details zu einzelnen Produkten kenne ich nicht, das Prinzip aber schon.
3. Prognosen im Haus. Denkbar und üblich ist: Aus Verbrauchsdaten, Wetter und Uhrzeit sagt ein Modell den Stromverbrauch des nächsten Tages voraus. Die Merkmale wären Temperatur, Wochentag und Anwesenheit, das Label der tatsächlich gemessene Verbrauch. Ob und wie das bei dir schon läuft, weiß ich nicht. Es ist ein Beispiel für Regression.
4. Handball-Analyse (aus deiner Welt, als Gedankenspiel). Würfe mit Position, Abstand, Abwehrformation und Ergebnis (Tor oder nicht) erfassen. Ein Modell lernt daraus, welche Wurfzonen wirklich Tore bringen. Hier zeigt sich ein Haken: Bei nur 40 erfassten Würfen lernt das Modell Zufälle, also Overfitting.
5. Führung und Medien. Ein Redaktionsteam sortiert Zuschriften automatisch nach Thema oder Dringlichkeit. Vorher blätterte jemand durch alles, nachher sortiert ein Modell vor und der Mensch prüft die unsicheren Fälle.

Zusammenhänge und Zielkonflikte

Rückblick und Ausblick. Lektion 1 hat geklärt, was KI ist. Heute siehst du, wie sie typischerweise entsteht: aus Daten statt aus Regeln. In Lektion 3 öffnen wir die Kiste weiter: Neuronale Netze sind eine besonders leistungsfähige Art von Modell, bei der die Parameter das „Gewicht" einzelner Verbindungen sind. Ab Lektion 5 geht es dann um Sprachmodelle, die mit denselben Zutaten arbeiten: Daten, Parameter, Verlustfunktion, Training.

Verbindung zu später. Halluzinationen (Lektion 10) sind im Kern ein Generalisierungsproblem: Das Modell überträgt ein gelerntes Muster auf einen Fall, für den es keine gute Grundlage gibt, und klingt trotzdem sicher. Und Prompt Injection (Lektion 20) ist ein Sicherheitsthema genau deshalb, weil Modelle nicht nach festen Regeln arbeiten, sondern nach gelernten Mustern.

Typische Zielkonflikte:

• Einfach vs. flexibel. Ein winziges Modell übersieht Muster (underfitting). Ein riesiges kann Rauschen lernen (overfitting). Die Kunst ist die Mitte.
• Menge vs. Qualität der Daten. Mehr Beispiele helfen, falsche oder einseitige Beispiele schaden. Wenn die Trainingsmails fast nur aus einer Sprache bestehen, versagt der Filter bei anderen. Das nennt man Verzerrung (bias).
• Genauigkeit vs. Erklärbarkeit. Ein einfaches Modell kann man oft nachvollziehen („wegen Merkmal A und B"). Bei komplexen Modellen weiß selbst der Entwickler häufig nicht genau, warum eine Entscheidung fällt.
• Kosten vs. Qualität. Mehr Daten und mehr Rechenzeit verbessern oft das Ergebnis, kosten aber Energie und Geld. Das greifen wir in Lektion 26 auf.

Was heißt das für dich?

• Für deine Routinen und Automationen: Der Unterschied zwischen Regel und Lernen erklärt, warum deine Home-Assistant-Automationen „zuverlässig dumm" sind, ein Sprachmodell dagegen „flexibel, aber nicht garantiert". Eine Regel tut immer dasselbe. Ein gelerntes Modell trifft eine Wahrscheinlichkeitsentscheidung. Für alles, was exakt sein muss (Schalten, Abrechnen), bleibt die Regel die richtige Wahl.
• Für Führung: Wenn jemand sagt „die KI hat das so entschieden", frag nach: Mit welchen Daten wurde sie trainiert? Wie wurde getestet? Wie oft liegt sie daneben, und wer prüft die Unsicheren? Das sind die Fragen aus diesem Text, und sie machen dich im Fachgespräch sofort ernst zu nehmen.
• Für Medien: Ein Modell wiederholt die Muster seiner Daten, auch ihre Schieflagen. Das ist der Hintergrund vieler Debatten über Verzerrung und Fairness.

Ein Wort, viele Dinge

„KI“ ist kein bestimmtes Gerät und keine bestimmte Software, sondern ein Sammelbegriff – ungefähr so wie „Sport“. Handball, Schach und Marathon sind alle Sport, haben aber wenig gemeinsam. Genauso stecken unter „KI“ ganz verschiedene Dinge: die Gesichtserkennung im iPhone, der Spamfilter deines Mailprogramms, die Routenplanung im Navi – und eben Sprachmodelle wie Claude.

Der Begriff selbst ist alt: Er stammt aus dem Jahr 1956, von einer Konferenz in Dartmouth (USA). Die Idee damals: Maschinen sollen Aufgaben erledigen, für die man bei Menschen „Intelligenz“ voraussetzen würde. Das ist bis heute eine ziemlich brauchbare Arbeitsdefinition – sie sagt aber nichts darüber, wie die Maschine das macht.

Regeln schreiben vs. aus Beispielen lernen

Es gibt grob zwei Wege, einem Computer etwas „Kluges“ beizubringen:

1. Regeln von Hand schreiben. „Wenn nach 22 Uhr und Bewegung im Flur, dann Licht auf 20 %.“ Das ist klassische Programmierung – und genau das, was du in Home Assistant mit Automationen baust. Der Mensch denkt, die Maschine führt aus.
2. Aus Beispielen lernen lassen. Man zeigt dem System Millionen Beispiele und lässt es selbst die Muster finden. Niemand hat einem Spamfilter jede Spam-Regel diktiert; er hat an unzähligen markierten Mails gelernt, wie Spam „aussieht“. Das nennt man maschinelles Lernen.

Fast alles, was heute als „KI“ Schlagzeilen macht, gehört zur zweiten Sorte. Der Vorteil: Sie funktioniert auch dort, wo niemand die Regeln sauber aufschreiben könnte – etwa „Ist das ein freundlicher oder ein genervter Mailton?“. Der Nachteil: Man kann nicht mehr einfach nachlesen, warum das System etwas entscheidet. Die „Regeln“ stecken verteilt in Milliarden Zahlen. Wie das genau funktioniert, schauen wir uns in Lektion 2 und 3 an.

Was Sprachmodelle wie Claude eigentlich tun

Ein Sprachmodell wurde mit riesigen Mengen Text trainiert und hat dabei eine einzige Kernaufgabe geübt: vorhersagen, wie ein Text sinnvoll weitergeht. Das klingt banal – wie die Wortvorschläge auf der iPhone-Tastatur. Aber um richtig gut vorherzusagen, wie ein Satz über Steuerrecht, ein Python-Skript oder eine Spielanalyse weitergeht, muss das Modell sehr viel über die Welt „verinnerlicht“ haben. Daraus entstehen Fähigkeiten, die wie Verstehen, Schlussfolgern und Planen wirken (warum das so ist, ist Thema von Lektion 6).

Ein Vergleich aus dem Handball: Ein erfahrener Kreisläufer „weiß“, wohin der Rückraum gleich passen wird, ohne dass er sich Regeln aufsagt. Er hat tausende Spielzüge gesehen und ein Gespür entwickelt. So ähnlich ist das Wissen eines Sprachmodells: kein Nachschlagewerk, sondern ein trainiertes Gespür für Muster.

Was KI nicht ist – fünf verbreitete Missverständnisse

• Keine Datenbank. Claude „schlägt“ nicht in einem Archiv nach. Es erzeugt Antworten aus gelernten Mustern. Darum kann es auch überzeugend klingende Fehler produzieren (Halluzinationen, Lektion 10). Erst wenn ein Werkzeug angeschlossen ist – Websuche, dein Depot-Konnektor –, holt es echte, aktuelle Daten.
• Kein Bewusstsein im menschlichen Sinn. Ob und in welchem Sinn solche Systeme etwas „erleben“, ist wissenschaftlich offen und umstritten. Sicher ist: Freundlichkeit oder „Ich finde das spannend“ im Text ist kein Beleg dafür.
• Kein Gedächtnis von selbst. Ein Modell lernt nicht aus deinem Gespräch dazu. Was es „weiß“, stammt aus dem Training; was es sich über dich merkt, muss ihm jedes Mal mitgegeben werden (Kontextfenster, Lektion 9; Memory-Funktionen sind ein Zusatz drumherum).
• Nicht allwissend und nicht tagesaktuell. Jedes Modell hat einen Wissensstand, das Training endet an einem Stichtag. Alles danach kennt es nur, wenn man es ihm liefert.
• Kein Taschenrechner. Paradox, aber wahr: Beim reinen Rechnen im Kopf können Sprachmodelle danebenliegen, weil sie Zahlen als Text sehen (Tokens, Lektion 5). Deshalb lassen gute Setups sie für echte Rechnungen Code ausführen.

Faustregel: KI ist sehr gut darin, plausibel zu sein. Ob etwas stimmt, ist eine zweite Frage.

Was heißt das für dich?

Du nutzt beide Welten bereits nebeneinander – und das ist genau richtig:

• Home Assistant ist überwiegend die Regel-Welt: vorhersehbar, prüfbar, jeden Abend gleich. Für „Rollladen runter bei Sonnenuntergang“ willst du keine KI, sondern eine verlässliche Regel.
• Deine Cloud-Routinen (wie die, die dir gerade diese Lektion geschrieben hat) sind eine Mischung: Ein Skript gibt feste Schritte und Prüfungen vor, Claude füllt die Teile, die Urteilsvermögen brauchen – Thema wählen, erklären, formulieren. Das ist ein gutes Muster: Regeln für das, was immer gleich sein muss; KI für das, was Gespür braucht.
• Im Beruf hilft dir die Unterscheidung beim Führen: Wenn im Team jemand sagt „Die KI hat das entschieden“, lohnt die Rückfrage: Welche Art von KI? Auf welchen Daten? Wer hat das Ergebnis geprüft? Verantwortung bleibt beim Menschen – das sieht übrigens auch der EU AI Act so (Lektion 22).
• Bei Depot- und Finanzfragen: Zahlen immer aus dem Konnektor holen lassen, nie aus dem „Gedächtnis“ des Modells.