Fallback Strategy

Einfach erklärt

Fallback Strategies definieren, was passiert, wenn ein KI-System unsicher ist, scheitert oder eine Entscheidung nicht autonom treffen sollte.

Fallback-Hierarchie:

1. KI-Vorhersage bei ausreichender Sicherheit
   ↓ Fallback
2. KI mit Warnung oder Bestätigung bei mittlerer Sicherheit
   ↓ Fallback
3. Einfachere Regel bei niedriger Sicherheit
   ↓ Fallback
4. Human Review
   ↓ Fallback
5. Default-Antwort

Technischer Deep Dive

Implementation

def predict_with_fallback(model, input, threshold):
    prediction, confidence = model.predict(input)
    
    if confidence >= threshold:
        return prediction, "ai"
    elif confidence >= rule_threshold:
        # Einfachere Regel
        return rule_based_prediction(input), "rule"
    else:
        # Human Review
        queue_for_review(input)
        return None, "human"

Chatbot-Fallback

def chatbot_response(query):
    intent, confidence = classify_intent(query)
    
    if confidence > intent_threshold:
        return handle_intent(intent)
    elif confidence > clarification_threshold:
        return f"Meinst du {intent}? [Ja/Nein]"
    else:
        return "Ich bin mir nicht sicher. Möchtest du mit einem Menschen sprechen?"

Fallback-Patterns in KI-Produkten

In LLM-basierten Produkten haben sich Fallbacks auf mehreren Ebenen etabliert – von der Infrastruktur bis zum Dialog:

Ebene	Fallback-Pattern
Modell	Ausweichen auf ein anderes Modell bei Überlastung oder Ausfall des primären Anbieters
Antwortqualität	Bei fehlenden Quellen: „Dazu habe ich keine verlässlichen Informationen” statt Halluzination
Tool-Nutzung	Schlägt ein Tool-Aufruf fehl, antwortet der Agent aus eigenem Wissen – mit Hinweis
Dialog	Chatbot bietet Kontaktformular oder Live-Chat an, wenn er nicht weiterkommt
Retrieval (RAG)	Keine passenden Dokumente gefunden → breitere Suche oder ehrliches „nicht gefunden”

Entscheidend ist die Reihenfolge: Erst die nächstbeste automatische Option, dann der Mensch, zuletzt der ehrliche Abbruch. Jeder Fallback sollte für Nutzer erkennbar sein – stillschweigend degradierte Antworten beschädigen das Vertrauen.

Do & Don’t

Do	Don’t
Fallbacks als Teil des Designs planen, nicht als Notlösung	Fehlerfälle erst in Produktion entdecken
Transparent machen, dass ein Fallback aktiv ist	Degradierte Qualität als Normalfall verkaufen
Kontext an den Menschen übergeben (bisheriger Verlauf)	Nutzer beim Support von vorn beginnen lassen
Ehrliches „Ich weiß es nicht” zulassen	Um jeden Preis eine Antwort erzwingen
Schwellenwerte pro Use Case kalibrieren	Einen globalen Confidence-Threshold für alles

Abgrenzung zu verwandten Begriffen

• Fallback vs. Retry: Ein Retry versucht denselben Weg erneut (etwa bei einem Timeout), ein Fallback wechselt auf einen anderen Weg. In der Praxis: erst begrenzt wiederholen, dann ausweichen.
• Fallback vs. Guardrail: Guardrails verhindern, dass eine riskante Aktion Schaden anrichtet. Fallbacks regeln, wie es weitergeht, wenn das System nicht liefern kann. Guardrails schützen vor der KI, Fallbacks kompensieren ihr Scheitern.
• Fallback vs. Human-in-the-Loop: Human-in-the-Loop kann ein fester Prozessschritt sein (jede Entscheidung wird geprüft). Als Fallback ist der Mensch nur die Eskalationsstufe für unsichere Fälle.

Messbarkeit

• Fallback-Rate: Wie oft greift welche Stufe? Eine steigende Rate kann auf Modellprobleme oder veränderte Nutzeranfragen hinweisen.
• Erfolg nach Fallback: Lösen Nutzer ihr Anliegen über den Ausweichpfad – oder brechen sie dort ab?
• False Fallbacks: Wie oft wird eskaliert, obwohl die KI richtig lag? Zu vorsichtige Schwellenwerte verschenken Automatisierungspotenzial.

Fallback-Raten gehören ins Monitoring wie Fehlerraten: Sie sind ein Frühindikator für sich verschiebende Modellqualität oder Nutzungsmuster.