הנדסת פרומפטים לעוזר AI: היכן נשברת לוגיקת התשובות
הנדסת פרומפטים לעוזר AI באפליקציה מתחילה לא בניסוחים יפים, אלא בניתוח היכן בדיוק נשברת לוגיקת התשובות. העוזר נראה עובד בהדגמה ומתפרק בתרחישים אמיתיים: המשתמש שואל שאלת הבהרה לאחר שני הודעות, מחליף נושא, כותב עם שגיאות כתיב או מערבב שתי בקשות באחת.
איכות התשובות יורדת לא בגלל המודל, אלא בגלל שכללי ההתנהגות, גבולות התפקיד והעבודה עם הקשר השיחה מתוארים באופן חלקי.
הסוג הראשון של כשלים — תשובות לא רלוונטיות. העוזר או יוצא לדיונים כלליים במקום לנתוני האפליקציה, או ממציא עובדות שאינן קיימות במערכת. הסיבה בדרך כלל היא שבהנחיות לא נקבע סדר עדיפויות למקורות: מה לקחת מפרופיל המשתמש, מה מהקטלוג, ומה אסור להשלים מדעת.
הסוג השני — אובדן הקשר השיחה: העוזר שוכח על מה דובר, שואל שוב דבר שכבר נאמר, מאבד מסננים נבחרים במעבר בין מסכים. כאן חשוב לא אורך ההיסטוריה, אלא אילו ישויות מופקות ממנה ומועברות לבקשה הבאה.
הסוג השלישי — התנהגות לא יציבה עם גידול בעומס. אותה שאלה בדיוק נותנת תשובות שונות בהתאם לאורך ההיסטוריה, לסדר ההודעות ולכמה בקשות הגיעו במקביל. העוזר מתחיל "לגלוש" לטון אחר, לקטוע תשובות או להתעלם ממגבלות. זו תוצאה של כך שהפרומפט מורכב מחתיכות מפוזרות ללא מבנה אחיד וללא בדיקת יציבות.
מפרקים כיצד זה נסגר: כיצד מתוכננת מבנה ההנחיות, כיצד נשמר הקשר השיחה וכיצד התנהגות העוזר נבדקת בתרחישים, ולא על דוגמה מוצלחת אחת.
מה נותן הנדסת פרומפטים בנויה היטב
הנדסת פרומפטים היא לא "לכוונן ניסוח", אלא שכבה מנוהלת בין המודל למוצר. הפרומפט מגדיר את תפקיד העוזר, גבולות הידע, פורמט התשובה וכללי ההסלמה לנציג אנושי.
כאשר שכבה זו בנויה באופן מערכתי, התנהגות העוזר הופכת לצפויה: על שאילתות זהות הוא עונה באופן זהה, ועל שאילתות לא שגרתיות — לא ממציא, אלא מבקש הבהרה או מעביר לאדם.
מה מודדים ומה משתנה
שיעור התשובות הרלוונטיות עולה הודות להצמדה קשיחה לבסיס הידע ולהוראות מפורשות "מה לא לעשות". זמן התגובה יורד כאשר הפרומפט לא מכריח את המודל לחשוב בקול רם במקום שבו נדרש עובדה קצרה, ופורמט התשובה מוגדר מראש.
עמידות לשאילתות נבדקת באמצעות מערכת של תרחישים פרובוקטיביים: שגיאות כתיב, שפות מעורבות, שאלות מחוץ לנושא, ניסיונות לחלץ הוראות פנימיות. אנו מריצים מערכות כאלה על כל תיקון בפרומפט, כדי ששיפור בתרחיש אחד לא ישבור את האחרים.
איך זה נראה בעבודה
אנו מנהלים גרסאות לפרומפטים כמו קוד, שומרים דיאלוגים לדוגמה ומשווים מדדי העוזר לפני ואחרי שינויים. איכות הדיאלוג מוערכת לא "בעין", אלא לפי שיעור הפניות שנפתרו ללא נציג אנושי ולפי מספר שאלות ההבהרה לתרחיש אחד. קו מתאר כזה מאפשר לשנות את התנהגות העוזר באופן ממוקד — ללא בנייה מחדש של האפליקציה.
הגישה שלנו נשענת על OpenAI ומודלים אחרים כשכבה הניתנת להחלפה הדדית: הלוגיקה של העוזר חיה בפרומפטים ובכללים, ולא בספק ספציפי. זה מפחית את הסיכון שהחלפת מודל תאפס את איכות הדיאלוג שנצברה.
גישות לבניית פרומפטים: השוואת מצבים
הבחירה בגישה לארגון פרומפטים קובעת עד כמה צפויה התנהלות השיחה של העוזר ומהי קצב עליית העלות של פנייה למודל. תבנית נוקשה עם הנחיית תפקיד קבועה מעניקה טון ופורמט תשובה יציבים, אך נשברת כבר בפנייה הראשונה שאינה סטנדרטית של המשתמש.
הרכבה דינמית של הקשר וזיכרון שיחה מסירים את המגבלה הזו, אך דורשים בקרה על אורך ההיסטוריה ועל סדרי עדיפויות בין הבלוקים.
בפועל המצבים אינם מתחרים זה בזה אלא משולבים: שכבה בסיסית מגדירה תפקיד וגבולות, ומעליה נבנה ההקשר של הסשן הנוכחי. להלן השוואה לפי מתי כל גישה מתאימה והיכן מתחילות המגבלות שלה.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| תבנית נוקשה עם הנחיית תפקיד | תרחישים יציבים: עזרה, סטטוס הזמנה, פעולות טיפוסיות | אינה סובלת ניסוחים לא סטנדרטיים, כל סטייה מהתרחיש — סירוב או הזיה |
| תבנית עם משבצות משתנות | תרחיש אחד עם נתונים משתנים: השמת שם, הזמנה, עיר | מספר הענפים גדל, התמיכה בתבניות מסתבכת עם כל משתנה חדש |
| הרכבה דינמית של הקשר | העוזר עונה לפי נתוני האפליקציה ומקורות חיצוניים | נדרשת בקרת רלוונטיות: בלוקים מיותרים מטשטשים את ההנחיה ומגבירים את השהיה |
| שרשרת פרומפטים עם זיכרון שיחה | משימות רב-שלביות: ביצוע, התאמה, אבחון צעד-אחר-צעד | ההיסטוריה גדלה, נדרשים סיכום וכללים מפורשים מה לשכוח |
מה מכריע הבחירה במצב
תבניות נוקשות מנצחות במקום שבו חשובה החזרתיות: אותה פנייה מניבה תשובה זהה, והתנהגות העוזר ניתנת בקלות לכיסוי בבדיקות. פרומפטים דינמיים וזיכרון שיחה נדרשים כאשר המשתמש מנהל משימה בכמה צעדים ומצפה שהעוזר ישמור על ההקשר של ההודעות הקודמות.
היכן הגישות נשברות
המגבלות העיקריות — הצפת הקשר וקונפליקט הנחיות: ככל שנוספים יותר בלוקים לפרומפט, כך עולה הסיכוי שהמודל יתעלם מחלקם. לכן אנו קובעים סדרי עדיפויות בין השכבות, מגבילים את עומק ההיסטוריה ומעבירים נתונים חוזרים לפורמט מובנה ולא לטקסט חופשי.
כיצד אנו בונים את העבודה עם פרומפטים: שלבים
הנדסת פרומפטים עבור אסיסטנט אינה "ניסוח מוצלח" של משפטים, אלא מחזור הנדסי: לפרק תרחישים קיימים, לעצב את מבנה ההנחיות, לבדוק בדיאלוגים אמיתיים ולהעביר לצוות נהלים שלפיהם ניתן לפתח את המערכת בלעדינו. להלן — כיצד בנוי התהליך.
- ביקורת תרחישים. אוספים פניות אמיתיות של משתמשים, מסמנים היכן האסיסטנט עונה באופן שגוי או סוטה מהנושא, ומתעדים ענפי דיאלוג טיפוסיים. בפלט — מפת תרחישים עם עדיפויות: מה קריטי לעסק ומה מקרה נדיר.
- עיצוב פרומפטים. מגדירים את תפקיד האסיסטנט, גבולות התשובות המותרות, הטון וכללי ההסלמה לנציג אנושי. המבנה נבנה בבלוקים — הנחיה, הקשר, דוגמאות — כך שעריכות בבלוק אחד לא ישברו את האחרים.
- הגדרת האסיסטנט. מקשרים את הפרומפטים לנתוני האפליקציה ולמקורות חיצוניים, מגדירים התנהגות בבקשה חלקית או סותרת. בנפרד מפרטים מה האסיסטנט לא צריך לעשות.
- בדיקת דיאלוגים. מריצים את התרחישים על סט של בקשות אמיתיות ובקשות קצה, ומשווים את התשובות לאמת מידה. כל עריכה בפרומפט עוברת בדיקה חוזרת — רגרסיה נתפסת לפני השחרור.
- מדידת איכות. מחשבים את שיעור התשובות הנכונות, תדירות ההסלמות והחזרות לנושא. המדדים מראים היכן האסיסטנט עדיין "מתנדנד", ומגדירים את מחזור השיפור הבא.
- העברת נהלים. מוסרים לצוות מסמך עם ההיגיון של הפרומפטים, כללי השינויים וצ'ק-ליסט לבדיקה. מכאן ואילך עורכים לפי המסמך, בלי לפנות אלינו בכל שינוי.
מחזור כזה חוזר על עצמו ככל שהמוצר גדל: פונקציות חדשות באפליקציה — תרחישים חדשים, והפרומפטים מתעדכנים יחד איתם, ולא נשארים ברמת הגרסה הראשונה.
ארטיפקטים: ספריית פרומפטים וכללי התנהגות העוזר
ספריית פרומפטים היא לא אוסף טקסטים במסמך משותף, אלא קטלוג מנוהל גרסאות: כל תרחיש נמצא בקובץ נפרד עם תיאור הייעוד, נתוני הקלט וההתנהגות הצפויה של העוזר.
תיקונים עוברים סקירה ונכנסים לגרסת האפליקציה יחד עם הקוד, ולכן התנהגות העוזר משוחזרת מגרסה לגרסה ואינה תלויה במי שנגע לאחרונה בניסוח.
כללי ההתנהגות מתארים לא רק "מה לענות", אלא גם "מה לא לעשות": גבולות הנושא, עבודה עם נתונים אישיים, הבהרות חובה לפני פעולה ועדיפות בין הוראות.
תרשימי ענפי השיחה מתעדים את ההסתעפויות — ברכה, הבהרה, אישור, סירוב, הסלמה לנציג — עם ציון באיזה תנאי העוזר עובר לענף כזה או אחר.
בלוק נפרד — טיפול בחריגים: קלט ריק או סותר, בקשה מחוץ לתחום האחריות, שירות לא זמין, ניסיונות חוזרים. לכל סוג כשל מוגדר תרחיש ותשובת גיבוי, כדי שהעוזר לא "יתקע" ולא ימציא נתונים.
לידי הלקוח מועבר:
- ספריית פרומפטים מובנית עם ניהול גרסאות והיסטוריית שינויים;
- כללי התנהגות העוזר: גבולות הנושא, עבודה עם נתונים, עדיפות הוראות;
- תרשימי ענפי שיחה עם תנאי מעבר ונקודות הסלמה;
- תקנון טיפול בחריגים לפי סוגי כשל;
- תיעוד העוזר: ייעוד התרחישים, נתוני קלט, התנהגות צפויה;
- סט שיחות בדיקה לבדיקת שינויים לפני גרסה;
- הנחיות לביצוע תיקונים — מי, כיצד ובאיזו סקירה משנה פרומפטים.
התיעוד מתעדכן יחד עם הספרייה: אם תרחיש משתנה, תיאור מיושן לא נשאר תלוי בנפרד. תארו את המשימה — נחזור עם הערכה ותוכנית להרכב הארטיפקטים עבור המוצר שלכם.
קייס: כיצד גדלה דיוק התשובות של העוזר
הלקוח — שירות משלוחי מזון עם עוזר בתוך אפליקציית המובייל. העוזר ענה על שאלות בנוגע להזמנה, להרכב המוצרים ולזמני אספקה, אך בשליש מהמקרים סיפק תשובות לא רלוונטיות: בלבל בין קטגוריות, הציע מוצרים שאינם במלאי, והתעלם ממגבלות כתובת המשלוח. המשתמשים נטשו את הדיאלוג בהודעה השנייה, והתמיכה קיבלה את אותן שאלות באופן ידני.
התחלנו בבדיקה: ניתחנו לוג של כמה אלפי דיאלוגים, סימנו היכן התשובה סטתה מהמסלול, וחילקנו את השגיאות לשלושה סוגים — הצבה שגויה של נתוני ההזמנה, אובדן הקשר בין ההודעות, וחריגה מגבולות התפקיד.
לאחר מכן כתבנו מחדש את הפרומפט המערכתי: קבענו את התפקיד והגבולות, הוספנו בדיקת עובדות חובה על ההזמנה לפני מתן תשובה, ותיארנו את ההתנהגות בעת חוסר בנתונים — שאלת הבהרה במקום ניחוש. בנפרד הרכבנו סט של דיאלוגים לדוגמה והרצנו דרכו כל גרסה חדשה של הפרומפט.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור התשובות הרלוונטיות | 68% | 94% |
| דיאלוגים שהושלמו עד הסוף | 41% | 73% |
| פניות לתמיכה בנושא ההזמנה | רמת בסיס | −38% |
| חזרה לעוזר בסשן הבא | 22% | 47% |
העלייה בשימור המשתמשים כאן היא תוצאה, ולא משימה נפרדת: כאשר העוזר הפסיק לטעות בשאלות פשוטות, המשתמשים החלו לפתור דרכו את מה שקודם לכן הלכו לחפש באופן ידני. נקודה חשובה — הפרומפט אינו סטטי.
הטמענו הרצת רגרסיה על הדיאלוגים לדוגמה לפני כל שחרור, וכן כלל: כל שינוי במודל או בלוגיקת הצבת הנתונים עובר בדיקה על סט זה. בלי זה, הדיוק מתדרדר בתוך כמה עדכונים.
קייס מהפרקטיקה של הצוות שלנו — הפרטים תחת NDA, הנתונים מובאים לפי מדידות פנימיות בתקופה דומה.
במה שונה הנדסת פרומפטים מכיוונון עדין של המודל?
הנדסת פרומפטים וכיוונון עדין של המודל פותרים משימה אחת — לגרום לעוזר להשיב בטון, בפורמט ובמסגרת הנושאים המותרים הרצויים — אך פועלים ברבדים שונים. הנדסת פרומפטים משנה את ההוראה: הודעת מערכת, תיאור התפקיד, דוגמאות שיחה, כללי סירוב ופורמט התשובה.
המודל נשאר כשהיה, ורק מה שמוזן לו כקלט משתנה. כיוונון עדין משנה את משקולות המודל עצמן על גבי מערך דוגמאות מוכן — וההתנהגות מתקבעת ברמת הפרמטרים.
ההבדל מתבטא באופי המשימה. אם יש צורך לקבוע סגנון, מבנה תשובה, להגביל את תחום הנושאים, להוסיף כמה עשרות דוגמאות של תגובות «נכונות» — די בכך ברמת הפרומפטים, והתיקונים מבוצעים בתוך דקות בלי בנייה מחדש ופריסה חוזרת.
כיוונון עדין נדרש כאשר הכללים נעשים רבים מדי, הם מתנגשים זה עם זה, והמודל בכל זאת «נסחף» בתרחישים נדירים: אז נאספות אלפי דוגמאות, והאימון מעביר את החוקיות אל המשקולות.
המגבלות של הגישות הן מראה זו לזו. פרומפטים אינם בחינם מבחינת הקשר: ככל שיש יותר הוראות ודוגמאות, כך הבקשה ארוכה יותר וכך גבוהים השהיה והצריכה בכל קריאה.
כיוונון עדין מסיר חלק מהעומס הזה, אך דורש מערך נתונים מתויג, מחזור אימון והרצה חוזרת של בדיקות בכל עדכון — ולכן גדלים הזמן עד לשחרור ועלות התמיכה.
בפועל, הבחירה כמעט תמיד הולכת מפרומפטים לעידון נוסף, ולא להפך. תחילה ממצים את המקסימום מההוראות והדוגמאות, מודדים באילו תרחישים האיכות יורדת, ורק אם הירידה יציבה ומאושרת במטריקות — עוברים לכיוונון עדין. סדר הפוך משמעו אימון על משימה שהובנה היטב שלא כהלכה וסבבי עבודה מיותרים.
קיים גם מצב היברידי: המודל הבסיסי מעודן על דומיין צר, בעוד כללי ההתנהגות, הטון והפורמט הקונקרטיים נשארים בפרומפטים — כך קל יותר לשנות את המוצר בלי אימון מחדש. אנחנו מתחילים מפרומפטים ומטריקות איכות, וההחלטה על עידון נוסף מתקבלת לפי נתונים, ולא לפי אינטואיציה.
ספקות טכניים נפוצות
הנדסת פרומפטים עבור אסיסטנט היא לא "אוסף של ביטויים מוצלחים", אלא שכבה מנוהלת בין המודל למוצר. להלן שאלות הנדסיות שעולות לרוב בדיון טכני, וכיצד אנו סוגרים אותן.
כיצד מובטח יציבות התשובות של האסיסטנט בעת עדכון המודל?
הפרומפטים מנוהלים בגרסאות יחד עם הקוד, ולא נערכים "על חי" בממשק. לפני העלאה, ענף המודל החדש מורץ על סט תרחישי ייחוס: שאילתות טיפוסיות, ניסוחים גבוליים, ניסיונות להסיט את האסיסטנט מהמסלול. אם שיעור התשובות הנכונות יורד מתחת לסף, השחרור נחסם, והפרומפט מושלם. כך עדכון המודל לא הופך להפתעה עבור המשתמשים.
מה עם אבטחת פרומפטים והגנה מפני דליפות?
הוראת המערכת נשמרת בשרת ולעולם אינה נשלחת לאפליקציית הלקוח — באפליקציה קיימת רק שאילתת המשתמש. סודות ומפתחות גישה מועברים לאחסון מאובטח, בטקסט הפרומפט הם אינם נמצאים.
בנפרד אנו סוגרים ניסיונות לשלוף את ההוראה או לעקוף את המגבלות: שאילתות חשודות מסוננות, והתשובות עוברות בדיקה לתוכן אסור.
כיצד הפתרון מתרחב עם גידול בעומס?
שכבת הפרומפטים מופרדת מהלוגיקה של האפליקציה, ולכן עומדת בגידול במספר המשתמשים ללא כתיבה מחדש. שאילתות נשמרות במטמון במקומות שבהם התשובה אינה תלויה בהקשר, ותרחישים כבדים מועברים לתור. עם גידול בקהל המשתמשים מתווספים משאבים, ולא נבנית מחדש לוגיקת האסיסטנט.
כיצד נשלטת האיכות לאחר ההשקה?
אנו מנהלים יומן שאילתות ותשובות, מתייגים מקרים כושלים והופכים אותם לבדיקות חדשות. מדדים — שיעור התשובות הנכונות, מספר הסירובים, זמן התגובה — גלויים על הדשבורד. זה מאפשר לתקן את הפרומפט נקודתית, ולא לכתוב מחדש את האסיסטנט כולו.
תארו את המשימה — נחזור עם הערכה ותוכנית לשכבת הפרומפטים עבור המוצר שלכם.
נדון במשימה שלך ונחזור עם תוכנית
כדי להציע מבנה עבודה, עלינו להבין את מצבו הנוכחי של העוזר: אילו תרחישים הוא כבר מכסה, היכן הוא מגיב באופן לא יציב, ואילו בקשות מועברות לנציגים. תאר את המשימה בצורה חופשית — זה מספיק כדי לחזור עם הערכה ותוכנית הטמעה.
הנדסת פרומפטים מתחילה לא מטקסט ההוראות, אלא מניתוח שיחות אמיתיות ומהגבולות שמהם העוזר אינו אמור לחרוג.
בהמשך נציע מבנה: אילו תרחישים נכסה ראשונים, היכן נדרשים מגבלות קשיחות על פורמט התשובה, והיכן — שאלות הבהרה למשתמש. בנפרד נדון כיצד העוזר יתנהג כאשר הנתונים חלקיים, כאשר יש התנגשות בין הוראות, ובבקשות שמחוץ לתחום אחריותו.
מה כולל תוכנית ההטמעה:
- ניתוח התרחישים הנוכחיים וסוגי הפניות האופייניות של משתמשים;
- מפת תפקידים של העוזר: מה הוא עושה בעצמו, מה הוא מבהיר, ומה הוא מעביר לאדם;
- מבנה ההוראות לכל תרחיש עם כללים לפורמט התשובה;
- סט שיחות בדיקה וקריטריוני קבלה לכל תרחיש;
- סדר ההטמעה: מתרחיש אחד ועד כיסוי מלא ללא עצירת האפליקציה;
- תקנון לתיקוני הוראות לאחר ההשקה ונקודות בקרת איכות;
- הערכת העבודה לפי שלבים עם לוחות זמנים ברורים ותחומי אחריות.
מצדנו ניתן המלצות לגבי אילו תרחישים כדאי להטמיע ראשונים, ואילו להשאיר בינתיים לנציגים — הדבר מפחית את הסיכון לחוויה שלילית כבר בהתחלה. תאר את המשימה ואת התרחישים הנוכחיים של העוזר: נחזור עם הערכת העבודה ותוכנית לשלבים הבאים.