ki-engineeering/10-daten-und-kontextarchitektur.md

Daten- und Kontextarchitektur

Model-Tier und Routing stehen (Kapitel 09). Im nächsten Ticket landet trotzdem der Satz: „Leg die letzten 50 Tickets und die Policy-PDF ins Context — dann halluziniert er nicht.“ Drei Releases später ist p95 tot, die Rechnung verdoppelt, Logs stecken voller PII, und die Antwort ist überzeugend falsch — weil der falsche Snippet oben stand und die Session-History den alten Bug mitgeschleppt hat.

Das ist kein „bisschen mehr Prompt“. Das ist Context-Architektur: was das Modell sieht, in welcher Reihenfolge, mit welchem Budget und welcher Datenklasse — und was bewusst nicht im Fenster landet.

These 4 / Kern in einem Satz: Context ist der primäre Qualitätshebel — und meint Prompt + Retrieval + Memory + Tool-Results (plus alles, was ihr sonst noch ins Fenster schiebt); wer Context nicht als System designt, optimiert am falschen Ende (T4 × T7).

Dieses Kapitel ist die Context-&-Data-Schicht des Production Stacks (Kapitel 07). Prompt-Formulierungen und Contracts: Kapitel 11. Retrieval-Mechanik (Chunking, Index, Hybrid, Rerank): Kapitel 12. Hier: was Context ist, welche Tiers Memory hat, wie du budgetierst, cachst und Privacy hältst — ohne das RAG-Kapitel vorwegzunehmen.

---

Bridge: Klassisches SE → AI Engineering

Klassisches SE	In AI Engineering …
Request-Payload / DTO an die Service-API	Context-Paket an den LLM-Aufruf (Instruktionen, Fakten, State, Tool-Output)
Cache (HTTP, Redis, CDN)	Exact- / Semantic- / Prompt-Prefix-Cache — und Cache als Qualitäts- und Kostenhebel
Session / User Profile / Read-Model	Memory-Tiers (ephemeral → working → long-term) mit Retention
Pagination, Projection, „nur nötige Spalten“	Context-Diät: Relevanz vor Vollständigkeit; stufenweises Nachladen
Datenklassen, Masking vor Logs	dieselben Regeln für Prompt, Trace, Eval-Sample und Provider-Payload
Bounded Context / Anti-Corruption	Trust Boundaries: untrusted User-Text und Docs isoliert von Policy-Instruktionen
Query-Budget / Timeout pro Downstream	Token- und Block-Budget pro Context-Slot
Idempotenz-Keys, Cache-Keys	Cache-Keys inkl. Prompt-Version, Index-Version, Tenant, Locale

Die Brücke: Context ist eure Laufzeit-Datenbank für eine einzelne Inferenz — kurzlebig, teuer pro Token, und das Modell liest sie als Wahrheit, solange ihr nichts Gegenteiliges erzwingt.

---

Was „Context“ hier meint

Im Sinne dieses Buchs (kanonisch T4):

Context  =  System-/Developer-Instruktionen
         +  User-Input (und Channel-Metadaten, die ihr durchreicht)
         +  Retrieval-Snippets / Grounding-Evidenz
         +  Memory (Session, Profil, Zusammenfassungen, …)
         +  Tool-Results und Zwischenergebnisse
         +  Structured Contracts / Schemas / Few-Shots (wo im Fenster)

Nicht Context: das Gewichts-Wissen des Foundation Models. Das ist Trainingsbestand — nützlich als Sprach- und Welt-Prior, kein Ersatz für eure Fakten und Policies (siehe Ampel und Grounding in Kapitel 05–08).

Context Engineering vs. „Prompt schreiben“

Fokus nur Prompt-Wording	Context Engineering (dieses Kapitel)
Formulierung der Instruktion	Assembly: welche Blöcke, welche Quelle, welche Reihenfolge
Ein String wächst organisch	Budget und Priorität pro Slot
„Mehr Kontext = besser“	Relevanz, Frische, Trust, Privacy
Debug = Prompt umformulieren	Debug = welcher Block hat die Antwort dominiert?

Formulierung bleibt wichtig — sie ist aber der Interface-Vertrag (Kapitel 11). Ohne Daten- und Memory-Architektur polierst du die Verpackung eines chaotischen Warenkorbs.

Wer baut Context? (Control Flow)

Context-Assembly sitzt im Control Flow / Harness, nicht „im Modell“:

1. AuthZ und Tenant-Scope klären
2. Memory und Retrieval gezielt laden (Queries, Limits)
3. Redaction / Datenklassen anwenden
4. Blöcke priorisieren und auf Budget stutzen
5. Prompt-Template + Version anwenden
6. Modell aufrufen; Tool-Results zurück in den nächsten Context

Das Modell konsumiert Context; es kuratiert ihn nicht vertrauenswürdig (und darf es in Prod nicht allein).

---

Context-Slots und Budget

Stellt euch das Fenster als feste Anzahl Slots mit Priorität vor — nicht als endlosen Chat-Log.

Typische Slots (Beispiel-Layout)

Slot	Inhalt	Priorität (Faust)	Typische Fehler
Policy / Contract	Rolle, harte Regeln, Output-Schema, Safety	hoch, stabil	8k Policy-Prosa statt Code-Rules
Task	aktuelle User-Anfrage / Event	hoch	Channel-Noise, ganze Mail-Threads ungekürzt
Grounding	abgerufene Evidenz mit IDs	hoch bei Fakten-Tasks	Top-k zu groß, Ranking egal
Working Memory	relevante Session-Zusammenfassung, Entity-State	mittel	volles Transcript ab Turn 1
Tool-Results	letzte Tool-Outputs, gekürzt/normalisiert	hoch wenn frisch	Roh-JSON mit Secrets und 50 Seiten
Few-Shots / Stil	knappe Beispiele	niedrig–mittel	Dutzend Beispiele „nur zur Sicherheit“
Long-term Memory	Profil, Präferenzen, stabile Fakten	selektiv	alles jemals Gesagte

Konkrete Token-Zahlen hängen vom Modell ab (Context-Limits und Pricing ändern sich — Stand August 2026, immer am aktuellen Provider-Limit messen). Die Architektur ist: jedes Slot hat ein Soft- und Hard-Cap.

Context-Diät (Regeln)

1. Relevanz vor Vollständigkeit — lieber 3 treffende Passagen als 30 „vielleicht nützliche“.
2. Frisch vor alt — aktuelle Tool-Results und die letzte User-Message schlagen alte Chat-Runden.
3. Evidence vor Eloquenz-Instruktion — bei Fakten-Tasks Grounding nicht für Stil-Tips opfern.
4. Struktur vor Dump — Tabellen, Bullet-Fakten, IDs; kein PDF-Rohschrott ohne Auswahl.
5. Stufenweise nachladen — erst grob antworten/planen, dann gezieltes Retrieval (Control Flow), nicht alles vorab.

Budget als Feature (T7)

Hebel	Wirkung
kleineres Grounding-k	weniger Tokens, oft bessere Signal-to-Noise
Session-Summary statt Transcript	stabile Latenz bei langen Chats
Tool-Result-Clipping	weniger Injection-Fläche und Kosten
Cache-Hit	0 Modell-Tokens (Exact) oder günstiger Prefix

„Ein bisschen mehr Context“ ist eine Produktentscheidung mit Preisschild — und oft mit Qualitäts-Trade-off (Lost-in-the-middle, widersprüchliche Snippets).

---

Memory-Tiers

Memory ist alles, was ihr über den reinen Request hinaus ins Context-Fenster holt, weil es den Task besser macht. Ohne Tiers wird „Memory“ zu einem wachsenden Blob.

Tier	Lebensdauer	Beispiele	Speicherort (typisch)	Ins Context?
Ephemeral	ein Request / eine Inferenz	aktueller User-Text, Request-ID, Feature-Flags	Request-Scope	immer (Task-Slot)
Working	Session / Conversation / Job	letzte N Turns, laufende Entity-State, Tool-Trace-Kurzform	Session-Store, Workflow-State	kuratiert (Summary + selektive Turns)
Task/Artifact	bis Abschluss eines Vorgangs	Ticket-Entwurf, Warenkorb-Kontext, offene Approval	Domain-DB / Workflow	bei Bedarf, versioniert
Long-term	pro User/Tenant, Wochen–Jahre	Präferenzen, stabile Fakten, „kennt mich“-Profil	Profil-DB, oft mit Consent	selektiv und redacted
Corpus / Knowledge	unabhängig von User-Session	Docs, Policies, Produktkatalog	Index / Search / API	via Retrieval, nicht als Dauer-Memory im Prompt

Working Memory: Summary schlägt Scrollback

Langes Transcript 1:1 mitzuschleppen ist der Default der Chat-Demo — und der Feind von p95, €/Task und Stabilität.

Pattern: nach N Turns oder Token-Schwelle eine kontrollierte Zusammenfassung (eigenes, billiges Modell oder Template) schreiben; Roh-Turns archivieren für Audit, aber nicht jeden Turn ins nächste Fenster.

Mitführen	Eher weglassen / archivieren
offene Ziele, Entitäten, Entscheidungen	Smalltalk, wiederholte Fehlversuche
zitierte IDs und offene Fragen	alte Tool-Rohdaten
User-Korrekturen („nicht X, sondern Y“)	verworfene Entwürfe

Long-term Memory: Consent, Wahrheit, Löschung

Long-term Memory ist Produktdaten, keine magische Persönlichkeit:

• Was darf persistiert werden? (Datenklasse, Rechtsgrundlage — Praxis in Kapitel 20, keine Rechtsberatung)
• Wer korrigiert falsche Erinnerungen? (User-sichtbare Prefs > unsichtbare Modell-Zusammenfassung)
• Wie löscht ihr? (Retention, „vergiss das“, Tenant-Offboarding)
• Isolation: Tenant A sieht nie Memory von Tenant B — auch nicht über „ähnliche“ Embeddings im falschen Index

Faustregel: Lieber explizite Profilfelder und Events als „das Modell erinnert sich irgendwie aus dem Chat“.

Corpus ist kein Session-Memory

RAG-Korpus und Session-Memory vermischen Teams gern. Trennung:

• Corpus = gemeinsame, versionierte Wissensbasis → Retrieval (Kapitel 12)
• Memory = person-/session-/vorgangsbezogen → Tiers oben

Beides kann im Context landen — Ownership, Invalidierung und Privacy sind verschieden.

---

Caching (Context- und Antwort-Ebene)

Caching ist hier Architektur, nicht nur Infra-Knob.

Ebenen

Cache-Typ	Was	Wann stark	Risiko
Exact Answer Cache	identischer (oder kanonischer) Request → gespeicherte Antwort	FAQ, idempotente Lookups, gleiche Inputs	Stale bei Wissens-Update; Privacy pro Tenant
Retrieval Cache	Query → Doc-IDs / Snippets	wiederholte ähnliche Fragen	Index-Version im Key; falsche IDs = systematisch falsch
Embedding Cache	Text → Vektor	teure Embed-Calls, stabile Docs	Modell-Version der Embeddings im Key
Prompt-Prefix / Provider-Cache	stabiler System-/Schema-Prefix	hohe QPS, großer fester Prefix	Provider-spezifisch; Pin und Invalidierung beachten (Stand je Anbieter)
Tool-Result Cache	Tool-Args → Result (TTL)	teure Read-APIs	AuthZ und Tenant im Key; keine Writes cachen ohne Idempotenz-Story
Semantic Cache (Ähnlichkeit)	„ähnliche“ Query → alte Antwort	High-QPS Support-like	Qualitätsfalle: ähnlich ≠ gleich; Threshold + Eval nötig

Cache-Keys (Minimum)

Ohne saubere Keys cacht ihr über Tenant- oder Policy-Grenzen hinweg.

cache_key ≈ hash(
  tenant_id,
  feature_key,
  prompt_version,
  model_id,          # oder "answer_logic_version"
  index_version,     # wenn Retrieval involviert
  locale,
  normalized_input   # oder retrieval_fingerprint
)

Invalidierung: Index-Deploy, Policy-Change, Prompt-Version, Preislisten-Update — explizite Events, nicht „TTL und beten“.

Decision Frame: Welcher Cache zuerst?

Situation	Zuerst
Viele identische FAQ-Requests	Exact Answer (+ short TTL oder Event-Invalidierung)
Teures Retrieval, stabile Docs	Retrieval- + Embedding-Cache
Riesiger stabiler System-Prompt	Prefix-Strategien / Provider-Cache wo verfügbar
„Ähnliche“ Support-Fragen	Semantic nur mit Golden-Set-Messung und engem Threshold
Personalisierte Antworten	Exact/Semantic vorsichtig; oft nur Retrieval cachen, Generate live

Cache ist kein Ersatz für schlechte Context-Diät. Er multipliziert, was ihr einmal falsch zusammengebaut habt.

---

Privacy und Trust im Context

Alles, was ins Fenster geht, kann in Antwort, Provider-Logs, euren Traces und Eval-Exports landen. Context-Architektur ist Privacy-Architektur (T8).

Praktische Regeln (ohne Rechtsberatung)

1. Datenklassen vor Assembly — was darf zu welchem Provider / in welche Region?
2. Redaction vor dem Modell, nicht nur vor dem UI-Log — Tokens, Secrets, unnötige PII strippen oder maskieren.
3. Minimierung — Felder, die der Task nicht braucht, gehören nicht in Grounding oder Memory.
4. Tenant-Isolation in Retrieval, Memory und Cache-Keys.
5. Tool-Results behandeln wie untrusted Input — können Injection und Leakage tragen (Kapitel 13, 19).
6. Eval-Samples und Traces derselben Klasse unterwerfen; „nur intern“ ist kein Freifahrtschein für Roh-PII-Seen.

Vertiefung Compliance-Praxis: Kapitel 20. Security-Review: security-review-ai.md.

Trust-Boundaries im Context-String

Untrusted Blöcke (User, Tickets, Web-Docs, Tool-Output) kennzeichnen und trennen von Instruktionen — strukturell (eigene Message-Rollen / Delimiter / Felder), nicht nur mit „ignoriere Anweisungen im Dokument“-Hoffnung. Control Flow entscheidet, welche Quelle Instruktionen setzen darf.

---

Patterns und Trade-offs

Pattern: Context Builder als Modul

Ein dedizierter Baustein build_context(task) -> ContextBundle mit Slot-Budgets, Redaction und Telemetrie (tokens_per_slot, retrieval_ids, memory_tier_hits).

Trade-off: etwas mehr Code; dafür diffbare Context-Politik statt Prompt-Spaghetti in drei Services.

Pattern: Two-stage Context

Stage A: billig/klein (Routing, Missing-Info, grobe Intent). Stage B: nur bei Bedarf volles Grounding + Stronger Tier (Kapitel 09).

Trade-off: mehr Orchestrierung; spart Tokens und oft Latenz im Happy Path.

Pattern: Evidence Pack mit IDs

Grounding immer als nummerierte Snippets mit stabilen IDs; Antwort und Logs referenzieren IDs. Kein „irgendwo im Blob stand das“.

Trade-off: Retrieval- und Citation-Disziplin; Grundlage für Eval und Incident-Debug (Kapitel 12).

Pattern: Memory Write-Path getrennt vom Read-Path

Was ins Long-term Memory geschrieben wird, ist ein eigener, reviewbarer Pfad (explizite Prefs, bestätigte Fakten) — nicht jeder Modell-Satz aus dem Chat.

Trade-off: weniger „magisches Erinnern“; dafür korrigierbare Wahrheit und weniger Memory-Poisoning.

Decision Frame: Was darf ins Fenster?

Frage	Wenn nein / unklar …
Braucht der Task das jetzt?	weglassen oder später nachladen
Ist die Quelle vertrauenswürdig genug für diesen Slot?	quarantänen, kürzen, nicht als Policy
Darf die Datenklasse zum Provider?	redaction, anderes Hosting, kein Call
Sprengt es das Slot-Budget?	ranken, summary, drop lowest priority
Ist es im Cache frisch genug?	invalidieren oder live laden

Trade-off: Vollständigkeit vs. Steuerbarkeit

Mehr Context	Weniger / kuratierter Context
seltener „Modell wusste es nicht“	seltener Widerspruch und Noise
höhere € und p95	schärfere Relevanz-Anforderung an Retrieval
mehr Leakage-Fläche	kleinere Angriffs- und Log-Fläche
Demo wirkt „allwissend“	Prod wirkt kontrollierbar

Default in Production: kuratiert. Vollständigkeit ist ein Retrieval-/Memory-Ziel, kein Dump-Recht.

---

Anti-Patterns

Anti-Pattern	Symptom	Besser
Context-Maximalismus	ganze DBs/PDFs „zur Sicherheit“ im Prompt	Diät, Top-k, stufenweise Nachladen
Transcript als Architektur	Business-State nur im Chat-Log	Working-State in Domain/Workflow; Summary im Context
Memory = stiller Datenstaubsauger	alles speichern, nichts löschen	Tiers, Consent, Retention, Korrektur-UI
Cache ohne Tenant im Key	Cross-Tenant-Leaks oder falsche Prefs	Keys wie oben; Isolation testen
Semantic Cache als Wahrheit	„ähnliche“ Frage, falsche Antwort	enger Threshold, Exact wo möglich, Eval
PII erst im UI maskieren	Provider und Traces sehen Rohdaten	Redaction in der Assembly-Pipeline
Tool-Rohschwall	200 KB JSON in die nächste Runde	normalisieren, clippen, schema’n
Corpus in die Session gekippt	Index-Inhalte als Dauer-Prompt	Retrieval pro Request; Index-Version
Schuld nur beim Modell	jeder Fehler → Tier-Upgrade	zuerst tokens_per_slot und Retrieval-IDs lesen
Prefix-Hoffnung ohne Pin	Provider-Cache, Prompt driftet still	prompt_version + model_id in Observability

---

Production Notes

Cost. Context-Größe und Memory-Mitnahme dominieren oft die Token-Rechnung stärker als Output-Länge. Misst Tokens pro Slot und Cache-Hit-Rate pro feature_key. Exact Cache und Diät schlagen oft den nächsten Model-Tier (T7). Vertiefung Unit Economics: Kapitel 23.

Latency. p95 ≈ Assembly (Retrieval + Memory-Load + Redaction) + Modell (+ Tool-Runden). Parallelisiert Vorholen, wo möglich; Session-Summary hält Chat-Pfade flach. Async, wenn die Spec große Contexts erlaubt (Kapitel 07).

Observability. Pro Request mindestens: prompt_version, tokens_in total und ideal pro Slot, retrieval_ids / index_version, memory_tiers_used, cache_hit (welcher Typ), Redaction-Flags, Tenant. Ohne Slot-Telemetrie bleibt „Context war schuld“ Anekdote. Minimum: observability-minimum.md.

Security / Privacy. Untrusted Blöcke trennen; Tool- und Doc-Content als Injection-Fläche behandeln; Cache und Logs derselben Datenklasse. Secrets nie „kurz im Context, wir loggen nicht“ — jemand loggt immer (T8).

Lifecycle. Prompt-, Index- und Memory-Schema-Versionen koppeln. Index-Deploy invalidiert Retrieval-Caches. Model-Change kann Context-Nutzung verschieben (längere Fenster ≠ bessere Nutzung): Eval mit realistischen Context-Größen, nicht nur mit Spielzeug-Prompts (T9). Owner für Context Builder und für Korpus/Memory-Retention benennen (T10).

---

Key Takeaways

• Context = Prompt + Retrieval + Memory + Tool-Results — der primäre Qualitätshebel (T4); Assembly gehört in den Control Flow.
• Slots und Budgets schlagen „alles mitgeben“; Context-Diät ist Qualitäts- und Kostenarchitektur.
• Memory-Tiers (ephemeral → working → long-term; Corpus getrennt) mit Retention, Korrektur und Tenant-Isolation.
• Caching (Exact, Retrieval, Prefix, vorsichtig Semantic) mit sauberen Keys und Invalidierung — multipliziert Gutes und Schlechtes.
• Privacy sitzt in der Pipeline vor dem Modellaufruf, nicht nur in der UI.
• Prompt-Contracts und RAG-Tiefe folgen in 11 und 12; ohne dieses Kapitel optimiert ihr Formulierungen auf chaotischen Daten.

Praktische nächste Schritte

1. Nimm ein AI-Feature und liste die Context-Slots (was landet heute wirklich im Fenster?) — grob Tokens oder Zeilen schätzen.
2. Markiere pro Slot: Quelle, Datenklasse, Soft-Cap, ob Cache erlaubt ist.
3. Ersetze mindestens an einer Stelle volles Transcript durch Summary + State (oder dokumentiere, warum nicht).
4. Prüfe einen Cache- oder Log-Pfad auf Tenant + prompt_version im Key bzw. in der Policy.
5. Schreibe drei Sätze Context-Politik in die Feature-Spec (templates/ai-feature-spec.md: Daten, Privacy, Cost Envelope).
6. Als Nächstes Bausteine: Prompting als Interface-Design — Contracts und Versionierung auf dem Context, den ihr jetzt bewusst baut.