המצגת המסכמת מראה מה הצוות השיג, איך העבודה נעשתה, ואילו ראיות תומכות במסקנות, כטיעון טכני ברור ולא כיומן.
היא צריכה לאפשר לקהל לענות על:
איזו בעיה נבחנה?
למה היא חשובה?
מה נבנה או נחקר?
אילו נתונים ושיטות שימשו?
אילו ניסויים בוצעו?
אילו תוצאות הושגו?
מה הצוות למד?
מה נותר לא פתור?
המצגת המסכמת אינה יומן כרונולוגי; היא טיעון טכני ברור הנתמך בראיות.
מה המצגת המסכמת חייבת לספק
שבעה חלקים, לכל אחד מה להציג, הדרישות, וממה להימנע.
1
הגדרת הפרויקט הסופית
מה להציג
תנו תיאור תמציתי ומזוקק של מקרה השימוש המניע, של הגדרת הבעיה, של הקלטים והפלטים, של המשתמשים המיועדים, של מטרת המערכת או המחקר המרכזית, ושל ההיקף הסופי. סקרו את הנתונים, המודלים, ה-pipeline והמדדים שנבחרו.
דרישות
השתמשו בהגדרה הסופית, לא בניסוח מההצעה. הקהל צריך להבין את הפרויקט בתוך הדקות הראשונות.
הימנעו מ
הקדשת זמן רב מדי לרקע
הצגת מטרות מיושנות מההצעה
הצגת פרטים טכניים לפני הבעיה
אמירות מעורפלות כמו ”רצינו לשפר את ה-AI“
2
הישגי הפרויקט ותרומותיו
מה להציג
נסחו בבירור מה הצוות השלים. הישגים אפשריים:
מאגר נתונים חדש
pipeline עיבוד שלם
מודל שאומן או כוונן
השוואה של כמה מודלים
פרוטוקול הערכה חדש
שיפור בביצועים
אב-טיפוס שהוטמע
אינטגרציה חדשה
תובנות טכניות מהניסויים
מגבלות שזוהו בשיטות קיימות
דרישות
הפרידו בין הישגים שהושלמו לבין עבודה עתידית, ותנו ראיה לכל טענה.
דוגמה. תרומה: מאגר נתונים ייעודי לתחום של 4,000 דגימות מתויגות. ראיה: פרוטוקול התיוג, הסכמה בין המתייגים, התפלגות הדגימות, וקישור למאגר.
הימנעו מ
מנייה של פעילויות במקום הישגים
הצגת נפח קוד כהישג
תיאור שימוש ב-API כחדשנות
הצגת רכיבים לא גמורים כאילו הושלמו
הגזמה בשיפורים זניחים
3
מתודולוגיה
מה להציג
הסבירו מה נעשה:
איסוף או ייצור נתונים
תיוג
עיבוד מקדים
חלוקת נתונים
בחירת מודל
אימון
כוונון עדין
פיתוח prompt
כוונון היפר-פרמטרים
הערכה
ניתוח שגיאות
אינטגרציה של המערכת
דרישות
פרטו במידה מספקת כדי שצוות אחר יוכל לשחזר, ונמקו את הבחירות המרכזיות:
למה המודל הזה?
למה חלוקת הנתונים הזו?
למה המדדים האלה?
אילו חלופות נבדקו?
איך נבחרו הפרמטרים?
איך נמנעה התאמת-יתר?
איך נמנעה דליפת נתונים?
הפרויקט חייב לכלול לפחות מודל אחד מאומן או מכוונן (fine-tuned), ולא רק zero-shot או few-shot.
הימנעו מ
הצגת קוד במקום הסבר המתודולוגיה
מנייה של כלים בלי לציין את תפקידם
השמטת ניסויים שנכשלו
שינוי תנאי ההערכה בין מודלים
הצגת החלטות ידניות לא מתועדות
4
תוצאות הניסויים
מה להציג
הציגו תוצאות בטבלאות, גרפים ודוגמאות ברורים:
תוצאות בסיס (baseline)
תוצאות המודל המרכזי
מודלים חלופיים
מחקרי אבלציה במקומות הרלוונטיים
ניתוח לפי מחלקה או לפי תרחיש
מדידות איכות, זמן תגובה, או עלות
ניתוח שגיאות
דרישות
השוו את כל השיטות על אותו מאגר נתונים, אותה חלוקת מבחן, אותם מדדים, ותנאים ברי-השוואה. סמנו בבירור את התוצאה הטובה ביותר, את הבסיס, את הפתרון המרכזי המוצע, ואת השונות הסטטיסטית בין הריצות. כל גרף וטבלה צריכים כותרת, תוויות קריאות, שמות צירים, יחידות, מקראות, דיוק בעל משמעות, וכיתוב ברור.
הימנעו מ
צילומי מסך של פלט גולמי מ-notebook
טבלאות בלתי קריאות
גרפים ללא תוויות צירים
השוואת מספרים מתנאים שונים
הצגת הניסוי הטוב ביותר בלבד
דוגמאות איכותניות בלי תוצאות כמותיות
5
פרשנות וניתוח שגיאות
מה להציג
הסבירו מה המשמעות של התוצאות:
למה השיטה הטובה ביותר גברה על האחרות
היכן היא עדיין נכשלת
אילו מחלקות או תרחישים קשים
האם השיפורים בעלי משמעות מעשית
האם התוצאות תומכות בהשערה המקורית
אילו הנחות היו שגויות
דרישות
קשרו את התוצאות למטרות הפרויקט; אל תסתפקו בהקראת הטבלה. הסבירו סיבות סבירות מתוך מאפייני הנתונים, ארכיטקטורת המודל, הליך האימון, מורכבות התחום, איכות התוויות, או אילוצי המערכת.
הימנעו מ
התייחסות למתאם כאל סיבתיות
קריאה לכל שיפור ”מובהק“
תליית כל השגיאות בחוסר נתונים
התעלמות מתוצאות בלתי צפויות או שליליות
הסקת מסקנות שהניסויים אינם תומכים בהן
6
מסקנה ועבודה עתידית
מה להציג
ענו על:
האם המטרה הושגה?
אילו תוצאות הן החזקות ביותר?
מה הצוות למד?
מה הייתם עושים אחרת?
אילו מגבלות נותרו?
מה כדאי לחקור בהמשך?
דרישות
בססו את המסקנה על התוצאות שהוצגו, ונסחו את העבודה העתידית באופן ספציפי.
חלש: ”להשתמש בעוד נתונים ולשפר את המודל.“ חזק: ”לאסוף לפחות 500 דוגמאות משתי המחלקות התת-מיוצגות ולהעריך כוונון עדין מאוזן-מחלקות באמצעות macro-F1.“
הימנעו מ
הצגת תוצאות חדשות במסקנה
חזרה על כל המצגת
טענות לא נתמכות
הצגת כל משימה לא גמורה כמחקר עתידי
7
הוכחת המאמץ בפרויקט
מה להציג
הראו את העבודה שמאחורי התוצאות:
סקירת עבודות קודמות
ניקוי ואימות נתונים
השוואת כמה מודלים
כוונון פרמטרים
ניפוי באגים ב-pipeline
ניתוח שגיאות
עיצוב מחדש של רכיבים חלשים
הרצה חוזרת של ניסויים מבוקרים
שיפור יכולת השחזור
דרישות
הוכיחו מאמץ באמצעות ראיות טכניות, לא באמצעות שעות עבודה. הראו כמה מחזורים של מימוש, הערכה, ניתוח שגיאות, שיפור, והערכה מחדש.
הימנעו מ
שימוש בשורות קוד כראיה
הדגשת עיצוב הממשק על פני עבודה טכנית
הצגת קריאות API חוזרות כניסוי
בלבול בין קושי המימוש לבין עומק טכני
הציגו דוגמאות קונקרטיות של הנתונים והמודל
הפכו את הראיות לקונקרטיות: דוגמאות נתונים (תמונות או טקסט), כיצד הנתונים נוצרו, שלבי המודל, קלט ופלט אמיתיים של המודל, וכמה מקרי שגיאה ברורים.
דוגמאות נתונים (תמונות או טקסט)
תמונה, צילום חזה 224×224 · תווית: דלקת ריאות
"App crashes when I upload a PDF over 10 MB."
טקסט, פנייה לתמיכה → תווית: באג
כיצד הנתונים נוצרים או עוברים טרנספורמציה
"Great pizza, fast delivery."→"gr8 pizza, delivery was not fast"
"The wifi keeps dropping every few minutes."→{ label: network, conf: 0.92 }
"סכם את הרשומה הקלינית: ..."→"כאב חזה לסירוגין במשך יומיים ..."
תמונת קלט→2 תיבות: car 0.94, pedestrian 0.81
שגיאות המודל, עם הסיבה הסבירה
חזה spam, האמת לא spam: המודל נתן משקל יתר לביטוי שיווקי בתוך ציטוט בתשובה.
זיהה מכונית אחת, פיספס אחת בגשם כבד: יחס אות-לרעש נמוך טשטש את הקצוות.
יצר מינון שאינו מופיע ברשומת המקור: האחזור החזיר קטע לא רלוונטי.
רשימת תיוג להגשה
זוהי בדיקה סופית מהירה, לא תחליף למדריך המלא. קראו קודם את הדרישות המלאות שלמעלה, ואז השתמשו בעשרת הפריטים האלה כדי לוודא שהחלקים המרכזיים נמצאים במקומם לפני ההגשה.
הגדרת הפרויקט הסופית תמציתית וברורה בתוך הדקות הראשונות.
ההישגים מופרדים מעבודה עתידית, ולכל אחד יש ראיה.
המתודולוגיה מפורטת דיה לשחזור, עם נימוק לבחירות.
מושווים לפחות שלושה מודלים, כולל מודל מאומן או מכוונן ווריאנטים של zero-shot או few-shot.
כל השיטות מושוות על אותם נתונים, חלוקה, מדדים ותנאים.
התוצאות בטבלאות ובגרפים ברורים עם כותרות (מסומנים הטוב ביותר, הבייסליין והשונות).
הפרשנות מקשרת את התוצאות למטרות ומסבירה סיבות סבירות.
