Nyereség:
- Lehetőség egy biztonságos felhőalapú LLM architektúra létrehozására, amely nem tartja meg az API kulcsot az ügyfélen, hanem egy háttérproxyn megy keresztül
- Robusztus integrációk írásának képessége, amelyek növelik az észlelt sebességet a streaminggel, és finoman kezelik az olyan helyzeteket, mint például időtúllépések, hálózati hibák és sebességkorlátozások
- Képes csökkenteni a költségeket az elküldött token lerövidítésével, és megkérdőjelezni a személyes adatok szükségességét, mielőtt azok a felhőbe kerülnének
Az eszközön lévő mesterséges intelligencia erős, de korlátozott. Ha valóban „intelligens csevegési asszisztenst”, hosszú szöveges összefoglalót vagy összetett kreatív alkotást szeretne hozzáadni egy alkalmazáshoz, akkor olyan modellekre van szüksége, amelyek túl nagyok ahhoz, hogy elférjenek egy telefonban. Itt jön képbe a felhő AI: az alkalmazás egy API-n (Application Programming Interface) keresztül csatlakozik egy nagy nyelvi modellhez (LLM) – a szabványos interfész, ahol két szoftver adatokat küld és fogad egymásnak. Ebben a részben megtanuljuk, hogyan integrálható a felhő LLM biztonságos, gyors és költségtudatos módon egy mobilalkalmazásba. A kritikus hangsúly a biztonságon lesz: a helytelenül telepített LLM-integráció kiszivároghat az API-kulcsból, és több ezer font értékű számlákat eredményezhet.
Az építészet aranyszabálya: tartsa a kulcsot az ügyfélen
A felhő AI integráció során elkövethető legveszélyesebb hiba az API kulcs (a szolgáltatás használatára jogosító titkos jelszó) közvetlen beágyazása a mobilalkalmazás kódjába. A mobilalkalmazások letöltésre kerülnek a felhasználó eszközére, és a kód visszafejtéssel olvasható ki – a lefordított alkalmazás elemzésével, és megnézi, mi van benne. Ha a kulcsa az alkalmazásban van, valaki kibonthatja azt, és korlátlan számú kérést intézhet fiókjából.
A helyes architektúra a következő: a mobilalkalmazás kéréseket küld a saját háttérkiszolgálójának (az Ön által vezérelt proxyszervernek); A kulcs csak a szerveren található; A szerver az LLM szolgáltatáshoz lép, és visszaküldi a választ az alkalmazásnak. Ez a köztes szoftver sebességkorlátozást, visszaélés-megelőzést és költségszabályozást is biztosít.
Megközelítés
hol a kulcs
Biztonság
A kulcs az alkalmazásban van (HAMIS)
Ügyfélben, nyilvánosan
Kiszivárog, a számla felrobban
A kulcs a háttérben van (TRUE)
A szerveren, rejtve
Biztonságos, irányítható
Vigyázat: Ha a mesterséges intelligencia felhőalapú LLM-integrációját kéri, olyan példát produkálhat, amely a kulcsot közvetlenül az alkalmazás kódjába írja az Ön kényelme érdekében. Soha ne vedd ezt élőben. Ügyeljen arra, hogy a promptban szerepeljen a „Az API-kulcs ne legyen az ügyfélen, menjen át a háttérproxyn” mondatot.
Streaming: az észlelt sebesség növelése
Az LLM válaszok hosszúak lehetnek, és másodpercekig tarthatnak, amíg teljes egészükben elkészülnek. Rossz élmény, ha a felhasználót üres képernyőn hagyjuk várakozni. A megoldás a streaming – szóról szóra jeleníti meg a választ a generálás során. A felhasználó figyeli a szöveg helyesírását, mint a ChatGPT-ben; ez drámaian növeli az észlelt sebességet és folyékonyságot. A Flow on mobile azt jelenti, hogy darabokat (tokeneket – a modell által előállított szövegrészeket) adunk hozzá a szerverről az interfészhez, amint megérkeznek. Kifejezetten kérje a folyamatot az AI-ba való integráció nyomtatásakor.
Tipp: Adjon hozzá egy „szünet” gombot a streamelési válaszhoz. A felhasználónak képesnek kell lennie a termelés leállítására, amikor megkapja a kívánt választ; Ez javítja az élményt és csökkenti a költségeket a szükségtelen tokengenerálás csökkentésével. A hosszú válasz közepén a felhasználó talán már megtalálta a választ.
Költség-, késedelem- és hibakezelés
A Cloud LLM minden kérésnél pénzköltséget (tokenenkénti díj) és időköltséget (latencia) hordoz. Három tudományág elengedhetetlen. Cost: limit prompt and response length, do not send unnecessarily long system instructions, default to small and cheap model if possible. Késés: adatfolyam használata, időtúllépés beállítása, a felhasználó értesítése, ha a hálózat lassú. Hiba: hálózati kimaradás, a szolgáltatás 429-et (túl sok kérés) vagy 500-at (szerverhiba) adhat vissza; mindegyiket óvatosan kezelje, ne omolja össze az alkalmazást. Ezenkívül az LLM néha értelmetlen vagy helytelen (hallucináció) válaszokat ad; Adjon hozzá egy réteget a válasz ellenőrzéséhez a kritikus területeken.
három mini tok
1. eset – Kiszivárgott kulcs. Egy startup közvetlenül a React Native alkalmazásába ágyazta be az OpenAI kulcsot, hogy gyorsan kiszálljon. Három héttel az alkalmazás megjelenése után a kulcsot visszafejtették, és 2400 dollár értékben használták egyik napról a másikra. A csapatnak vissza kellett vonnia a kulcsot, és be kellett állítania egy háttérproxyt. Tanulság: a kényelemből vett parancsikon lett a legdrágább útvonal.
2. eset – A lemorzsolódás az áramlással csökkent. Egy oktatási alkalmazás először streamelés nélkül adta ki Kérdések és válaszok funkcióját; A felhasználók 6 másodperces tétlen várakozás után léptek ki. A flow hozzáadásával az első szó 0,8 másodpercen belül elkezdett megjelenni, és az elhagyási arány 48%-ról 12%-ra csökkent. Ugyanaz a modell, ugyanaz a sebesség – csak különbség a megjelenítésben.
3. eset – Költségszabályozás. Az egyik alkalmazás minden felhasználói üzenettel elküldte a teljes csevegési előzményeket a modellnek; Hosszú beszélgetések során egyetlen kérés elérte a 8000 tokent, ami megnövelte a költségeket. Csak az utolsó néhány üzenet és egy összefoglaló elküldésével a csapat 70%-kal csökkentette a kérésenkénti tokeneket, harmadára csökkentette a havi számlát. Tanulság: mérd meg, amit küldesz.
Gyenge felszólítás / Erős felszólítás
Gyenge felszólítás: "Adjon hozzá egy csevegést, például a ChatGPT-t az alkalmazásomhoz."
Hatékony prompt: "Csevegési asszisztens hozzáadása az iOS/Swift alkalmazásomhoz. Architektúra: az alkalmazás kérelmet küld a saját háttérrendszeremre, az LLM API kulcs NINCS a KLIENSEN, hanem a proxyn keresztül megy. - A válasz streamelve érkezik, szóról szóra megjelenítve - A "Stop" gomb megszakítja a termelést - Időtúllépés, hálózati hiba kezelése, 50 -2. küldje el az utolsó 6 üzenetet + összefoglaló (költségkontroll)Először magyarázza el az építészeti diagramot, majd adja meg külön a kliens és a proxy kódot."
Másolható sablonok
Biztonságos architektúra sablon:"Felhő LLM-integráció tervezése [platform] alkalmazásomba. Szabály: API kulcs csak a háttérben. Kliens -> proxy -> LLM. Proxyban: hitelesítés, felhasználónkénti sebességkorlát, kérések naplózása. Listázza ki külön a kliens és a proxy felelősségeit, majd exportálja a kódot."
Streaming-sablon: "Adjon hozzá egy adatfolyam-választ ehhez a csevegőképernyőhöz: - Részvények hozzáadása az üzenetbuborékhoz, amint megérkeznek - Kurzor/animáció megjelenítése gépelés közben - A "Stop" gomb megnyomásával megszakíthatja az adatfolyamot - Részleges szöveg megőrzése, és figyelmeztetés, ha hiba történik a stream befejezése közben [meglévő kód]"
Költség-latencia sablon: "Költség és késleltetés csökkentése ebben az LLM-integrációban:- Hogyan csökkenthetem az elküldött tokent (előzmények rövidítése, összefoglaló)?- Melyik esetben elegendő a kisebb/olcsóbb modell?- Javasoljon időtúllépést és próbálkozzon újra stratégiával[kód]"
Hibatűrési sablon: "Tegye ezt az LLM-hívást rugalmassá: - Különálló viselkedés hálózat nélkül, időtúllépés, 429 (sebességkorlát), 500 (szerver) - Nem technikai jellegű, udvarias üzenet a felhasználónak - Ellenőrző megjegyzés a kritikus válaszok hallucinációinak kockázatára [kód]"
Gyakori hibák
- Az API-kulcs beágyazása az alkalmazásba. A legdrágább és leggyakoribb biztonsági hiba; A kulcs határozottan a hátsó végén található.
- Nem használ áramlást. Ha hagyja, hogy a felhasználó hosszú válaszokra várjon, az elűzi a felhasználót.
- A teljes csevegési előzmény elküldése minden kéréssel. Megsokszorozza a token költségét és a késleltetést.
- Hibafeltételek megkerülése. Ha a 429/500/timeout nem foglalkozik, az alkalmazás összeomlik vagy lefagy.
- Az LLM választ kérdés nélkül helyesnek tekintve. A hallucináció valódi; Adjon hozzá ellenőrző réteget a kritikus területen.
- Felhasználói adatok küldése a szükségtelen LLM-nek. Kérdezze meg, hogy szükség van-e személyes adatokra, vagy el kell takarni azokat, mielőtt a felhőbe kerülne.
Összefoglalva
A Cloud LLM olyan nagyszerű képességeket hoz, amelyek nem férnek el az eszközön a mobilhoz, de biztonságot és költségfegyelmet igényelnek. Aranyszabály: Az API-kulcs soha nincs a kliensen, hanem a háttérproxyn megy keresztül. Az áramlás nagymértékben növeli az észlelt sebességet és a visszatartást; A "stop" gomb támogatja. A költséget a küldött token lerövidítése határozza meg; Az ellenálló képesség úgy érhető el, ha minden hibaesetet kecsesen kezelünk. Az LLM-válaszok tartalmazhatnak hallucinációkat; A kritikus területeken az ellenőrzés elengedhetetlen, és a személyes adatokat felülvizsgálják, mielőtt elküldenék őket a felhőbe.
Pályázati feladat
Kérjen kliens + háttérproxy tervezést az AI-tól a „Biztonságos architektúra sablon” segítségével „szövegösszegzés” vagy „csevegés” funkcióhoz. Ellenőrizze, hogy az API-kulcs csak a háttérben található-e a generált tervben. Ezután vegyen ki legalább két módot a „Költségkésleltetési mintával” küldött token csökkentésére, és írja meg az udvarias üzenetet, amelyet hibaállapot esetén (pl. 429) kell megjeleníteni a felhasználónak.
ellenőrző lista
- [ ] Ellenőriztem, hogy az API-kulcs a háttérben található, és nem az ügyfélen
- [ ] Elküldtem a választ, és hozzáadtam egy „szünet” gombot
- [ ] Kezeltem az időtúllépést, a hálózati hibát, a 429-es és az 500-as helyzeteket
- [ ] A beküldött tokent csökkentettem a múltbeli rövidítéssel/összefoglalóval
- [ ] Az LLM-válaszban a hallucinációk kockázatával szembeni érvényesítést mérlegeltem
- [ ] A felhőbe járás előtt ellenőriztem a személyes adatok szükségességét/maszkolását