The Prompting Playbook: פרומפט מול Harness

הרעיון המרכזי

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

הנקודה החשובה: מערכת AI טובה היא שילוב של פרומפט + מודל + harness + כלים + evals. לא רק טקסט.

תרחיש 1: לתחזק פרומפט קיים

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

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

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

סט הערכות טוב כולל:

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

ניקוי הפרומפט

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

לכן כדאי להפריד מבנה:

• role
• guidelines
• policy
• data
• tone of voice
• output format

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

כשל 1: המודל מסתיר מידע שיש לו

במקרה של hotspot data, למודל היה את המידע הנכון מתוך נתוני הלקוח: ללקוח יש 5GB. אבל בפרומפט הייתה הוראה ישנה שאמרה לא לתת פרטים שגויים לגבי תוכניות legacy ולהפנות את הלקוח ל־URL.

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

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

כדאי לשמור פרומפטים ב־version control, במיוחד תיקונים הגנתיים, עם הסיבה למה הוסיפו אותם.

כשל 2: הוראות לא מוסיפות יכולת

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

הפתרון היה לתת לו כלי: proration calculator.

צריך:

1. להגיד בפרומפט מתי להשתמש בכלי.
2. להגדיר tool schema ב־API.
3. לממש את החישוב האמיתי בקוד.

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

כשל 3: מטרה חד-צדדית יוצרת התנהגות גרועה

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

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

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

תרחיש 2: לבנות agent חדש מאפס

הדוגמה השנייה היא agent שיוצר לוח משמרות שבועי לעובדי חנות לפי זמינות, headcount, וחוקים קשיחים.

כאן לא משתמשים רק בפרומפט. משווים בין כמה גישות:

1. מודל קטן + פרומפט פשוט: נכשל.
2. מודל חזק יותר + אותו פרומפט: פחות טעויות, אבל עדיין נכשל.
3. מודל חזק עם adaptive thinking: מצליח, אבל יקר ואיטי.
4. מודל קטן עם פרומפט טוב יותר: משתפר, אבל צורך הרבה tokens ולפעמים לא מסיים.
5. לולאה agentic של generate / evaluate / repair: מצליחה עם פחות latency ו־tokens.

לולאת generate/evaluate/repair

“Agentic generate/evaluate/repair loop: passes with lower latency/tokens than trying to force one prompt to do everything.”

המשפט הזה אומר:

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

1. Generate: מודל יוצר טיוטה ראשונה.
2. Evaluate: שלב נפרד בודק את הטיוטה ומחזיר רשימת בעיות מדויקת.
3. Repair: שלב שלישי מקבל את הבעיות ומתקן רק אותן.

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

בדוגמת לוח המשמרות מהווידאו:

• generate יוצר schedule ראשוני.
• evaluate אומר: “ביום רביעי חסר עובד”, “שרה שובצה בזמן שהיא לא זמינה”, “יש משמרת בלי manager”.
• repair מתקן את הבעיות האלה במקום לבנות הכל מחדש.

זה דומה לאיך שאנחנו עובדים עם קוד: קודם כותבים, אחר כך מריצים tests/lint, אחר כך מתקנים לפי failures. לא מנסים לכתוב קוד מושלם עם קומפילציה דמיונית בתוך הראש.

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

1. מחולל יוצר טיוטת לוח משמרות.
2. evaluator בודק אילו חוקים הופרו.
3. repair prompt מתקן רק את הבעיות הספציפיות.

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

הפלייבוק המעשי

כשמתחזקים או בונים מערכת AI:

1. תתחיל מ־evals, לא מניחושים.
2. תכלול מקרי בקרה, מקרי קצה, ומקרי גבול יכולת.
3. תנקה את מבנה הפרומפט לפני שאתה מתקן כשלים נקודתיים.
4. תפריד בין מדיניות, נתונים, תפקיד, טון, ופורמט פלט.
5. תזהה ותסיר patches ישנים שנועדו למודלים קודמים.
6. תתקן כשל אחד בכל פעם.
7. אל תשתמש בפרומפט כדי להוסיף יכולת שאין למודל.
8. תן כלים למשימות שדורשות דיוק.
9. תציג למודל את שני הצדדים של טריידאופים.
10. תשתמש ב־structured outputs או stop sequences כשפורמט הפלט חשוב.
11. אל תחשוב רק על הפרומפט; תחשוב גם על המודל, ה־API, וה־harness.
12. למשימות מורכבות, שקול לפרק ללולאת generate / evaluate / repair.

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

הווידאו בעצם אומר: prompting הוא engineering discipline. כשמודל נכשל, אל תקפוץ מיד להוסיף עוד משפט לפרומפט. קודם תשאל:

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

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

פרומפט מול Harness

כן. ה־generate/evaluate/repair loop הוא בעיקר שינוי של harness / orchestration, לא רק שינוי פרומפט.

הפרומפטים משתנים גם, כי יש עכשיו שלושה פרומפטים קטנים, אבל השינוי האמיתי הוא בקוד שמפעיל את המודל:

old:
user input -> one big prompt -> model -> final answer

new:
user input -> generate prompt -> draft
draft -> evaluate prompt / validator -> list of problems
draft + problems -> repair prompt -> fixed answer

כלומר ה־harness הוא ה”מערכת מסביב למודל”: מי קורא למודל, באיזה סדר, עם איזה כלים, איזה schema, איזה retries, איזה validators, איזה model, איזה stop sequences, איך מחזירים tool results, ואיך מחליטים אם התשובה מספיק טובה.

מה נכלל ב־harness?

האם זו בעיית מבנה?
בדרך כלל זה prompt. למשל הפרומפט מערבב policy, tone, data והוראות.
אבל אם המבנה מנוהל דרך templates, message roles, prompt builder, או הפרדה בין system/user/developer messages, אז זה גם קצת harness.

האם יש הוראה ישנה שמפריעה?
בעיקר prompt/versioning. זו הוראה בתוך הפרומפט שצריך למחוק או לשנות.
ה־harness קשור רק אם יש מערכת שמזריקה הוראות ישנות אוטומטית.

האם חסר כלי?
זה כבר tools + harness.
לא מספיק לכתוב בפרומפט “תחשב נכון”. צריך לממש כלי, להגדיר tool schema, לתת למודל גישה אליו, להריץ את הכלי, ולהחזיר את התוצאה למודל.

האם המודל לא מתאים?
זה harness/config.
בחירת model, routing בין מודלים, fallback, adaptive thinking, max tokens, temperature וכו׳.

האם פורמט הפלט לא מוגדר מספיק?
יכול להיות prompt, אבל הפתרון החזק יותר הוא הרבה פעמים harness: structured outputs, JSON schema, parser, validator, retry on invalid output, stop sequence.

האם המשימה צריכה ארכיטקטורה של כמה שלבים במקום פרומפט אחד?
זה חד משמעית harness/orchestration.
כמו generate/evaluate/repair, planner/executor, retrieve/read/write, או classify/route/respond.

דוגמאות מתי לא לתקן בפרומפט

אם המודל עושה מתמטיקה לא אמינה:
לא להוסיף “be very accurate”. להוסיף calculator/tool.

אם הוא צריך מידע עדכני:
לא לכתוב “use current information”. לתת search/RAG/database tool.

אם הוא מחזיר JSON שבור:
לא רק “return valid JSON”. להשתמש ב־structured output או schema validation + retry.

אם הוא לא יודע אם להסלים לאדם:
לפעמים לא להשאיר את זה למודל. לשים rule deterministic ב־harness: אם billing_conflict=true, route_to_human.

אם הוא צריך לבדוק הרבה constraints:
לא לדחוף את כל החוקים לפרומפט ענק. להשתמש ב־validator קוד או בלולאת generate/evaluate/repair.

אם הוא איטי ויקר מדי:
זה לא פרומפט. זה model routing, caching, max tokens, split steps, או בחירת מודל אחר.

אם יש פעולות עם side effects, כמו שליחת אימייל או חיוב לקוח:
לא לסמוך רק על “ask before sending”. ה־harness צריך approval gate אמיתי.

השורה הכי פרקטית

אם הבעיה היא הבנה/כוונה/סדר הוראות, תתחיל בפרומפט.

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