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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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או בכל מקום אחר.

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