· ship · Aktualisiert am
Fallbacks für unsichere und Offline-Antworten in KI-Apps
Eine gute KI-App braucht eine klare Anzeige für Situationen, in denen das Modell nicht helfen kann. „Keine Antwort“, „keine ausreichenden Belege“ und „keine Verbindung“ sind unterschiedliche Zustände. Ein leerer Chat oder derselbe Ladekreis erklärt nicht, was passiert ist.
Den Fallback nach der Ursache wählen
Findet die Suche keine passenden Inhalte, sagen Sie, dass die verfügbaren Quellen die Frage nicht beantworten, und bieten Sie Suche oder eine engere Frage an. Ist die Antwort unsicher, machen Sie die Grenze sichtbar und zeigen Sie prüfbare Belege. Verlassen Sie sich nicht allein auf eine unkalibrierte Selbsteinschätzung des Modells; definieren Sie den Zustand anhand geprüfter Produktsignale, etwa fehlender Quellenbelege oder eines Guardrail-Ergebnisses. Läuft die Anfrage in einen Timeout oder ist das Gerät offline, bleibt der Entwurf erhalten; ein erneuter Versuch wird bei verfügbarer Verbindung angeboten. Ein Transportfehler ist keine Ablehnung durch das Modell.
Fallbacks sollten sicher und umkehrbar sein. Eine generierte Aktion darf nichts stillschweigend senden oder überschreiben. Wird ein Cache-Ergebnis gezeigt, nennen Sie den letzten Aktualisierungszeitpunkt und ob die Ansicht vollständig ist. Falls das nicht möglich ist, sagen Sie, was weiterhin funktioniert, etwa gespeicherte Inhalte oder ein manueller Ablauf.
Beispiel: Assistent für Projektnotizen
Illustratives Beispiel: Eine mobile App fasst zuvor synchronisierte Projektnotizen zusammen. Im Flugmodus fragt jemand nach einer Zusammenfassung. Die App behält die Frage im Eingabefeld, zeigt „KI-Zusammenfassung offline nicht verfügbar“ und bietet die vier beim Sync um 09:20 gespeicherten Notizen durchsuchbar an. Sie stellt keine aktuelle Zusammenfassung in Aussicht.
Später fragt die Person online, welche Notiz einen Liefertermin freigegeben hat; in den Treffern steht keine Freigabe. Die App sagt, dass sie keine Bestätigung findet, und bietet Quellen sowie manuelle Suche an. Bei einem Timeout bleibt die Frage erhalten und ein Retry wird sichtbar. So entsteht ein nächster Schritt, ohne Gewissheit zu erfinden oder Arbeit zu verlieren.
Checkliste
- Erkennt der Nutzer fehlende Belege, Unsicherheit, Timeout und Offline-Zustand?
- Sind Quelle und Aktualität bei Teil- oder Cache-Ergebnissen sichtbar?
- Kann der Nutzer manuell fortfahren, ohne Frage oder Datei zu verlieren?
- Ist ein Retry ausdrücklich, begrenzt und vor doppelten Aktionen geschützt?
- Warten folgenreiche generierte Aktionen auf Bestätigung?
- Verhindert die Rückkehr der Verbindung eine stille Wiederholung?
Mehr steht in unseren Offline-first-KI-Patterns. Den Umfang passender Leistungen für KI-Apps finden Sie ebenfalls hier.
Geschrieben vom Clutch Developer Studio in Barcelona. Fragen: info@clutchdeveloper.com