ניתוח מחקר · המקורות נבדקו ב־7 בנובמבר 2026
סוכן שזוכר כלל פריסה ישן עלול להקשות יותר מסוכן ששואל שוב. מבחינת צוות הנדסי, השאלה השימושית היא האם ההקשר שנשמר מסייע למשימה הבאה, והאם אפשר לתקן אותו. בדיקת קבלה קטנה יכולה להפוך את השאלה הזו למעשית.
מה דיווחה Anthropic?
מחקר זיכרון הסוכנים של Anthropic מ־6 בנובמבר עוסק בהקשר מתמשך, ולא בעדכון משקולות. ב־25 שאלות על מסמכי Stainless, חיפוש בלבד עמד ב־53% מהקריטריונים שנבדקו; חיפוש עם ויקי מפותח הגיע ל־61%, לעומת 48% לויקי בלבד. במשימת מסמכים משפטיים אחרת לא נמצא יתרון ברור לויקי. ההכנה דרשה חישוב משמעותי. אלה בדיקות של הספק למשימות מסוימות, והן אינן מוכיחות שיפור כללי בייצור או חיסכון כולל. לא שחזרנו אותן באופן עצמאי.
מחקר ותיעוד מוצר עונים על שאלות שונות
התיעוד הנפרד של Memory tool מתאר ממשק בצד הלקוח: Claude מבקש פעולות בקבצים, והיישום מבצע אותן באחסון שבשליטתו. תיאור המימוש אינו הבטחת ביצועים או הכרזה על תכונה חדשה במסגרת המחקר.
בסקירת מערכת, בקשו ראיות משני בעלי תפקידים: האחראי ליישום צריך להסביר כיצד המידע נשמר ומופרד, והאחראי להערכה צריך להראות האם המידע שנשמר משפר את העבודה המיועדת. שם מוצר או הגדרה מופעלת אינם עונים על שתי השאלות.
בדיקת תיקון מוצעת
זהו דף עבודה הנדסי מקורי, ולא בדיקה שביצענו ל־Claude או לשירות אחר. התחילו במסמכים סינתטיים בסביבה שאינה סביבת ייצור. אל תכניסו למערך הבדיקה רשומות לקוחות, פרטי גישה או שיחות פרטיות.
- הגדירו משימה חוזרת אחת. למשל, בקשו מעוזר להסביר את נוהל הפריסה המאושר לשירות דמיוני. כתבו מראש את התשובה הצפויה ואת ההפניות הנדרשות. כללו שאלות שמצריכות מסמך אחד ושאלות שמצריכות כמה מסמכים, כדי שממוצע מוצלח לא יסתיר קטגוריה חלשה.
- צרו השוואה הוגנת. השתמשו באותה גרסת מודל, באותם מסמכי מקור וכלים ובאותו תקציב משימה, פעם עם חיפוש בלבד ופעם עם זיכרון. חזרו על המקרים ושמרו גם ניסיונות שנכשלו. הפרידו את שאלות המבחן הסופי מהדוגמאות ששימשו לכוונון ההוראות לכתיבת הזיכרון.
- שנו עובדה במקור המוסמך. במערך הבדיקה, החליפו את הכלל ״פורסים ביום שלישי״ בכלל מתוארך ״פורסים ביום חמישי״. השאירו בכוונה את ההערה הישנה. שאלו שוב ובדקו האם הסוכן מוצא את העדכון, מסביר את הסתירה ומעדכן או מוציא משימוש את ההערה המיושנת. לאחר מכן פתחו שיחה חדשה וחזרו על השאלה.
- בדקו את גבול הסמכות של הערה. הכניסו למסמך סינתטי משפט שנראה כהוראה, למשל בקשה לדלג על שלב אישור. ודאו ששמירתו או סיכומו אינם הופכים תוכן מקור להרשאה. בנפרד, בדקו שמשתמש דמיוני אחד אינו יכול לשלוף הערות של משתמש אחר.
- בדקו הסרה והתאוששות. הסירו עובדה סינתטית בתהליך הנתמך של היישום. בדקו מה נשאר במאגר הפעיל, בסיכומים שנגזרו ממנו ובתוצאות האחזור. תעדו מגבלות של שמירת מידע, במקום להניח שהיעדר תוצאת חיפוש מוכיח מחיקה בכל מקום.
ספרו את מלוא עלות התפעול
תעדו איכות תשובות, תדירות של תשובות מיושנות, זמן תגובה, שימוש במודל וקריאות לכלים בכל תצורה. כללו את העבודה של יצירת ההערות, רענונן והטיפול בעדכונים שנכשלו. הציגו את העלויות עבור מספר משימות מוגדר. תשובה זולה יותר אחרי הכנה יקרה עדיין עשויה להיות מועילה, אבל היקף השימוש החוזר הצפוי צריך להצדיק זאת.
קבעו את תנאי ההצלחה לפני שתראו את התוצאות. נקודת פתיחה סבירה היא היעדר חשיפת מידע בין משתמשים במערך הבדיקה, טיפול נכון בכל שינוי מדיניות מכוון ושיפור מדוד באיכות במסגרת תקציב הצוות. בדיקה קטנה אינה אישור אבטחה ואינה חוזה את כל ההתנהגות העתידית; היא יכולה לחשוף תכנון שכבר נכשל בדרישות הבסיס שלו.
התוצר צריך להיכנס לעמוד אחד: התצורה שנבדקה, גרסאות המסמכים, תוצאה לכל מקרה, העלות הכוללת שנמדדה, כשלים ידועים ואחראי לבדיקה הבאה. כך המהנדס הבא מקבל בסיס שאפשר לשחזר ולבחון לפני שהזיכרון משתלב בתהליך עבודה בייצור.