High-Level-Architektur

Folgende Darstellung zeigt die High-Level-Referenzarchitektur in 4 Schichten (Layer), die untenstehend näher beschrieben werden.

Offene Standards

Die Referenzimplementierung verfolgt einen konsequenten Cloud-Native-Ansatz und ist für den Betrieb innerhalb von Kubernetes-Clustern optimiert. Um maximale Interoperabilität, Skalierbarkeit und Herstellerunabhängigkeit (Vendor Independence) zu gewährleisten, basiert die Architektur strikt auf etablierten offenen Standards.

Vier Standards bilden dabei das technologische Rückgrat der Plattform:

• OpenAI API (Schema): Dient als universelle Schnittstelle für das Inference-Backend. Sie entkoppelt die anwendenden Services von den konkreten Modellen und ermöglicht den nahtlosen Austausch der darunterliegenden Engines (z.B. vLLM, Azure OpenAI).
• Model Context Protocol (MCP): Standardisiert die Anbindung von externen Datenquellen und Tools. Anstatt proprietärer Integrationen erfolgt der Zugriff auf Fachverfahren oder Datenbanken einheitlich über MCP-Server.
• OpenID Connect (OIDC): Gewährleistet eine sichere, föderierte Authentifizierung und Autorisierung. Identitätsinformationen und Rollen werden standardisiert (z.B. über Keycloak) an die Services weitergereicht.
• OpenTelemetry (OTEL): Schafft vollständige Transparenz (Observability) über die gesamte Aufrufkette hinweg. Es bietet einen herstellerneutralen Rahmen für das Sammeln von Metriken, Logs und Distributed Traces.

Durch die Kombination dieser Standards entsteht eine zukunftssichere und wartungsfreundliche Architektur, die sich nahtlos in bestehende Behörden-IT-Landschaften integrieren lässt und einen "Vendor Lock-in" effektiv vermeidet.

Komponenten der Referenzarchitektur lassen sich in vier Layer einteilen. Eine besondere Herausforderung bei der Implementierung der verschiedenen Komponenten (Building Blocks) innerhalb der Layers liegt in der föderierten Benutzer- und Modell-Verwaltung. Diese wird im Kapitel Datenmanagement beschrieben.

Frontend-Layer

Die Referenzarchitektur sieht verschiedene Frontends vor. Das Frontend-Layer umfasst die Benutzeroberflächen für Administratoren und Endnutzer, welche auf die KI-Dienste zugreifen und sie verwalten können.

Als "offensichtlichste" seien genannt:

• ein Chat-Frontend,
• Fachverfahren
• Office-PlugIn
• ein Admin-Frontend

Alle Frontends können über das API-Gateway auf die verschiedenen Services zugreifen.

Services-Layer

Der Services-Layer umfasst zustandslose, funktionale Bausteine, die zu Use Cases kombiniert werden können. Diese Services sind über das API-Gateway zugänglich, in dem auch eine Service-Registry integriert ist. Darüber hinaus fungiert das API-Gateway als Load Balancer für die Service-Aufrufe.

Folgende erste Servicearten sind identifiziert:

• RAG: Über RAGs können mithilfe domänen-spezifischer Datenquellen die Antworten für einen bestimmten Kontext verbessert werden. Die RAGs können z. B. mit RAGFlow umgesetzt werden. Beispiel: der Service "DocumentSearch".

• MCP-Server bieten einen standardisierten Zugang zu verschiedenen Datenquellen, Prompt-Templates sowie nachfolgend beschriebenen Tools.

• Tools sind verschiedene Werkzeuge, die keinen Zugriff auf Large Language Models benötigen. Beispiele: ein Taschenrechner, Websuche oder das aktuelle Wetter.

• Task based Services stellen auf Basis von LLMs Funktionen zur Verfügung. Beispiele: Summarization, Planning und Reasoning.

• Agents sind Services, die autonom oder semi-autonom eine Aufgabe erfüllen. Die Aufgaben-Steuerung kann entweder durch eine Standard Operating Procedure (SOP) vorgegeben werden oder mittels LLM in einem Planungs-Task erzeugt werden. Ein Agent kann sich dann je nach Aufgabe anderer Services bedienen.

Inference-Layer

Der Inference-Layer ist für die effiziente Bereitstellung und Ausführung der Sprachmodelle verantwortlich. Er umfasst die Inference Server und Engines, die für Latenz und Durchsatz optimiert sind, sowie Mechanismen zur Verwaltung von Ressourcen wie GPU-Speicher oder Batch-Processing. Hier werden auch Optimierungstechniken wie Quantisierung, KV-Cache-Management und Paged Attention eingesetzt, um die Performance zu maximieren. Der Inference-Layer abstrahiert die unterschiedlichen Modellformate (z. B. PyTorch, Safetensors, GGUF) und stellt eine einheitliche Schnittstelle für die Services zur Verfügung.

ML-Layer

Der ML-Layer bildet die unterste Schicht und stellt die eigentlichen Modelle sowie die Trainings- und Fine-Tuning-Umgebungen bereit. Hier werden Basismodelle geladen, angepasst und versioniert. Zudem beinhaltet dieser Layer die Infrastruktur für das kontinuierliche Training, Evaluierung und Monitoring der Modelle. Der ML-Layer sorgt dafür, dass neue Modellversionen nahtlos in den Inference-Layer integriert werden können und unterstützt sowohl Open-Source-Modelle als auch proprietäre Varianten.