Dynamic Reasoning Budget — התאמת עומק החשיבה לכל משימה

מאת צוות מדיה דיל · 12.08.2026 · Model Economics · 6 דק׳

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

צוות תמיכה טכני שהטמיע סוכן AI מעל מערכת הטיקטים גילה תוך שבועיים תופעה מוזרה: חשבון ה-API עלה פי שלושה, אבל שביעות הרצון של הלקוחות לא זזה. הסיבה התבררה כשבדקו לוגים — כל שאלה, מ"מה שעות הפעילות שלכם" ועד "יש לי כשל מדורג בשלושה שירותים שתלויים זה בזה", עברה עם אותו budget_tokens קבוע של 32,000 טוקני חשיבה. השאלה הפשוטה קיבלה תשובה נכונה אחרי חשיבה של 400 טוקן בפועל, אבל המערכת "שילמה" על המקסימום כי כך הוגדר סטטית. במקביל, כמה מקרי הכשל המורכבים דווקא נחתכו לפני שהמודל סיים לרדת לשורש הבעיה, כי אפילו 32K לא הספיקו לשרשרת חשיבה עם חמישה שירותים מעורבים. זה בדיוק הכשל של budget קבוע: הוא גם מבזבז וגם חונק, בו-זמנית, על אותו dial.

המחיר הכפול של budget סטטי

כשמקצים reasoning budget אחיד לכל הבקשות, משלמים משני הכיוונים. בצד הבזבזני: מודלים עם extended thinking נוטים "למלא" את המרחב שהוקצה להם אם הוא גדול מדי, כלומר שאלה שדורשת 5 צעדי היסק תניב לפעמים 40 צעדים רק כי יש להם מקום. זה לא רק עלות כספית ישירה על טוקני חשיבה (שבחלק מהספקים מחויבים כמו טוקני פלט) — זה גם latency מיותר שמשפיע על UX בזמן אמת. בצד החונק: budget נמוך מדי גורם למודל לחתוך את שרשרת ההיגיון באמצע ולהחזיר מסקנה מוקדמת שלא עברה אימות מלא, מה שמוביל ל-retry, שמכפיל את העלות פעמיים או שלוש על אותה משימה בפועל.

הנתון שכדאי לעקוב אחריו הוא לא "עלות ממוצעת לבקשה" אלא ההתפלגות שלה. בארגון עם מיקס משימות אמיתי, לרוב 70%-80% מהבקשות הן פשוטות יחסית ודורשות מעט מאוד חשיבה, בעוד 5%-10% הן משימות מורכבות שדורשות פי עשרות מהתקציב הממוצע. budget קבוע שממוצע בין הקצוות האלה פשוט שגוי לשני הקצוות בו-זמנית, בדיוק כמו שממוצע גובה בין ילד לג'irafה לא אומר כלום.

איך בונים budget שמותאם למשימה

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

• סיווג משימה מראש — classifier קל (מודל קטן או אפילו heuristics מבוססי regex ואורך קלט) שמתייג את הבקשה כ"פשוטה", "בינונית" או "מורכבת" לפני שהיא בכלל מגיעה למודל היקר.
• היסטוריית הצלחה לפי סוג משימה — אם קטגוריית משימות מסוימת נכשלת שוב ושוב עם budget של 4K אבל מצליחה כמעט תמיד ב-16K, זה סיגנל כמותי לקבוע את ברירת המחדל שלה, ולא ניחוש.
• אסקלציה תוך-ריצה — מתחילים ב-budget נמוך, ואם ה-verifier או בדיקת confidence מזהים שהתשובה לא עברה סף איכות, מריצים שוב עם תקציב גבוה יותר במקום להגדיל תקציב לכולם מראש.

שילוב של שלושת הסיגנלים האלה מייצר מדיניות שמתעדכנת אוטומטית: משימות חדשות מתחילות עם budget סביר לפי סיווג, וקטגוריות שמראות שיעור אסקלציה גבוה מקבלות ברירת מחדל גבוהה יותר לאורך זמן. זו בדיוק הלוגיקה שמתוארת בהרחבה במאמר על Inference-Time Compute, שם מוסבר למה תוספת זמן חשיבה בכלל משפרת תוצאה, ומאיזו נקודה היא מפסיקה לתרום. חשוב שהמדיניות הזו תישמר כקונפיגורציה חיצונית ולא תיכתב hard-coded בקוד האפליקציה — כך אפשר לעדכן אותה כתוצאה מניתוח נתונים בלי דיפלוי חדש, ולבצע A/B test בין מדרגות budget שונות על אותה קטגוריית משימות.

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

הטעות הנפוצה היא לחשוב על budget כמתג "נמוך/גבוה". בפועל שווה להגדיר סולם עם 3-4 מדרגות, כל אחת עם budget_tokens קבוע וכל אחת "עולה" רק כשהקודמת נכשלה: למשל 0 טוקני חשיבה (תשובה ישירה) → 4,000 → 16,000 → 64,000. כל מדרגה שמדלגים אליה מכפילה עלות, ולכן חשוב מאוד שהאסקלציה תתבסס על בדיקת כשל אמיתית — לא רק "המודל לא בטוח מספיק", אלא בדיקה מבוססת verifier או כלל עסקי ברור. מאמר Verifier Models מתאר איך בונים את שכבת האימות הזו כך שהיא זולה ומהירה יחסית לקריאה המקורית, כדי שהאסקלציה עצמה לא תהיה צוואר הבקבוק.

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

כדי להמחיש את הסדר גודל: נניח 100,000 בקשות בחודש, שמתוכן 75% נפתרות במדרגה הראשונה (0-4K), 20% דורשות אסקלציה למדרגה השנייה (16K) ורק 5% מגיעות למדרגה העליונה (64K). גם אם עלות טוקן חשיבה קבועה, החלוקה הזו מוזילה את סך העלות החודשית פי 4-5 לעומת מדיניות שמריצה את כל הבקשות במדרגה העליונה "כדי להיות בטוחים". ההבדל הזה, מוכפל על פני מיליוני קריאות בשנה, הוא בדיוק הפער בין תמחור AI שמתכנס לרווחיות לבין תמחור שמכריח להעלות מחיר ללקוח כדי לכסות עלויות תפעול.

מדידה ובקרה שוטפת

בלי מדידה, מדיניות budget דינמית מתדרדרת חזרה ל"תני לכולם את המקסימום כדי להיות בטוחים". שלושה מדדים שכדאי להטמיע בדשבורד תפעולי: טוקני חשיבה ממוצעים לבקשה שנפתרה בהצלחה (לא רק לכל בקשה), שיעור האסקלציות למדרגה העליונה לפי קטגוריית משימה, ו-p95 latency מול עלות ל-1,000 בקשות. כשמדדים את זה יחד עם עקרונות הנדסת עלויות AI, מתקבלת תמונה שמאפשרת לכוונן את הסולם באופן שוטף במקום להגדיר אותו פעם אחת ולשכוח ממנו.

שווה גם לזכור ש-Dynamic Reasoning Budget לא מחליף ניהול טוב של הפרומפט והכלים עצמם. תקציב חשיבה גדול לא יתקן tool definitions מבולגנות או context עם מידע לא רלוונטי — הוא רק נותן למודל יותר "מקום" לתקן את עצמו סביב בעיה בסיסית שנשאר קיימת. לכן, לפני שמגדילים budget כפתרון קסם, שווה לוודא שהטוקנים שכן נשלחים למודל בכלל רלוונטיים, כפי שמתואר במאמר על Token Engineering. בפועל, הצירוף המנצח הוא context נקי ומצומצם יחד עם budget שמותאם דינמית — כל אחד מהם לבד פותר רק חלק מהבעיה, אבל יחד הם מייצרים מערכת שגם זולה משמעותית וגם עומדת בסטנדרט איכות גבוה יותר מאשר budget קבוע וגדול.

תגיות: Dynamic Reasoning Budget · Extended Thinking · budget_tokens · Inference Cost · Model Economics

← חזרה לבלוג · צור קשר