לפני שמשתמשים ב-AI כדי ליצור תוכן, צריך לבחור את הפלטפורמה שבה הוא מתארח. הבחירה שלכם משפיעה על המהירות, העלות, יכולת ההתאמה והאמינות של מערכת ה-AI. תוכל לבחור בין האפשרויות:
- AI בצד הלקוח: פועל ישירות בדפדפן. כלומר, הנתונים נשארים פרטיים במכשיר של המשתמש, ואין השהיה ברשת. עם זאת, כדי שה-AI מצד הלקוח יפעל בצורה טובה, צריך תרחישי שימוש מוגדרים היטב וספציפיים מאוד.
- AI בצד השרת: פועל בענן. הוא יעיל וניתן להרחבה, אבל יקר יותר מבחינת זמן האחזור והעלות.
לכל אפשרות יש יתרונות וחסרונות, וההגדרה הנכונה תלויה בתרחיש השימוש, בכישורים של הצוות ובמשאבים שלכם. לדוגמה, אתם יכולים להציע כלי לסיכום שפועל באופן מקומי, כדי שהמשתמשים יוכלו לשאול שאלות אישיות בלי לנהל פרטים אישיים מזהים (PII). עם זאת, נציג תמיכת לקוחות יכול לתת תשובות שימושיות יותר באמצעות מודל מבוסס-ענן שיש לו גישה למאגר גדול של משאבים.
במודול הזה תלמדו איך:
- השוואה בין היתרונות והחסרונות של AI בצד הלקוח ובצד השרת.
- התאימו את הפלטפורמה לתרחיש השימוש וליכולות של הצוות.
- עיצוב מערכות היברידיות שמציעות AI בלקוח ובשרת, כדי לצמוח עם המוצר.
בדיקת האפשרויות
כשמדובר בפריסה, אפשר לחלק את פלטפורמות ה-AI לשני צירים עיקריים. האפשרויות הזמינות:
- איפה המודל פועל: בצד הלקוח או בצד השרת?
- יכולת התאמה אישית: מה מידת השליטה שלכם בידע וביכולות של המודל? אם יש לכם שליטה במודל, כלומר אתם יכולים לשנות את משקלי המודל, אתם יכולים להתאים אישית את ההתנהגות שלו כדי לעמוד בדרישות הספציפיות שלכם.
AI בצד הלקוח
ה-AI בצד הלקוח פועל בדפדפן, והחישוב מתבצע באופן מקומי במכשיר של המשתמש. אתם לא צריכים לספק מחשוב בזמן ההסקה, והנתונים נשארים במחשב של המשתמש. כך אפשר לספק חוויות אינטראקטיביות קלות משקל במהירות ובאופן פרטי.
עם זאת, מודלים בצד הלקוח הם בדרך כלל קטנים למדי, מה שיכול להגביל את היכולות והביצועים שלהם. הם מתאימים במיוחד למשימות מאוד ספציפיות, כמו זיהוי רעילות או ניתוח סנטימנט. בדרך כלל מדובר במשימות של AI גנרטיבי עם מרחב פלט מוגבל.
יש שתי אפשרויות עיקריות:
- AI מובנה: דפדפנים כמו Google Chrome ו-Microsoft Edge משלבים מודלים של AI. אפשר לגשת אליהם באמצעות קריאות ל-JavaScript, בלי צורך בהגדרה או באירוח. אחרי שמורידים את המודל, כל האתרים שמשתמשים בו יכולים לקרוא לו.
- מודלים בהתאמה אישית: אתם יכולים להשתמש בספריות בצד הלקוח, כמו Transformers.js ו-MediaPipe, כדי לשלב מודלים באפליקציה שלכם. כלומר, אתם יכולים לשלוט במשקלים של המודל. עם זאת, המשמעות היא שכל משתמש באתר שלכם צריך להוריד את המודל המותאם אישית. גם המודלים הכי קטנים של AI הם גדולים בהקשר של אתר.
AI בצד השרת
ב-AI בצד השרת, אפליקציית האינטרנט שלכם קוראת ל-API כדי לשלוח קלט למודל ה-AI ולקבל את הפלט שלו. ההגדרה הזו תומכת במודלים גדולים ומורכבים יותר, והיא לא תלויה בחומרה של המשתמש.
שתי הקטגוריות של AI בצד השרת הן:
- שירותים מנוהלים: אלה מודלים שמתארחים במרכזי נתונים של צד שלישי, כמו Gemini 3 ו-GPT-5. בעלי המודל מספקים API כדי לגשת אליו. המשמעות היא שאתם יכולים להשתמש במודלים מתקדמים עם הגדרה מינימלית. הם אידיאליים ליצירת אב טיפוס מהיר, לשיחה פתוחה ולנימוק למטרות כלליות. עם זאת, הרחבת שירות מנוהל עלולה להיות יקרה.
- מודלים באירוח עצמי: אתם יכולים לפרוס מודלים עם משקלים פתוחים, כמו Gemma או Llama, בתשתית שלכם או במאגר מנוהל, כמו Vertex AI או Hugging Face Inference. הגישה הזו מאפשרת לכם ליהנות מהאימון המקדים שהמודל עבר על ידי היוצר שלו, אבל אתם שומרים על שליטה במודל, בנתוני הכוונון העדין ובביצועים.
בחירת פלטפורמה ראשונית
כדאי לעיין במאפיינים הארכיטקטוניים של פלטפורמות ה-AI ולנתח את היתרונות והחסרונות כדי להחליט על ההגדרה הראשונית.
הגדרת הדרישות הארכיטקטוניות
בכל החלטה, צריך להתפשר. כדאי לעיין במאפיינים העיקריים שמגדירים את העלות והערך של פלטפורמת ה-AI:
- העוצמה של המודל: עד כמה המודל פועל בצורה טובה בקרב מגוון רחב של משתמשים ומשימות, בלי כוונון. לרוב, יש קורלציה בין זה לבין גודל המודל.
- התאמה אישית: המידה שבה אפשר לכוונן, לשנות או לשלוט בהתנהגות ובארכיטקטורה של המודל.
- דיוק: האיכות והמהימנות הכוללות של התחזיות או התוצאות של המודל.
- פרטיות: המידה שבה נתוני המשתמשים נשארים מקומיים ובשליטת המשתמשים.
- עלות קבועה: ההוצאה החוזרת שנדרשת להפעלת מערכת ה-AI, ללא קשר לשימוש, כולל הקצאה ותחזוקה של התשתית.
- עלות לכל בקשה: העלות הנוספת של כל בקשה נכנסת.
- תאימות: עד כמה הגישה פועלת בדפדפנים, במכשירים ובסביבות שונות בלי לוגיקת חזרה.
- נוחות המשתמשים: האם המשתמשים צריכים לבצע פעולות נוספות כדי להשתמש במערכת ה-AI, כמו הורדת מודל.
- נוחות למפתחים: כמה מהר וקל למרבית המפתחים לפרוס, לשלב ולתחזק את המודל, בלי ידע מיוחד ב-AI.
בטבלה הבאה מופיעה דוגמה להערכות של רמת הביצועים של כל פלטפורמה בכל קריטריון, כאשר 1 הוא הנמוך ביותר ו-5 הוא הגבוה ביותר.
| קריטריונים | לקוח | שרת | ||
| AI מובנה או AI במכשיר | מודל בהתאמה אישית | שירות מנוהל | מודל באירוח עצמי | |
| Model power |
למה המודל קיבל 2 כוכבים על עוצמת המודל?ה-AI המובנה וה-AI במכשיר משתמשים במודלים קטנים של דפדפן שנטענו מראש ועברו אופטימיזציה לתכונות ספציפיות למשימות, ולא לשיחה או להסקת מסקנות. |
למה קיבלתי 3 כוכבים על עוצמת המודל?ספריות מותאמות אישית מצד הלקוח מציעות גמישות רבה יותר מ-AI מובנה, אבל עדיין יש מגבלות על גודל ההורדה, על הזיכרון ועל החומרה של המשתמש. |
למה 4 כוכבים לחוזק המודל?עם שירותים מנוהלים ואירוח עצמי, יש לכם גישה למודלים גדולים ומתקדמים, שיכולים לבצע חשיבה מורכבת, לטפל בהקשרים ארוכים ולבצע מגוון רחב של משימות. |
|
| התאמה אישית |
למה קיבלתם כוכב אחד על יכולת ההתאמה האישית?מודלים מוטמעים לא מאפשרים גישה למשקלים של המודל או לנתוני האימון. הדרך העיקרית להתאים אישית את ההתנהגות שלהם היא באמצעות הנדסת פרומפטים |
למה 5 כוכבים על יכולת התאמה אישית?האפשרות הזו מאפשרת לכם לשלוט בבחירת המודל ובמשקלים שלו. ספריות רבות בצד הלקוח מאפשרות גם כוונון עדין ואימון של מודלים. |
למה קיבלתם כוכב אחד על יכולת ההתאמה האישית?שירותים מנוהלים חושפים מודלים עוצמתיים, אבל מציעים שליטה מינימלית בהתנהגות הפנימית שלהם. ההתאמה האישית מוגבלת בדרך כלל להנחיות ולהקשר של הקלט. |
למה 5 כוכבים על יכולת ההתאמה האישית?מודלים באירוח עצמי מאפשרים שליטה מלאה במשקלים של המודל, בנתוני האימון, בשינויים המדויקים ובפריסת ההגדרות. |
| דיוק |
למה קיבלת 2 כוכבים על דיוק?הדיוק במודלים המובנים מספיק למשימות מוגדרות היטב, אבל גודל המודל המוגבל וההכללה מפחיתים את המהימנות של תשומות מורכבות או מדויקות. |
למה רמת הדיוק היא 3 כוכבים?אפשר לשפר את הדיוק של מודל בהתאמה אישית מצד הלקוח בתהליך בחירת המודל. עם זאת, היא עדיין מוגבלת על ידי גודל המודל, הכמותיות והשונות בחומרת הלקוח. |
למה 5 כוכבים לדיוק?בדרך כלל, שירותים מנוהלים מציעים רמת דיוק גבוהה יחסית, כי הם נהנים ממודלים גדולים, מנתוני אימון נרחבים ומשיפורים מתמשכים של הספק. |
למה דירוג הדיוק הוא 4 כוכבים?רמת הדיוק יכולה להיות גבוהה, אבל היא תלויה במודל שנבחר ובמאמץ ההתאמה. יכול להיות שיהיה עיכוב בביצועים של שירותים מנוהלים. |
| זמן האחזור של הרשת |
למה 5 כוכבים לזמן האחזור של הרשת?העיבוד מתבצע ישירות במכשיר של המשתמש. |
למה זמן האחזור של הרשת מקבל 2 כוכבים?מתבצעת שליחה הלוך ושוב לשרת. |
||
| פרטיות |
למה 5 כוכבים לפרטיות?כברירת מחדל, נתוני המשתמשים צריכים להישאר במכשיר, כדי לצמצם את החשיפה של הנתונים ולפשט את התאימות לפרטיות. |
למה קיבלתם 2 כוכבים על פרטיות?נתוני הקלט של המשתמשים צריכים להישלח לשרתים חיצוניים, מה שמגדיל את החשיפה של הנתונים ואת דרישות התאימות. עם זאת, יש פתרונות ספציפיים לצמצום בעיות שקשורות לפרטיות, כמו Private AI Compute. |
למה קיבלת 3 כוכבים על פרטיות?הנתונים נשארים בשליטת הארגון, אבל הם עדיין יוצאים מהמכשיר של המשתמש ונדרשים אמצעי טיפול מאובטחים ותאימות. |
|
| עלות קבועה |
למה 5 כוכבים לעלות קבועה?המודלים פועלים במכשירים הקיימים של המשתמשים, כך שאין עלויות נוספות של תשתית. |
למה 5 כוכבים לעלות קבועה?ברוב ממשקי ה-API החיוב מבוסס על שימוש, כך שאין עלות קבועה. |
למה קיבלתי 2 כוכבים על עלות קבועה?העלויות הקבועות כוללות תשתיות, תחזוקה ותקורה תפעולית. |
|
| עלות לכל בקשה |
למה 5 כוכבים לעלות לכל בקשה?אין עלות לכל בקשה, כי ההסקה פועלת במכשיר של המשתמש. |
למה קיבלתי 2 כוכבים על עלות לכל בקשה?בדרך כלל, שירותים מנוהלים מתומחרים לפי בקשה. עלויות ההרחבה יכולות להיות משמעותיות, במיוחד בנפחי תנועה גבוהים. |
למה 3 כוכבים לעלות לכל בקשה?אין עלות ישירה לכל בקשה, אבל העלות האפקטיבית לכל בקשה תלויה בניצול התשתית. |
|
| תאימות |
למה קיבלתי 2 כוכבים על תאימות?הזמינות משתנה בהתאם לדפדפן ולמכשיר, ולכן צריך להשתמש בחלופות בסביבות שלא נתמכות. |
למה קיבלתי כוכב אחד על תאימות?התאימות תלויה ביכולות החומרה ובזמן הריצה, ולכן היא מוגבלת למכשירים מסוימים. |
למה 5 כוכבים לתאימות?פלטפורמות בצד השרת תואמות לכל המשתמשים, כי ההסקות מתבצעות בצד השרת והלקוחות צורכים רק API. |
|
| נוחות המשתמש |
למה 3 כוכבים לנוחות המשתמש?בדרך כלל השימוש ב-AI מובנה הוא חלק, אבל נדרש להוריד מודל ראשוני ולוודא שיש תמיכה בדפדפן. |
למה 2 כוכבים על נוחות השימוש?יכול להיות שיהיו עיכובים למשתמשים בגלל הורדות או חומרה לא נתמכת. |
למה 4 כוכבים לנוחות המשתמש?הוא פועל באופן מיידי בלי להצריך הורדות או דרישות מכשיר, ומספק חוויית משתמש חלקה. עם זאת, יכול להיות שיהיה עיכוב אם החיבור לרשת חלש. |
|
| נוחות למפתחים |
למה 5 כוכבים לנוחות המפתחים?ה-AI המובנה לא דורש הגדרה מורכבת, תשתית או מומחיות ב-AI, ולכן קל לשלב אותו ולתחזק אותו. |
למה נתת 2 כוכבים לנוחות המפתחים?נדרש ניהול של מודלים, זמני ריצה, אופטימיזציה של הביצועים ותאימות בין מכשירים. |
למה 4 כוכבים לנוחות המפתחים?שירותים מנוהלים מפשטים את הפריסה וההתאמה לעומס. עם זאת, עדיין נדרש שילוב של API, ניהול עלויות והנדסת הנחיות. |
למה נתת 1 כוכב לנוחות המפתחים?פריסה מותאמת אישית בצד השרת דורשת מומחיות משמעותית בתשתית, בניהול מודלים, במעקב ובאופטימיזציה. |
| מאמצי תחזוקה |
למה נתת 4 כוכבים למאמצי התחזוקה?הדפדפנים מטפלים בעדכונים ובאופטימיזציה של המודלים, אבל המפתחים צריכים להתאים את עצמם לשינויים בזמינות. |
למה נתת 2 כוכבים למאמץ התחזוקה?נדרשים עדכונים שוטפים למודלים, לכוונון הביצועים ולתאימות, ככל שהדפדפנים והמכשירים מתפתחים. |
למה נתת 5 כוכבים למאמץ התחזוקה?הספק מטפל בתחזוקה. |
למה נתת 2 כוכבים למאמץ התחזוקה?נדרשת תחזוקה רציפה, כולל עדכוני מודלים, ניהול תשתית, שינוי גודל ואבטחה. |
ניתוח היתרונות והחסרונות
כדי להמחיש את תהליך קבלת ההחלטות, נוסיף עוד תכונה ל-Example Shoppe, פלטפורמת מסחר אלקטרוני בגודל בינוני. אתם רוצים לחסוך בעלויות של שירות לקוחות בשעות לא פעילות, ולכן אתם מחליטים ליצור עוזר דיגיטלי מבוסס-AI שיענה על שאלות של משתמשים לגבי הזמנות, החזרות ומוצרים.
אפשר לעיין בתוכנית המלאה של מערכת ה-AI, שכוללת את ההזדמנות והפתרון.
לנתח את התרחיש באמצעות שתי נקודות מבט: דרישות התרחיש לדוגמה ומגבלות עסקיות או מגבלות של הצוות.
| דרישה | ניתוח | קריטריונים | השלכה |
| רמת דיוק גבוהה וגמישות | משתמשים שואלים מגוון שאלות מורכבות לגבי הזמנות, מוצרים והחזרות. | העוצמה והדיוק של המודל | נדרש מודל שפה גדול (LLM). |
| ספציפיות הנתונים | התשובות צריכות להתייחס לשאלות ספציפיות לגבי נתוני החברה, המוצרים והמדיניות. | אפשרויות התאמה אישית | נדרשת הטמעה של נתונים, כמו RAG, אבל לא כוונון עדין של המודל. |
| דרישה | ניתוח | קריטריונים | השלכה |
| בסיס משתמשים | מאות אלפי משתמשים. | מדרגיות, תאימות | נדרשת ארכיטקטורה שמטפלת בתנועה גבוהה ואמינה. |
| התמקדות אחרי ההשקה | הצוות יעבור לפרויקטים אחרים אחרי ההשקה של גרסה 1. | מאמץ התחזוקה | צריך פתרון עם תחזוקה שוטפת מינימלית. |
| מומחיות הצוות | מפתחי אתרים מנוסים, מומחיות מוגבלת ב-AI/ML | נוחות למפתחים | הפתרון צריך להיות קל לפריסה ולשילוב בלי כישורים מיוחדים בתחום ה-AI. |
אחרי שקבעתם את סדר העדיפויות של הקריטריונים, תוכלו לעיין בטבלה להערכת פשרות כדי להבין איזו פלטפורמה מתאימה לקריטריונים שהגדרתם כחשובים ביותר:
| קריטריונים בעדיפות | הזוכה בפלטפורמה |
| הספק הדגם | צד השרת |
| אפשרויות התאמה אישית | בצד השרת: מודל באירוח עצמי |
| נוחות למפתחים | בצד השרת: שירות מנוהל |
| מאמץ התחזוקה | בצד השרת: שירות מנוהל |
| תאימות ומדרגיות | צד השרת |
מהפירוט הזה ברור שכדאי להשתמש ב-AI בצד השרת, וכנראה בשירות מנוהל. התכונה הזו מציעה מודל רב-תכליתי לשאלות מורכבות של לקוחות. הוא מצמצם את המאמץ שנדרש לתחזוקה ולפיתוח, כי הוא מעביר לספק את האחריות על התשתית, איכות המודל וזמן הפעולה.
אמנם האפשרויות להתאמה אישית מוגבלות, אבל זה שווה את זה לצוות פיתוח אתרים עם ניסיון מוגבל בהנדסת מודלים.
הגדרה של RAG (שליפה משופרת של דורות) יכולה לעזור לכם לספק למודל את ההקשר הרלוונטי בזמן ההסקה.
Hybrid AI
מערכות AI מתקדמות פועלות לעיתים רחוקות בפלטפורמה אחת או עם מודל אחד. במקום זאת, הם מפזרים את עומסי העבודה של ה-AI כדי לבצע אופטימיזציה של הפשרות.
זיהוי הזדמנויות לשימוש ב-AI היברידי
אחרי ההשקה, כדאי לשפר את הדרישות על סמך נתונים ומשוב מהשטח. בדוגמה שלנו, Example Shoppe, אתם מחכים כמה חודשים כדי לנתח את התוצאות ולגלות את הדברים הבאים:
- כ-80% מהבקשות חוזרות על עצמן ("איפה ההזמנה שלי?", "How do I return this?" (איך מחזירים את זה?). שליחת הבקשות האלה לשירות מנוהל יוצרת הרבה תקורה ועלויות.
- רק 20% מהבקשות דורשות נימוק מעמיק ושיחה אינטראקטיבית פתוחה.
מודל מקומי קל משקל יכול לסווג קלט של משתמשים ולענות על שאילתות שגרתיות, כמו "מהי מדיניות החזרת המוצרים שלך?" אפשר להפנות שאלות מורכבות, נדירות או דו-משמעיות למודל בצד השרת.
הטמעה של AI בצד השרת ובצד הלקוח מאפשרת לכם להפחית את העלויות ואת זמן האחזור, ועדיין לשמור על גישה ליכולות ניתוח חזקות כשצריך.
חלוקת עומס העבודה
כדי לבנות את המערכת ההיברידית הזו עבור Example Shoppe, צריך להתחיל בהגדרת מערכת ברירת המחדל. במקרה כזה, עדיף להתחיל בצד הלקוח. האפליקציה צריכה לבצע ניתוב ל-AI בצד השרת בשני מקרים:
- גיבוי על סמך תאימות: אם המכשיר או הדפדפן של המשתמש לא יכולים לטפל בבקשה, הם צריכים לחזור לשרת
- העברה לטיפול ברמה גבוהה יותר על סמך יכולות: אם הבקשה מורכבת מדי או לא מוגדרת מספיק עבור המודל בצד הלקוח, בהתאם לקריטריונים שנקבעו מראש, היא תועבר לטיפול במודל גדול יותר בצד השרת. אפשר להשתמש במודל כדי לסווג את הבקשה כבקשה נפוצה, ואז לבצע את המשימה בצד הלקוח, או כבקשה לא נפוצה, ואז לשלוח את הבקשה למערכת בצד השרת. לדוגמה, אם המודל בצד הלקוח קובע שהשאלה קשורה לבעיה לא נפוצה, כמו קבלת החזר כספי במטבע אחר.
גמישות מובילה למורכבות גדולה יותר
חלוקת עומסי העבודה בין שתי פלטפורמות מעניקה גמישות רבה יותר, אבל גם מוסיפה מורכבות:
- תזמור: שתי סביבות הפעלה משמעותן יותר חלקים נעים. צריך לוגיקה לניתוב, לניסיונות חוזרים ולגיבויים.
- ניהול גרסאות: אם משתמשים באותו מודל בכמה פלטפורמות, הוא צריך להיות תואם לשני הסביבות.
- הנדסת הנחיות והנדסת הקשר: אם אתם משתמשים במודלים שונים בכל פלטפורמה, אתם צריכים לבצע הנדסת הנחיות לכל אחת מהן.
- מעקב: היומנים והמדדים מפוצלים ונדרש מאמץ נוסף לאיחוד שלהם.
- אבטחה: אתם מנהלים שני שטחי תקיפה. צריך להקשיח את נקודות הקצה המקומיות ואת נקודות הקצה בענן.
זוהי עוד נקודת איזון שכדאי לקחת בחשבון. אם יש לכם צוות קטן או שאתם בונים תכונה לא חיונית, יכול להיות שלא תרצו להוסיף את המורכבות הזו.
התובנות שלכם
הבחירה שלכם בפלטפורמה עשויה להשתנות. מתחילים מתרחיש השימוש, מתאימים אותו לניסיון ולמשאבים של הצוות, ומשפרים אותו ככל שהמוצר והשימוש ב-AI מתפתחים. המשימה שלכם היא למצוא את השילוב הנכון בין מהירות, פרטיות ושליטה עבור המשתמשים, ואז לבנות את המערכת עם מידה מסוימת של גמישות. כך תוכלו להתאים את עצמכם לדרישות משתנות וליהנות מעדכונים עתידיים של הפלטפורמה והמודל.
משאבים
- בחירת הפלטפורמה והמודל תלויה זו בזו, ולכן מומלץ לקרוא מידע נוסף על בחירת מודל.
- איך משתמשים ב-AI היברידי וב-AI מצד הלקוח כדי להרחיב את השימוש ב-AI מעבר לענן
בדיקת ההבנה
מהם שני השיקולים העיקריים כשבוחרים פלטפורמת AI לאפליקציה?
מתי שירות שמנוהל בצד השרת, כמו Gemini Pro, הוא הבחירה הכי טובה לפלטפורמה שלכם?
מה היתרון העיקרי של הטמעה של מערכת AI היברידית?