Context Rot — למה ביצועי סוכן יורדים ככל שהשיחה מתארכת

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

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

צוות שבדק סוכן מחקר פנימי מצא ממצא שהטריד אותו: אותה שאלה בדיוק, כשנשאלת בתחילת שיחה, מקבלת תשובה נכונה ב-95% מהמקרים. כשאותה שאלה בדיוק נשאלת בתור ה-25 של שיחה ארוכה, עם אותו מידע רלוונטי עדיין נגיש בהקשר, אחוז ההצלחה צונח ל-70%. שום דבר לא "נשכח" באופן טכני — הטוקנים הרלוונטיים עדיין נמצאים בחלון ההקשר, בתוך מגבלת הטוקנים הפורמלית. זו בדיוק התופעה שמכונה Context Rot: ירידה הדרגתית באיכות ובאמינות התשובות ככל שההקשר גדל, גם כשאין שום חריגה ממגבלה פורמלית. זו לא בעיית קיבולת — זו בעיית איכות שימוש בקיבולת.

שלוש סיבות מוכחות ל-Context Rot

הראשונה היא lost-in-the-middle: מחקרים חוזרים ונשנים מראים שמודלים נותנים משקל תשומת לב גבוה יותר למידע שנמצא בתחילת ההקשר ובסופו, ופחות למידע שקבור באמצע. שיחה ארוכה שבה עובדה קריטית נאמרה בתור 15 מתוך 40 נמצאת בדיוק באזור הסיכון הזה. השנייה היא הצטברות מסיחים (distractors): כל תוצאת כלי, כל ניסיון כושל, כל שינוי כיוון באמצע השיחה נשאר בהקשר ומתחרה על תשומת הלב עם המידע הרלוונטי לתשובה הנוכחית. ככל שיש יותר "רעש" כזה, כך גדל הסיכוי שהמודל ייתפס לפרט לא רלוונטי. השלישית היא מידע סותר שלא עודכן — אם בתור 5 נאמר "נשתמש ב-PostgreSQL" ובתור 20 הוחלט לעבור ל-MySQL, אבל ההצהרה הראשונה נשארת בהקשר בלי סימון מפורש שהיא בוטלה, המודל עלול "לפצל את ההבדל" בין השניים בצורה שלא הגיונית לאף אחד.

למה זה שונה מ"נגמר לנו מקום"

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

מדידה: איך יודעים שיש בעיה בכלל

הדרך הכי אמינה לזהות Context Rot היא לא לחכות לתלונות משתמשים אלא לבנות eval שמדמה אותה במכוון: לוקחים משימה קבועה עם תשובה נכונה ידועה, ומריצים אותה בכמה "עומקי הקשר" שונים — למשל אותה שאלה מוטמעת בתור 1, בתור 10, בתור 30 של שיחה מדומה עם תוכן ניטרלי מסביב. גרף שמראה את שיעור ההצלחה כפונקציה של עומק ההקשר הוא הכלי האבחוני החזק ביותר, כי הוא חושף בדיוק את הנקודה שבה הביצועים מתחילים לקרוס — ולא כל המודלים והמשימות מתנהגים אותו דבר. משימות שדורשות שליפת עובדה בודדת (needle-in-haystack) בדרך כלל עמידות יותר מאשר משימות שדורשות סינתזה של כמה עובדות שמפוזרות לאורך ההקשר.

for depth in [1, 10, 20, 30, 40]:
  transcript = buildSyntheticHistory(depth, fillerTurns)
  transcript.insert(criticalFact, atTurn=3)
  result = runAgent(transcript, question)
  log(depth, result.correct)

מיטיגציה: לא רק "לדחוס יותר"

הטעות הנפוצה ביותר היא לחשוב ש-compaction לבדו פותר Context Rot. compaction עוזר בכך שהוא מקטין את כמות הרעש הכולל, אבל אם הסיכום עצמו לא ממוקם נכון או לא מודגש, הבעיה יכולה לחזור בצורה אחרת. שלוש טכניקות שמתמודדות עם התופעה ישירות: מיקום מחדש — הזזת המידע הקריטי ביותר לתחילת או לסוף ההקשר באופן יזום לפני כל קריאה, לא רק להשאיר אותו איפה שהוא "נחת" כרונולוגית; סימון מפורש של ביטול — כשמשהו שנאמר קודם כבר לא תקף, לסמן זאת במפורש ("הוחלף בהחלטה מתאריך X") במקום להשאיר את הסתירה גלויה; בידוד תת-משימות — כשמשימה מורכבת מכמה שלבים עצמאיים, להריץ כל שלב בהקשר נקי משלו (למשל דרך sub-agent) במקום לצבור הכל בשיחה אחת ארוכה, כפי שנפוץ בארכיטקטורות שמפורטות במאמר על ארכיטקטורת זיכרון סוכנים.

מתי Context Rot לא באמת הבעיה

לא כל ירידה בביצועים לאורך שיחה היא Context Rot — לפעמים המשימה עצמה נהיית קשה יותר ככל שמתקדמים (שלבים מאוחרים תלויים ביותר החלטות קודמות), ולפעמים הבעיה היא פשוט prompt לא ברור מלכתחילה. לפני שמשקיעים בתשתית מיטיגציה, כדאי לוודא עם ה-eval שתואר למעלה שאכן מדובר בירידה שתלויה בעומק ההקשר ולא במורכבות המשימה עצמה — אחרת פותרים בעיה שלא קיימת ומפספסים את הבעיה האמיתית.

הבדלים בין מודלים ובין ספקים

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

תפקיד הפורמט: מבנה קבוע נגד רעש

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

תגיות: Context Rot · Lost in the Middle · LLM Evaluation · Context Window · Agent Reliability

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