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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. בוחרים איך הציון יחושב

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

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

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

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

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

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

4. החלטה איפה להריץ את המעריך

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

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

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

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

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

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

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

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

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

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