יישום פרומפטים בשיטת Chain-of-Thought (CoT) עבור LLM

Chain-of-Thought פרומפטינג: מדוע התשובות אינן יציבות

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

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

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

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

מה נותן חשיבה מנוהלת: השפעות מדידות

חשיבה מנוהלת אינה «מודל חכם יותר», אלא סדר שלבים שהוגדר מראש, שאותו המודל עובר עד למסקנה. במשימות רב-שלביות זה משנה את דיוק התשובות, את החזרתיות שלהן ואת היקף הבדיקה הידנית.

שיעור התשובות הנכונות במשימות רב-שלביות

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

חזרתיות: קלט זהה — פלט צפוי

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

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

כמה בדיקה ידנית נחסכת

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

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

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

להלן ארבעה מצבים והמגבלות שלהם.

מתי תשובה ישירה מספיקה

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

מתי נדרשת בדיקה במעבר שני

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

סדר העבודות: מניתוח משימות ועד מסירה

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

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

סימון חשיבה תקנית

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

בדיקה על מדגם מושהה

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

מה נשאר אצלכם: ספריית פרומפטים ותקנונים

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

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

כיצד נשמרות ומתעדכנות קבוצות הפרומפטים

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

מקרה בוחן: כיצד גדל דיוק התשובות בניתוח בקשות

מה היה לפני

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

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

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

מה קרה אחרי

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

• שיעור המסקנות הנכונות — 94% לעומת 68% לפני העיבוד מחדש;
• תיקון ידני — פנייה אחת מתוך חמש עשרה במקום כל פנייה שלישית;
• זמן הניתוח הצטמצם מ-12 ל-4 דקות לפנייה;
• הסלמות למומחה בכיר — פי שלושה פחות.

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

במה שונה חשיבה צעד-אחר-צעד מבדיקה עצמית?

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

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

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

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

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

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

ספקות טכניים נפוצים ומגבלות

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

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

האם דוגמאות חשיבה בפרומפט הן חובה?

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

כיצד למדוד את האפקט, ולא להאמין על סמך מילה?

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

האם ניתן להעביר פרומפטים לתרחיש אחר?

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

נדון במשימה: מה להבהיר לפני ההתחלה

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

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

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