નફો:
- સુરક્ષિત ક્લાઉડ એલએલએમ આર્કિટેક્ચર સ્થાપિત કરવાની ક્ષમતા જે ક્લાયંટ પર API કી રાખતી નથી પરંતુ બેક-એન્ડ પ્રોક્સીમાંથી પસાર થાય છે
- મજબૂત એકીકરણ લખવાની ક્ષમતા જે સ્ટ્રીમિંગ સાથે કથિત ગતિમાં વધારો કરે છે અને સમયસમાપ્તિ, નેટવર્ક ભૂલો અને ઝડપ મર્યાદા જેવી પરિસ્થિતિઓને નરમાશથી હેન્ડલ કરે છે
- મોકલેલા ટોકનને ટૂંકાવીને ખર્ચ ઘટાડવાની ક્ષમતા અને ક્લાઉડ પર જાય તે પહેલાં વ્યક્તિગત ડેટાની આવશ્યકતા પર પ્રશ્ન
ઓન-ડિવાઈસ AI શક્તિશાળી છે પરંતુ મર્યાદિત છે. જ્યારે તમે સાચા અર્થમાં "સ્માર્ટ ચેટ સહાયક", લાંબા ટેક્સ્ટ સારાંશ અથવા એપ્લિકેશનમાં જટિલ રચનાત્મક ઉત્પાદન ઉમેરવા માંગતા હો, ત્યારે તમારે એવા મોડલની જરૂર છે જે ફોન પર ફિટ થવા માટે ખૂબ મોટા હોય. આ તે છે જ્યાં ક્લાઉડ AI કાર્યમાં આવે છે: તમારી એપ્લિકેશન એક API (એપ્લિકેશન પ્રોગ્રામિંગ ઈન્ટરફેસ – પ્રમાણભૂત ઈન્ટરફેસ જ્યાં બે સોફ્ટવેર એકબીજાને ડેટા મોકલે છે અને પ્રાપ્ત કરે છે) દ્વારા મોટા ભાષાના મોડેલ (LLM) સાથે જોડાય છે. આ એકમમાં આપણે શીખીશું કે ક્લાઉડ LLM ને કેવી રીતે સુરક્ષિત, ઝડપી અને ખર્ચ-સભાન રીતે મોબાઇલ એપ્લિકેશનમાં એકીકૃત કરવું. નિર્ણાયક ભાર સુરક્ષા પર રહેશે: ખોટી રીતે ઇન્સ્ટોલ કરેલ LLM એકીકરણ તમારી API કી લીક કરી શકે છે અને પરિણામે હજારો પાઉન્ડના બિલ આવી શકે છે.
આર્કિટેક્ચરનો સુવર્ણ નિયમ: ક્લાયંટ પર ચાવી રાખો
સૌથી ખતરનાક ભૂલ જે ક્લાઉડ AI એકીકરણમાં થઈ શકે છે તે એપીઆઈ કી (ગુપ્ત પાસવર્ડ કે જે સેવાનો ઉપયોગ કરીને અધિકૃત કરે છે) સીધા મોબાઈલ એપ્લિકેશન કોડમાં એમ્બેડ કરવાની છે. મોબાઇલ એપ્લિકેશનો વપરાશકર્તાના ઉપકરણ પર ડાઉનલોડ થાય છે અને કોડ રિવર્સ એન્જિનિયરિંગ દ્વારા વાંચી શકાય છે — સંકલિત એપ્લિકેશનને પાર્સ કરીને અને તેની અંદર શું છે તે જોઈને. જો તમારી કી એપની અંદર છે, તો કોઈ તેને એક્સટ્રેક્ટ કરી શકે છે અને તમારા એકાઉન્ટમાંથી અમર્યાદિત વિનંતીઓ કરી શકે છે.
સાચું આર્કિટેક્ચર આ છે: મોબાઇલ એપ્લિકેશન તમારા પોતાના બેકએન્ડ સર્વરને વિનંતીઓ મોકલે છે (તમે નિયંત્રિત કરો છો તે પ્રોક્સી સર્વર); કી ફક્ત સર્વર પર જ રહે છે; સર્વર એલએલએમ સેવા પર જાય છે અને એપ્લિકેશનનો પ્રતિસાદ પરત કરે છે. આ મિડલવેર સ્પીડ કેપિંગ, દુરુપયોગ નિવારણ અને ખર્ચ નિયંત્રણ પણ પ્રદાન કરે છે.
અભિગમ
ચાવી ક્યાં છે
સુરક્ષા
કી એપ્લિકેશનમાં છે (FALSE)
ક્લાયન્ટમાં, જાહેરમાં
તે લીક થાય છે, બિલ ફૂટે છે
કી બેકએન્ડમાં છે (TRUE)
સર્વર પર, છુપાયેલ
સલામત, નિયંત્રણક્ષમ
સાવધાન: જ્યારે તમે AI ને ક્લાઉડ LLM એકીકરણ માટે પૂછો છો, ત્યારે તે એક ઉદાહરણ ઉત્પન્ન કરી શકે છે જે તમારી સુવિધા માટે એપ્લિકેશન કોડમાં સીધી કી લખે છે. આને ક્યારેય લાઈવ ન લો. પ્રોમ્પ્ટમાં "API કી ક્લાયંટ પર ન હોવી જોઈએ, બેકએન્ડ પ્રોક્સી દ્વારા જાઓ" વાક્ય શામેલ કરવાની ખાતરી કરો.
સ્ટ્રીમિંગ: કથિત ગતિ વધારવી
LLM જવાબો લાંબા હોઈ શકે છે અને તેમને સંપૂર્ણ રીતે ઉત્પન્ન કરવામાં સેકન્ડ લાગી શકે છે. વપરાશકર્તાને ખાલી સ્ક્રીન પર રાહ જોવી એ ખરાબ અનુભવ છે. ઉકેલ સ્ટ્રીમિંગ છે - શબ્દ દ્વારા જવાબ શબ્દ પ્રદર્શિત કરવો, કારણ કે તે જનરેટ થાય છે. વપરાશકર્તા ટેક્સ્ટની જોડણીનું નિરીક્ષણ કરે છે, જેમ કે ChatGPT; આ નાટકીય રીતે કથિત ગતિ અને પ્રવાહમાં વધારો કરે છે. મોબાઈલ પર ફ્લો એટલે સર્વરથી ઈન્ટરફેસમાં આવતાની સાથે ટુકડાઓ (ટોકન્સ — મોડેલ દ્વારા ઉત્પાદિત ટેક્સ્ટનો ટુકડો) ઉમેરવાનો. AI માં એકીકરણ પ્રિન્ટ કરતી વખતે સ્પષ્ટપણે પ્રવાહની વિનંતી કરો.
ટીપ: સ્ટ્રીમિંગ પ્રતિસાદમાં "થોભો" બટન ઉમેરો. જ્યારે તેને જોઈતો જવાબ મળે ત્યારે વપરાશકર્તા ઉત્પાદન બંધ કરી શકે છે; આ બંને અનુભવને સુધારે છે અને બિનજરૂરી ટોકન જનરેશનને કાપીને ખર્ચ ઘટાડે છે. લાંબા જવાબની મધ્યમાં, વપરાશકર્તાને તેમનો જવાબ પહેલેથી જ મળી ગયો હશે.
ખર્ચ, વિલંબ અને ભૂલ વ્યવસ્થાપન
Cloud LLM દરેક વિનંતી સાથે નાણાં ખર્ચ (ટોકન દીઠ ફી) અને સમય ખર્ચ (લેટન્સી) વહન કરે છે. ત્રણ શિસ્ત આવશ્યક છે. Cost: limit prompt and response length, do not send unnecessarily long system instructions, default to small and cheap model if possible. લેટન્સી: સ્ટ્રીમિંગનો ઉપયોગ કરો, સમયસમાપ્તિ સેટ કરો, જો નેટવર્ક ધીમું હોય તો વપરાશકર્તાને સૂચિત કરો. ભૂલ: નેટવર્ક આઉટેજ, સેવા 429 (ઘણી બધી વિનંતીઓ) અથવા 500 (સર્વર ભૂલ) પરત કરી શકે છે; દરેકને નરમાશથી હેન્ડલ કરો, એપ્લિકેશનને ક્રેશ કરશો નહીં. ઉપરાંત, એલએલએમ કેટલીકવાર અર્થહીન અથવા ખોટા (આભાસ) જવાબો આપે છે; જટિલ વિસ્તારોમાં જવાબની ચકાસણીનો એક સ્તર ઉમેરો.
ત્રણ નાના કેસો
કેસ 1 - લીક કી. એક સ્ટાર્ટઅપે ઝડપથી બહાર આવવા માટે OpenAI કીને સીધી તેની રીએક્ટ નેટિવ એપમાં એમ્બેડ કરી. એપ રીલીઝ થયાના ત્રણ અઠવાડિયા પછી, કીને રિવર્સ એન્જીનિયર કરવામાં આવી હતી અને રાતોરાત $2,400 મૂલ્યનો ઉપયોગ કરવામાં આવ્યો હતો. ટીમે કીને રદ કરવી પડી અને બેકએન્ડ પ્રોક્સી સેટ કરવી પડી. પાઠ: સુવિધા માટે લેવાયેલ શોર્ટકટ સૌથી મોંઘો માર્ગ બની ગયો.
કેસ 2 — પ્રવાહ સાથે ડ્રોપઆઉટ ઘટ્યું. એક એજ્યુકેશન એપ્લિકેશને સૌપ્રથમ સ્ટ્રીમિંગ વિના તેની Q&A સુવિધા રજૂ કરી; વપરાશકર્તાઓ 6 સેકન્ડની નિષ્ક્રિય રાહ જોયા પછી બહાર નીકળી રહ્યા હતા. જ્યારે પ્રવાહ ઉમેરવામાં આવ્યો, ત્યારે પ્રથમ શબ્દ 0.8 સેકન્ડમાં દેખાવા લાગ્યો, અને ત્યાગનો દર 48% થી ઘટીને 12% થયો. સમાન મોડલ, સમાન ગતિ — માત્ર પ્રસ્તુતિમાં તફાવત.
કેસ 3 - ખર્ચ નિયંત્રણ. એક એપ્લિકેશન દરેક વપરાશકર્તા સંદેશ સાથે મોડેલને સમગ્ર ચેટ ઇતિહાસ મોકલી રહી હતી; લાંબી વાતચીતમાં, એક જ વિનંતિ 8,000 ટોકન્સ સુધી પહોંચી, જે ખર્ચમાં વધારો કરે છે. માત્ર છેલ્લા થોડા સંદેશાઓ અને સારાંશ મોકલીને, ટીમે વિનંતી દીઠ ટોકન્સમાં 70% ઘટાડો કર્યો, માસિક બિલને ત્રીજા ભાગ સુધી ઘટાડ્યું. પાઠ: તમે જે મોકલો છો તેનું માપ કાઢો.
નબળા પ્રોમ્પ્ટ / મજબૂત પ્રોમ્પ્ટ
નબળા સંકેત: "મારી એપ્લિકેશનમાં ChatGPT જેવી ચેટ ઉમેરો."
શક્તિશાળી પ્રોમ્પ્ટ: "મારી iOS/Swift એપ્લિકેશનમાં ચેટ સહાયક ઉમેરો. આર્કિટેક્ચર: એપ્લિકેશન મારા પોતાના બેકએન્ડ પર વિનંતી મોકલે છે, LLM API કી ક્લાયંટ પર નથી, તે પ્રોક્સીમાંથી પસાર થાય છે. - પ્રતિસાદ સ્ટ્રીમિંગ આવે છે, શબ્દ દ્વારા શબ્દ પ્રદર્શિત થાય છે - 'સ્ટોપ' બટન પ્રોડક્શનમાં વિક્ષેપ પાડે છે - હેન્ડલ ટાઇમઆઉટ, નેટવર્ક 50, 200 અને 2000ની પરિસ્થિતિમાં ભૂલ થાય છે. ચેટ ઇતિહાસ ટૂંકો કરો: છેલ્લા 6 સંદેશાઓ મોકલો + સારાંશ (ખર્ચ નિયંત્રણ) પહેલા આર્કિટેક્ચરલ ડાયાગ્રામ સમજાવો, પછી ક્લાયંટ અને પ્રોક્સી કોડ અલગથી આપો."
નકલ કરી શકાય તેવા નમૂનાઓ
સુરક્ષિત આર્કિટેક્ચર ટેમ્પલેટ: "મારી [પ્લેટફોર્મ] એપ્લિકેશનમાં ક્લાઉડ LLM એકીકરણ ડિઝાઇન કરો. નિયમ: API કી ફક્ત બેકએન્ડમાં. ક્લાયંટ -> માય પ્રોક્સી -> LLM. પ્રોક્સીમાં: પ્રમાણીકરણ, પ્રતિ-વપરાશકર્તા દર મર્યાદા, વિનંતી લૉગિંગ. ક્લાયંટ અને પ્રોક્સી જવાબદારીઓને અલગથી સૂચિબદ્ધ કરો, પછી કોડની નિકાસ કરો."
સ્ટ્રીમિંગ ટેમ્પલેટ: "આ ચેટ સ્ક્રીન પર સ્ટ્રીમિંગ પ્રતિસાદ ઉમેરો:- મેસેજ બબલમાં સ્નિપેટ્સ આવતાં જ ઉમેરો- ટાઇપ કરતી વખતે કર્સર/એનિમેશન બતાવો- 'સ્ટોપ' બટન સ્ટ્રીમને રદ કરો- આંશિક ટેક્સ્ટ સાચવો અને જો સ્ટ્રીમ સમાપ્ત થઈ રહી હોય ત્યારે કોઈ ભૂલ હોય તો ચેતવણી આપો [હાલનો કોડ]"
કોસ્ટ-લેટન્સી ટેમ્પ્લેટ:"આ LLM એકીકરણમાં ખર્ચ અને લેટન્સી ઘટાડવી:- હું મોકલેલ ટોકન કેવી રીતે ઘટાડી શકું (ઇતિહાસ સંક્ષિપ્ત, સારાંશ)?- કયા કિસ્સામાં નાનું/સસ્તું મોડલ પૂરતું છે?- સમયસમાપ્તિ સૂચવો અને વ્યૂહરચના[કોડ] ફરીથી પ્રયાસ કરો"
ફોલ્ટ ટોલરન્સ ટેમ્પ્લેટ: "આ LLM કૉલને સ્થિતિસ્થાપક બનાવો:- કોઈ નેટવર્ક માટે અલગ વર્તન, સમયસમાપ્તિ, 429 (દર મર્યાદા), 500 (સર્વર)- બિન-તકનીકી, વપરાશકર્તાને નમ્ર સંદેશ- જટિલ જવાબોમાં આભાસના જોખમ સામે ચકાસણી નોંધ[કોડ]"
સામાન્ય ભૂલો
- એપ્લિકેશનમાં API કીને એમ્બેડ કરવું. સૌથી ખર્ચાળ અને સામાન્ય સુરક્ષા બગ; ચાવી ચોક્કસપણે પાછળના છેડે આવેલી છે.
- પ્રવાહનો ઉપયોગ કરતા નથી. લાંબા જવાબો માટે રાહ જોઈ રહેલા વપરાશકર્તાને છોડી દેવાથી વપરાશકર્તા દૂર થઈ જશે.
- દરેક વિનંતી સાથે સમગ્ર ચેટ ઇતિહાસ મોકલી રહ્યું છે. તે ટોકન ખર્ચ અને લેટન્સીને ગુણાકાર કરે છે.
- ભૂલ શરતો બાયપાસ. જો 429/500/સમય સમાપ્તિને સંબોધવામાં નહીં આવે તો એપ્લિકેશન ક્રેશ થઈ જશે અથવા સ્થિર થઈ જશે.
- LLM જવાબને પ્રશ્ન વિના સાચો ગણવો. આભાસ વાસ્તવિક છે; નિર્ણાયક વિસ્તારમાં ચકાસણી સ્તર ઉમેરો.
- બિનજરૂરી એલએલએમમાં વપરાશકર્તાનો ડેટા મોકલવો. પૂછો કે શું વ્યક્તિગત ડેટા આવશ્યક છે અથવા તે ક્લાઉડ પર જાય તે પહેલાં તેને માસ્ક કરવો જોઈએ.
સારાંશમાં
ક્લાઉડ એલએલએમ એ શ્રેષ્ઠ ક્ષમતાઓ લાવે છે જે મોબાઇલમાં ઉપકરણ પર ફિટ થતી નથી, પરંતુ સુરક્ષા અને ખર્ચ શિસ્તની જરૂર છે. સુવર્ણ નિયમ: API કી ક્યારેય ક્લાયંટ પર હોતી નથી, તે બેકએન્ડ પ્રોક્સીમાંથી પસાર થાય છે. પ્રવાહ મોટા પ્રમાણમાં કથિત ઝડપ અને રીટેન્શન વધે છે; "સ્ટોપ" બટન દ્વારા સપોર્ટેડ છે. મોકલેલા ટોકનને ટૂંકાવીને ખર્ચ નક્કી કરવામાં આવે છે; તમામ ભૂલના કેસોને ચિત્તાકર્ષક રીતે હેન્ડલ કરીને સ્થિતિસ્થાપકતા પ્રાપ્ત થાય છે. LLM જવાબોમાં આભાસનો સમાવેશ થઈ શકે છે; જટિલ વિસ્તારોમાં, ચકાસણી આવશ્યક છે અને વ્યક્તિગત ડેટાને ક્લાઉડ પર મોકલતા પહેલા તેની સમીક્ષા કરવામાં આવે છે.
એપ્લિકેશન કાર્ય
"ટેક્સ્ટ સારાંશ" અથવા "ચેટ" સુવિધા માટે "સિક્યોર આર્કિટેક્ચર ટેમ્પલેટ" નો ઉપયોગ કરીને AI થી ક્લાયંટ + બેકએન્ડ પ્રોક્સી ડિઝાઇનની વિનંતી કરો. ચકાસો કે API કી ફક્ત જનરેટ કરેલ ડિઝાઇનમાં બેકએન્ડમાં રહે છે. પછી "ખર્ચ-વિલંબ પેટર્ન" સાથે મોકલવામાં આવેલ ટોકન ઘટાડવાની ઓછામાં ઓછી બે રીતો કાઢો અને ભૂલની સ્થિતિ માટે વપરાશકર્તાને પ્રદર્શિત કરવા માટેનો નમ્ર સંદેશ લખો (દા.ત. 429).
ચેકલિસ્ટ
- [ ] મેં ચકાસ્યું છે કે API કી બેકએન્ડમાં રહે છે અને ક્લાયંટ પર નહીં
- [ ] મેં પ્રતિભાવ સ્ટ્રીમિંગ કર્યું અને 'થોભો' બટન ઉમેર્યું
- [ ] મેં સમય સમાપ્તિ, નેટવર્ક ભૂલ, 429 અને 500 પરિસ્થિતિઓને સંભાળી
- [ ] મેં ભૂતકાળના સંક્ષેપ/સારાંશ સાથે સબમિટ કરેલ ટોકન ઘટાડ્યું છે
- [ ] મેં LLM જવાબમાં આભાસના જોખમ સામે માન્યતા ધ્યાનમાં લીધી
- [ ] મેં ક્લાઉડ પર જતાં પહેલાં વ્યક્તિગત ડેટાની આવશ્યકતા/માસ્કિંગ તપાસી