גיזום קונטקסט וסוכני Retrieval

תוכן מלא

## הבעיה

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

השאלה הטובה יותר היא לא: *איך לשמור יותר?*
אלא: *איך להביא פנימה רק את מה שעדיין באמת ראוי להיות פעיל עכשיו?*

## שינוי המודל המנטלי

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

## למה retrieval צריך להיות תפקיד נפרד

בהרבה מערכות, אותו סוכן מנסה גם:
- לחפש
- לשלוף
- לסנן
- לחשוב
- לענות

וזה יוצר עומס. ארכיטקטורה בריאה יותר היא:

**retrieval/search subagent → evidence set → reasoning/generation agent**

כך מפרידים בין:
- מציאת evidence
- הערכת רלוונטיות
- יצירת התשובה

## מה סוכן retrieval צריך לעשות

סוכן retrieval טוב צריך:
- לפרק את בעיית החיפוש
- לאסוף candidate evidence
- להסיר כפילויות
- לזרוק פריטים ישנים או חלשים ברלוונטיות
- לשמור רק את ה-evidence הכי שימושי לשלב הבא

ברוב המקרים הוא **לא** צריך להיות הסוכן שעונה סופית.

## כללי גיזום קונטקסט

heuristics טובים כוללים:
- להסיר כפילויות
- להסיר evidence ישן, אלא אם הוא חשוב היסטורית
- לשמור פריטים שמשרתים את המטרה הנוכחית, לא רק את הנושא הרחב
- להפריד בין background context ל-active evidence
- להעדיף חומרים עם מקור על פני summaries מוסקים
- לשמור רישום של מה נגזם, גם אם הוא לא עובר הלאה

## שלוש שכבות זיכרון

### Tier A — Active context
מה שהמודל צריך עכשיו.

### Tier B — Retrievable working memory
חומר שאפשר להביא אם צריך.

### Tier C — Archival memory
היסטוריה שמורה שלא אמורה להיכנס לקונטקסט הפעיל בלי סיבה חזקה.

הטעות היא להתייחס לכל שלוש השכבות כאילו הן אמורות לשבת יחד באותו prompt.

## מה לא לבלבל

### Pruning זה לא forgetting
להוציא משהו מהקונטקסט הפעיל זה לא למחוק אותו לנצח.

### Summarization לא תמיד מספיק
סיכומים יכולים לעזור, אבל הם גם עלולים להסתיר evidence חשוב. לפעמים צריך selective retention, לא compression.

## השלכות על מערכות סוכנים אישיות

אם בונים סוכנים לעצמך, לחברים או למשפחה:
- לא דוחפים את כל ההיסטוריה לתוך ה-prompt
- שולפים לפי רלוונטיות נוכחית
- שומרים את הקונטקסט הפעיל קטן ועשיר באות
- מפרידים בין personal memory לבין current evidence

## השלכות על CoachOS

CoachOS במיוחד צריך להימנע מ-raw memory dumps.

הוא צריך שכבת retrieval שמסוגלת להבדיל בין:
- מה חשוב לרגע האימוני הזה
- מה useful background
- מה רק היסטוריה ארכיונית

אחרת continuity הופך מרווח לתובנה לרעש שמבלבל.

## המלצה פרקטית

כשמתכננים מערכת סוכנים, כדאי להוסיף retrieval layer או subagent כאשר:
- המשימה תלויה בהרבה היסטוריה
- השאלה היא multi-hop
- יש הרבה מקורות אפשריים
- קונטקסט לא נכון יכול להסיח את המודל

מערכת טובה היא לא זאת עם ערימת הזיכרון הכי גדולה.
היא זאת שיודעת להציף evidence נכון בצורה נקייה.