Inference-Time Compute — למה יותר זמן חשיבה עשוי לשפר את התוצאה
מאת צוות מדיה דיל · 12.08.2026 · Model Economics · 6 דק׳
מדריך למנגנון שמאחורי inference-time compute: מתי חשיבה ארוכה יותר בזמן ריצה באמת משפרת דיוק, מתי היא לא עוזרת בכלל, ואיך למדוד את התועלת השולית שלה.
צוות הנדסה שבדק שיפור דיוק במודל agentic גילה תוצאה שנראית סותרת: הגדלת budget החשיבה מ-2,000 ל-16,000 טוקן שיפרה משמעותית את הביצועים במשימות דיבוג קוד ותכנון רב-שלבי, אבל לא הזיזה כמעט כלום בשאלות עובדתיות על מוצר פנימי — המודל פשוט "חשב יותר" על מידע שאין לו, והמשיך לייצר את אותה תשובה שגויה בביטחון גבוה יותר. זה ההבדל המכריע שרוב הצוותים מפספסים: inference-time compute הוא כלי נהדר לפתור reasoning gap — פער בין המידע הקיים לבין המסקנה הנכונה ממנו — אבל הוא לא כלי לפתור knowledge gap, כלומר מידע שפשוט לא נמצא במודל או בהקשר שסופק לו. להבין את ההבדל הזה זה התנאי הראשון לפני שמשקיעים כסף באסטרטגיית inference-time compute.
שני סוגי כשל, שני פתרונות שונים
כשמודל טועה, הטעות נובעת בדרך כלל מאחת משתי סיבות שונות מהותית. הראשונה היא כשל היסק: כל המידע הדרוש לתשובה הנכונה נמצא ב-context, אבל המודל לא "עיבד" אותו נכון — פספס תלות בין שני נתונים, קפץ למסקנה מוקדם מדי, או ביצע חישוב שגוי. הסוג הזה של כשל מגיב מצוין להארכת זמן חשיבה, כי בעצם נותנים למודל עוד "צעדים" לתקן את עצמו, בדיוק כמו שאדם שעובר על פתרון פעם שנייה לאט יותר תופס טעויות שפספס בריצה מהירה.
הסוג השני הוא כשל ידע: המידע הרלוונטי פשוט לא קיים אצל המודל — לא באימון ולא ב-context שסופק. במקרה כזה, תוספת זמן חשיבה לא עוזרת, ולפעמים אפילו מזיקה, כי המודל "ממציא" נימוקים ארוכים ומשכנעים יותר סביב תשובה שגויה, מה שמקשה על גילוי הטעות בבדיקה ידנית. הפתרון לכשל ידע הוא לא budget גדול יותר אלא context טוב יותר — retrieval מדויק, כלים שמביאים מידע עדכני, או fine-tuning על הדומיין הספציפי. זיהוי נכון של סוג הכשל הוא בדיוק מה שקובע אם משקיעים בהגדלת Dynamic Reasoning Budget או בשיפור מקורות המידע.
עקומת ה-scaling: תשואה פוחתת ולא ליניארית
מחקרי scaling על inference-time compute מראים עקביות מפתיעה: הדיוק עולה בערך באופן לוגריתמי ביחס לכמות טוקני החשיבה, לא ליניארי. כלומר הכפלת ה-budget מ-1K ל-2K טוקנים עשויה להוסיף כמה נקודות אחוז דיוק, אבל הכפלה נוספת מ-2K ל-4K תוסיף פחות, ומ-16K ל-32K לרוב כמעט כלום על אותה משפחת בעיות. זה בדיוק כמו עקומת למידה אנושית: הקריאה השנייה של מסמך תופסת הרבה, הקריאה החמישית כמעט לא מוסיפה.
המשמעות התפעולית היא שיש נקודת "ברך" בעקומה שממנה והלאה תוספת budget היא כמעט טהורה כעלות בלי תועלת. הדרך המעשית למצוא את הנקודה הזו היא לא ניחוש אלא מדידה אמפירית על סט משימות מייצג: מריצים אותו סט בקטגוריות budget שונות (למשל 1K, 4K, 16K, 64K), מודדים דיוק בכל רמה, ומאתרים את הנקודה שבה תוספת של פי 4 בעלות מניבה פחות מ-2%-3% שיפור בדיוק. מעבר לנקודה הזו, אין הצדקה כלכלית להמשיך להעלות budget כברירת מחדל — רק כמסלול אסקלציה נדיר למשימות קריטיות.
דוגמה מספרית ממחישה את זה היטב: נניח שבמדגם של 500 משימות דיבוג, budget של 2K טוקנים נותן 61% הצלחה, 8K נותן 74%, 32K נותן 80% ו-128K נותן 82%. העלות ב-128K גבוהה פי 64 מהעלות ב-2K, אבל השיפור בדיוק הוא רק 21 נקודות אחוז, ורוב השיפור הזה כבר מומש בקפיצה הראשונה ל-8K. מי שמפעיל budget של 128K כברירת מחדל על כל 500 המשימות משלם פי כמה עשרות מהעלות האופטימלית תמורת פחות מ-10% שיפור נוסף מעבר ל-8K — בדיוק הפער בין החלטה מבוססת נתונים לבין החלטה אינטואיטיבית של "יותר זה תמיד יותר טוב".
שלוש שיטות למינוף inference-time compute
מעבר להארכת שרשרת החשיבה הפשוטה, יש כמה טכניקות מבוססות לניצול compute בזמן ריצה, וכל אחת עם profile עלות/תועלת שונה:
- Chain-of-thought ארוך — פשוט לתת למודל "לחשוב בקול" יותר לפני תשובה סופית. זול יחסית ליישום, אבל הכי רגיש לתקרת ה-scaling שתוארה למעלה.
- Self-consistency / Best-of-N — מריצים את אותה שאלה N פעמים במקביל בטמפרטורה מסוימת, ובוחרים בתשובה שחוזרת הכי הרבה פעמים (majority vote) או עוברת אימות. זה מכפיל עלות פי N באופן ליניארי, אבל לרוב משפר דיוק בצורה יציבה יותר מהארכת chain-of-thought בודד, כי הוא "ממצע" טעויות אקראיות.
- Tree search / deliberation מובנה — המודל בונה כמה מסלולי פתרון חלקיים, מעריך אותם תוך כדי, וממשיך רק במסלולים המבטיחים. יקר ביישום ובתשתית, אבל יעיל במיוחד במשימות עם מרחב חיפוש גדול כמו תכנון רב-שלבי.
לא כל שיטה מתאימה לכל בעיה. Best-of-N דורש דרך זולה ומהירה להשוות בין תשובות מועמדות — בדיוק התפקיד שממלאים Verifier Models ייעודיים, שיכולים לדרג תשובות מועמדות בשבריר מהעלות של יצירתן.
מתי לא כדאי להשקיע ב-inference-time compute
יש מקרים שבהם ההשקעה הנכונה היא לא בזמן ריצה אלא לפני זה. אם קטגוריית משימות שלמה סובלת מכשל ידע חוזר — למשל שאלות על מדיניות פנימית שמשתנה לעיתים רחוקות — ה-ROI הגבוה יותר הוא ב-retrieval מדויק או אפילו fine-tuning ממוקד, לא בהגדלת budget חשיבה על כל בקשה. באופן דומה, אם המשימה היא בעצם lookup פשוט (״מה הסטטוס של הזמנה X״), אין שום סיבה להריץ שרשרת חשיבה ארוכה — זו בדיוק המשימה שכדאי לנתב למודל קטן וזול, כפי שמתואר ב-הנדסת עלויות AI.
הכלל המעשי: inference-time compute הוא תחליף טוב להשקעה בזמן אימון רק כשמדובר בבעיית היסק אמיתית עם כל המידע הדרוש כבר זמין. בכל מקרה אחר, זו דרך יקרה להסוות בעיה שצריך לפתור במקום אחר — בין אם בשכבת ה-retrieval, בין אם באיכות ה-prompt, ובין אם בבחירת המודל הנכון מלכתחילה.
אבחון נכון בין שני סוגי הכשל דורש תשתית מדידה, לא ניחוש. הדרך המעשית היא לתייג כל תשובה שגויה שחוזרת מהמערכת לפי מקור הכשל — האם המידע היה זמין ולא נוצל נכון, או שהמידע פשוט חסר — ולעקוב אחרי ההתפלגות הזו לאורך זמן. קטגוריה עם רוב כשלי היסק היא מועמדת טובה להשקעה ב-inference-time compute; קטגוריה עם רוב כשלי ידע היא מועמדת להשקעה ב-retrieval, בכלים חיצוניים או במודל ייעודי. בלי ההפרדה הזו, קל מאוד לשפוך כסף על budget חשיבה גדול יותר ולקבל בתמורה כמעט שום שיפור מדיד.
תגיות: Inference-Time Compute · Test-Time Scaling · Chain-of-Thought · Best-of-N · Model Economics