איך מדבגים פרומפט.

מה בדיוק לא עובד?

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

• “התשובה ארוכה מדי - 12 פסקאות במקום 3.”
• “פספס את ההוראה לפלט JSON, החזיר טקסט חופשי.”
• “המציא תאריך שלא היה בקלט.”
• “ענה באנגלית למרות שביקשתי עברית.”

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

לשחזר את הבעיה

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

לצמצם את הפרומפט

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

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

לשנות דבר אחד בכל פעם

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

# דוגמה: רוצים פלט קצר ובפורמט JSON.

# גרסה A (בעיה: לפעמים ארוך):
"סכם את המסמך"

# שינוי 1 בלבד:
"סכם את המסמך בלא יותר מ-100 מילים"

# נבדק - אם תוקן, מצוין. אם לא, שינוי 2:
"סכם את המסמך. החזר JSON עם השדות: summary, key_points (מערך של 3)"

להוסיף דוגמאות (few-shot)

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

לשאול את המודל

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

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

לתעד את הגרסה הסופית

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

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