KI-Landkarte & Modelllebenszyklus

Warum eine Landkarte?

„KI“ ist im Betrieb selten ein Ding, sondern ein Sammelbegriff. Wer die Begriffe nicht trennt, diskutiert aneinander vorbei: Der Fachbereich meint einen Chatbot, der Einkauf meint einen Vertrag, der Betrieb meint eine neue Abhängigkeit im Change-Prozess.

Diese Landkarte hat einen einzigen Zweck — sie soll dir erlauben, eine Anfrage einzuordnen, bevor jemand ein Werkzeug auswählt. Die technische Tiefe kommt in den späteren Modulen; hier geht es um die Achsen, an denen Entscheidungen hängen.

Modell — Eine parametrisierte Funktion, die Eingaben in Ausgaben abbildet. Ein Modell kennt weder Nutzerrechte noch Freigabeprozesse; diese Eigenschaften gehören zum umgebenden System.

Eine belastbare Bestandsaufnahme benennt deshalb mindestens vier Dinge getrennt: den Anwendungsfall, das verwendete Modell, die zugeführten Daten und die nachgelagerten Kontrollen. Die Aussage „Wir setzen KI ein“ ist betrieblich so ungenau wie „Wir setzen Software ein“. Erst die konkrete Kette zeigt, wo Daten das Unternehmen verlassen, wo Wahrscheinlichkeiten entstehen und welche Komponente eine Wirkung auslöst. Der Preis dieser Genauigkeit ist mehr Vorarbeit im Architekturgespräch; der Gewinn ist, dass Fehler einer veränderbaren Schicht zugeordnet werden können.

Die Schachtelung: KI ⊃ ML ⊃ Deep Learning ⊃ LLM

Künstliche Intelligenz ist das Oberfeld: Systeme, die Aufgaben lösen, für die man sonst menschliches Urteil bräuchte. Dazu zählen auch klassische, vollständig regelbasierte Expertensysteme.

Maschinelles Lernen ist die Teilmenge, in der das Verhalten nicht programmiert, sondern aus Daten abgeleitet wird. Deep Learning ist wiederum die Teilmenge, die dafür vielschichtige neuronale Netze nutzt. Ein großes Sprachmodell (LLM) ist ein spezielles Deep-Learning-Modell, das auf sehr großen Textmengen darauf trainiert wurde, das jeweils nächste Textstück vorherzusagen.

• Nicht jede KI ist ein LLM — Betrugserkennung, Prognose und Bildklassifikation sind häufig klassisches ML.
• Nicht jedes ML braucht Deep Learning — für Tabellendaten sind einfachere Verfahren oft genauer und billiger.
• Ein LLM ist keine Datenbank und keine Rechenmaschine, sondern ein Sprachmodell.

Die Mengenbeziehung ist eine Orientierung, keine Produkttaxonomie. Ein Hersteller kann „AI“ auf ein deterministisches Regelwerk schreiben; umgekehrt kann ein kleines Klassifikationsmodell ein sinnvoller ML-Baustein sein, ohne generative Oberfläche. Für den Betrieb zählt daher nicht das Etikett, sondern der beobachtbare Contract: Welche Eingabe wird verarbeitet, welches Ergebnis entsteht, wurde Verhalten aus Beispielen gelernt, und ist die Ausgabe offen oder auf Klassen begrenzt? Diese Fragen verhindern, dass Teams Kontrollbedarf aus Marketingbegriffen ableiten.

Regelbasiert oder gelernt — die erste Weiche

Regelbasierte Software ist überlegen, wo die Regel bekannt, stabil und aufschreibbar ist. Eine Urlaubsanspruchsberechnung, eine Steuerformel, eine Gültigkeitsprüfung von Kontonummern — dort ist ein gelerntes Modell nicht nur überflüssig, sondern schädlich: Es kann eine Regel nur annähern, die man exakt haben könnte.

Gelernte Modelle lohnen sich dort, wo die Regel existiert, aber niemand sie vollständig aufschreiben kann: Wann klingt eine E-Mail wie eine Beschwerde? Welches Ticket gehört zu welchem Team? Diese Grenze — „kann ich die Regel hinschreiben?“ — trägt weiter als jede Technologie-Diskussion.

Eine praktisch brauchbare Probe lautet: Kann ein Fachexperte die Entscheidung als endliche, widerspruchsfreie Regel notieren und gegen Grenzfälle testen? Dann ist if, eine Tabelle oder ein Solver meist die ehrlichere Implementierung. Ist die relevante Struktur nur in vielen Beispielen sichtbar, kann Lernen passen. Dazwischen liegt ein häufiger Hybrid: Ein Modell extrahiert unscharfe Information, danach erzwingt Code die harte Regel. Nachteil: Die Pipeline hat mehr Schnittstellen und braucht Fehlerbehandlung zwischen Extraktion und Entscheidung.

Diskriminativ oder generativ

Diskriminative Modelle ordnen zu: Eingabe rein, eine Klasse oder ein Wert raus (Kategorie, Wahrscheinlichkeit, Score). Sie sind leicht messbar — es gibt eine richtige Antwort je Fall, also lassen sich Trefferquote und Verwechslungen direkt auswerten.

Generative Modelle erzeugen neue Inhalte: Text, Code, Bild. Ihre Stärke ist die Offenheit des Ausgaberaums — genau das macht die Bewertung schwer, denn es gibt selten genau eine richtige Ausgabe.

Feste, stabile Klassenmenge und viele gelabelte Beispiele

diskriminativer Klassifikator — billiger, schneller, direkt messbar

Offene Formulierung, wechselnde Aufgaben, wenig Trainingsdaten

generatives Modell — flexibel, aber aufwendiger zu bewerten

Exakt spezifizierbare Regel

Code — gar kein Modell

Diskriminatives Modell — Ein Modell, das Grenzen zwischen vorgegebenen Klassen oder einen Zielwert lernt. Sein Ausgaberaum ist enger als bei freier Generierung und dadurch meist leichter messbar.

Ein LLM kann zwar per Prompt als Klassifikator dienen, doch das macht die Aufgabe nicht generativ. Bei stabilen Klassen und ausreichenden Labels sollte ein Team beide Wege auf demselben Testset vergleichen. Das LLM kauft schnelle Anpassbarkeit und sprachliche Robustheit; ein spezialisierter Klassifikator kauft oft geringere Latenz, klarere Scores und stabilere Ausgabeformen. Die richtige Wahl folgt aus der gemessenen Fehlerverteilung, nicht aus der Frage, welches System im Demo-Chat eindrucksvoller wirkt.

Deterministisch gegen probabilistisch — die Abnahme ändert sich

Klassische Software ist deterministisch: gleiche Eingabe, gleiche Ausgabe, und ein Fehler ist ein Defekt, der behoben wird. Gelernte Systeme sind probabilistisch: Sie haben eine Fehlerrate, die man senken, aber nicht auf null setzen kann. Ein einzelner falscher Fall ist dort kein Bug im klassischen Sinn, sondern ein erwartetes Ereignis.

Damit ändert sich die Abnahme. Ein Kriterium wie „darf nie eine falsche Kategorie vergeben“ ist bei einem gelernten System nicht erfüllbar und blockiert jede Einführung. Sinnvoll ist stattdessen: gemessene Fehlerrate auf einem repräsentativen Set, definierter Umgang mit dem Fehlerfall und ein Rückfallweg.

Probabilistisch bedeutet nicht, dass jede Ausführung zwingend anders sein muss. Es bedeutet, dass das Modell eine Verteilung über mögliche Ausgaben repräsentiert und die Qualität statistisch bewertet werden muss. Ein Schema-Validator kann deterministisch prüfen, ob JSON formal passt; er kann aber nicht allein beweisen, dass ein generierter Sachverhalt stimmt. Gute Systeme kombinieren beide Ebenen: statistische Tests für Modellverhalten, deterministische Invarianten für alles, was niemals verletzt werden darf.

Modell gegen System — wo Verlässlichkeit entsteht

Das Modell ist eine Komponente, kein Produkt. Was der Nutzer als „die KI“ erlebt, ist ein System: Datenzufuhr, Prompt, Modellaufruf, Validierung der Ausgabe, Protokollierung, Fehlerbehandlung, Bedienoberfläche. Die meisten Qualitätsprobleme in der Praxis sitzen in diesen Schichten und nicht im Modell.

Praktische Folge: Wenn ein Ergebnis schlecht ist, ist „ein besseres Modell“ selten der erste Hebel. Häufiger fehlen die richtigen Daten im Kontext, eine Validierung der Ausgabe oder eine klare Aufgabendefinition.

Sculley und Kollegen beschreiben ML-Systeme als Geflecht aus Datenabhängigkeiten, Konfiguration, Serving, Monitoring und Konsumenten. Diese Sicht ist für LLM-Anwendungen zentral: Derselbe Modellendpunkt kann in einer Suchhilfe akzeptabel und in einer automatischen Berechtigungsvergabe unvertretbar sein. Die Systemgrenze bestimmt den Schaden. Empfehlung: Formuliere die Garantie am Ausgang der gesamten Pipeline. Preis: Zusätzliche Validatoren, Fallbacks und Beobachtbarkeit kosten Latenz und Betriebskapazität.

Warum die Entstehung wichtig ist

Fast jede Fehlvorstellung über LLMs im Betrieb hat dieselbe Wurzel: die Annahme, das Modell würde im Gespräch dazulernen und sich merken, was du ihm sagst. Wer den Entstehungsweg kennt, sortiert Anforderungen sofort richtig — manches gehört ins Training, das allermeiste in den Kontext, einiges gar nicht ins Modell.

Der Lebenszyklus trennt außerdem Entscheidungen mit sehr verschiedenen Taktzeiten. Training kann Wochen dauern und wird als neues Artefakt ausgeliefert. Eine Promptänderung oder neue Retrieval-Quelle wirkt dagegen mit dem nächsten Deployment oder sogar dem nächsten Request. Wer diese Zeitskalen vermischt, wählt für eine schnell wechselnde Geschäftsregel einen langsamen und schlecht reversiblen Hebel. Das folgende Modell hilft: Gewichte speichern gelernte Regelmäßigkeiten, Kontext liefert fallbezogene Information, Code erzwingt Prozessregeln.

Pretraining: die teure Grundausbildung

Im Pretraining lernt das Modell auf sehr großen Textmengen eine einzige Aufgabe: das nächste Textstück vorhersagen. Dabei entsteht als Nebenprodukt sehr viel — Grammatik, Weltwissen, Programmierkonventionen, Stilgefühl. Nichts davon ist als Fakt abgelegt; alles steckt in Gewichten, den durchtrainierten Zahlenparametern des Netzes.

Zwei Konsequenzen für den Betrieb. Erstens: Was nicht im Trainingskorpus war, ist nicht im Modell — eure internen Systeme, Prozesse und Kundendaten gehören dazu. Zweitens: Es gibt einen Wissensstichtag. Alles nach diesem Zeitpunkt existiert für das Modell nicht, auch wenn es souverän darüber spricht.

Beim Pretraining werden Parameter durch Optimierung auf großen Datenmengen angepasst. Das Ergebnis ist kein durchsuchbares Dokumentenarchiv: Herkunft und genaue Speicherung eines einzelnen Fakts sind nicht wie Datensätze in einer Tabelle adressierbar. Darum ist „Es stand in den Trainingsdaten“ keine ausreichende Provenienz für eine Antwort. Pretraining liefert breite sprachliche und statistische Fähigkeiten; für aktuelle interne Fakten braucht die Anwendung eine kontrollierte Quelle. Nachteil: Externe Wissenszufuhr schafft einen zusätzlichen Index- oder Tool-Pfad, der selbst ausfallen kann.

Post-Training: Verhalten formen, nicht Wissen nachfüllen

Ein rein vorab trainiertes Modell setzt Text fort, es befolgt keine Anweisungen. Erst das Post-Training macht daraus einen brauchbaren Assistenten. Zwei Bausteine sind üblich: überwachtes Feintuning auf Beispieldialogen und eine anschließende Präferenz-Optimierung, bei der das Modell aus dem Vergleich bevorzugter und abgelehnter Antworten lernt.

Post-Training bestimmt vor allem Verhalten: Antwortstil, Anweisungstreue, Umgang mit Formatvorgaben, Verweigerungsverhalten. Es fügt kein nennenswertes neues Faktenwissen hinzu — und es erklärt Effekte, die im Betrieb irritieren, etwa dass ein Modell eine völlig legitime interne Aufgabe ablehnt, weil sie oberflächlich nach etwas Heiklem aussieht.

Modell soll aktuelle oder interne Fakten kennen

Kontext bzw. Grounding — nicht Training

Modell soll ein festes Ausgabeformat oder einen Hausstil treffen

Prompt, Beispiele; bei hohem Volumen ggf. Feintuning

Modell soll eine neue Fähigkeit erwerben, die es gar nicht hat

anderes Basismodell — Feintuning erzeugt selten neue Grundfähigkeiten

Post-Training umfasst Verfahren, die ein Basismodell für Anweisungen und gewünschtes Verhalten brauchbarer machen. Die InstructGPT-Arbeit trennt beispielsweise Demonstrationen, ein aus Präferenzurteilen trainiertes Reward-Modell und anschließende Optimierung. Daraus folgt keine Garantie auf Wahrheit: Präferenzen bewerten, welche Antwort Menschen bevorzugen, und können Stil oder Zustimmung belohnen. Im Betrieb darf „gut ausgerichtet“ deshalb nicht mit „faktisch geprüft“ verwechselt werden.

Die Gewichte sind statisch

Im Betrieb ändert sich am Modell nichts. Jeder Aufruf ist unabhängig: Das Modell bekommt einen Text, erzeugt eine Antwort und vergisst alles. Was wie Erinnerung aussieht — der Chatverlauf, „das Modell kennt mich“ —, ist Kontext, den die Anwendung bei jedem Aufruf erneut mitschickt.

Ein normaler Inferenzaufruf aktualisiert die Gewichte nicht. Gesprächsgedächtnis entsteht, weil die Anwendung ausgewählte Historie erneut mitsendet oder extern speichert. Das lässt sich testen: Beginnt eine neue Session ohne gespeicherten Zustand, ist die Korrektur verschwunden. Wer dauerhafte Erinnerung verspricht, muss daher Speicherort, Aufbewahrung, Zugriff und Löschung benennen. Preis: Persistenter Zustand verbessert Kontinuität, erweitert aber Datenschutz-, Kosten- und Konsistenzprobleme.

Feintuning: wann es der richtige Hebel ist

Feintuning trainiert ein ausgeliefertes Modell auf eigenen Beispielen nach — heute meist parameter-effizient, also mit wenigen zusätzlichen Gewichten statt vollständigem Neutraining. Es ist stark bei Form und Verhalten: konsistente Ausgabestruktur, Fachsprache, Kürze, ein festes Klassifikationsschema.

Es ist schwach als Wissensspeicher. Fakten, die sich ändern, in Gewichte zu schreiben, heißt: bei jeder Änderung neu trainieren, ohne die Möglichkeit, den alten Stand gezielt zu löschen. Wechselndes Wissen gehört in den Kontext — dort ist es austauschbar, belegbar und abschaltbar.

• Feintuning braucht ein sauberes, repräsentatives Beispielset — die Datenarbeit ist der eigentliche Aufwand.
• Es erzeugt eine eigene Modellversion, die du versionieren, evaluieren und migrieren musst.
• Herkunft und Rechte an den Trainingsbeispielen sind zu klären, bevor trainiert wird — nachträglich ist ein Beispiel aus den Gewichten nicht mehr sauber zu entfernen.

Fine-Tuning verändert Verhalten durch weitere Optimierung an Beispielen. Es passt, wenn viele Fälle dieselbe stabile Form oder Domänensprache verlangen und Prompting allein das Ziel nicht erreicht. Es ist kein bevorzugter Kanal für eine täglich geänderte Preisliste. LoRA reduziert den trainierbaren Anteil gegenüber vollständigem Fine-Tuning, beseitigt aber nicht die Aufgaben: Datensatz kuratieren, Baseline definieren, Regressionen messen, Artefakt versionieren und Rollback vorsehen. Der billigere Trainingslauf ist nicht der ganze Lebenszykluspreis.

Größer ist nicht automatisch besser

Fähigkeit wächst mit Modellgröße und Trainingsdatenmenge, aber nicht beliebig und nicht gleichmäßig über alle Aufgaben. Für eine eng umrissene Aufgabe mit gutem Kontext schlägt ein kleineres Modell regelmäßig ein größeres ohne Kontext — bei einem Bruchteil von Kosten und Latenz.

Modellgröße ist ein Kandidat, kein Abnahmekriterium. Ouyang und Kollegen zeigten in ihrer untersuchten Prompt-Verteilung, dass ein kleineres post-trainiertes Modell menschlich bevorzugte Antworten gegenüber einem wesentlich größeren Basismodell liefern konnte. Das ist kein allgemeines Größengesetz, sondern ein Beleg für Aufgaben- und Trainingsabhängigkeit. Vergleiche Modelle daher auf deinem Eval-Set und miss zusätzlich Latenz und Kosten. Gleich im Check ordnest du acht konkrete Anforderungen der richtigen Schicht zu.