Zum Hauptinhalt springen

Vollständiger Lernkurs

Backend Developer + AI

AI-Funktionen in zuverlässigen Backend-Systemen

LLM-APIs, RAG, Tools, Queues, Observability, Evaluation und Produktionsarchitektur.

Beende den Kurs nicht mit einer Demo, die genau einen erfolgreichen Request überlebt, sondern mit einem Production-Evidence-Paket für ein AI-Backend: typisierte Verträge, Retries und Idempotenz, kontrolliertes Streaming, RAG mit ACL- und Freshness-Prüfungen, begrenzte Tool-Aktionen, Evaluation Gate, Observability, Kostenbudgets und ein getesteter Rollback-Pfad.

0%0/9 Lektionen

Der Fortschritt wird lokal in deinem Browser gespeichert.

10–16 Wochen3 Module9 Lektionen1 Assessments

Lern-Betriebssystem

So arbeitest du den Kurs durch und behältst ein belastbares Ergebnis

1. Mit dem Vertrag beginnen

Definiere für jede AI-Funktion zuerst Input-/Output-Schema, Timeout-Budget, Retry Policy, Idempotency Key, Error Taxonomy und autoritative Quelle. Ein Prompt ohne Transport- und Application-Vertrag ist noch kein Backend.

2. Fehler reproduzieren

Ergänze zum Happy Path Timeout, Provider-429/5xx, fehlerhafte strukturierte Ausgabe, Duplicate Request, Client Cancellation und veraltetes Retrieval. Jeder Fehler muss in einem vorhersehbaren Systemzustand enden.

3. Side Effect verifizieren

Wenn das Modell eine Tool-Aktion vorschlägt, prüft die Application Layer unabhängig Identity, Authority, Schema, Preconditions und Idempotenz. Modelltext ist keine Erlaubnis zur Ausführung.

4. Production Evidence sichern

Erfasse Traces, Latenz, Retries, Retrieval Evidence, Tool-Entscheidungen, Kosten pro erfolgreichem Task und Regressionsergebnisse. „Lokal hat es geantwortet“ ist ein erstaunlich bescheidener Observability Stack.

Kursregeln

Nicht nur gelesen — sondern nachgewiesen

  • HTTP 200 vom Model Provider bedeutet nicht, dass das Domain Result korrekt ist; Transport-, Schema-, Semantic- und Authority-Checks sind getrennte Schichten.
  • Retry ohne Idempotenz und Reconciliation ist ein Generator doppelter Side Effects, kein Reliability Pattern.
  • Gib dem Modell niemals Authority, die der authentifizierte Caller nicht besitzt; ein Tool Schema ersetzt keinen Permission Check.
  • Bewerte RAG getrennt auf Retrieval- und Answer-Layer: eine relevante Antwort aus einem fremden ACL Scope ist weiterhin ein Failure.
  • Nach einem Production Incident wird die minimierte Reproduction vor der nächsten Model-, Prompt-, Retrieval- oder Tool-Änderung zu einem permanenten Regression Case.

Modul 1

Gemeinsamer AI-Kern

Grundverständnis und Kontrolle der Ergebnisse.

ErgebnisSichere und überprüfbare Nutzung von AI.

  1. AI-Grundverständnis und Modellgrenzen

    Kern

    Fähigkeiten, Halluzinationen, Kontextgrenzen, Datenschutz und verantwortungsvolle Nutzung.

    Material →

  2. Prompt- und Context Engineering

    Kern

    Anweisungen, Constraints, Beispiele und Prüfung der Ergebnisse.

    Voraussetzungen: AI-Grundverständnis und Modellgrenzen

    Material →

  3. Structured Outputs und Evaluation

    Kern

    Antwortschemata, deterministische Checks und Testfälle.

    Voraussetzungen: Prompt- und Context Engineering

    Material →Ressource →

Checkpoint nach dem Modul

Backend-AI-Contract-Baseline

  • ✓ Input-/Output-Verträge und Failure Taxonomy sind dokumentiert
  • ✓ für jede AI-Antwort ist ein Verification Signal definiert
  • ✓ Privacy- und Authority-Grenzen sind vor der Integration markiert

Szenario-Transfer-Lab

Transfer Lab: einen AI-Endpoint in einen Backend-Vertrag verwandeln

Nimm einen Endpoint, der heute nur einen Prompt an das Modell weiterleitet. Zerlege ihn in Transport Contract, Model Contract, Verification, Data Boundary und Failure States, sodass ein anderer Backend Engineer den Client implementieren kann, ohne den magischen Prompt zu kennen.

Abgabe

API Contract + Sequence Diagram + Failure Matrix mit Timeout, Retry, fehlerhafter Ausgabe, Cancellation, Privacy Boundary und Owner für jeden autoritativen Check.

LLM-API-Production-Patterns →Structured Outputs →Knowledge Map →Roadmap Backend Developer + AI →
  • ✓ Schema Validation erfolgt vor Domain Logic
  • ✓ Retry ist nur für explizit definierte Failure Classes erlaubt
  • ✓ Privacy- und Authority-Grenzen werden nicht an den Prompt delegiert
  • ✓ kritische Felder besitzen ein deterministisches oder autoritatives Verification Signal

Modul 2

LLM-API-Integration

Verträge, Streaming und Zuverlässigkeit.

ErgebnisEin produktionsreifer AI-Client.

  1. LLM-API-Verträge

    Kern

    Typisierte Schemas, Validierung, Timeouts, Retries und Idempotenz.

    Material →

  2. Streaming und Backpressure

    Kern

    Teilantworten, Abbruch und Flow Control.

    Material →

  3. Projekt: Production-AI-API

    ProjektPraxis + Assessment

    Structured Outputs, Retries, Traces, Tests und Kostenreport.

    Material →Praxis →Assessment →

Checkpoint nach dem Modul

Resilienter LLM-API-Client

  • ✓ Timeouts, Retries, Backoff und Cancellation besitzen ausführbare Tests
  • ✓ ein Duplicate Request erzeugt keinen doppelten Side Effect
  • ✓ strukturierte Ausgabe wird vor Domain Logic validiert und Streaming umgeht keine finale Validation

Szenario-Transfer-Lab

Transfer Lab: Retries, Idempotenz und Streaming unter Last

Baue einen resilienten AI-API-Client und zerstöre absichtlich Netzwerk- und Provider-Pfad: 429, 5xx, langsamer Stream, Disconnect nach Partial Response und wiederholter Request nach unbekanntem Outcome. Beweise, dass Retry Side Effects nicht vervielfacht und Terminal Failure nicht versteckt.

Abgabe

Ausführbarer Client + Failure-Injection-Tests + Trace Report mit Attempts, Backoff, Cancellation, Idempotency Key, Final State, p95 Latency und Kosten pro erfolgreichem Task.

Praxis: resilienter AI-API-Client →Streaming und Backpressure →AI Evaluation →AI² Business →
  • ✓ Duplicate Delivery erzeugt keinen doppelten Write oder Action
  • ✓ Client Cancellation stoppt oder reconciled die Arbeit tatsächlich
  • ✓ Partial Streaming Output gilt nie als validiertes finales Ergebnis
  • ✓ Latenz und Kosten werden pro erfolgreichem Task inklusive Retries gemessen

Modul 3

RAG, Tools und Production

Wissen, Aktionen, Quality Gates und Monitoring.

ErgebnisEine AI-Funktion mit SLOs, Evaluations und Rollback.

  1. RAG-Service-Architektur

    Kern

    Retrieval, Zitate, ACL und Aktualität.

    Material →

  2. Tool Calling und Berechtigungen

    Kern

    Typisierte Tools, Freigaben und Audit Trail.

    Material →

  3. Milestone: Production-AI-Funktion

    Meilenstein

    Evaluations, Security Review, Monitoring und Rollback.

    Material →

Checkpoint nach dem Modul

Governed Production-AI-Feature

  • ✓ RAG prüft ACL, Freshness und Citations
  • ✓ Tool-Aktionen besitzen explizite Authority und eine autoritative Postcondition
  • ✓ Quality-, Latency-, Cost- und Safety-Gates können den Rollout stoppen und Rollback wurde getestet

Szenario-Transfer-Lab

Transfer Lab: RAG + Tool-Aktion mit Production Gate

Baue einen Backend-Flow, in dem Retrieval ein Evidence Pack erstellt, das Modell eine begrenzte Tool-Aktion vorschlägt und die Application Layer Permission und Final State prüft. Ändere danach Retrieval oder Model Configuration und führe vor dem Canary Regression Checks aus.

Abgabe

End-to-End-Trace: Identity → Query → ACL/Filter → ranked Evidence → structured Decision → Tool Preconditions → Action → autoritative Postcondition → Evaluation Result → Release Decision.

RAG-Referenz →Tool-Calling-Verträge →Production Evaluation →AI Incident Response →
  • ✓ Retrieval liefert keinen verbotenen ACL Scope und veraltete Evidence besitzt eine explizite Policy
  • ✓ Model Output führt kein Tool ohne Application-seitigen Authority Check aus
  • ✓ der Side Effect wird durch eine autoritative Postcondition bestätigt oder in einen Reconcile State überführt
  • ✓ eine kritische Regression blockiert den Rollout unabhängig davon, wie schön die Demo aussieht

Capstone-Vertrag

Capstone: governed AI-Backend-Service

Baue eine Production-nahe AI-Funktion als Backend Service mit API Contract, Provider-/Model-Stage, Retrieval oder Tools, deterministischen Controls, Evaluation, Observability und Rollback. Ziel ist kontrolliertes Verhalten unter Failure zu beweisen, nicht noch einen Chat mit Dark Theme zu bauen.

Was abzugeben ist

  • — OpenAPI- oder typisierter API Contract, Domain Schemas, Error Taxonomy und Timeout-/Retry-/Idempotency-Policy
  • — Architecture + Sequence Diagram mit Identity-, Data-, Model-, Retrieval/Tool- und Authoritative-System-Boundaries
  • — ausführbare Failure-Injection-Suite für 429/5xx, Timeout, Cancellation, fehlerhafte Ausgabe, Duplicate Delivery, veraltetes Retrieval und Partial Side Effects
  • — RAG-/Tool-Evidence für ACL, Freshness und Citations oder Permission-/Precondition-/Postcondition-Traces
  • — Evaluation Dataset + Regression Report mit Quality-, Safety- und Domain-Correctness-Thresholds
  • — Observability Pack mit Latency, Errors, Retries, Token-/Provider-Kosten, Kosten pro erfolgreichem Task und Sampled Traces
  • — Staged Rollout + Canary-/Rollback-/Kill-Kriterien + Incident-to-Regression-Runbook

Wann es als fertig gilt

  • ✓ die API liefert ein validiertes Domain Result oder einen kontrollierten typisierten Failure, nicht „fast JSON“
  • ✓ Retry, Idempotenz und Reconciliation verhindern versteckte doppelte Side Effects
  • ✓ der RAG-/Tool-Pfad bewahrt Identity-, ACL- und Authority-Grenzen vom Request bis zum Final State
  • ✓ eine kritische Quality- oder Security-Regression blockiert den Release vor dem Canary
  • ✓ SLO und Budget werden pro erfolgreichem Task inklusive Retries und Review Overhead bewertet
  • ✓ Rollback oder Fallback stellt einen bekannten funktionierenden Envelope wieder her und bewahrt Audit Evidence

Abschlusspraxis und Assessment

Der Kurs endet mit einem praktischen Artefakt und einer Abnahmerubrik. Das Ergebnis gilt erst nach erfüllten Akzeptanzkriterien als abgeschlossen, nicht bloß nach dem Lesen der Materialien.

Projekt: Production-AI-API →Roadmap öffnen →