Mga nadagdag:
- Kakayahang magtatag ng secure na cloud LLM architecture na hindi pinapanatili ang API key sa client ngunit dumadaan sa back-end proxy
- Kakayahang magsulat ng mga matatag na pagsasama na nagpapataas ng nakikitang bilis sa streaming at malumanay na pangasiwaan ang mga sitwasyon tulad ng mga timeout, mga error sa network at mga limitasyon ng bilis
- Kakayahang bawasan ang gastos sa pamamagitan ng pagpapaikli sa ipinadalang token at pagtatanong sa pangangailangan ng personal na data bago ito mapunta sa cloud
Ang on-device AI ay malakas ngunit limitado. Kapag gusto mong magdagdag ng tunay na "smart chat assistant," mahabang pagbubuod ng text, o kumplikadong creative production sa isang app, kailangan mo ng mga modelong masyadong malaki para magkasya sa isang telepono. Dito pumapasok ang cloud AI: kumokonekta ang iyong application sa isang malaking modelo ng wika (LLM) sa pamamagitan ng isang API (Application Programming Interface – ang karaniwang interface kung saan nagpapadala at tumatanggap ng data ang dalawang software sa isa't isa). Sa yunit na ito matututunan natin kung paano isama ang cloud LLM sa isang mobile application sa isang ligtas, mabilis at cost-conscious na paraan. Ang kritikal na diin ay sa seguridad: ang isang hindi wastong naka-install na integration ng LLM ay maaaring tumagas sa iyong API key at magresulta sa mga singil na nagkakahalaga ng libu-libong pounds.
Ang ginintuang tuntunin ng arkitektura: panatilihin ang susi sa kliyente
Ang pinaka-mapanganib na pagkakamali na maaaring gawin sa cloud AI integration ay ang pag-embed ng API key (ang lihim na password na nagpapahintulot sa paggamit ng serbisyo) nang direkta sa mobile application code. Dina-download ang mga mobile application sa device ng user at mababasa ang code sa pamamagitan ng reverse engineering — pag-parse ng pinagsama-samang application at tingnan kung ano ang nasa loob nito. Kung nasa loob ng app ang iyong susi, maaaring kunin ito ng isang tao at gumawa ng walang limitasyong mga kahilingan mula sa iyong account.
Ang tamang arkitektura ay ito: ang mobile application ay nagpapadala ng mga kahilingan sa iyong sariling backend server (ang proxy server na iyong kinokontrol); Ang susi ay namamalagi lamang sa server; Pumunta ang server sa serbisyo ng LLM at ibinabalik ang tugon sa application. Nagbibigay din ang middleware na ito ng speed capping, pag-iwas sa pang-aabuso, at kontrol sa gastos.
Diskarte
nasaan ang susi
Seguridad
Ang susi ay nasa application (FALSE)
Sa kliyente, pampubliko
Tumutulo, sumasabog ang kuwenta
Ang susi ay nasa backend (TRUE)
Sa server, nakatago
Ligtas, nakokontrol
Babala: Kapag humiling ka sa AI para sa cloud LLM integration, maaari itong makagawa ng isang halimbawa na direktang nagsusulat ng key sa application code para sa iyong kaginhawahan. Huwag kailanman kunin ito nang live. Tiyaking isama ang pangungusap na "Hindi dapat nasa kliyente ang API key, dumaan sa backend proxy" sa prompt.
Streaming: pagtaas ng perceived na bilis
Ang mga sagot sa LLM ay maaaring mahaba at tumagal ng ilang segundo upang makagawa sa kabuuan ng mga ito. Ang pag-iwan sa user na naghihintay sa isang blangkong screen ay isang masamang karanasan. Ang solusyon ay streaming — ipinapakita ang sagot na salita sa pamamagitan ng salita, habang ito ay nabuo. Sinusubaybayan ng gumagamit ang pagbabaybay ng teksto, tulad ng sa ChatGPT; ito ay kapansin-pansing nagpapataas ng perceived na bilis at katatasan. Ang daloy sa mobile ay nangangahulugan ng pagdaragdag ng mga piraso (mga token — ang piraso ng text na ginawa ng modelo) mula sa server patungo sa interface pagdating ng mga ito. Tahasang hilingin ang daloy kapag nagpi-print ng integration sa AI.
Tip: Magdagdag ng "pause" na button sa streaming na tugon. Dapat na maihinto ng user ang produksyon kapag nakuha niya ang sagot na gusto niya; Pareho nitong pinapabuti ang karanasan at binabawasan ang gastos sa pamamagitan ng pagputol ng hindi kinakailangang pagbuo ng token. Sa gitna ng mahabang sagot, maaaring nahanap na ng user ang kanilang sagot.
Gastos, pagkaantala at pamamahala ng error
Ang Cloud LLM ay nagdadala ng halaga ng pera (bayad sa bawat token) at gastos sa oras (latency) sa bawat kahilingan. Tatlong disiplina ang mahalaga. Cost: limit prompt and response length, do not send unnecessarily long system instructions, default to small and cheap model if possible. Latency: gumamit ng streaming, magtakda ng timeout, abisuhan ang user kung mabagal ang network. Error: network outage, serbisyo ay maaaring bumalik 429 (napakaraming mga kahilingan) o 500 (server error); hawakan ang bawat isa nang malumanay, huwag i-crash ang app. Gayundin, kung minsan ang LLM ay nagbibigay ng walang kabuluhan o hindi tama (hallucination) na mga sagot; Magdagdag ng layer ng pag-verify ng sagot sa mga kritikal na lugar.
tatlong mini case
Case 1 — Leak key. Direktang na-embed ng isang startup ang OpenAI key sa React Native app nito para mabilis na makalabas. Tatlong linggo pagkatapos mailabas ang app, ang susi ay na-reverse engineered at $2,400 ang halaga ng paggamit ay ginawa sa magdamag. Kinailangan ng team na bawiin ang susi at mag-set up ng backend proxy. Aralin: ang shortcut na kinuha para sa kaginhawahan ay naging pinakamahal na ruta.
Kaso 2 — Bumaba ang dropout sa daloy. Isang education app ang unang naglabas ng Q&A feature nito nang walang streaming; ang mga user ay lumalabas pagkatapos ng 6 na segundo ng idle na paghihintay. Nang idinagdag ang daloy, nagsimulang lumabas ang unang salita sa loob ng 0.8 segundo, at bumaba ang rate ng pag-abandona mula 48% hanggang 12%. Parehong modelo, parehong bilis — pagkakaiba lang sa presentasyon.
Kaso 3 — Kontrol sa gastos. Isang app ang nagpapadala ng buong kasaysayan ng chat sa modelo kasama ang bawat mensahe ng user; Sa mahabang pag-uusap, umabot sa 8,000 token ang isang kahilingan, na nagpapataas ng halaga. Sa pamamagitan lamang ng pagpapadala ng huling ilang mensahe at isang buod, binawasan ng team ang mga token bawat kahilingan ng 70%, na binabawasan ang buwanang singil sa isang ikatlo. Aralin: sukatin ang iyong ipinadala.
Mahinang prompt / Malakas na prompt
Mahinang prompt: "Magdagdag ng chat tulad ng ChatGPT sa aking app."
Napakahusay na prompt: "Magdagdag ng chat assistant sa aking iOS/Swift na application. Architecture: ang application ay nagpapadala ng kahilingan sa sarili kong backend, ang LLM API key ay WALA sa CLIENT, dumadaan ito sa proxy. - Ang tugon ay dumarating sa streaming, ipinapakita ang salita sa bawat salita - Ang 'Stop' na button ay nakakaabala sa produksyon - Pangasiwaan ang timeout, network error, 429 at 500 na mga sitwasyon sa huling pagpapadala ng mensahe sa chat + (cost control)Ipaliwanag muna ang architectural diagram, pagkatapos ay bigyan ang client at proxy code nang magkahiwalay."
Mga nakopyang template
Secure architecture template:"Idisenyo ang cloud LLM integration sa aking [platform] application. Panuntunan: API key lang sa backend. Client -> my proxy -> LLM. Sa proxy: authentication, per-user rate limit, request logging. Ilista ang mga responsibilidad ng client at proxy nang hiwalay, pagkatapos ay i-export ang code."
Streaming na template: "Magdagdag ng streaming na tugon sa chat screen na ito:- Magdagdag ng mga snippet sa bubble ng mensahe sa pagdating nila- Magpakita ng cursor/animation habang nagta-type- Ipakansela ang 'Stop' button sa stream- Panatilihin ang bahagyang text at magbabala kung may error habang nagtatapos ang stream[umiiral na code]"
Cost-latency template:"Bawasan ang gastos at latency sa LLM integration na ito:- Paano ko babawasan ang ipinadalang token (pagpapaikli ng kasaysayan, buod)?- Sa anong kaso sapat na ang mas maliit/mas murang modelo?- Magmungkahi ng timeout at muling subukan ang diskarte[code]"
Fault tolerance template: "Gawin itong LLM call resilient:- Separate behavior for no network, timeout, 429 (rate limit), 500 (server)- Non-technical, polite message to user- Verification note laban sa panganib ng hallucination sa mga kritikal na tugon[code]"
Mga karaniwang pagkakamali
- Pag-embed ng API key sa application. Ang pinakamahal at karaniwang bug sa seguridad; Ang susi ay tiyak na namamalagi sa likod na dulo.
- Hindi gumagamit ng daloy. Ang pag-iwan sa user na naghihintay ng mahahabang sagot ay magpapalayas sa user.
- Ipinapadala ang buong kasaysayan ng chat sa bawat kahilingan. Pinaparami nito ang halaga ng token at latency.
- Pag-bypass sa mga kundisyon ng error. Kung ang 429/500/timeout ay hindi natugunan ang application ay mag-crash o mag-freeze.
- Isinasaalang-alang ang sagot sa LLM bilang tama nang walang tanong. Ang guni-guni ay totoo; Magdagdag ng layer ng pag-verify sa kritikal na lugar.
- Pagpapadala ng data ng user sa hindi kinakailangang LLM. Itanong kung kinakailangan o dapat bang itago ang personal na data bago ito mapunta sa cloud.
Sa buod
Ang Cloud LLM ay nagdadala ng mahusay na mga kakayahan na hindi akma sa device sa mobile, ngunit nangangailangan ng seguridad at disiplina sa gastos. Golden rule: Ang API key ay hindi kailanman nasa client, dumadaan ito sa backend proxy. Ang daloy ay lubos na nagpapataas ng perceived na bilis at pagpapanatili; Sinusuportahan ng "stop" button. Ang halaga ay tinutukoy sa pamamagitan ng pagpapaikli ng token na ipinadala; Nakakamit ang katatagan sa pamamagitan ng maayos na paghawak sa lahat ng kaso ng error. Maaaring kabilang sa mga sagot sa LLM ang mga guni-guni; Sa mga kritikal na lugar, mahalaga ang pag-verify at sinusuri ang personal na data bago ito ipadala sa cloud.
Gawain ng aplikasyon
Humiling ng disenyo ng client + backend proxy mula sa AI gamit ang “Secure architecture template” para sa feature na “text summarization” o “chat”. I-verify na nasa backend lang ang API key sa nabuong disenyo. Pagkatapos ay kunin ang hindi bababa sa dalawang paraan upang bawasan ang token na ipinadala gamit ang "Cost-delay pattern" at isulat ang magalang na mensahe na ipapakita sa user para sa isang kundisyon ng error (hal. 429).
checklist
- [ ] Na-verify ko na ang API key ay nasa backend at hindi sa client
- [ ] Ginawa ko ang pag-stream ng tugon at nagdagdag ng 'pause' na button
- [ ] Pinangasiwaan ko ang timeout, network error, 429 at 500 na sitwasyon
- [ ] Binawasan ko ang isinumiteng token gamit ang nakaraang pagdadaglat/buod
- [ ] Isinaalang-alang ko ang pagpapatunay laban sa panganib ng mga guni-guni sa sagot sa LLM
- [ ] Sinuri ko ang pangangailangan/pagta-mask ng personal na data bago pumunta sa cloud