ניהול זיכרון ו-Context Window: מעבר ל-RAG פשוט
איך מנהלים זיכרון ארוך-טווח (Long-Term Memory), מתי כדאי להשתמש ב-Graph Memory ומתי ב-Vector Store, ואיך מונעים שכחה קטסטרופלית.
שלוש שכבות זיכרון
זיכרון עובד (Working) — מה שיש עכשיו ב-context window: הודעות אחרונות, מצב משימה נוכחי. יקר ומצומצם. הכל שנכנס לכאן משולם בכל תור מחדש.
זיכרון זמני (Episodic) — מה קרה באינטראקציה הזו: סיכומים, החלטות, טעויות שתוקנו. נשמר מחוץ לחלון ונשלף בעת הצורך.
זיכרון סמנטי (Semantic) — עובדות קבועות על המשתמש/המערכת: העדפות, סכימות, מושגי domain. לרוב ב-Vector Store או מסד נתונים מובנה.
רוב המערכות שנכשלות נכשלות כי הן מנסות לדחוס הכל לשכבה הראשונה — ואז או שהחלון נגמר או שהחשבונית מזנקת.
RAG לבד לא מספיק
RAG פותר שליפה של מסמך קרוב לשאלה. הוא לא פותר שמירת מצב (State) בין שלבים, ולא מניעת שכחה של מה שסוכן למד לפני שלושה צעדים. שליפה וזיכרון הם שתי מערכות שונות, ובלי להפריד ביניהן מקבלים סוכן שיודע לצטט מסמכים אבל לא זוכר מה הוחלט בשיחה.
בתוך השליפה עצמה — היברידית תמיד: וקטורים + מילות מפתח + סינון מטא-דאטה. שאילתה וקטורית טהורה מחזירה דמיון סמנטי, לא בהכרח את התשובה הנכונה. מזהים מספר תעודה או שם מוצר מדויק — זה job לחיפוש מילולי, לא ל-embeddings.
Graph memory — מתי ומתי לא
Graph Memory מנצח כשיש יחסים בין ישויות (מי יצר מה, מה תלוי במה) ושאלות שצריך לעבור בהן דרך כמה קשרים — multi-hop. דומיינים קלאסיים: פיננסים, משפט, codebase עם תלויות, CRM מורכב. הוא מפסיד כשיש בעיקר מסמכים עצמאיים — שם וקטורים זולים יותר, מהירים יותר ופשוטים יותר.
כלל אצבע: התחילו ב-Vector + מסד נתונים יחסי, והוסיפו graph רק כשסוג מחזורי אחד של שאלות לא נפתר טוב בשליפה הקיימת. רוב הסוכנים בייצור מתחילים ב-vector, מוסיפים שכבה אפיזודית כשהסשנים מתארכים, ורק מיעוט מגיע לגרף.
ניהול החלון: compaction שלא מאבד �מידע
ההיסטוריה גדלה עד שהיא פוגעת במסגרת או בתקציב. הפתרון הנפוץ בייצור בנוי משלושה אזורים:
- System prompt + הגדרת המשימה — נשארים מילה במילה, תמיד.
- N התורים האחרונים — נשמרים מילה במילה, לקוהרנטיות.
- כל מה שמעליהם — מוצא מהחלון ומוחלף בסיכום.
הטריגר: בסביבות 60–70% ניצולת החלון. לא 95% — כי סיכום שנוצר אחרי שהמודל כבר "נרקב" בעומס הוא בעצמו מדולדל.
והטעות הגדולה: לסכם את הכל מחדש בכל פעם. הדפוס הנכון הוא סיכום מצטבר — מסכמים רק את הקטע שזה עתה הוצא מהחלון וממזגים אותו לסיכום הקיים, במקום לבנות מחדש את כל הנרטיב. זה גם חוסך כסף וגם מונע סחיפה של עובדות.
מניעת שכחה קטסטרופלית
סיכום אגרסיבי של ההיסטוריה היא הדרך המהירה לאבד מידע. במקום: סיכום נצבר + שמירת עובדות מפתח מחוץ לחלון (נתיבי קבצים, החלטות, תוכנית עבודה) + יכולת להחזיר את המקור מהאחסון בעת הצורך (rehydrate). הסיכום הוא index, לא מקור האמת.
מדדו את זה: benchmark ששואל שוב ושוב על עובדות שהסוכן למד מוקדם ב-session. אם התשובות מידרדרות אחרי compaction — הסיכום שלכם בוגד בכם, ועדיף לגלות את זה בבדיקה מאשר אצל לקוח.
רוצה להעמיק את הנושא אצלך בצוות?
סדנאות מעשיות והרצאות שמבוססות על הניסויים מהשטח — כולל קוד חי ותרגול.
בואו נדבר