גישות לניקוד

כדי לקבוע איך לדרג, לנרמל ולהעניש את רשומות הקוד של המועמדים במסגרת רתמת ההערכה, כדאי ליישם את העקרונות האדריכליים הבאים.

השגת יעדים באופן ישיר

‫AlphaEvolve מבצעת רק חיפושים למקסימיזציה, ומתייחסת לכל יעד אופטימיזציה כמשימת טיפוס הרים. כדי לצמצם מדד כמו זמן אחזור או שיעורי שגיאות, צריך להפוך את הערך המחושב הסופי לשלילי: score = -latency_ms # AE maximizes -> minimizes latency.

שמירה על מונוטוניות פונקציה קפדנית

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

מדדים מפורטים וספציפיים

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

תגמול על הצלחה חלקית במקום על תוצאות דלילות

תגמלו על הצלחה חלקית במקום להסתמך רק על תוצאות סופיות או בינאריות. תמיד עדיף להשתמש באות דירוג צפוף על פני אות דירוג דליל.

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

כדי לשמור על כיוון החיפוש:

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

• התאמה מדויקת של המשקלים: חשוב לוודא שהאות המשני תואם באופן מונוטוני ליעד האמיתי, ושהמשקל שלו נמוך יותר באופן בטוח. אם הוא לא משוקלל כמו שצריך, AlphaEvolve תבצע אופטימיזציה של מדד ה-proxy על חשבון היעד בפועל (מה שיגרום ל-reward hack).

לדוגמה, אפשר ליצור פונקציית מטרה סקלרית באמצעות נקודות כשובר שוויון לוגי: use score = matches_won + w * (points_scored / points_possible).

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

מתחילים עם יעד אחד

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

שינוי קנה המידה ונרמול לפני השילוב

כדי למנוע הטיה באופטימיזציה, חשוב להקפיד על איזון קפדני של קנה המידה במדדים:

• שינוי קנה המידה בטווחים שונים: נרמול המדדים לטווחים שניתן להשוות ביניהם לפני שמשלבים אותם. שילוב של ציונים מוגבלים (בטווח שבין 0 ל-1) וציונים לא מוגבלים (בטווח שבין 0 ל-infinity) בלי שינוי קנה מידה מפורש גורם למדד הלא מוגבל לשלוט בנוף הכושר.

• עדיף להשתמש במבנים של חיבור ולא של כפל: יעדים של כפל יכולים להיות רגישים מאוד לשינויים קלים במכנה, וזה פוגע בדיוק וביציבות של החיפוש. במקום זאת, צריך להטמיע סכומים משוקללים מצטברים: w1*A - w2*L - w3*M. הפורמט הזה מאפשר לשנות בקלות את המשקל של כל פרמטר ביצועים.

• נרמול ביחס לערכים הראשוניים: כדי למנוע מהבדלים בקנה המידה להטות את נתיב החיפוש, מחלקים כל מדד בערך הבסיס הראשוני שלו, כך שכל המדדים מתחילים בערך בסיס של 1.0 לפני שמחילים משקלים ומשלבים אותם.

הגדלת ההבדלים המספריים המינימליים

יכול להיות שהבדלים קטנים בציונים המספריים לא יספקו אות אופטימיזציה שימושי למודל ה-LLM הבסיסי. אם מועמד חזק מקבל ציון 1e-7 ומועמד חלש יותר מקבל ציון 1e-8, יכול להיות שה-LLM לא יבחין ביניהם באופן משמעותי כשהוא בודק את ההקשר. משנים את קנה המידה של הציונים הסופיים לטווח ברור וקריא לאנשים (כמו 0 עד 100), כדי שהשיפורים המצטברים בקוד יופיעו באופן מספרי בהנחיה ליצירת הקוד.