יוצא לחפש אחר דאטה ו-AI

הצצה אל מאחורי הקלעים של אימון מודלי AI, חושפת תהליך מורכב ויקר, ומגלה כי הדאטה עליו מתאמן המודל הוא אולי האתגר הגדול בפיתוח אפליקציות ארגוניות מבוססות GenAI. על הסכנה הגדולה בשיבושי דאטה נעלמים מן העין, עליית מקצוע ה-Data Reliability Engineer וגם סיפור אמתי לגמרי על מודל שהשתגע

המפגש שלנו ביומיום עם בינה מלאכותית גנרטיבית הוא נחמד ופשוט. אני, למשל, משתמש ב-ChatGPT וב-BARD למצגות (בשילוב עם Midjourney), לניתוח וכתיבת קוד, ואפילו לכתיבת מאמרים וסיפורים לילדים שלי. זה קל ולא מצריך כל מאמץ מצדי. הקלות הזו בשימוש ב-AI המוגש כשירות, מתעתעת, כי מנהלים בארגונים מתפתים לחשוב שבאותה קלות שבה הם עושים שימוש יומיומי בטכנולוגיה, ניתן ליישם תהליכים מבוססי AI בארגונים גדולים, שצריכים לתת דין וחשבון לרגולטור או ללקוחותיהם. אבל האמת היא שמאחורי הקלעים של האפליקציות הידידותיות, מגלים תהליכים מורכבים מאוד.

מאחורי הקלעים של אימון מודלים – יש למישהו במקרה אסימון?

מודלי שפה גדולים, ובפרט מודלי Assistant (כמו ChatGPT) לא נוצרים יש מאין. הבניה והאימון שלהם תלויים בתהליך ארוך, מורכב ובעיקר יקר העושה שימוש באבני בניין בסיסיות הנקראות Tokens. תהליך האימון של מודלים מורכבים כמו זה שאנו מכירים המניע את ChatGPT כולל בדרך ארבעה שלבים מרכזיים:

Pre-Training – בשלב זה באמצעות אימון על מערך נתונים עצום, נוצר מודל בסיס, שעדיין רחוק מאוד מהמודל שאחראי ל-ChatGPT. תהליך האימון הוא מורכב וארוך ודורש כוח מחשוב עצום. בתחילת השנה הודלף מידע על תהליך האימון של מודל LLaMA של חברת מטא: המידע עליו אומן המודל, בתהליך שלקח 21 ימים, מכיל כ-65 מיליארד פרמטרים על 2,048 מעבדי GPU מסוג A100 בעלות של כ-5 מיליון דולר. ועדיין מדובר רק על מודל בסיס. לצורך השוואה, GPT 3.5 (המודל הישן של OpenAI) מכיל 175 מיליארד פרמטרים.

בשלב הזה נוצר הקסם, המודל לומד רפרזנטציות כלליות משמעותיות שעוזרות לו לפרק את מבנה השפה ואת היחסים וקשרי הגומלין בין המילים השונות. חשוב לומר שמודל שפה לא יודע באמת מה הן מילים משום שהוא אינו מכיר קונספט כזה. למעשה מודל עובר אימון על טוקנים (סמל / אסימון) שהם למעשה רפרזנטציה מספרית (Integers) של האותיות. מודלי בסיס כאמור, עוסקים במשימה אחת ויחידה והיא לחזות את הטוקן הבא הסביר ביותר מבחינה סטטיסטית.

מטפסים שלב למודל Assistant שיודע לתת מענה לשאלות

Supervised Fine Tuning – בשלב זה, מודל הבסיס עובר אימון נוסף, במטרה ליצור מודל Assistant שהוא בפשטות מודל המיומן במתן מענה לשאלות ולא רק בהשלמת מסמכים. למרות שניתן לבקש ממודל בסיס להתנהג כמודל Assistant על ידי שימוש ב- Prompt, הוא עדיין לא ״חכם״ מספיק להוות מודל מסוג Assistant ללא שלב ה- Supervised Fine Tuning, שבו גם ניתן למקד את יכולות המודל סביב עולם תוכן מסוים (כמו למשל פיננסים). שלב זה הוא למעשה שלב בו נותנים למודל אלפי דוגמאות ועוזרים לו להבין מה היא הציפייה ממנו וגם מה היא התשובה הטובה ביותר שהוא יכול לתת ע״י טכניקה של פירוק, מבנה התשובה והחלקים השונים בה לגורמים.

השלב הבא: בינה מלאכותית עורכת ניסויים בבני אדם – לא באמת, אבל מסתבר שאנחנו טובים בשיפור ביצועי מודלים

Reward Modeling – בשלב זה נעשה שימוש בבני אדם על מנת לשפר את ביצועי המודל. אנחנו מתגלים כטובים מאוד בלבחור את התשובה הנכונה ביותר או הטובה ביותר מבין כמה תשובות. השימוש בשיטה הזו מאפשר ליצור Loss Function המשמש את השלב הבא של אימון המודל.  בבסיסה, פונקציית Loss מייצגת מדד ל״מידת ההתאמה״ של תוצאות/תחזיות של מודל Machine Learning למציאות בפועל. התוצר הוא למעשה כימות המלמד עד כמה רחוקות התחזיות של המודל מהערכים האמתיים. או באופן פשוט יותר “ההבדל בין מה שיש למה שצריך להיות”.

Reinforcement Learning או למידת חיזוק – בשלב זה, התנהגויות חיוביות (או טוקנים נכונים) מקבלות חיזוק עפ״י ה-Loss Function שנוצר תוך הפחתת הסבירות להתנהגויות לא רצויות אשר לא מקבלות חיזוק כלל. באופן הזה המודל מתכוונן לתת תוצאות אופטימליות אל מול ההגדרה של ה- Loss Function.

עכשיו, כשאנחנו מבינים מה נדרש כדי לפתח מודל שפה, ניתן גם להבין שלא כל ארגון מסוגל לעשות זאת, נדרש ידע מעמיק וייחודי וכן משאבים כלכליים עצומים. לכן, רוב השימוש במודלי השפה הגדולים יעשה ע״י שימוש ב-API ורוב ספקיות הענן ומספר סטרטאפים כבר מציעים שירותים המאפשרים זאת. לצד זאת, עולם ה-Open Source לא נשאר אדיש, וכיום יש מספר רב של מודלים באיכות גבוהה מאוד, מבוססי קוד פתוח, שניתן לעשות בהם שימוש לצורך יישום של פתרונות מבוססי AI.

מודל ה-Data-centric – כאשר הדאטה תופס את מקום המודל במרכז הבמה

קופרניקוס בילה את ימיו האחרונים בלשכנע את העולם שכדור הארץ אינו במרכז מערכת השמש. כיום כולם מדברים AI ונראה כאילו הכל סובב סביב המודלים, אבל הולכת ומתחדדת ההבנה שמודלי ה-AI, מורכבים וחכמים ככל שיהיו אינם המרכז אלא ה-Data שעליו הם עוברים את האימון שלהם וממנו הם נוצרים. ארגונים שרוצים לעשות שימוש במודלי AI על גבי ה-Data שלהם חייבים לטפל בשאלות ארגוניות וטכנולוגיות כמו מי אחראי על איכות המידע הניתן למודל? איך מוודאים את מהימנותו? וכיצד מודדים את נכונות התשובות שהמודלים הג׳נרטיביים נותנים למשתמשים.

Data Products – הסכנה הגדולה בשיבושי הדאטה הנעלמים מן העין

אחד המושגים החשובים ביותר בעולם ה-Data כיום הוא Data Product, והוא מתייחס לאפליקציה או כלי המבוססים על Data ומונגשים לארגון כמוצר. מאחורי הקלעים של כל Data Product שכזה, יהיה זה מודל AI או אפילו Dashboard ארגוני – יש המון תשתיות ותהליכים שעובדים יחד. תקלה משמעותית יכולה להתבטא במידע שלא מגיע בזמן, לקוחות לא מרוצים ואובדן הכנסה.  אבל התקלות המורכבות באמת הן לאו דווקא התקלות שמפילות תהליכים, אלא תקלות שגורמות לשינויים ואי דיוקים ב-Data שאותם לפעמים קשה לאתר, וכאשר ה-Data הזה פוגש את מודל ה-AI שלנו, בין אם באימון או כקונטקסט, זה כבר מאוחר מדי. מקרים כאלה נקראים Data Down Time.

על מנת למדוד את איכותם של הנתונים ולהתריע כאשר ישנו שינוי (Drift) במידע, ארגונים נדרשים לפתח יכולות, תהליכי עבודה ואף לעשות שימוש במוצרים ייעודיים מעולם ה-Data Quality. הכלים ותהליכי המדידה הללו נופלים תחת קטגוריה מתפתחת הנקראת Data Observability עם פלטפורמות כמו MonteCarloData, BigEye ועוד. אבל שימוש בכלים וניטור תשתיות כשלעצמו אינו מספיק, נדרש בעל מקצוע שאמון על טיפול בנושאים כאלה ויכול לתת מענה כאשר ישנן תקלות Data.

זה מטוס? זו ציפור? לא, זה Data Reliability Engineer!

תחום חדש שעושה את הצעדים הראשונים שלו וקיים כבר בארגונים כמו Uber, Disney ועוד הוא Data Reliability Engineering. ה- DRE’s הם למעשה Data Engineers עם התמחות בנושאי מהימנות של תשתיות ומידע בארגון. הם עובדים על מערכות ה-Data Observability ואמונים על ארבעה אזורים מרכזיים:

• איכות ה-Data
• ניטור תהליכי עיבוד המידע (Pipeline Monitoring)
• מיטוב ביצועים
• מתן מענה לתקלות (Incident Response)

בעזרת ה-DRE’s ארגונים יכולים במהירות להוריד את הזמן לזיהוי תקלה (Time to Detection), להגיע לסיבה ממנה קרתה התקלה (Root Cause Analysis), וכן לטפל בתקלות עם SLA מדוד (Time to Resolution).

אז מה היה לנו לאחרונה בחדשות בינה מלאכותית גנרטיבית? דיווח על ירידה בביצועי ChatGPT ומחקר מדעי שחשף מודל שהשתגע. כדאי להמשיך לעקוב

בעתיד הקרוב, אנו נראה מספר רב של סטרטאפים שמנסים להנגיש את חווית ה-AI הארגוני כשירות, וזאת לצד גדילה ביישומים הארגוניים המפותחים פנימית. כל זה קורה כאשר ישנה התפתחות מתמדת בידע סביב עבודה עם אותם מודלי שפה. צפויים להתפתח תפקידים חדשים או תחומי אחריות חדשים שיתווספו למקצועות קיימים, מהנדסת פרומפטים (Prompt Engineering) ועד יישום תהליכי Governance על תשובות המודל וניהול ה- Data שהמודלים מייצרים. מדי יום מפורסמים מחקרים חדשים  ששופכים אור חדש על תהליכי אימון מודלים ועל טכנולוגיית ה-GenAI. חברות וארגונים ששוקלים ליישם פתרונות מבוססים על GenAI – חשוב להיות מודעים לכך, ולהתייעץ עם אנשי מקצוע המומחים לתחום. לדוגמה, שני מחקרים חשובים שהתפרסמו לאחרונה, האחד עוסק בשינוי ההתנהגות של ChatGPT ומתאר  כיצד איכות התוצרים שלו ירדה בכ-35% בחודשים האחרונים. והשני סוקר תופעה, הנקראת Model Autophagy Disorder (בקיצור MAD), המתקיימת כאשר מודל  GenAI עובר אימון על מידע סינתטי. מחקרים אלה מדגישים את החשיבות של ביסוס מודלים ויישומים על מידע נקי ואיכותי כבסיס לאיכות המודל והיישום.

יישום של מודלי GenAI זאת לא ארוחה בפיתה אלא סעודה מלאה בת חמש מנות. יש עוד הרבה ללמוד ולגלות והתחום מתפתח מדי יום בקצב מסחרר. ארגונים שרוצים  לשלב יכולות של GenAI בארגון צריכים להיות מודעים לכך, ולעשות תהליכים כאלה בליווי אנשי מקצוע בעלי ידע מעמיק אשר יכולים להזניק את הארגון קדימה באופן בטוח ואחראי.