agentic-ai llm rag architecture observability

Der Full Stack von Agentic AI, Schicht für Schicht: Vom Frontend bis zur Überwachbarkeit.

Zehn Ebenen hinter einem Produktionsagenten: Frontend, Dateneingang, Aufteilung in Blöcke, Embeddings, Vektorabfrage, Datenabruf, Prompting, der LLM, Bereitstellung und Bewertung.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 202611 Min. Lesezeit2433 Wörter

Quellen: The Full Stack of Agentic AI: From User Interface to Production-Grade Intelligence

Künstliche Intelligenz hat längst den Punkt überschritten, an dem jemand einen Prompt eintippt und eine Antwort liest. Moderne KI-Produkte sind vollständige Softwaresysteme. Sie nehmen Dokumente entgegen, verwandeln unstrukturiertes, chaotisches Material in nutzbare Erkenntnisse, erzeugen Embeddings, holen Kontext ab, kommunizieren mit großen Sprachmodellen, führen Tools aus, laufen innerhalb von Cloud-Infrastrukturen und überwachen ihre eigene Leistung. Das gilt doppelt für agierende KI. Ein Agent ist kein LLM, das in einem Chatfenster gefangen ist. Eine produktionsreife agierende Anwendung benötigt einen ganzen Technologiestack um das Modell herum, wobei das Modell nur eine Schicht darin darstellt.

Ein Referenzarchitekturdiagramm dieses Stacks bietet eine nützliche Übersicht, die vom Frontend über die Aufnahme, das Abrufen und das Formulieren von Prompts bis zu den Modellen, der Bereitstellung und der Überwachung reicht. Die folgenden Abschnitte erläutern jede Schicht, wofür sie dient, warum sie existiert und wie die Tools miteinander verbunden sind.

Die Schichten im Überblick

In dieser Reihenfolge arbeitet der Stack: Frontend, Dokumenteneingabe, Aufteilung in Blöcke und Vorausverarbeitung, Embeddings, Vektordatenbank, Abruf von Informationen, Prompt-Engineering, LLM, Infrastruktur und Bereitstellung sowie schließlich Überwachung und Bewertung.

Diese Abfolge ist kein strenger Prozessablauf. In echten agilen Systemen interagieren die Komponenten ständig miteinander. Ein Agent kann Informationen mehrfach abrufen, externe Tools aufrufen, verschiedene Modelle verwenden, seine eigenen Antworten bewerten und weitere Arbeitsabläufe auslösen, bevor ein endgültiges Ergebnis erzeugt wird. Der Stack lässt sich besser als das Technologieökosystem rund um KI-Systeme verstehen als als einfache Abfolge von Anfrage und Antwort.

Schicht 1: Das Frontend

Jedes KI-System benötigt einen Ort, an dem die Menschen darauf zugreifen können. Die Frontend-Oberfläche präsentiert die Benutzererfahrung – sei es ein Chatbot, ein Unternehmensportal, ein Analyse-Dashboard, ein internes Tool oder eine von KI unterstützte Arbeitsumgebung. Typische Technologiewahlmöglichkeiten sind React, Next.js, Streamlit und Azure App Service. React erstellt interaktive Benutzeroberflächen, während Next.js ein umfassenderes Framework für produktive Webanwendungen ist. Streamlit eignet sich gut, um KI- und Datenanwendungen ohne herkömmliche Frontend-Toolchains schnell zusammenzustellen. Azure App Service bietet verwaltete Hosting-Lösungen für Webanwendungen und APIs.

In einer unternehmensweiten agilen Architektur ist das Frontend mehr als nur ein Chatfeld. Es kann den Fortschritt des Agenten, die von ihm abgerufenen Quellen, den Status des Workflows, die Ergebnisse der Tools, Genehmigungsanfragen, generierte Dokumente sowie Interaktionen mit menschlichen Nutzern anzeigen. Hier wird die KI für die Geschäftsnutzer zugänglich.

Schicht 2: Dokumenteneingang

Ein leistungsstarkes System benötigt Zugang zu relevanten Informationen, und Unternehmenswissen befindet sich selten in einer übersichtlichen Form. Es ist über PDFs, Word-Dateien, Präsentationsfolien, Scans, Webseiten, Datenbanken, E-Mails und vieles mehr verstreut. Die Dokumenteneingangsverarbeitung sammelt und extrahiert den Inhalt aus all diesen Quellen.

Zu diesem Zweck eingesetzte Tools sind Azure AI Content Understanding, Apache Tika, Microsoft Fabric, LangChain sowie OCR-Engines. OCR ist wichtig, wenn sich Informationen in Scans oder Bildern befinden. Apache Tika extrahiert Text und Metadaten aus einer sehr breiten Palette von Formaten. Microsoft Fabric trägt zu umfassenderen Unternehmensdatenworkflows bei, und ein Framework wie LangChain kann Eingangskomponenten in KI-Pipelines integrieren.

Das Ziel ist einfach: Verstreute Unternehmensinformationen in Inhalte umwandeln, die von Maschinen verarbeitet werden können. Ohne eine zuverlässige Eingabeschicht wird selbst das fortschrittlichste Modell Schwierigkeiten haben, aussagekräftige Antworten über Ihre Organisation zu liefern.

Schicht 3: Aufteilung in Blöcke und Vorausverarbeitung

Das Extrahieren von Text ist erst der Anfang. Ein 200-seitiges Dokument kann nicht vollständig in jede Modellanfrage eingefügt werden, daher müssen große Dokumente in kleinere, sinnvolle Einheiten aufgeteilt werden. Diese Blöcke können Absätze, Abschnitte, Seiten oder semantische Einheiten sein, und Frameworks wie LangChain bieten verschiedene Strategien zur Aufteilung in Blöcke an.

Gutes Chunking bedeutet mehr als das Abschneiden alle paar hundert Zeichen, denn schlechtes Chunking zerstört den Kontext. Wenn eine Definition von der Erklärung getrennt wird, die ihr Bedeutung verleiht, kann die Wiederherstellung unvollständige Ergebnisse liefern. Zu große Chunking-Einheiten führen zu ungenauen Wiederherstellungen, während zu kleine Einheiten wichtige Beziehungen verlieren. Die Strategie beeinflusst daher direkt die Qualität aller nachfolgenden Schritte.

Das Vorkonvertieren umfasst das Reinigen, das Entfernen unnötiger Inhalte, die Normalisierung von Formaten, das Extrahieren von Metadaten, die Erkennung der Dokumentstruktur sowie die Ergänzung der Chunking-Einheiten mit zusätzlichen Informationen. In diesem Schritt wird oft bereits entschieden, wie gut die spätere Wiederherstellung funktionieren wird.

Layer 4: Embeddings

Sobald die Dokumente in Chunking-Einheiten aufgeteilt sind, benötigt das System eine Methode, um deren Bedeutung festzuhalten. Ein Embedding-Modell wandelt Text in einen numerischen Vektor um, wodurch ähnliche Konzepte im Embedding-Raum in der Nähe voneinander liegen.

Vergleichen Sie eine Anfrage zur Zurücksetzung des Passworts eines Mitarbeiters mit einer Anfrage nach der Änderung der Arbeitsanmeldedaten. Die Formulierung unterscheidet sich, doch der Zweck ist ähnlich, und ein gutes Embedding-Modell erkennt das. Zu den für diese Schicht genannten Anbietern gehören OpenAI, Cohere sowie auf Azure basierende KI-Dienste. Die resultierenden Vektoren bilden die Grundlage für die semantische Suche und -abrufung, was diese Entwicklung zu einer der bedeutendsten im gesamten Stack macht: Die menschliche Sprache wird zu einer mathematischen Darstellung, und diese Darstellung ermöglicht die Erfassung semantischer Ähnlichkeiten.

Schicht 5: die Vektordatenbank

Embeddings müssen an einem Ort gespeichert werden, der eine schnelle Ähnlichkeitssuche ermöglicht – genau das ist die Aufgabe der Vektordatenbank. In der Darstellung werden Milvus, FAISS, Azure AI Search, Azure Cosmos DB sowie Azure Database for PostgreSQL aufgeführt. Sie unterscheiden sich stark in ihren Funktionen und im Bereitstellungsmodell, doch alle zielen auf eine effiziente Auffindung durch semantische Ähnlichkeiten ab.

Wenn ein Benutzer eine Frage stellt, wird die Anfrage selbst in ein Embedding umgewandelt, und das System sucht nach den nächstgelegenen Vektoren. Die entsprechenden Abschnitte werden anschließend an die nachfolgenden Schichten weitergeleitet. Dies bildet die Grundlage der meisten retrieval-augmented generation-Systeme.

Schicht 6: die Abrufschicht

Eine Vektordatenbank speichert Informationen, doch die Abrufschicht entscheidet, was tatsächlich dem Modell angezeigt wird. Dieser Unterschied kann leicht übersehen werden. Der Abruf kann auf semantischer Ähnlichkeit, Schlüsselwortsuche, Metadatenfilterung, hybriden Suchverfahren, Neuranking sowie anderen Techniken beruhen, und Tools wie Azure AI Search, LangChain und LlamaIndex decken diese Ansätze ab.

Eine ausgereifte Lösung kombiniert verschiedene Strategien. Die semantische Suche findet konzeptionell verwandtes Material, während die Schlüsselwortsuche sicherstellt, dass genaue Identifikatoren, Produktnamen, Policenummern oder technische Begriffe nicht übersehen werden. Dies ist eine hybride Suchmethode, und unternehmensweite RAG-Lösungen fügen zunehmend Metadatenfilter, Neuranking-Verfahren, Wissensgraphen sowie weitere Mechanismen hinzu.

Das Ziel ist es nicht, so viel wie möglich zu finden, sondern die richtigen Informationen zu erhalten.

Layer 7: Prompt-Engineering

Nach der Suche muss das System eine gute Anweisung für das Sprachmodell erstellen. Ein Produktionsprompt ist weit mehr als nur die Frage des Benutzers. Er kann Systemanweisungen, den gefundenen Kontext, das Gesprächsverlauf, Geschäftsregeln, Anforderungen an das Ausgabeformat, Sicherheitsbeschränkungen, Beispiele, Tool-Definitionen sowie Metadaten enthalten. LangChain, Promptify und DSPy sind Beispiele für Tools, die dabei helfen, solche Prompts zu strukturieren und anzupassen.

Die Prompt-Engineerung geht auch über das manuelle Erfinden cleverer Formulierungen hinaus. Der Fokus verschiebt sich auf das Kontext-Engineering, das eine breitere Frage stellt: Was soll das Modell erhalten, in welcher Struktur und zu welchem Zeitpunkt im Workflow? Das ist umso wichtiger für Agenten, die den Kontext dynamisch aus früheren Aktionen, abgerufenem Material, Tool-Ausgaben und Zwischenergebnissen erstellen können.

Layer 8: das LLM

Im Zentrum steht das große Sprachmodell, in dem Sprachverständnis, Schlussfolgern, Generierung und Befolgung von Anweisungen stattfinden. Zu den genannten Plattformen und Modellen gehören Azure, OpenAI, LLaMA und Mistral AI. Das Modell erhält die Anfrage zusammen mit sorgfältig vorbereitetem Kontext und Anweisungen.

Ein Prinzip verdient es, wiederholt zu werden: Das LLM ist nicht die gesamte Anwendung. Es handelt sich dabei um einen Komponenten innerhalb eines weitaus größeren Systems, und eine Produktionsanwendung benötigt zusätzlich Funktionen zur Informationsabrufung, Orchestrierung, Sicherheit, Bewertung, Überwachung, Infrastruktur sowie Geschäftslogik. Das wird besonders deutlich, wenn man von einem Prototypen zu einer unternehmensweiten Produktionsumgebung übergeht.

Von LLM-Anwendungen zu Agenten

Es ist hilfreich, eine herkömmliche LLM-Anwendung von einer agentbasierten zu unterscheiden. Eine einfache Anwendung umfasst Benutzer, Prompt, LLM und Antwort. Eine RAG-Anwendung umfasst Benutzer, Informationsabrufung, Kontext, LLM und Antwort. Ein agentbasiertes System ist hingegen weitaus dynamischer: Benutzer, Agent, Planung, Informationsabrufung, Tools, LLM, Bewertung, weitere Aktionen, endgültige Antwort. Der Agent entscheidet selbst, was als Nächstes getan werden soll, anstatt einfach einer festgelegten Abfolge zu folgen.

Nehmen wir an, jemand fragt, warum der Produktionspipeline von gestern fehlgeschlagen ist und was dagegen unternommen werden soll. Ein Agent kann die Ausführungshistorie abrufen, Protokolle überprüfen, Datenbanken abfragen, Fehlermeldungen analysieren, betriebliche Richtlinien konsultieren, eine wahrscheinliche Ursache ermitteln und gegebenenfalls eine genehmigte Lösung empfehlen oder ausführen. Das unterscheidet sich grundlegend von der Erstellung eines Textabsatzes.

Layer 9: Infrastruktur und Bereitstellung

Ein poliertes Prototyp macht noch kein für die Produktion bereites Produkt. Die Einführung in die Produktion erfordert skalierbare Infrastruktur, Netzwerktechnologien, Sicherheitsmaßnahmen, Automatisierung der Bereitstellung, Ressourcenverwaltung sowie Widerstandsfähigkeit. Zu den verwendeten Architekturen gehören Azure Container Apps, Azure Kubernetes Service, Docker und Kubernetes.

Docker packt Anwendungen in portable Container. Kubernetes orchestriert containerisierte Arbeitslasten in verteilten Umgebungen. Azure Kubernetes Service ist ein verwaltetes Kubernetes-Angebot, und Azure Container Apps vereinfacht das Bereitstellen von Containern, ohne dass man die gesamte Kubernetes-Umgebung verwalten muss.

Diese Schicht ist wichtig, wenn ein System mit hohem Benutzerverkehr, vielen gleichzeitigen Workflow-Prozessen, Lasten durch Modellinferenz, Hintergrundverarbeitung, Pipelines zur Einholung von Dokumenten, langlaufenden Aufgaben, Integrationen mit externen Tools sowie Anforderungen an die Unternehmenssicherheit umgehen muss. Ein Modell mag hervorragend sein, doch die Infrastruktur entscheidet darüber, ob diese Leistungskraft zuverlässig in großem Maßstab bereitgestellt werden kann.

Schicht 10: Überwachbarkeit und Bewertung

Die Beobachtbarkeit gehört zu den am meisten vernachlässigten Aspekten der KI-Entwicklung. Traditionelle Anwendungen lassen sich anhand der CPU-Nutzung, des Speichers, der Latenz, der Fehler und der Anfragenrate überwachen. KI-Anwendungen benötigen jedoch mehr. Die Teams müssen erkennen können, was das Modell erhalten hat, was abgerufen wurde, welche Tools verwendet wurden, welche Entscheidungen daraus resultierten, wie lange jede Schritt dauerte, wie viele Tokens verwendet wurden und ob die endgültige Antwort hilfreich war.

Hier kommen Azure AI Foundry, OpenTelemetry und Grafana ins Spiel. OpenTelemetry sammelt Telemetriedaten aus verteilten Anwendungen, während Grafana betriebliche sowie anwendungsbezogene Metriken visualisiert.

Die Bewertung ist eine weitere Dimension. Produktionsysteme benötigen möglicherweise Bewertungen hinsichtlich Relevanz, Fundiertheit, Halluzinationen, Qualität der Informationsabrufung, Latenz, Kosten, Sicherheit und Kundenzufriedenheit. Agenten heben die Anforderungen, da auch ihre Aktionen zusammen mit der endgültigen Antwort bewertet werden müssen:

Hat es das richtige Tool gewählt?
Hat es die richtigen Informationen abgerufen?
Hat es unnötige Aufrufe von Tools vorgenommen?
Hat es den korrekten Arbeitsablauf befolgt?
Hat es nach Abschluss der Aufgabe aufgehört zu arbeiten?
Hat es bei Bedarf an menschlichem Eingreifen richtig reagiert?

Diese Fragen machen Beobachtbarkeit und Bewertung zu unverzichtbaren Bestandteilen der Entwicklung von KI-Systemen in der Produktion.

Warum die gesamte Architektur wichtig ist

Ein häufiger Irrtum besagt, dass das Erstellen einer KI-Anwendung darin besteht, ein leistungsstarkes LLM auszuwählen und eine Benutzeroberfläche hinzuzufügen. Das kann für eine Demo funktionieren, spiegelt aber selten wider, was eine Unternehmens-KI-Plattform erfordert.

Betrachten wir den Fall, dass ein Mitarbeiter einen Assistenten nach der Richtlinie des Unternehmens zur Behandlung eines bestimmten Kundenproblems fragt. Das System muss die Anfrage verstehen, die richtigen Richtliniedokumente finden, die relevanten Abschnitte herausfiltern, sie dem Modell zur Verfügung stellen, eine fundierte Antwort erstellen – gegebenenfalls die Quelle angeben –, Sicherheitsrichtlinien durchsetzen, die Interaktion überwachen und beurteilen, ob die Antwort nützlich war. Jede Schicht spielt eine Rolle: Die Frontend-Schicht ermöglicht die Interaktion, die Eingabeschicht liefert das Wissen, die Vorausverarbeitung macht es nutzbar, die Embeddings erfassen die Bedeutung, die Vektordatenbanken speichern suchbare Repräsentationen, die Abrufschicht findet den Kontext, die Prompting-Schicht strukturiert die Anfrage, das LLM erzeugt die Antwort, die Infrastruktur gewährleistet Skalierbarkeit und Zuverlässigkeit und die Überwachungsfunktionen bieten Transparenz und Rechenschaftspflicht. In diesem Sinne ist moderne KI vollständig integriert.

Werkzeuge auswählen

Die Technologien in der Referenzarchitektur bilden keine Checkliste, die vollständig übernommen werden muss. Jede davon ist eine Option für ihre jeweilige Schicht. Ein Unternehmen könnte beispielsweise von vornherein React und Next.js wählen, Azure AI Content Understanding zur Verarbeitung von Dokumenten, LangChain zur Orchestrierung, ein gehostetes Embedding-Modell, Azure AI Search zur Suche sowie ein auf Azure bereitgestelltes Modell und Azure Container Apps, um alles zu betreiben. Ein anderes Unternehmen könnte hingegen eine völlig andere Kombination wählen.

Die wichtigste Erkenntnis ist, dass die Architektur vor den Tools kommt. Die Geschäftsanforderungen prägen die Architektur, diese wiederum bestimmt die Funktionen, die jede Schicht benötigt, und erst danach sollten spezifische Technologien ausgewählt werden.

Mehr als nur ein LLM

Die Vollstreckenansicht erklärt außerdem, warum agentbasierte Projekte schnell kompliziert werden. Ein Agent benötigt möglicherweise Unternehmenswissen über RAG, strukturierte Daten aus Datenbanken, externe Informationen über APIs, operative Fähigkeiten durch Tools sowie die Ausführung von Workflows über Orchestrierungssysteme. Zudem braucht er Schutzmechanismen: Authentifizierung und Autorisierung, Kontrollen zur Datensicherheit, Schutz vor Prompt-Injection, Berechtigungen für Tools, Schritte zur menschlichen Freigabe, Audit-Spuren und Bewertungsrahmenwerke.

Agentebasierte KI befindet sich somit an der Schnittstelle mehrerer Disziplinen: Softwareentwicklung, Datenengineering, KI-Engineering, Cloud-Engineering, Sicherheit und Observabilität. Die Entwicklung von Produktionsagenten stellt eine ingenieurtechnische Herausforderung dar und ist nicht nur ein Übungsfeld für das Verfassen von Prompts.

Wie sich die Anwendungsarchitektur entwickelt hat

Die Branche hat verschiedene Entwicklungsstufen durchlaufen. Frühe KI-Anwendungen waren modellzentriert. RAG verband anschließend Modelle mit externem Wissen. Durch toolergänzte Systeme konnten Modelle mit externen Funktionen interagieren. Heute kombiniert agierende KI Modelle, Informationsabruf, Tools, Speicher, Planung, Orchestrierung und Bewertung. Der Fortschritt verläuft von einfachen LLMs über RAG bis hin zum Einsatz von Tools, zu Agenten und zu mehreren Agentensystemen – und je weiter es fortschreitet, desto wichtiger wird die zugrundeliegende Infrastruktur.

Wo anzufangen

Nicht jede Anwendung benötigt den gesamten Stack. Ein einfaches Frage-Antwort-Tool kann mit einem grundlegenden LLM auskommen. Wenn die Anwendung auf privaten oder häufig wechselnden Kenntnissen angewiesen ist, fügen Sie RAG hinzu. Wenn Beziehungen zwischen Entitäten im Mittelpunkt des Problems stehen, sollten Sie eine auf Graphen basierende Suche in Betracht ziehen. Wenn das System Aufgaben planen, Werkzeuge auswählen, mehrere Schritte ausführen und spontan Entscheidungen treffen muss, eignet sich agierende KI besser.

Das Ziel sollte nicht die aufwendigste Architektur sein, sondern die einfachste, die das Problem zuverlässig löst.

Was kommt als Nächstes

Das Feld entwickelt sich weiter. Wissensgraphen, Vektordatenbanken, Agentenframeworks, Workflow-Engine, multimodale Modelle, Bewertungstools und Cloud-Plattformen werden voraussichtlich enger miteinander verbunden werden. Anwendungen werden neben Text auch Bilder, Audio, Video, strukturierte Daten, Unternehmenssysteme sowie reale Workflows verarbeiten. Das Beobachten und Bewerten eines Systems wird genauso wichtig sein wie die Auswahl des passenden Modells. Was vor uns liegt, dreht sich weniger um intelligentere Modelle allein, sondern vielmehr um zuverlässige Systeme, die auf ihnen aufbauen.

Die Schlussfolgerung

Agentic AI ist keine einzelne Technologie, sondern ein komplettes Ökosystem. Vom Frontend, über das die Benutzer interagieren, bis hin zur Erfassung und Vorbereitung der Daten, Embeddings und Vektordatenbanken, der Suche und Anweisungsgabe sowie schließlich zu LLMs, der Bereitstellung und Überwachung – jede Schicht prägt die Intelligenz, die das System letztendlich zeigt. Das LLM ist nur ein Teil davon. Ein für die Produktion geeignetes agantisches System benötigt die richtigen Daten, eine geeignete Suchstrategie, Orchestrierungsmöglichkeiten, Infrastruktur sowie Methoden zur Bewertung. Wie leistungsfähig die Modelle sind, spielt eine geringere Rolle als die Qualität der umgebenden Systeme.