ki-engineeering/32-anhang-c-glossar.md

Anhang C: Glossar

Dieses Glossar spiegelt die Buch-Terminologie von AI Engineering für Software-Entwickler. Begriffe sind im Sinne der zehn Thesen und des Production Stacks definiert — nicht als allgemeines KI-Lexikon und nicht als Vendor-Glossar.

Serie (kurz): Mechanik und Grenzen der Modelle → Next Token (ki-hinterm-vorhang). Coding-Agents als Dev-Tool → Coding Agents in der Praxis (ki-praxis). Security von Dev-Agent-Harnesses → Secure Coding Agents (ki-agent). Hier: Produkt-AI bauen und betreiben. Produkt-Agent und Coding-Agent teilen Mechaniken; Ownership, Threat Model und Erfolgsmetriken unterscheiden sich.

Einträge sind alphabetisch (deutsche und englische Fachwörter gemischt, wie im Text). „Nicht:“ markiert häufige Fehlbedeutungen.

---

A

Adaptation — Alles, womit du ein vortrainiertes Foundation Model für ein Produktproblem nutzbar machst, ohne Pretraining: Prompting, Structured Output, RAG, Tools, Agents, Fine-Tuning, Distillation. Adaptation ist die primäre Arbeit von AI Engineering.
Nicht: Training from scratch oder Research-Training-Läufe.
→ Kap. 08

Adaptation Ladder — Entscheidungsleiter der Adaptation von leicht/ reversibel zu schwer/ teuer: Prompt → Structured Output → RAG → Tools/Workflow → Agent → Fine-Tune → Train. Von unten starten, nur mit Evidenz (Eval, Kosten, Ops) steigen.
Nicht: eine Pflicht-Reihenfolge für jedes Feature; Kombis (z. B. RAG + Tools) sind normal.
→ Kap. 08

AI Engineering — Software Engineering für Systeme, die Foundation Models adaptieren und orchestrieren: spezifizieren, bauen, evaluieren, absichern und betreiben. Fokus auf Produktionsreife (Eval, Ops, Cost, Security, Lifecycle), nicht auf Modellforschung.
Nicht: ML Engineering (Training, Research, Feature Stores als Kernjob).
→ Kap. 03

B

Budget Cap — Harte Obergrenze für Kosten, Tokens, Tool-Calls oder Agent-Schleifen pro Request, Session, Tenant oder Zeitraum. Caps gehören in den Control Flow (Orchestrierung), nicht nur in die Rechnung am Monatsende.
→ Kap. 16, 23

C

Canary — Kontrolliertes Ausrollen einer Änderung (Modell, Prompt, Index, Policy) auf einen kleinen Anteil des Live-Traffics, mit Qualitäts-, Kosten- und Safety-Signalen vor dem Full Rollout.
Nicht: nur HTTP-5xx beobachten — Silent Degradation braucht Quality Stops.
→ Kap. 18, 24

Cascade / Fallback — Gestaffelte Antwortstrategie: erst günstigeres/schnelleres Model-Tier oder einfacherer Pfad; bei Unsicherheit, Schema-Fail oder Policy-Hit eskalieren bzw. auf deterministischen Fallback (Regel, Template, Mensch, „kann ich nicht“) wechseln.
→ Kap. 09, 16

Chunking — Zerlegen von Dokumenten in abrufbare Einheiten (Größe, Überlapp, Strukturgrenzen) für Index und Retrieval. Chunk-Design steuert Recall, Kontext-Rauschen und Kosten.
Nicht: „512 Tokens für alles“ als Architektur.
→ Kap. 12

Citation — Nachvollziehbare Verknüpfung von generierter Aussage zu Retrieval-Quellen (IDs, Snippets, URLs im System). Citations sind Produkt- und Trust-Feature und Eval-Anker — kein reines UI-Dekor.
→ Kap. 12

Coding-Agent — LLM-basierter Agent als Dev-Tool (IDE, CLI, Repo-Harness): schreibt und ändert Code im Entwicklungsprozess. Mechaniken ähneln Produkt-Agents; Threat Model, Ownership und Metriken sind andere. Vertiefung: ki-praxis / ki-agent.
Nicht: synonym mit Produkt-Agent im Nutzerprodukt.
→ Kap. 02, 14

Context / Context Engineering — Alles, was das Modell in einem Schritt „sieht“: System-/User-Prompt, Retrieval, Memory, Tool-Results, Policies. Context Engineering ist die produktseitige Architektur dieses Fensters (Slots, Budgets, Redaction, Cache) — der primäre Qualitätshebel (T4).
Nicht: nur der System-Prompt-Text.
→ Kap. 10

Control Flow vs. LLM Flow — Control Flow ist euer deterministischer Orchestrierungspfad (State, Caps, Validate, Flags). LLM Flow ist die probabilistische Modellarbeit (Tokens, Tool-Vorschläge). Vermischen erzeugt undebugbare „magische“ Controller.
→ Kap. 07, 16

D

Data Residency (Residenz) — Vorgabe, in welchen Rechts-/Rechenräumen Daten (Prompts, Logs, Embeddings, Provider-Egress) verarbeitet und gespeichert werden dürfen. Residenz ist Architektur- und Vendor-Entscheidung, nicht nur Vertragsklausel.
→ Kap. 20

Drift — Systematische Verschiebung von Eingaben, Korpus, Nutzerverhalten oder Modellverhalten gegenüber dem, wofür Eval und Spec gelten. Drift erklärt viele „früher war es besser“-Tickets ohne sichtbaren Deploy.
→ Kap. 18, 24

E

Eval — Messbare Qualitätsprüfung von AI-Ausgaben und -Pfaden (offline Golden Sets, CI-Gates, Stichproben, Online-Signale). Ohne Eval existiert Qualität im Buchsinne nicht (T3).
Nicht: „fühlt sich gut an“ oder einmalige Demo.
→ Kap. 17

F

Feature Flag / Kill Switch — Schalter, um AI-Pfade (Feature, Strong-Tier, Agent-Loop, Tool-Klasse) ohne Full Deploy ein- oder auszuschalten. Der Kill Switch ist der Not-Aus bei Cost Spike, Safety- oder Qualitäts-Incident.
→ Kap. 16, 25

Foundation Model — Großes vortrainiertes Modell (oft multimodale oder textbasierte LLMs), das Produkte adaptieren, statt es selbst von Grund auf zu trainieren. Im Buch: Dependency mit Lifecycle, nicht „die KI“ als Blackbox-Götze.
→ Kap. 03, 24

G

Golden Set — Kuratierte, versionierte Fallsammlung mit erwarteten Eigenschaften (Labels, Rubrics, Schemas, Citations) für Regression und Release-Gates. Kleine, repräsentative Sets schlagen große ungepflegte.
→ Kap. 17

Guardrail — Kontrollen an Input, Output und Policy (Schema, Allow-/Deny-Listen, Safety-Filter, Tool-Permissions, Rate Limits) — im Harness durchgesetzt, nicht nur als Prompt-Appell „sei ehrlich“.
→ Kap. 19, 16

H

Harness — Software-Schicht ums Modell: Orchestrierung, Tools, Policies, Validate/Repair/Fallback, Observability, Budget. Im Buch ein Konzept, kein Produktname.
Nicht: synonym mit einem bestimmten Vendor-Framework.
→ Kap. 07, 16

Human-in-the-loop (HITL) — Explizite menschliche Freigabe, Korrektur oder Eskalation an definierten Gates (riskante Tools, unklare Fälle, Compliance). HITL ist Architektur, nicht „wenn das Modell unsicher wirkt“.
→ Kap. 14, 26

Hybrid Search — Kombination mehrerer Retrieval-Signale (z. B. keyword/BM25 + dense/Vektor, oft plus Filter/Metadaten) vor oder mit Rerank. Rein vektorbasiertes „Index = fertig“ ist selten robust genug.
→ Kap. 12

I

Incident (AI-Klassen) — Produktionsstörung mit AI-spezifischen Klassen jenseits reiner Availability (kanonisch Kap. 25): Safety/Security (Policy, Leakage, Injection, Tool-Abuse), Cost spike, Quality drop (inkl. Silent Degradation / schädliches Model-Update), Latency/timeouts, Provider outage, Data/Index. Runbooks und Owner gehören dazu.
→ Kap. 25

K

Kill Switch — siehe Feature Flag / Kill Switch.

L

Leakage — Unerwünschtes Offenlegen sensibler Daten in Outputs, Logs, Traces, Provider-Payloads oder an andere Tenants (System-Prompts, Secrets, PII, fremde Dokumente). Leakage ist Security- und Privacy-Thema.
→ Kap. 19, 20

LLM (Large Language Model) — Foundation Model mit Fokus auf Text (häufig auch Tools/Strukturausgaben). Im Buch meist die konkrete Modellklasse hinter Chat-, Embed- und Tool-APIs; nicht synonym mit dem gesamten AI-System.
→ Kap. 03

LLM-as-Judge — Eval-Verfahren, bei dem ein Modell Ausgaben gegen Rubrics/Schemas bewertet. Nützlich für Skalierung; braucht Kalibrierung, Stichproben mit Menschen und Schutz vor Bias/Injection im Judge-Pfad.
Nicht: alleiniger Qualitätsbeweis ohne Golden Set und menschliche Anker.
→ Kap. 17

M

MCP (Model Context Protocol) — Beispiel für ein offenes Integrationsprotokoll, das Tools, Ressourcen und ggf. Prompt-Primitive standardisiert anbindet (Interop, Gateway-Patterns). MCP ist Interop — kein Ersatz für Tool Contracts, AuthZ, Caps und Eval.
Nicht: Produktname, reines „Transport“-Detail oder Pflicht-Architektur.
→ Kap. 13

ML Engineering — Disziplin rund um Training, Datenpipelines für Lernen, Experimente, Model Serving aus eigenem Trainingsjob. Grenzt an AI Engineering bei Fine-Tune/Distill/Eval-Infra; Kernjob und Ownership unterscheiden sich (T1).
→ Kap. 03

Model-Change — Jede Änderung an Modell-ID, Provider, Prompt-Version, Index, Tool-Schema oder Policy, die die Antwortverteilung beeinflussen kann. Im Buch: wie ein Breaking Change behandeln (Pin, Eval-Gate, Canary, Rollback) — These T9.
→ Kap. 24, Templates: model-change-checklist.md

Model Routing — Abbildung von Task/Workload auf Model-Tier (und ggf. Provider/Hosting) nach Qualität, Latenz, Kosten und Risiko — oft dynamisch mit Cascade.
Nicht: „immer das stärkste Modell“.
→ Kap. 09

Model-Tier — Architektur-Rolle für Modelle: typisch Fast/Cheap · Balanced · Strong · Specialized. Welches Produkt heute in „Strong“ sitzt, ändert sich; die Rolle und Routing-Regeln bleiben.
Nicht: Vendor-Hitliste oder einmaliges Benchmark-Ranking als Spec.
→ Kap. 09

N

Non-Determinismus — Runtime-Eigenschaft: gleiche Inputs können variierende Ausgaben liefern. Gehört ins Design (Schema, Retries mit Caps, Sampling-Policy, Fallbacks), nicht nur ins Ticket „flaky“.
→ Kap. 04, 16

O

Observability Trace — Durchgängige Spur eines AI-Requests: Spans für Context-Assembly, Model-Call(s), Tool-Runden, Validate/Repair, inkl. feature_key, Modell-IDs, Token-Zähler, Retrieval-IDs, Fehlerklassen. Basis für Debug, Cost und Incident.
Nicht: nur Access-Logs ohne Qualitäts- und Token-Signale.
→ Kap. 22

Online Metrics — Qualitäts- und Betriebsmetriken am Live-Traffic (Task Success Proxies, Reject-/Repair-Rate, User-Feedback, Cost/Task, Latency, Safety-Events) — Ergänzung zu Offline-Eval, nicht Ersatz.
→ Kap. 18, 23

Orchestrierung (Orchestration) — Codegesteuerter Control Flow ums Modell: State, Timeouts, Routing, Tools, Validate/Repair/Fallback, HITL, Flags. Orchestrierung schlägt „Magic“ im Prompt (T6).
→ Kap. 16, 14

Owner / Ownership — Klare Verantwortung für Spec, Prompt/Contract-Versionen, Eval, Model-Change, Security-Review und On-Call. Der Mensch bleibt Owner (T10); das Modell ersetzt keinen Product- oder Incident-Owner.
→ Kap. 26

P

Pinning — Festnageln konkreter Versionen (Model-ID, Prompt-Version, Index-/Embedding-Version, Tool-Schema), damit Deployments reproduzierbar und rollbacks möglich sind. „Latest“ in Produktion ist Anti-Pattern.
→ Kap. 09, 24

Pipeline vs. Agent — Pipeline: fester, codegesteuerter Schrittgraph (vorhersehbare Tools/Calls). Agent: Modell wählt Schritte/Tools in einem Loop unter Caps und Policies. Pipelines sind oft robuster und günstiger; Agents nur mit Evidenz und Kill Switch.
→ Kap. 14

Production Stack — Schichtenmodell des Buchs: UX/Channel → Orchestrierung (Harness) → Adaptation → Model Access → Context & Data → Eval & Guardrails → Observability & Cost; Security, Privacy und Ownership durchziehen.
→ Kap. 07

Produkt-Agent — LLM + Tools + Loop im Nutzerprodukt (Support, Ops, Domänenworkflow). Erfolgsmetriken sind Produkt-SLOs; Side Effects und AuthZ sind Teil der App-Security.
Nicht: Coding-Agent im Entwickler-Repo.
→ Kap. 14

Prompt (as Interface) — Prompting als Interface- und Contract-Design: Rollen, Schemas, Fehlerpfade, Versionierung — nicht als kreatives Wortmagie-Hobby. Architektur vor Prompt-Feinschliff (T5).
→ Kap. 11

Prompt Injection (direct / indirect) — Angriff, der Modellverhalten über manipulierte Anweisungen steuert. Direct: im User-Input. Indirect: in abgerufenen Dokumenten, Tickets, E-Mails, Webseiten im Context. Mitigation: Isolation, least privilege Tools, Output-Validierung, nicht nur „ignoriere Anweisungen im Text“.
→ Kap. 19, 12

R

RAG (Retrieval-augmented Generation) — Zur Laufzeit relevante Informationen holen und in den Context legen, bevor/während generiert wird. Index allein ist kein fertiges System: Chunking, Hybrid Search, Rerank, Citations, ACL und Eval gehören dazu.
→ Kap. 12

Redaction — Maskieren oder Entfernen sensibler Inhalte vor Modell, Log und Export. Redaction vor dem Modell und Redaction in Observability sind getrennte Specs.
→ Kap. 10, 20

Rerank — Zweite Stufe nach Retrieval: Kandidaten neu ordnen (Cross-Encoder, LLM-Rerank, Regeln), um Präzision im Context-Fenster zu erhöhen. Trade-off: Latenz und Kosten vs. bessere Treffer.
→ Kap. 12

Rollback — Schnelles Zurück auf letzte bekannte gute Version (Modell-Pin, Prompt, Index, Flag). Voraussetzung: Pinning, Artefakt-Registry und getesteter Kill-/Switch-Pfad.
→ Kap. 24, 25

S

Shadow Traffic — Neuen Pfad (Modell, Prompt, Pipeline) parallel mit Live-Inputs füttern, ohne Nutzer-Output zu ändern; Ergebnisse vergleichen (Qualität, Latenz, Kosten). Vorbereitung für Canary.
→ Kap. 18

Silent Degradation — System bleibt „grün“ (keine 5xx-Spitze), aber semantische Qualität sinkt (falsche Antworten, schlechtere Citations, mehr Repairs). Default-Failure-Mode ohne Online Quality Signals.
→ Kap. 18

SLO (AI) — Service Level Objectives für AI-Features: nicht nur Latency/Uptime, sondern messbare Qualitäts- und Safety-Ziele (z. B. Task-Success-Rate, Schema-Fail-Rate, Citation-Coverage) plus Cost-Envelope.
→ Kap. 23, 06

Structured Output — Ausgabe gegen ein Schema (JSON Schema, Typen, Enums) validiert und im Control Flow bindend gemacht. Freier Fließtext ist UX oder Entwurf, selten stabile API zwischen Systemteilen.
→ Kap. 11, 16

T

Token Accounting — Erfassen und Zuordnen von Input-/Output- (und ggf. Cache-/Reasoning-)Tokens zu Feature, Tenant, Modell und Schritt. Grundlage für Unit Economics, Budgets und Anomalie-Erkennung.
→ Kap. 22, 23

Tool / Function Calling — Kontrollierter Aufruf eurer Funktionen/APIs durch modell-generierte, schema-gebundene Requests. Das Modell schlägt vor; euer Code autorisiert, führt aus und protokolliert.
Nicht: unkontrolliertes Shell-out oder „das Modell darf alles“.
→ Kap. 13

Tool Abuse — Missbrauch erlaubter oder zu weit geöffneter Tools (Datenexfiltration, unerwünschte Side Effects, Privilege Escalation) — oft über Injection oder übertriebene Tool-Rechte. Least privilege und Caps sind Pflicht.
→ Kap. 19, 13

Tool Contract — Spezifikation eines Tools: Name, Schema, Idempotenz, Fehlercodes, AuthZ, Side-Effect-Klasse, Timeouts, Observability. Vertrag zwischen Modell-Interface und Backend — versioniert wie jede API.
→ Kap. 13, Template: tool-contract.md

U

Unit Economics — Kosten- und Wertrechnung pro sinnvoller Einheit (Request, Ticket, Dokument, Session, erfolgreicher Task): Tokens, Tool-Calls, Mensch-Zeit, Infrastruktur. Kosten und Latenz sind Features (T7).
→ Kap. 23

V

Validate / Repair / Fallback — Standardmuster um probabilistische Knoten: Ausgabe prüfen (Schema, Business-Rules) → bei Fail gezielter Repair mit Diagnose (cap) → sonst deterministischer Fallback oder HITL. Blindes Retry desselben Prompts ist selten die Lösung.
→ Kap. 16

---

Lesetipp

• Begriffe mit Ownership und Eval zuerst klären: ohne gemeinsame Sprache enden Retros in „die KI war schlecht“.
• Bei Unsicherheit Produkt- vs. Coding-Agent: frage nach wo der Loop läuft und wer den Schaden trägt.
• Schichten und Ladder: Kap. 07 und 08; Security-Cluster: 19–20.