Vinster:
- Möjlighet att etablera en säker moln LLM-arkitektur som inte håller API-nyckeln på klienten utan går genom en back-end proxy
- Förmåga att skriva robusta integrationer som ökar den upplevda hastigheten med streaming och försiktigt hantera situationer som timeouts, nätverksfel och hastighetsgränser
- Möjlighet att minska kostnaderna genom att förkorta den skickade token och ifrågasätta nödvändigheten av personlig data innan den går till molnet
AI på enheten är kraftfull men begränsad. När du vill lägga till en verkligt "smart chattassistent", lång textsammanfattning eller komplex kreativ produktion till en app, behöver du modeller som är för stora för att få plats på en telefon. Det är här moln AI kommer in i bilden: din applikation ansluter till en stor språkmodell (LLM) via ett API (Application Programming Interface – standardgränssnittet där två programvaror skickar och tar emot data till varandra). I denna enhet kommer vi att lära oss hur man integrerar moln LLM i en mobilapplikation på ett säkert, snabbt och kostnadsmedvetet sätt. Den kritiska tonvikten kommer att ligga på säkerhet: en felaktigt installerad LLM-integration kan läcka din API-nyckel och resultera i räkningar värda tusentals pund.
Arkitekturens gyllene regel: behåll nyckeln på kunden
Det farligaste misstaget som kan göras i moln AI-integration är att bädda in API-nyckeln (det hemliga lösenordet som tillåter användning av tjänsten) direkt i mobilapplikationskoden. Mobilapplikationer laddas ner till användarens enhet och koden kan läsas genom omvänd ingenjörskonst - genom att analysera den kompilerade applikationen och se vad som finns i den. Om din nyckel finns i appen kan någon extrahera den och göra obegränsade förfrågningar från ditt konto.
Den korrekta arkitekturen är denna: mobilapplikationen skickar förfrågningar till din egen backend-server (proxyservern du kontrollerar); Nyckeln finns bara på servern; Servern går till LLM-tjänsten och returnerar svaret till applikationen. Denna mellanvara ger också hastighetstak, förebyggande av missbruk och kostnadskontroll.
Tillvägagångssätt
var är nyckeln
Säkerhet
Nyckeln finns i applikationen (FALSK)
I klient, offentlig
Det läcker, räkningen exploderar
Nyckeln finns i backend (TRUE)
På servern, dold
Säker, kontrollerbar
Varning: När du ber AI om moln LLM-integration, kan den producera ett exempel som skriver nyckeln direkt i applikationskoden för din bekvämlighet. Ta aldrig detta live. Se till att inkludera meningen "API-nyckeln ska inte finnas på klienten, gå igenom backend-proxyn" i prompten.
Streaming: öka den upplevda hastigheten
LLM-svar kan vara långa och ta sekunder att producera i sin helhet. Att låta användaren vänta på en tom skärm är en dålig upplevelse. Lösningen strömmar — visar svaret ord för ord, allt eftersom det genereras. Användaren övervakar stavningen av texten, som i ChatGPT; detta ökar dramatiskt upplevd hastighet och flyt. Flöde på mobilen innebär att man lägger till bitar (tokens — textstycket som produceras av modellen) från servern till gränssnittet när de anländer. Begär uttryckligen flödet vid utskrift av integration till AI.
Tips: Lägg till en "paus"-knapp i streamingsvaret. Användaren ska kunna stoppa produktionen när han får det svar han vill ha; Detta både förbättrar upplevelsen och minskar kostnaderna genom att minska onödig tokengenerering. Mitt i det långa svaret kan användaren redan ha hittat sitt svar.
Hantering av kostnader, förseningar och fel
Cloud LLM bär pengakostnad (avgift per token) och tidskostnad (latens) med varje begäran. Tre discipliner är viktiga. Cost: limit prompt and response length, do not send unnecessarily long system instructions, default to small and cheap model if possible. Latens: använd streaming, ställ in timeout, meddela användaren om nätverket är långsamt. Fel: nätverksavbrott, tjänsten kan returnera 429 (för många förfrågningar) eller 500 (serverfel); hantera var och en försiktigt, krascha inte appen. Dessutom ger LLM ibland meningslösa eller felaktiga (hallucinations) svar; Lägg till ett lager av verifiering av svaret i kritiska områden.
tre minifodral
Fall 1 — Läckt nyckel. En startup bäddade in OpenAI-nyckeln direkt i sin React Native-app för att komma ut snabbt. Tre veckor efter att appen släpptes gjordes nyckeln omvänd konstruerad och användes över en natt till ett värde av 2 400 USD. Teamet var tvungen att återkalla nyckeln och sätta upp en backend-proxy. Lärdom: genvägen som togs för bekvämlighets skull blev den dyraste vägen.
Fall 2 — Bortfallet minskade med flödet. En utbildningsapp släppte först sin Q&A-funktion utan streaming; användare lämnade efter 6 sekunders väntan i viloläge. När flödet lades till började det första ordet dyka upp efter 0,8 sekunder, och avbrottsfrekvensen sjönk från 48 % till 12 %. Samma modell, samma hastighet — bara en skillnad i presentation.
Fall 3 — Kostnadskontroll. En app skickade hela chatthistoriken till modellen med varje användarmeddelande; I långa samtal nådde en enda begäran 8 000 tokens, vilket ökade kostnaden. Genom att bara skicka de sista meddelandena och en sammanfattning minskade teamet tokens per begäran med 70 %, vilket minskade den månatliga räkningen till en tredjedel. Lektion: mät vad du skickar.
Svag prompt / Stark prompt
Svag uppmaning: "Lägg till en chatt som ChatGPT till min app."
Kraftfull uppmaning: "Lägg till en chattassistent till min iOS/Swift-applikation. Arkitektur: applikationen skickar en förfrågan till min egen backend, LLM API-nyckeln finns INTE på KLIENT, den går via proxyn. - Svaret kommer strömmande, visas ord för ord - 'Stopp'-knappen avbryter produktionen - Hantera timeout, nätverkshistorik, 50 förkorta chattsituationen, 409 förkorta chatten. 6 meddelanden + sammanfattning (kostnadskontroll) Förklara arkitekturdiagrammet först, ge sedan klienten och proxykoden separat."
Kopierbara mallar
Säker arkitekturmall: "Design moln-LLM-integration i min [plattform]-applikation. Regel: API-nyckel endast i backend. Klient -> min proxy -> LLM. I proxy: autentisering, gräns för per-användare, begärandeloggning. Lista klient- och proxyansvar separat, exportera sedan koden."
Streamingmall: "Lägg till ett strömmande svar på den här chattskärmen:- Lägg till utdrag i meddelandebubblan när de anländer- Visa en markör/animation medan du skriver- Låt 'Stopp'-knappen avbryta strömmen- Spara en del av texten och varna om det finns ett fel medan strömmen avslutas[befintlig kod]"
Kostnadsfördröjningsmall: "Minska kostnaden och latensen i denna LLM-integrering:- Hur minskar jag skickade token (historikförkortning, sammanfattning)?- I vilket fall räcker det med mindre/billigare modell?- Föreslå timeout och försök igen strategi[kod]"
Feltoleransmall: "Gör detta LLM-samtal motståndskraftigt:- Separat beteende utan nätverk, timeout, 429 (hastighetsgräns), 500 (server)- Icke-tekniskt, artigt meddelande till användaren- Verifieringsnotis mot risk för hallucinationer i kritiska svar[kod]"
Vanliga misstag
- Bädda in API-nyckeln i applikationen. Det dyraste och vanligaste säkerhetsfelet; Nyckeln ligger definitivt på baksidan.
- Använder inte flow. Att låta användaren vänta på långa svar kommer att driva bort användaren.
- Skickar hela chatthistoriken med varje förfrågan. Det multiplicerar tokenkostnad och latens.
- Förbigå feltillstånd. Om 429/500/timeout inte åtgärdas kommer programmet att krascha eller frysa.
- Anser LLM-svaret som korrekt utan fråga. Hallucinationen är verklig; Lägg till verifieringslager i kritiskt område.
- Skickar användardata till onödiga LLM. Fråga om personuppgifter krävs eller bör maskeras innan de går till molnet.
Sammanfattningsvis
Cloud LLM ger fantastiska funktioner som inte passar på enheten till mobilen, men kräver säkerhet och kostnadsdisciplin. Gyllene regel: API-nyckeln finns aldrig på klienten, den går genom backend-proxyn. Flödet ökar kraftigt upplevd hastighet och retention; Stöds av "stopp"-knappen. Kostnaden bestäms genom att förkorta den skickade token; Motståndskraft uppnås genom att hantera alla felfall på ett elegant sätt. LLM-svar kan innehålla hallucinationer; I kritiska områden är verifiering viktigt och personuppgifter granskas innan de skickas till molnet.
Applikationsuppgift
Begär en klient + backend-proxydesign från AI:n med hjälp av "Säker arkitekturmallen" för en "textsammanfattning" eller "chatt"-funktion. Verifiera att API-nyckeln endast finns i backend i den genererade designen. Extrahera sedan minst två sätt för att minska token som skickas med "Kostnadsfördröjningsmönstret" och skriv det artiga meddelandet som ska visas för användaren för ett feltillstånd (t.ex. 429).
checklista
- [ ] Jag verifierade att API-nyckeln finns i backend och inte på klienten
- [ ] Jag strömmade svaret och la till en "paus"-knapp
- [ ] Jag hanterade timeout, nätverksfel, 429 och 500 situationer
- [ ] Jag minskade den inskickade token med den tidigare förkortningen/sammanfattningen
- [ ] Jag övervägde validering mot risken för hallucinationer i LLM-svaret
- [ ] Jag kontrollerade nödvändigheten/maskeringen av personuppgifter innan jag gick till molnet