Baue einen produktionsreifen LLM-API-Client mit strukturierten Ausgaben, Validierung, Retries, Timeouts, Idempotenz, Tracing und Tests.
Szenario
Ein interner Dienst soll ein LLM zur Klassifizierung von Support-Anfragen aufrufen. Antworten müssen strukturiert, wiederholte Requests sicher und Fehler messbar sowie reproduzierbar sein.
Ergebnis: Requests und Responses besitzen eine stabile typisierte Form.
Aufgaben
Prüfungen
Ergebnis: Der Client kontrolliert das Netzwerkverhalten explizit.
Aufgaben
Prüfungen
Ergebnis: Jeder Aufruf lässt sich nachträglich erklären.
Aufgaben
Prüfungen
Ergebnis: Bekannte Fehlermodi sind lokal reproduzierbar.
Aufgaben
Prüfungen
Bewertungsraster
Requests, Responses und Fehler besitzen eine explizite typisierte Form.
Unzureichend
Das Schema ist unvollständig oder Fehler werden verschluckt.
Kompetent
Die Kernverträge sind typisiert und getestet.
Stark
Verträge sind versioniert und Fehlermodi besitzen eigene Typen und Tests.
Erforderliche Nachweise
Timeouts, Retries, Backoff, Rate Limits und Idempotenz sind mit sicheren Grenzen umgesetzt.
Unzureichend
Retries sind unbegrenzt oder retryable und non-retryable Fehler werden vermischt.
Kompetent
Retry- und Timeout-Policies sind begrenzt und getestet.
Stark
Jitter, Circuit Breaker oder Multi-Model-Fallback werden mit Evidenz nachgewiesen.
Erforderliche Nachweise
Jeder Aufruf ist über Request ID, Latenz, Retries, Usage und sichere Logs erklärbar.
Unzureichend
Es gibt keine Ende-zu-Ende-Korrelation oder sensible Daten stehen in Logs.
Kompetent
Request ID, Latenz, Usage und Redaction sind umgesetzt.
Stark
Distributed Traces, Dashboards oder Alert-Schwellen sind umgesetzt.
Erforderliche Nachweise
Erfolgs- und Fehlerpfade lassen sich automatisch reproduzieren.
Unzureichend
Nur der Happy Path ist getestet.
Kompetent
Unit- und Integrationstests decken die wichtigsten Fehlermodi ab.
Stark
Concurrency-/Lasttests und stabile Regression Fixtures sind enthalten.
Erforderliche Nachweise