Sofortantwort
Error Recovery Patterns einfach erklärt
UX-Patterns für graceful Fehlerbehandlung in KI-Systemen.
- Kurz gesagt
- Hilfreiche Fehlermeldungen statt nur technischer Codes
- Typischer Einsatz
- Chatbots, Generative KI, Klassifikation
- Wichtig zu wissen
- Undo und Retry ermöglichen
Error Recovery Patterns im Überblick
Error Recovery Patterns helfen Nutzern, wenn etwas schiefgeht oder ein System unsichere Ergebnisse liefert.
Gute vs. schlechte Fehlerbehandlung:
Schlecht:
"Error 500: Internal Server Error"
Besser:
"Etwas ist schiefgelaufen. Bitte versuche es erneut."
Gut:
"Ich konnte deine Anfrage nicht verarbeiten.
Das könnte helfen:
• Formuliere die Frage anders
• [Erneut versuchen]
• [Mit Mensch sprechen]"
Technisch betrachtet
Recovery-Strategien
| Strategie | Wann nutzen |
|---|---|
| Retry | temporäre oder technische Fehler |
| Rephrase | unklare Eingaben oder Verständnisprobleme |
| Fallback | niedrige Confidence oder fehlende Daten |
| Escalate | komplexe, sensible oder riskante Fälle |
| Undo | reversible oder falsche Aktionen |
Implementation
def handle_error(error_type, context):
if error_type == "low_confidence":
return {
"message": "Ich bin mir nicht sicher.",
"actions": [
{"label": "Anders formulieren", "action": "rephrase"},
{"label": "Mit Mensch sprechen", "action": "escalate"}
]
}
elif error_type == "action_failed":
return {
"message": "Das hat nicht geklappt.",
"actions": [
{"label": "Erneut versuchen", "action": "retry"},
{"label": "Rückgängig", "action": "undo"}
]
}Schritt für Schritt
Wie aus einem Fehler ein kontrollierter Ablauf wird
Fehlerarten und Folgen unterscheiden
Unterscheide erwartete Eingabefehler, vorübergehende Ausfälle, dauerhafte Defekte und sicherheitsrelevante Abweichungen. Erst die mögliche Folge bestimmt, ob Wiederholen, Abbrechen oder menschliche Klärung angemessen ist.
Sicheren Standardpfad festlegen
Definiere, was das System im Zweifel nicht tun darf, welche Informationen erhalten bleiben und wie Menschen verständlich informiert werden. Eine freundliche Meldung darf keine unsichere oder falsche Folgeaktion verdecken.
Wiederholung und Rückfall begrenzen
Nutze Backoff, Zeitlimits, Fallbacks oder Warteschlangen nur mit klaren Abbruchregeln. Wiederholungen müssen idempotent oder anderweitig geschützt sein, damit ein Fehler keine Doppelaktion erzeugt.
Ursache beobachten und verbessern
Protokolliere ausreichenden Kontext, ohne sensible Daten unnötig zu sammeln. Wiederkehrende Fehler werden priorisiert, analysiert und durch Tests oder Architekturänderungen dauerhaft reduziert.
Konkretes Beispiel
Ein externer Dienst fällt kurzzeitig aus
Eine Anwendung benötigt für einen Arbeitsschritt eine externe Schnittstelle. Sie soll nicht sofort scheitern, darf aber auch keine falschen Ergebnisse oder doppelte Aufträge erzeugen.
Unkontrollierter Retry
Bei jedem Fehler versucht das System die Anfrage sofort erneut. Dadurch entstehen Lastspitzen, unklare Zustände und im schlimmsten Fall mehrere gleiche Vorgänge beim externen Dienst.
Sicherer Rückfall
Das System wartet begrenzt, verwendet idempotente Kennungen und übergibt nach einer definierten Grenze an eine Warteschlange oder einen Menschen. Der Fall bleibt nachvollziehbar und kann später erneut geprüft werden.
Einordnung
Vorteile und Grenzen
Das spricht dafür
- Reduziert Schaden und Verwirrung, wenn erwartbare Fehler in kontrollierte Abläufe überführt werden.
- Macht Zuständigkeiten, Grenzen und sichere Alternativen für Menschen und Systeme sichtbar.
- Unterstützt Lernen aus wiederkehrenden Störungen statt bloßer Symptombehandlung.
Das solltest du beachten
- Automatische Wiederholung kann Fehler verstärken, wenn Ursache und Abbruchgrenze fehlen.
- Fallbacks können veraltete, unvollständige oder weniger sichere Ergebnisse liefern.
- Gute Recovery Patterns ersetzen nicht die Behebung von Ursachen und strukturellen Schwächen.
Vertiefung · für FortgeschritteneFehler in einen sicheren nächsten Schritt überführen
Kontrollierter Fehlerpfad
- Fallback Strategy
- Strategien für den Umgang mit KI-Fehlern und Unsicherheit.
- Idempotenz
- Eine Operation liefert dasselbe Ergebnis, egal wie oft sie ausgeführt wird.
- Message Queue
- Warteschlange für asynchrone Service-Kommunikation.
- Observability
- Fähigkeit, den Zustand eines Systems durch Logs, Metrics und Traces zu verstehen.