ה-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 גנרטיבי. ההנחיה לא צריכה להיות מסובכת. לדוגמה, אפשר לתת הוראה פשוטה כמו "תרגם את המשפט הבא מאנגלית לצרפתית", ואז לכתוב את המשפט שרוצים לתרגם. אבל בלי ההוראה המקדימה הזו, מודל בסיס לא יבצע את משימת התרגום הנדרשת. לכן, כדי שמודל בסיסי יבצע את המשימה שנדרשת על ידי האפליקציה, צריך להזין הנחיה, אפילו רק הוראה בסיסית, יחד עם הקלט.
רכיב המודל עם ההנחיות יוצר הבחנה חשובה בשיטות העבודה של MLOps בפיתוח אפליקציות של AI גנרטיבי. בפיתוח של אפליקציית AI גנרטיבי, צריך לבצע ניסויים ואיטרציות בהקשר של רכיב מודל שמונחה על ידי הנחיה. מחזור הניסויים של AI גנרטיבי מתחיל בדרך כלל בבדיקת וריאציות של ההנחיה – שינוי הניסוח של ההוראות, הוספת הקשר או הכללת דוגמאות רלוונטיות – והערכת ההשפעה של השינויים האלה. השיטה הזו נקראת בדרך כלל הנדסת פרומפטים.
הנדסת פרומפטים כוללת את השלבים האיטרטיביים הבאים:
- הנחיות: יצירה ושיפור של הנחיות כדי להפיק התנהגויות רצויות ממודל בסיסי לתרחיש שימוש ספציפי.
- הערכה: הערכת הפלטים של המודל, באופן אידיאלי באמצעות תוכנה, כדי לאמוד את ההבנה שלו ואת מידת ההצלחה שלו בביצוע ההוראות בהנחיה.
כדי לעקוב אחרי תוצאות ההערכה, אפשר לרשום את התוצאות של ניסוי. ההנחיה עצמה היא רכיב מרכזי בתהליך הנדסת ההנחיות, ולכן היא הופכת לארטיפקט החשוב ביותר מבין הארטיפקטים שמשתתפים בניסוי.
עם זאת, כדי להתנסות באפליקציה מבוססת-AI גנרטיבי, צריך לזהות את סוגי הארטיפקטים. ב-AI חיזוי, הנתונים, צינורות הנתונים והקוד שונים. אבל עם פרדיגמת ההנחיות ב-AI גנרטיבי, ההנחיות יכולות לכלול הקשר, הוראות, דוגמאות, אמצעי הגנה ונתונים פנימיים או חיצוניים בפועל שנמשכים ממקום אחר.
כדי לקבוע את סוג הארטיפקט, צריך להבין שלהנחיה יש רכיבים שונים ונדרשות אסטרטגיות ניהול שונות. כמה נקודות שכדאי לחשוב עליהן:
- הנחיה כנתונים: חלקים מסוימים בהנחיה מתפקדים כמו נתונים. רכיבים כמו פרומפט עם כמה דוגמאות (few-shot), מאגרי ידע ושאילתות של משתמשים הם בעצם נקודות נתונים. הרכיבים האלה דורשים שיטות 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. בבינה מלאכותית גנרטיבית, מפתחים שרשרת במהלך השילוב, מבצעים ניסויים בשרשרת מקצה לקצה, וחוזרים על אסטרטגיות שרשור, פרומפטים, מודלים בסיסיים וממשקי 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 גנרטיבי, אפליקציה אחת יכולה להשתמש בסוגים שונים של נתונים ממקורות נתונים שונים לחלוטין, וכולם פועלים יחד.
כדאי להביא בחשבון את סוגי הנתונים הבאים:
- הנחיות להתניה: הוראות שניתנות למודל הבסיס כדי להנחות את הפלט שלו ולקבוע את הגבולות של מה שהוא יכול ליצור.
- פרומפט עם כמה דוגמאות (few-shot): דרך להראות למודל מה רוצים להשיג באמצעות זוגות של קלט ופלט. הדוגמאות האלה עוזרות למודל להבין את המשימות הספציפיות, ובמקרים רבים הן יכולות לשפר את הביצועים.
- נתוני Grounding או נתוני הגדלה: הנתונים שמאפשרים למודל הבסיסי ליצור תשובות להקשר ספציפי ולשמור על עדכניות ורלוונטיות של התשובות בלי לאמן מחדש את כל המודל הבסיסי. הנתונים האלה יכולים להגיע מממשקי API חיצוניים (כמו חיפוש Google) או מממשקי API פנימיים וממקורות נתונים.
- מערכי נתונים ספציפיים למשימות: מערכי הנתונים שעוזרים לכוונן מודל בסיסי קיים למשימה מסוימת, וכך לשפר את הביצועים שלו בתחום הספציפי הזה.
- מערכי נתונים מלאים לאימון מוקדם: מערכי הנתונים העצומים שמשמשים לאימון הראשוני של מודלים בסיסיים. יכול להיות שלמפתחי אפליקציות אין גישה לנתונים האלה או לטוקנייזרים, אבל המידע שמקודד במודל עצמו משפיע על הפלט והביצועים של האפליקציה.
מגוון סוגי הנתונים הזה מוסיף שכבת מורכבות מבחינת ארגון הנתונים, מעקב וניהול מחזור החיים. לדוגמה, אפליקציה מבוססת-RAG יכולה לשכתב שאילתות של משתמשים, לאסוף באופן דינמי דוגמאות רלוונטיות באמצעות אוסף של דוגמאות שנבחרו בקפידה, לשלוח שאילתה למאגר נתונים וקטורי ולשלב את המידע עם תבנית הנחיה. אפליקציה שמבוססת על RAG מחייבת ניהול של כמה סוגי נתונים, כולל שאילתות משתמשים, מסדי נתונים וקטוריים עם פרומפט עם כמה דוגמאות (few-shot) ומידע על החברה, ותבניות של הנחיות.
כל סוג נתונים צריך ארגון ותחזוקה קפדניים. לדוגמה, כדי להשתמש במסד נתונים וקטורי, צריך לעבד את הנתונים להטמעות, לבצע אופטימיזציה של אסטרטגיות חלוקה למקטעים ולוודא שרק מידע רלוונטי זמין. צריך ליצור גרסאות לתבניות של הנחיות ולעקוב אחריהן, וצריך לשכתב את השאילתות של המשתמשים. שיטות מומלצות ל-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 ו-Agent Platform Feature Store כדי לעקוב אחרי השינויים האלה ואחרי הגרסאות של מערכי הנתונים האלה.
- מודלים של מתאמים: טכניקות כמו כוונון LoRA למודלים של מתאמים מתפתחות כל הזמן. כדי לנהל את הנכסים האלה בצורה יעילה, כדאי להשתמש בפתרונות מוכרים לאחסון נתונים (לדוגמה, Cloud Storage).
אינטגרציה רציפה (CI)
במסגרת של אינטגרציה רציפה, כל שינוי בקוד עובר בדיקה אוטומטית לפני המיזוג, כדי לזהות בעיות בשלב מוקדם. בדיקות יחידה ובדיקות שילוב חשובות לאיכות ולאמינות. בדיקות יחידה מתמקדות בחלקים נפרדים של הקוד, בעוד שבדיקות שילוב מוודאות שרכיבים שונים פועלים יחד.
הטמעה של מערכת אינטגרציה רציפה עוזרת לבצע את הפעולות הבאות:
- הבטחת פלט אמין ואיכותי: בדיקות קפדניות מגבירות את הביטחון בביצועים ובעקביות של המערכת.
- זיהוי באגים בשלב מוקדם: זיהוי בעיות באמצעות בדיקות מונע מהן לגרום לבעיות גדולות יותר בהמשך. אם מאתרים באגים בשלב מוקדם, המערכת חזקה ועמידה יותר במקרים קיצוניים ובקלט לא צפוי.
- עלויות תחזוקה נמוכות יותר: תרחישי בדיקה מתועדים היטב מפשטים את פתרון הבעיות ומאפשרים לבצע שינויים בצורה חלקה יותר בעתיד, וכך מצמצמים את המאמצים הכוללים שנדרשים לתחזוקה.
ההטבות האלה חלות על אפליקציות AI גנרטיבי. הטמעה של שילוב רציף בכל רכיבי המערכת, כולל תבניות ההנחיות, השרשרת, לוגיקת השרשור, כל המודלים המוטמעים ומערכות השליפה.
עם זאת, ליישום של אינטגרציה רציפה ב-AI גנרטיבי יש את האתגרים הבאים:
- קשה ליצור תרחישי בדיקה מקיפים: הפלט של AI גנרטיבי הוא מורכב ופתוח, ולכן קשה להגדיר וליצור קבוצה מקיפה של תרחישי בדיקה שמכסים את כל האפשרויות.
- בעיות בשחזור: קשה להשיג תוצאות דטרמיניסטיות שניתנות לשחזור, כי למודלים גנרטיביים יש לעיתים קרובות אקראיות ומשתנות מובנות בפלט שלהם, גם עבור קלטים זהים. האקראיות הזו מקשה על בדיקה עקבית של התנהגויות צפויות.
האתגרים האלה קשורים קשר הדוק לשאלה הרחבה יותר של הערכת אפליקציות של AI גנרטיבי. אפשר להחיל רבות מטכניקות ההערכה על פיתוח של מערכות CI ל-AI גנרטיבי.
פיתוח רציף (continuous delivery)
אחרי מיזוג הקוד, מתחיל תהליך של מסירה רציפה כדי להעביר את הקוד שנבנה ונבדק דרך סביבות שדומות מאוד לסביבת הייצור, לצורך בדיקות נוספות לפני הפריסה הסופית.
כפי שמתואר במאמר פיתוח וניסוי, רכיבי שרשרת הופכים לאחד מהרכיבים העיקריים לפריסה, כי הם מהווים את הבסיס לאפליקציית ה-AI הגנרטיבי. תהליך המסירה של אפליקציית ה-AI הגנרטיבי שמכילה את השרשרת עשוי להשתנות בהתאם לדרישות ההשהיה ולתרחיש לדוגמה (עיבוד באצווה או עיבוד אונליין).
במקרים לשימוש בקבוצות, צריך לפרוס תהליך קבוצתי שמופעל לפי לוח זמנים בסביבת הייצור. תהליך ההעברה מתמקד בבדיקת כל צינור הנתונים בשילוב בסביבה שדומה לסביבת הייצור לפני הפריסה. כחלק מתהליך הבדיקה, מפתחים יכולים לאשר דרישות ספציפיות לגבי התפוקה של תהליך האצווה עצמו, ולבדוק שכל הרכיבים של האפליקציה פועלים בצורה תקינה. (לדוגמה, מפתחים יכולים לבדוק הרשאות, תשתית ותלות בקוד).
תרחישי שימוש אונליין מחייבים פריסה של API, שהוא האפליקציה שמכילה את השרשרת ויכולה להגיב למשתמשים עם זמן אחזור נמוך. תהליך המסירה כולל בדיקה של ה-API באינטגרציה בסביבה שדומה לסביבת הייצור. מטרת הבדיקות האלה היא לוודא שכל הרכיבים של האפליקציה פועלים בצורה תקינה. אפשר לאמת דרישות לא פונקציונליות (לדוגמה, יכולת הרחבה, אמינות וביצועים) באמצעות סדרת בדיקות, כולל בדיקות עומס.
רשימת משימות לפריסה
ברשימה הבאה מפורטים השלבים שצריך לבצע כשפורסים אפליקציית AI גנרטיבי באמצעות שירות מנוהל כמו Gemini Enterprise Agent Platform:
- הגדרת ניהול גרסאות: הטמעת שיטות של ניהול גרסאות לפריסות של מודלים. ניהול גרסאות מאפשר לחזור לגרסאות קודמות אם יש צורך בכך, ולעקוב אחרי שינויים שבוצעו במודל או בהגדרות הפריסה.
- אופטימיזציה של המודל: מבצעים משימות אופטימיזציה של המודל (זיקוק, קוונטיזציה וגיזום) לפני אריזת המודל או הפריסה שלו.
- העברת המודל לקונטיינר: אריזת המודל שאומן בקונטיינר.
- הגדרת דרישות החומרה של היעד: מוודאים שסביבת הפריסה של היעד עומדת בדרישות לביצועים אופטימליים של המודל, כמו מעבדי GPU, מעבדי TPU ומאיצי חומרה מיוחדים אחרים.
- הגדרת נקודת הקצה של המודל: מציינים את מאגר המודל, פורמט הקלט, פורמט הפלט ופרמטרים נוספים של הגדרה.
- הקצאת משאבים: מקצים את משאבי ה-Compute המתאימים לנקודת הקצה על סמך התנועה הצפויה ודרישות הביצועים.
- הגדרת בקרת גישה: הגדרת מנגנונים לבקרת גישה כדי להגביל את הגישה לנקודת הקצה על סמך מדיניות אימות והרשאה. בקרת גישה עוזרת לוודא שרק משתמשים או שירותים מורשים יכולים ליצור אינטראקציה עם המודל שנפרס.
- יצירת נקודת קצה של מודל: יצירת נקודת קצה כדי לפרוס את המודל כשירות API בארכיטקטורת REST. נקודת הקצה מאפשרת ללקוחות לשלוח בקשות לנקודת הקצה ולקבל תשובות מהמודל.
- הגדרת מעקב ורישום ביומן: מגדירים מערכות מעקב ורישום ביומן כדי לעקוב אחרי הביצועים של נקודת הקצה, ניצול המשאבים ויומני השגיאות.
- פריסת שילובים בהתאמה אישית: שילוב המודל באפליקציות או בשירותים בהתאמה אישית באמצעות ערכת ה-SDK או ממשקי ה-API של המודל.
- פריסת אפליקציות בזמן אמת: יצירת צינור נתונים בסטרימינג שמעבד נתונים ומפיק תשובות בזמן אמת.
רישום ביומן ומעקב
כדי לנטר אפליקציות של AI גנרטיבי ואת הרכיבים שלהן, צריך להוסיף טכניקות לניטור לטכניקות הניטור שבהן אתם משתמשים ב-MLOps רגיל. אתם צריכים לתעד ולנטר את האפליקציה מקצה לקצה, כולל תיעוד וניטור של הקלט והפלט הכוללים של האפליקציה ושל כל רכיב.
הקלט לאפליקציה מפעיל כמה רכיבים כדי ליצור את הפלט. אם הפלט של קלט מסוים לא מדויק מבחינה עובדתית, צריך לקבוע איזה מהרכיבים לא פעל בצורה טובה. אתם צריכים לכלול ביומן את שושלת הנתונים של כל הרכיבים שהופעלו. בנוסף, צריך למפות את הקלט והרכיבים עם כל הארטיפקטים והפרמטרים הנוספים שהם תלויים בהם, כדי שתוכלו לנתח את הקלט והפלט.
כשמפעילים מעקב, מומלץ לתעדף מעקב ברמת האפליקציה. אם ניטור ברמת האפליקציה מוכיח שהאפליקציה פועלת בצורה טובה, זה אומר שגם כל הרכיבים פועלים בצורה טובה. לאחר מכן, תוכלו להחיל מעקב על רכיבי המודל שמוצגים בהנחיה כדי לקבל תוצאות מפורטות יותר ולהבין טוב יותר את האפליקציה.
בדומה לניטור רגיל ב-MLOps, צריך להטמיע תהליך התראה כדי להודיע לבעלי האפליקציה על סחף, הטיה או ירידה בביצועים. כדי להגדיר התראות, צריך לשלב כלים להתראות ולהודעות בתהליך המעקב.
בקטעים הבאים מתוארות משימות של מעקב אחרי הטיה וסחף והערכה מתמשכת. בנוסף, המעקב ב-MLOps כולל מעקב אחרי מדדים של תקינות המערכת הכוללת, כמו שימוש במשאבים וחביון. מדדי היעילות האלה חלים גם על יישומים של AI גנרטיבי.
זיהוי הטיה
זיהוי הטיה במערכות קונבנציונליות של למידת מכונה מתייחס להטיה באימון ובפריסה שמתרחשת כשחל שינוי בהתפלגות נתוני התכונות בסביבת הייצור לעומת התפלגות נתוני התכונות שנצפתה במהלך אימון המודל. במקרה של אפליקציות 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 גנרטיבי באמצעות Agent Platform
מחברים: Anant Nawalgaria, Christos Aniftos, Elia Secchi, Gabriela Hernandez Larios, Mike Styer ו-Onofrio Petragallo