רווחים:
- יכולת להקים ארכיטקטורת LLM ענן מאובטחת שאינה שומרת את מפתח ה-API בלקוח אלא עוברת דרך פרוקסי אחורי
- יכולת לכתוב אינטגרציות חזקות שמגבירות את המהירות הנתפסת עם סטרימינג ולטפל בעדינות במצבים כמו פסקי זמן, שגיאות רשת ומגבלות מהירות
- יכולת להפחית את העלות על ידי קיצור האסימון שנשלח ולפקפק בנחיצות הנתונים האישיים לפני שהם עוברים לענן
AI במכשיר הוא חזק אך מוגבל. כאשר אתה רוצה להוסיף "עוזר צ'אט חכם" באמת, סיכום טקסט ארוך או ייצור יצירתי מורכב לאפליקציה, אתה צריך דגמים גדולים מכדי להתאים לטלפון. כאן נכנסת לתמונה AI בענן: האפליקציה שלכם מתחברת למודל שפה גדול (LLM) באמצעות API (ממשק תכנות יישומים – הממשק הסטנדרטי שבו שתי תוכנות שולחות ומקבלות נתונים זו לזו). ביחידה זו נלמד כיצד לשלב ענן LLM באפליקציה סלולרית בצורה בטוחה, מהירה ומודעת לעלות. הדגש הקריטי יהיה על אבטחה: אינטגרציה לא נכונה של LLM עלולה לדלוף את מפתח ה-API שלך ולהביא לחשבונות בשווי אלפי פאונד.
כלל הזהב של האדריכלות: שמור את המפתח על הלקוח
הטעות המסוכנת ביותר שניתן לעשות באינטגרציה של AI בענן היא הטמעת מפתח ה-API (הסיסמה הסודית שמאשרת את השימוש בשירות) ישירות בקוד האפליקציה לנייד. יישומים ניידים מורידים למכשיר של המשתמש וניתן לקרוא את הקוד על ידי הנדסה לאחור - ניתוח האפליקציה המקומפלת ורואה מה יש בתוכה. אם המפתח שלך נמצא בתוך האפליקציה, מישהו יכול לחלץ אותו ולבצע בקשות בלתי מוגבלות מחשבונך.
הארכיטקטורה הנכונה היא זו: האפליקציה לנייד שולחת בקשות לשרת הקצה שלך (שרת ה-proxy שאתה שולט בו); המפתח נמצא רק בשרת; השרת עובר לשירות LLM ומחזיר את התגובה לאפליקציה. תוכנת ביניים זו מספקת גם מכסת מהירות, מניעת שימוש לרעה ובקרת עלויות.
גישה
איפה המפתח
אבטחה
המפתח נמצא באפליקציה (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 (שגיאת שרת); לטפל בכל אחד מהם בעדינות, אל תרסק את האפליקציה. כמו כן, LLM לפעמים נותן תשובות חסרות משמעות או שגויות (הזיה); הוסף שכבת אימות של התשובה באזורים קריטיים.
שלושה מיני תיקים
מקרה 1 - מפתח דלף. סטארט-אפ הטמיע את מפתח OpenAI ישירות באפליקציית React Native שלו כדי לצאת מהר. שלושה שבועות לאחר יציאת האפליקציה, המפתח עבר הנדסה לאחור ושימוש בשווי 2,400 דולר נעשה בן לילה. הצוות היה צריך לבטל את המפתח ולהגדיר פרוקסי אחורי. לקח: קיצור הדרך שנלקח מטעמי נוחות הפך למסלול היקר ביותר.
מקרה 2 - נשירה ירדה עם הזרימה. אפליקציית חינוך פרסמה לראשונה את תכונת השאלות והתשובות שלה ללא סטרימינג; משתמשים יצאו לאחר 6 שניות של המתנה סרק. כאשר נוספה זרימה, המילה הראשונה החלה להופיע תוך 0.8 שניות, ושיעור הנטישה ירד מ-48% ל-12%. אותו דגם, אותה מהירות - רק הבדל במצגת.
מקרה 3 - בקרת עלויות. אפליקציה אחת שלחה את כל היסטוריית הצ'אט לדגם עם כל הודעת משתמש; בשיחות ארוכות הגיעה בקשה בודדת ל-8,000 אסימונים, מה שהעלה את העלות. על ידי שליחת ההודעות האחרונות בלבד וסיכום, הצוות הפחית אסימונים לכל בקשה ב-70%, והפחית את החשבון החודשי לשליש. שיעור: למדוד את מה שאתה שולח.
הנחיה חלשה / הנחיה חזקה
הנחיה חלשה: "הוסף צ'אט כמו ChatGPT לאפליקציה שלי."
הנחיה עוצמתית: "הוסף עוזר צ'אט לאפליקציית iOS/Swift שלי. ארכיטקטורה: האפליקציה שולחת בקשה לחלק האחורי שלי, מפתח ה-LLM API לא נמצא ב-CLIENT, הוא עובר דרך ה-proxy. - התגובה מגיעה בזרם, מוצגת מילה אחר מילה - כפתור 'עצור' מפריע להפקה - טיפול בפסק זמן, שגיאת רשת 50 מקצר את המצב האחרון, 4029 מקצר את המצב האחרון: 6 הודעות + סיכום (בקרת עלויות) הסבירו תחילה את הדיאגרמה הארכיטקטונית, ולאחר מכן תן את קוד הלקוח והפרוקסי בנפרד."
תבניות הניתנות להעתקה
תבנית ארכיטקטורה מאובטחת: "עיצוב ענן אינטגרציה של LLM ביישום [פלטפורמה] שלי. כלל: מפתח API רק ב-backend. לקוח -> ה-proxy שלי -> LLM. ב-proxy: אימות, מגבלת תעריף לכל משתמש, רישום בקשות. רשום את אחריות הלקוח וה-proxy בנפרד, ואז ייצא את הקוד."
תבנית סטרימינג: "הוסף תגובה זורמת למסך הצ'אט הזה:- הוסף קטעים לבועת ההודעה כשהם מגיעים- הצג סמן/אנימציה בזמן ההקלדה- בקש מהלחצן 'עצור' לבטל את הזרם- שמור טקסט חלקי והזהיר אם יש שגיאה בזמן שהזרם מסתיים [קוד קיים]"
תבנית עלות-השהייה: "הפחת את העלות וההשהיה באינטגרציה הזו של LLM:- כיצד אוכל להפחית את האסימון שנשלח (קיצור היסטורי, סיכום)?- באיזה מקרה מספיק מודל קטן/זול יותר?- הצע פסק זמן ונסה שוב אסטרטגיה[קוד]"
תבנית סובלנות תקלות: "הפוך את שיחת LLM זו לחוסן:- התנהגות נפרדת ללא רשת, זמן קצוב, 429 (מגבלת קצב), 500 (שרת)- הודעה לא טכנית, מנומסת למשתמש- הערת אימות נגד סיכון להזיה בתשובות קריטיות[קוד]"
טעויות נפוצות
- הטמעת מפתח ה-API באפליקציה. באג האבטחה היקר והנפוץ ביותר; המפתח בהחלט נמצא בקצה האחורי.
- לא משתמש בזרימה. השארת המשתמש בהמתנה לתשובות ארוכות תרחיק את המשתמש.
- שליחת כל היסטוריית הצ'אט עם כל בקשה. זה מכפיל את העלות האסימונית ואת ההשהיה.
- עקיפת תנאי שגיאה. אם 429/500/פסק זמן לא יטופל, האפליקציה תקרוס או תקפא.
- התייחסות לתשובת LLM כנכונה ללא שאלה. ההזיה אמיתית; הוסף שכבת אימות באזור קריטי.
- שליחת נתוני משתמש ל-LLM מיותר. שאל אם נדרשים נתונים אישיים או שיש להסוות אותם לפני שהם עוברים לענן.
לסיכום
Cloud LLM מביא יכולות מעולות שאינן מתאימות למכשיר למובייל, אך דורש אבטחה ומשמעת עלויות. כלל זהב: מפתח ה-API אף פעם לא נמצא בלקוח, הוא עובר דרך פרוקסי הקצה האחורי. זרימה מגבירה מאוד את המהירות הנתפסת ואת השמירה; נתמך על ידי כפתור "עצור". העלות נקבעת על ידי קיצור האסימון שנשלח; חוסן מושגת על ידי טיפול בכל מקרי השגיאה בחן. תשובות LLM עשויות לכלול הזיות; באזורים קריטיים, אימות חיוני והנתונים האישיים נבדקים לפני שליחתם לענן.
משימת יישום
בקש לקוח + עיצוב פרוקסי עורפי מה-AI באמצעות "תבנית ארכיטקטורה מאובטחת" עבור תכונת "סיכום טקסט" או "צ'אט". ודא שמפתח ה-API נמצא רק ב-backend בעיצוב שנוצר. לאחר מכן חלץ לפחות שתי דרכים להפחתת האסימון שנשלח עם "דפוס השהיית עלות" וכתוב את הודעת המנומס שתוצג למשתמש עבור מצב שגיאה (למשל 429).
רשימת בדיקה
- [ ] וידאתי שמפתח ה-API נמצא ב-backend ולא בלקוח
- [ ] הזרמתי את התגובה והוספתי כפתור 'השהיה'
- [ ] טיפלתי בפסק זמן, שגיאת רשת, מצבי 429 ו-500
- [ ] הקטנתי את האסימון שנשלח עם הקיצור/סיכום העבר
- [ ] שקלתי אימות נגד הסיכון להזיות בתשובת LLM
- [ ] בדקתי את הצורך/מסיכה של נתונים אישיים לפני שהלכתי לענן