הלוחש למכונות - Prompt Engineering בעשרים דקות

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

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

Prompt Engineering מתחיל בהגדרה מדויקת

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

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

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

אל תתחילו מ-zero-shot כשיש לכם דוגמאות

מודל יכול לקבל משימה בפעם הראשונה ולנסות לפתור אותה. שחר קורא לזה zero-shot. לפעמים זה יספיק. הרבה פעמים תקבלו תשובה סבירה, אבל לא תשובה שנראית כמו העבודה שלכם.

החלופה היא לתת few-shot examples: כמה דוגמאות קצרות ל-output הרצוי. אם אתם רוצים סיכום, אפשר להראות למודל איך נראו סיכומים קודמים שאהבתם. אם אתם רוצים prompt ליצירת תמונה, אפשר לתת דוגמאות לתיאור, למבנה ולפרטים שאתם נוטים לבקש.

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

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

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

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

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

הכרחתי אותו לחשוב.

השתמשו ב-LLM כדי לשפר את הפרומפט עצמו

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

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

הוא גם מתאר עבודה בין מודלים: להעביר output של Claude ל-ChatGPT ולהפך. זו אינה הוכחה שאחד מהם תמיד צודק. זו דרך לקבל ביקורת נוספת ולחדד את הניסוח. למי שמחפש מסגרת רחבה יותר לשינויים שמודלי AI מכניסים לעבודה, אפשר להמשיך להרצאה מי הזיז את הבינה שלי?.

אם אין קונטקסט - תבקשו שאלות

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

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

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

RAP: role, action, parameters

כדי לארגן את ההנחיה, שחר משתמש במסגרת RAP: role, action, parameters. קודם מגדירים role - למשל אנליסט או דמות ספציפית שהמודל צריך לגלם. אחר כך action - מה בדיוק המשימה. לבסוף parameters - הקונטקסט והחומרים שעומדים לרשותו, כמו מסמכים, תמונות וטקסטים.

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

מבחינתי זה סט הנחיות שאנחנו הולכים לבוא ולתת לכלי.

המודל עדיין יכול לחרטט

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

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

הסטטיסטיקה יכולה לטעות.

השורה התחתונה

• Prompt Engineering מתחיל בהגדרה של תוצאה, פורמט ומוקד - לא בטריק ניסוח.
• few-shot examples נותנים למודל דוגמאות למה נחשב output טוב אצלכם.
• אפשר לבקש מהמודל להסביר את תהליך הבדיקה שלו, לייצר אפשרויות ולצמצם אותן בשלבים.
• כשחסר קונטקסט, שאלות חזרה טובות יותר מניחוש מהיר.
• RAP מסדרת role, action ו-parameters סביב משימה ברורה.
• גם פרומפט מצוין לא מחליף אימות עובדות.

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