פיתוח ובדיקת System Prompt עבור עוזר AI

פיתוח System prompt: היכן העוזר עונה באופן שגוי

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

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

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

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

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

אפקט מדיד מהוראה מכוילת של העוזר

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

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

המדד הראשון — שיעור התשובות הנכונות. לאחר ניקוי כללים ודוגמאות הוא עולה מ-70–75 ל-90+ אחוזים באותם תרחישים, ומספר הפניות לנציג באותם תרחישים יורד פי כמה: העוזר מפסיק להישען על ניסוחים כלליים ומוביל את הדיאלוג לתוצאה. בנפרד אנו בוחנים תשובות מחוץ לכשירות — שם המדד אינו ׳נכון/לא נכון׳, אלא נכונות האסקלציה.

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

אחידות סגנון התשובות היא גם כן величина מדידה: מבנה, אורך, צורת פנייה וניסוחי סירוב מוגדרים בכללים מפורשים ונבדקים אוטומטית לפי סמנים, ולכן תרחיש חדש לא ׳מתפזר׳ בטון לעומת האחרים.

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

דרכים להגדיר את התנהגות העוזר: השוואת גישות

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

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

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

סדר העבודה על הוראת העוזר

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

1. ביקורת תשובות העוזר: מתייגים דיאלוגים אמיתיים — היכן הוא יוצא מהתפקיד, משלים עובדות, שובר פורמט. בפלט — רשימת סירובים טיפוסיים עם תדירות.
2. סכימת כללים: תפקיד, טון, גבולות כשירות, סדרי עדיפויות בקונפליקט בין הנחיות והתנהגות כשאין מספיק נתונים — למי להעביר את הבקשה.
3. טיוטת ההוראה: ניסוחים לכל כלל ובנוסף בלוקים נפרדים לתרחישים נפוצים, כדי שהטקסט הראשי לא יתפח.
4. סט בדיקות: תגובות ייחוס ותשובות צפויות, כולל פרובוקציות, שאלות חלקיות ונושאים מחוץ לתחום.
5. בדיקת ההוראה: הרצה על הסט והשוואה לייחוס, תיקון ניסוחים, קיבוע גרסה. תשובות שנויות במחלוקת מנתחים בנפרד.
6. קבלה על תרחישי הלקוח: מבהירים מקרי גבול ואת הטון של התשובות.
7. העברה: הוראה, סט בדיקות ותקנון עדכון קצר — כשהמוצר משתנה, הכללים מתוקנים נקודתית.

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

אילו ארטיפקטים נשארים לצוות אחרי הפרויקט

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

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

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

מקרה בוחן: כיצד הסירו אי-התאמות בתשובות העוזר

העוזר של רשת מרכזי שירות ServicePro השיב ללקוחות בצ׳אט, בדואר ובמסנג׳ר. על סט בקרה של 200 תרחישים, אותה שאלה על מועדים והחזר הניבה אי-התאמות ב-29% מהמקרים: הכללים שוכפלו בשלושה מקומות בהוראה וסתרו זה את זה.

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

מה היה לא תקין

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

מה נכתב מחדש ומה התקבל

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

אותו סט אחרי התיקונים: אי-התאמות 29% → 2%, תשובות עם פרטים מומצאים 11% → 0.8%, שיעור התשובות הנכונות 71% → 96%. הסט הפך לסט רגרסיה — כל תיקון בהוראה מורץ במלואו, וחזרה לגרסה קודמת אורכת דקות.

מה לעשות אם הפרומפט כבר כתוב, אבל התשובות לא יציבות

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

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

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

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

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

ספקות טכניים נפוצים לפני ההתחלה

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

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

איך לוודא שהתשובות תואמות את הכללים?

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

האם עדכון ההוראה הוא הרכבה מחדש מלאה של הפתרון?

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

מה מקבל הלקוח בהעברת הפרויקט?

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

נדבר על המשימה שלכם: מה להכין לשיחה

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

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

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

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