12/30פרק 12 מתוך 30

Chain of Thought, RLVR ו-Test-Time Compute — במדידה

אותן 24 בעיות: 0% נכונות ב-1.9 tokens, 100% ב-145. ואז self-consistency קונה חזרה דיוק שכבר היה ל-greedy decoding.

13 ביולי 2026עודכן 11 בספטמבר 202611 דקות קריאה

בעמוד הזה

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

ראשית, הוא התבקש לתת את התשובה:

TEXT

"...How many bolts are left?  Reply with only the final number, nothing else."

  0 / 24 correct        1.9 tokens per answer

ואז הוא התבקש לתת את התשובה, עם רשות לעבוד קודם:

TEXT

"...How many bolts are left?  Think step by step, then give the final
 number on its own line."

  24 / 24 correct       145.2 tokens per answer

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

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

המודל לא חושב. הוא מחשב זמן רב יותר.

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

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

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

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

פליטת tokens משנה את זה, והיא משנה את זה בשתי דרכים שונות שכדאי להפריד ביניהן:

יותר חישוב. כל token שנוצר הוא עוד מעבר קדימה מלא. מאה ארבעים וחמישה tokens של עבודה הם פי מאה ארבעים וחמישה אריתמטיקה ממתן תשובה ישירה.
זיכרון מוחצן. ה-tokens נכתבים אל ה-context, כך שהמעבר הבא יכול לקרוא אותם. 5 × 13 = 65 הופך לעובדה בקלט, לא לערך שהמודל חייב להחזיק באקטיבציה ולשאת קדימה. המודל משתמש בפלט של עצמו בתור דף טיוטה.

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

אין כאן צורך בשום דבר מיסטי, וזה מניב תחזית מוצקה: chain of thought אמור לעזור הכי הרבה בבעיות עם מבנה סדרתי — שבהן שלב שני צריך את התוצאה של שלב ראשון — והכי פחות בבעיות שהן שליפה יחידה. זה בדיוק מה שהספרות מוצאת, וזו הסיבה ש-"think step by step" לא עושה כלום עבור מהי בירת צרפת.

Chain of thought כטכניקת prompt

קישור למקטע: Chain of thought כטכניקת prompt

הטכניקה הגיעה ב-2022 בשני חלקים. Wei ואחרים הראו שהכללת דוגמאות פתורות ב-prompt — הדגמות שבהן לתשובה קודמת הנמקה — יצרה שיפורים גדולים במדדי אריתמטיקה והיגיון יומיומי.¹ אחר כך Kojima ואחרים הראו משהו מוזר יותר: לא צריך את הדוגמאות. הוספה של "Let's think step by step" ל-zero-shot prompt תופסת חלק גדול מאותו שיפור.²

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

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

Self-consistency, ותוצאה שהפתיעה אותי

קישור למקטע: Self-consistency, ותוצאה שהפתיעה אותי

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

במדידה על 16 מאותן בעיות, דגימה ב-temperature 0.8, הצבעת רוב על פני $n$ שרשראות:

$n$	דיוק	tokens מצטברים	tokens לכל בעיה
1	81 %	2,952	185
2	81 %	5,618	351
3	100 %	8,417	526
4	100 %	11,103	694
5	100 %	13,933	871

שש-עשרה בעיות הן מכנה קטן, והכלל של פרק 4 חל על הטבלה הזו בדיוק כמו על כל טבלה אחרת. 13 מתוך 16 הם 81 % עם רווח Wilson של 95 % בטווח [57, 93]; 16 מתוך 16 הם 100 % עם [81, 100]. הם חופפים. קראו את צורת העקומה, שהיא הממצא; אל תקראו את המדרגה המדויקת שבה היא משתטחת, דבר ששש-עשרה בעיות לא יכולות לאתר.

שני דברים יש בטבלה הזו, והשני הוא לא מה שציפיתי.

העקומה משתטחת ב- $n = 3$ . עד הדגימה השלישית הדיוק כבר בתקרה שלו, ושתי הדגימות הנותרות לא קונות כלום בזמן שהן עולות 172 tokens כל אחת, 345 יחד. זו הצורה של כל עקומת self-consistency שמדווחת בספרות, וזה קורה הרבה מוקדם יותר ממה שמסגור של "יותר דגימות זה יותר טוב" מרמז.

ו-greedy decoding כבר היה ב-100 %. הביטו שוב בתחילת הפרק: שרשרת אחת, בלי דגימה, 145 tokens, ‏24/24. דגימה ב-temperature 0.8 הורידה את הדיוק ל-81 %, ו-self-consistency נזקק לשלוש יצירות כדי לטפס בחזרה למקום שבו מעבר greedy יחיד כבר היה — ב-פי 3.6 tokens, או פי שישה אם מריצים את הסריקה עד חמש בלי לדעת איפה היא משתטחת.

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

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

Tree of thoughts, והעלות שלו בקריאות.

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

העלות היא מה שמונע ממנו להיות ברירת מחדל. Self-consistency עם $n = 5$ הוא חמש יצירות. עץ עם רוחב $b$ ועומק $d$ הוא עד $b^d$ מצבים, וכל מצב צריך לפחות יצירה אחת כדי להתרחב ולעיתים קרובות עוד אחת כדי להיות מוערך. התוצאות שפורסמו משתמשות בעשרות עד מאות קריאות מודל עבור תשובה אחת.

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

מלבקש ועד לאימון

קישור למקטע: מלבקש ועד לאימון

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

ה-post-training של פרק 11 היה צריך העדפות אנושיות, כי ל-"האם זו הייתה תשובה טובה?" אין תשובה תכנותית. אבל עבור חלק מהשאלות יש. תשובה מתמטית או שווה לערך הנכון או שלא. קוד או עובר את הבדיקות או שלא. הוכחה או נבדקת בהצלחה או שלא.

עבור תחומים כאלה אפשר להחליף את מודל התגמול ב-verifier, ומאותו רגע כל מה שמטה הזרם משתפר בבת אחת: בלי מתייגים, בלי התאמת Bradley–Terry, בלי reward hacking מהסוג שנמדד בפרק 11 — כי אי אפשר להחמיא ל-unit test. זה reinforcement learning from verifiable rewards, וזו המסגרת שעבורה GRPO נבנה: לדגום קבוצת ניסיונות פתרון לאותה בעיה, לבדוק כל אחד, ולהשתמש בציון הממוצע של הקבוצה כ-baseline. בלי critic, בלי מתייג, בלי מודל תגמול. רק תוכנית שאומרת נכון או לא נכון.

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

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

התוצאה שמסגרה מחדש את התחום הגיעה מ-DeepSeek בתחילת 2025.⁶ הם לקחו מודל בסיס והפעילו reinforcement learning עם verifiable rewards ישירות, בלי שלב supervised fine-tuning קודם — השלב שפרק 11 מציג כיסוד של הכול. שרשראות הנמקה ארוכות הופיעו בכל זאת. כך גם התנהגויות שאף אחד לא אימן אליהן: המודל החל לבדוק מחדש את הצעדים שלו, ובקטע המצוטט ביותר במאמר, לשקול מחדש באופן ספונטני גישה באמצע פתרון.

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

Reasoning tokens הם שורה בחשבון

קישור למקטע: Reasoning tokens הם שורה בחשבון

המשמעות המעשית של כל זה היא שמודל הנמקה מפיק tokens שביקשתם ו-tokens שלא ביקשתם, ואתם משלמים על שניהם.

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

רוב ה-APIs סופרים reasoning tokens בתוך ספירת ה-output tokens. החשבון שלכם ומגבלת max_tokens שלכם כוללים שניהם את החשיבה שאתם אף פעם לא רואים.
Gemini של Google מדווח על thinking tokens כשדה נפרד, מחוץ לספירת הפלט הסטנדרטית.

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

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

הציר השלישי.

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

Test-time compute הוא שלישי, והוא מתנהג אחרת משני האחרים: הוא מושקע לכל בקשה, אפשר לשנות אותו לכל בקשה, והוא נסחר ישירות מול latency ועלות במקום מול תקציב אימון. Snell ואחרים⁷ מראים שבחלק מהבעיות, תקציב חישוב קבוע קונה יותר דיוק כשהוא מושקע ב-inference מאשר כשהוא מושקע במודל גדול יותר — וזה הופך את ההנחה שהדרך לקבל תשובות טובות יותר היא מודל גדול יותר.

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

מתי "think step by step" מפסיק לעזור

קישור למקטע: מתי "think step by step" מפסיק לעזור

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

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

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

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

לאן זה ממשיך מכאן

קישור למקטע: לאן זה ממשיך מכאן

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

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

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

מקורות ושיטה

קישור למקטע: מקורות ושיטה

כל המדידות בפרק הזה מגיעות מ-Qwen/Qwen2.5-0.5B-Instruct על 24 בעיות מילוליות דו-שלביות שנוצרו, עם greedy decoding למעט במקומות שבהם מצוינת דגימה, ועם אפס יצירות שנחתכו במגבלות ה-token ששימשו. הן ניתנות לשחזור, והן מודל קטן על בעיות קלות: קראו את תוצאת ה-self-consistency כהדגמה של המנגנון, לא כ-benchmark. פרק 18 של הערות ההרצאה CS229 ופרק 12 של Hugging Face LLM Course מכסים שניהם את החומר הזה עם מודלים גדולים יותר ו-benchmarks ראויים.

הפניות

קישור למקטע: הפניות

Wei, J. et al. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. arXiv:2201.11903 (2022). ↩
Kojima, T., Gu, S. S., Reid, M., Matsuo, Y. and Iwasawa, Y. Large Language Models are Zero-Shot Reasoners. arXiv:2205.11916 (2022). תוצאת "let's think step by step". ↩
Wang, X. et al. Self-Consistency Improves Chain of Thought Reasoning in Language Models. arXiv:2203.11171 (2022). ↩
Yao, S. et al. Tree of Thoughts: Deliberate Problem Solving with Large Language Models. arXiv:2305.10601 (2023). ↩
Lightman, H. et al. Let's Verify Step by Step. arXiv:2305.20050 (2023). מציג את PRM800K, מערך הנתונים של 800,000 שלבים ל-process supervision. ↩
DeepSeek-AI. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948 (2025). תוצאת R1-Zero — reinforcement learning שהופעל ישירות על מודל בסיס, בלי שלב supervised fine-tuning — נמצאת בסעיף 2.2. ↩
Snell, C., Lee, J., Xu, K. and Kumar, A. Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters. arXiv:2408.03314 (2024). ↩