Automatic Prompt Engineer (APE) מאפשר למודל שפה לכתוב, לבחון ולבחור את הפרומפט הטוב ביותר עבור משימה נתונה, ובכך הופך את מה שהיה בעבר אמנות של ניסוי וטעייה לחיפוש מבוסס נתונים (data-driven) שניתן לשחזר.
למה כתיבת פרומפטים הפכה לצוואר בקבוק
הנדסת פרומפטים (Prompt engineering) — ניסוח המילים המדויקות שאומרות למודל מה לעשות — הייתה במשך זמן רב שילוב של אינטואיציה ומזל. אנשי מקצוע משנים מילה כאן, מחליפים ביטוי שם, מריצים את המודל, ועוצרים כשהפלט "מרגיש נכון". הגישה הזו אורכת זמן רב, תלויה בדמיון של המהנדס ומגבילה את הביצועים. בסביבת ייצור (production), המשמעות היא מחזורי עבודה ארוכים יותר, תוצאות לא עקביות ועלויות נסתרות שצצות רק לאחר ההשקה.
תהליך העבודה בן שלושת השלבים של APE
APE מתייחס ליצירת פרומפט כבעיית חיפוש. המשתמש מזין סט קטן של דוגמאות קלט-פלט. לאחר מכן, המערכת מריצה שלושה שלבים אוטומטיים:
- Propose (הצעה) – המודל סורק את הדוגמאות ופולט קבוצה של הנחיות מועמדות, כגון "החזר את ההפך" או "כתוב את המילה הנגדית".
- Score (דירוג) – המערכת מריצה כל מועמד על סט נפרד של דוגמאות שלא נראו קודם לכן, וסופרת כמה תשובות תואמות לפלט המצופה, מה שמניב מספר דיוק גולמי. בשלב זה אין מעורבות של שיפוט אנושי.
- Select (בחירה) – ההנחיה בעלת הדיוק הגבוה ביותר הופכת לפרומפט הסופי.
ניתן לחזור על הלולאה. הפרומפט המנצח הופך ל"זרע" (seed) החדש, והמודל מציע וריאציות. בריצות שדווחו, הנחיה גנרית שקיבלה ציון של 83% עברה שיפור לגרסה שהגיעה ל-100% על סט הבדיקה.
מה הופך את הגישה הזו לחזקה יותר מיד אנושית
- כיסוי (Coverage) – מודל שפה גדול (LLM) מייצר עשרות חלופות ניסוח תוך שניות, הרבה יותר ממה שאדם יכול היה לבחון.
- אובייקטיביות – הבחירה נשענת על דיוק מדיד, ולא על מידת הליטוש של הניסוח. הנחיה בסגנון ספר לימוד עשויה עדיין להפסיד לווריאציה תמציתית ובעלת צליל מוזר שהמודל מבין טוב יותר.
מכיוון שמדד הדירוג מגיע מהמשתמש — בדרך כלל בדיקת התאמה מדויקת (exact-match) או בדיקת יחידה (unit test) — ניתן לכייל את המערכת לכל דרישה בהמשך התהליך, מיצירת קוד ועד ניתוח סנטימנט.
המחיר של האוטומציה
הפשרה היא כוח מחשוב. דירוג כל מועמד דורש קריאות רבות למודל, ולכן שלב הפיתוח צורך כמות ניכרת של שימוש ב-API. APE מתייחסת להוצאה זו כהשקעה חד-פעמית: ברגע שהפרומפט האופטימלי מזוהה, ניתן להשתמש בו שוב ושוב לנצח ללא עלות נוספת.
שני תנאי מוקדם גם מגבילים את האימוץ:
- דוגמאות מתויגות (Labeled examples) – המערכת זקוקה לסט מייצג של קלטים ופלטים נכונים.
- פונקציית דירוג (Scoring function) – על המשתמשים להגדיר מה המשמעות של "נכון" עבור המשימה שלהם, בין אם מדובר בהתאמה מדויקת של מחרוזת, טווח סבולת מספרי או ולידטור (validator) מותאם אישית.
היכן שהרעיון עלול להיתקל בקשיים
אם סט הדוגמאות הראשוני קטן מדי או אינו מייצג, הפרומפט הנבחר עלול לסבול מ-overfitting (התאמת יתר) ולהיכשל בשימוש בעולם האמיתי.
מה כדאי לעקוב אחריו בהמשך
הכלי מציע חלופה: הזנת מספר דוגמאות, מתן אפשרות למודל לבצע איטרציות, וקבלת פרומפט שהמערכת מדרגת כגבוה ביותר מבין ניסיונותיה. הדמו נמצא בקישור בהכרזה המקורית, וקהילת למידה מתכנסת ב-Telegram.
שורה תחתונה: אוטומציה של הנדסת פרומפטים מחליפה ניחושים בביצועים מדידים, אך היא דורשת נתונים מראש, כוח מחשוב והגדרה ברורה של הצלחה.