פרומפטינג Few-Shot: סיווג, חילוץ וסגנון ארגוני

מדוע few-shot פרומפטינג נשבר על נתונים אמיתיים

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

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

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

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

מה נותנת יצירה מבוקרת על בסיס דוגמאות

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

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

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

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

גישות לכוונון: דוגמאות, הוראות, אימון נוסף

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

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

השוואת גישות

את נפח סט הדוגמאות בוחרים לפי המחלקה הגרועה ביותר, לא לפי הממוצע: 5–15 דוגמאות למחלקה לבקשה, ומאה ומעלה לאימון נוסף. אם יש יותר קטגוריות, קודם בודקים היררכיה או סכימה דו-שלבית — רשימה שטוחה של 50+ מחלקות מאבדת דיוק ללא תלות במצב שנבחר.

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

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

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

ספריית דוגמאות, תבניות בקשות, תקנון

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

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

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

מקרה בוחן: סיווג פניות בזרימת בקשות

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

מה היה לפני ההטמעה

ארבעה מפעילים תייגו את התור והסתייגו בפרשנות: ההתאמה ביניהם עמדה על 80%, כלומר כל פנייה חמישית בתיוג חוזר עברה לקטגוריה אחרת. הזמן הממוצע מקבלת הבקשה ועד מינוי אחראי הגיע ל-6–8 דקות, וקטגוריות שנויות במחלוקת נדונו בפגישה משותפת — זה אכל חלק מהמשמרת.

מה שינו ומה יצא

כיווננו few-shot פרומפטינג: בבקשה הועברו 5–8 דוגמאות ייחוס לכל קטגוריה בתוספת כלל ביטחון נמוך — המודל לא מחליט בעצמו, אלא מסמן את הפנייה בדגל למפעיל. ספר הקטגוריות והתקנונים נשארו כשהיו, לא נדרש אימון נוסף, והאיכות נבדקה נוסף על גבי סט ציבורי Banking77.

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

במה few-shot שונה מאימון נוסף של המודל?

גישת few-shot לא משנה את משקולות המודל: אתם מתארים את המשימה במילים ומצרפים כמה דוגמאות מתויגות ישירות בבקשה. ההתנהגות משתנה כבר בקריאה הבאה — תיקון ניסוח או החלפת דוגמה אחת נותנים תוצאה חדשה בלי בנייה מחדש של המודל.

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

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

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

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

ספקות טכניים: איכות, נפח, תמיכה

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

מה לעשות עם קטגוריות נדירות שכמעט אין בהן דוגמאות?

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

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

איך לשנות ניסוחים וסטים של דוגמאות בלי השבתה?

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

נדון במשימה ונחזור עם תוכנית עבודה

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

מה עוזר בקלט:

• 30–50 דוגמאות אנונימיות של נתוני קלט עם ציון התשובה הצפויה — מהן נאסף סט ל-few-shot.
• רשימה של מחלקות יעד או שדות חילוץ והחלטה במקרים לא חד-משמעיים: לשייך למחלקה או להעביר לבדיקה.
• הפרומפט או הכללים הנוכחיים, אם כבר ניסיתם, ומה בדיוק היה שגוי — חזרות של שגיאות מראות היכן נדרשת גישה אחרת.
• מגבלות על נתונים: היכן הם נמצאים, האם אפשר לשלוח אותם לשירותים חיצוניים, למי יש גישה.
• פרופיל עומס: כמה בקשות בשעה, מהו עומס השיא ואורך הטקסט הממוצע.
• דרישות לפורמט התשובה — סכימה, שדות חובה, מה נחשב לשגיאה קריטית.
• קריטריון קבלה: איזה שיעור של תשובות נכונות על הסט שלכם נחשב לתקפה.

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

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