פרומפט טוב אומר למודל מה אתם רוצים ונותן לו מספיק מידע כדי להתחיל. בסרטון הזה נעבור על בקשה מעורפלת, נשפר אותה דרך שאלות, ונשתמש בדוגמאות כדי להראות את הפלט שאנחנו צריכים. נסתכל גם על איך נותנים לסוכן מטרה ודרך לבדוק אותה. כל שינוי בפרומפט יכול לשנות את הסתברויות הטוקן הבא שהמודל דוגם מהן, אז תעשו שינויים מכוונים ותבדקו אם הם עזרו.
נתחיל מבקשה מעורפלת. תכתוב פונקציה שמעבדת את הנתונים. הבקשה מציינת את המשימה, אבל משאירה את רוב ההתנהגות לא מוגדרת.
באיזה פורמט הנתונים? אילו שדות באמת חשובים? מה צריך לקרות כשהקלט פגום? אם נשאיר את השאלות האלה בלי תשובה, המודל עשוי להניח הנחות משלו. כל הנחה היא מקום שבו התוצאה יכולה להיות שונה ממה שהתכוונו.
אתם יכולים לכתוב את הפרטים בעצמכם. כשמדובר במשימה עם כמה החלטות פתוחות, שיחה קצרה עשויה להיות קלה יותר. תבקשו מהמודל לשאול אתכם שאלות לפני שהוא כותב את הקוד. למשל, תשאל אותי שאלות עד שהדרישות ברורות, ואז תכתוב את הפונקציה. אפשר גם לבקש ממנו לסכם על מה הסכמתם לפני שהוא מתחיל.
עכשיו בדיוק אותם פערים חוזרים אליכם כשאלות. באיזה פורמט הנתונים? אילו שדות חשובים? מה צריך לקרות עם שורה פגומה? אתם עונים על השאלות אחת אחת. המודל עוזר למצוא פערים, ואתם מחליטים על ההתנהגות שאתם רוצים. תוסיפו כל דבר חשוב שהוא לא שאל עליו.
אחרי שעונים על השאלות, הבקשה ספציפית. היא אומרת מה שם הפונקציה, מה הארגומנט שלה, ומה טיפוס ההחזרה, והיא מציינת את ההתנהגות המדויקת שאנחנו רוצים. תקרא את הקובץ כ-JSONL, ותדלג על כל שורה שלא נפרסת. המודל לא נעשה חכם יותר. הסרנו ניחושים לגבי הטיפוס של הפונקציה, ההיקף שלה, וההתנהגות שלה, עוד לפני שהוא מתחיל. עכשיו אפשר לבדוק את הקוד מול ההחלטות האלה.
תדמיינו שאתם מוסרים את הפרומפט לעמית לעבודה. אם הוא היה צריך לשאול על הקלטים, הפלט או האילוצים, גם המודל צריך את המידע הזה. אפשר לספק אותו ישירות או לגבש אותו דרך שאלות. עמימות היא סיבה נפוצה אחת לתוצאות לא רצויות. כשהמודל עושה את הדבר הלא נכון, תבדקו מה הפרומפט השאיר פתוח, וגם האם המימוש עצמו נכון.
הדוגמה הראשונה הייתה פונקציה אחת, והשאלות הפתוחות היו על ההתנהגות שלה. משימה לסוכן צריכה עוד שני דברים. קחו את הבקשה "תשפר את הקוד". היא לא אומרת מה זה "טוב יותר", אז הסוכן צריך לנחש. היא גם לא נותנת שום דרך לדעת מתי העבודה הסתיימה.
עכשיו תשוו את זה לזה. ההתחברות נכשלת כשבמייל יש אותיות גדולות. תוסיף טסט שמשחזר את הבאג, ואז תתקן אותו. זה אומר מה הבעיה ומה הבדיקה הקונקרטית. טסט שנכשל לפני התיקון ועובר אחריו הוא עדות שהשינוי מטפל בבאג.
הבקשה הזאת משאירה את פרטי המימוש לסוכן. היא לא מכתיבה עריכה שורה אחרי שורה. במקום זה, אתם נותנים לו את המטרה, יחד עם דרך לדעת אם זה עבד.
תכללו כל אילוץ שהוא צריך לעמוד בו. אם נדרשת גישה מסוימת, תגידו את זה ותסבירו למה.
עכשיו קחו משימה קטנה שאין לה שום קשר לקוד. אנחנו רוצים שהמודל יתייג את הסנטימנט של ביקורות על מסעדות. בקשה בלי דוגמאות פתורות נקראת zero-shot prompting. אתם מתארים במילים את המשימה ואת הפורמט שאתם רוצים.
ב-few-shot prompting מוסיפים קודם כמה דוגמאות פתורות. כל אחת מהן מצמידה לביקורת את התווית שלה. "הפסטה הכי טובה בעיר" מקבלת positive. "מרק קר, מלצר גס רוח" מקבלת negative. "אוכל מעולה, אבל המתנה ארוכה" מקבלת mixed. אנחנו לא מלמדים את המודל מה זה סנטימנט. הוא כבר יודע את זה מהאימון שלו. הדוגמאות מראות באילו תוויות אנחנו משתמשים, כולל mixed, ושהתשובה היא מילה אחת.
בלי דוגמאות, המודל עשוי לענות במשפט שלם, ועשוי לנטות לחיובי או לשלילי. התשובה יכולה להיות הגיונית ועדיין לא להיות אחת התוויות שלנו. עם הדוגמאות, התשובה היא מילה אחת, "mixed". היא עוקבת אחרי התבנית שסיפקנו.
דוגמאות מראות למודל איך נראית תשובה מתאימה. כאן הן מדגימות את התוויות ואת הפורמט. תתחילו מכמה דוגמאות מייצגות. שלוש עד חמש דוגמאות הן נקודת התחלה סבירה, ואז אפשר לבדוק אם עוד דוגמאות מועילות. דוגמאות יכולות גם להבהיר את המשימה או להראות איך לטפל במקרה חריג. תבחרו אותן לפי מה שהמודל צריך ללמוד מהפרומפט הזה.
כמה הרגלי כתיבה הופכים את המשימה לקלה יותר להבנה. ראשית, תגידו מה אתם רוצים שהמודל ייצר. "תכתוב פרוזה" ספציפי יותר מ"אל תשתמש במרקדאון", שעדיין משאיר כמה פורמטים אפשריים.
שנית, תנו את הסיבה כשהיא עוזרת להסביר את הדרישה. למשל, תגידו שהטקסט יוקרא בקול על ידי מנוע הקראה. הסיבה עוזרת למודל לקבל החלטה הגיונית במקרים הקשורים שלא חשבתם לפרט במפורש.
שלישית, תבהירו את הפעולה המבוקשת. "תשנה את X" מבקש עריכה. "תציע שינוי ל-X" מבקש עצה. תשתמשו בניסוח שאתם באמת מתכוונים אליו. נימוס זה בסדר. העניין הוא להבהיר אם הסוכן צריך לפעול, להסביר, או לחכות להחלטה שלכם.
רביעית, תבקשו מבנה כשאתם צריכים אותו. אם אתם רוצים את הפלט כתגיות, או כ-JSON, או בסכמה מסוימת, תגידו את זה במפורש בפרומפט. הרבה יותר קל לשאר התוכנית שלכם לעבוד עם פלט מובנה, והרבה יותר קל לכם לבדוק.
חמישית, תבקשו מהסוכן להריץ את הבדיקות הרלוונטיות לפני שהוא מדווח שסיים. כשמדובר בשינוי קוד, זה יכול להיות טסטים או בודק טיפוסים. תסתכלו על התוצאות, כולל כל דבר שהוא לא הצליח להריץ.
שישית, אם פרומפט מפורט מרגיש כמו יותר מדי הקלדה, תגידו אותו בקול. ל-Claude Code יש בשביל זה הכתבה קולית. תקלידו /voice כדי להפעיל אותה, ואז תחזיקו את מקש הרווח בזמן שאתם מדברים. Codex מציע הכתבה באפליקציית הדסקטופ שלו, אבל לא בגרסת הטרמינל. לדבר דורש הרבה פחות מאמץ מאשר להקליד, אז יהיה לכם קל יותר לתת פרומפטים ארוכים ומפורטים יותר.
אפשר להשתמש בהרגלים האלה יחד: לציין את המשימה, להסביר אילוצים רלוונטיים, להראות את הפורמט, ולבקש בדיקות. תשמרו על החלקים שעוזרים בפרויקט שלכם.
נתראה בסרטון הבא.