אילון אוריאל: Chain of Thought (CoT) – איך לגרום למודל “לחשוב בקול רם” ולשפר תוצאות מתמטיות (בלי לשבור את הראש)

אם יצא לך לבקש ממודל שיפתור תרגיל במתמטיקה והוא ענה תשובה שנשמעת בטוחה בעצמה כמו מישהו שמזמין “קפה על בסיס אינטואיציה” – אז כן, אתה מכיר את הבעיה: לפעמים התוצאה נכונה, לפעמים כמעט נכונה, ולפעמים… מעניינת. כאן בדיוק נכנס Chain of Thought (CoT): טכניקה שנועדה לגרום למודל לעבוד בצורה יותר מסודרת, שלב-אחר-שלב, כדי להעלות משמעותית את הסיכוי לפתרון אמין.

אבל רגע לפני שמתחילים: חשוב לדעת משהו עדכני מהעולם האמיתי של מודלים שאותו מסביר אילון אוריאל. בהרבה מערכות מודרניות לא תמיד תקבל “מחשבה בקול רם” מלאה של המודל (ולפעמים גם לא כדאי), אבל כן אפשר לקבל את היתרונות של CoT דרך ניסוחים חכמים, דרך מבנה פתרון, דרך בדיקות ביניים, ודרך מה שנקרא Reasoning Scaffolds – פיגומים לחשיבה.

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

למה דווקא CoT? כי מתמטיקה אוהבת סדר (ואגו פחות)

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

CoT עוזר בעיקר ב:

• בעיות רב-שלביות: אלגברה, גיאומטריה, הסתברות, בעיות מילוליות

• תכנון פתרון לפני ביצוע: להחליט איזה נוסחה, איזה טריק, איזה פירוק

• מעקב אחרי יחידות, תחומים, סימנים, הנחות

• הפחתת “קפיצות” מחשבה שמייצרות טעויות

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

אז מה זה CoT בפועל? (רמז: לא “תסביר לי”)

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

יש כמה סגנונות:

• CoT מפורש: model מציג שלבים גלויים (לא תמיד זמין/רצוי בכל מערכת)

• CoT מובנה: אתה מבקש מבנה פתרון קבוע (שלבים, ואז תשובה)

• CoT סמוי + תוצר נקי: המודל “חושב” אבל מציג רק מסקנות/שלבים מסוכמים

• Self-check: פתרון ואז בדיקה שיטתית של התוצאה

הנקודה החשובה: המטרה היא לא לקרוא רומן. המטרה היא אמינות.

הפרומפט המנצח: 7 מרכיבים שעושים סדר בבלגן

במקום “תפתור”, תן למודל מסגרת עבודה. הנה תבנית שעובדת מעולה למתמטיקה:

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

2. נתונים והנחות: לרשום מה ידוע, ומה מניחים (למשל: x חיובי? זוויות במעלות?).

3. אסטרטגיה: לבקש לבחור דרך פתרון לפני חישוב.

4. צעדים ממוספרים: שלבים מסודרים, בלי דילוגים.

5. בדיקות ביניים: למשל: לבדוק יחידות, סימנים, תחומים.

6. תשובה סופית בפורמט קבוע: למשל: “תשובה: ___”.

7. אימות: להציב בחזרה / להשוות לשיטה שנייה / sanity check.

דוגמת פרומפט “שובר שוויון”: פתור את הבעיה הבאה. קודם תכתוב: (א) רשימת נתונים והנחות (ב) תכנית פתרון קצרה (2–4 שורות) (ג) פתרון בשלבים ממוספרים (ד) בדיקת נכונות מהירה (ה) תשובה סופית בשורה אחת

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

3 שדרוגים שמקפיצים דיוק במתמטיקה (כן, גם בלי קסמים)

1) “אל תפתור מהר” – תבקש תכנון לפני ביצוע

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

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

2) “בדוק את עצמך” – אימות בסוף

מתמטיקה טובה היא מתמטיקה שנבדקה.

דוגמה: אחרי שמצאת תשובה, תבצע בדיקה: הצבה חזרה, בדיקת קצוות, או הערכה מקורבת.

3) “תן לי פורמט” – פורמט מפחית טעויות

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

פורמטים מומלצים:

• שלב 1, שלב 2, שלב 3…

• טבלה של משתנים

• “Known / Unknown / Plan / Steps / Check / Final”

הטריק של “תוצאה ואז נימוק קצר”: כשלא צריך מגילה

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

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

זה נותן:

• קריאות

• פחות מקום לבלבול

• עדיין יש “עקבות חשיבה” סבירות

בעיות מילוליות: המקום שבו CoT עושה קסמים (בקטע טוב)

בעיות מילוליות הן מוקש, כי יש בהן תרגום שפה → מתמטיקה.

מה לבקש:

• לתרגם את הסיפור למשוואות

• להגדיר משתנים במפורש

• לבדוק הגיון: האם התשובה גדולה מדי/קטנה מדי?

תבנית קצרה לבעיות מילוליות:

• הגדר משתנים

• בנה משוואות

• פתר

• בדוק מול הסיפור

• תן תשובה עם יחידות

אל תוותר על “יחידות”. יחידות הן כמו חגורת בטיחות: לא תמיד צריך, אבל כשצריך – מציל.

מתי CoT נכשל (ואיך הופכים את זה לניצחון קטן)?

CoT לא מבטיח שלמות. הוא משפר תהליך, אבל אם יש:

• מספרים גדולים עם חישוב ידני ארוך

• בעיה טריקית עם הנחה נסתרת

• ניסוח עמום …אז עדיין יכולה לברוח טעות.

איך מטפלים בזה:

• בקש פתרון בשתי שיטות שונות ולהשוות

• בקש “מצא את הטעות האפשרית הנפוצה כאן”

• בקש לבצע בדיקה נומרית מהירה

• חלק את הבעיה לתת-בעיות (מודולים קטנים)

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

זה עובד טוב במיוחד בבעיות עם סימנים מינוס, שברים, תחומים, או הסתברות.

כמה פרומפטים מוכנים שאתה יכול להעתיק ולהדביק (ולקצור מחמאות)

1) למתמטיקה כללית

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

2) לאלגברה

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

3) להסתברות

הגדר מרחב מדגם, אירועים, ואז חשב. בסוף תבדוק שהתוצאה בתחום 0–1.

4) לגיאומטריה

ציין משפטים/עובדות שאתה משתמש בהם, צייר תיאור מילולי קצר (מי מקביל למי), ואז פתר. בסוף בדיקת היגיון: האם האורך/זווית הגיוניים?

5) לשאלות עם הרבה חישוב

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

שאלות ותשובות (כי ברור שאלה הדברים שכולם שואלים)

• שאלה: האם תמיד כדאי לבקש “תחשוב בקול רם”?

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

• שאלה: מה ההבדל בין “תסביר” לבין CoT?

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

• שאלה: למה המודל לפעמים טועה בחשבון בסיסי?

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

• שאלה: איך משפרים תוצאות בשאלות עם מלכודות ניסוח?

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

• שאלה: מה הטיפ הכי חזק לשיפור אמינות?

• תשובה: “פתרון + בדיקה בשיטה אחרת”. גם אם השיטה השנייה קצרה, עצם ההשוואה מורידה טעויות.

• שאלה: איך להימנע מתשובה סופית יפה אבל לא נכונה?

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

• שאלה: האם CoT עוזר גם בבעיות תיכון/אוניברסיטה?

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

סיכום קצר שמיישר קו (ובא לך לנסות מיד)

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

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