Winst:
- Mogelijkheid om een veilige cloud LLM-architectuur op te zetten die de API-sleutel niet op de client bewaart, maar via een back-end proxy gaat
- Mogelijkheid om robuuste integraties te schrijven die de waargenomen snelheid bij streaming verhogen en voorzichtig omgaan met situaties zoals time-outs, netwerkfouten en snelheidslimieten
- Mogelijkheid om de kosten te verlagen door het verzonden token in te korten en de noodzaak van persoonlijke gegevens in twijfel te trekken voordat deze naar de cloud gaan
AI op het apparaat is krachtig maar beperkt. Als je een echt ‘slimme chatassistent’, lange tekstsamenvattingen of complexe creatieve productie aan een app wilt toevoegen, heb je modellen nodig die te groot zijn om op een telefoon te passen. Dit is waar cloud AI in het spel komt: uw applicatie maakt verbinding met een groot taalmodel (LLM) via een API (Application Programming Interface – de standaardinterface waarbij twee software gegevens naar elkaar verzenden en ontvangen). In deze unit leren we hoe we cloud LLM op een veilige, snelle en kostenbewuste manier kunnen integreren in een mobiele applicatie. De kritische nadruk zal liggen op beveiliging: een onjuist geïnstalleerde LLM-integratie kan uw API-sleutel lekken en resulteren in rekeningen ter waarde van duizenden euro's.
De gouden regel van de architectuur: houd de sleutel bij de opdrachtgever
De gevaarlijkste fout die gemaakt kan worden bij de integratie van cloud-AI is het rechtstreeks insluiten van de API-sleutel (het geheime wachtwoord dat het gebruik van de dienst autoriseert) in de code van de mobiele applicatie. Mobiele applicaties worden gedownload naar het apparaat van de gebruiker en de code kan worden gelezen door middel van reverse engineering: het parseren van de gecompileerde applicatie en kijken wat erin zit. Als uw sleutel zich in de app bevindt, kan iemand deze uit uw account halen en onbeperkt verzoeken indienen.
De juiste architectuur is deze: de mobiele applicatie stuurt verzoeken naar uw eigen backend-server (de proxyserver die u beheert); De sleutel bevindt zich alleen op de server; De server gaat naar de LLM-service en stuurt het antwoord terug naar de applicatie. Deze middleware biedt ook snelheidslimieten, misbruikpreventie en kostenbeheersing.
Benadering
waar is de sleutel
Beveiliging
De sleutel bevindt zich in de applicatie (FALSE)
In klant, openbaar
Het lekt, de rekening ontploft
De sleutel bevindt zich in de backend (TRUE)
Op de server, verborgen
Veilig, beheersbaar
Let op: Wanneer u AI om cloud LLM-integratie vraagt, kan deze voor uw gemak een voorbeeld opleveren waarin de sleutel rechtstreeks in de applicatiecode wordt geschreven. Neem dit nooit live mee. Zorg ervoor dat u de zin 'De API-sleutel mag niet op de client staan, ga via de backend-proxy' in de prompt opneemt.
Streaming: het verhogen van de waargenomen snelheid
LLM-antwoorden kunnen lang zijn en het duurt enkele seconden om ze in hun geheel te produceren. De gebruiker op een leeg scherm laten wachten is een slechte ervaring. De oplossing is streaming: het antwoord wordt woord voor woord weergegeven terwijl het wordt gegenereerd. De gebruiker controleert de spelling van de tekst, zoals in ChatGPT; dit verhoogt dramatisch de waargenomen snelheid en vloeiendheid. Flow op mobiel betekent het toevoegen van stukjes (tokens – het stukje tekst dat door het model wordt geproduceerd) van de server naar de interface zodra ze aankomen. Vraag expliciet om de flow bij het printen van de integratie met AI.
Tip: Voeg een pauzeknop toe aan het streamingantwoord. De gebruiker moet de productie kunnen stopzetten wanneer hij het gewenste antwoord krijgt; Dit verbetert zowel de ervaring als verlaagt de kosten door het onnodig genereren van tokens te verminderen. Midden in het lange antwoord heeft de gebruiker mogelijk het antwoord al gevonden.
Beheer van kosten, vertragingen en fouten
Cloud LLM brengt bij elk verzoek geldkosten (kosten per token) en tijdskosten (latentie) met zich mee. Drie disciplines zijn essentieel. Cost: limit prompt and response length, do not send unnecessarily long system instructions, default to small and cheap model if possible. Latency: gebruik streaming, stel een time-out in, stel de gebruiker op de hoogte als het netwerk traag is. Fout: netwerkstoring, service retourneert mogelijk 429 (te veel verzoeken) of 500 (serverfout); behandel ze allemaal voorzichtig en laat de app niet crashen. Ook geeft LLM soms betekenisloze of onjuiste (hallucinatie) antwoorden; Voeg op kritieke gebieden een verificatielaag toe voor het antwoord.
drie minikoffers
Geval 1 — Gelekte sleutel. Een startup heeft de OpenAI-sleutel rechtstreeks in zijn React Native-app ingebed om er snel uit te komen. Drie weken nadat de app was uitgebracht, werd de sleutel reverse-engineered en werd er in één nacht $ 2.400 aan gebruik gemaakt. Het team moest de sleutel intrekken en een backend-proxy opzetten. Les: de voor het gemak genomen kortere route werd de duurste route.
Geval 2 – De uitval nam af met de stroom. Een onderwijsapp bracht voor het eerst zijn vraag- en antwoordfunctie uit zonder streaming; gebruikers verlieten het programma na 6 seconden inactief wachten. Toen flow werd toegevoegd, verscheen het eerste woord binnen 0,8 seconden en daalde het verlatingspercentage van 48% naar 12%. Hetzelfde model, dezelfde snelheid – alleen een verschil in presentatie.
Geval 3 — Kostenbeheersing. Eén app stuurde bij elk gebruikersbericht de volledige chatgeschiedenis naar het model; In lange gesprekken bereikte één enkel verzoek 8.000 tokens, waardoor de kosten hoger uitvielen. Door alleen de laatste paar berichten en een samenvatting te sturen, heeft het team het aantal tokens per verzoek met 70% verlaagd, waardoor de maandelijkse factuur met een derde is gedaald. Les: meet wat je verzendt.
Zwakke prompt/sterke prompt
Zwakke prompt: "Voeg een chat zoals ChatGPT toe aan mijn app."
Krachtige prompt: "Voeg een chatassistent toe aan mijn iOS/Swift-applicatie. Architectuur: de applicatie stuurt een verzoek naar mijn eigen backend, de LLM API-sleutel staat NIET op de CLIENT, deze gaat via de proxy. - Het antwoord komt streaming, woord voor woord weergegeven - De 'Stop'-knop onderbreekt de productie - Handel time-out, netwerkfout, 429 en 500 situaties netjes af - Verkort de chatgeschiedenis: stuur de laatste 6 berichten + samenvatting (kostenbeheersing) Leg de architectuur uit diagram eerst en geef vervolgens de client- en proxycode afzonderlijk op."
Kopieerbare sjablonen
Beveiligde architectuursjabloon: "Ontwerp cloud-LLM-integratie in mijn [platform]-applicatie. Regel: API-sleutel alleen in backend. Klant -> mijn proxy -> LLM. In proxy: authenticatie, snelheidslimiet per gebruiker, logboekregistratie. Geef de client- en proxy-verantwoordelijkheden afzonderlijk weer en exporteer vervolgens de code."
Streamingsjabloon: "Voeg een streamingreactie toe aan dit chatscherm: - Voeg fragmenten toe aan de berichtballon zodra ze binnenkomen - Toon een cursor/animatie tijdens het typen - Zorg dat de knop 'Stop' de stream annuleert - Behoud gedeeltelijke tekst en waarschuw als er een fout is terwijl de stream eindigt [bestaande code]"
Sjabloon voor kostenlatentie: "Verminder kosten en latentie in deze LLM-integratie: - Hoe verminder ik het verzonden token (geschiedenisafkorting, samenvatting)? - In welk geval is een kleiner/goedkoper model voldoende? - Stel een time-out voor en strategie voor opnieuw proberen [code]"
Fouttolerantiesjabloon: "Maak deze LLM-oproep veerkrachtig: - Afzonderlijk gedrag voor geen netwerk, time-out, 429 (snelheidslimiet), 500 (server) - Niet-technisch, beleefd bericht aan de gebruiker - Verificatienotitie tegen het risico van hallucinatie in kritische antwoorden [code]"
Veel voorkomende fouten
- Het inbedden van de API-sleutel in de applicatie. De duurste en meest voorkomende beveiligingsbug; De sleutel ligt zeker aan de achterkant.
- Geen gebruik maken van stroom. Als u de gebruiker op lange antwoorden laat wachten, wordt de gebruiker weggejaagd.
- Bij elk verzoek wordt de volledige chatgeschiedenis verzonden. Het vermenigvuldigt de tokenkosten en latentie.
- Foutcondities omzeilen. Als 429/500/timeout niet wordt aangepakt, zal de applicatie crashen of vastlopen.
- Het LLM-antwoord als correct beschouwen zonder vragen. De hallucinatie is echt; Voeg een verificatielaag toe in het kritieke gebied.
- Gebruikersgegevens naar onnodige LLM verzenden. Vraag of persoonlijke gegevens vereist zijn of moeten worden gemaskeerd voordat deze naar de cloud gaan.
Samengevat
Cloud LLM biedt geweldige mogelijkheden die niet op het apparaat passen bij mobiel, maar vereist beveiliging en kostendiscipline. Gouden regel: De API-sleutel bevindt zich nooit op de client, maar gaat via de backend-proxy. Flow verhoogt de waargenomen snelheid en retentie enorm; Ondersteund door de "stop"-knop. De kosten worden bepaald door het verzonden token in te korten; Veerkracht wordt bereikt door alle foutgevallen netjes af te handelen. LLM-antwoorden kunnen hallucinaties omvatten; Op kritieke gebieden is verificatie essentieel en worden persoonlijke gegevens beoordeeld voordat deze naar de cloud worden verzonden.
Applicatie taak
Vraag een client + backend proxy-ontwerp aan bij de AI met behulp van de “Secure architecture template” voor een “tekstsamenvatting” of “chat” -functie. Controleer of de API-sleutel zich alleen in de backend van het gegenereerde ontwerp bevindt. Extraheer vervolgens ten minste twee manieren om het token dat wordt verzonden met het "Cost-delay patroon" te verminderen en schrijf het beleefde bericht dat aan de gebruiker moet worden weergegeven voor een foutconditie (bijvoorbeeld 429).
controlelijst
- [ ] Ik heb geverifieerd dat de API-sleutel zich in de backend bevindt en niet op de client
- [ ] Ik heb het antwoord gestreamd en een 'pauze'-knop toegevoegd
- [ ] Ik behandelde time-out-, netwerkfout-, 429- en 500-situaties
- [ ] Ik heb het ingediende token verkleind met de vroegere afkorting/samenvatting
- [ ] Ik heb in het LLM-antwoord validatie tegen het risico op hallucinaties overwogen
- [ ] Ik heb de noodzaak/maskering van persoonlijke gegevens gecontroleerd voordat ik naar de cloud ging