ה-AI הגנרטיבי מציג דרך חדשה לבנייה ולהפעלה של אפליקציות AI, ששונה מ-AI חיזוי. כדי ליצור אפליקציה מבוססת-AI גנרטיבי, צריך לבחור מתוך מגוון רחב של ארכיטקטורות וגדלים, לאצור נתונים, ליצור הנחיות אופטימליות, לכוונן מודלים למשימות ספציפיות ולבסס את התפוקות של המודל על נתונים מהעולם האמיתי.
במאמר הזה מוסבר איך אפשר להתאים תהליכי DevOps ו-MLOps כדי לפתח, לפרוס ולהפעיל אפליקציות 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 מזהים איזה מודל בסיסי מתאים ביותר לתרחיש השימוש שלהם. הם בוחנים את היתרונות, החסרונות והעלויות של כל מודל כדי לקבל החלטה מושכלת.
- פיתוח והתנסות: מפתחים משתמשים בהנדסת הנחיות כדי ליצור ולשפר הנחיות קלט ולקבל את הפלט הנדרש. כשזמינים, למידה עם מעט דוגמאות, כוונון יעיל בפרמטרים (PEFT) ושרשור מודלים עוזרים להנחות את התנהגות המודל. שרשור מודלים מתייחס לניהול של קריאות למספר מודלים ברצף ספציפי כדי ליצור תהליך עבודה.
- פריסה: מפתחים צריכים לנהל הרבה ארטיפקטים בתהליך הפריסה, כולל תבניות של הנחיות, הגדרות של שרשרות, מודלים מוטמעים, מאגרי נתונים לאחזור ומתאמי מודלים שעברו כוונון עדין. לארטיפקטים האלה יש דרישות ניהול משלהם, וצריך לנהל אותם בקפידה לאורך תהליך הפיתוח והפריסה. בנוסף, כשפורסים אפליקציות של AI גנרטיבי, צריך לקחת בחשבון את היכולות הטכניות של תשתית היעד, כדי לוודא שהדרישות של החומרה של האפליקציה מתקיימות.
- מעקב מתמשך בסביבת הייצור: אדמינים משפרים את הביצועים של האפליקציה ושומרים על תקני בטיחות באמצעות טכניקות של אתיקה של בינה מלאכותית, כמו הבטחת הוגנות, שקיפות ואחריות בתוצאות של המודל.
- שיפור מתמיד: מפתחים משנים כל הזמן את מודלי הבסיס באמצעות טכניקות הנחיה, החלפת המודלים בגרסאות חדשות יותר או אפילו שילוב של כמה מודלים כדי לשפר את הביצועים, את היעילות בעלויות או את זמן האחזור. אימון רציף רגיל עדיין רלוונטי לתרחישים שבהם נדרש כוונון עדין חוזר או שילוב של לולאות משוב מאנשים.
לשיטות הנדסת הנתונים יש תפקיד קריטי בכל שלבי הפיתוח. כדי ליצור תוצאות אמינות, צריך להשתמש בנתונים עובדתיים (כדי לוודא שהתוצאות של המודל מבוססות על מידע מדויק ועדכני) ובנתונים עדכניים ממערכות פנימיות וממערכות ארגוניות. התאמת הנתונים עוזרת להתאים את המודלים למשימות ולסגנונות ספציפיים, ולתקן שגיאות חוזרות.
איך מוצאים את מודל הבסיס לתרחיש לדוגמה
יצירת מודלים בסיסיים דורשת הרבה משאבים, ולכן רוב העסקים מעדיפים להשתמש במודל בסיסי קיים שמתאים לתרחיש השימוש שלהם. קשה למצוא את מודל הבסיס הנכון כי יש הרבה מודלים כאלה. לכל מודל יש ארכיטקטורות, גדלים, מערכי נתונים לאימון ורישיונות שונים. בנוסף, לכל תרחיש לדוגמה יש דרישות ייחודיות, ולכן צריך לנתח את המודלים הזמינים לפי כמה מימדים.
כשמעריכים מודלים, כדאי להביא בחשבון את הגורמים הבאים:
- איכות: מריצים הנחיות בדיקה כדי לאמוד את איכות הפלט.
- זמן אחזור וקצב העברת נתונים: צריך לקבוע את זמן האחזור ואת קצב העברת הנתונים שנדרשים לתרחיש השימוש, כי הגורמים האלה משפיעים ישירות על חוויית המשתמש. לדוגמה, צ'אטבוט דורש חביון נמוך יותר ממשימות סיכום שעוברות עיבוד באצווה.
- זמן פיתוח ותחזוקה: צריך לקחת בחשבון את ההשקעה בזמן לפיתוח הראשוני ולתחזוקה השוטפת. בדרך כלל, מודלים מנוהלים דורשים פחות מאמץ ממודלים שזמינים באופן פתוח ואתם פורסים בעצמכם.
- עלות השימוש: צריך לקחת בחשבון את עלויות התשתית והצריכה שמשויכות למודל.
- תאימות: הערכת היכולת של המודל לעמוד בתקנות הרלוונטיות ובתנאי הרישוי.
פיתוח וניסוי
כשמפתחים אפליקציות מבוססות-AI גנרטיבי, תהליכי הפיתוח והניסוי הם איטרטיביים ומתוזמנים. כל איטרציה ניסיונית כוללת שיפור של הנתונים, התאמה של מודל הבסיס והערכה של התוצאות. הערכה מספקת משוב שמנחה את האיטרציות הבאות בלולאת משוב מתמשכת. אם הביצועים לא עומדים בציפיות, אפשר לאסוף עוד נתונים, להוסיף לנתונים או לבצע עוד פעולות לניהול הנתונים. בנוסף, יכול להיות שתצטרכו לבצע אופטימיזציה של ההנחיות, להחיל טכניקות של כוונון עדין או לעבור למודל בסיסי אחר. מחזור העידון האיטרטיבי הזה, שמבוסס על תובנות מההערכה, חשוב לא פחות לאופטימיזציה של אפליקציות AI גנרטיביות מאשר לאופטימיזציה של למידת מכונה ו-AI לחיזוי.
הפרדיגמה של מודל הבסיס
מודלים בסיסיים שונים ממודלים לחיזוי כי הם מודלים רב-תכליתיים. במקום לאמן מודלים למטרה אחת על נתונים שספציפיים למשימה הזו, מודלים בסיסיים מאומנים על מערכי נתונים רחבים, ולכן אפשר להשתמש במודל בסיסי במגוון רחב של תרחישי שימוש.
מודלים בסיסיים רגישים מאוד לשינויים בקלט שלהם. הפלט של המודל והמשימה שהוא מבצע נקבעים לפי הקלט שמועבר למודל. מודל בסיסי יכול לתרגם טקסט, ליצור סרטונים או לסווג נתונים פשוט על ידי שינוי הקלט. גם שינויים קלים בקלט יכולים להשפיע על היכולת של המודל לבצע את המשימה בצורה נכונה.
המאפיינים האלה של מודלים בסיסיים מחייבים שיטות פיתוח ותפעול שונות. למרות שמודלים בהקשר של AI לחיזוי הם עצמאיים וספציפיים למשימה, מודלים בסיסיים הם רב-תכליתיים וצריכים אלמנט נוסף מעבר לקלט של משתמשים. מודלים של AI גנרטיבי דורשים הנחיה, ובאופן ספציפי יותר, תבנית הנחיה. תבנית הנחיה היא קבוצה של הוראות ודוגמאות עם placeholders להזנת קלט של משתמשים. האפליקציה יכולה לשלב את תבנית ההנחיה עם הנתונים הדינמיים (כמו הקלט של המשתמש) כדי ליצור הנחיה מלאה, שהיא הטקסט שמועבר כקלט למודל הבסיסי.
רכיב המודל עם ההנחיה
הנוכחות של ההנחיה היא מאפיין ייחודי של אפליקציות מבוססות-AI גנרטיבי. המודל וההנחיה לא מספיקים ליצירת תוכן. מערכת AI גנרטיבי צריכה את שניהם. השילוב של המודל וההנחיה נקרא רכיב המודל עם ההנחיה. רכיב המודל שנוצר על סמך הנחיה הוא הרכיב העצמאי הקטן ביותר שמספיק ליצירת אפליקציית AI גנרטיבי. ההנחיה לא צריכה להיות מסובכת. לדוגמה, יכולה להיות הוראה פשוטה כמו 'תרגם את המשפט הבא מאנגלית לצרפתית', ואחריה המשפט שרוצים לתרגם. אבל בלי ההוראה המקדימה הזו, מודל בסיסי לא יבצע את משימת התרגום הנדרשת. לכן, כדי שמודל בסיסי יבצע את המשימה שנדרשת על ידי האפליקציה, צריך להזין הנחיה, אפילו רק הוראה בסיסית, יחד עם הקלט.
רכיב המודל עם ההנחיה יוצר הבחנה חשובה בשיטות העבודה של MLOps בפיתוח אפליקציות AI גנרטיבי. בפיתוח של אפליקציית AI גנרטיבי, צריך לבצע ניסויים ואיטרציות בהקשר של רכיב מודל שמונחה על ידי הנחיה. מחזור הניסויים של AI גנרטיבי מתחיל בדרך כלל בבדיקת וריאציות של ההנחיה – שינוי הניסוח של ההוראות, הוספת הקשר או הכללת דוגמאות רלוונטיות – והערכת ההשפעה של השינויים האלה. השיטה הזו נקראת בדרך כלל הנדסת הנחיות.
הנדסת הנחיות כוללת את השלבים האיטרטיביים הבאים:
- הנחיה: יצירה ושיפור של הנחיות כדי להפיק התנהגויות רצויות ממודל בסיסי לתרחיש שימוש ספציפי.
- הערכה: הערכת הפלטים של המודל, באופן אידיאלי באמצעות תוכנה, כדי לאמוד את ההבנה שלו ואת מידת ההצלחה שלו בביצוע ההוראות בהנחיה.
כדי לעקוב אחרי תוצאות ההערכה, אפשר לרשום את התוצאות של ניסוי. ההנחיה עצמה היא רכיב מרכזי בתהליך של הנדסת הנחיות, ולכן היא הופכת לארטיפקט הכי חשוב מבין הארטיפקטים שמשתתפים בניסוי.
עם זאת, כדי להתנסות באפליקציית AI גנרטיבי, צריך לזהות את סוגי הארטיפקטים. ב-AI חיזוי, הנתונים, צינורות הנתונים והקוד שונים. אבל עם פרדיגמת ההנחיות ב-AI גנרטיבי, ההנחיות יכולות לכלול הקשר, הוראות, דוגמאות, אמצעי הגנה ונתונים פנימיים או חיצוניים בפועל שנמשכים ממקום אחר.
כדי לקבוע את סוג הארטיפקט, צריך להבין שלהנחיה יש רכיבים שונים ונדרשות אסטרטגיות ניהול שונות. כמה נקודות שכדאי לחשוב עליהן:
- הנחיה כנתונים: חלקים מסוימים בהנחיה מתפקדים כמו נתונים. רכיבים כמו דוגמאות עם מעט נתונים, מאגרי ידע ושאילתות של משתמשים הם בעצם נקודות נתונים. הרכיבים האלה דורשים שיטות MLOps שמתמקדות בנתונים, כמו אימות נתונים, זיהוי סחף וניהול מחזור חיים.
- הנחיה כקוד: רכיבים אחרים כמו הקשר, תבניות להנחיות ומגבלות דומים לקוד. הרכיבים האלה מגדירים את המבנה והכללים של ההנחיה עצמה, ונדרשים תהליכי אישור, ניהול גרסאות של קוד ובדיקות.
לכן, כשמיישמים שיטות עבודה מומלצות של MLOps על AI גנרטיבי, צריך להגדיר תהליכים שמאפשרים למפתחים לאחסן, לאחזר, לעקוב ולשנות הנחיות בקלות. התהליכים האלה מאפשרים חזרה מהירה על שלבים וניסויים מבוססי עקרונות. לעתים קרובות, גרסה מסוימת של הנחיה יכולה לפעול היטב עם גרסה ספציפית של המודל, אבל לא עם גרסה אחרת. כשעוקבים אחרי התוצאות של ניסוי, צריך לתעד את ההנחיה, את גרסאות הרכיבים, את גרסת המודל, את המדדים ואת נתוני הפלט.
שרשור מודלים והגדלה
מודלים של 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 אחרים בצורה מתואמת כדי להשיג מטרה ספציפית. בדרך כלל לא צריך הנדסת פיצ'רים (feature engineering), איסוף נתונים או מחזורי אימון נוספים של המודל, אלא רק שינויים בניסוח של תבנית ההנחיה.
המעבר ל-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 גנרטיבי, אפליקציה אחת יכולה להשתמש בסוגים שונים של נתונים ממקורות נתונים שונים לחלוטין, וכולם פועלים יחד.
כדאי להביא בחשבון את סוגי הנתונים הבאים:
- הנחיות מותנות: הוראות שניתנות למודל הבסיסי כדי להנחות את הפלט שלו ולקבוע את הגבולות של מה שהוא יכול ליצור.
- דוגמאות עם מעט נתונים: דרך להראות למודל מה רוצים להשיג באמצעות זוגות של קלט ופלט. הדוגמאות האלה עוזרות למודל להבין את המשימות הספציפיות, ובמקרים רבים הן יכולות לשפר את הביצועים.
- נתוני ביסוס או הגדלה: הנתונים שמאפשרים למודל הבסיסי ליצור תשובות להקשר ספציפי ולשמור על עדכניות ורלוונטיות של התשובות בלי לאמן מחדש את כל המודל הבסיסי. הנתונים האלה יכולים להגיע מ-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 לצד מסד נתונים, וכולם מוזנים על ידי פייפליין דינמי. כל אחד מהרכיבים האלה עשוי לדרוש תהליך פריסה משלו.
פריסת אפליקציות של AI גנרטיבי דומה לפריסה של מערכות תוכנה מורכבות אחרות, כי צריך לפרוס רכיבי מערכת כמו מסדי נתונים ואפליקציות 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 ומאיצי חומרה מיוחדים אחרים.
- הגדרת נקודת הקצה של המודל: מציינים את מאגר המודל, פורמט הקלט, פורמט הפלט ופרמטרים נוספים של הגדרה.
- הקצאת משאבים: הקצאת משאבי מחשוב מתאימים לנקודת הקצה על סמך התנועה הצפויה ודרישות הביצועים.
- הגדרת בקרת גישה: הגדרת מנגנונים לבקרת גישה כדי להגביל את הגישה לנקודת הקצה על סמך מדיניות אימות והרשאה. בקרת גישה עוזרת להבטיח שרק משתמשים או שירותים מורשים יוכלו ליצור אינטראקציה עם המודל שנפרס.
- Create model endpoint: יצירת נקודת קצה לפריסת המודל כשירות 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 ו-Onofrio Petragallo