הגדרת מרחב החיפוש ומשתני ההחלטה

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

התהליך הזה כולל:

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

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

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

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

מבנה של תוכנית ראשונית

תוכנית ראשונית מורכבת משני סוגי בלוקים עיקריים שקובעים את גבולות החיפוש האבולוציוני:

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

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

   import numpy as np
   # Code to constrain the search space (Immutable)
   def def_preprocessing():
       """Feature engineering and preprocessing."""
       pass
   
   # EVOLVE-BLOCK-START
   # Mutable block: Provides degrees of freedom for AlphaEvolve to optimize
   def model_tuning():
       """Model tuning function: parametrized to take features."""
       pass
   # EVOLVE-BLOCK-END
   
   # Boilerplate code that does not impact solution performance (Immutable)
   def batch_predictions():
       """Inference function: batch predictions to test performance."""
       pass
   

כללי העיצוב של EVOLVE-BLOCK כוללים:

• שורות נפרדות: תגי ההערה EVOLVE-BLOCK-START ו-EVOLVE-BLOCK-END צריכים להופיע בשורות נפרדות. אל תמקמו קוד או תוכן אחר באותה שורה של סמן, חוץ מרווחים לבנים ותחיליות של הערות (כמו # או //).
• נדרש קוד שניתן לעריכה: האזור שבין סמן ההתחלה לסמן הסיום חייב להכיל לפחות שורה אחת של קוד שניתן לעריכה. בלוקים שמכילים רק רווחים לבנים, הערות או מחרוזות תיעוד נדחים עם שגיאת אימות, כי אין לוגיקה ש-AlphaEvolve יכול לשנות.
• ללא קינון: אין תמיכה בבלוקים של התפתחות מקוננת.

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

שיטות מומלצות לצמצום מרחב החיפוש

האופן שבו אתם מסדרים את הייבוא הבלתי ניתן לשינוי וממקמים את הבלוקים של evolve מראה באופן מפורש את הגבולות התפעוליים של AlphaEvolve.

ניהול ייבוא ספריות ויחסי תלות

‫AlphaEvolve לא יכול לקבוע באופן מובנה אילו ספריות חיצוניות מתאימות לסביבת הייצור שלכם.

כדי לאפשר ניתוח פתוח: אם כל חבילה מתמטית או חבילת למידת מכונה מתאימה למקסום המדד, צריך להציב את הייבוא בתוך EVOLVE-BLOCK שניתן לשינוי. הגישה הזו מאפשרת ל-AlphaEvolve להשתמש בחלופות למסגרות (למשל, להחליף את sklearn ב-TensorFlow או ב-xgboost).

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

איך להימנע ממרחב חיפוש מוגבל מדי

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

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

מיקום אסטרטגי של בלוקים להשגת יעדים ממוקדים

שינוי ההיקף של EVOLVE-BLOCK משנה את כל יעד האופטימיזציה של צינור עיבוד הנתונים:

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

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

שמירה על היררכיה מודולרית (דוגמאות ל-HDL/Verilog): כשמבצעים אופטימיזציה של הגדרות של בלוקים של קוד מבני, חשוב לשמור את התגים EVOLVE-BLOCK-START ו-EVOLVE-BLOCK-END בתוך הגבולות של הגדרת המודול. כך ההיוריסטיקה של החיפוש לא תבצע מהלכים לא חוקיים מבחינה מבנית, כמו ניסיון להחליף מודול אחד שמכיל את כל מה שצריך בכמה מודולי משנה צפים שלא מופו.