Three-Tier-AI-Fallback

Angenommen, dein Produkt ruft eine LLM-API auf und dieser Aufruf scheitert. Was sieht der Nutzer? „Service temporarily unavailable" ist die schlechte Antwort. Die gute Antwort: eine still degradierte Response, die trotzdem noch tut, was sie soll, und die der Nutzer nicht einmal bemerkt.

Das Muster sind drei gestapelte Tiers: API → regelbasiert → hartkodiert. Jeder Tier kann dieselbe Anfrage bearbeiten, mit sinkender Qualität, aber steigender Zuverlässigkeit.

Der Dispatch

async def generate_response(context: dict) -> str:
    # Tier 1: LLM API (primär)
    try:
        return await _call_api(context, timeout=5.0)
    except (httpx.HTTPError, APIError) as e:
        log.info("tier-1 failed (%s), falling through", type(e).__name__)

    # Tier 2: rule-based reasoning
    try:
        result = _rules_engine(context)
        if result:
            return result
    except Exception as e:
        log.warning("tier-2 failed (%s), falling through", e)

    # Tier 3: hardcoded fallback
    return _hardcoded_for_context(context)

Der Dispatch ist bewusst dumm gehalten. Jeder Tier liefert entweder eine brauchbare Response oder nichts; und wenn es nichts ist, läuft der nächste. Keine Koordination, keine Retry-Logik auf dieser Ebene, keine cleveren Circuit Breaker.

Was jeder Tier macht

Tier 1 — LLM-API ist die Default-Option. Beste Output-Qualität. Aber auch der Tier, der ausfällt, wenn das Netzwerk wegbricht, wenn du an Rate-Limits stößt, wenn der Provider einen Incident hat, wenn dein Key ohne Vorwarnung rotiert wird oder wenn ein Modell, auf das du dich verlässt, deprecated wird. Plane für all diese Fälle.

Tier 2 — regelbasiertes Reasoning führt dieselbe Logik aus, lokal, in ganz normalem Python. Für einen AI-Coach, der Input-Verbesserungen vorschlägt: eine handgeschriebene Rules-Engine mit grob 60 if/else-Zweigen deckt die häufigsten Feedback-Muster ab. Weniger elegant, aber in 80 % der Fälle richtig und sofort verfügbar.

Tier 3 — hartkodiert ist das absolute Minimum. Ein kleines Dictionary mit kontextgebundenen Standardantworten. Langweilig, repetitiv, aber zuverlässig. Wenn Tier 1 und Tier 2 scheitern, bekommt der Nutzer wenigstens irgendetwas — und irgendetwas ist immer besser als ein Error-Toast.

Wann Tier 2 sinnvoll ist und wann nicht

Tier 2 ist paradoxerweise der teuerste Tier zum Bauen — es ist Code, und Code zu schreiben kostet mehr Zeit als ein API-Aufruf. Du baust ihn, wenn:

• Das Feature in einem kritischen User-Flow sitzt (jede Session trifft es)
• „Keine Response" ein sichtbarer Bruch im Produkt ist
• Der Regelraum klein genug ist, um ihn auszuschreiben

Du lässt ihn weg, wenn:

• Das Feature selten genutzt wird oder unkritisch ist
• Ein Failure sich elegant lösen lässt (ein „Erneut versuchen"-Button)
• Der Regelraum wirklich offen ist (kreatives Schreiben zum Beispiel)

Für die meisten Features reichen Tier 1 + Tier 3. Der mittlere Tier ist für Produkte, bei denen Reliability Teil der Marke ist.

Cache ist fast ein eigener Tier

Direkt unter Tier 1, vor jedem Aufruf, kann eine Cache-Schicht die API komplett überspringen. Cache-Keys sind meist (context-hash, mood, last-action) oder etwas Vergleichbares. Eine Hit-Rate von 40–60 % ist realistisch für einen Chat-Agenten mit wiederkehrenden Mustern.

Cache-TTLs sind allerdings ein Tuning-Problem. Zu lang, und der Agent „wiederholt sich" — Nutzer sehen dieselbe Antwort zweimal in einer Session und die Illusion zerbricht. Zu kurz, und du zahlst API-Kosten, die du nicht hättest zahlen müssen. Fang bei 30 Minuten an und passe anhand von Beschwerden über Wiederholungen an.

Observability pro Tier

Logge, welcher Tier jede Anfrage bearbeitet hat. Nach einer Woche siehst du die echte Verteilung. Wenn Tier 1 99 % bedient und Tier 2 + 3 zusammen 1 %, kannst du Tier 2 wahrscheinlich streichen. Wenn Tier 2 auf 15 % kommt: der trägt sein Gewicht — und deine API ist weniger zuverlässig, als du dachtest.

Die Zahlen überraschen dich meistens in mindestens eine Richtung.

Was es deiner Marke bringt

Der größte unsichtbare Gewinn dieses Musters: Wenn andere AI-Produkte sichtbar ausfallen (Toast-Errors, kaputte Loading-States, „AI is currently unavailable"-Banner), läuft dein Produkt einfach weiter. Etwas weniger smart, etwas langweiliger, aber immer noch funktional.

Ein Nutzer, der schon ein paar Mal von einem ausgefallenen AI-Produkt enttäuscht wurde, wird deinem vertrauen — selbst wenn auch dieses zehnmal down war und er einfach Tier-3-Responses bekam, ohne es zu merken.