Agent Memory Architecture — Short-Term, Long-Term, Semantic ו-Episodic Memory

מאת צוות מדיה דיל · 09.08.2026 · AI · 7 דק׳

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

משתמש חוזר לצ'אטבוט שירות לקוחות בפעם השלישית באותו שבוע, ומספר בכל פעם מחדש את אותו הקשר — כי הסוכן "לא זוכר" אותו. באותו זמן, Agent פנימי שמבצע משימת קידוד ארוכה מאבד את ההקשר ברגע שהשיחה חוצה את חלון ה-token, וחוזר על אותה טעות שוב ושוב. שני התרחישים חושפים את אותה בעיה: מודל שפה, בפני עצמו, הוא חסר מצב (stateless) לחלוטין — כל קריאה מתחילה מאפס, ומה שנראה כמו "זיכרון" הוא בכלל תשתית חיצונית שבונים סביב המודל. Agent Memory Architecture היא ההנדסה של התשתית הזו: מה שומרים, איפה, לכמה זמן, ואיך שולפים אותו בחזרה בזמן שהוא רלוונטי.

למה "זיכרון" הוא בעצם בעיית אחזור מידע

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

ארבעת סוגי הזיכרון

• Short-Term Memory (זיכרון עבודה) — היסטוריית השיחה הנוכחית, בדרך כלל פשוט מוזרקת ישירות לחלון ההקשר. מוגבל בגודלו על ידי חלון ה-token, ונעלם ברגע שהשיחה מסתיימת אלא אם הוא נשמר במפורש.
• Long-Term Memory (זיכרון ארוך טווח) — מידע ששורד בין שיחות: העדפות משתמש, עובדות שנלמדו, החלטות קודמות. נשמר באחסון חיצוני קבוע ונשלף לפי רלוונטיות לשיחה הנוכחית.
• Semantic Memory (זיכרון סמנטי) — ידע כללי, עובדתי, לא תלוי הקשר זמני — למשל "המשתמש עובד בתחום הפיננסים" או מדיניות ארגונית. דומה במבנה למאגר RAG קלאסי.
• Episodic Memory (זיכרון אפיזודי) — זיכרון של אירועים ספציפיים שקרו: "בשיחה הקודמת המשתמש ביקש לבטל הזמנה אבל התחרט". שימושי במיוחד ל-Agents שצריכים ללמוד מדפוסי אינטראקציה חוזרים לאורך זמן.

לא כל מערכת זקוקה לכל ארבעת הסוגים. צ'אטבוט שירות פשוט לרוב מסתפק ב-Short-Term ו-Long-Term בסיסי (העדפות). Agent מחקרי ארוך טווח נהנה מ-Episodic Memory כדי ללמוד מטעויות עבר. הבחירה צריכה לנבוע מהצורך העסקי, לא מ"כדי שיהיה מתקדם יותר".

מנגנון ניקוד ודירוג זיכרונות

לא כל זיכרון שווה באותה מידה, ולכן מערכות בשלות מדרגות זיכרונות לפי כמה גורמים: עדכניות (זיכרון מלפני שעה רלוונטי יותר מזיכרון מלפני שנה, בהנחות שוות אחרות), תדירות גישה (זיכרון שנשלף שוב ושוב כנראה חשוב יותר), וimportance מוצהר (המשתמש עצמו סימן משהו כחשוב, או שהמערכת זיהתה אותו כהחלטה מחייבת). דירוג משוקלל כזה, בשילוב עם דמיון סמנטי לשאילתה הנוכחית, נותן שליפה הרבה יותר מדויקת מאשר הסתמכות על דמיון וקטורי בלבד — בדיוק כמו ש-Reranking משפר תוצאות RAG רגיל.

איך בונים את זה בפועל: אחסון ושליפה

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

-- טבלת long-term memory פשוטה עם pgvector
CREATE TABLE agent_memory (
  id UUID PRIMARY KEY,
  user_id UUID NOT NULL,
  memory_type TEXT CHECK (memory_type IN ('preference','fact','episode')),
  content TEXT NOT NULL,
  embedding VECTOR(1536),
  importance FLOAT DEFAULT 0.5,
  created_at TIMESTAMPTZ DEFAULT now(),
  last_accessed_at TIMESTAMPTZ
);
-- שליפה: top-k לפי דמיון, עם משקל ל-importance ולעדכניות

החלטת ארכיטקטורה מרכזית: מתי לכתוב לזיכרון

שני דפוסים עיקריים: כתיבה מפורשת (explicit) — הסוכן עצמו מחליט מה שווה לזכור ומריץ קריאה ייעודית לשמירה, נותן שליטה מדויקת אך מוסיף עומס reasoning; וכתיבה אוטומטית (implicit) — תהליך רקע מנתח שיחות ומחלץ מהן זיכרונות שווים בלי מעורבות הסוכן בזמן אמת. הגישה האוטומטית זולה יותר בזמן ריצה אך מסוכנת יותר — היא עלולה "לזכור" מידע לא רלוונטי או שגוי בלי בקרה. שילוב נפוץ: Agent מסמן מועמדים לזיכרון תוך כדי שיחה, ותהליך רקע נפרד מסנן ומאשר לפני כתיבה קבועה.

שילוב זיכרון עם Multi-Agent

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

מחיקה, Right to be Forgotten ותקינה

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

Trade-offs: עלות, פרטיות ורלוונטיות

• עלות אחסון ושליפה — כל שיחה שנשלפת דורשת embedding וקריאה למאגר וקטורי, מה שמוסיף latency ועלות לכל תור שיחה.
• פרטיות ורגישות מידע — זיכרון ארוך טווח פירושו החזקת מידע אישי לאורך זמן, מה שמעלה שאלות רגולטוריות ודורש מדיניות מחיקה ברורה (right to be forgotten), נושא שמתקשר לניהול סודות ו-AI ולאבטחת מידע בעידן ה-AI.
• זיכרון "מזהם" — מידע שגוי או מיושן שנשמר בזיכרון ארוך טווח יכול להטעות שיחות עתידיות; נדרש מנגנון פקיעה (TTL) או עדכון.
• Recall מול Precision — שליפת יותר מדי זיכרונות "ליתר ביטחון" מנפחת את ההקשר בדיוק כמו RAG רגיל, ופוגעת באיכות במקום לשפר אותה.

טעויות נפוצות בבניית זיכרון לסוכנים

• שמירת כל דבר "ליתר ביטחון" — מאגר זיכרון שגדל בלי סינון הופך לרעש שמקשה על שליפה מדויקת; לא כל מה שנאמר שווה זכירה.
• העדר מנגנון פקיעה — מידע שהיה נכון לפני חצי שנה (למשל "המשתמש עובד בחברה X") עלול להיות שגוי היום; זיכרון בלי TTL או בדיקת עדכניות מסתכן במידע מיושן שמוזרק כעובדה.
• בלבול בין זיכרון למאגר RAG כללי — ערבוב מידע אישי-דינמי עם ידע כללי-סטטי באותו מאגר מקשה על ניהול הרשאות ומחיקה נפרדת בעת בקשת פרטיות.
• העדר ניקוד importance — כשכל הזיכרונות שווים במשקל, השליפה מחזירה תערובת של מידע קריטי ומידע שולי ללא הבחנה.
• שכפול זיכרון בין סוכנים ללא סנכרון — במערכות Multi-Agent, אם כל סוכן מנהל זיכרון נפרד בלי מקור אמת משותף, נוצרים פערי מידע וסתירות בין סוכנים שונים שמדברים עם אותו משתמש.

דוגמה מהשטח

מערכת ליווי לקוחות B2B הוסיפה Long-Term Memory כדי שהסוכן "יזכור" העדפות תקשורת והחלטות קודמות של כל לקוח. הגרסה הראשונה שמרה כל הודעה כפוטנציאל זיכרון, מה שיצר מאגר עמוס במידע שולי וגרם לירידה באיכות התשובות כי הסוכן שלף לעיתים זיכרונות לא רלוונטיים. השינוי שתיקן זאת: הגבלת כתיבה לזיכרון רק למידע שסומן מפורשות כ"חשוב" (העדפות מוצהרות, החלטות מחייבות), יחד עם ציון importance שדועך עם הזמן אלא אם הזיכרון נגיש שוב. התוצאה הייתה מאגר קטן יותר אך משמעותית יותר רלוונטי.

שאלות נפוצות

האם זיכרון ארוך טווח תמיד משפר את התוצאות?

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

מה ההבדל בין Agent Memory לבין RAG רגיל?

RAG שולף ממאגר ידע חיצוני קבוע (תיעוד, מסמכים). Agent Memory שולף ממאגר שנבנה מתוך האינטראקציות עצמן ומשתנה כל הזמן — הוא דינמי ואישי, לא סטטי וכללי.

איך מוחקים זיכרון כשמשתמש מבקש זאת?

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

כמה זיכרון "רב מדי"?

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

האם צריך מאגר וקטורי ייעודי לזיכרון, או אפשר להשתמש באותו מאגר כמו RAG?

ניתן להשתמש באותה תשתית טכנית, אך מומלץ להפריד לוגית (namespace, טבלה נפרדת) בין זיכרון אישי-דינמי לבין מאגר ידע כללי-סטטי, כדי לא לערבב בטעות מידע אישי בשליפה כללית.

איך בודקים שמנגנון הזיכרון עובד כמו שצריך?

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

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

תגיות: Agent Memory · Long-Term Memory · Episodic Memory · Semantic Memory · Vector Database · AI Agents

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