KI-Systemarchitektur verständlich erklärt

Wie LLM, API, RAG, Memory, Agenten, Datenbanken, Tools, MCP, Queues und klassische Software zu belastbaren Systemen zusammenfinden

Fakten- und Recherchestand: 8. August 2026 Version: 1.0 Autor: Andreas Rüdiger Räumlicher Schwerpunkt: Deutschland / Europäische Union; technische Quellen international Zielgruppe: Unternehmer, Entscheider, Fachanwender, Entwickler, Berater und Projektverantwortliche Quellenbasis: 126 dokumentierte Primär-, Forschungs-, Standard- und offizielle Produktquellen Vorgesehener Dateiname: 13_ki-systemarchitektur-verstaendlich-erklaert-faktendossier_2026-08-08

Management-Zusammenfassung

KERNAUSSAGE: Die wichtigste Aussage dieses Dossiers lautet: Eine KI-Anwendung ist kein Modell mit Oberfläche, sondern ein verteiltes Softwaresystem. Das Modell verarbeitet bereitgestellten Kontext und erzeugt probabilistische Ausgaben. Verbindliche Daten, Rechte, Prozesszustände, Fehlerbehandlung und Nachweise müssen außerhalb des Modells organisiert werden. ^{[S-002; S-075; S-116]}

ARCHITEKTUR-SYNTHESE: Für viele praktische Anwendungen reicht eine Schichtenlogik: Fachprozess und Benutzeroberfläche, Anwendungs- und Orchestrierungsschicht, Modellzugang, Retrieval/Tools/Memory, Daten- und Integrationsschicht sowie Querschnittskontrollen für Identität, Sicherheit, Evaluation, Observability und Kosten. Diese Trennung macht sichtbar, welches Bauteil welches Problem löst und wo ein Ausfall entstehen kann. ^{[S-067; S-123; S-098; S-025]}

``mermaid flowchart TB U[Nutzung und Fachprozess] --> A[Anwendung und Orchestrierung] A --> G[KI-Zugang / Modellgateway] G --> M[LLM oder VLM] G --> R[Retrieval und Reranking] G --> T[Tools und MCP] G --> X[Memory] R --> D[Datenbanken, Indizes, Objektspeicher] T --> I[CRM, ERP, E-Mail, Dateien, APIs] A --> Q[Queues, Events, Workflows] S[Identität, Sicherheit, Evals, Observability, Kosten] --- A S --- G S --- D ``

Welches Bauteil löst welches Problem?

Die entscheidenden Trennlinien

• Das Modell formuliert; das System of Record entscheidet, welche Daten gelten. ^{[S-002; S-075]}
• Structured Output begrenzt die Form; fachliche Validierung prüft den Inhalt. ^{[S-059; S-057]}
• Tool Calling schlägt eine Aktion vor; die Anwendung prüft und führt aus. ^{[S-054; S-115]}
• RAG liefert externe Informationen; Autorisierung entscheidet, welche davon ein Nutzer sehen darf. ^{[S-014; S-110]}
• Workflow steuert bekannte Abläufe; ein Agent wird nur für offene Pfade eingesetzt. ^{[S-071; S-038]}
• MCP standardisiert Kommunikation; Trust und Security bleiben gesonderte Aufgaben. ^{[S-060; S-062]}
• Memory speichert ausgewählte Erinnerungen; ein Chatverlauf ist nur Rohmaterial. ^{[S-048; S-051]}
• TLS schützt Transport; Least Privilege, Logging und Datenkontrollen schützen den Betrieb. ^{[S-105; S-110; S-109]}

Wann überhaupt keine KI nötig ist

ARCHITEKTUR-SYNTHESE: Wenn eine Aufgabe durch feste Formeln, Pflichtfelder, eindeutige Regeln, bekannte Zustände oder exakte Datenbankabfragen vollständig beschrieben werden kann, ist klassische Software meist leichter zu testen, günstiger und auditierbarer. KI sollte nur den Anteil übernehmen, in dem Sprache, Mehrdeutigkeit, unstrukturierte Dokumente oder offene Recherche tatsächlich einen Mehrwert erzeugen. ^{[S-072; S-071; S-040]}

``mermaid flowchart TD A{Durch Regeln/Formeln vollständig beschreibbar?} A -->|Ja| B[Klassische Software / DMN / Workflow] A -->|Nein| C{Sprache, unstrukturierte Inhalte oder Mehrdeutigkeit?} C -->|Schritte bekannt| D[Workflow mit begrenztem KI-Schritt] C -->|Pfad offen| E[Begrenzter Agent] B --> F[Rechte, Tests, Audit] D --> F E --> F ``

Praktische Leitlinie: Beginne nie mit der Frage „Welches Modell nehmen wir?“. Beginne mit Daten, Fehlerfolge, Reversibilität, Nutzerrechten und Erfolgskriterien. Erst danach wird entschieden, ob ein Modell überhaupt benötigt wird. ^{[S-116; S-122; S-072]}

Methodik, Evidenzhierarchie und Recherchegrenzen

METHODIK: Das Dossier basiert auf fünf Quellenklassen: Originalforschung, offizielle Standards und RFCs, Behörden- und Sicherheitsdokumente, offizielle Projektdokumentation sowie Rechtsquellen. Anbieterangaben werden ausschließlich für Funktions- und Protokollstände genutzt, nicht als unabhängiger Nachweis von Produktivität oder Qualität. ^{[S-045; S-116; S-067]}

AKTUALITÄT: Der Stichtag ist der 8. August 2026. Besonders schnelllebig sind MCP, Modell- und Tool-APIs, Kontext- und Cachingmechanismen, Open-Source-Serving, Agentenbenchmarks sowie OpenTelemetry-GenAI-Semantik. Sie werden im Refresh-Kapitel gesondert markiert. ^{[S-061; S-124; S-091]}

DATUMSREGEL: Bei offiziellen Dokumentationen ohne verlässliches Veröffentlichungsdatum wird das Datum ausdrücklich als UNKLAR ausgewiesen und durch das Prüfdatum ersetzt. Es wird kein Datum geraten. ^{[S-054; S-055; S-056]}

RECHERCHEGRENZE: Das Dossier ist keine Produktauswahl und enthält keine individuellen Architekturfreigaben. Ein konkretes System benötigt Threat Modeling, Datenschutzprüfung, Lastannahmen, Tests gegen eigene Daten und einen Betriebsverantwortlichen. ^{[S-116; S-112; S-122]}

Die 50 wichtigsten Kernaussagen

Das Gesamtbild: vom Nutzer bis zum Betrieb

ARCHITEKTUR-SYNTHESE: Ein produktiver Request durchläuft mehrere Vertrauens- und Verarbeitungsschichten. Typisch sind: Eingangsvalidierung, Identitäts- und Mandantenprüfung, fachliche Kontextbildung, Modell- oder Retrievalaufruf, mögliche Werkzeugaktionen, Ergebnisvalidierung, Speicherung beziehungsweise Ausgabe sowie Telemetrie. Nicht jeder Use Case benötigt jede Stufe; jede ausgelassene Stufe muss aber eine bewusste Entscheidung sein. ^{[S-065; S-098; S-054; S-123]}

Data Plane und Control Plane

ARCHITEKTUR-SYNTHESE: Im Data Plane fließen Nutzereingaben, Dokumente, Retrievalpassagen, Toolargumente und Antworten. Im Control Plane liegen Konfigurationen wie erlaubte Modelle, Promptversionen, Toolkatalog, Policies, Budgets, Secrets, Rolloutstatus und Evaluationsfreigaben. Die Trennung verhindert, dass ein Modell oder Nutzertext seine eigenen Sicherheitsregeln verändern kann. ^{[S-090; S-067; S-110; S-062]}

Der kontrollierte Request-Lebenszyklus

1. 1. Request-ID erzeugen und Eingangsschema validieren. ^{[S-065; S-059]}
2. 2. Identität, Mandant und Session serverseitig bestimmen. ^{[S-099; S-098]}
3. 3. Fachliche Berechtigung und Datenklasse prüfen. ^{[S-110; S-125]}
4. 4. Benötigte Daten aus System of Record, RAG, Memory oder Tools auswählen. ^{[S-014; S-048; S-075]}
5. 5. Prompt und Toolkatalog aus versionierter Konfiguration zusammensetzen. ^{[S-054; S-055]}
6. 6. Modellaufruf mit Timeout, Budget und Telemetrie ausführen. ^{[S-080; S-124]}
7. 7. Struktur, Quellenbindung und Policy-Ergebnis prüfen. ^{[S-059; S-027; S-116]}
8. 8. Schreibaktionen erst nach erneuter Autorisierung und gegebenenfalls Freigabe ausführen. ^{[S-110; S-114]}
9. 9. Fachliches Ergebnis atomar speichern oder ausgeben. ^[S-075]
10. 10. Outcome, Kosten, Fehler und Eval-Signale erfassen, ohne unnötige sensible Inhalte zu loggen. ^{[S-123; S-109]}

Entwurfsregel: Je weiter ein Request vom reinen Textentwurf zur verbindlichen Außenwirkung oder Datenänderung wandert, desto stärker müssen deterministische Kontrollen und menschliche Freigaben werden. ^{[S-114; S-116]}

Was im Modellaufruf tatsächlich geschieht

TECHNISCHE GRUNDLAGE: Ein Sprachmodell erhält eine tokenisierte Sequenz und sagt schrittweise das nächste Token voraus. Chatrollen, Tooldefinitionen und strukturierte Ausgaben sind Anwendungs- oder API-Abstraktionen auf dieser Grundlage. Sie verändern die Nutzbarkeit erheblich, machen aus dem Modell aber keine transaktionale Fachsoftware. ^{[S-001; S-002; S-004; S-054]}

Tokenisierung und Kontextbudget

TECHNISCHE GRUNDLAGE: Tokenisierung zerlegt Text in Subword-Einheiten oder andere modellabhängige Symbole. Tabellen, Code, lange URLs, Mehrsprachigkeit und Sonderzeichen können daher anders kosten als reine Zeichen- oder Wortzählung vermuten lässt. Architektur und UI sollten Tokenverbrauch messen statt nur Zeichen zu zählen. ^{[S-004; S-094; S-095]}

Inferenz, Sampling und Reproduzierbarkeit

FORSCHUNGS- UND BETRIEBSSYNTHESE: Autoregressive Inferenz erzeugt Ausgaben sequenziell. Parameter wie Temperatur, Top-p, Stop-Sequenzen und maximale Ausgabe beeinflussen Variation und Länge; selbst bei niedriger Variation ist vollständige Reproduzierbarkeit über Hardware, Modellversionen und Anbieterupdates nicht garantiert. Für verbindliche Prozesse müssen Tests deshalb auf erlaubte Ergebnisräume und fachliche Invarianten zielen. ^{[S-002; S-007; S-120]}

Latenzbestandteile

ARCHITEKTUR-SYNTHESE: Eine Streaming-Antwort reduziert wahrgenommene Wartezeit, ändert aber nicht automatisch die Zeit bis zu einem vollständig validierten Ergebnis. Tool Calls, JSON und verbindliche Dokumente sollten häufig erst nach vollständiger Prüfung freigegeben werden. ^{[S-092; S-091; S-059]}

Kontext, Prompt, Session und State

BEGRIFFSKLÄRUNG: Vier Begriffe werden häufig vermischt: Prompt ist die konkrete Eingabe an das Modell, Kontextfenster die technische Kapazität des Aufrufs, Session ein anwendungsseitiger Zusammenhang mehrerer Interaktionen und State der persistente Prozess- oder Geschäftszustand. Nur der letzte kann verbindlich sein, wenn er in einem kontrollierten System gespeichert wird. ^{[S-013; S-075; S-048]}

Promptaufbau als Datenvertrag

ARCHITEKTUR-SYNTHESE: Ein robuster Promptaufbau trennt stabile Regeln, dynamische Fachparameter, untrusted Inhalte, abgerufene Quellen und Ausgabeanforderungen. Diese Trennung muss in Datenstrukturen und Code sichtbar sein; reine Trennzeichen im Text sind keine harte Sicherheitsisolation. ^{[S-113; S-059; S-057]}

Session und Gesprächshistorie

ARCHITEKTUR-SYNTHESE: Eine Session-ID verbindet Requests in der Anwendung. Die Anwendung entscheidet, welche früheren Nachrichten erneut in den Modellkontext gelangen. Vollständiges Anhängen des gesamten Verlaufs skaliert schlecht, kann alte Fehler verstärken und erhöht Daten- sowie Tokenrisiken. ^{[S-013; S-048; S-066]}

ARCHITEKTUR-SYNTHESE: Geeignete Strategien sind begrenztes Sliding Window, strukturierte Zustandsobjekte, überprüfte Zusammenfassungen, explizites Memory und erneutes Retrieval aus der autoritativen Quelle. Jede Zusammenfassung ist selbst ein abgeleitetes Artefakt und sollte nicht stillschweigend zum System of Record werden. ^{[S-047; S-050; S-075]}

Promptversionierung

BETRIEBSGRUNDSATZ: Modell, Prompt, Tooldefinition, Schema, Retrievalindex und Policy bilden gemeinsam eine lauffähige Version. Wird nur der Prompt geändert, kann dennoch das Gesamtverhalten kippen. Produktionssysteme sollten die Kombination in Traces und Evaluationsläufen erfassen. ^{[S-123; S-122; S-067]}

API, Modellgateway und Datenverträge

STANDARDGRUNDLAGE: Eine API ist die technische Grenze zwischen Komponenten. Sie sollte unabhängig von natürlicher Sprache klare Endpunkte, Methoden, Felder, Fehler, Authentisierung und Versionen besitzen. OpenAPI beschreibt synchrone HTTP-Schnittstellen; AsyncAPI und CloudEvents adressieren ereignisgetriebene Kommunikation. ^{[S-065; S-067; S-070; S-069]}

Direkter Providerzugang oder Modellgateway

Stabiler interner Vertrag

ARCHITEKTUR-SYNTHESE: Ein interner Modellvertrag sollte fachlich beschreiben, was benötigt wird, statt rohe Anbieterparameter unkontrolliert durchzureichen. Typische Felder sind Task-Typ, Input, erlaubte Tools, gewünschtes Schema, Qualitätsklasse, Datenklasse, Latenz-/Kostenbudget, Trace-ID und Fallbackregel. ^{[S-067; S-059; S-123]}

Fallback und Providerwechsel

ARCHITEKTUR-SYNTHESE: Provider unterscheiden sich bei Rollen, Tool Calling, strukturierten Ausgaben, Kontext, Caching, Safety-Policies und Fehlermodellen. Eine scheinbar einheitliche API darf diese Unterschiede nicht verdecken. Jede Fallbackroute benötigt eigene Contract- und Qualitäts-Evals. ^{[S-054; S-055; S-056; S-122]}

Strukturierte Ausgaben und fachliche Validierung

AKTUELLER PRODUKTSTAND: Strukturierte Ausgaben reduzieren Parsingfehler und können Felder, Typen, Enums und Pflichtangaben begrenzen. Sie sind besonders wichtig, sobald eine Modellausgabe von Software weiterverarbeitet wird. Die Grenze bleibt: Ein formal gültiges Objekt kann inhaltlich falsch sein. ^{[S-059; S-057; S-058]}

Vier Prüfebenen

ARCHITEKTUR-SYNTHESE: Für Extraktion sollte jedes kritische Feld nach Möglichkeit eine Provenienz tragen: Dokument-ID, Seite, Textspanne oder Koordinate. Das erleichtert Review und verhindert, dass ein überzeugend formulierter Wert ohne Beleg in das System of Record gelangt. ^{[S-027; S-076; S-075]}

EVALUATIONSSYNTHESE: Bei Klassifikation muss es eine Unknown-/Abstain-Option geben. Ein Schema, das nur bekannte Klassen erlaubt, kann das Modell zu einer falschen Auswahl zwingen, obwohl der Input keiner Klasse entspricht. ^{[S-122; S-120]}

Harte Grenze: Nie eine Modellausgabe direkt als SQL, Shell-Befehl, HTML oder API-Request ausführen, nur weil sie strukturiert ist. Kontextgerechte Validierung und sichere Ausführung bleiben Pflicht. ^{[S-115; S-107]}

Tool Calling: vom Vorschlag zur kontrollierten Aktion

AKTUELLER PRODUKTSTAND: Tool Calling erlaubt dem Modell, aus einem definierten Katalog einen Werkzeugaufruf mit strukturierten Argumenten vorzuschlagen. Die Anwendung entscheidet, ob der Call zulässig ist, führt ihn mit eigenen Credentials aus und gibt Ergebnis oder Fehler an das Modell zurück. ^{[S-054; S-055; S-056]}

Gute Werkzeuge sind klein und eindeutig

ARCHITEKTUR-SYNTHESE: Eine Toolbeschreibung sollte Zweck, erlaubte Eingaben, Einheiten, Grenzen, Side Effects und Fehlerfälle klar machen. Dennoch dürfen Beschreibungen nicht die serverseitige Validierung ersetzen, weil das Modell sie fehlinterpretieren oder untrusted Content sie beeinflussen kann. ^{[S-054; S-113; S-115]}

Read, propose, execute

ARCHITEKTUR-SYNTHESE: Für risikoreiche Systeme ist ein dreistufiges Muster robust: read liest autorisierte Daten, propose erzeugt einen strukturierten Änderungsvorschlag, execute führt erst nach fachlicher und gegebenenfalls menschlicher Freigabe aus. Dadurch lässt sich Autonomie graduell statt binär gestalten. ^{[S-114; S-110; S-116]}

Toolresultate und Fehler

ARCHITEKTUR-SYNTHESE: Werkzeuge sollten strukturierte Ergebnisse mit Status, Daten, Provenienz und maschinenlesbarem Fehler liefern. Der Fehler muss zwischen temporär, permanent, nicht autorisiert, nicht gefunden und fachlich abgelehnt unterscheiden, damit der Orchestrator nicht blind wiederholt. ^{[S-068; S-080; S-067]}

MCP: Interoperabilität, Architektur und Sicherheitsgrenzen

AKTUELLER STANDARDSTAND: Das Model Context Protocol beschreibt eine Architektur aus Host, Client und Server. Server stellen Fähigkeiten wie Tools, Ressourcen oder weitere Interaktionen bereit; der Host kontrolliert Nutzererfahrung, Modellzugang und Sicherheitskontext. MCP ist eine Integrationsschicht, nicht das gesamte Agentensystem. ^{[S-060; S-061]}

Warum MCP nützlich ist

• Einheitliche Discovery und Beschreibung von Werkzeugen reduziert proprietäre Einzeladapter. ^[S-060]
• Hosts können mehrere Server anbinden und Fähigkeiten in einen Modellkontext überführen. ^[S-060]
• Der 2026-07-28-Stand macht Requests stateless, routbarer und teilweise cachebar. ^[S-061]
• Headerbasierte Method-/Toolinformation erleichtert Gateway, Rate Limit und Autorisierungsentscheidungen. ^[S-061]

Was sich am 28. Juli 2026 änderte

Trust Boundary eines MCP-Servers

SICHERHEITSGRUNDSATZ: Ein MCP-Server kann Code ausführen, Daten lesen oder externe APIs aufrufen. Seine Toolbeschreibung ist keine Sicherheitsgarantie. Der Host muss Serverherkunft, Version, Berechtigungen, Netzwerkzugriff, Credential-Nutzung und erlaubte Datenbereiche kontrollieren. ^{[S-062; S-114; S-108]}

ARCHITEKTUR-SYNTHESE: MCP sollte wie jede externe API versioniert, inventarisiert und beobachtet werden. Pro Tool gehören Owner, Datenklassen, Scopes, Side Effects, Rate Limits, letzte Prüfung, Clientfreigaben und Abschaltweg in ein Register. ^{[S-060; S-062; S-123]}

Refresh-Hinweis: MCP gehört zu den am schnellsten veraltenden Teilen dieses Dossiers. Jede Implementierung muss gegen die konkrete Protokollversion und die zugehörigen SDK-Migrationshinweise geprüft werden. ^[S-061]

RAG: der vollständige Wissensfluss

FORSCHUNGSGRUNDLAGE: Retrieval-Augmented Generation verbindet ein generatives Modell mit extern abgerufenen Informationen. Der praktische Nutzen liegt darin, veränderliche, eigene oder belegpflichtige Inhalte zur Laufzeit bereitzustellen. Die Architekturqualität hängt jedoch mindestens ebenso stark von Datenaufnahme und Retrieval wie vom Modell ab. ^{[S-014; S-025; S-026]}

``mermaid flowchart LR subgraph Ingestion A[Originale] --> B[Parsing] B --> C[Chunking + Metadaten] C --> D[Volltext- und Vektorindex] D --> E[Version und ACL] end subgraph Laufzeit Q[Frage + Identität] --> R[Filter + Retrieval] R --> K[Reranking] K --> P[Kontext + Quellen] P --> L[LLM] L --> V[Antwortprüfung] end E --> R ``

Ingestion: die unterschätzte Hälfte

ARCHITEKTUR-SYNTHESE: Originaldokument, extrahierter Inhalt, Chunk, Embedding und Indexeintrag sind getrennte Artefakte. Ihre Beziehungen sollten nachvollziehbar sein, damit ein Treffer bis zur Originalfundstelle zurückgeführt und bei Dokumentänderung gezielt neu aufgebaut werden kann. ^{[S-076; S-026; S-027]}

Query Pipeline

ARCHITEKTUR-SYNTHESE: Eine Anfrage sollte nicht direkt als Vektorsuche behandelt werden. Zunächst sind Nutzeridentität, Mandant, Sprache, Suchabsicht, erlaubte Datenräume und gegebenenfalls Zeit- oder Produktfilter zu bestimmen. Danach können Query Expansion, hybride Suche, Reranking und Kontextkompression folgen. ^{[S-017; S-035; S-110; S-026]}

Naive, Advanced, Modular und Agentic RAG

Quellenbindung und Abstain

ARCHITEKTUR-SYNTHESE: Eine quellengebundene Antwort sollte nur Aussagen enthalten, die aus den bereitgestellten Passagen folgen, und für jede wesentliche Aussage auf die konkrete Fundstelle verweisen. Fehlt ausreichende Evidenz, ist „nicht belegt“ oder eine Eskalation belastbarer als eine plausible Ergänzung aus Modellwissen. ^{[S-027; S-116; S-122]}

PROVENIENZREGEL: Zitate sollten nicht erst nachträglich anhand ähnlicher Dokumente angehängt werden. Das System muss speichern, welche Passagen tatsächlich im Kontext lagen und welche Textaussage darauf gestützt wurde. ^{[S-027; S-021]}

Embeddings, Retrieval, Hybrid Search und Reranking

FORSCHUNGSGRUNDLAGE: Embeddings repräsentieren Texte als Vektoren. Ähnliche Inhalte liegen im gewählten Repräsentationsraum häufig näher beieinander. Die praktische Suchqualität hängt von Modell, Sprache, Domäne, Chunking, Distanzmetrik, Index und Kandidatenzahl ab; allgemeine Leaderboards sind nur Ausgangspunkte. ^{[S-030; S-031; S-028]}

Dense, Sparse und Multi-Vector

ANN und HNSW

TECHNISCHE GRUNDLAGE: Bei großen Vektorbeständen wird häufig Approximate Nearest Neighbor Search verwendet, um Suchzeit gegen geringe Näherungsfehler zu tauschen. HNSW organisiert Vektoren in einem mehrschichtigen navigierbaren Graphen. Parameter beeinflussen Indexgröße, Aufbauzeit, Recall und Abfragelatenz. ^{[S-029; S-034]}

ARCHITEKTUR-SYNTHESE: ANN-Parameter sind keine einmalige Infrastrukturentscheidung. Sie müssen zusammen mit Embeddingmodell, Filterselektivität, Datenmenge und Zielmetrik getestet werden. Bei kleinen Beständen kann eine exakte Suche einfacher und ausreichend sein. ^{[S-029; S-028; S-034]}

Query Expansion, HyDE und Self-/Corrective RAG

FORSCHUNGSSTAND: HyDE erzeugt ein hypothetisches Dokument und nutzt dessen Embedding für Retrieval. Self-RAG und Corrective RAG ergänzen adaptive Retrieval- oder Bewertungsschritte. Diese Verfahren zeigen, dass Retrieval selbst ein iterativer Prozess sein kann; sie erhöhen aber die Zahl der Modellaufrufe und benötigen eigene Evals. ^{[S-017; S-018; S-019]}

Reranking

FORSCHUNGSSYNTHESE: Reranking trennt schnellen Recall von präziser Reihenfolge. Ein erster Retriever liefert Kandidaten; ein Cross-Encoder, Late-Interaction-Modell oder LLM bewertet sie genauer. Der Nutzen ist besonders dann relevant, wenn top-k klein ist oder mehrere ähnliche Dokumentversionen existieren. ^{[S-016; S-028; S-026]}

Relationale Datenbank, Vektorindex, Volltextindex und Objektspeicher

ARCHITEKTUR-SYNTHESE: Die häufigste Fehlannahme lautet, eine Vektordatenbank sei der zentrale Speicher einer KI-Anwendung. Tatsächlich besitzen produktive Systeme meist mehrere spezialisierte Speicher: System of Record, Objektspeicher, Suchindex, Event Log, Cache und gegebenenfalls Memory Store. ^{[S-075; S-076; S-034; S-084]}

Relationale Datenbank als Autorität

TECHNISCHE GRUNDLAGE: Relationale Datenbanken bieten Transaktionen, Constraints, Isolation und Abfragen über strukturierte Beziehungen. Für Kunden, Aufträge, Rollen, Zustände, Freigaben und Abrechnung sind diese Eigenschaften entscheidender als semantische Ähnlichkeit. ^{[S-075; S-074]}

AKTUELLER PRODUKTSTAND / SYNTHESE: Ein Vektorindex kann als Erweiterung derselben Datenbank betrieben werden, etwa über pgvector. Das kann Konsistenz und Betrieb vereinfachen, ist aber nicht automatisch für jede Datenmenge oder Latenz optimal. Architekturentscheidend sind Messwerte und Betriebsfähigkeit, nicht die Produktkategorie. ^{[S-034; S-073]}

Volltextindex

TECHNISCHER PRODUKTSTAND: Volltextsuche verarbeitet Tokens, Wörterbücher, Ranking und Phrasen. Sie ist besonders wertvoll für Eigennamen, Artikelnummern, Paragraphen, Zitate und exakte Terminologie. In RAG-Systemen sollte sie nicht vorschnell durch reine Embeddings ersetzt werden. ^{[S-033; S-035]}

Objektspeicher

ARCHITEKTUR-SYNTHESE: Objektspeicher eignet sich für Original-PDFs, Bilder, Audio, große Exporte und unveränderte Rohartefakte. Die Anwendung sollte Prüfsumme, MIME-Typ, Größe, Verschlüsselungs-/Zugriffskontext und Verweis auf fachliche Metadaten speichern. Eine öffentliche URL ist kein Rechtemodell. ^{[S-076; S-110; S-125]}

Event Log und Cache

ARCHITEKTUR-SYNTHESE: Ein Event Log beschreibt Ereignisse über Zeit und kann Replay sowie mehrere Konsumenten ermöglichen. Ein Cache speichert abgeleitete Ergebnisse temporär. Beide dürfen nicht unbemerkt zur einzigen Quelle eines verbindlichen Zustands werden. ^{[S-084; S-069; S-066; S-075]}

Memory: welche Erinnerung wohin gehört

FORSCHUNGSSYNTHESE: Memory ist kein einheitlicher technischer Baustein. Forschungen und Produktionsansätze unterscheiden kurzfristigen Kontext, episodische Erinnerungen, semantische Fakten, prozedurale Fähigkeiten und Reflexionen. Für Unternehmen kommt zusätzlich verbindlicher Geschäftszustand hinzu, der nicht als freie Erinnerung behandelt werden darf. ^{[S-047; S-048; S-049; S-050]}

Memory Write Policy

ARCHITEKTUR-SYNTHESE: Ein System sollte nicht jede Nutzeräußerung dauerhaft speichern. Eine Memory Write Policy definiert speicherbare Typen, Sensitivität, Zweck, Scope, Bestätigung, TTL und Konfliktverhalten. Kritische Erinnerungen sollten sichtbar, korrigierbar und löschbar sein. ^{[S-050; S-051; S-125]}

Retrieval aus Memory

ARCHITEKTUR-SYNTHESE: Memory-Retrieval sollte mindestens Nutzer-/Mandantenscope, Relevanz, Frische, Vertrauensniveau und Konflikte berücksichtigen. Ein älterer Eintrag darf einen neueren oder autoritativen Datensatz nicht still überschreiben. ^{[S-049; S-050; S-075]}

Zusammenfassungen und Verdichtung

ARCHITEKTUR-SYNTHESE: Zusammenfassungen reduzieren Token, sind aber verlustbehaftete Ableitungen. Bei jeder Verdichtung sollte das System auf die zugrunde liegenden Ereignisse oder Nachrichten zurückverweisen und bei wichtigen Entscheidungen erneut aus der Primärquelle lesen. ^{[S-048; S-047; S-013]}

Klare Grenze: Ein KI-Memory ist eine kuratierte, fehlbare Hilfsstruktur. Verbindliche Rechts-, Finanz-, Kunden- und Prozessdaten gehören in kontrollierte Fachsysteme. ^{[S-075; S-125]}

Fine-Tuning, Adapter, Distillation und Modellanpassung

FORSCHUNGSGRUNDLAGE: Fine-Tuning verändert Modellparameter oder Zusatzadapter anhand von Trainingsbeispielen. LoRA und QLoRA reduzieren den Speicher- und Rechenbedarf solcher Anpassungen. DPO adressiert Präferenzoptimierung; Distillation überträgt Verhalten auf kleinere Modelle. ^{[S-009; S-010; S-011; S-012]}

Entscheidungsmatrix

EVALUATIONSGRUNDSATZ: Vor Fine-Tuning braucht es eine Baseline, einen getrennten Trainings-/Validierungs-/Testbestand, Qualitäts- und Sicherheitsmetriken, Datenrechte sowie einen Rollbackpfad. Ohne reproduzierbare Evals kann eine Anpassung einzelne Beispiele verbessern und andere Fähigkeiten verschlechtern, ohne dass dies sichtbar wird. ^{[S-122; S-120; S-116]}

BETRIEBSSYNTHESE: Fine-Tuning bindet stärker an Modellfamilie, Tokenizer, Trainingspipeline und Serving-Stack. Adapter und quantisierte Varianten vereinfachen manche Szenarien, erzeugen aber zusätzliche Artefakte, Versionen und Kompatibilitätsprüfungen. ^{[S-009; S-010; S-091]}

Agenten, Planung und begrenzte Autonomie

FORSCHUNGSSTAND: Agentische Systeme lassen ein Modell über mehrere Schritte Beobachtungen verarbeiten, Aktionen auswählen und Ergebnisse erneut bewerten. ReAct, Reflexion und Tree-Search-Ansätze liefern Forschungsbausteine; realistische Benchmarks zeigen, dass zuverlässige End-to-End-Ausführung deutlich schwieriger als ein einzelner guter Modelloutput ist. ^{[S-038; S-041; S-042; S-043; S-044]}

Minimale Agentenarchitektur

Planen ist nicht Ausführen

SICHERHEITSGRUNDSATZ: Ein Agentenplan ist ein vorläufiger Vorschlag. Vor jeder Aktion muss die Anwendung aktuelle Rechte, Toolstatus, Argumente, Kosten und fachliche Vorbedingungen erneut prüfen. Ein früherer Plan darf keine dauerhafte Autorisierung darstellen. ^{[S-110; S-062; S-098]}

Single Agent oder Multi-Agent

FORSCHUNGSSYNTHESE: Mehrere Agenten können Rollen oder Perspektiven trennen, erzeugen aber zusätzliche Nachrichten, Koordinationsfehler, Kosten und Verantwortungsunklarheit. Ein zweiter Agent ist kein unabhängiger Prüfer, wenn beide dieselben Daten, Modelle und Fehlerannahmen teilen. ^{[S-053; S-045; S-121]}

Autonomiestufen

ARCHITEKTUR-SYNTHESE: Die Autonomiestufe sollte pro Tool und Aktion definiert werden, nicht pauschal pro „Agent“. Ein Agent kann Dokumente autonom lesen, aber jede schreibende Aktion zur Freigabe stellen. ^{[S-114; S-116]}

Deterministische Workflows und die bewusste Entscheidung gegen KI

STANDARDGRUNDLAGE: BPMN modelliert Prozessschritte, Ereignisse und Gateways; DMN modelliert Entscheidungen und Regeln. Wenn ein Geschäftsprozess vollständig bekannt ist, liefern solche formalen Modelle bessere Nachvollziehbarkeit als eine frei generierte Planung. ^{[S-071; S-072]}

Das Sandwich-Muster

ARCHITEKTUR-SYNTHESE: Ein häufig robustes Muster ist deterministisch -> generativ -> deterministisch. Vor dem Modell werden Daten und Rechte festgelegt; das Modell übernimmt Klassifikation, Extraktion oder Formulierung; danach prüfen Regeln, Schemas und Freigaben das Ergebnis. ^{[S-059; S-072; S-110]}

Kriterien für „keine KI“

• Ausgabe muss mathematisch exakt und vollständig sein; klassische Berechnung ist möglich. ^[S-072]
• Regeln sind bekannt, stabil und rechtlich oder fachlich auditierbar. ^{[S-071; S-072]}
• Eingaben sind bereits strukturiert und benötigen keine Sprachinterpretation.
• Fehlerfolge ist hoch, während menschliche oder technische Verifikation des KI-Ergebnisses nicht praktikabel ist. ^[S-116]
• Volumen und Latenz machen einen deterministischen Algorithmus deutlich günstiger.
• Der Prozess benötigt nur Suche und Filter, keine generative Synthese. ^{[S-033; S-035]}

Regeln aus natürlicher Sprache

ARCHITEKTUR-SYNTHESE: Ein LLM kann aus Fachtexten Vorschläge für Regeln, Testfälle oder Prozessmodelle erzeugen. Die resultierenden Regeln müssen jedoch von Fachverantwortlichen formalisiert, auf Widersprüche geprüft, versioniert und mit Gegenbeispielen getestet werden. Natürliche Sprache bleibt mehrdeutig. ^{[S-072; S-122; S-116]}

Queues, Events, Webhooks, Cron und durable Execution

TECHNISCHE GRUNDLAGE: Asynchrone Architektur ist zentral, sobald Verarbeitung länger dauert, Last schwankt, externe Systeme ausfallen können oder ein Prozess auf spätere Ereignisse wartet. Queue, Event Log, Webhook, Scheduler und Workflow Engine sind dabei unterschiedliche Bausteine. ^{[S-082; S-084; S-077; S-085]}

Zustellsemantik und fachliche Wirkung

RELIABILITY-SYNTHESE: „Exactly once“ auf Transport- oder Stream-Ebene ist nicht dasselbe wie genau eine fachliche Wirkung über mehrere Systeme. Ein Zahlungsvorgang, Ticket oder Versand benötigt einen stabilen fachlichen Schlüssel, Deduplizierung und eine atomare beziehungsweise reconciliierbare Zustandsführung. ^{[S-084; S-081; S-079; S-075]}

Inbox-/Outbox-Muster

ARCHITEKTUR-SYNTHESE: Beim Inbox-Muster speichert der Empfänger eine Event-ID oder Idempotency Key zusammen mit dem Verarbeitungsergebnis. Beim Outbox-Muster schreibt die Fachtransaktion ein zu veröffentlichendes Ereignis in derselben Datenbanktransaktion; ein separater Publisher überträgt es. Beide Muster reduzieren Lücken zwischen Datenänderung und Nachrichtenversand. ^{[S-075; S-084; S-081]}

Webhook-Referenzpfad

1. Signatur und Zeitfenster prüfen; keine Identität aus Payloadtext ableiten. ^{[S-077; S-106]}
2. Event-ID deduplizieren und Payload unverändert archivieren, soweit zulässig.
3. Schnell mit geeignetem Status antworten und eigentliche Arbeit in Queue/Workflow verschieben. ^{[S-077; S-082]}
4. Temporäre und permanente Fehler unterscheiden; begrenzt mit Backoff/Jitter wiederholen. ^[S-080]
5. Nach Retry-Budget in Dead Letter / Incident Queue überführen; manuellen Replay ermöglichen. ^[S-079]
6. Regelmäßig mit der Quell-API reconciliieren, wenn Geschäftsfolgen kritisch sind. ^[S-077]

Durable Execution für KI-Prozesse

AKTUELLER PRODUKTSTAND: Mehrstufige KI-Prozesse können Stunden oder Tage dauern: Dokument kommt an, Extraktion läuft, Mensch korrigiert, ERP antwortet, Angebot wird freigegeben. Eine durable Workflow Engine speichert Ereignishistorie und kann nach Prozess- oder Infrastrukturfehlern an definierten Punkten fortsetzen. ^{[S-085; S-086]}

ARCHITEKTUR-SYNTHESE: Modellaufrufe sind externe Activities mit Timeout, Retrypolicy und gespeichertem Ergebnis. Sie dürfen bei Replay nicht unbemerkt erneut eine irreversible Aktion auslösen. Side Effects müssen über idempotente Activities oder explizite Marker kontrolliert werden. ^{[S-086; S-081; S-114]}

Identität, Authentisierung, Autorisierung und Secrets

SICHERHEITSGRUNDLAGE: Produktive KI-Systeme besitzen mehrere Identitäten: Menschen, technische Dienste, externe Integrationen und gegebenenfalls agentische Laufzeiten. Mandant und Identität sind dabei nicht dasselbe. Ein angemeldeter Nutzer gehört zu einem Mandanten, kann aber je Objekt und Aktion unterschiedliche Rechte besitzen. ^{[S-099; S-110; S-098]}

Vier getrennte Autorisierungsprüfungen

1. Darf der Nutzer die KI-Funktion grundsätzlich verwenden?
2. Darf die Anwendung die konkreten Quelldaten lesen?
3. Darf das ausgewählte Tool auf das konkrete Objekt zugreifen oder es verändern?
4. Darf das Ergebnis an den vorgesehenen Empfänger ausgegeben, gespeichert oder versendet werden?

ARCHITEKTUR-SYNTHESE: Diese Prüfungen dürfen nicht auf eine einzige Rollenabfrage reduziert werden. Besonders bei RAG und Agenten kann der Eingabekanal erlaubt sein, während einzelne Dokumente, Felder oder Aktionen gesperrt bleiben. ^{[S-110; S-062; S-116]}

OAuth und OIDC richtig einordnen

AKTUELLER STANDARDSTAND: OAuth 2.0 ist ein Autorisierungsrahmen; OpenID Connect ergänzt eine Identitätsschicht. Für browser- und appbasierte öffentliche Clients stärkt PKCE den Authorization Code Flow. Der OAuth 2.0 Security Best Current Practice RFC 9700 verwirft oder begrenzt ältere unsichere Muster und betont exakte Redirect-URI-Prüfung, Senderbindung und Schutz vor Tokenmissbrauch. ^{[S-097; S-099; S-101; S-098]}

Tokens und der Confused-Deputy-Effekt

SICHERHEITSBEFUND: Ein Access Token ist für einen bestimmten Ressourcenkontext und eine bestimmte Audience gedacht. Ein Vermittler, der Token ungeprüft an andere Ressourcen weiterreicht, kann zum Confused Deputy werden. MCP-Sicherheitsleitlinien warnen ausdrücklich vor Token Passthrough und unklaren Delegationsketten. ^{[S-100; S-098; S-062]}

• Audience, Issuer, Ablauf, Signatur und erforderliche Claims prüfen. ^{[S-102; S-103]}
• Scopes als grobe Delegationsgrenze nutzen, anschließend Objekt- und Mandantenrechte prüfen. ^{[S-098; S-110]}
• Kurzlebige Tokens und getrennte Clients pro Umgebung und Integrationsklasse einsetzen.
• Refresh Tokens, Client Secrets und Signaturschlüssel nicht an Modelle oder Tooltexte ausgeben. ^[S-108]
• Bei schreibenden Aktionen die Identität, den fachlichen Auftrag und die Freigabe in der Auditspur verbinden.

Secret Management

SICHERHEITSGRUNDSATZ: Secrets sollten zentral inventarisiert, außerhalb des Quellcodes gespeichert, nach Umgebung und Dienst getrennt, regelmäßig rotiert und in Logs redigiert werden. Wo möglich sind kurzlebige Workload-Credentials statischen Schlüsseln vorzuziehen. ^{[S-108; S-109; S-098]}

Harte Grenze: Das Modell entscheidet niemals über eigene Rechte. Es kann eine gewünschte Aktion beschreiben; die Anwendung prüft Identität, Objekt, Policy und aktuellen Zustand unabhängig davon. ^{[S-110; S-114]}

Observability, Logging, Audit und Kostenmessung

AKTUELLER STANDARDSTAND: Observability verbindet Traces, Metriken und Logs, damit ein Systemzustand aus Telemetrie erklärbar wird. Für generative KI entwickeln OpenTelemetry und Anbieter eigene Semantikkonventionen. Diese Felder ändern sich schnell und müssen versioniert werden. ^{[S-123; S-124]}

Eine End-to-End-Trace statt isolierter Modelllogs

ARCHITEKTUR-SYNTHESE: Ein Modellaufruf ist nur ein Span im Gesamtprozess. Ein belastbarer Trace beginnt am Nutzer- oder Eventeingang und verbindet Retrieval, Datenbankzugriffe, Queue, Tools, Modell, Validator, Freigabe und Side Effects über gemeinsame Korrelationskennungen. ^{[S-123; S-124; S-069]}

Auditlog ist nicht Debuglog

SICHERHEITS- UND RECHTSSCHNITTSTELLE: OWASP empfiehlt eine konsistente Protokollierung sicherheitsrelevanter Ereignisse, warnt aber zugleich vor sensitiven Daten in Logs. Datenschutzrechtlich bleiben Logdaten personenbezogen, wenn sie einer Person zugeordnet werden können; Zweck, Zugriff, Dauer und Löschung müssen daher gestaltet werden. ^{[S-109; S-125]}

Kosten pro Prozess statt nur pro Token

BETRIEBSSYNTHESE: Tokenkosten sind nur ein Teil der Vollkosten. Retrieval, Embeddings, Reranking, Tool-APIs, Queue, Speicher, Egress, lokale GPU-Zeit, Monitoring, Fehlversuche, Human Review und Wartung müssen einer fachlichen Transaktion zugeordnet werden. ^{[S-007; S-090; S-095; S-094]}

Minimaler Betriebsdatensatz

• Trace-ID und fachliche Transaktions-ID
• Zeitstempel, Umgebung, Service-, Modell-, Prompt-, Policy- und Toolschemaversion
• Tenant-/Nutzerkontext in datensparsamer Form
• Retrieval- und Toolentscheidungen mit Resultatstatus
• Token, Latenz, Cache, Retry, Kosten und Fehlerklasse
• Validator-, Policy-, Human-Gate- und Side-Effect-Ergebnis
• Verweis auf Eval-/Incident-/Feedbackdatensatz, nicht zwingend den gesamten Inhalt

Evaluation, Tests und Freigabekriterien

EVALUATIONSGRUNDLAGE: KI-Evaluation ist kein einzelner Genauigkeitswert. HELM strukturiert mehrere Szenarien und Metriken; RAGAS trennt Retrieval- und Antwortaspekte; praktische Leitfäden betonen aufgabenspezifische Testsets und menschliche Kalibrierung. ^{[S-120; S-027; S-122]}

Testpyramide für KI-Systeme

Golden Set

PRAXISGRUNDSATZ: Ein Golden Set ist ein versionierter Bestand repräsentativer Testfälle mit erwarteten Ergebnissen, zulässigen Varianten und Bewertungsregeln. Es sollte reale Häufigkeiten nicht nur spiegeln, sondern auch seltene kritische Fehler gezielt übergewichten. ^{[S-122; S-120; S-116]}

Komponentenmetriken

LLM-as-a-Judge

FORSCHUNGSBEFUND: G-Eval zeigt, dass Modelle textuelle Qualität anhand strukturierter Kriterien bewerten können. Ein Modellgrader bleibt jedoch selbst modell-, prompt- und datenabhängig. Er muss gegen menschliche Urteile kalibriert, auf Positions- und Stilbias geprüft und regelmäßig neu validiert werden. ^{[S-121; S-122]}

Release Gate

Messregel: Eine Demo beantwortet „kann einmal funktionieren“. Ein Evaluationssystem beantwortet „wie häufig, unter welchen Bedingungen, mit welchen Fehlern und Kosten funktioniert es“. ^{[S-045; S-122]}

Reliability: Timeout, Retry, Idempotenz, Cache und Fallback

RELIABILITY-GRUNDSATZ: Ein KI-System hängt meist von mehreren verteilten Diensten ab. Reliability entsteht deshalb nicht durch einen einzelnen Retry, sondern durch ein End-to-End-Zeitbudget, begrenzte Wiederholung, idempotente Fachwirkung, Zustandsführung, Degradation und Reconciliation. ^{[S-065; S-080; S-081; S-086]}

Timeoutbudget

ARCHITEKTUR-SYNTHESE: Jeder externe Aufruf benötigt ein Timeout. Zusätzlich braucht der Gesamtprozess ein Deadline-Budget, damit mehrere interne Retries nicht die Nutzer- oder Geschäftsfrist überschreiten. Längere Arbeiten sollten asynchron werden statt einen offenen HTTP-Request zu halten. ^{[S-065; S-080; S-082]}

Retry mit Backoff und Jitter

RELIABILITY-GRUNDSATZ: Retries sind nur für temporäre und idempotent behandelbare Fehler geeignet. Exponentieller Backoff und Jitter reduzieren synchronisierte Wiederholungswellen. Ein 4xx-Validierungsfehler, eine abgelehnte Autorisierung oder ein inhaltlich falsches Ergebnis wird durch Wiederholung nicht automatisch besser. ^{[S-080; S-065]}

Idempotenz

RELIABILITY-GRUNDSATZ: Eine idempotente Fachoperation kann bei gleicher Geschäftsabsicht wiederholt werden, ohne eine zusätzliche Wirkung zu erzeugen. Dafür reicht nicht, dass HTTP PUT formal idempotent sein kann; die Anwendung benötigt einen stabilen fachlichen Schlüssel, gespeicherten Zustand und definiertes Konfliktverhalten. ^{[S-065; S-078; S-081]}

Caching-Ebenen

AKTUELLER STANDARD- UND PRODUKTSTAND: HTTP-Caching nach RFC 9111, Anbieter-Prompt-Caching, Retrieval-Caches und Anwendungscaches besitzen unterschiedliche Schlüssel, Datenschutzfolgen und Invalidierungsregeln. Ein Cachetreffer ist nur korrekt, wenn Eingabe, Berechtigung, Version und Gültigkeit übereinstimmen. ^{[S-066; S-095; S-094; S-096]}

Fallback und Degradation

ARCHITEKTUR-SYNTHESE: Ein Fallbackmodell kann andere strukturierte Ausgaben, Toolwahl, Sicherheitsgrenzen und Latenz besitzen. Deshalb muss es mit demselben Golden Set und den gleichen Side-Effect-Grenzen getestet werden. Bei kritischen Funktionen ist „kontrolliert nicht antworten“ oft besser als ein ungeprüfter Ersatz. ^{[S-057; S-055; S-056; S-122]}

Reconciliation

ARCHITEKTUR-SYNTHESE: Bei geschäftskritischen Integrationen genügt Ereignisverarbeitung allein nicht. Ein regelmäßiger Reconciliation-Lauf vergleicht Quell- und Zielsystem, erkennt verlorene oder doppelte Zustände und erstellt reparierbare Abweichungen. ^{[S-077; S-079; S-075]}

Sicherheitsarchitektur: Prompt Injection, Tools und Vertrauenszonen

SICHERHEITSBEFUND: OWASP veröffentlichte am 3. August 2026 die aktuelle Ausgabe „OWASP GenAI LLM Top 10 2026“. Die detaillierte 2025er Risikoseite zu Prompt Injection beschreibt weiterhin die für die Architektur entscheidende Angriffsklasse: Direkte Injection stammt vom Nutzer; indirekte Injection kann in Webseiten, Dokumenten, E-Mails oder Toolresultaten verborgen sein. Das Kernproblem ist, dass ein Modell Daten und Instruktionen nicht mit einer harten Sicherheitsgrenze trennt. ^{[S-111; S-112; S-113; S-117]}

Vertrauenszonen

Defensive Architektur gegen indirekte Prompt Injection

• Externe Inhalte nie in dieselbe logische Autoritätsklasse wie Systemregeln aufnehmen. ^[S-113]
• Toolset und Rechte unabhängig vom Dokumentinhalt vorab begrenzen. ^{[S-114; S-110]}
• Read-only Recherche und schreibende Aktionen in getrennte Phasen, Prozesse oder Identitäten aufteilen.
• Modelle nicht mit Secrets, breiten Tokens oder unnötigen internen Metadaten versorgen. ^{[S-108; S-062]}
• Toolargumente gegen feste Schemas und fachliche Allow-/Deny-Regeln prüfen. ^{[S-059; S-115]}
• Ungewöhnliche Instruktionsmuster, Datenexfiltration und Toolketten als Security-Signale protokollieren. ^{[S-109; S-118]}
• Für externe Wirkung explizite, inhaltlich konkrete Freigabe verlangen; eine generische „Agent darf handeln“-Zustimmung reicht nicht.

Excessive Agency

SICHERHEITSBEFUND: Übermäßige Handlungsfähigkeit entsteht, wenn ein System zu viele Funktionen, Berechtigungen oder autonome Schritte erhält. Schaden kann sowohl aus bösartiger Injection als auch aus normalem Modellfehler entstehen. Die wirksamste Kontrolle ist eine kleinere Aktionsfläche. ^{[S-114; S-119; S-116]}

Improper Output Handling

SICHERHEITSGRUNDSATZ: Modelloutput ist untrusted Input für das nächste System. Ohne Escaping, Parsing und Validierung kann er Injection in HTML, SQL, Shell, Templates oder nachgelagerte Agenten auslösen. Freitext darf nicht direkt zu Code oder Befehl werden. ^{[S-115; S-107; S-059]}

MCP- und Tool-Lieferkette

AKTUELLER STANDARD- UND SICHERHEITSSTAND: MCP erleichtert Discovery und Nutzung externer Fähigkeiten. Dadurch wächst die Lieferkette: Serverimplementierung, Paket, Hosting, OAuth-Konfiguration, Toolbeschreibung, Rückgabedaten und Updates können Risiken tragen. Ein Serverinventar und eine Zulassungsprüfung bleiben erforderlich. ^{[S-060; S-062; S-061]}

Threat Modeling und Red Teaming

SICHERHEITSRAHMEN: NIST AI 100-2e2025 beschreibt adversariales maschinelles Lernen; MITRE ATLAS strukturiert beobachtete Taktiken und Techniken. Für agentische Systeme sollten Threat Models neben Modellangriffen auch Identität, Tools, Datenquellen, Lieferkette, Logs und Side Effects umfassen. ^{[S-117; S-118; S-119]}

Sicherheitsregel: Ein intelligenterer Agent ist kein Ersatz für kleinere Rechte. Sicherheitsarchitektur muss auch dann tragen, wenn das Modell eine falsche, manipulierte oder missverständliche Aktion vorschlägt. ^{[S-114; S-062]}

Datenprovenienz, Datenschutz und Mandantentrennung

DATENARCHITEKTUR-GRUNDSATZ: Ein KI-System verarbeitet mehrere Artefakte: Originaldaten, extrahierten Text, Chunks, Embeddings, Indexeinträge, Prompts, Modellantworten, Toolresultate, Memories, Logs und Evaluationsdaten. Für jedes Artefakt sind Zweck, Herkunft, Eigentümer, Scope, Aufbewahrung und Löschpfad zu bestimmen. ^{[S-026; S-125; S-124]}

Provenienzketten

ARCHITEKTUR-SYNTHESE: Ein Quellenlink allein reicht nicht, wenn die zugrunde liegende Version später verändert wird. Für reproduzierbare Entscheidungen sollten Dokument-ID, Version oder Hash und die tatsächlich verwendete Passage gespeichert werden, soweit dies rechtlich und betrieblich zulässig ist. ^{[S-027; S-076; S-074]}

Datenschutz durch Architektur

GELTENDES RECHT: Die DSGVO verlangt unter anderem Zweckbindung, Datenminimierung, Speicherbegrenzung und angemessene Sicherheit. Daraus folgen keine universellen Technikvorgaben, aber konkrete Architekturfragen: Welche Daten werden an welchen Anbieter gesendet, wie lange gespeichert, für welche Folgeprozesse genutzt und wie gelöscht oder berichtigt? ^[S-125]

Mandantentrennung über alle Ebenen

SICHERHEITS- UND DATENARCHITEKTUR: Mandantentrennung darf nicht an der Oberfläche enden. Sie muss für relationale Daten, Objektspeicher, Suchindizes, Retrievalfilter, Cachekeys, Queues, Workflows, Logs, Memory und Backups gelten. Ein einziger gemeinsamer Index kann zulässig sein, erhöht aber die Anforderungen an unvermeidbare serverseitige Filter und Tests. ^{[S-110; S-034; S-074; S-125]}

Löschung und Indexsynchronität

ARCHITEKTUR-SYNTHESE: Die Löschung einer Originaldatei muss abhängige Artefakte erreichen: extrahierten Text, Chunks, Embeddings, Volltext- und Vektorindex, Caches, Memories und gegebenenfalls Evaluationsexporte. Ein Löschereignis braucht daher eine nachvollziehbare, wiederholbare Fan-out-Verarbeitung und einen Reconciliation-Check. ^{[S-125; S-079; S-081]}

AI Act als Systemschnittstelle

GELTENDES EU-RECHT / SCHNITTSTELLE: Der AI Act stellt je nach Rolle und Systemkategorie unterschiedliche Anforderungen. Für Architekturarbeit besonders relevant sind dokumentierbare Daten- und Systemgrenzen, technische Dokumentation, Logging, menschliche Aufsicht, Genauigkeit, Robustheit und Cybersicherheit bei erfassten Systemen. Die konkrete Einordnung bleibt eine separate Rechtsprüfung. ^[S-126]

Cloud, lokal, hybrid und Modell-Serving

BETRIEBSSYNTHESE: Cloud-API, lokales Serving und Hybridarchitektur lösen unterschiedliche Probleme. Die Wahl betrifft nicht nur Datenschutz, sondern auch Modellqualität, Latenz, Verfügbarkeit, Kapazität, Personal, Updategeschwindigkeit, Lizenz, Egress und Exitfähigkeit. ^{[S-090; S-091; S-093; S-116]}

Model Gateway

ARCHITEKTUR-SYNTHESE: Ein Model Gateway zentralisiert Providerzugang, Credentials, Routing, Quoten, Logging, Kosten, Policy und Fallback. Es sollte jedoch keine falsche Austauschbarkeit erzeugen: Modelle unterscheiden sich bei Tool Calling, Structured Output, Kontext, Safety und Semantik. ^{[S-054; S-055; S-056; S-124]}

Lokales Serving ist mehr als eine Modelldatei

AKTUELLER PRODUKTSTAND: vLLM adressiert unter anderem KV-Cache-Management und hohen Durchsatz; Text Generation Inference und llama.cpp liefern weitere Serving- beziehungsweise lokale Laufzeitansätze; KServe orchestriert Model Serving auf Kubernetes. Keines dieser Werkzeuge ersetzt Kapazitätsplanung, Modell-/Lizenzprüfung, Absicherung und Evaluation. ^{[S-007; S-091; S-092; S-093; S-090]}

Deploymentmuster

AKTUELLER PRODUKT- UND BETRIEBSSTAND: Kubernetes Deployments steuern gewünschte Replikate und rollende Updates; Jobs modellieren endliche Arbeit und CronJobs zeitgesteuerte Jobs. Für Modellendpunkte ergänzen Serving-Systeme Skalierung und Revisionen. Die konkrete Plattform ist weniger wichtig als reproduzierbare Images, Konfiguration, Health Checks, Ressourcenlimits, Canary und Rollback. ^{[S-089; S-088; S-087; S-090]}

Modellwechsel

• Golden Set und Sicherheitsset gegen neue Modellversion ausführen. ^[S-122]
• Tool- und Structured-Output-Schemas auf Abweichungen prüfen. ^{[S-057; S-055; S-058]}
• Tokenisierung, Kontextgrenzen, Latenz, Kosten, Cache und Rate Limits neu messen.
• Shadow oder Canary mit begrenztem Scope nutzen; keine unbemerkte Aliasumstellung.
• Prompt, Modell, Gatewaypolicy, Toolset und Evalresultat als Releasepaket versionieren.
• Rollback auf vorherige Kombination technisch und organisatorisch vorbereiten.

Achtzehn Forschungs- und Technikprofile

LESEHINWEIS: Die folgenden Profile verdichten zentrale Originalarbeiten, Standards und Produktdokumentationen. Sie zeigen jeweils den belastbaren Kern und die daraus folgende Architekturkonsequenz; sie ersetzen keine vollständige Lektüre der Quellen. ^{[S-001; S-014; S-038; S-123]}

Transformer und autoregressive Inferenz

Post-Training und Instruktionsbefolgung

Langer Kontext und Lost in the Middle

Klassisches RAG

Dense Retrieval und Embeddings

Hybrid Retrieval und Reranking

Hierarchisches und graphbasiertes Retrieval

Tool Calling

MCP als Interoperabilitätsschicht

ReAct und agentische Schleifen

Agenten in realistischen Umgebungen

Externes Memory

Fine-Tuning und Adapter

Strukturierte Ausgaben

Queues und Zustellsemantik

Durable Workflow

OAuth, OIDC und MCP-Autorisierung

Observability und Evaluation

Achtzehn vollständige Referenzarchitekturen

ARCHITEKTUR-SYNTHESE: Die Referenzarchitekturen sind neutrale Entwurfsmuster. Sie kombinieren belegte technische Bausteine mit klar als Synthese erkennbaren Entscheidungen. Konkrete Rechts-, Sicherheits-, Last- und Kostenanforderungen müssen je Projekt ergänzt werden. ^{[S-116; S-067; S-071]}

A1 - Stateless Schreib- und Zusammenfassungsassistent

A2 - Strukturierte Dokumentextraktion

A3 - Wissensassistent mit klassischem RAG

A4 - Enterprise Search ohne Generierung

A5 - Kundenservice mit Ticket- und CRM-Aktion

A6 - E-Mail zu CRM mit Freigabeschritt

A7 - Text-to-SQL mit Read-only-Sicherheitsgrenze

A8 - Deterministische Dokumentklassifikation mit KI-Ausnahme

A9 - Angebotserstellung mit menschlicher Freigabe

A10 - Begrenzter Rechercheagent

A11 - Multi-Tenant SaaS-Assistent

A12 - Lokaler vertraulicher Assistent

A13 - Batch-Anreicherung großer Datenbestände

A14 - Ereignisgetriebene Anomalie-Erklärung

A15 - Website-Chatbot mit RAG und Eskalation

A16 - Persönliches Arbeitsgedächtnis

A17 - Coding-Agent in Sandbox

A18 - Kein-KI-Referenz: Regelbasierter Genehmigungsprozess

Entscheidungs- und Auswahlmatrizen

Welcher Baustein löst welches Problem?

Welcher Speicher für welchen Zustand?

RAG, langer Kontext, Fine-Tuning oder Tool?

ARCHITEKTUR-SYNTHESE: Diese Optionen schließen sich nicht aus. Ein System kann aktuelle Dokumente über RAG, Live-Status über Tools und stabiles Extraktionsverhalten über Prompt oder Fine-Tuning kombinieren. Entscheidend ist, welcher Zustand wo autoritativ geführt wird. ^{[S-014; S-009; S-054; S-075]}

Cron, Queue, Event oder Workflow?

Agent oder Workflow?

Architektur-Risikoscore

Orientierung: 0-5 Punkte: einfacher, kontrollierter Assistent. 6-10: internes System mit formalen Evals und Betrieb. 11-15: erfahrenes Team, starke Sicherheits- und Freigabegrenzen. 16-21: Spezialverfahren; freie Agentenautonomie ist regelmäßig unangemessen. Der Score ist ein redaktioneller Referenzrahmen, keine Rechts- oder Zertifizierungsklassifikation.

``mermaid flowchart TD A[Problem] --> B{Exakte bekannte Regeln?} B -- Ja --> C[Klassischer Code / DMN] B -- Nein --> D{Prozessschritte bekannt?} D -- Ja --> E[Workflow mit begrenztem KI-Schritt] D -- Nein --> F{Offene Sprach-/Suchaufgabe?} F -- Nein --> G[Anforderung klären / keine KI] F -- Ja --> H[Begrenzter Agent] H --> I[Tools, Budget, Stop, Evals, Human Gate] ``

36-stufiger Referenzweg vom Problem zum Betrieb

ARCHITEKTUR-SYNTHESE: Der Referenzweg beginnt bewusst vor Modell- und Toolwahl. Er verbindet Fachprozess, Daten, Systemdesign, Sicherheit, Evaluation und Betrieb. Schritte können iterativ durchlaufen werden; ausgelassen werden sollten sie nur mit dokumentierter Begründung. ^{[S-116; S-071; S-122; S-123]}

Phase A - Problem und Risiko

Phase B - Daten, Identität und Verantwortung

Phase C - Komponenten und Schnittstellen

Phase D - Prozess, Asynchronität und Sicherheit

Phase E - Evaluation und Belastungstest

Phase F - Release und laufender Betrieb

Zwanzig Mythen im Faktencheck

Mythos 1: Ein großes Modell ist bereits eine vollständige Anwendung.

FAKTENCHECK: Falsch. Modellzugang, Daten, Rechte, Tools, Zustände, Tests und Betrieb sind eigenständige Bausteine. ^{[S-001; S-116; S-123]}

Mythos 2: Mehr Kontext löst jedes Wissensproblem.

FAKTENCHECK: Falsch. Relevanz, Position, Aktualität und Zugriffskontrolle bleiben begrenzende Faktoren. ^{[S-013; S-026]}

Mythos 3: RAG verhindert Halluzinationen.

FAKTENCHECK: Falsch. RAG kann Quellen bereitstellen; Retrieval und Generierung können weiterhin scheitern. ^{[S-014; S-027]}

Mythos 4: Eine Vektordatenbank ersetzt SQL.

FAKTENCHECK: Falsch. Ähnlichkeitssuche ersetzt keine Transaktionen, Constraints oder referenzielle Integrität. ^{[S-034; S-075]}

Mythos 5: Embeddings verstehen Wahrheit.

FAKTENCHECK: Falsch. Sie liefern Repräsentationen für Ähnlichkeit und müssen domänenspezifisch evaluiert werden. ^{[S-030; S-028]}

Mythos 6: Structured Output macht die Antwort korrekt.

FAKTENCHECK: Falsch. Ein gültiges Schema kann sachlich falsche Werte enthalten. ^{[S-059; S-057]}

Mythos 7: Tool Calling bedeutet, dass das Modell das Tool sicher ausführt.

FAKTENCHECK: Falsch. Die Anwendung führt aus und trägt Verantwortung für Validierung und Rechte. ^{[S-054; S-115]}

Mythos 8: MCP macht alle Tools automatisch vertrauenswürdig.

FAKTENCHECK: Falsch. MCP verbessert Interoperabilität; Trust, Codequalität und Berechtigung bleiben offen. ^{[S-060; S-062]}

Mythos 9: Ein Agent ist nur ein längerer Prompt.

FAKTENCHECK: Falsch. Agenten benötigen Zustand, Schleife, Werkzeuge, Budgets, Abbruch und Beobachtbarkeit. ^{[S-038; S-045]}

Mythos 10: Mehr Agenten bedeuten automatisch bessere Ergebnisse.

FAKTENCHECK: Falsch. Koordination erhöht Kommunikation, Kosten und neue Fehlermodi. ^{[S-053; S-045]}

Mythos 11: Memory bedeutet, einfach jeden Chat zu speichern.

FAKTENCHECK: Falsch. Auswahl, Typ, Herkunft, Zeit, Scope und Löschung sind zentrale Designfragen. ^{[S-048; S-051]}

Mythos 12: Fine-Tuning ist die beste Methode für aktuelle Unternehmensdaten.

FAKTENCHECK: Meist falsch. Änderbares Wissen passt oft besser zu Retrieval oder APIs. ^{[S-014; S-009]}

Mythos 13: Webhooks werden genau einmal zugestellt.

FAKTENCHECK: Falsch. Duplikate, Verzögerung und Retry sind normale Entwurfsfälle. ^{[S-077; S-079]}

Mythos 14: Eine Queue verhindert Datenverlust automatisch.

FAKTENCHECK: Falsch. Acknowledgements, Persistenz, Dead Letters und Betriebskonfiguration entscheiden. ^{[S-083; S-084]}

Mythos 15: Cron ist eine Workflow-Engine.

FAKTENCHECK: Falsch. Cron startet zeitgesteuert; es verwaltet keine robuste mehrstufige Prozesshistorie. ^{[S-087; S-086]}

Mythos 16: OAuth sagt der Anwendung, was ein Nutzer fachlich darf.

FAKTENCHECK: Falsch. OAuth delegiert Zugriff; Objekt- und Fachautorisierung bleibt Sache der Anwendung. ^{[S-097; S-110]}

Mythos 17: JWT ist automatisch sicher, weil es signiert ist.

FAKTENCHECK: Falsch. Algorithmus, Claims, Audience, Schlüssel und Validierung müssen korrekt behandelt werden. ^{[S-102; S-103]}

Mythos 18: TLS macht eine KI-Anwendung sicher.

FAKTENCHECK: Falsch. TLS schützt Transport, nicht Rechte, Prompt Injection, Endpunkte oder Logs. ^{[S-105; S-113]}

Mythos 19: Ein guter Demo-Chatbot braucht keine Evals.

FAKTENCHECK: Falsch. Demoqualität sagt wenig über Randfälle, Datenänderungen und Produktionsverhalten. ^{[S-122; S-120]}

Mythos 20: KI sollte überall eingebaut werden, wo es technisch möglich ist.

FAKTENCHECK: Falsch. Bei klaren Regeln und exakten Berechnungen ist klassische Software häufig geeigneter. ^{[S-072; S-071]}

Zwanzig offene Forschungs- und Praxisfragen

Einordnung: „Offen“ bedeutet nicht, dass keine brauchbare Architektur möglich ist. Es bedeutet, dass die Entscheidung stärker lokal gemessen, begrenzt und regelmäßig aktualisiert werden muss.

50 buchrelevante Faktenkarten

Glossar

Agent

Softwarekomponente, die Ziele über mehrere Schritte verfolgt, Zustand beobachtet und Werkzeuge aufruft.

Agent Loop

Wiederholte Folge aus Beobachten, Entscheiden/Planen, Handeln, Bewerten und Abbruchprüfung.

ANN

Approximate Nearest Neighbor; beschleunigte Näherungssuche nach ähnlichen Vektoren.

API

Programmierschnittstelle mit definierten Requests, Responses, Fehlern und Authentisierung.

API Gateway

Zwischenschicht für Routing, Limits, Authentisierung, Observability und Policies vor APIs.

API Key

Geheimwert zur Identifizierung oder Autorisierung eines Clients; sollte gescoped und rotierbar sein.

AsyncAPI

Spezifikation zur Beschreibung ereignisgetriebener Schnittstellen.

At-least-once

Zustellsemantik, bei der eine Nachricht mindestens einmal, möglicherweise mehrfach ankommt.

Authentication

Nachweis einer Identität.

Authorization

Entscheidung, welche Aktion eine Identität auf einer Ressource ausführen darf.

Batch

Gebündelte, nicht interaktive Verarbeitung vieler Einheiten.

BPMN

Standard zur Modellierung von Geschäftsprozessen.

Cache

Temporäre Wiederverwendung bereits berechneter oder geladener Ergebnisse.

Chunk

Teil eines Dokuments, der separat indiziert oder in Modellkontext gestellt wird.

CloudEvents

Standardisiertes Format für Ereignismetadaten.

Context Window

Maximale Tokenmenge, die ein Modellaufruf als Eingabe plus Ausgabe verarbeiten kann.

Continuous Batching

Dynamisches Zusammenfassen laufender Inferenzanfragen für höhere Hardwareauslastung.

Cron

Zeitbasierter Auslöser für wiederkehrende Jobs.

Dead Letter Queue

Ablage für Nachrichten, die nach definierten Versuchen nicht verarbeitet werden konnten.

Dense Retrieval

Semantische Suche über dichte Vektorrepräsentationen.

Distillation

Übertragung von Verhalten eines größeren Lehrer- auf ein kleineres Schülermodell.

DMN

Standard zur formalen Modellierung von Entscheidungsregeln.

Deduplizierung

Erkennen und Verhindern mehrfacher fachlicher Verarbeitung derselben Nachricht.

Embedding

Numerische Vektorrepräsentation eines Inhalts.

Event

Unveränderliche Meldung, dass etwas geschehen ist.

Event Bus

Infrastruktur zur Verteilung von Ereignissen an Konsumenten.

Fine-Tuning

Anpassung von Modellparametern oder Adaptern mit zusätzlichen Trainingsdaten.

Function Calling

Mechanismus, bei dem ein Modell Werkzeugname und strukturierte Argumente vorschlägt.

Gateway

Kontroll- und Routing-Schicht zwischen Clients und nachgelagerten Diensten.

GraphRAG

RAG-Ansatz, der Entitäten und Beziehungen graphbasiert organisiert und durchsucht.

Grounding

Bindung einer Ausgabe an bereitgestellte Daten, Quellen oder Werkzeuge.

HNSW

Graphbasierter ANN-Index für schnelle Vektorsuche.

Human-in-the-loop

Gezielter menschlicher Prüf- oder Freigabeschritt mit klarer Entscheidungskompetenz.

Hybrid Search

Kombination lexikalischer und semantischer Suchsignale.

Idempotenz

Eigenschaft, dass wiederholte Ausführung dieselbe fachliche Wirkung wie einmalige Ausführung hat.

Ingestion

Aufnahme, Parsing, Bereinigung und Vorbereitung von Daten für Suche oder Verarbeitung.

Inference

Ausführung eines trainierten Modells auf Eingaben.

JSON Schema

Spezifikation zur Beschreibung und Validierung von JSON-Strukturen.

JWT

Kompaktes Tokenformat für Claims; Sicherheit hängt von korrekter Validierung ab.

KV-Cache

Zwischenspeicher von Key-/Value-Zuständen während autoregressiver Inferenz.

Latency

Zeit zwischen Anfrage und nutzbarem Ergebnis.

Least Privilege

Vergabe nur der minimal notwendigen Rechte.

Lexical Search

Suche nach Wörtern, Termen und exakten Zeichenfolgen.

LLM

Large Language Model; großes Sprachmodell zur Tokenvorhersage und Sprachverarbeitung.

LLM-as-a-Judge

Verwendung eines Sprachmodells zur Bewertung anderer Modellausgaben.

LoRA

Low-Rank Adaptation; parametereffiziente Modellanpassung über Zusatzmatrizen.

Memory

Externe oder interne Mechanismen zur Wiederverwendung früherer Informationen.

MCP

Model Context Protocol; Protokoll zur Verbindung von KI-Hosts, Clients und Werkzeug-/Datenservern.

Metadata Filter

Einschränkung von Suchkandidaten anhand strukturierter Attribute.

Model Gateway

Abstraktionsschicht vor einem oder mehreren Modellanbietern.

Model Routing

Auswahl eines Modells nach Aufgabe, Kosten, Latenz, Risiko oder Verfügbarkeit.

Multi-Tenancy

Gemeinsamer Dienst für mehrere Mandanten mit strikter Datentrennung.

OAuth 2.0

Framework für delegierte Autorisierung.

Object Store

Speicher für Dateien/Objekte mit Schlüssel, Metadaten und häufig Versionierung.

Observability

Fähigkeit, Systemzustand über Traces, Metriken und Logs zu verstehen.

OIDC

OpenID Connect; Identitätsschicht auf OAuth 2.0.

OpenAPI

Spezifikation zur Beschreibung synchroner HTTP-APIs.

Orchestrator

Komponente, die Schritte, Zustände, Tools und Fehlerpfade koordiniert.

PagedAttention

Speicherverwaltungsansatz für KV-Caches beim LLM-Serving.

Policy Engine

Komponente, die formale Zugriffs- oder Geschäftsregeln auswertet.

Prompt

Anweisungen und Kontext, die einem Modell für einen Aufruf bereitgestellt werden.

Prompt Cache

Wiederverwendung eines identischen oder stabilen Prompt-Präfixes.

Prompt Injection

Angriff oder Fehlermuster, bei dem untrusted Text das Modellverhalten unzulässig beeinflusst.

Provenance

Nachweis von Herkunft, Version und Verarbeitung eines Daten- oder Antwortbestandteils.

Queue

Warteschlange zur asynchronen Entkopplung von Produzent und Konsument.

RAG

Retrieval-Augmented Generation; Generierung mit zur Laufzeit abgerufenen externen Informationen.

Rate Limit

Begrenzung von Aufrufen pro Zeit oder Budget.

Relational Database

Datenbank mit Tabellen, Schlüsseln, Constraints und Transaktionen.

Reranker

Modell oder Verfahren, das Retrieval-Kandidaten präziser neu sortiert.

Retry

Wiederholung einer fehlgeschlagenen Operation.

Schema

Formale Beschreibung erwarteter Datenstruktur.

Semantic Search

Suche anhand inhaltlicher Ähnlichkeit statt nur exakter Wörter.

Structured Output

Modellausgabe, die einem vorgegebenen maschinenlesbaren Schema folgt.

System of Record

Führendes, autoritatives System für einen Geschäftsdatenbestand.

TLS

Transport Layer Security; Schutz von Netzwerkverbindungen.

Token

Kleinste vom Modell verarbeitete Text- oder Symbolsequenz.

Tool

Externe Funktion, API oder Ressource, die ein Modell nicht selbst ausführt.

Trace

Verknüpfte Telemetriespur eines Requests über mehrere Komponenten.

Vector Database

Speicher- und Indexsystem für Ähnlichkeitssuche über Vektoren.

Webhook

HTTP-basierte Benachrichtigung über ein Ereignis.

Workflow Engine

System zur kontrollierten Ausführung mehrstufiger Prozesse mit Zustand und Fehlerpfaden.

Quellen- und Belegmatrix

LESEHINWEIS: Die 50 Kernaussagen sind die zentrale Belegmatrix. Status und Refresh-Priorität kennzeichnen, wie die Aussage im Buch weiterverwendet werden darf. Herstellerquellen belegen Produktfunktionen am Stichtag, nicht unabhängige Wirksamkeit. ^{[S-122; S-116]}

Quellengruppen nach Verwendung

Vollständiges Quellenregister

Abruf- und Prüfstand: 8. August 2026, sofern nicht anders angegeben. Living Documents und Produktdokumentationen müssen vor Buchveröffentlichung erneut geöffnet werden. Direkte URLs sind vollständig angegeben.

APIs und Datenverträge

^[S-059] JSON Schema: A Media Type for Describing JSON Documents - Draft 2020-12

• Autor/Herausgeber: JSON Schema project
• Datum: 31.08.2022
• Dokumenttyp: Offizieller Spezifikationsstand
• Status: Standard / Spezifikation
• Relevanz: Maschinenlesbare Validierungs- und Beschreibungsschemata.
• Refresh-Priorität: mittel
• Direkte URL: [https://json-schema.org/draft/2020-12/json-schema-core](https://json-schema.org/draft/2020-12/json-schema-core)

^[S-065] RFC 9110: HTTP Semantics

• Autor/Herausgeber: IETF / Fielding, Nottingham und Reschke
• Datum: 06.2022
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: HTTP-Methoden, Semantik, Statuscodes und Idempotenzgrundlagen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9110.html](https://www.rfc-editor.org/rfc/rfc9110.html)

^[S-066] RFC 9111: HTTP Caching

• Autor/Herausgeber: IETF / Fielding, Nottingham und Reschke
• Datum: 06.2022
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Caching-Semantik für HTTP.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9111.html](https://www.rfc-editor.org/rfc/rfc9111.html)

^[S-067] OpenAPI Specification 3.2.0

• Autor/Herausgeber: OpenAPI Initiative
• Datum: 19.09.2025
• Dokumenttyp: Offizielle Spezifikation
• Status: Aktueller Spezifikationsstand
• Relevanz: Maschinenlesbare Beschreibung synchroner HTTP-APIs.
• Refresh-Priorität: hoch
• Direkte URL: [https://spec.openapis.org/oas/v3.2.0.html](https://spec.openapis.org/oas/v3.2.0.html)

^[S-068] RFC 9457: Problem Details for HTTP APIs

• Autor/Herausgeber: IETF / Nottingham, Wilde und Dalal
• Datum: 07.2023
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Standardisierte Fehlerobjekte für HTTP-APIs.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9457.html](https://www.rfc-editor.org/rfc/rfc9457.html)

Agenten und Tools

^[S-038] ReAct: Synergizing Reasoning and Acting in Language Models

• Autor/Herausgeber: Yao et al.
• Datum: 06.10.2022
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (ICLR 2023)
• Relevanz: Grundmuster für abwechselndes Schlussfolgern und Werkzeughandeln.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2210.03629](https://arxiv.org/abs/2210.03629)

^[S-039] Toolformer: Language Models Can Teach Themselves to Use Tools

• Autor/Herausgeber: Schick et al.
• Datum: 09.02.2023
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (NeurIPS 2023)
• Relevanz: Werkzeugnutzung als erlernte Modellfähigkeit.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2302.04761](https://arxiv.org/abs/2302.04761)

^[S-040] MRKL Systems: A modular, neuro-symbolic architecture that combines large language models, external knowledge sources and discrete reasoning

• Autor/Herausgeber: Karpas et al.
• Datum: 01.05.2022
• Dokumenttyp: Originalarbeit / arXiv
• Status: Forschungsarbeit
• Relevanz: Modulare Verbindung von Modell und externen Expertenwerkzeugen.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2205.00445](https://arxiv.org/abs/2205.00445)

^[S-041] Reflexion: Language Agents with Verbal Reinforcement Learning

• Autor/Herausgeber: Shinn et al.
• Datum: 20.03.2023
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (NeurIPS 2023)
• Relevanz: Agentische Selbstreflexion über Feedback und episodisches Gedächtnis.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2303.11366](https://arxiv.org/abs/2303.11366)

^[S-042] Language Agent Tree Search Unifies Reasoning Acting and Planning in Language Models

• Autor/Herausgeber: Zhou et al.
• Datum: 06.10.2023
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (ICML 2024)
• Relevanz: Baumsuche für agentisches Planen und Handeln.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2310.04406](https://arxiv.org/abs/2310.04406)

^[S-043] WebArena: A Realistic Web Environment for Building Autonomous Agents

• Autor/Herausgeber: Zhou et al.
• Datum: 25.07.2023
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (ICLR 2024)
• Relevanz: Benchmark realer Webaufgaben und Grenzen autonomer Agenten.
• Refresh-Priorität: hoch
• Direkte URL: [https://arxiv.org/abs/2307.13854](https://arxiv.org/abs/2307.13854)

^[S-044] AgentBench: Evaluating LLMs as Agents

• Autor/Herausgeber: Liu et al.
• Datum: 07.08.2023
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (ICLR 2024)
• Relevanz: Mehrumgebungs-Benchmark für Sprachmodellagenten.
• Refresh-Priorität: hoch
• Direkte URL: [https://arxiv.org/abs/2308.03688](https://arxiv.org/abs/2308.03688)

^[S-045] AI Agents That Matter

• Autor/Herausgeber: Kapoor et al.
• Datum: 01.07.2024
• Dokumenttyp: Originalarbeit / arXiv
• Status: Forschungsarbeit
• Relevanz: Kritik an Agentenbenchmarks, Kosten- und Reproduzierbarkeitsanforderungen.
• Refresh-Priorität: hoch
• Direkte URL: [https://arxiv.org/abs/2407.01502](https://arxiv.org/abs/2407.01502)

^[S-046] Beyond Browsing: API-Based Web Agents

• Autor/Herausgeber: Lu et al.
• Datum: 21.10.2024
• Dokumenttyp: Originalarbeit / arXiv
• Status: Preprint
• Relevanz: API-basierte statt rein visueller Webinteraktion.
• Refresh-Priorität: hoch
• Direkte URL: [https://arxiv.org/abs/2410.16464](https://arxiv.org/abs/2410.16464)

^[S-052] Voyager: An Open-Ended Embodied Agent with Large Language Models

• Autor/Herausgeber: Wang et al.
• Datum: 25.05.2023
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Beitrag
• Relevanz: Skill-Bibliothek und iteratives Lernen eines Agenten.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2305.16291](https://arxiv.org/abs/2305.16291)

^[S-053] MultiAgentBench: Evaluating the Collaboration and Competition of LLM Agents

• Autor/Herausgeber: Zhu et al.
• Datum: 03.03.2025
• Dokumenttyp: Originalarbeit / arXiv
• Status: Preprint
• Relevanz: Mehragenten-Koordination und Benchmarking.
• Refresh-Priorität: hoch
• Direkte URL: [https://arxiv.org/abs/2503.01935](https://arxiv.org/abs/2503.01935)

Anbieter-Dokumentation

^[S-036] Retrieval guide

• Autor/Herausgeber: OpenAI
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Aktueller Produktstand für gehostetes Retrieval und Vektorspeicher.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.openai.com/api/docs/guides/retrieval](https://developers.openai.com/api/docs/guides/retrieval)

^[S-037] Embeddings with the Gemini API

• Autor/Herausgeber: Google
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Aktueller Produktstand für Embeddings.
• Refresh-Priorität: hoch
• Direkte URL: [https://ai.google.dev/gemini-api/docs/embeddings](https://ai.google.dev/gemini-api/docs/embeddings)

^[S-054] Function calling guide

• Autor/Herausgeber: OpenAI
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Aktueller Produktmechanismus für modellseitige Werkzeugaufrufe.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.openai.com/api/docs/guides/function-calling](https://developers.openai.com/api/docs/guides/function-calling)

^[S-055] Tool use with Claude

• Autor/Herausgeber: Anthropic
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Aktueller Produktmechanismus für Werkzeugdefinition und -aufruf.
• Refresh-Priorität: hoch
• Direkte URL: [https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview)

^[S-056] Function calling with the Gemini API

• Autor/Herausgeber: Google
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Aktueller Produktmechanismus für Funktionsaufrufe.
• Refresh-Priorität: hoch
• Direkte URL: [https://ai.google.dev/gemini-api/docs/function-calling](https://ai.google.dev/gemini-api/docs/function-calling)

^[S-057] Structured Outputs guide

• Autor/Herausgeber: OpenAI
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Schema-konforme strukturierte Modellausgaben.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.openai.com/api/docs/guides/structured-outputs](https://developers.openai.com/api/docs/guides/structured-outputs)

^[S-058] Structured outputs with the Gemini API

• Autor/Herausgeber: Google
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Schema-konforme strukturierte Modellausgaben.
• Refresh-Priorität: hoch
• Direkte URL: [https://ai.google.dev/gemini-api/docs/structured-output](https://ai.google.dev/gemini-api/docs/structured-output)

^[S-064] MCP connector and Claude Code MCP documentation

• Autor/Herausgeber: Anthropic
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Produktintegration von MCP.
• Refresh-Priorität: hoch
• Direkte URL: [https://platform.claude.com/docs/en/agents-and-tools/mcp-connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector)

Anpassung und Training

^[S-009] LoRA: Low-Rank Adaptation of Large Language Models

• Autor/Herausgeber: Hu et al.
• Datum: 17.06.2021
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (ICLR 2022)
• Relevanz: Parametereffizientes Fine-Tuning über Low-Rank-Adapter.
• Refresh-Priorität: niedrig
• Direkte URL: [https://arxiv.org/abs/2106.09685](https://arxiv.org/abs/2106.09685)

^[S-010] QLoRA: Efficient Finetuning of Quantized LLMs

• Autor/Herausgeber: Dettmers et al.
• Datum: 23.05.2023
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (NeurIPS 2023)
• Relevanz: Speichereffizientes Fine-Tuning quantisierter Modelle.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2305.14314](https://arxiv.org/abs/2305.14314)

^[S-011] Direct Preference Optimization: Your Language Model is Secretly a Reward Model

• Autor/Herausgeber: Rafailov et al.
• Datum: 29.05.2023
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (NeurIPS 2023)
• Relevanz: Präferenzoptimierung als Alternative zu komplexeren RLHF-Pipelines.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2305.18290](https://arxiv.org/abs/2305.18290)

^[S-012] Distilling the Knowledge in a Neural Network

• Autor/Herausgeber: Hinton, Vinyals und Dean
• Datum: 09.03.2015
• Dokumenttyp: Originalarbeit / arXiv
• Status: Forschungsarbeit
• Relevanz: Grundidee der Wissensdistillation.
• Refresh-Priorität: niedrig
• Direkte URL: [https://arxiv.org/abs/1503.02531](https://arxiv.org/abs/1503.02531)

Caching und Kosten

^[S-094] Prompt caching

• Autor/Herausgeber: Anthropic
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Anbietermechanismus zur Wiederverwendung großer Prompt-Präfixe.
• Refresh-Priorität: hoch
• Direkte URL: [https://platform.claude.com/docs/en/build-with-claude/prompt-caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)

^[S-095] Prompt caching guide

• Autor/Herausgeber: OpenAI
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Anbietermechanismus zur Wiederverwendung von Prompt-Präfixen.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.openai.com/api/docs/guides/prompt-caching](https://developers.openai.com/api/docs/guides/prompt-caching)

^[S-096] Context caching with the Gemini API

• Autor/Herausgeber: Google
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Anbietermechanismus zur Speicherung und Wiederverwendung von Kontext.
• Refresh-Priorität: hoch
• Direkte URL: [https://ai.google.dev/gemini-api/docs/caching](https://ai.google.dev/gemini-api/docs/caching)

Daten und Suche

^[S-033] PostgreSQL 18 Documentation: Full Text Search

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Veröffentlichungsdatum UNKLAR; Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Dokumentation
• Status: Living Documentation
• Relevanz: Lexikalische Volltextsuche und Ranking in einer relationalen Datenbank.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/18/textsearch.html](https://www.postgresql.org/docs/18/textsearch.html)

^[S-034] pgvector: Open-source vector similarity search for Postgres

• Autor/Herausgeber: pgvector project
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Vektorsuche innerhalb PostgreSQL.
• Refresh-Priorität: hoch
• Direkte URL: [https://github.com/pgvector/pgvector](https://github.com/pgvector/pgvector)

^[S-035] Hybrid search with Elasticsearch

• Autor/Herausgeber: Elastic
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Kombination lexikalischer und semantischer Suche, einschließlich RRF.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.elastic.co/docs/solutions/search/hybrid-search](https://www.elastic.co/docs/solutions/search/hybrid-search)

^[S-073] PostgreSQL 18 Released

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: 25.09.2025
• Dokumenttyp: Offizielle Release-Mitteilung
• Status: Aktueller Major-Release am Stichtag
• Relevanz: Aktueller Versionsstand der relationalen Referenzdatenbank.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/about/news/postgresql-18-released-3142/](https://www.postgresql.org/about/news/postgresql-18-released-3142/)

^[S-074] PostgreSQL 18 Documentation: Concurrency Control

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Veröffentlichungsdatum UNKLAR; Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Dokumentation
• Status: Living Documentation
• Relevanz: Transaktionen, Isolation und MVCC.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/18/mvcc.html](https://www.postgresql.org/docs/18/mvcc.html)

^[S-075] PostgreSQL 18 Documentation: Transactions

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Veröffentlichungsdatum UNKLAR; Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Dokumentation
• Status: Living Documentation
• Relevanz: Atomare Änderungen und Rollback in relationalen Datenbanken.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/18/tutorial-transactions.html](https://www.postgresql.org/docs/18/tutorial-transactions.html)

^[S-076] Amazon S3 User Guide

• Autor/Herausgeber: Amazon Web Services
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Objektspeicher für Dateien und große Binärdaten.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)

Deployment und Betrieb

^[S-087] CronJob

• Autor/Herausgeber: Kubernetes
• Datum: 13.05.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Aktueller Dokumentationsstand
• Relevanz: Zeitgesteuerte Jobs in Kubernetes.
• Refresh-Priorität: hoch
• Direkte URL: [https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/)

^[S-088] Jobs

• Autor/Herausgeber: Kubernetes
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Endliche Batch-Aufgaben und Wiederholungslogik.
• Refresh-Priorität: hoch
• Direkte URL: [https://kubernetes.io/docs/concepts/workloads/controllers/job/](https://kubernetes.io/docs/concepts/workloads/controllers/job/)

^[S-089] Deployments

• Autor/Herausgeber: Kubernetes
• Datum: 18.06.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Aktueller Dokumentationsstand
• Relevanz: Deklarative Rollouts und Rollbacks zustandsloser Anwendungen.
• Refresh-Priorität: hoch
• Direkte URL: [https://kubernetes.io/docs/concepts/workloads/controllers/deployment/](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)

Evaluation

^[S-027] RAGAs: Automated Evaluation of Retrieval Augmented Generation

• Autor/Herausgeber: Es et al.
• Datum: 03.2024
• Dokumenttyp: Peer-reviewter Konferenzbeitrag
• Status: EACL 2024 System Demonstrations
• Relevanz: Komponentenbezogene Evaluation von RAG-Systemen.
• Refresh-Priorität: mittel
• Direkte URL: [https://aclanthology.org/2024.eacl-demo.16/](https://aclanthology.org/2024.eacl-demo.16/)

^[S-120] Holistic Evaluation of Language Models

• Autor/Herausgeber: Liang et al.
• Datum: 16.11.2022
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Beitrag (TMLR 2023)
• Relevanz: Mehrdimensionale, reproduzierbare Modellevaluation.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2211.09110](https://arxiv.org/abs/2211.09110)

^[S-121] G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment

• Autor/Herausgeber: Liu et al.
• Datum: 29.03.2023
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Beitrag (EMNLP 2023)
• Relevanz: LLM-basierte Bewertung und deren Bias-Risiken.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2303.16634](https://arxiv.org/abs/2303.16634)

^[S-122] Define success criteria and build evaluations

• Autor/Herausgeber: Anthropic
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Aufgabenspezifische Evals, Rubrics und Grading-Methoden.
• Refresh-Priorität: hoch
• Direkte URL: [https://platform.claude.com/docs/en/test-and-evaluate/develop-tests](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests)

Events und Workflows

^[S-069] CloudEvents Specification 1.0.2

• Autor/Herausgeber: Cloud Native Computing Foundation
• Datum: 03.02.2022
• Dokumenttyp: Offizielle Spezifikation
• Status: CNCF-Spezifikation
• Relevanz: Standardisiertes Ereignisformat für verteilte Systeme.
• Refresh-Priorität: mittel
• Direkte URL: [https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md](https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md)

^[S-070] AsyncAPI Specification 3.1.0

• Autor/Herausgeber: AsyncAPI Initiative
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Spezifikation
• Status: Aktueller Spezifikationsstand
• Relevanz: Maschinenlesbare Beschreibung ereignisgetriebener APIs.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.asyncapi.com/docs/reference/specification/v3.1.0](https://www.asyncapi.com/docs/reference/specification/v3.1.0)

^[S-071] Business Process Model and Notation (BPMN) Version 2.0.2

• Autor/Herausgeber: Object Management Group
• Datum: 01.2014
• Dokumenttyp: Offizielle Norm
• Status: OMG-Spezifikation
• Relevanz: Modellierung deterministischer Geschäftsprozesse.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.omg.org/spec/BPMN/2.0.2/](https://www.omg.org/spec/BPMN/2.0.2/)

^[S-072] Decision Model and Notation (DMN) Version 1.5

• Autor/Herausgeber: Object Management Group
• Datum: 08.2024
• Dokumenttyp: Offizielle Norm
• Status: OMG-Spezifikation
• Relevanz: Explizite, regelbasierte Entscheidungslogik.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.omg.org/spec/DMN/1.5/](https://www.omg.org/spec/DMN/1.5/)

^[S-077] Receive Stripe events in your webhook endpoint

• Autor/Herausgeber: Stripe
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Signaturprüfung, Retries und Ereigniszustellung bei Webhooks.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.stripe.com/webhooks](https://docs.stripe.com/webhooks)

^[S-078] Idempotent requests and error handling

• Autor/Herausgeber: Stripe
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Idempotenzschlüssel für wiederholbare API-Aufrufe.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.stripe.com/api/idempotent_requests](https://docs.stripe.com/api/idempotent_requests)

^[S-079] Event and Webhook Delivery Semantics

• Autor/Herausgeber: Panke
• Datum: 28.06.2026
• Dokumenttyp: IETF Internet-Draft
• Status: Entwurf; kein finaler Standard
• Relevanz: Aktueller Entwurf zu Zustellsemantik, Retries, Deduplizierung und Idempotenz.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://datatracker.ietf.org/doc/draft-mayankpanke-event-delivery-semantics/](https://datatracker.ietf.org/doc/draft-mayankpanke-event-delivery-semantics/)

^[S-082] Work Queues Tutorial

• Autor/Herausgeber: RabbitMQ
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Arbeitswarteschlangen zur Entkopplung und Lastverteilung.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.rabbitmq.com/tutorials/tutorial-two-python](https://www.rabbitmq.com/tutorials/tutorial-two-python)

^[S-083] Consumer Acknowledgements and Publisher Confirms

• Autor/Herausgeber: RabbitMQ
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Bestätigungen und Zustellsemantik.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.rabbitmq.com/docs/confirms](https://www.rabbitmq.com/docs/confirms)

^[S-084] Kafka 4.3 Documentation: Design and delivery semantics

• Autor/Herausgeber: Apache Kafka
• Datum: 22.05.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Aktueller Dokumentationsstand
• Relevanz: Partitionierte Ereignislogs und Zustellsemantik.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://kafka.apache.org/43/documentation/](https://kafka.apache.org/43/documentation/)

^[S-085] Durable Execution and Temporal Platform Documentation

• Autor/Herausgeber: Temporal Technologies
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Dauerhafte Workflows, Wiederaufnahme und Orchestrierung.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.temporal.io/](https://docs.temporal.io/)

^[S-086] Workflow Execution Event History

• Autor/Herausgeber: Temporal Technologies
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Ereignishistorie als Grundlage deterministischer Wiederaufnahme.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.temporal.io/workflow-execution/event](https://docs.temporal.io/workflow-execution/event)

Identität und Sicherheit

^[S-097] RFC 6749: The OAuth 2.0 Authorization Framework

• Autor/Herausgeber: IETF / Hardt
• Datum: 10.2012
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Delegierte Autorisierung und Rollenmodell.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc6749.html](https://www.rfc-editor.org/rfc/rfc6749.html)

^[S-098] RFC 9700: Best Current Practice for OAuth 2.0 Security

• Autor/Herausgeber: IETF / Lodderstedt, Bradley, Labunets und Fett
• Datum: 01.2025
• Dokumenttyp: Best Current Practice
• Status: RFC
• Relevanz: Aktuelle Sicherheitsanforderungen für OAuth 2.0.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9700.html](https://www.rfc-editor.org/rfc/rfc9700.html)

^[S-099] OpenID Connect Core 1.0 incorporating errata set 2

• Autor/Herausgeber: OpenID Foundation
• Datum: 15.12.2023
• Dokumenttyp: Offizielle Spezifikation
• Status: Final Specification
• Relevanz: Identitätsschicht auf OAuth 2.0.
• Refresh-Priorität: mittel
• Direkte URL: [https://openid.net/specs/openid-connect-core-1_0.html](https://openid.net/specs/openid-connect-core-1_0.html)

^[S-100] RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage

• Autor/Herausgeber: IETF / Jones und Hardt
• Datum: 10.2012
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Verwendung und Risiken von Bearer Tokens.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc6750.html](https://www.rfc-editor.org/rfc/rfc6750.html)

^[S-101] RFC 7636: Proof Key for Code Exchange by OAuth Public Clients

• Autor/Herausgeber: IETF / Sakimura, Bradley und Agarwal
• Datum: 09.2015
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Schutz des Authorization Code Flow für öffentliche Clients.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc7636.html](https://www.rfc-editor.org/rfc/rfc7636.html)

^[S-102] RFC 7519: JSON Web Token (JWT)

• Autor/Herausgeber: IETF / Jones, Bradley und Sakimura
• Datum: 05.2015
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Kompaktes Claims-Format für signierte oder verschlüsselte Tokens.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc7519.html](https://www.rfc-editor.org/rfc/rfc7519.html)

^[S-103] RFC 8725: JSON Web Token Best Current Practices

• Autor/Herausgeber: IETF / Sheffer, Hardt und Jones
• Datum: 02.2020
• Dokumenttyp: Best Current Practice
• Status: RFC
• Relevanz: Sicherheitsregeln für JWT-Verarbeitung.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc8725.html](https://www.rfc-editor.org/rfc/rfc8725.html)

^[S-104] SP 800-63B-4: Digital Identity Guidelines - Authentication and Authenticator Management

• Autor/Herausgeber: NIST
• Datum: 07.2025
• Dokumenttyp: Behördenstandard
• Status: Final Publication
• Relevanz: Aktueller NIST-Stand zu Authentisierung und Authenticator Management.
• Refresh-Priorität: hoch
• Direkte URL: [https://doi.org/10.6028/NIST.SP.800-63B-4](https://doi.org/10.6028/NIST.SP.800-63B-4)

^[S-105] RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3

• Autor/Herausgeber: IETF / Rescorla
• Datum: 07.2026
• Dokumenttyp: Internet Standard
• Status: RFC; ersetzt RFC 8446
• Relevanz: Aktueller TLS-1.3-Standard am Stichtag.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9846.html](https://www.rfc-editor.org/rfc/rfc9846.html)

^[S-106] RFC 9421: HTTP Message Signatures

• Autor/Herausgeber: IETF / Backman et al.
• Datum: 02.2024
• Dokumenttyp: Internet Standard
• Status: RFC
• Relevanz: Kryptografische Signaturen ausgewählter HTTP-Nachrichtenbestandteile.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9421.html](https://www.rfc-editor.org/rfc/rfc9421.html)

^[S-107] REST Security Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Sicherheitsleitlinie
• Status: Living Documentation
• Relevanz: HTTPS, Zugriffskontrolle, Token- und API-Sicherheit.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html)

^[S-108] Secrets Management Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Sicherheitsleitlinie
• Status: Living Documentation
• Relevanz: Speicherung, Rotation und Zugriff auf Geheimnisse.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)

^[S-110] Authorization Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Sicherheitsleitlinie
• Status: Living Documentation
• Relevanz: Robuste Autorisierungslogik und Least Privilege.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)

Inference und Betrieb

^[S-006] FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness

• Autor/Herausgeber: Dao et al.
• Datum: 27.05.2022
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (NeurIPS 2022)
• Relevanz: Inference- und Trainingsoptimierung der Attention-Berechnung.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2205.14135](https://arxiv.org/abs/2205.14135)

^[S-007] Efficient Memory Management for Large Language Model Serving with PagedAttention

• Autor/Herausgeber: Kwon et al.
• Datum: 12.09.2023
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (SOSP 2023)
• Relevanz: PagedAttention und effizientes LLM-Serving.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2309.06180](https://arxiv.org/abs/2309.06180)

^[S-008] Fast Inference from Transformers via Speculative Decoding

• Autor/Herausgeber: Leviathan, Kalman und Matias
• Datum: 30.11.2022
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (ICML 2023)
• Relevanz: Beschleunigung autoregressiver Inferenz durch spekulative Kandidaten.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2211.17192](https://arxiv.org/abs/2211.17192)

^[S-090] KServe - Kubernetes-native model serving

• Autor/Herausgeber: KServe project
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: CNCF Incubating / Living Documentation
• Relevanz: Modellbereitstellung, Skalierung, Health Checks und Inference Graphs.
• Refresh-Priorität: hoch
• Direkte URL: [https://kserve.github.io/website/](https://kserve.github.io/website/)

^[S-091] vLLM Documentation

• Autor/Herausgeber: vLLM project
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: PagedAttention, Continuous Batching, Prefix Caching und Quantisierung.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://docs.vllm.ai/en/stable/](https://docs.vllm.ai/en/stable/)

^[S-092] Text Generation Inference Documentation

• Autor/Herausgeber: Hugging Face
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Produktionsorientiertes LLM-Serving mit Batching, Streaming und Telemetrie.
• Refresh-Priorität: hoch
• Direkte URL: [https://huggingface.co/docs/text-generation-inference/index](https://huggingface.co/docs/text-generation-inference/index)

^[S-093] llama.cpp: LLM inference in C/C++

• Autor/Herausgeber: ggml-org
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Lokale und Cloud-Inferenz auf breitem Hardware-Spektrum.
• Refresh-Priorität: hoch
• Direkte URL: [https://github.com/ggml-org/llama.cpp](https://github.com/ggml-org/llama.cpp)

KI-Sicherheit

^[S-111] OWASP GenAI LLM Top 10 2026

• Autor/Herausgeber: OWASP GenAI Security Project
• Datum: 03.08.2026
• Dokumenttyp: Offizielle Community-Sicherheitsleitlinie
• Status: Aktuelle Ausgabe am Stichtag
• Relevanz: Aktuellster OWASP-Risikokatalog für LLM-Anwendungen am 8. August 2026.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/)

^[S-112] OWASP Top 10 for LLM Applications 2025

• Autor/Herausgeber: OWASP GenAI Security Project
• Datum: 2025
• Dokumenttyp: Offizielle Community-Sicherheitsleitlinie
• Status: Vorgängerausgabe; Detailreferenz
• Relevanz: Risikokatalog der 2025-Ausgabe; für die zugehörigen Detailseiten weiter relevant.
• Refresh-Priorität: hoch
• Direkte URL: [https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/](https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/)

^[S-113] LLM01:2025 Prompt Injection

• Autor/Herausgeber: OWASP GenAI Security Project
• Datum: 2025
• Dokumenttyp: Offizielle Community-Sicherheitsleitlinie
• Status: Detailseite der 2025-Ausgabe; geprüft 08.08.2026
• Relevanz: Direkte und indirekte Prompt Injection.
• Refresh-Priorität: hoch
• Direkte URL: [https://genai.owasp.org/llmrisk/llm01-prompt-injection/](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)

^[S-114] LLM06:2025 Excessive Agency

• Autor/Herausgeber: OWASP GenAI Security Project
• Datum: 2025
• Dokumenttyp: Offizielle Community-Sicherheitsleitlinie
• Status: Detailseite der 2025-Ausgabe; geprüft 08.08.2026
• Relevanz: Übermäßige Rechte und autonome Aktionsmöglichkeiten.
• Refresh-Priorität: hoch
• Direkte URL: [https://genai.owasp.org/llmrisk/llm06-sensitive-information-disclosure/](https://genai.owasp.org/llmrisk/llm06-sensitive-information-disclosure/)

^[S-115] LLM05:2025 Improper Output Handling

• Autor/Herausgeber: OWASP GenAI Security Project
• Datum: 2025
• Dokumenttyp: Offizielle Community-Sicherheitsleitlinie
• Status: Detailseite der 2025-Ausgabe; geprüft 08.08.2026
• Relevanz: Unsichere Weiterverarbeitung von Modellausgaben.
• Refresh-Priorität: hoch
• Direkte URL: [https://genai.owasp.org/llmrisk/llm05-supply-chain-vulnerabilities/](https://genai.owasp.org/llmrisk/llm05-supply-chain-vulnerabilities/)

^[S-116] NIST AI 600-1: Artificial Intelligence Risk Management Framework - Generative Artificial Intelligence Profile

• Autor/Herausgeber: NIST
• Datum: 26.07.2024
• Dokumenttyp: Behördenstandard / Risikoprofil
• Status: Final Publication
• Relevanz: Risiken und Maßnahmen für generative KI.
• Refresh-Priorität: mittel
• Direkte URL: [https://doi.org/10.6028/NIST.AI.600-1](https://doi.org/10.6028/NIST.AI.600-1)

^[S-117] NIST AI 100-2e2025: Adversarial Machine Learning - A Taxonomy and Terminology of Attacks and Mitigations

• Autor/Herausgeber: NIST
• Datum: 03.2025
• Dokumenttyp: Behördenstandard / Taxonomie
• Status: Final Publication
• Relevanz: Angriffe einschließlich Prompt Injection, Daten- und Modellangriffen.
• Refresh-Priorität: hoch
• Direkte URL: [https://doi.org/10.6028/NIST.AI.100-2e2025](https://doi.org/10.6028/NIST.AI.100-2e2025)

^[S-118] MITRE ATLAS - Adversarial Threat Landscape for Artificial-Intelligence Systems

• Autor/Herausgeber: MITRE
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Wissensbasis
• Status: Living Knowledge Base
• Relevanz: Taktiken und Techniken gegen KI-Systeme.
• Refresh-Priorität: hoch
• Direkte URL: [https://atlas.mitre.org/](https://atlas.mitre.org/)

^[S-119] Request for Information About Securing AI Agent Systems

• Autor/Herausgeber: NIST / CAISI
• Datum: 01.2026
• Dokumenttyp: Behördenveröffentlichung
• Status: RFI / laufende Standardisierungsarbeit
• Relevanz: Aktuelle Sicherheitsfragen agentischer Systeme.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems](https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems)

Kontext und Prompting

^[S-013] Lost in the Middle: How Language Models Use Long Contexts

• Autor/Herausgeber: Liu et al.
• Datum: 06.07.2023
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Beitrag (TACL 2024)
• Relevanz: Unterschied zwischen nominellem und effektiv nutzbarem Kontext.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2307.03172](https://arxiv.org/abs/2307.03172)

MCP

^[S-060] Architecture - Specification 2026-07-28

• Autor/Herausgeber: Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizielle Protokollspezifikation
• Status: Aktueller Spezifikationsstand
• Relevanz: Host-Client-Server-Architektur und Protokollkern von MCP.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/specification/2026-07-28/architecture](https://modelcontextprotocol.io/specification/2026-07-28/architecture)

^[S-061] The 2026-07-28 Specification

• Autor/Herausgeber: Soria Parra und Delimarsky / Model Context Protocol
• Datum: 28.07.2026
• Dokumenttyp: Offizieller Release-Beitrag
• Status: Aktueller Release-Stand
• Relevanz: Stateless Core, MRTR, Header-Routing, Caching und Auth-Härtung.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://blog.modelcontextprotocol.io/posts/2026-07-28/](https://blog.modelcontextprotocol.io/posts/2026-07-28/)

^[S-062] Security Best Practices

• Autor/Herausgeber: Model Context Protocol
• Datum: Veröffentlichungsdatum UNKLAR; Draft, geprüft 08.08.2026
• Dokumenttyp: Offizielle Sicherheitsdokumentation
• Status: Draft / Living Documentation
• Relevanz: Angriffe und Gegenmaßnahmen für MCP-Implementierungen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/docs/draft/tutorials/security/security_best_practices](https://modelcontextprotocol.io/docs/draft/tutorials/security/security_best_practices)

^[S-063] Authorization - Specification 2025-06-18

• Autor/Herausgeber: Model Context Protocol
• Datum: 18.06.2025
• Dokumenttyp: Offizielle Protokollspezifikation
• Status: Historischer Spezifikationsstand; durch 2026er Stand zu aktualisieren
• Relevanz: OAuth-basierte Autorisierung für HTTP-Transporte.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization)

Memory

^[S-047] Generative Agents: Interactive Simulacra of Human Behavior

• Autor/Herausgeber: Park et al.
• Datum: 07.04.2023
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (UIST 2023)
• Relevanz: Memory Stream, Reflexion und Planung in simulierten Agenten.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2304.03442](https://arxiv.org/abs/2304.03442)

^[S-048] MemGPT: Towards LLMs as Operating Systems

• Autor/Herausgeber: Packer et al.
• Datum: 12.10.2023
• Dokumenttyp: Originalarbeit / arXiv
• Status: Preprint
• Relevanz: Hierarchisches Memory Management für begrenzte Kontextfenster.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2310.08560](https://arxiv.org/abs/2310.08560)

^[S-049] A-MEM: Agentic Memory for LLM Agents

• Autor/Herausgeber: Xu et al.
• Datum: 17.02.2025
• Dokumenttyp: Originalarbeit / arXiv
• Status: Preprint
• Relevanz: Agentische Organisation und Verknüpfung von Erinnerungen.
• Refresh-Priorität: hoch
• Direkte URL: [https://arxiv.org/abs/2502.12110](https://arxiv.org/abs/2502.12110)

^[S-050] Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory

• Autor/Herausgeber: Chhikara et al.
• Datum: 28.04.2025
• Dokumenttyp: Originalarbeit / arXiv
• Status: Preprint
• Relevanz: Produktionsorientierte Long-Term-Memory-Architektur.
• Refresh-Priorität: hoch
• Direkte URL: [https://arxiv.org/abs/2504.19413](https://arxiv.org/abs/2504.19413)

^[S-051] Evaluating Memory in LLM Agents via Incremental Multi-Turn Interactions

• Autor/Herausgeber: Hu et al.
• Datum: 07.07.2025
• Dokumenttyp: Originalarbeit / arXiv
• Status: Preprint
• Relevanz: Evaluation von Agentenmemory über inkrementelle Interaktionen.
• Refresh-Priorität: hoch
• Direkte URL: [https://arxiv.org/abs/2507.05257](https://arxiv.org/abs/2507.05257)

Modellgrundlagen

^[S-001] Attention Is All You Need

• Autor/Herausgeber: Vaswani et al.
• Datum: 12.06.2017
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (NeurIPS 2017)
• Relevanz: Grundarchitektur des Transformers und Self-Attention.
• Refresh-Priorität: niedrig
• Direkte URL: [https://arxiv.org/abs/1706.03762](https://arxiv.org/abs/1706.03762)

^[S-002] Language Models are Few-Shot Learners

• Autor/Herausgeber: Brown et al.
• Datum: 28.05.2020
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (NeurIPS 2020)
• Relevanz: Skalierte autoregressive Sprachmodelle und In-Context Learning.
• Refresh-Priorität: niedrig
• Direkte URL: [https://arxiv.org/abs/2005.14165](https://arxiv.org/abs/2005.14165)

^[S-003] Training language models to follow instructions with human feedback

• Autor/Herausgeber: Ouyang et al.
• Datum: 04.03.2022
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (NeurIPS 2022)
• Relevanz: Post-Training und menschliches Feedback für Instruktionsbefolgung.
• Refresh-Priorität: niedrig
• Direkte URL: [https://arxiv.org/abs/2203.02155](https://arxiv.org/abs/2203.02155)

^[S-004] SentencePiece: A simple and language independent subword tokenizer and detokenizer for Neural Text Processing

• Autor/Herausgeber: Kudo und Richardson
• Datum: 20.08.2018
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (EMNLP 2018)
• Relevanz: Tokenisierung als technische Vorstufe von Modellkontext und Kosten.
• Refresh-Priorität: niedrig
• Direkte URL: [https://arxiv.org/abs/1808.06226](https://arxiv.org/abs/1808.06226)

^[S-005] Training Compute-Optimal Large Language Models

• Autor/Herausgeber: Hoffmann et al.
• Datum: 29.03.2022
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (NeurIPS 2022)
• Relevanz: Zusammenspiel von Modellgröße, Datenmenge und Trainingsbudget.
• Refresh-Priorität: niedrig
• Direkte URL: [https://arxiv.org/abs/2203.15556](https://arxiv.org/abs/2203.15556)

Observability

^[S-109] Logging Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Sicherheitsleitlinie
• Status: Living Documentation
• Relevanz: Anwendungs- und Sicherheitslogging.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)

^[S-123] OpenTelemetry Semantic Conventions 1.43.0

• Autor/Herausgeber: OpenTelemetry
• Datum: Version 1.43.0; Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Spezifikation
• Status: Aktueller Living-Standard
• Relevanz: Standardisierte Attribute für Traces, Metriken und Logs.
• Refresh-Priorität: hoch
• Direkte URL: [https://opentelemetry.io/docs/specs/semconv/](https://opentelemetry.io/docs/specs/semconv/)

^[S-124] Inside the LLM Call: GenAI Observability with OpenTelemetry

• Autor/Herausgeber: OpenTelemetry
• Datum: 06.2026
• Dokumenttyp: Offizieller Projektbeitrag
• Status: Aktueller Projektstand
• Relevanz: Aktiver Stand der GenAI-Telemetrie und agentischen Beobachtbarkeit.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/blog/2026/genai-observability/](https://opentelemetry.io/blog/2026/genai-observability/)

RAG und Retrieval

^[S-014] Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

• Autor/Herausgeber: Lewis et al.
• Datum: 22.05.2020
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (NeurIPS 2020)
• Relevanz: Grundmodell für Retrieval plus Generierung.
• Refresh-Priorität: niedrig
• Direkte URL: [https://arxiv.org/abs/2005.11401](https://arxiv.org/abs/2005.11401)

^[S-015] Dense Passage Retrieval for Open-Domain Question Answering

• Autor/Herausgeber: Karpukhin et al.
• Datum: 10.04.2020
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (EMNLP 2020)
• Relevanz: Dichtes Passage Retrieval mit Dual Encodern.
• Refresh-Priorität: niedrig
• Direkte URL: [https://arxiv.org/abs/2004.04906](https://arxiv.org/abs/2004.04906)

^[S-016] ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT

• Autor/Herausgeber: Khattab und Zaharia
• Datum: 27.04.2020
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (SIGIR 2020)
• Relevanz: Late Interaction als Retrieval- und Reranking-Ansatz.
• Refresh-Priorität: niedrig
• Direkte URL: [https://arxiv.org/abs/2004.12832](https://arxiv.org/abs/2004.12832)

^[S-017] Precise Zero-Shot Dense Retrieval without Relevance Labels

• Autor/Herausgeber: Gao et al.
• Datum: 20.12.2022
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Beitrag (ACL 2023)
• Relevanz: HyDE: hypothetische Dokumente zur Verbesserung dichter Suche.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2212.10496](https://arxiv.org/abs/2212.10496)

^[S-018] Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection

• Autor/Herausgeber: Asai et al.
• Datum: 17.10.2023
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (ICLR 2024)
• Relevanz: Adaptive Retrieval- und Kritikschritte.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2310.11511](https://arxiv.org/abs/2310.11511)

^[S-019] Corrective Retrieval Augmented Generation

• Autor/Herausgeber: Yan et al.
• Datum: 29.01.2024
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Beitrag (2024)
• Relevanz: Korrektives Retrieval mit Qualitätsbewertung und Websuche.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2401.15884](https://arxiv.org/abs/2401.15884)

^[S-020] RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval

• Autor/Herausgeber: Sarthi et al.
• Datum: 31.01.2024
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (ICLR 2024)
• Relevanz: Hierarchisches Retrieval über rekursive Zusammenfassungen.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2401.18059](https://arxiv.org/abs/2401.18059)

^[S-021] From Local to Global: A Graph RAG Approach to Query-Focused Summarization

• Autor/Herausgeber: Edge et al.
• Datum: 24.04.2024
• Dokumenttyp: Originalarbeit / Microsoft Research
• Status: Forschungsarbeit
• Relevanz: Graphbasierte globale und lokale Retrieval-Strategien.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.microsoft.com/en-us/research/publication/from-local-to-global-a-graph-rag-approach-to-query-focused-summarization/](https://www.microsoft.com/en-us/research/publication/from-local-to-global-a-graph-rag-approach-to-query-focused-summarization/)

^[S-022] Project GraphRAG

• Autor/Herausgeber: Microsoft Research
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Aktueller Projekt- und Implementierungsstand von GraphRAG.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.microsoft.com/en-us/research/project/graphrag/](https://www.microsoft.com/en-us/research/project/graphrag/)

^[S-023] Introducing DRIFT Search: Combining global and local search methods to improve quality and efficiency

• Autor/Herausgeber: Microsoft Research
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizieller Forschungsblog
• Status: Hersteller-/Forschungsquelle
• Relevanz: Kombination globaler und lokaler GraphRAG-Suche.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.microsoft.com/en-us/research/blog/introducing-drift-search-combining-global-and-local-search-methods-to-improve-quality-and-efficiency/](https://www.microsoft.com/en-us/research/blog/introducing-drift-search-combining-global-and-local-search-methods-to-improve-quality-and-efficiency/)

^[S-024] LazyGraphRAG: Setting a new standard for quality and cost

• Autor/Herausgeber: Microsoft Research
• Datum: 25.11.2024
• Dokumenttyp: Offizieller Forschungsblog
• Status: Hersteller-/Forschungsquelle
• Relevanz: Kosten- und Qualitätsvarianten graphbasierter Retrieval-Architekturen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/](https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/)

^[S-025] Retrieval-Augmented Generation for Large Language Models: A Survey

• Autor/Herausgeber: Gao et al.
• Datum: 18.12.2023
• Dokumenttyp: Forschungssurvey / arXiv
• Status: Preprint
• Relevanz: Systematisierung von Naive, Advanced und Modular RAG.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2312.10997](https://arxiv.org/abs/2312.10997)

^[S-026] Retrieval-Augmented Generation for Large Language Models: A Survey from a Retrieval Perspective

• Autor/Herausgeber: Huang et al.
• Datum: 16.04.2024
• Dokumenttyp: Forschungssurvey / arXiv
• Status: Preprint
• Relevanz: Retrieval-Pipeline, Indexierung, Abfrage und Evaluation.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2404.10981](https://arxiv.org/abs/2404.10981)

^[S-028] BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models

• Autor/Herausgeber: Thakur et al.
• Datum: 18.04.2021
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Beitrag (NeurIPS Datasets and Benchmarks 2021)
• Relevanz: Breite Evaluation von Retrievalverfahren über heterogene Datensätze.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2104.08663](https://arxiv.org/abs/2104.08663)

^[S-029] Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs

• Autor/Herausgeber: Malkov und Yashunin
• Datum: 30.03.2016
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Beitrag (TPAMI 2018)
• Relevanz: ANN-Index HNSW als technische Grundlage vieler Vektorsuchen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://arxiv.org/abs/1603.09320](https://arxiv.org/abs/1603.09320)

^[S-030] MTEB: Massive Text Embedding Benchmark

• Autor/Herausgeber: Muennighoff et al.
• Datum: 13.10.2022
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Beitrag (EACL 2023)
• Relevanz: Mehrdimensionale Evaluation von Text-Embeddings.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2210.07316](https://arxiv.org/abs/2210.07316)

^[S-031] MMTEB: Massive Multilingual Text Embedding Benchmark

• Autor/Herausgeber: Enevoldsen et al.
• Datum: 19.02.2025
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-review-/Benchmarkarbeit
• Relevanz: Mehrsprachige Embedding-Evaluation.
• Refresh-Priorität: hoch
• Direkte URL: [https://arxiv.org/abs/2502.13595](https://arxiv.org/abs/2502.13595)

^[S-032] BGE M3-Embedding: Multi-Lingual, Multi-Functionality, Multi-Granularity Text Embeddings Through Self-Knowledge Distillation

• Autor/Herausgeber: Chen et al.
• Datum: 05.02.2024
• Dokumenttyp: Originalarbeit / arXiv
• Status: Preprint / Modellarbeit
• Relevanz: Dense, Sparse und Multi-Vector Retrieval in einem Embedding-Modell.
• Refresh-Priorität: hoch
• Direkte URL: [https://arxiv.org/abs/2402.03216](https://arxiv.org/abs/2402.03216)

Rechtliche Schnittstellen

^[S-125] Verordnung (EU) 2016/679 - Datenschutz-Grundverordnung

• Autor/Herausgeber: Europäische Union
• Datum: 27.04.2016
• Dokumenttyp: Rechtsquelle
• Status: Geltendes Unionsrecht
• Relevanz: Architekturrelevante Grundsätze für personenbezogene Daten; Details in Dossier 1.
• Refresh-Priorität: mittel
• Direkte URL: [https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://eur-lex.europa.eu/eli/reg/2016/679/oj)

^[S-126] Verordnung (EU) 2024/1689 - AI Act

• Autor/Herausgeber: Europäische Union
• Datum: 13.06.2024
• Dokumenttyp: Rechtsquelle
• Status: Geltendes Unionsrecht mit gestaffelter Anwendung
• Relevanz: Architekturrelevante Rollen, Risikomanagement und Transparenz; Details in Dossier 2.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://eur-lex.europa.eu/eli/reg/2024/1689/oj](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)

Reliability

^[S-080] Timeouts, retries, and backoff with jitter

• Autor/Herausgeber: Amazon Web Services
• Datum: 12.06.2026
• Dokumenttyp: Offizielle Engineering-Dokumentation
• Status: AWS Builders Library
• Relevanz: Timeouts, begrenzte Retries, exponentielles Backoff und Jitter.
• Refresh-Priorität: hoch
• Direkte URL: [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)

^[S-081] Making retries safe with idempotent APIs

• Autor/Herausgeber: Amazon Web Services
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Engineering-Dokumentation
• Status: AWS Builders Library
• Relevanz: Sichere Wiederholung nichttrivialer API-Operationen.
• Refresh-Priorität: hoch
• Direkte URL: [https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)

Schnell veraltende Informationen, Refresh-Plan und Qualitätsbericht

Refresh-Klassen

Konkrete Refresh-Liste

Vor Buch-Freeze zwingend prüfen

• MCP: aktuell veröffentlichte Spezifikation, Transport, Authentisierung, Security Best Practices und Breaking Changes.
• TLS: aktuellen IETF-Standard und relevante Sicherheitsupdates; am Stichtag RFC 9846 vom Juli 2026. ^[S-105]
• OpenAPI, JSON Schema, CloudEvents und AsyncAPI: aktuelle Version und Implementierungsunterstützung.
• OpenTelemetry: aktuelle stabile GenAI-Semantikkonventionen und Datenschutzempfehlungen. ^{[S-123; S-124]}
• Provider-APIs: Modellnamen, Structured Output, Tool Calling, Caching, Rate Limits, Preise und Datenbedingungen.
• Serving-Stacks: vLLM, TGI, llama.cpp, KServe, Kubernetes und relevante Sicherheitsupdates.
• Agenten- und Prompt-Injection-Forschung sowie OWASP/NIST/MITRE-Material.
• AI Act und DSGVO-Auslegung an den konkret im Buch beschriebenen Anwendungsszenarien.
• Alle Zahlen, Versionsdaten und wörtlich zugespitzten Aussagen unmittelbar an der Originalquelle.

Qualitätskennzahlen

Stärken

• Konsequente Trennung von Modell, Kontext, Retrieval, Datenhaltung, Tools, Workflow, Agent und Betrieb.
• 126 dokumentierte Primär-, Forschungs-, Standard- und offizielle Produktquellen mit URL, Datum, Status und Refresh-Klasse.
• 50 belegte Kernaussagen und eine vollständige Quellenmatrix.
• 18 praxisnahe Referenzarchitekturen, darunter bewusst einfache und bewusst KI-freie Muster.
• Verbindung von Fachprozess, Sicherheit, Datenprovenienz, Evaluation, Reliability und Vollkosten.
• Aktuelle Standards am 8. August 2026, einschließlich MCP 2026-07-28 und TLS 1.3 nach RFC 9846.

Bekannte Grenzen

• Produkt- und Living Documentation kann sich unmittelbar nach dem Stichtag ändern.
• Viele Agenten-, Memory- und RAG-Varianten beruhen auf Preprints oder Benchmarks; ihre Übertragbarkeit auf Unternehmensproduktion ist begrenzt.
• Das Dossier führt keine Lasttests, Penetrationstests, Datenschutz-Folgenabschätzungen oder juristischen Einzelfallprüfungen für ein konkretes System durch.
• Kosten und Hardwaredimensionierung hängen stark von Modell, Lastprofil, Region, Auslastung und Personal ab und werden in Dossier 17 vertieft.
• Komplexe verteilte Systeme besitzen zusätzliche Implementierungsdetails, die ein verständliches Architektur-Dossier nicht vollständig abbilden kann.
• Die Referenzarchitekturen sind Muster, keine zertifizierten Blaupausen.

Redaktionelle Schlussfolgerung

EIGENE SYNTHESE: Die wichtigste Architekturentscheidung lautet nicht „welches Modell?“, sondern „welcher Teil des Problems ist probabilistisch, welcher Zustand ist verbindlich, welche Aktion ist erlaubt und wie wird ein Fehler erkannt und begrenzt?“. Ein gutes KI-System verwendet klassische Software nicht als Behelf, sondern als tragende Struktur um die generative Komponente. ^{[S-072; S-075; S-110; S-122]}

Leitsatz: LLM, RAG, Memory, Agent und MCP sind Fähigkeiten. Produktqualität entsteht erst durch Datenverträge, Rechte, Zustände, Tests, Reliability und Betrieb.

Ende des Fakten-Dossiers 13.