תהליך ה-"dreaming" של מפתח פועל פעמיים ביום, ומצמצם יומן אירועים גולמי של סוכן LLM למאגר זיכרון קומפקטי ומאומת, תוך צמצום משמעותי של הוצאות ה-tokens. הטריק הזה חשוב מכיוון שרוב מערכות הסוכנים עמוסים את זיכרון העבודה שלהם בכל פרט שהם רואים, מה שמוביל במהירות לסתירות, הקשר שנשכח ועלויות API מתנפחות.

למה זיכרון חשוב לסוכני LLM

סוכני LLM מתייחסים לכל בקשת משתמש, קריאה לכלי (tool call) או תצפית פנימית כאל "אירוע" חדש. הגישה הנאיבית מצרפת כל אירוע ל-prompt שמניע את ההחלטה הבאה. בפועל, זה ממלא את ה-prompt ברעש, מאלץ את המודל להעריך מחדש עובדות מיושנות ודוחף את השימוש ב-tokens לרמת התמחור הגבוהה ביותר. התוצאה: יותר שגיאות וחשבון נסתר שעולה עם כל אינטראקציה.

איך עובד תהליך ה-"dreaming" הלילי

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

  • Reflect – LLM סורק צבירים של אירועים קשורים, מציע עובדות תמציתיות ומתעד אילו אירועים תומכים בכל הצעה.
  • Score – ה-pipeline בודק האם לעובדה יש מספיק אירועים תומכים והאם האירועים הללו מרווחים מספיק בזמן כדי להיות אמינים.
  • Judge – שתי בדיקות תקינות (sanity checks) מוודאות שהעובדה החדשה אינה סותרת זיכרון קיים ושהיא אינה כפולה.

עובדות שעוברות את כל הבדיקות מקודמות ל-זיכרון קבוע. אלו שלא עמדו בסטנדרטים מגיעות ל-תור בדיקה (review queue), שם מפעיל אנושי יכול לאשר או לדחות אותן בלחיצת מקש אחת. כל אישור יוצר commit בסגנון git, המעניק עקבות ביקורת (audit trail) מלאים של מה השתנה בזיכרון ומתי.

תובנות הנדסיות מרכזיות

  • פרידה בין כתיבה לעבודה. תנו לסוכנים לשפוך כל תצפית ליומן; תנו לתהליך ייעודי להחליט מה נשאר.
  • התמקדות בסירוב, לא ביצירה. יצירת רעיונות היא זולה; מניעת זיהום הזיכרון היא החלק הקשה.
  • בקרת אדם בנקודת הבקרה הזולה ביותר. טיוטה אוטומטית ולאחריה אישור ידני מהיר עדיפה על אוטונומיה מלאה מבחינת עלות ובטיחות.
  • הגבלת הוצאות tokens בכל מחזור. הגבלה קשיחה על מספר ה-tokens בכל הרצת dreaming עוצרת הוצאות מופרזות.
  • ביקורת על כשלים שקטים. אם שלב אחד מפעיל כללים שונים מהשלב הבא, נתונים עלולים להיעלם מבלי שיבחינו בכך; בדיקות מפורשות יתפסו את חוסר ההתאמה.

חסרונות פוטנציאליים

הרצת תהליך האיחוד (consolidation) במצב offline יוצרת השהיה: הסוכן לא יראה עובדות שאומתו לאחרונה עד למחזור ה-"dream" הבא. באפליקציות בעלות קצב תנועה מהיר הדורשות למידה מיידית, עיכוב זה עלול להוות חיסרון. המערכת מסתמכת גם על בודק אנושי יחיד; אופן הרחבת תור הבדיקה מבלי לנפח את עלויות העבודה נותר שאלה פתוחה.

מה כדאי לעקוב אחריו בהמשך

מפתחים הנספים עם סוכני LLM צריכים לנטר את חשבונות ה-tokens ואת יומני השגיאות לאיתור סימנים של "זיהום זיכרון" (memory pollution) – הצהרות חוזרות או סותרות שניתן לייחס להן הצטברות של אירועים גולמיים. הוספת תהליך dreaming מעניקה כפתור שליטה (knob) קונקרטי להורדת העלויות הללו, תוך קבלת היסטוריית זיכרון ניתנת לביקורת. ככל שיותר צוותים יאמצו את מודל ה-split-log, יופיעו ככל הנראה כלים שיעשו אוטומציה לשלבי ה-reflect-score-judge וישתלבו עם בקרת גרסאות, מה שיהפוך את הגישה מפחות מותאמת אישית (bespoke) ליותר "חבר ונגן" (plug-and-play). האיזון (trade-off) בין מיידיות לניקיון יקבע עד כמה תהליך ה-"dreaming" הלילי יהפוך לחלק סטנדרטי בארכיטקטורה של סוכני LLM.