Gewinne:
- Möglichkeit zum Aufbau einer sicheren Cloud-LLM-Architektur, die den API-Schlüssel nicht auf dem Client behält, sondern über einen Back-End-Proxy läuft
- Fähigkeit, robuste Integrationen zu schreiben, die die wahrgenommene Geschwindigkeit beim Streaming erhöhen und Situationen wie Zeitüberschreitungen, Netzwerkfehler und Geschwindigkeitsbegrenzungen sanft bewältigen
- Möglichkeit, die Kosten zu senken, indem das gesendete Token verkürzt wird und die Notwendigkeit personenbezogener Daten in Frage gestellt wird, bevor diese in die Cloud übertragen werden
Die KI auf dem Gerät ist leistungsstark, aber begrenzt. Wenn Sie einer App einen wirklich „intelligenten Chat-Assistenten“, eine lange Textzusammenfassung oder eine komplexe kreative Produktion hinzufügen möchten, benötigen Sie Modelle, die zu groß sind, um auf ein Telefon zu passen. Hier kommt Cloud AI ins Spiel: Ihre Anwendung verbindet sich über eine API (Application Programming Interface – die Standardschnittstelle, über die zwei Softwareprogramme Daten miteinander senden und empfangen) mit einem großen Sprachmodell (LLM). In dieser Einheit lernen wir, wie wir Cloud LLM sicher, schnell und kostenbewusst in eine mobile Anwendung integrieren. Der entscheidende Schwerpunkt wird auf der Sicherheit liegen: Eine falsch installierte LLM-Integration könnte Ihren API-Schlüssel preisgeben und zu Rechnungen im Wert von mehreren Tausend Pfund führen.
Die goldene Regel der Architektur: Behalten Sie den Schlüssel beim Client
Der gefährlichste Fehler, der bei der Cloud-KI-Integration gemacht werden kann, besteht darin, den API-Schlüssel (das geheime Passwort, das die Nutzung des Dienstes autorisiert) direkt in den Code der mobilen Anwendung einzubetten. Mobile Anwendungen werden auf das Gerät des Benutzers heruntergeladen und der Code kann durch Reverse Engineering gelesen werden, indem die kompilierte Anwendung analysiert und der Inhalt überprüft wird. Wenn sich Ihr Schlüssel in der App befindet, kann ihn jemand extrahieren und unbegrenzte Anfragen von Ihrem Konto aus stellen.
Die richtige Architektur sieht folgendermaßen aus: Die mobile Anwendung sendet Anfragen an Ihren eigenen Backend-Server (den von Ihnen kontrollierten Proxyserver); Der Schlüssel befindet sich nur auf dem Server; Der Server geht zum LLM-Dienst und gibt die Antwort an die Anwendung zurück. Diese Middleware bietet außerdem Geschwindigkeitsbegrenzung, Missbrauchsprävention und Kostenkontrolle.
Ansatz
Wo ist der Schlüssel?
Sicherheit
Der Schlüssel liegt in der Anwendung (FALSE)
Im Client, öffentlich
Es sickert durch, die Rechnung explodiert
Der Schlüssel liegt im Backend (WAHR)
Auf dem Server, versteckt
Sicher, kontrollierbar
Achtung: Wenn Sie AI um die Cloud-LLM-Integration bitten, wird möglicherweise ein Beispiel erstellt, das den Schlüssel zur Vereinfachung direkt in den Anwendungscode schreibt. Nimm das niemals live. Stellen Sie sicher, dass Sie in der Eingabeaufforderung den Satz „Der API-Schlüssel sollte sich nicht auf dem Client befinden, gehen Sie über den Backend-Proxy“ ein.
Streaming: Erhöhung der wahrgenommenen Geschwindigkeit
LLM-Antworten können lang sein und es dauert nur wenige Sekunden, bis sie vollständig vorliegen. Den Benutzer auf einem leeren Bildschirm warten zu lassen, ist eine schlechte Erfahrung. Die Lösung ist Streaming – die Anzeige der Antwort Wort für Wort, während sie generiert wird. Der Benutzer überwacht die Rechtschreibung des Textes, wie bei ChatGPT; Dies erhöht die wahrgenommene Geschwindigkeit und Sprachkompetenz erheblich. Unter Flow auf Mobilgeräten versteht man das Hinzufügen von Teilen (Tokens – die vom Modell erzeugten Textteile) vom Server zur Schnittstelle, sobald diese eintreffen. Fordern Sie den Flow beim Drucken der Integration in AI explizit an.
Tipp: Fügen Sie der Streaming-Antwort eine Schaltfläche „Pause“ hinzu. Der Benutzer sollte in der Lage sein, die Produktion zu stoppen, wenn er die gewünschte Antwort erhält; Dies verbessert sowohl das Erlebnis als auch die Kosten, indem unnötige Token-Generierung vermieden wird. In der Mitte der langen Antwort hat der Benutzer möglicherweise bereits seine Antwort gefunden.
Kosten-, Verzögerungs- und Fehlermanagement
Bei Cloud LLM fallen bei jeder Anfrage Geldkosten (Gebühr pro Token) und Zeitkosten (Latenz) an. Drei Disziplinen sind unerlässlich. Cost: limit prompt and response length, do not send unnecessarily long system instructions, default to small and cheap model if possible. Latenz: Streaming verwenden, Timeout festlegen, Benutzer benachrichtigen, wenn das Netzwerk langsam ist. Fehler: Netzwerkausfall, der Dienst gibt möglicherweise 429 (zu viele Anfragen) oder 500 (Serverfehler) zurück; Behandeln Sie jeden vorsichtig, lassen Sie die App nicht abstürzen. Außerdem gibt LLM manchmal bedeutungslose oder falsche (Halluzinations-)Antworten; Fügen Sie in kritischen Bereichen eine Ebene zur Überprüfung der Antwort hinzu.
drei Mini-Koffer
Fall 1 – Durchgesickerter Schlüssel. Ein Startup hat den OpenAI-Schlüssel direkt in seine React Native-App eingebettet, um schnell herauszukommen. Drei Wochen nach der Veröffentlichung der App wurde der Schlüssel rückentwickelt und über Nacht im Wert von 2.400 US-Dollar genutzt. Das Team musste den Schlüssel widerrufen und einen Backend-Proxy einrichten. Lektion: Die aus Bequemlichkeitsgründen gewählte Abkürzung wurde zur teuersten Route.
Fall 2 – Der Dropout nahm mit der Strömung ab. Eine Bildungs-App veröffentlichte ihre Frage-und-Antwort-Funktion zunächst ohne Streaming. Benutzer verließen das Unternehmen nach 6 Sekunden untätigem Warten. Als Flow hinzugefügt wurde, erschien das erste Wort bereits nach 0,8 Sekunden und die Abbruchrate sank von 48 % auf 12 %. Gleiches Modell, gleiche Geschwindigkeit – nur ein Unterschied in der Präsentation.
Fall 3 – Kostenkontrolle. Eine App sendete mit jeder Benutzernachricht den gesamten Chatverlauf an das Modell. In langen Gesprächen erreichte eine einzelne Anfrage 8.000 Token, was die Kosten in die Höhe trieb. Indem das Team nur die letzten paar Nachrichten und eine Zusammenfassung verschickte, reduzierte es die Token pro Anfrage um 70 %, wodurch sich die monatliche Rechnung auf ein Drittel reduzierte. Lektion: Messen Sie, was Sie senden.
Schwache Eingabeaufforderung / Starke Eingabeaufforderung
Schwache Aufforderung: „Füge einen Chat wie ChatGPT zu meiner App hinzu.“
Leistungsstarke Eingabeaufforderung: „Fügen Sie einen Chat-Assistenten zu meiner iOS/Swift-Anwendung hinzu. Architektur: Die Anwendung sendet eine Anfrage an mein eigenes Backend, der LLM-API-Schlüssel befindet sich NICHT auf dem CLIENT, er geht über den Proxy. – Die Antwort wird gestreamt und Wort für Wort angezeigt – Die Schaltfläche „Stopp“ unterbricht die Produktion – Behandeln Sie Timeout, Netzwerkfehler, 429- und 500-Situationen ordnungsgemäß – Verkürzen Sie den Chat-Verlauf: Senden Sie die letzten 6 Nachrichten + Zusammenfassung (Kostenkontrolle). Erklären Sie zuerst das Architekturdiagramm und geben Sie dann ab den Client- und Proxy-Code separat.
Kopierbare Vorlagen
Vorlage für sichere Architektur: „Entwerfen Sie die Cloud-LLM-Integration in meine [Plattform-]Anwendung. Regel: API-Schlüssel nur im Backend. Client -> mein Proxy -> LLM. Im Proxy: Authentifizierung, Ratenbegrenzung pro Benutzer, Anforderungsprotokollierung. Listen Sie die Client- und Proxy-Verantwortlichkeiten getrennt auf und exportieren Sie dann den Code.“
Streaming-Vorlage: „Fügen Sie eine Streaming-Antwort zu diesem Chat-Bildschirm hinzu: – Fügen Sie Snippets zur Nachrichtenblase hinzu, sobald sie eintreffen – Zeigen Sie einen Cursor/eine Animation während der Eingabe an – Lassen Sie den Stream mit der Schaltfläche „Stopp“ abbrechen – Behalten Sie Teiltext bei und warnen Sie, wenn ein Fehler auftritt, während der Stream endet [vorhandener Code]“
Kosten-Latenz-Vorlage: „Reduzieren Sie Kosten und Latenz bei dieser LLM-Integration: – Wie reduziere ich gesendete Token (Verlaufsabkürzung, Zusammenfassung)? – In welchem Fall reicht ein kleineres/günstigeres Modell aus? – Schlagen Sie eine Timeout- und Wiederholungsstrategie vor[Code]“
Fehlertoleranzvorlage: „Machen Sie diesen LLM-Anruf widerstandsfähig: – Separates Verhalten für kein Netzwerk, Zeitüberschreitung, 429 (Ratenbegrenzung), 500 (Server) – Nicht-technische, höfliche Nachricht an den Benutzer – Verifizierungshinweis gegen das Risiko einer Halluzination in kritischen Antworten[Code]“
Häufige Fehler
- Einbetten des API-Schlüssels in die Anwendung. Der teuerste und häufigste Sicherheitsfehler; Der Schlüssel liegt definitiv im Backend.
- Flow wird nicht verwendet. Wenn man den Benutzer auf lange Antworten warten lässt, wird er abgeschreckt.
- Bei jeder Anfrage wird der gesamte Chatverlauf verschickt. Es vervielfacht die Token-Kosten und die Latenz.
- Fehlerbedingungen umgehen. Wenn 429/500/Timeout nicht behoben wird, stürzt die Anwendung ab oder friert ein.
- Betrachten Sie die LLM-Antwort ohne Frage als richtig. Die Halluzination ist real; Fügen Sie im kritischen Bereich eine Überprüfungsebene hinzu.
- Senden von Benutzerdaten an unnötiges LLM. Fragen Sie, ob personenbezogene Daten erforderlich sind oder maskiert werden sollten, bevor sie in die Cloud übertragen werden.
Zusammenfassend
Cloud LLM bietet großartige Funktionen, die nicht auf Mobilgeräte passen, erfordert aber Sicherheit und Kostendisziplin. Goldene Regel: Der API-Schlüssel befindet sich nie auf dem Client, sondern läuft über den Backend-Proxy. Flow erhöht die wahrgenommene Geschwindigkeit und Bindung erheblich; Unterstützt durch „Stopp“-Taste. Die Kosten werden durch die Verkürzung des gesendeten Tokens ermittelt; Ausfallsicherheit wird durch die ordnungsgemäße Behandlung aller Fehlerfälle erreicht. LLM-Antworten können Halluzinationen beinhalten; In kritischen Bereichen ist eine Verifizierung unerlässlich und personenbezogene Daten werden überprüft, bevor sie an die Cloud gesendet werden.
Anwendungsaufgabe
Fordern Sie von der KI ein Client- und Backend-Proxy-Design an, indem Sie die „Vorlage für sichere Architektur“ für eine „Textzusammenfassung“ oder „Chat“-Funktion verwenden. Stellen Sie sicher, dass sich der API-Schlüssel im generierten Design nur im Backend befindet. Extrahieren Sie dann mindestens zwei Möglichkeiten, um das mit dem „Kostenverzögerungsmuster“ gesendete Token zu reduzieren, und schreiben Sie die Höflichkeitsnachricht, die dem Benutzer bei einer Fehlerbedingung (z. B. 429) angezeigt wird.
Checkliste
- [ ] Ich habe überprüft, dass sich der API-Schlüssel im Backend und nicht auf dem Client befindet
- [ ] Ich habe die Antwort gestreamt und eine Schaltfläche „Pause“ hinzugefügt
- [ ] Ich habe Timeout-, Netzwerkfehler-, 429- und 500-Situationen behandelt
- [ ] Ich habe das übermittelte Token mit der bisherigen Abkürzung/Zusammenfassung gekürzt
- [ ] Ich habe in der LLM-Antwort eine Validierung gegen das Risiko von Halluzinationen in Betracht gezogen
- [ ] Ich habe vor dem Wechsel in die Cloud die Notwendigkeit/Maskierung personenbezogener Daten geprüft