ה-AI הגנרטיבי מציע דרך חדשה לבנות ולהפעיל אפליקציות AI, שונה מ-AI לחיזוי. כדי לבנות אפליקציית AI גנרטיבי, צריך לבחור מתוך מגוון רחב של ארכיטקטורות וגדלים, לאצור נתונים, ליצור הנחיות אופטימליות, לכוונן מודלים למשימות ספציפיות ולבסס את התפוקות של המודל על נתונים מהעולם האמיתי.
במסמך הזה מוסבר איך להתאים תהליכי DevOps ו-MLOps כדי לפתח, לפרוס ולהפעיל אפליקציות של AI גנרטיבי במודלים קיימים של AI בסיסי. למידע על פריסת AI לחיזוי, אפשר לעיין במאמר MLOps: פייפליינים של אספקה רציפה ואוטומציה בלמידת מכונה.
מה זה DevOps ו-MLOps?
DevOps היא מתודולוגיה של הנדסת תוכנה שמקשרת בין פיתוח ותפעול. DevOps מעודד שיתוף פעולה, אוטומציה ושיפור מתמיד כדי לייעל את מחזור החיים של פיתוח התוכנה, באמצעות שיטות עבודה כמו אינטגרציה רציפה ופיתוח רציף (CI/CD).
MLOps מבוסס על עקרונות DevOps כדי לתת מענה לאתגרים של בנייה ותפעול של מערכות למידת מכונה (ML). מערכות למידת מכונה בדרך כלל משתמשות ב-AI חיזוי כדי לזהות דפוסים ולבצע חיזויים. תהליך העבודה של MLOps כולל את השלבים הבאים:
- אימות נתונים
- אימון המודל
- הערכה ואיטרציה של מודלים
- פריסה והצגה של מודלים
- מעקב אחרי מודלים
מהם מודלים בסיסיים?
מודלים בסיסיים הם רכיב הליבה ביישום של AI גנרטיבי. המודלים האלה הם תוכניות גדולות שמשתמשות במערכי נתונים כדי ללמוד ולקבל החלטות ללא התערבות אנושית. מודלים בסיסיים עוברים אימון על סוגים רבים של נתונים, כולל טקסט, תמונות, אודיו ווידאו. מודלים בסיסיים כוללים מודלים גדולים של שפה (LLM) כמו Llama 3.1 ומודלים מולטי-מודאליים כמו Gemini.
בניגוד למודלים של AI לחיזוי, שעוברים אימון למשימות ספציפיות על מערכי נתונים ממוקדים, מודלים בסיסיים עוברים אימון על מערכי נתונים עצומים ומגוונים. ההדרכה הזו מאפשרת לכם להשתמש במודלים בסיסיים כדי לפתח אפליקציות למגוון רחב של תרחישי שימוש. למודלים בסיסיים יש מאפיינים מתפתחים (PDF), שמאפשרים להם לספק תשובות לקלט ספציפי בלי אימון מפורש. בגלל התכונות המתפתחות האלה, קשה ליצור מודלים בסיסיים ולהפעיל אותם, וצריך להתאים את תהליכי ה-DevOps וה-MLOps.
פיתוח מודל בסיסי דורש משאבי נתונים משמעותיים, חומרה ייעודית, השקעה משמעותית ומומחיות ייעודית. לכן, עסקים רבים מעדיפים להשתמש במודלים קיימים כדי לפשט את הפיתוח והפריסה של אפליקציות ה-AI הגנרטיבי שלהם.
מחזור החיים של אפליקציה מבוססת-AI גנרטיבי
מחזור החיים של אפליקציה מבוססת-AI גנרטיבי כולל את השלבים הבאים:
- גילוי: מפתחים ומהנדסי AI מזהים את מודל הבסיס שהכי מתאים לתרחיש השימוש שלהם. הם בוחנים את היתרונות, החסרונות והעלויות של כל מודל כדי לקבל החלטה מושכלת.
- פיתוח וניסויים: מפתחים משתמשים בהנדסת הנחיות כדי ליצור הנחיות קלט ולשפר אותן כדי לקבל את הפלט הנדרש. כשזמין, few-shot learning, fine-tuning (PEFT) יעיל בפרמטרים ושרשור מודלים עוזרים להנחות את התנהגות המודל. שרשור מודלים מתייחס לתיאום של קריאות למספר מודלים ברצף ספציפי כדי ליצור תהליך עבודה.
- פריסה: מפתחים צריכים לנהל הרבה ארטיפקטים בתהליך הפריסה, כולל תבניות של הנחיות, הגדרות של שרשרות, מודלים מוטמעים, מאגרי נתונים לאחזור ומתאמי מודלים שעברו כוונון עדין. לארטיפקטים האלה יש דרישות ניהול משלהם, וצריך לנהל אותם בקפידה לאורך תהליך הפיתוח והפריסה. בנוסף, כשפורסים אפליקציות AI גנרטיביות, צריך להתחשב ביכולות הטכניות של תשתית היעד ולוודא שהדרישות של החומרה של האפליקציה מתקיימות.
- מעקב מתמשך בסביבת הייצור: אדמינים משפרים את הביצועים של האפליקציה ושומרים על תקני בטיחות באמצעות אתיקה של בינה מלאכותית, כמו הבטחת הוגנות, שקיפות ואחריות בתוצאות של המודל.
- שיפור מתמשך: מפתחים משנים כל הזמן את מודלי הבסיס באמצעות טכניקות הנחיה, החלפת המודלים בגרסאות חדשות יותר או אפילו שילוב של כמה מודלים כדי לשפר את הביצועים, את היעילות בעלויות או את זמן האחזור. אימון רציף רגיל עדיין רלוונטי לתרחישים שבהם נדרש כוונון עדין חוזר או שילוב של לולאות משוב אנושי.
לשיטות הנדסת נתונים יש תפקיד חשוב בכל שלבי הפיתוח. כדי ליצור תוצאות מהימנות, צריך להשתמש בנתונים עובדתיים (כדי לוודא שהתוצאות של המודל מבוססות על מידע מדויק ועדכני) ובנתונים עדכניים ממערכות פנימיות וממערכות ארגוניות. כוונון הנתונים עוזר להתאים את המודלים למשימות ולסגנונות ספציפיים, ולתקן שגיאות חוזרות.
איך מוצאים את מודל הבסיס לתרחיש לדוגמה
יצירת מודלים בסיסיים דורשת הרבה משאבים, ולכן רוב העסקים מעדיפים להשתמש במודל בסיסי קיים שמתאים לתרחיש השימוש שלהם. קשה למצוא את מודל הבסיס הנכון כי יש הרבה מודלים כאלה. לכל מודל יש ארכיטקטורות, גדלים, מערכי נתונים לאימון ורישיונות שונים. בנוסף, לכל תרחיש שימוש יש דרישות ייחודיות, ולכן צריך לנתח את המודלים הזמינים לפי כמה פרמטרים.
כשמעריכים מודלים, כדאי להביא בחשבון את הגורמים הבאים:
- איכות: מריצים הנחיות בדיקה כדי לאמוד את איכות הפלט.
- זמן אחזור וקצב העברת נתונים: צריך לקבוע את זמן האחזור ואת קצב העברת הנתונים שנדרשים לתרחיש השימוש, כי הגורמים האלה משפיעים ישירות על חוויית המשתמש. לדוגמה, צ'אטבוט דורש חביון נמוך יותר ממשימות סיכום שעוברות עיבוד באצווה.
- זמן פיתוח ותחזוקה: צריך לקחת בחשבון את ההשקעה בזמן לפיתוח הראשוני ולתחזוקה השוטפת. בדרך כלל, מודלים מנוהלים דורשים פחות מאמץ ממודלים שזמינים באופן פתוח ומוטמעים באופן עצמאי.
- עלות השימוש: צריך לקחת בחשבון את עלויות התשתית והצריכה שמשויכות למודל.
- תאימות: הערכת היכולת של המודל לעמוד בתקנות הרלוונטיות ובתנאי הרישוי.
פיתוח וניסוי
כשמפתחים אפליקציות של AI גנרטיבי, תהליך הפיתוח והניסוי הוא איטרטיבי ומתוזמן. כל איטרציה ניסיונית כוללת שיפור של הנתונים, התאמה של מודל הבסיס והערכה של התוצאות. ההערכה מספקת משוב שמנחה את האיטרציות הבאות בלולאת משוב רציפה. אם הביצועים לא עומדים בציפיות, אפשר לאסוף עוד נתונים, להגדיל את הנתונים או לשפר את הנתונים. בנוסף, יכול להיות שתצטרכו לבצע אופטימיזציה של ההנחיות, להשתמש בטכניקות של כוונון עדין או לעבור למודל בסיס אחר. מחזור השיפור האיטרטיבי הזה, שמבוסס על תובנות מההערכה, חשוב לא פחות לאופטימיזציה של אפליקציות של AI גנרטיבי מאשר לאופטימיזציה של אפליקציות של למידת מכונה ו-AI חיזוי.
הפרדיגמה של מודל הבסיס
מודלים בסיסיים שונים ממודלים לחיזוי כי הם מודלים רב-תכליתיים. במקום לאמן מודלים למטרה אחת על נתונים שספציפיים למשימה הזו, מאמנים מודלים בסיסיים על מערכי נתונים רחבים, וכך אפשר להשתמש במודל בסיסי במגוון רחב של תרחישי שימוש.
מודלים בסיסיים רגישים מאוד לשינויים בקלט שלהם. הפלט של המודל והמשימה שהוא מבצע נקבעים לפי הקלט של המודל. מודל בסיסי יכול לתרגם טקסט, ליצור סרטונים או לסווג נתונים פשוט על ידי שינוי הקלט. גם שינויים קלים בקלט יכולים להשפיע על היכולת של המודל לבצע את המשימה בצורה נכונה.
המאפיינים האלה של מודלים בסיסיים מחייבים שיטות פיתוח ותפעול שונות. למרות שמודלים בהקשר של AI לחיזוי הם עצמאיים וממוקדים במשימה ספציפית, מודלים בסיסיים הם רב-תכליתיים וצריכים אלמנט נוסף מעבר לקלט של המשתמש. מודלים של AI גנרטיבי דורשים הנחיה, ובאופן ספציפי יותר, תבנית הנחיה. תבנית של הנחיה היא קבוצה של הוראות ודוגמאות, יחד עם placeholders שנועדו להכיל קלט של משתמשים. האפליקציה יכולה לשלב את תבנית ההנחיה עם הנתונים הדינמיים (כמו קלט של משתמשים) כדי ליצור הנחיה מלאה, שהיא הטקסט שמועבר כקלט למודל הבסיסי.
רכיב המודל עם ההנחיה
הנוכחות של ההנחיה היא מאפיין ייחודי של אפליקציות מבוססות-AI גנרטיבי. המודל וההנחיה לא מספיקים ליצירת תוכן, ונדרשים שניהם כדי להפעיל AI גנרטיבי. השילוב של המודל וההנחיה נקרא רכיב מודל מונחה. רכיב המודל המונחה הוא הרכיב העצמאי הקטן ביותר שמספיק ליצירת אפליקציית AI גנרטיבי. ההנחיה לא צריכה להיות מסובכת. לדוגמה, היא יכולה להיות הוראה פשוטה, כמו 'תרגם את המשפט הבא מאנגלית לצרפתית', ואחריה המשפט שרוצים לתרגם. עם זאת, בלי ההוראה המקדימה הזו, מודל בסיסי לא יבצע את משימת התרגום הנדרשת. לכן, נדרשת הנחיה, אפילו רק הוראה בסיסית, בנוסף לקלט, כדי שהמודל הבסיסי יבצע את המשימה שנדרשת על ידי האפליקציה.
רכיב המודל עם ההנחיות יוצר הבחנה חשובה בשיטות העבודה של MLOps בפיתוח אפליקציות AI גנרטיבי. בפיתוח של אפליקציית AI גנרטיבי, צריך לבצע ניסויים ואיטרציות בהקשר של רכיב מודל שמונחה על ידי הנחיה. מחזור הניסויים ב-AI גנרטיבי מתחיל בדרך כלל בבדיקת וריאציות של ההנחיה – שינוי הניסוח של ההוראות, הוספת הקשר או הכללת דוגמאות רלוונטיות – והערכת ההשפעה של השינויים האלה. השיטה הזו נקראת בדרך כלל הנדסת הנחיות.
הנדסת הנחיות כוללת את השלבים האיטרטיביים הבאים:
- הנחיה: יצירה ושיפור של הנחיות כדי להפיק התנהגויות רצויות ממודל בסיסי לתרחיש שימוש ספציפי.
- הערכה: הערכת התפוקות של המודל, באופן אידיאלי באמצעות תוכנה, כדי לאמוד את ההבנה שלו ואת מידת ההצלחה שלו בביצוע ההוראות בהנחיה.
כדי לעקוב אחרי תוצאות ההערכה, אפשר לרשום את התוצאות של ניסוי. ההנחיה עצמה היא רכיב מרכזי בתהליך הנדסת ההנחיות, ולכן היא הופכת לארטיפקט החשוב ביותר מבין הארטיפקטים שמשתתפים בניסוי.
עם זאת, כדי להתנסות באפליקציית AI גנרטיבי, צריך לזהות את סוגי הארטיפקטים. ב-AI חיזוי, הנתונים, צינורות הנתונים והקוד שונים. אבל עם פרדיגמת ההנחיות ב-AI גנרטיבי, ההנחיות יכולות לכלול הקשר, הוראות, דוגמאות, אמצעי הגנה ונתונים פנימיים או חיצוניים בפועל שנמשכים ממקום אחר.
כדי לקבוע את סוג הארטיפקט, צריך להבין שלהנחיה יש רכיבים שונים ונדרשות אסטרטגיות ניהול שונות. כמה נקודות שכדאי לחשוב עליהן:
- הנחיה כנתונים: חלקים מסוימים בהנחיה מתפקדים כמו נתונים. רכיבים כמו דוגמאות עם הקשר מועט, מאגרי ידע ושאילתות של משתמשים הם בעצם נקודות נתונים. הרכיבים האלה דורשים שיטות MLOps שמתמקדות בנתונים, כמו אימות נתונים, זיהוי סחף וניהול מחזור חיים.
- הנחיה כקוד: רכיבים אחרים כמו הקשר, תבניות להנחיות ומגבלות דומים לקוד. הרכיבים האלה מגדירים את המבנה והכללים של ההנחיה עצמה, ונדרשות שיטות עבודה שמתמקדות יותר בקוד, כמו תהליכי אישור, ניהול גרסאות של קוד ובדיקות.
לכן, כשמיישמים שיטות עבודה מומלצות של MLOps על בינה מלאכותית גנרטיבית, צריך להגדיר תהליכים שמאפשרים למפתחים לאחסן, לאחזר, לעקוב ולשנות הנחיות בקלות. התהליכים האלה מאפשרים איטרציה מהירה וניסויים מבוססים. לעתים קרובות, גרסה מסוימת של הנחיה יכולה לפעול היטב עם גרסה ספציפית של המודל, אבל לא לפעול טוב עם גרסה אחרת. כשעוקבים אחרי התוצאות של ניסוי, צריך לתעד את ההנחיה, את הגרסאות של הרכיבים, את גרסת המודל, את המדדים ואת נתוני הפלט.
שרשור מודלים והגדלה
מודלים של AI גנרטיבי, במיוחד מודלים גדולים של שפה (LLM), מתמודדים עם אתגרים מובנים בשמירה על עדכניות ובמניעת הזיות. קידוד מידע חדש ב-LLM דורש אימון מקדים יקר ואינטנסיבי מבחינת נתונים לפני שאפשר לפרוס אותם. בהתאם לתרחיש השימוש, יכול להיות שלא יספיק להשתמש רק במודל אחד עם הנחיה כדי לבצע יצירה מסוימת. כדי לפתור את הבעיה, אפשר לחבר כמה מודלים עם הנחיות, יחד עם קריאות לממשקי API חיצוניים ולוגיקה שמוצגת כקוד. רצף של רכיבי מודל שמונחים יחד בדרך הזו נקרא בדרך כלל שרשרת.
הדיאגרמה הבאה מציגה את הרכיבים של רשת ואת תהליך הפיתוח היחסי.
הפחתת ההשפעה של הטיה בגלל עדכניות והמצאות
שתי תבניות נפוצות שמבוססות על שרשרת ויכולות לצמצם את הבעיות של הטיה למידע עדכני והזיות הן יצירה עם שליפה משופרת (RAG) (PDF) וסוכנים.
- RAG משפר מודלים שעברו אימון מוקדם באמצעות ידע שאוחזר ממסדי נתונים, וכך לא צריך לבצע אימון מוקדם. RAG מאפשר להצמיד את התשובה למקורות ולצמצם את ההזיות על ידי שילוב של מידע עובדתי עדכני ישירות בתהליך היצירה.
- סוכנים, שהשימוש בהם נפוץ בזכות טכניקת ה-prompting של ReAct (PDF), משתמשים במודלים גדולים של שפה (LLM) כמתווכים שמתקשרים עם כלים שונים, כולל מערכות RAG, ממשקי API פנימיים או חיצוניים, תוספים בהתאמה אישית או אפילו סוכנים אחרים. סוכנים מאפשרים לבצע שאילתות מורכבות ופעולות בזמן אמת על ידי בחירה דינמית של מקורות מידע רלוונטיים ושימוש בהם. המודל הגדול של השפה (LLM), שפועל כסוכן, מפרש את השאילתה של המשתמש, מחליט באיזה כלי להשתמש ומנסח את התשובה על סמך המידע שאוחזר.
אתם יכולים להשתמש ב-RAG ובסוכנים כדי ליצור מערכות מרובות סוכנים שמחוברות לרשתות מידע גדולות, וכך לטפל בשאילתות מורכבות ולקבל החלטות בזמן אמת.
התיאום בין מודלים, לוגיקה וממשקי API שונים הוא לא דבר חדש באפליקציות של AI גנרטיבי. לדוגמה, מנועי המלצות משלבים מודלים של סינון שיתופי, מודלים מבוססי-תוכן וכללים עסקיים כדי ליצור המלצות מותאמות אישית למוצרים עבור משתמשים. באופן דומה, בזיהוי תרמיות, מודלים של למידת מכונה משולבים עם מערכות מבוססות-כללים ומקורות נתונים חיצוניים כדי לזהות פעילויות חשודות.
מה שמייחד את השרשרות האלה של רכיבי AI גנרטיבי הוא שאי אפשר לאפיין מראש את ההתפלגות של תשומות הרכיבים, ולכן קשה יותר להעריך ולתחזק את הרכיבים בנפרד. האורקסטרציה גורמת לשינוי פרדיגמה באופן שבו מפתחים אפליקציות AI ל-AI גנרטיבי.
ב-AI חיזוי, אפשר לבצע איטרציות על המודלים והרכיבים הנפרדים בבידוד, ואז לשרשר אותם באפליקציית ה-AI. ב-AI גנרטיבי, מפתחים שרשרת במהלך השילוב, מבצעים ניסויים בשרשרת מקצה לקצה, וחוזרים על אסטרטגיות שרשור, הנחיות, מודלים בסיסיים וממשקי API אחרים בצורה מתואמת כדי להשיג מטרה ספציפית. בדרך כלל לא צריך הנדסת תכונות, איסוף נתונים או מחזורי אימון נוספים של המודל, אלא רק שינויים בניסוח של תבנית ההנחיה.
המעבר ל-MLOps ל-AI גנרטיבי, בניגוד ל-MLOps ל-AI חיזוי, מוביל להבדלים הבאים:
- הערכה: בגלל הקשר ההדוק בין השרשרות, צריך לבצע הערכה מקצה לקצה של השרשרות, ולא רק של כל רכיב, כדי להעריך את הביצועים הכוללים שלהן ואת איכות הפלט שלהן. מבחינת טכניקות ומדדים להערכה, הערכת שרשרות דומה להערכת מודלים עם הנחיות.
- ניהול גרסאות: אתם צריכים לנהל שרשרת כארטיפקט שלם. כדי לנתח את ההגדרות, לשחזר אותן ולהבין את ההשפעה של השינויים על הפלט, צריך לעקוב אחרי ההגדרות של השרשרת באמצעות היסטוריית הגרסאות שלה. היומנים צריכים לכלול את הקלט, הפלט, מצבי הביניים של השרשרת וכל הגדרה של השרשרת שהייתה בשימוש במהלך כל הרצה.
- ניטור רציף: כדי לזהות ירידה בביצועים, סחף נתונים או התנהגות לא צפויה בשרשרת, צריך להגדיר מערכות ניטור פרואקטיביות. מעקב רציף עוזר לזהות בעיות פוטנציאליות בשלב מוקדם כדי לשמור על איכות הפלט שנוצר.
- בדיקה עצמית: צריך לבדוק את זרימות הנתונים הפנימיות בשרשרת (כלומר, את הקלט והפלט של כל רכיב) וגם את הקלט והפלט של השרשרת כולה. על ידי מתן שקיפות לגבי הנתונים שזורמים בשרשרת והתוכן שנוצר, מפתחים יכולים לאתר את המקורות של שגיאות, הטיה או התנהגות לא רצויה.
בתרשים הבא מוצג איך שרשראות, רכיבי מודל עם הנחיות וכוונון מודל פועלים יחד באפליקציית AI גנרטיבי כדי לצמצם את ההטיה שנובעת מנתונים עדכניים ואת ההזיות. הנתונים נאספים, המודלים מכווננים ונוספות שרשראות כדי לשפר עוד יותר את התשובות. אחרי שהתוצאות נבדקות, המפתחים יכולים לרשום את הניסוי ולהמשיך לבצע שיפורים.
כוונון עדין
כשמפתחים תרחיש שימוש ב-AI גנרטיבי שכולל מודלים בסיסיים, יכול להיות שיהיה קשה להסתמך רק על הנדסת הנחיות ושרשור כדי לפתור את תרחיש השימוש, במיוחד במשימות מורכבות. כדי לשפר את הביצועים של המשימה, מפתחים צריכים לעיתים קרובות לבצע כוונון עדין של המודל ישירות. כוונון עדין מאפשר לשנות באופן פעיל את כל השכבות או קבוצת משנה של שכבות (כוונון עדין יעיל בפרמטרים) של המודל כדי לייעל את היכולת שלו לבצע משימה מסוימת. הדרכים הנפוצות ביותר לכוונון מודל הן:
- כוונון מפוקח (SFT): מאמנים את המודל בצורה מבוקרת, ומלמדים אותו לחזות את רצף הפלט הנכון עבור קלט נתון.
- למידה ממשוב אנושי (RLHF): מאמנים מודל תגמול כדי לחזות מה אנשים יעדיפו כתשובה. לאחר מכן, משתמשים במודל התגמול הזה כדי להכווין את מודל ה-LLM בכיוון הנכון במהלך תהליך הכוונון. התהליך הזה דומה למצב שבו פאנל של שופטים אנושיים מנחה את תהליך הלמידה של המודל.
בתרשים הבא אפשר לראות איך כוונון עוזר לשפר את המודל במהלך מחזור הניסויים.
ב-MLOps, כוונון עדין חולק את היכולות הבאות עם אימון מודלים:
- היכולת לעקוב אחרי פריטי המידע שנוצרו בתהליך הפיתוח (Artifact) שמהווים חלק ממשימת ההתאמה. לדוגמה, ארטיפקטים כוללים את נתוני הקלט או את הפרמטרים שמשמשים לכוונון המודל.
- היכולת למדוד את ההשפעה של הכוונון. היכולת הזו מאפשרת להעריך את המודל המכוונן למשימות הספציפיות שעליהן הוא אומן, ולהשוות את התוצאות עם מודלים מכווננים קודמים או מודלים קפואים לאותה משימה.
אימון והתאמה רציפים
ב-MLOps, אימון מתמשך הוא תהליך שבו מאמנים שוב ושוב מודלים של למידת מכונה בסביבת ייצור. אימון מתמשך עוזר לוודא שהמודל נשאר עדכני ופועל היטב ככל שדפוסי הנתונים בעולם האמיתי משתנים לאורך זמן. במודלים של AI גנרטיבי, לרוב יותר פרקטי לבצע התאמה מתמשכת של המודלים מאשר לאמן אותם מחדש, בגלל העלויות הגבוהות של הנתונים והחישובים.
הגישה לכוונון מתמשך תלויה בתרחיש השימוש ובמטרות הספציפיות שלכם. למשימות יחסית סטטיות כמו סיכום טקסט, יכול להיות שהדרישות לכוונון מתמשך יהיו נמוכות יותר. אבל ליישומים דינמיים כמו צ'אטבוטים שצריכים התאמה אנושית מתמדת, נדרש כוונון תכוף יותר באמצעות טכניקות כמו RLHF שמבוססות על משוב אנושי.
כדי לקבוע את האסטרטגיה הנכונה להתאמה מתמשכת, צריך להעריך את אופי תרחיש השימוש ואת האופן שבו נתוני הקלט משתנים לאורך זמן. העלות היא גם שיקול חשוב, כי תשתית המחשוב משפיעה מאוד על מהירות הכוונון ועל העלות שלו. מעבדים גרפיים (GPU) ויחידות לעיבוד טנסורים (TPU) הם חומרה שנדרשת לצורך כוונון עדין. מעבדי GPU, שמוכרים בזכות יכולת העיבוד המקבילי שלהם, יעילים מאוד בטיפול בעומסי עבודה שדורשים הרבה כוח מחשוב, ולרוב הם משמשים לאימון ולהרצה של מודלים מורכבים של למידת מכונה. לעומת זאת, מעבדי TPU תוכננו במיוחד על ידי Google כדי להאיץ משימות של למידת מכונה. יחידות TPU מצטיינות בטיפול בפעולות של מטריצות גדולות, שנפוצות ברשתות נוירונים של למידה עמוקה.
נוהלי טיפול בנתונים
בעבר, ההתנהגות של מודלים של למידת מכונה נקבעה רק על ידי נתוני האימון שלהם. זה עדיין נכון לגבי מודלים בסיסיים, אבל ההתנהגות של מודלים של אפליקציות AI גנרטיביות שמבוססות על מודלים בסיסיים נקבעת לפי האופן שבו המודל מותאם באמצעות סוגים שונים של נתוני קלט.
מודלים בסיסיים מאומנים על נתונים כמו:
- מערכי נתונים לאימון מוקדם (לדוגמה, C4, The Pile או נתונים קנייניים)
- קבוצות נתונים לשיפור ההוראות
- מערכי נתונים לשיפור הבטיחות
- נתוני העדפות של בני אדם
אפליקציות של AI גנרטיבי מותאמות לנתונים כמו:
- הנחיות
- נתונים מוגברים או מבוססים (לדוגמה, אתרים, מסמכים, קובצי PDF, מסדי נתונים או ממשקי API)
- נתונים ספציפיים למשימה עבור PEFT
- הערכות ספציפיות למשימות
- נתוני העדפות של בני אדם
ההבדל העיקרי בין שיטות העבודה עם נתונים בלמידת מכונה חיזויית לבין שיטות העבודה עם נתונים ב-AI גנרטיבי הוא בשלב הראשון של תהליך מחזור החיים. ב-ML חיזוי, משקיעים הרבה זמן בהנדסת נתונים, ואם אין את הנתונים הנכונים, אי אפשר לבנות אפליקציה. ב-AI גנרטיבי, מתחילים עם מודל בסיס, כמה הוראות ואולי כמה דוגמאות של קלט (כמו למידה בהקשר). אתם יכולים ליצור אב-טיפוס ולהשיק אפליקציה עם מעט מאוד נתונים.
עם זאת, קלות יצירת האב טיפוס מגיעה עם האתגר הנוסף של ניהול נתונים מגוונים. AI לחיזוי מסתמך על מערכי נתונים מוגדרים היטב. ב-AI גנרטיבי, אפליקציה אחת יכולה להשתמש בסוגים שונים של נתונים ממקורות נתונים שונים לחלוטין, וכולם פועלים יחד.
כדאי להביא בחשבון את סוגי הנתונים הבאים:
- הנחיות להתניה: הוראות שניתנות למודל הבסיסי כדי להנחות את הפלט שלו ולקבוע את הגבולות של מה שהוא יכול ליצור.
- דוגמאות עם מעט נתונים: דרך להראות למודל מה רוצים להשיג באמצעות זוגות של קלט ופלט. הדוגמאות האלה עוזרות למודל להבין את המשימות הספציפיות, ובמקרים רבים הן יכולות לשפר את הביצועים.
- נתוני ביסוס או הגדלה: הנתונים שמאפשרים למודל הבסיסי ליצור תשובות להקשר ספציפי ולשמור על עדכניות ורלוונטיות של התשובות בלי לאמן מחדש את כל המודל הבסיסי. הנתונים האלה יכולים להגיע מממשקי API חיצוניים (כמו חיפוש Google) או מממשקי API פנימיים וממקורות נתונים.
- מערכי נתונים ספציפיים למשימות: מערכי הנתונים שעוזרים לכוונן מודל בסיסי קיים למשימה מסוימת, וכך לשפר את הביצועים שלו בתחום הספציפי הזה.
- מערכי נתונים מלאים לאימון מוקדם: מערכי הנתונים העצומים שמשמשים לאימון ראשוני של מודלים בסיסיים. יכול להיות שמפתחי אפליקציות לא יוכלו לגשת אליהם או לטוקנייזרים, אבל המידע שמקודד במודל עצמו משפיע על הפלט והביצועים של האפליקציה.
מגוון סוגי הנתונים הזה מוסיף שכבת מורכבות מבחינת ארגון הנתונים, המעקב וניהול מחזור החיים. לדוגמה, אפליקציה מבוססת-RAG יכולה לשכתב שאילתות של משתמשים, לאסוף באופן דינמי דוגמאות רלוונטיות באמצעות אוסף של דוגמאות שנבחרו בקפידה, לשלוח שאילתה למאגר נתונים וקטורי ולשלב את המידע עם תבנית הנחיה. אפליקציה שמבוססת על RAG מחייבת ניהול של כמה סוגי נתונים, כולל שאילתות משתמשים, מסדי נתונים וקטוריים עם דוגמאות שנבחרו בקפידה ללמידה עם מעט דוגמאות ומידע על החברה, ותבניות של הנחיות.
כל סוג של נתונים צריך ארגון ותחזוקה קפדניים. לדוגמה, כדי להשתמש במסד נתונים וקטורי צריך לעבד את הנתונים להטמעות, לבצע אופטימיזציה של אסטרטגיות חלוקה למקטעים ולוודא שרק מידע רלוונטי זמין. תבנית של הנחיה צריכה להיות עם ניהול גרסאות ומעקב, וצריך לשכתב שאילתות של משתמשים. שיטות מומלצות של MLOps ו-DevOps יכולות לעזור במשימות האלה. ב-AI חיזוי, יוצרים צינורות נתונים לחילוץ, לשינוי ולטעינה. ב-AI גנרטיבי, יוצרים צינורות לניהול, לפיתוח, להתאמה ולשילוב של סוגים שונים של נתונים באופן שניתן לניהול גרסאות, למעקב ולשחזור.
כוונון עדין של מודלים בסיסיים יכול לשפר את הביצועים של אפליקציות AI גנרטיבי, אבל המודלים צריכים נתונים. אפשר להשיג את הנתונים האלה על ידי הפעלת האפליקציה ואיסוף נתונים מהעולם האמיתי, יצירת נתונים סינתטיים או שילוב של שתי האפשרויות. השימוש במודלים גדולים ליצירת נתונים סינתטיים הופך פופולרי יותר ויותר כי השיטה הזו מזרזת את תהליך הפריסה, אבל עדיין חשוב שאנשים יבדקו את התוצאות כדי לוודא את האיכות. הנה כמה דוגמאות לשימוש במודלים גדולים למטרות של הנדסת נתונים:
- יצירת נתונים סינתטיים: בתהליך הזה נוצרים נתונים מלאכותיים שדומים מאוד לנתונים מהעולם האמיתי מבחינת המאפיינים והתכונות הסטטיסטיות שלהם. מודלים גדולים ומתקדמים לרוב משלימים את המשימה הזו. נתונים סינתטיים משמשים כנתוני אימון נוספים ל-AI גנרטיבי, ומאפשרים לו ללמוד דפוסים ויחסים גם כשנתונים אמיתיים מהעולם האמיתי עם תוויות הם נדירים.
- תיקון נתונים סינתטיים: הטכניקה הזו מתמקדת בזיהוי שגיאות וחוסר עקביות במערכי נתונים מסומנים קיימים ותיקונן. ה-AI הגנרטיבי יכול להשתמש במודלים גדולים יותר כדי לסמן טעויות אפשריות בתוויות ולהציע תיקונים כדי לשפר את האיכות והמהימנות של נתוני האימון.
- הגדלת נתונים סינתטיים: הגישה הזו לא מסתפקת ביצירת נתונים חדשים. היא כוללת מניפולציה חכמה של נתונים קיימים כדי ליצור וריאציות מגוונות, תוך שמירה על תכונות וקשרים חיוניים. במהלך האימון, AI גנרטיבי יכול להיתקל במגוון רחב יותר של תרחישים מאשר AI חיזוי, מה שמוביל להכללה משופרת וליכולת ליצור פלטים ניואנסיים ורלוונטיים.
קשה להעריך בינה מלאכותית גנרטיבית, בניגוד ל-AI חיזוי. לדוגמה, יכול להיות שלא תדעו את חלוקת נתוני האימון של המודלים הבסיסיים. אתם צריכים ליצור מערך נתונים מותאם אישית להערכה שמשקף את כל תרחישי השימוש שלכם, כולל תרחישי שימוש חיוניים, ממוצעים וקיצוניים. בדומה לנתוני כוונון עדין, אפשר להשתמש במודלים חזקים של LLM כדי ליצור, לאצור ולהגדיל נתונים לבנייה של מערכי נתונים חזקים להערכה.
הערכה
תהליך ההערכה הוא פעילות מרכזית בפיתוח של אפליקציות מבוססות-AI גנרטיבי. ההערכה יכולה להתבצע ברמות שונות של אוטומציה: החל מהערכה שמבוססת לחלוטין על פעולות של בני אדם ועד להערכה אוטומטית לחלוטין שמבוססת על תהליך.
כשיוצרים אב טיפוס של פרויקט, ההערכה היא לרוב תהליך ידני. המפתחים בודקים את הפלט של המודל כדי לקבל תחושה איכותית לגבי הביצועים שלו. אבל ככל שהפרויקט מתקדם ומספר תרחישי הבדיקה גדל, הערכה ידנית הופכת לצוואר בקבוק.
לאוטומציה של תהליך הבדיקה יש שני יתרונות משמעותיים: היא מאפשרת לכם להתקדם מהר יותר ומשפרת את מהימנות הבדיקות. בנוסף, היא מבטלת את הסובייקטיביות האנושית, ועוזרת להבטיח שהתוצאות יהיו ניתנות לשחזור.
אבל לאוטומציה של הערכה של אפליקציות AI גנרטיביות יש אתגרים משלה. לדוגמה:
- הקלטים (ההנחיות) והפלטים יכולים להיות מורכבים מאוד. הנחיה אחת יכולה לכלול כמה הוראות ואילוצים שהמודל צריך לנהל. הפלט עצמו הוא לרוב רב-ממדי, כמו תמונה שנוצרה או בלוק טקסט. קשה למדוד את איכות התוצאות האלה באמצעות מדד פשוט. מדדים מוכרים מסוימים, כמו BLEU לתרגומים ו-ROUGE לסיכומים, לא תמיד מספיקים. לכן, אתם יכולים להשתמש בשיטות הערכה בהתאמה אישית או במודל בסיסי אחר כדי להעריך את המערכת שלכם. לדוגמה, אפשר להנחות מודל שפה גדול (כמו AutoSxS) לתת ציון לאיכות של טקסטים שנוצרו במגוון מאפיינים.
- הרבה מדדי הערכה של AI גנרטיבי הם סובייקטיביים. מה הופך פלט אחד לטוב יותר מפלט אחר? חשוב לוודא שההערכה האוטומטית תואמת לשיפוט אנושי, כי אתם רוצים שהמדדים שלכם יהיו מדד מהימן למה שאנשים יחשבו. כדי להבטיח השוואה בין ניסויים, צריך לקבוע את גישת ההערכה והמדדים בשלב מוקדם בתהליך הפיתוח.
- חוסר בנתוני אמת, במיוחד בשלבים הראשונים של הפרויקט. פתרון עקיף אחד הוא ליצור נתונים סינתטיים שישמשו כאמת בסיסית זמנית שאפשר לשפר עם הזמן באמצעות משוב אנושי.
- כדי להגן על אפליקציות של AI גנרטיבי מפני התקפות יריבות, חשוב לבצע הערכה מקיפה. גורמים זדוניים יכולים ליצור הנחיות כדי לנסות לחלץ מידע רגיש או לתמרן את התוצאות של המודל. ערכות ההערכה צריכות להתייחס באופן ספציפי לנקודות החולשה האלה, באמצעות טכניקות כמו fuzzing של הנחיות (הזנת וריאציות אקראיות של הנחיות למודל) ובדיקה של דליפת מידע.
כדי להעריך אפליקציות של בינה מלאכותית גנרטיבית, צריך להטמיע את הפעולות הבאות:
- אפשר להפוך את תהליך ההערכה לאוטומטי כדי להבטיח מהירות, יכולת הרחבה ושחזור. אפשר להתייחס לאוטומציה כאל תחליף לשיקול דעת אנושי.
- אפשר להתאים אישית את תהליך ההערכה לפי הצורך בתרחישי השימוש שלכם.
- כדי להבטיח השוואה, חשוב לייצב את גישת ההערכה, המדדים ונתוני האמת הבסיסיים מוקדם ככל האפשר בשלב הפיתוח.
- יצירת נתונים סינתטיים של בסיס מידע משותף כדי לפצות על היעדר נתונים אמיתיים של בסיס מידע משותף.
- כדאי לכלול תרחישי בדיקה של הנחיות מתנגדות כחלק ממערך ההערכה כדי לבדוק את המהימנות של המערכת עצמה מפני התקפות כאלה.
כלים לפריסה
אפליקציות של AI גנרטיבי ברמת ייצור הן מערכות מורכבות עם הרבה רכיבים שפועלים באינטראקציה. כדי לפרוס אפליקציה של AI גנרטיבי לייצור, צריך לנהל את הרכיבים האלה ולתאם ביניהם לבין השלבים הקודמים של פיתוח אפליקציות של AI גנרטיבי. לדוגמה, אפליקציה אחת יכולה להשתמש בכמה מודלים מסוג LLM לצד מסד נתונים, כשכולם מוזנים על ידי צינור נתונים דינמי. כל אחד מהרכיבים האלה יכול לדרוש תהליך פריסה משלו.
פריסת אפליקציות של בינה מלאכותית גנרטיבית דומה לפריסה של מערכות תוכנה מורכבות אחרות, כי צריך לפרוס רכיבי מערכת כמו מסדי נתונים ואפליקציות Python. מומלץ להשתמש בשיטות סטנדרטיות של הנדסת תוכנה, כמו בקרת גרסאות ו-CI/CD.
ניהול הגרסאות
ניסויים ב-AI גנרטיבי הם תהליך איטרטיבי שכולל מחזורים חוזרים של פיתוח, הערכה ושינוי. כדי להבטיח גישה מובנית וניתנת לניהול, צריך להטמיע ניהול גרסאות קפדני לכל הרכיבים שניתנים לשינוי. הרכיבים האלה כוללים:
- תבניות של הנחיות: אלא אם אתם משתמשים בפתרונות ספציפיים לניהול הנחיות, כדאי להשתמש בכלים לניהול גרסאות כדי לעקוב אחרי הגרסאות.
- הגדרות שרשרת: כדאי להשתמש בכלים לניהול גרסאות כדי לעקוב אחרי גרסאות של הקוד שמגדיר את השרשרת (כולל שילובים של API, קריאות למסד נתונים ופונקציות).
- מערכי נתונים חיצוניים: למערכי נתונים חיצוניים יש תפקיד חשוב במערכות RAG. כדי לעקוב אחרי השינויים האלה ואחרי הגרסאות של מערכי הנתונים האלה, אפשר להשתמש בפתרונות קיימים לניתוח נתונים כמו BigQuery, AlloyDB ל-PostgreSQL ו-Vertex AI Feature Store.
- מודלים של מתאמים: טכניקות כמו כוונון LoRA למודלים של מתאמים מתפתחות כל הזמן. כדי לנהל את הנכסים האלה בצורה יעילה, כדאי להשתמש בפתרונות מוכרים לאחסון נתונים (לדוגמה, Cloud Storage).
אינטגרציה רציפה (CI)
במסגרת של אינטגרציה רציפה, כל שינוי בקוד עובר בדיקה אוטומטית לפני המיזוג, כדי לזהות בעיות בשלב מוקדם. בדיקות יחידה ובדיקות שילוב חשובות לאיכות ולאמינות. בדיקות יחידה מתמקדות בחלקים נפרדים של הקוד, ואילו בדיקות שילוב מאמתות שרכיבים שונים פועלים יחד.
הטמעה של מערכת אינטגרציה רציפה עוזרת לבצע את הפעולות הבאות:
- מוודאים שהתוצאות אמינות ואיכותיות: בדיקות קפדניות מגבירות את הביטחון בביצועים ובעקביות של המערכת.
- זיהוי באגים בשלב מוקדם: זיהוי בעיות באמצעות בדיקות מונע מהן לגרום לבעיות גדולות יותר בהמשך. זיהוי באגים בשלב מוקדם הופך את המערכת לחזקה ועמידה יותר במקרים חריגים ובקלט לא צפוי.
- עלויות תחזוקה נמוכות יותר: תרחישי בדיקה מתועדים היטב מפשטים את פתרון הבעיות ומאפשרים לבצע שינויים בצורה חלקה יותר בעתיד, וכך מצמצמים את מאמצי התחזוקה הכוללים.
היתרונות האלה רלוונטיים לאפליקציות של AI גנרטיבי. כדאי להחיל שילוב רציף על כל הרכיבים של המערכת, כולל תבניות ההנחיות, השרשרת, לוגיקת השרשור, כל המודלים המוטמעים ומערכות האחזור.
עם זאת, ליישום של אינטגרציה רציפה ב-AI גנרטיבי יש את האתגרים הבאים:
- קשה ליצור תרחישי בדיקה מקיפים: הפלט של AI גנרטיבי הוא מורכב ופתוח, ולכן קשה להגדיר וליצור קבוצה מקיפה של תרחישי בדיקה שמכסים את כל האפשרויות.
- בעיות בשחזור: קשה להשיג תוצאות דטרמיניסטיות שניתנות לשחזור, כי למודלים גנרטיביים יש לעיתים קרובות אקראיות ומשתנות מובנות בתוצאות שלהם, גם עבור קלטים זהים. האקראיות הזו מקשה על בדיקה עקבית של התנהגויות צפויות.
האתגרים האלה קשורים קשר הדוק לשאלה הרחבה יותר של הערכת אפליקציות של AI גנרטיבי. אפשר להחיל רבות מטכניקות ההערכה על פיתוח של מערכות CI ל-AI גנרטיבי.
פיתוח רציף (continuous delivery)
אחרי מיזוג הקוד, מתחיל תהליך של העברה רציפה כדי להעביר את הקוד שנבנה ונבדק דרך סביבות שדומות מאוד לסביבת הייצור, לצורך בדיקות נוספות לפני הפריסה הסופית.
כפי שמתואר במאמר פיתוח וניסוי, רכיבי שרשרת הופכים לאחד מהרכיבים העיקריים לפריסה, כי הם מהווים את הבסיס לאפליקציית ה-AI הגנרטיבי. תהליך המסירה של אפליקציית ה-AI הגנרטיבי שמכילה את השרשרת עשוי להשתנות בהתאם לדרישות ההשהיה ולתרחיש לדוגמה (עיבוד באצווה או עיבוד אונליין).
תרחישי שימוש באצווה מחייבים פריסה של תהליך אצווה שמופעל לפי לוח זמנים בסביבת הייצור. תהליך המסירה מתמקד בבדיקה של כל צינור הנתונים בשילוב בסביבה שדומה לסביבת הייצור לפני הפריסה. כחלק מתהליך הבדיקה, מפתחים יכולים לאמת דרישות ספציפיות לגבי התפוקה של תהליך האצווה עצמו, ולבדוק שכל הרכיבים של האפליקציה פועלים בצורה תקינה. (לדוגמה, מפתחים יכולים לבדוק הרשאות, תשתית ותלות בקוד).
תרחישי שימוש אונליין מחייבים פריסה של API, שהוא האפליקציה שמכילה את השרשרת ויכולה להגיב למשתמשים עם זמן אחזור נמוך. תהליך המסירה כולל בדיקה של ה-API באינטגרציה בסביבה שדומה לסביבת הייצור. מטרת הבדיקות האלה היא לוודא שכל הרכיבים של האפליקציה פועלים בצורה תקינה. אפשר לאמת דרישות לא פונקציונליות (לדוגמה, יכולת הרחבה, אמינות וביצועים) באמצעות סדרת בדיקות, כולל בדיקות עומס.
רשימת משימות לפריסה
ברשימה הבאה מפורטים השלבים שצריך לבצע כשפורסים אפליקציית AI גנרטיבי באמצעות שירות מנוהל כמו Vertex AI:
- הגדרת ניהול גרסאות: כדאי להטמיע שיטות עבודה מומלצות לניהול גרסאות של פריסות מודלים. ניהול גרסאות מאפשר לחזור לגרסאות קודמות אם יש צורך בכך, ולעקוב אחרי שינויים שבוצעו במודל או בהגדרות הפריסה.
- אופטימיזציה של המודל: לפני שאורזים או פורסים את המודל, מבצעים משימות אופטימיזציה של המודל (זיקוק, קוונטיזציה וגיזום).
- העברת המודל לקונטיינר: אריזת המודל שאומן בקונטיינר.
- הגדרת דרישות החומרה של היעד: מוודאים שסביבת הפריסה של היעד עומדת בדרישות לביצועים אופטימליים של המודל, כמו מעבדי GPU, מעבדי TPU ומאיצי חומרה מיוחדים אחרים.
- הגדרת נקודת הקצה של המודל: מציינים את מאגר המודל, פורמט הקלט, פורמט הפלט ופרמטרים נוספים של הגדרה.
- הקצאת משאבים: מקצים את משאבי ה-Compute המתאימים לנקודת הקצה על סמך התנועה הצפויה ודרישות הביצועים.
- הגדרת בקרת גישה: הגדרת מנגנונים של בקרת גישה כדי להגביל את הגישה לנקודת הקצה על סמך מדיניות אימות והרשאה. בקרת גישה עוזרת להבטיח שרק משתמשים או שירותים מורשים יוכלו ליצור אינטראקציה עם המודל שנפרס.
- יצירת נקודת קצה של מודל: יצירת נקודת קצה לפריסת המודל כשירות API בארכיטקטורת REST. נקודת הקצה מאפשרת ללקוחות לשלוח בקשות לנקודת הקצה ולקבל תשובות מהמודל.
- הגדרת מעקב ורישום ביומן: מגדירים מערכות מעקב ורישום ביומן כדי לעקוב אחרי הביצועים של נקודת הקצה, ניצול המשאבים ויומני השגיאות.
- פריסת שילובים בהתאמה אישית: שילוב המודל באפליקציות או בשירותים בהתאמה אישית באמצעות ה-SDK או ממשקי ה-API של המודל.
- פריסת אפליקציות בזמן אמת: יצירת צינור נתונים בסטרימינג שמעבד נתונים ומפיק תשובות בזמן אמת.
רישום ביומן ומעקב
כדי לעקוב אחרי אפליקציות של AI גנרטיבי והרכיבים שלהן, צריך להשתמש בטכניקות שאפשר להוסיף לטכניקות המעקב שבהן אתם משתמשים ב-MLOps רגיל. אתם צריכים לרשום ביומן ולעקוב אחרי האפליקציה מקצה לקצה, כולל רישום ביומן ומעקב אחרי הקלט והפלט הכוללים של האפליקציה וכל רכיב.
הקלט לאפליקציה מפעיל כמה רכיבים כדי ליצור את הפלט. אם הפלט של קלט מסוים לא מדויק מבחינה עובדתית, צריך לקבוע איזה מהרכיבים לא פעל בצורה טובה. אתם צריכים לכלול ביומן את השושלת של כל הרכיבים שהופעלו. בנוסף, צריך למפות את הקלט והרכיבים עם כל הארטיפקטים והפרמטרים הנוספים שהם תלויים בהם, כדי שתוכלו לנתח את הקלט והפלט.
כשמפעילים מעקב, מומלץ לתעדף מעקב ברמת האפליקציה. אם ניטור ברמת האפליקציה מוכיח שהאפליקציה פועלת בצורה טובה, זה מרמז שגם כל הרכיבים פועלים בצורה טובה. לאחר מכן, תוכלו להחיל מעקב על רכיבי המודל שמוצגים בהנחיה כדי לקבל תוצאות מפורטות יותר ולהבין טוב יותר את האפליקציה.
בדומה לניטור רגיל ב-MLOps, צריך להטמיע תהליך התראה כדי להודיע לבעלי האפליקציה על סחף, הטיה או ירידה בביצועים. כדי להגדיר התראות, צריך לשלב כלים להתראות ולהודעות בתהליך המעקב.
בקטעים הבאים מתוארות משימות של מעקב אחרי הטיה וסחף והערכה מתמשכת. בנוסף, המעקב ב-MLOps כולל מעקב אחרי מדדים של תקינות המערכת הכוללת, כמו שימוש במשאבים וחביון. מדדי היעילות האלה חלים גם על יישומים של AI גנרטיבי.
זיהוי הטיה
זיהוי הטיה במערכות קונבנציונליות של למידת מכונה מתייחס ל-training-serving skew שמתרחש כשחל שינוי בהתפלגות נתוני התכונות בסביבת הייצור לעומת התפלגות נתוני התכונות שנצפתה במהלך אימון המודל. במקרה של אפליקציות AI גנרטיביות שמשתמשות במודלים שאומנו מראש ברכיבים שמקושרים יחד כדי ליצור את הפלט, צריך גם למדוד הטיה. כדי למדוד הטיה, אפשר להשוות בין חלוקת נתוני הקלט שבהם השתמשתם כדי להעריך את האפליקציה לבין חלוקת הקלטים לאפליקציה בסביבת הייצור. אם שני ההתפלגויות מתרחקות זו מזו, צריך לבדוק את הנושא לעומק. אפשר להחיל את אותו התהליך גם על נתוני הפלט.
זיהוי סחיפה
בדומה לזיהוי הטיה, זיהוי סחף בודק הבדלים סטטיסטיים בין שני מערכי נתונים. עם זאת, במקום להשוות בין הערכות ובין נתוני קלט, זיהוי סחף מחפש שינויים בנתוני הקלט. זיהוי סחף מאפשר להעריך את נתוני הקלט, ולכן גם את השינויים בהתנהגות המשתמשים לאורך זמן.
מכיוון שהקלט של האפליקציה הוא בדרך כלל טקסט, אפשר להשתמש בשיטות שונות כדי למדוד הטיה וסחף. באופן כללי, השיטות האלה מנסות לזהות שינויים משמעותיים בנתוני הייצור, גם טקסטואליים (כמו גודל הקלט) וגם מושגיים (כמו נושאים בקלט), בהשוואה למערך נתוני ההערכה. כל השיטות האלה מחפשות שינויים שיכולים להצביע על כך שהאפליקציה לא מוכנה לטפל בהצלחה באופי הנתונים החדשים שמתקבלים עכשיו. כמה שיטות נפוצות כוללות את השיטות הבאות:
- חישוב הטמעות ומרחקים
- ספירת אורך הטקסט ומספר הטוקנים
- מעקב אחרי שינויים באוצר המילים, מושגים חדשים, כוונות, הנחיות ונושאים במערכי נתונים
- שימוש בגישות סטטיסטיות כמו least-squares density difference (הפרש צפיפות הריבועים הפחותים, PDF), maximum mean discrepancy (ההבדל המקסימלי בין הממוצעים, MMD), learned kernel MMD (ההבדל המקסימלי בין הממוצעים של ליבת הנלמדת, PDF) או MMD מודע-הקשר.
מקרים לשימוש ב-AI גנרטיבי הם מגוונים מאוד, ולכן יכול להיות שתצטרכו מדדים מותאמים אישית נוספים שישקפו בצורה טובה יותר שינויים לא צפויים בנתונים.
הערכה מתמשכת
גישה נפוצה נוספת למעקב אחרי אפליקציות של AI גנרטיבי היא הערכה רציפה. במערכת הערכה רציפה, המערכת מתעדת את התפוקה של המודל בסביבת הייצור ומריצה משימת הערכה באמצעות התפוקה הזו כדי לעקוב אחרי הביצועים של המודל לאורך זמן. אפשר לאסוף משוב ישיר מהמשתמשים, כמו דירוגים, שמספק תובנות מיידיות לגבי האיכות הנתפסת של התפוקות. במקביל, השוואה בין התשובות שנוצרו על ידי המודל לבין נתוני האמת מאפשרת ניתוח מעמיק יותר של הביצועים. אפשר לאסוף נתוני אמת באמצעות הערכה אנושית או כתוצאה מגישה של שילוב מודלים של AI כדי ליצור מדדי הערכה. התהליך הזה מספק תצוגה של השינויים במדדי ההערכה מאז פיתוח המודל ועד היום.
לשלוט
בהקשר של MLOps, ממשל כולל את כל השיטות והמדיניות שקובעות שליטה, אחריות ושקיפות לגבי הפיתוח, הפריסה והניהול השוטף של מודלים של למידת מכונה, כולל כל הפעילויות שקשורות למחזורי החיים של הקוד, הנתונים והמודל.
ביישומים של AI לחיזוי, שושלת מתמקדת במעקב אחרי המסלול המלא של מודל למידת מכונה והבנתו. ב-AI גנרטיבי, שושלת חורגת מארטיפקט המודל וכוללת את כל הרכיבים בשרשרת. המעקב כולל את הנתונים, המודלים, שושלת המודל, הקוד ונתוני ההערכה והמדדים הרלוונטיים. מעקב אחרי שושלת יכול לעזור לכם לבצע ביקורת במודלים, לנפות באגים ולשפר אותם.
בנוסף לשיטות העבודה החדשות האלה, אתם יכולים לנהל את מחזור החיים של הנתונים ואת מחזורי החיים של רכיבי ה-AI הגנרטיבי באמצעות שיטות עבודה סטנדרטיות של MLOps ו-DevOps.
המאמרים הבאים
פריסת אפליקציית AI גנרטיבי באמצעות Vertex AI
מחברים: Anant Nawalgaria, Christos Aniftos, Elia Secchi, Gabriela Hernandez Larios, Mike Styer, and Onofrio Petragallo