Von LLMs zu Systemen: ein Vier-Schichten-Blueprint für produktive KI

Heute wiederholt sich dasselbe Muster bei Large Language Models. Training und Deployment eines Modells sind auf einen API-Aufruf geschrumpft – das umgebende System ist jedoch komplexer geworden als je zuvor.

Dieser Artikel stellt eine Vier-Schichten-Architektur für produktive KI-Anwendungen vor: LLM, Harness, Grounding Layer und Use Case.

Das Modell ist nur eine Schicht. Produktive KI lebt in den anderen drei.

Einleitung

Jede große Technologiewelle beginnt mit einer vereinfachenden Annahme. Im Machine Learning war es die Annahme, bessere Modelle würden ganz von selbst zu besseren Ergebnissen führen. In der Praxis genügte die Modellqualität allein nie. Produktive Systeme erforderten Datenpipelines, Validierung, Deployment, Monitoring und Governance. Das Modell war wichtig, aber nur eine Komponente eines weit größeren Systems.

Dasselbe Muster zeichnet sich nun bei Large Language Models ab. Weil die Modelle über eine API zugänglich sind, nahmen Entwicklerinnen und Entwickler an, der Bau intelligenter Anwendungen sei unkompliziert geworden. Tatsächlich ist die Komplexität nicht verschwunden – sie hat sich verlagert. Die Herausforderung liegt jetzt in der Architektur rund um das Modell: wie Kontext zusammengestellt wird, wie Tools orchestriert werden, wie die Nutzerabsicht interpretiert wird und wie Ausgaben zuverlässig gemacht werden.

MLOps vor einem Jahrzehnt: Das Problem ist nicht das Modell

Im Jahr 2015 machte die Arbeit „Hidden Technical Debt in Machine Learning Systems" deutlich, dass das Modell nur ein kleiner Teil produktiver ML-Systeme ist (siehe Diagramm unten). Der Großteil der Komplexität steckt in der umgebenden Infrastruktur: Datenerfassung, Validierung, Feature-Extraktion, Konfiguration, Prozesssteuerung, Serving und Monitoring. Ist das umgebende System schwach, spielt das Modell keine Rolle.

Diese Erkenntnis stellte infrage, wie Organisationen investierten. Sie konzentrierten sich stark auf das Experimentieren mit Modellen und unterschätzten zugleich den Aufwand, der nötig ist, um Modelle in der realen Welt vertrauenswürdig zu machen. Die Schwierigkeit von ML lag nicht darin, ein Modell einmal zu trainieren, sondern darin, ein lebendiges System voller verborgener Abhängigkeiten zu pflegen.

Sculley und Co-Autoren zeigten, dass ML-Systeme eine gefährliche Art technischer Schulden tragen: Modelle sind mit Datenpipelines, Feature-Engineering und Serving-Umgebungen verflochten, sodass sich kleine Änderungen unvorhersehbar fortpflanzen. MLOps entstand, um diese Komplexität zu beherrschen – durch reproduzierbare Pipelines, Versionierung, Deployment, Monitoring, Retraining und Governance. Es machte ML nicht einfach, aber operativ handhabbar.

Dasselbe Muster heute

Large Language Models haben verändert, wo die Komplexität sitzt – nicht aber die Tatsache, dass sie existiert.

Im klassischen ML mussten Organisationen ihre eigenen Modelle trainieren, deployen und bereitstellen. Bei LLMs wird ein Großteil dieser Last ausgelagert, was die Illusion erzeugt, der schwierige Teil sei verschwunden. Tatsächlich ist er nach oben in die Anwendungsschicht gewandert.

Aus der alten Herausforderung, ein Modell zu operationalisieren, ist die neue Herausforderung geworden, ein Reasoning-System zu operationalisieren. Traditionelle Modelle erzeugten oft eng begrenzte, strukturierte Ausgaben. LLMs erzeugen freie Sprache, treffen Entscheidungen und verhalten sich nicht-deterministisch.

Sie befähigen Agenten dazu, Dokumente zu durchsuchen, Daten abzufragen, Datensätze zu aktualisieren, Workflows auszulösen und Subagenten über mehrere Schritte hinweg zu koordinieren. An diesem Punkt braucht das System eine Architektur, nicht nur Prompting. Der glanzvolle Teil ist nach wie vor das Modell. Der schwierige Teil ist nach wie vor das Drumherum.

Die vier Schichten wirksamer Agenten

Produktive KI-Systeme lassen sich als vier Schichten verstehen: LLM, Harness, Knowledge Graph und Use Case.

1. Die LLM-Schicht

Das LLM ist die denkende Schicht beziehungsweise die Reasoning-Engine des Agenten. Es interpretiert natürliche Sprache, generiert Text und bestimmt den nächsten Schritt in der Schleife des Agenten.

Seine Rolle ähnelt der eines traditionellen ML-Modells in einem Produktivsystem: Das Modell liefert die Vorhersage, während die umgebende Infrastruktur diese Vorhersage nützlich, zuverlässig und steuerbar macht. Ebenso liefert das LLM die Reasoning-Fähigkeit des Agenten, ist aber auf die umgebenden Schichten angewiesen, um dieses Reasoning zu verankern, zu lenken und zu operationalisieren.

Das LLM ist das Gehirn des Agenten, aber nicht das gesamte System.

2. Die Harness-Schicht

Die Harness ist die operative Schicht rund um das Modell. Sie regelt, wie sich der Agent zur Laufzeit verhält. Sie ist es, die das LLM von einer Allzweck-Reasoning-Engine in eine kontrollierte Anwendungskomponente verwandelt.

Die Harness bestimmt, welche Tools oder MCPs der Agent aufrufen oder mit denen er verbunden werden darf. Sie setzt Guardrails durch, die verhindern, dass das Modell über akzeptable Grenzen hinaus abdriftet. Sie verwaltet das Konversationsgedächtnis: was der Agent über mehrere Gesprächsschritte hinweg behält, was er verwirft und wie frühere Interaktionen das nachfolgende Reasoning prägen.

Wenn das LLM der Motor ist, ist die Harness die Steuerungsebene (Control Plane). Hier liegt zugleich der Großteil der technischen Komplexität eines produktiven Agenten – und hier entscheidet sich letztlich der Unterschied zwischen einer beeindruckenden Demo und einem zuverlässigen System.

3. Die Grounding-Schicht

Jeder Agent – ob konversationell oder in einen Prozess eingebettet – ist auf Kontext angewiesen, um zuverlässig zu arbeiten. Ohne ihn wird selbst ein leistungsfähiges Modell halluzinieren, die Absicht falsch deuten oder Ausgaben erzeugen, die flüssig, aber operativ falsch sind.

Die Grounding-Schicht stellt diesen Kontext zusammen, bevor das Modell zum Reasoning aufgefordert wird. Sie löst zwei Probleme.

Das erste ist die Auflösung der Absicht (Intent Resolution). Nutzer drücken sich verkürzt und mit impliziten Bezügen aus: „Zeig mir die Zahlen des letzten Quartals für das Hamburg-Projekt" erfordert, dass das System auflöst, welches Projekt, welche Kennzahlen und welcher Zeitraum gemeint sind. Die Grounding-Schicht übersetzt unzureichend spezifizierte Anfragen in die präzisen Entitäten, die Enterprise-Systeme benötigen. In autonomen Szenarien ist die entsprechende Herausforderung nicht die menschliche, sondern die systemische Mehrdeutigkeit: uneinheitliche Benennungen, veraltete Datensätze oder widersprüchliche Definitionen über Quellen hinweg.

Das zweite ist die Strukturierung des Kontexts. Enterprise-Daten, die über Datenbanken, Dokumenten-Repositories und interne APIs verteilt sind, liegen selten in einem Format vor, das zuverlässiges Reasoning unterstützt. Die Grounding-Schicht legt fest, wie diese Informationen repräsentiert werden, bevor sie das Modell erreichen: als Rohtext, strukturiertes JSON, Graph-Triples oder verdichtete natürliche Sprache. Diese Formatentscheidungen wirken sich unmittelbar auf die Qualität der Agentenausgabe aus.

Die Grounding-Schicht bereitet den Kontext auf; die Harness-Schicht liefert ihn aus.

Ein Knowledge Graph ist ein besonders wirksamer Weg, diese Schicht zu operationalisieren, weil er Probleme adressiert, die einfachere Retrieval-Methoden ungelöst lassen. Während schlüsselwortbasiertes Retrieval Dokumente zurückgibt, die die Antwort enthalten können oder auch nicht, kodiert ein Knowledge Graph Entitäten, Attribute und Beziehungen explizit. Damit löst er Zuordnungen wie „Hamburg-Projekt" direkt zur Projekt-ID auf und stellt eine konsistente semantische Schicht (Semantic Layer) über fragmentierten Enterprise-Quellen bereit.

4. Die Use-Case-Schicht

Die Use-Case-Schicht ist die Anwendung selbst: der Workflow, die Schnittstelle, die Ziele und die Einschränkungen, die den geschäftlichen Wert definieren.

Diese Schicht bestimmt, worauf der Agent optimieren soll, welche Aktionen er ausführen darf, welches Maß an Unsicherheit akzeptabel ist und was protokolliert, geprüft oder blockiert werden muss. Unterschiedliche Use Cases können auf demselben zugrunde liegenden Stack aufsetzen, erfordern aber unterschiedliche Verhaltensweisen und Kontrollen.

Doch wie schon vor einem Jahrzehnt beginnen viele Teams beim Modell und definieren das Problem erst später. Wirksame Systeme gehen den umgekehrten Weg. Der Use Case definiert die Anforderungen, und diese bestimmen, welches Wissen benötigt wird, wie sich die Harness verhalten soll und wie das Modell zu nutzen ist.

Fazit

Vor einem Jahrzehnt lernte die ML-Branche, dass das Modell nur ein kleiner Teil des Produktivsystems ist. Alles drumherum – Datenpipelines, Deployment, Monitoring, Governance und Betrieb – entscheidet darüber, ob es Wert schafft oder technische Schulden anhäuft.

Dieselbe Lektion kehrt nun mit LLMs zurück. Die heutigen Systeme sind konversationeller, dynamischer und täuschend einfach. Weil das Modell über eine API zugänglich ist, verwechselt man Zugänglichkeit leicht mit Vollständigkeit. Doch die eigentliche Komplexität ist nicht verschwunden. Sie hat sich in das Design der Harness, die Wissensrepräsentation und die Use-Case-spezifische Steuerung verlagert.

Die wirksamsten KI-Anwendungen werden nicht allein durch die Leistungsfähigkeit des Modells bestimmt. Sie werden auf einem bewusst gewählten Stack aufgebaut: das LLM für Entscheidungen, die Harness für die Orchestrierung, die Grounding-Schicht für den Kontext und der Use Case für den Wert.