צוות מחקר באוניברסיטת אילינוי אורבנה-שמפיין (UIUC) גילה כי יותר ממחצית מהתיוגים (annotations) במדד ה-BIRD Text-to-SQL הנפוץ הם שגויים, מה שמעלה סימני שאלה לגבי משמעות מדדי הדיוק שכל כך הרבה מפתחים מסתמכים עליהם.
למה המדד חשוב
BIRD הוא הסטנדרט דה-פקטו למדידת היכולת של מודל להפוך שאלה בשפה טבעית לשאילתת SQL. מאמרים, דפי מוצר ומבחני קבלה מצטטים ציוני BIRD. אם שאילתות ה-"gold" SQL שמגדירות את הנכונות פגומות, מודל שכותב שאילתה טובה יותר עלול להיענש, בעוד שמודל שמעתיק את תשובת ה-"gold" השגויה עלול לקבל פרס.
כיצד נחשף שיעור השגיאות
צוות ה-UIUC בחן 238 כשלים מתוך ה-BIRD-dev split. במקום לנחש מדוע כל פלט של מודל סומן כשגוי, הם תייגו ידנית כל אי-התאמה בין ה-SQL שנוצר על ידי המודל לבין ייחוס ה-"gold". הביקורת שלהם מצאה כי ב-52.8% מהמקרים קיימת שגיאת תיוג — SQL שגוי, סכימה לא תואמת, או אפילו שאלה בשפה טבעית לא תקינה.
דפוס אחד היווה 19% מהטעויות המסומנות: המודל השתמש ב-DISTINCT בעוד ששאילתת ה-"gold" לא השתמשה בו. דמיינו משתמש שמבקש את מספר המטופלים עם תוצאות מעבדה לא תקינות. תשובת ה-"gold" סופרת שורות באמצעות COUNT(ID). אם למטופל בודד יש חמש תוצאות מעבדה לא תקינות, שאילתת ה-"gold" תדווח על חמש במקום על אחת. ה-COUNT(DISTINCT ID) של המודל סופר כל מטופל פעם אחת בצורה נכונה. במקרים אלו, המדד מתעד שגיאת מודל למרות שהתשובה של המודל תואמת טוב יותר את הסמנטיקה המיועדת.
השפעה בעולם האמיתי על פיתוח מודלים
מפתחים מגיבים לעיתים קרובות לציוני BIRD נמוכים על ידי כוונון פרומפטים, הוספת אילוצים כמו "אל תשתמש ב-DISTINCT", או אימון מחדש על נתוני המדד. התאמות אלו יכולות להעלות את הציון המדווח, וליצור אשליה של התקדמות. הניתוח של UIUC מראה כי "שיפור" זה עשוי להיות פשוט overfitting למפתח התשובות השגוי, מה שעלול לפגוע בביצועים במסדי נתונים אמיתיים שבהם נדרשת הלוגיקה המתוקנת.
החוקרים הדגימו תרחיש הפוך. לאחר ניתוח של שאילתות המודל וה-"gold", הם זיהו שבעה מקרים שבהם המודל מיזג בטעות שתי עמודות נפרדות לאחת. ה-SQL של ה-"gold" היה נכון במקרים אלו. על ידי התמקדות רק בשגיאות אמיתיות אלו באמצעות פרומפט משופר, הם העלו את ביצועי המודל מבלי לנפח את ציון המדד.
משמעות הממצאים עבור בעלי עניין
- חוקרים: טענות לפרסום המבוססות על ציוני BIRD זקוקות להסתייגות לגבי איכות התיוג. השוואות בין מאמרים עשויות לשקף סובלנות שונה לרעש במדד ולא התקדמות מתודולוגית אמיתית.
- צוותי מוצר: הסתמכות על BIRD כמדד היחיד למוכנות לשחרור כרוכה בסיכון של שחרור מודלים שלמדו לשחזר שאילתות פגומות. בדיקות בעולם האמיתי על סכימות קנייניות הופכות לחיוניות.
- מנהלי מדדים (Benchmark curators): שיעור השגיאות הגבוה מרמז כי בדיקה שיטתית כבר מאוחרת מדי. ניקוי סט ה-"gold" או אספקת חלוקה (split) משנית "מאומתת" עשויים להחזיר את האמון.
תהליך ביקורת מעשי
צוות UIUC מציע תהליך קל שניתן ליישם על כל מדד Text-to-SQL:
- נתח (Parse) הן את שאילתות ה-SQL שנוצרו על ידי המודל והן את שאילתות ה-"gold" לעצי תחביר מופשטים (abstract syntax trees).
- יישר (Align) את המבנים כדי לחשוף הבדלים בעמודות נבחרות, מסננים, הצטרפויות (joins) ופונקציות אגרגציה.
- תייג (Tag) כל הבדל (למשל, עמודה נוספת, מסנן חסר, אגרגציה שגויה).
- סכם (Summarize) את התיוגים בהיסטוגרמה כדי לזהות קטגוריות שגיאות דומיננטיות.
- אמת (Validate) את שאילתת ה-"gold" עבור כל תיוג בתדירות גבוהה לפני השימוש בה כיעד להנדסת פרומפטים.
על ידי התמקדות בשיפור פרומפטים רק במקרים שבהם תשובת ה-"gold" היא ללא ספק נכונה, מפתחים יכולים להימנע מהמלכודת של "אופטימיזציה למדד שבור".
שורה תחתונה
מדד שמסמן בטעות יותר ממחצית מהדוגמאות שלו אינו יכול לשמש כסרגל מדידה אמין. מחקר ה-UIUC מראה שרבים מה"טעויות" שמסומנות על ידי BIRD הן למעשה הצלחות של המודל, בעוד שגיאות אמיתיות מסתתרות מאחורי תשובות "gold" נכונות. ביקורת על סט ה-"gold", שיפור צינורות ההערכה (evaluation pipelines) והתייחסות לציוני המדד כאל חלק אחד מאסטרטגיית אימות רחבה יותר הם הדרכים היחידות להבטיח ששיפורים על הנייר יתורגמו לאמינות בעולם האמיתי.