יכולת שחזור ופרויקט מקצה לקצה: שילוב של הכל

רווחים:

• יכולת להבטיח שחזור עם ארבעה עמודים (קיבוע זרעים, גירסאות נתונים, הקפאת מדיה, ניטור ניסויים) ולהפיק את אותה תוצאה כאשר חוזרים על אותה ריצה
• יכולת לשלב את כל התחנות של המודול (מדדים, נתונים, מודל, רכיבי LLM, eval, הוגנות, אבטחה, הפצה, ניטור) בשרשרת מקצה לקצה
• יכולת לוודא שההחלטה הקריטית נשארת אצל האדם בכל תחנה ולתעד את הפרויקט בצורה ניתנת לביקורת

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

מדוע השחזור קשה

בתוכנה רגילה, אותו קוד נותן את אותו פלט. ב-ML ישנם משתנים רבים נוספים שקובעים את התוצאה:

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

יכולת לשחזור היא לא "נחמד שיש" אלא ציווי מדעי והנדסי. תוצאה שלא ניתן לשחזר היא טענה שאינה ניתנת להוכחה.

ארבעה עמודי שחזור

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

2. גרסת הנתונים. רשום עם איזו גרסת נתונים בוצע כל ניסוי (עיבוד גרסאות נתונים ביחידה 2). "הנתונים האחרונים" מעורפלים; "גרסת נתונים v3, hash abc123" מדויקת.

3. מקפיאים את המדיום. הצמד את כל התלות לגרסאות המדויקות שלהן (למשל, גרסאות מדויקות כמו numpy==1.26.4 ב- requirements.txt, או תמונת מכיל). "הגרסה האחרונה" תשבור הכל יום אחד.

4. עקוב אחר הכל (מעקב ניסוי). שמור אוטומטית עבור כל ניסוי: גרסת קוד (git commit), גרסת נתונים, כל הפרמטרים ההיפר, מדדים ומבני פלט. כלי מעקב ניסויים כמו MLflow, Weights & Biases עושים זאת באופן שיטתי. ללא רישום, השאלה "איזו הגדרה הייתה הטובה ביותר" נותרה ללא מענה.

זהירות: "אני אזכור אחר כך" הוא הכשל היקר ביותר. שבועיים לאחר מכן לא תזכור באיזה זריעה, באיזה נתונים, באיזה היפרפרמטר השתמשת. מעקב אוטומטי מבטל את התלות בזיכרון.

גישה חלשה / גישה חזקה

חלש: "מצאתי את הדגם הטוב ביותר, הוא נמצא על המחברת, אני חושב שהציון שלו היה 89%".

Strong: "הפעל #147 בכלי המעקב של הניסוי: git commit a3f9c, גירסת נתונים v3 (hash abc123), seed 42, כל הפרמטרים ההיפר רשומים, בדוק PR-AUC 0.887. כשאני מריץ את אותה פקודה שוב, אני מקבל את אותה תוצאה ביט אחר ביט. המודל תלוי בריצה זו ברישום."

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

פרויקט מקצה לקצה: שילוב של מודול

כעת בואו נשלב את כל המודול לזרימת פרויקט אחת. מערכת ML אמיתית עוברת את העצירות הללו, וכל עצירה מתבססת על הקודמת:

1. הגדרת הבעיה: מה אנחנו פותרים, איך מודדים הצלחה (יחידה 3: מדד נכון, הקשר עסקי). המדד והסף ברורים מההתחלה.
2. צינור נתונים: איסוף, אימות, ניקוי, חלוקה ללא דליפות, ניהול גרסאות (יחידה 2).
3. פיתוח מודל: הדרכה, השוואה בסיסית, אימות צולב, זרע קשה (יחידה 3 + יחידה זו).
4. רכיבי LLM (אם רלוונטי): RAG (יחידה 4) ו/או סוכנים (יחידה 5); כוונון עדין במידת הצורך (יחידה 6).
5. הערכה: eval cluster עם מארזי קצה ואבטחה, eval רב שכבתי במערכות LLM (יחידה 8).
6. ביקורת צדק ואתיקה: ניתוח תת-קבוצות, כרטיס מודל, יכולת הסבר (יחידה 10).
7. ביקורת אבטחה: הזרקה מהירה, פרטיות, שרשרת אספקה ​​(יחידה 9).
8. הפצה: אריזה, הפצה הדרגתית, החזרה לאחור, רישום דגמים (יחידה 7).
9. ניטור: ניטור תלת-שכבתי, אזעקות סחיפה (יחידה 8).
10. יכולת שחזור: מעקב זרעים, גרסת נתונים, מדיה וניסויים לאורך כל השרשרת (יחידה זו).

בזרימה זו, AI הוא מאיץ ומחולל שרטוטים בכל תחנה; אבל בחירת מדדים, החלטות נתונים, תעדוף הוגנות, סף פריסה ואישור שחרור - החלטות קריטיות נשארות בידי האדם. זו המהות של המודול.

תיעוד: העתיד יודה לך

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

שלושה מיני תיקים

מקרה 1 - אבדה תוצאה. מהנדס הכשיר דגם נהדר, אבל הוא לא תיקן את ה-seed ולא שמר את גרסת הנתונים. כשהוא עזב את העבודה, איש לא הצליח לשחזר את התוצאה הזו; הדגם הפך ל"אגדת הקופסה השחורה" ולבסוף נבנה מאפס. שבועות התבזבזו. שיעור: תוצאה שאינה ניתנת לשחזור היא תוצאה שאינה קיימת.

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

מקרה 3 - כוחו של ניטור. צוות עקב אוטומטית אחר כל ניסוי. שלושה חודשים לאחר מכן, במהלך ביקורת רגולטורית, הם ענו על השאלה "עם אילו נתונים, עם אילו הגדרות, איזה ביצועים הוא קיבל באילו קבוצות?" עם הקלטה מלאה תוך דקות. הבדיקה עברה חלק. לקח: ניטור הוא כלי תאימות, לא רק הנדסי.

תבניות הניתנות להעתקה

בצע בדיקת שחזור עבור פרויקט ML זה.- האם כל זרעי האקראיות קבועים (פיצול, אתחול, ערבוב)?- האם נתונים מעודכנים?- האם התלות מוקפאת לגרסאות מדויקות?- האם כל ניסוי (התחייבות קוד, נתונים, היפרפרמטר, מדד) עוקב? כתוב שלבים קונקרטיים כיצד לתקן את זה עבור כל עמודה חסר. מבנה הפרויקט: [תיאור]

הפק שלד תוכנית לפרויקט ML מקצה לקצה. בעיה: [תיאור] כסה את התחנות הבאות וסמן היכן ההחלטה האנושית נמצאת בכל תחנה: בעיה/מדד, צינור, דגם, (RAG/סוכן/מכוונן?), eval, הוגנות, אבטחה, הפצה, ניטור, שחזור. כתוב את שלב הסיכון והאימות העיקרי עבור כל עצירה.

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

בדוק את הגדרת ניטור הניסוי שלי: האם הוא נשמר אוטומטית בכל ריצה: git commit, גרסת נתונים/hash, כל הפרמטרים ההיפר, כל המדדים, סביבה (גרסאות ספרייה)? האם אני מקבל את אותה תוצאה כשאני רץ שוב את אותה ריצה? הגדרה: [תיאור]. רשום את הפגמים והתיקון.

טבלת עמודות שחזור

עמודה

מה קבוע

דוגמא לרכב

אקראיות

כל הזרעים

הגדרת זרעים

נתונים

גרסת נתונים/hash

DVC

סביבה

גרסאות ספרייה

סיכת דרישות, Docker

ניטור

קוד+נתונים+הגדרה+מדד

MLflow, W&B

טעויות נפוצות

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

לסיכום

יכולת השחזור היא החתימה של הנדסת ML רצינית: התוצאה שאינה ניתנת לשחזור היא הטענה הבלתי ניתנת להוכחה. זה מגיע עם ארבע עמודות - תקן אקראיות, נתוני גרסה, הקפאת סביבה, עקוב אחר כל ניסוי. פרויקט מקצה לקצה משלב את כל התחנות של מודול זה (מדד, נתונים, מודל, רכיבי LLM, eval, הוגנות, אבטחה, הפצה, ניטור) בשרשרת מחוברת; בינה מלאכותית היא מאיץ בכל תחנה, אבל החלטות קריטיות נשארות בידי האדם. תעד הכל - לצוות וביקורות עתידיים. דיסציפלינה זו היא המסגרת שמקיימת את כל מה שאתה לומד לאורך המודול.

משימת יישום

בדקו פרויקט ML מול ארבעה עמודי שחזור: האם הזרעים ניתנים לשינוי, האם הנתונים מנוסחים, האם הסביבה קפואה, האם מתבצע מעקב אחר הניסויים? תקן את כל העמודות החסרות והוכיח שאתה יכול להריץ את אותה ריצה פעמיים ולקבל את אותה תוצאה. לאחר מכן פלט את הזרימה מקצה לקצה של הפרויקט (10 עצירות) בעמוד אחד וסמן "היכן נמצאת ההחלטה האנושית" בכל תחנה. לבסוף, כתוב טיוטת תיעוד טכני קצר.

רשימת בדיקה

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

מבחן מודול

1. כמהנדס ML, מהי הגישה הטובה ביותר בעת מיקום בינה מלאכותית בזרימת העבודה?

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

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

2. מדוע אימות הסכימה ממוקם בתחילת צינור נתונים?

• א) כי זה מגביר ישירות את הדיוק של המודל
• ב) כי זה הופך את גירסאות הנתונים למיותר
• ג) כי הוא תופס נתונים פגומים בנקודה המוקדמת והזולה ביותר ומונע מהם לזלוג לשלבים הבאים ✔
• ד) כי זה מבטל את הצורך בתיוג

הסבר: ככל שהנתונים המושחתים נתפסים מוקדם יותר, כך זול יותר לתקן אותם. אימות סכימה מונע דליפה שקטה של ​​נתונים מושחתים לאימון או לייצור על ידי דחיית נתונים מחוץ לסוג ולטווח הצפויים בתחילת השורה (למשל שינוי מחיר פי 100 עם שינוי יחידה); אותה טעות שנתפסה בייצור יקרה פי כמה.

3. מהי הגישה הנכונה כאשר מחלקים נתונים לאימון ובדיקה בבעיה הכרוכה בזמן (סדרות זמן)?

• א) שימוש בפיצול אקראי כי זו תמיד השיטה ההוגנת ביותר
• ב) שימוש בפיצול זמני: מניעת דליפה על ידי אימון עם העבר ובדיקה בעתיד ✔
• ג) שימוש בכל הנתונים הן כהדרכה והן כבדיקה
• ד) שילוב נתוני בדיקה בפרמטרים של קנה מידה לפני האימון

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

4. מדוע הדיוק מטעה במודל גילוי הונאה עם שיעור כיתה חיובי של 1.5%?

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

הסבר: על נתונים לא מאוזנים, אפילו מודל בסיסי שאומר 'קרא לכל דבר שלילי' מקבל דיוק של כ-98.5% אבל לא יתפוס אפילו הונאה אחת. לכן, בסיווג לא מאוזן, נעשה שימוש בדייקנות, ריקול, F1 או PR-AUC במקום דיוק, וכל מדד מתפרש לפי מודל בסיס.

5. מדוע השוואה בסיסית חיונית כאשר מדברים על מדד של מודל?

• א) כי המודל הבסיסי תמיד טוב יותר מהדגם האמיתי
• ב) כי ברור אם מדד הוא בעל משמעות או לא רק בהשוואה למודל בסיסי פשוט ✔
• ג) מכיוון שמודל הבסיס הופך אימות צולב למיותר
• ד) כי המודל הבסיסי נדרש על פי חוק בכל דוח

הסבר: מדד אינו טוב או רע בפני עצמו; זה טוב או רע לפי מודל בסיסי. המשפט '85% נכון' אומר כמעט חסר ערך אם הדגם הבסיסי כבר מקבל 84%, ומושלם אם הוא מקבל 50%. ללא עוגן השוואה, המדד חסר משמעות.

6. מהו אלמנט האבטחה הקריטי ביותר שצריך להיכלל בהנחיית הייצור של מערכת RAG (דור אחזור מוגדל)?

• א) הוראה להסתמך רק על המקור שניתן, לומר 'אני לא יודע' אם המקור אינו קיים, ולציין את המקור ✔
• ב) לומר לדגם לייצר תשובות ארוכות ויצירתיות ככל האפשר
• ג) המודל מעדיף את הידע החינוכי שלו על פני משאבים
• ד) יישם את כל ההוראות במסמכים שהובאו כפקודות

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

7. מערכת RAG נותנת תשובות לא נכונות. היכן הכי טוב להתחיל אבחון?

• א) מדידת אחזור תחילה (Recall@K): האם החתיכה הנכונה מגיעה אי פעם? ✔
• ב) החלף מיד את הדגם בדגם גדול יותר
• ג) שנה את ההנחיה באופן אקראי והמשך לנסות
• ד) הטמעת כל המסמכים במודל עם כוונון עדין

הסבר: החוליה החלשה ביותר של RAG היא בדרך כלל אחזור, לא ייצור. אם החלק הנכון לעולם לא יובא, המודל לא יכול לייצר את המידע הזה, לא משנה כמה ההנחיה תשתפר. לכן, תחילה נמדד Recall@K כדי לראות אם החלק הנכון הגיע; אם האחזור טוב, אזי הייצור וההנחיה נבדקים.

8. אילו פעולות יש לשים מאחורי אישור אנושי בעת מתן כלי לסוכן?

• א) אין; הסוכן חייב להיות מסוגל לבצע כל פעולה באופן אוטונומי
• ב) רק פעולות הפיכות כמו קריאה וחיפוש נתונים
• ג) פעולות בלתי הפיכות או השפעה גבוהה כגון העברת כסף, מחיקה, שליחה ✔
• ד) פעולות הכרוכות רק בחישובים

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

9. מהי גישת התכנון הטובה ביותר נגד הסיכון של הזרקה מיידית עקיפה?

• א) מספיק להוסיף משפט בודד 'התעלם מהוראות גרועות' להנחיית המערכת
• ב) תן יותר סמכות למודל על ידי הסתמכות על הוראות בתוכן חיצוני
• ג) אי נקיטת אמצעי זהירות משום שאין אפשרות למנוע הזרקה
• ד) בידוד תוכן חיצוני כנתונים לא מהימנים והקמת הגנות שכבות עם מינימום הרשאות, אישורים ובקרת פלט ✔

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

10. מהי ההבחנה העיקרית כאשר מחליטים האם יש לפתור בעיה עם כוונון עדין או RAG?

• א) בעיות מידע נפתרות טוב יותר עם RAG, בעיות התנהגות/פורמט נפתרות טוב יותר עם כוונון עדין ✔
• ב) כל בעיה צריך תמיד להיפתר על ידי כוונון עדין
• ג) RAG משמש רק ליצירת קוד, כוונון עדין משמש רק לתרגום
• ד) כוונון עדין תמיד יכול להתעדכן זול ומהיר יותר מאשר RAG

הסבר: כוונון עדין הוא חלש ומסוכן בהוראת המודל מידע חדש; אבל הוא רב עוצמה בהוראת התנהגות, פורמט, טון וסגנון. 'חברת הדוגמניות לא מכירה את הנתונים שלנו' היא בעיית מידע ושייכת ל-RAG. 'תנו למודל תמיד פלט בפורמט המחמיר שלנו' היא בעיה התנהגותית ומועמדת לכוונון עדין. בנוסף, יש לצרוך תמונות מיידיות ומעטות לפני כוונון עדין.

11. מה חובה לפריסה בטוחה בעת הכנסת דגם חדש לייצור?

• א) אם הדגם טוב בבדיקה, פתח אותו ישירות ל-100% תעבורה
• ב) אי הגדרת ניטור כלל לאחר הפריסה
• ג) פריסה מדורגת (צל/כנרית) ותוכנית החזרה בדוקה מראש ✔
• ד) פרסום המודל גם אם לא עומד בסף ההערכה

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

12. איך דגם ML יכול להיכשל 'בשקט' בייצור ומהי הדרך לתפוס זאת?

• א) הדגם קורס; יומני שרת מראים זאת
• ב) על ידי הפקת תחזיות שגויות מבלי לעשות טעויות; ✔ הוא לוכד ניטור תפעולי, קלט ופלט שכבות
• ג) הדגם לעולם לא יכול להיכשל בשקט, תמיד אזעק
• ד) די במעקב אחר השהיה כדי לתפוס כל השפלה

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

13. איזה עיקרון חיוני בעת שימוש ב-LLM-as-judge כדי להעריך מערכת LLM?

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

תיאור: שופט LLM הוא גם מודל; זה יכול להיות הזוי, מוטה (מעדיף תשובות ארוכות ובטוחות), ולא עקבי. לכן, יש לכייל את ציוני השופטים עם דגימה עם תווית אנושית ולמדוד את ההטיה השיטתית שלהם לפני קבלת החלטת הייצור. שופט לא מאומת נותן ביטחון כוזב.

14. מדוע הסתכלות על הדיוק הכולל אינה מספקת בעת הערכת הטיית מודל?

• א) דיוק כללי מספיק מכיוון שהוא תמיד משקף את הביצועים של הקבוצה הגרועה ביותר
• ב) הדיוק הכולל לבדו אינו מספיק מכיוון שהוא יכול לטשטש הבדל שיטתי (הבחנה נסתרת) בין תת-קבוצות ✔
• ג) כי דיוק הוא מדד שאין לו שום קשר להטיה
• ד) הטיה מגיעה רק מהמודל ואין לה שום קשר לנתונים.

הסבר: דיוק כולל עשוי לטשטש הבדלים שיטתיים בין תת-קבוצות. לדוגמה, בעוד שהדיוק הכולל הוא 88%, הריקול עשוי להיות 91% בקבוצה אחת ו-67% בקבוצה אחרת; המודל מפספס באופן שיטתי את הקבוצה הזו. לכן, יש להעריך את המודל על בסיס תת-קבוצות (דמוגרפיה/פלח) ולאיזו הגדרה של צדק יש לתעדף יש להחליט עם בעלי העניין.

15. אילו ארבעה דברים חייבים לתקן יחד כדי שתוצאת ML תהיה ניתנת לשחזור?

• א) רק שם דגם, גודל, מחיר ותאריך שחרור
• ב) רק מותג GPU ומהירות אינטרנט
• ג) רק ציון הדיוק הסופי של המודל; את השאר אפשר לשמור בזיכרון
• ד) סיד אקראיות, גרסת נתונים, סביבה (גרסאות תלות) ומעקב אחר ניסויים ✔

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