שיטות מומלצות לניסויים

כדי להתחיל להשתמש ב-AlphaEvolve לניסויים, מומלץ לפעול לפי תהליך העבודה הבא:

1. השלמת האתחול של הסביבה

   בדף Get Started (תחילת העבודה) אפשר להשלים את כל הדרישות המוקדמות ולהפעיל את הסביבה.

2. ביצוע אימות בסיסי

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

3. הפעלת הניסוי

   בוחרים בין שילוב מבוסס-סוכן לבין שילוב ידני:

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

   • שילוב ידני: אם אתם לא משתמשים בכלים מבוססי-סוכן, תוכלו להיעזר במעבדות התכנות וליצור את הניסוי באופן ידני על ידי ביצוע הפעולות הבאות:

     • הכנת בסיס לקוד ה-seed

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

     • יצירת פונקציית המעריך

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

     • תיעוד הגדרת הבעיה

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

     • בחירת הגדרת הניסוי

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

4. מעקב אחרי הביצוע

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

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

5. שילוב בסביבת הייצור

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

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