Generative KI erklärt: Modelle, Retrieval, Tools und Anwendungen sind nicht dasselbe

Generative KI ist keine einzelne Komponente. Ein produktives generatives KI-System kombiniert in der Regel ein generatives Modell mit Anwendungscode, der Anweisungen und Kontext bereitstellt, bei Bedarf externes Wissen abruft, Werkzeuge zum Lesen oder Ändern externer Systeme bereitstellt, Laufzeitstatus und Berechtigungen verwaltet und das Ergebnis in ein nutzbares Produkt verwandelt. Modell, Retrieval, Werkzeuge, Kontext, Laufzeit und Anwendung als dasselbe zu behandeln, verdeckt die Grenzen, die Aktualität, Sicherheit, Zuverlässigkeit, Kosten und Kontrolle bestimmen.

Was bedeutet „generative KI“ eigentlich?

Auf Modellebene bezieht sich generative KI auf KI-Modelle, die abgeleitete synthetische Inhalte wie Text, Bilder, Audio, Video, Code oder andere digitale Ausgaben erzeugen. NIST AI 600-1 verwendet diese modellorientierte Bedeutung und diskutiert Risiken separat auf Modell-, System-, Anwendungs- und Anwendungsfall-Ebene.

Diese Unterscheidung ist wichtig, weil ein KI-Modell nicht dasselbe ist wie das vollständige KI-System. Das aktuelle Glossar von NIST definiert ein KI-Modell als eine Komponente, die mithilfe computergestützter, statistischer oder maschineller Lerntechniken aus Eingaben Ausgaben erzeugt, während ein KI-System Software, Hardware, Anwendungen, Werkzeuge oder Hilfsprogramme umfassen kann, die mithilfe von KI arbeiten.

Das einfachste nützliche Modell eines generativen KI-Systems

Stellen Sie sich als erstes mentales Modell einen Unternehmensassistenten vor, der antwortet: „Kann dieser Kunde heute eine Rückerstattung erhalten?“ Eine nützliche Antwort kann mehrere unterschiedliche Verantwortlichkeiten erfordern. Das Sprachmodell kann die Frage interpretieren und die Erklärung schreiben, aber der aktuelle Bestellstatus kann aus einem Datenbankwerkzeug stammen, die Rückerstattungsrichtlinie kann aus dem Dokumentenabruf kommen, Berechtigungen können von der Anwendung durchgesetzt werden, und die endgültige Aktion kann einen kontrollierten API-Aufruf erfordern.

Reale Systeme folgen nicht immer genau dieser Reihenfolge. Retrieval kann vor dem ersten Modellaufruf stattfinden, Werkzeuge können während einer Agentenschleife ausgewählt werden, deterministische Anwendungslogik kann das Modell vollständig umgehen, und Validierung kann in mehreren Phasen erfolgen. Der Punkt ist, Verantwortlichkeiten zu trennen, nicht einen universellen Workflow vorzuschreiben.

Die sechs Grenzen, die zählen

1. Das Modell: Generierung ist seine Kernverantwortung

Ein generatives Modell bildet bereitgestellte Eingaben auf generierte Ausgaben ab. Bei einem Sprachmodell kann das natürlichsprachlichen Text, strukturiertes JSON, Code, Klassifikationen, Zusammenfassungen, Pläne oder Argumente für Werkzeugaufrufe umfassen. Multimodale generative Modelle können mit zusätzlichen Eingabe- und Ausgabetypen arbeiten.

Das Modell kann umfangreiches erlerntes Wissen in seinen Parametern enthalten, aber parametrisiertes Wissen ist keine Live-Datenbank. Das Modell weiß nicht automatisch von einem vor fünf Minuten erstellten Dokument, dem aktuellen Lagerbestand, einem privaten Kundendatensatz oder dem Zustand einer Anwendung, es sei denn, diese Informationen werden über den aktuellen Eingabepfad bereitgestellt.

Deshalb löst ein Wechsel des Modells nicht automatisch veraltetes Wissen, fehlende Berechtigungen, fehlerhaftes Retrieval, falsche Zustandsverantwortung oder unsichere Werkzeugausführung. Diese Fehler gehören oft zu anderen Schichten.

2. Retrieval: Das Auffinden externer Belege ist eine separate Operation

Retrieval wählt Informationen aus einer externen Quelle vor oder während der Generierung aus. Die Arbeit zur Retrieval-Augmented Generation aus dem Jahr 2020 von Lewis et al. machte die Trennung explizit, indem sie ein parametrisches generatives Modell mit abgerufenem nicht-parametrischem Speicher kombinierte. Moderne Produktionssysteme verwenden viele Retrieval-Varianten, aber die architektonische Idee bleibt: Nützliche Belege können zur Inferenzzeit abgerufen werden, anstatt sich nur auf das zu verlassen, was das Modell während des Trainings gelernt hat.

Retrieval kann lexikalische Suche, Embeddings, Vektorsuche, hybride Suche, SQL, Wissensgraphen, Metadatenfilter, APIs oder andere Auswahlmechanismen verwenden. Eine Vektordatenbank ist daher eine mögliche Retrieval-Komponente, nicht die Definition von RAG.

3. Werkzeuge: Zugriff und Aktion sind kein Modellwissen

Ein Werkzeug ist eine Schnittstelle, über die eine KI-Laufzeitumgebung Funktionalität außerhalb des Modells anfordern kann. Ein Werkzeug kann eine Datenbank abfragen, das Web durchsuchen, eine Datei lesen, einen Wert berechnen, einen internen Dienst aufrufen, ein Ticket erstellen, eine Nachricht senden, einen Datensatz ändern oder eine andere kontrollierte Operation auslösen.

Die aktuelle Funktionsaufruf-Dokumentation von OpenAI macht diese Grenze explizit: Funktionsaufrufe ermöglichen es Modellen, mit externen Systemen zu interagieren und auf Daten oder Aktionen zuzugreifen, die von der Anwendung bereitgestellt werden. Das Modell kann einen Aufruf vorschlagen oder auswählen, aber das externe System führt die eigentliche Operation aus.

Die Werkzeugnutzung wirft daher zwei separate Fragen auf: Kann das Modell diese Fähigkeit anfordern? Und wird die Anwendung sie autorisieren und ausführen? Ein Produktionssystem sollte die Absicht des Modells nicht mit der Berechtigung verwechseln, einen Seiteneffekt zu verursachen.

4. Kontext: Was das Modell gerade jetzt sehen kann

Kontext sind die Informationen, die dem Modell für einen bestimmten Inferenzschritt zur Verfügung stehen. Die Kontext-Engineering-Richtlinie von Anthropic beschreibt Kontext als die Menge von Tokens, die beim Sampling von einem LLM einbezogen werden. In der Praxis kann diese Menge Systemanweisungen, Benutzernachrichten, Gesprächsverlauf, abgerufene Belege, Werkzeugdefinitionen, Werkzeugergebnisse, Gedächtniszusammenfassungen und ausgewählten Anwendungszustand enthalten.

Kontext ist daher weder die vollständige Wissensbasis noch das Langzeitgedächtnis. Ein Unternehmen kann zehn Millionen Dokumente speichern, während nur eine Handvoll Passagen in einen Modellaufruf gelangen. Eine Laufzeitumgebung kann ein Jahr Gesprächsverlauf persistieren, während nur die für die aktuelle Aufgabe benötigten Teile offengelegt werden.

Das Kontextfenster schafft auch eine technische Einschränkung. Mehr Text hinzuzufügen garantiert keine bessere Antwort; irrelevante, veraltete, widersprüchliche oder wenig autoritative Informationen können die Belege verwässern, die tatsächlich wichtig sind.

5. Laufzeitumgebung und Orchestrierung: Koordination der Schleife

Die Laufzeitumgebung oder Orchestrierungsschicht koordiniert, wie das Modell an einer Aufgabe teilnimmt. Je nach Architektur kann sie Sitzungen, Modellanfragen, Werkzeugerkennung, Werkzeugaufrufschleifen, Wiederholungsversuche, Übergaben, Streaming-Ereignisse, Timeouts, Checkpoints, Kompaktierung oder Ausführungsumgebungen verwalten.

Einige Laufzeitumgebungen sind dünner Anwendungscode um eine Modell-API. Andere sind vollständige Agent-Harnesse. Eine verwaltete Anbieter-Laufzeitumgebung kann einen Teil der Schleife übernehmen, während die Anwendung weiterhin die Domänenwahrheit, Autorisierung, geschäftliche Seiteneffekte und den Produktlebenszyklus besitzt.

Diese Grenze ist wichtig, weil wo die Laufzeitumgebung läuft und wo die Inferenz läuft separate Entscheidungen sind. Ein lokal laufender Client- oder Agent-Prozess kann dennoch ein entferntes Modell aufrufen, während eine entfernte Anwendung ein Modell aufrufen kann, das auf Infrastruktur unter der Kontrolle der Organisation gehostet wird.

6. Die Anwendung: Wo KI zu einem Produkt wird

Die Anwendung ist die Produktgrenze um die KI-Komponenten. Sie verantwortet die Benutzererfahrung, das Domänenmodell, den aktuellen Zustand, die Identität, den Mandantenbereich, Berechtigungen, Persistenz, Dienstintegrationen, Validierung, Observability, Abrechnungs- oder Kontingentlogik, sofern relevant, sowie die Regeln, die bestimmen, was die KI sehen oder tun darf.

Diese Schicht verwandelt „ein Modell kann nützliche Ausgaben erzeugen“ in „ein System kann eine zuverlässige Fähigkeit bereitstellen“. Dasselbe Modell kann an einem privaten Rechercheassistenten, einem Support-Workflow, einem Code-Agenten oder einer Commerce-Anwendung teilnehmen, weil die umgebende Anwendung die Daten, Werkzeuge, Richtlinien, den Zustand und den Ausführungsvertrag verändert.

Wie die Teile in einer realen Anfrage zusammenwirken

Betrachten Sie einen Support-Assistenten, der gefragt wird: „Erstatte Bestellung 4711, wenn sie noch berechtigt ist, und erkläre warum.“ Die Anfrage kombiniert Wissen, aktuellen Zustand, Autorisierung, Schlussfolgerung und einen Seiteneffekt.

Wenn der Assistent nur über das Sprachmodell verfügt, kann er über Erstattungen sprechen, aber nicht sicher wissen, ob Bestellung 4711 derzeit berechtigt ist, oder die Transaktion durchführen. Wenn er nur über Retrieval verfügt, kann er die Richtlinie finden, aber es fehlt ihm weiterhin der Live-Bestellstatus. Wenn er über Werkzeuge ohne Anwendungsautorisierung verfügt, kann er leistungsfähig, aber unsicher werden. Zuverlässigkeit entsteht durch die Komposition der Schichten mit expliziter Verantwortlichkeit.

Verschiedene KI-Produkte verwenden unterschiedliche Kombinationen

Dies sind Architekturmuster, keine Reifegrad-Rankings. Eine Nur-Modell-Funktion kann das richtige Design sein, wenn die Aufgabe keine externen Fakten oder Aktionen benötigt. Das Hinzufügen von Retrieval, Werkzeugen, Gedächtnis oder einer Agentenschleife ist nur gerechtfertigt, wenn die Aufgabe diese Fähigkeiten erfordert.

Implementierungsnachweis: Aaasaasa AI Client

Aaasaasa AI Client ist ein lokal-first Desktop-KI-Arbeitsbereich, der mit Nuxt 4, Electron und TypeScript erstellt wurde. Sein AI Hub trennt bewusst Agent/Client, Anbieter, Modell, Laufzeitort, Berechtigungen und Webclient, anstatt sie als eine einzige „KI“-Einstellung zu behandeln.

Diese Trennung erzeugt konkretes Verhalten. Direct Chat kann mit Modellen sprechen, ohne Dateisystem- oder Shell-Werkzeuge. Ein Codex-Agent kann einen ausgewählten Arbeitsbereich und ein Berechtigungsprofil verwenden. Ollama kann direkte lokale Inferenz bereitstellen, während LM Studio und konfigurierbare OpenAI-kompatible Endpunkte andere Anbieterpfade darstellen. Ein lokal laufender Codex-Prozess kann dennoch ein Cloud-Modell verwenden, sodass UI und Architektur lokale Laufzeit nicht mit lokaler Inferenz gleichsetzen.

Die Implementierung enthält außerdem Qdrant-/Vektor-Unterstützung, Dokumentenextraktionsfähigkeiten und einen authentifizierten Directory-MCP-Broker. Diese Komponenten veranschaulichen eine weitere Grenze: Retrieval-Infrastruktur und Werkzeugzugriff können im selben Produkt leben, ohne zu Eigenschaften des Modells selbst zu werden.

Häufige Kategorienfehler

Fehlermodi, wenn die Grenzen zusammenbrechen

Grenzfehler sind nicht nur Terminologieprobleme. Sie erzeugen unterschiedliche Produktionsfehler, die unterschiedliche Korrekturen erfordern.

Was ist stabil und was ist versionsabhängig?

Die architektonischen Unterscheidungen in diesem Artikel sind bewusst herstellerneutral. Die aktuellen Beispiele unten sind Implementierungsfakten, die bei der Weiterentwicklung von APIs erneut überprüft werden sollten.

Ein Artikel, der als Quelle der Wahrheit dienen soll, sollte daher beide Ebenen bewahren: stabile Konzepte für die Architektur und datierte Belege für aktuelle Implementierungen. Die Vermischung beider lässt einen Artikel unnötig schnell veralten.

Der KI-Komponentengrenzentest

Wenn Sie eine KI-Funktion bewerten, stellen Sie die folgenden Fragen in dieser Reihenfolge. Die Antworten zeigen, welche Komponenten das System tatsächlich hat und welche Verantwortlichkeiten noch implizit sind.

Was generative KI nicht ist

Generative KI ist nicht gleichbedeutend mit einem LLM, obwohl LLMs eine bedeutende Klasse generativer Modelle sind. Sie ist auch nicht gleichbedeutend mit RAG, einer Vektordatenbank, einem Agenten, einem Tool-Protokoll, einer Chatbot-Oberfläche oder einer Anwendung.

Diese Konzepte können verbunden sein, aber jedes beantwortet eine andere architektonische Frage. Ein LLM fragt, wie Sprachausgabe erzeugt wird. Retrieval fragt, woher externe Belege kommen. Tools fragen, wie externe Fähigkeiten bereitgestellt werden. Kontext fragt, was das Modell sehen kann. Laufzeitumgebung fragt, wie die Ausführung koordiniert wird. Die Anwendung fragt, wie die Fähigkeit zu einem kontrollierten Produkt wird.

Wohin als Nächstes im Wissensgraphen

Sobald diese Grenzen klar sind, lassen sich tiefergehende Themen leichter einordnen. RAG gehört zu Retrieval und Kontextkonstruktion. Retrieval Trigger entscheidet, wann externe Belege erforderlich sind. Agent Memory betrifft das, was über die Zeit hinweg bestehen bleibt. Tool Calling und MCP gehören zum Fähigkeitszugriff. Agent Harnesses gehören zur Laufzeitorchestrierung. RBAC, Mandantentrennung und Domänenautorisierung gehören zur Anwendungs- und Plattformsicherheitsgrenze.

Einschränkungen

Das Sechs-Schichten-Modell ist eine Verantwortungskarte, keine Anforderung, dass jedes Produkt sechs separate Dienste bereitstellen muss. Eine kleine Anwendung kann Kontextkonstruktion, Retrieval und Orchestrierung innerhalb eines Prozesses implementieren. Eine verwaltete Plattform kann mehrere Verantwortlichkeiten hinter einer API bündeln. Die physische Bereitstellung kann kombiniert werden, während die semantische Zuständigkeit getrennt bleibt.

Auch die Terminologie variiert zwischen Anbietern und Forschung. „Agent“, „Runtime“, „Memory“, „Tool“, „Connector“ und „Kontext“ können unterschiedlich definiert werden. Die hier gewählten Definitionen sollen operative Zuständigkeit und Fehlerdiagnose explizit machen, nicht behaupten, dass jedes Framework identische Vokabeln verwendet.

Der Abschnitt Aaasaasa AI Client dokumentiert ein Implementierungsmuster. Er zeigt, dass explizite Grenzen praktikabel sind, beweist aber nicht, dass dasselbe Komponentenlayout für jedes KI-Produkt optimal ist.

Was würde diese Antwort ändern?

Die Verantwortungskarte müsste überarbeitet werden, wenn Modellarchitekturen selbst begannen, autoritativen externen Zustand, Berechtigungen, dauerhafte transaktionale Seiteneffekte und verifizierbaren Quellenzugriff als intrinsische Eigenschaften zu besitzen, statt als Fähigkeiten, die von einem umgebenden System bereitgestellt werden. Aktuelle Produktionsarchitekturen machen das nicht zu einer sicheren allgemeinen Annahme.

Einzelne Implementierungsbeispiele werden sich viel schneller ändern. Gehostete Retrieval-Tools, Agent-APIs, MCP-Integrationen, Kontextmanagement-Funktionen und Anbieterfähigkeiten entwickeln sich schnell. Diese Details sollten aktualisiert werden, ohne die zugrunde liegenden Unterscheidungen zwischen Generierung, Evidenz, Fähigkeitszugriff, Kontext, Ausführung und Anwendungssteuerung aufzulösen.

Fazit

Generative KI lässt sich leichter entwerfen, sobald „die KI“ nicht mehr als eine Blackbox behandelt wird. Das Modell ist die generative Komponente, nicht das vollständige Produkt. Retrieval liefert externe Evidenz. Tools stellen Fähigkeiten bereit. Kontext trägt ausgewählte Informationen in die aktuelle Inferenz. Die Runtime koordiniert die Ausführung. Die Anwendung besitzt die autoritative Produktgrenze.

Diese Trennung ist mehr als eine Erklärung. Sie sagt Ingenieuren, wo veraltete Fakten entstehen, wohin Autorisierung gehört, warum eine lokale Runtime dennoch Cloud-Inferenz nutzen kann, warum RAG nicht gleich einer Vektordatenbank ist, warum Tool-Aufrufe Validierung erfordern und warum ein Modellwechsel nicht jeden Systemfehler beheben kann.

Die dauerhafte Architekturfrage lautet daher nicht „Welches KI-Modell verwenden wir?“ Sie lautet: Welche Verantwortung besitzt jede Komponente, welche Evidenz überschreitet jede Grenze, und welche Schicht darf echten Zustand ändern?

FAQ

Glossar

Primärquellen und Implementierungsnachweise

Die folgenden stabilen Definitionen sind in Standards/Forschung verankert; sich schnell entwickelnde Implementierungsbeispiele verwenden aktuelle offizielle Engineering-Dokumentation. Aaasaasa AI Client ist ein originaler Implementierungsnachweis und wurde gegen seinen Codebase-/Dokumentationsstand vom 26. Juli 2026 geprüft.