כימות יעד האופטימיזציה

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

1. מה הערך שהמספר הזה מייצג?

2. איך המערכת מחשבת את זה?

3. איפה מתבצע החישוב?

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

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

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

השלבים העיקריים לכימות היעד

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

1. להציג את היעד כציון יחיד שעולה ככל שהפתרונות משתפרים

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

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

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

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

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

2. בחירת אופן חישוב הציון

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

שיטת מדידה	כדאי להשתמש בו כשהיעד הוא…	איך הציון מחושב	מה נדרש כדי להפעיל את האפליקציה
חישוב ישיר	כמות שאפשר לחשב בצורה סגורה מהפלט של המועמד באמצעות לוגיקה עסקית או לוגיקה של מוצר	המעריך מריץ את המועמד ומחיל נוסחה (סכום, יחס, ספירה, עלות)	תהליך משלו של הבקר – ללא תשתית נוספת
בדיקת ביצועים או עומס	זמן הריצה, קצב העברת הנתונים או הזיכרון של קוד המועמד עצמו	מריצים את המועמד על חומרה מייצגת ומודדים אותו. קודם כל בודקים את הנכונות	חומרת היעד (GPU,‏ TPU או CPU); חימום ושימוש בשיטת best-of-N כדי לצמצם את רעשי התזמון
סימולציה או תחליף דטרמיניסטיים	יקר או רועש מדי למדידה ישירה, אבל יש נתונים מהימנים שמובילים לפעולת היעד או שחזור של תנאים אמיתיים	חישוב פרוקסי דטרמיניסטי, או הפעלה מחדש של תרחישי הפעלה קבועים ומוגדרים מראש	כל סביבה; אפשרות לשחזור מלא עם זרעים קבועים
אימות מחוץ למדגם	איכות המודל או פייפליין הנתונים שהמועמד יוצר	מאמנים/מתאימים את המועמד, ואז נותנים לו ציון על נתונים שהוחזקו או שנוצרו לאחרונה	חבילת הכלים לאימון ולהערכה; פיצול קפדני בין אימון לאימות; אימות מחדש של המודלים המנצחים בקבוצת הנתונים שהוחרגה

מידע נוסף זמין בהודעה על AlphaEvolve בבלוג של Google Cloud .

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

3. טיפול בכמה יעדים ומגבלות

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

1. דפוסי הטמעה של כלי ההערכה

2. אופטימיזציה של כמה יעדים

שילוב סקלרי (הפשוט ביותר – מומלץ להתחיל איתו): משנים את קנה המידה של כל מדד לטווח השוואה, הופכים את הסימן של כל מדד שרוצים למזער ואז מחברים אותם: score = w1*A - w2*L - w3*M.

עדיף להשתמש בסכומים מצטברים ולא ביחסים כמו A/(L⋅M), שהם לא יציבים מבחינה מספרית.

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

```JSON
{
  "scores": [
    {"metric": "accuracy", "score": 0.95},
    {"metric": "latency_ms", "score": -120.0}
  ]
}
```

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

1. מומלץ להשתמש ב-3 עד 5 מדדים: אם משתמשים ביותר מדי מדדים, דומיננטיות פרטו מתנוונת כמעט בכל תוכנית, וחיפוש המדדים הופך ללא יעיל. לצבור מדדים או להשמיט מדדים מעבר לסף הזה.

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

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

4. החלטה על המיקום שבו הבוחן יפעל

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

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

התאמה בין סביבת ההפעלה לשיטת המדידה

חישוב ישיר או חלופי: התהליך של הבקר עצמו, או קונטיינר יחיד של Cloud Run.

בדיקת ביצועים או בדיקת עומס: חומרת היעד, כמו צומת GPU או TPU ב-GKE, חומרה בהתאמה אישית או חומרה מקומית משלכם, או כלי של צד שלישי או של ספק תוכנה עצמאי (ISV) (לדוגמה, סימולטור EDA או Verilog).

אימות מחוץ לדגימה או משימות כבדות: מערך האימון שלכם התפרס על פני Cloud Run או GKE, או הועבר ל-Google Cloud batch באמצעות Cluster Toolkit לעומסי עבודה גדולים של HPC או מאיצים.

שתי המגבלות חלות בלי קשר לסביבה

כדאי להשתדל שכל הערכה תימשך כ-10 דקות או פחות, כדי שהלולאה האבולוציונית תמשיך לנוע. למטרות יקרות, כדאי להשתמש בהערכה מדורגת כדי לבדוק כל מועמד, ולהריץ את ההערכה המלאה רק למועמדים מבטיחים.

אתם הבעלים של הרשת, האבטחה ואמצעי בקרת הגישה של המעריך. ‫AlphaEvolve לא פורס או מנהל את המעריך, ב- Google Cloud או במקומות אחרים.

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