Context Budgeting — כיצד מחלקים נכון את חלון ההקשר

מאת צוות מדיה דיל · 12.08.2026 · Context Engineering · 5 דק׳

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

צוות שבנה סוכן תמיכה טכנית גילה תופעה מוזרה: הסוכן עבד מצוין בבדיקות עם שיחות קצרות, אבל אחרי עשרה-חמישה עשר תורות התחיל "לשכוח" הנחיות שהוגדרו לו בתחילת השיחה — כללי טון, מדיניות החזרים, פורמט תשובה. הבעיה לא הייתה בפרומפט עצמו, אלא בכך שאיש לא הגדיר במפורש כמה מקום כל רכיב בחלון ההקשר מקבל. תוצאות כלים, קטעי RAG שהתארכו וההיסטוריה שהצטברה פשוט דחקו את ה-system prompt למקום שבו המודל שם עליו פחות משקל. זו בדיוק הבעיה ש-Context Budgeting בא לפתור: להתייחס לחלון ההקשר כמשאב מוגבל עם הקצאה מתוכננת מראש, ולא כמיכל שממלאים עד שהוא מתפוצץ.

למה "יש עוד מקום" הוא קריטריון גרוע

הגישה הנאיבית ביותר לניהול הקשר היא לבדוק רק אם עברנו את מגבלת הטוקנים של המודל, ולהוסיף תוכן כל עוד יש מקום פנוי. הבעיה היא שמגבלת הטוקנים הפורמלית (128K, 200K, ואפילו מיליון) רחוקה מאוד מה"תקציב האפקטיבי" שבו המודל עדיין מתפקד היטב. תופעה שתועדה שוב ושוב היא ירידה הדרגתית באיכות התשובות ככל שההקשר מתמלא, גם כשעדיין רחוקים ממגבלת הטוקנים הפיזית — נושא שמפורט לעומק במאמר על Context Rot. המשמעות המעשית: תקציב הקשר לא צריך להיות מוגדר לפי "כמה נכנס", אלא לפי "כמה שומר על ביצועים אמינים".

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

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

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

• System prompt וכללי יסוד — כ-3%-5% מהתקציב. חייב להישאר קבוע וקצר; אם הוא צומח, זה סימן אזהרה לניפוח לא מבוקר.
• הגדרות כלים (tool schemas) — כ-10%-15%. כל כלי נוסף מייקר את כל תור, גם אם לא נעשה בו שימוש בפועל, ולכן זו שכבה שדורשת גיזום תקופתי.
• הקשר משוחזר (RAG / מסמכים) — כ-30%-40%, עם דגש על relevance ולא רק על נפח. ראו הרחבה בנושא שליפה מדורגת במאמר על Just-in-Time Context.
• היסטוריית שיחה / תוצאות כלים — כ-20%-30%, עם מנגנון דחיסה או קיצוץ פעיל, כמתואר במאמר על Context Compaction.
• שמורת פלט (output reserve) — תקציב קבוע שנשמר ריק מראש כדי שהתשובה עצמה לא תיחתך באמצע.

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

אכיפה בזמן ריצה: מי נדחק כשהתקציב נגמר

תקציב בלי אכיפה הוא מסמך עיצוב, לא מנגנון. המימוש בפועל דורש שכבת ניהול שרצה לפני כל קריאה למודל, בודקת כמה טוקנים כל שכבה צורכת בפועל, ומחליטה מה קורה כשחורגים מהתקרה. סדר הפעולות הנפוץ הוא: קודם מקצצים תוצאות כלים ישנות שכבר לא רלוונטיות להחלטה הנוכחית, אחר כך מפעילים compaction על היסטוריית השיחה (ראו הרחבה במאמר על Context Compaction), ורק כמוצא אחרון נוגעים ב-system prompt או במסמכי ה-RAG הקריטיים ביותר.

function enforceBudget(sections, limits) {
  for (const s of ["toolResults", "history", "retrieval"]) {
    while (tokenCount(sections[s]) > limits[s]) {
      sections[s] = dropLeastRelevant(sections[s]);
    }
  }
  return sections;
}

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

ניטור: תקציב שאף אחד לא בודק הוא תקציב שנשבר בשקט

בלי dashboard שמראה ניצול תקציב בפועל לפי שכבה, לאורך זמן, אף אחד לא ישים לב כשתוצאות כלים מתחילות לתפוס 60% מההקשר במקום 20%. מדדים שכדאי לעקוב אחריהם: אחוז ניצול תקציב לכל שכבה בפילוח לפי סוג משימה, תדירות אירועי חיתוך (trimming events), ומתאם בין רמת ניצול לאיכות התשובה — אם יש לכם evals, כדאי לבדוק אם דיוק יורד כשתקציב ה-retrieval עובר סף מסוים. שילוב עם prompt caching מוסיף עוד שיקול: שינויים תכופים בתחילת ההקשר (כמו system prompt דינמי) שוברים cache hits, ולכן כדאי לתכנן את סדר השכבות כך שהחלקים היציבים ביותר יישארו בתחילת הקשר וייהנו מ-caching, בעוד הרכיבים הדינמיים מתווספים בסוף.

מתי תקציב קשיח מזיק

לא כל מערכת צריכה תקציב מפורט. עוזר צ'אט פשוט עם שיחות קצרות ובלי כלים מרובים לא ירוויח הרבה מהשקעה בתשתית budgeting — זה over-engineering. הסף שבו כדאי להשקיע הוא כשיש שילוב של שיחות ארוכות, ריבוי כלים, ו-RAG פעיל בו-זמנית; שם, בלי תקציב מפורש, כמעט תמיד יקרה שהמערכת "תגמור" מקום בצורה בלתי צפויה בדיוק בשיחה החשובה ביותר. ראו גם את הסקירה הכללית של Context Engineering להקשר הרחב יותר של איך תקציב הקשר משתלב בשאר שכבות התכנון.

תבנית התחלה ומספרים לדוגמה

לצוות שמתחיל מאפס, הדרך הפשוטה ביותר היא לא לנסות לחשב תקציב "אופטימלי" מהיום הראשון, אלא לקבוע ערכי ברירת מחדל סבירים ולכוונן אותם לפי נתונים אמיתיים. עבור סוכן עם חלון הקשר של 200K טוקנים, נקודת פתיחה סבירה יכולה להיראות כך: כ-6,000 טוקנים ל-system prompt, כ-20,000 להגדרות כלים (בהנחה של כעשרה-חמישה עשר כלים בממוצע), כ-70,000 להקשר משוחזר, כ-50,000 להיסטוריית שיחה לפני שמופעל compaction, וכ-15,000 שמורים כ-output reserve, כשהיתרה משמשת כרווח ביטחון. המספרים האלה לא קדושים — הם רק בסיס למדידה. אחרי שבוע-שבועיים של תעבורה אמיתית, בודקים אילו שכבות באמת מתקרבות לתקרה שלהן ואילו נשארות עם מרווח גדול, ומכווננים בהתאם. הטעות הנפוצה ביותר בשלב הזה היא לכוונן פעם אחת ולשכוח — תקציב שנקבע בהתאם לדפוסי שימוש של החודש הראשון כמעט תמיד מתיישן כשהמוצר גדל ומשתמשים מתחילים להשתמש בו בדרכים שלא נצפו מראש.

תקציב שונה למשימות שונות

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

תגיות: Context Budgeting · Context Window · Token Allocation · LLM Agents · Prompt Caching · RAG

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