מדריך מתקדם לכתיבת פרומפטים ל-ChatGPT

הפרומפט הוא ממשק, לא לחש

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

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

הנוסחה הבסיסית שכדאי לזכור

רוב הפרומפטים הטובים בנויים מארבעה מרכיבים: [תפקיד] + [משימה] + [הקשר] + [פורמט]. התפקיד קובע את נקודת המבט, המשימה מגדירה מה לעשות, ההקשר נותן את החומר, והפורמט מכתיב איך התשובה תיראה.

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

טכניקות שעובדות

Persona prompting

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

Chain of Thought

בקשו מהמודל לחשוב בשלבים. עבור בעיות חישוב או לוגיקה, הוראה כמו "חשוב צעד אחר צעד והצג כל שלב" מפחיתה שגיאות ומאפשרת לכם לבדוק איפה ההיגיון התפצל. שימו לב: מודלי חשיבה (reasoning) מהדור החדש מבצעים את זה מעצמם — אצל אלה, הוראה מפורשת "לחשוב בקול" עלולה דווקא להזיק, ועדיף לתת להם את הבעיה ולתת להם לעבוד.

Few-shot learning

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

טעויות שכדאי להימנע מהן

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

מעבר לפרומפט: הנדסת הקשר

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

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

עבודה עם מודלי חשיבה

הדור החדש של מודלי החשיבה שינה את כללי הכתיבה: המודלים האלה חושבים "בשקט" לפני שהם עונים, ולכן חלק מהטכניקות הקלאסיות — כמו דרישה מפורשת לחשוב שלב אחר שלב — כבר לא נחוצות ואף עלולות להפריע. הכלל החדש: תנו למודל החשיבה את הבעיה המלאה, את האילוצים ואת הפורמט, ותנו לו לעבוד. אל תנסחו אותו כסדרת צעדים שהוא כבר מבצע מעצמו.

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

System prompt והנחיות קבועות

כשעובדים דרך API, אפשר להפריד בין הוראות קבועות (system prompt) לבין הבקשה המשתנה. ה-system prompt הוא המקום להגדיר את הזהות, את הכללים ואת האילוצים שחוזרים בכל שיחה — למשל "ענה בעברית, אל תמציא נתונים, צטט מקור כשיש". ההפרדה הזו חוסכת חזרה על הוראות בכל בקשה, והופכת את המערכת לעקבית וקלה יותר לתחזוקה.

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

טבלת טכניקות לפי מטרה

מטרה	טכניקה	דוגמה קצרה
נקודת מבט מקצועית	Persona	"אתה מבקר קוד בכיר..."
בעיה לוגית מורכבת	Chain of Thought	"פרק את הבעיה לשלבים..."
עקביות פורמט	Few-shot	שתי דוגמאות של קלט ופלט
מבנה פלט קבוע	פורמט מפורש	"החזר JSON עם שדות..."
הפחתת המצאות	ציטוט מקור	"צטט את המקור לכל טענה"

איך בודקים שהפלט טוב

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

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

שורת תחתונה

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