גישות לניקוד

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

אופטימיזציה ישירה של היעדים

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

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

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

לספק מדדים מפורטים וגרנולריים

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

עדיף לתגמל הצלחה חלקית מאשר תוצאות דלילות

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

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

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

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

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

לדוגמה, אפשר ליצור פונקציית מטרה סקלרית באמצעות נקודות כשובר שוויון לוגי: 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 לפני שמחילים משקלים ומשלבים אותם.

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

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