Muse Wonder זוכר בין שיחות — שאלות השליטה נשארות

Meta הציגה ב־12 באוקטובר 2026 את Muse Wonder ואת Muse Wonder Full, עם יכולת Active Memory שנועדה להחזיר מידע רלוונטי משיחות קודמות גם כשהעבודה נמשכת לאורך זמן. Wonder זמין למפתחים דרך Meta Model API ו־Muse Code, ואילו Full זמין למנויי Muse Code. ההבטחה לזיכרון מתמשך מעלה מיד שאלה מעשית: מי קובע מה נשמר בין שיחות ומה קורה לפרט שכבר אינו דרוש?

לפי TechCrunch, השימוש ב־Wonder דרך ה־API מתומחר ב־4 דולרים למיליון אסימוני קלט וב־20 דולרים למיליון אסימוני פלט; חוקרת Meta קביה קופראפו תיארה את טווח הזיכרון המבוקש במילים “over days, weeks, months, and beyond”. זהו תיאור של יעד המוצר, ולא פירוט של תקופת שמירת נתונים שהובטחה למשתמשים או של בקרות מחיקה. ההבחנה הזאת חשובה במיוחד למי ששוקל לחבר לסוכן יומן, הודעות או מסמכים.

מה Active Memory אמור לזכור

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

הזיכרון הזה קשור ליכולת נוספת שנקראת Active Focus. היא נועדה לסייע לסוכן להמשיך במשימה כשמתעורר קושי, לנסות גישה אחרת, להתאושש משגיאות ולבקש הבהרה בעת הצורך. שתי היכולות משרתות עבודה שמתפרשת על פני צעדים רבים, אך ממלאות תפקידים שונים: הזיכרון מחזיר הקשר קודם, והמיקוד עוסק בהמשך הביצוע אחרי חסם. סוכן שמתמיד במשימה עדיין צריך לדעת אם פרט שנזכר השתנה מאז שנמסר.

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

Wonder ב־API, Full במינוי

ההבדל בין הדגמים הוא גם הבדל בין אפשרויות שימוש. מפתח שרוצה לשלב מודל ביישום משלו מקבל מסלול API עבור Wonder. מי שמבקש את Wonder Full מופנה למסלול המינוי של Muse Code; בהשקה לא הוצע עבורו מסלול API מקביל. לכן תוצאת מבחן שמיוחסת ל־Full אינה מתארת בהכרח את הדגם שעומד לרשות מפתח דרך ה־API.

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

תעריף ה־API מודד קלט ופלט, ואינו מספר לבדו כמה תעלה משימה מתמשכת. העלות בפועל תלויה בכמות המידע שהיישום שולח למודל בכל שלב, במספר החזרות על אותו הקשר ובאורך התשובות. אם יישום שומר בעצמו סיכומי שיחות ושולח אותם שוב, זו החלטת תכנון שמשפיעה הן על צריכת האסימונים והן על היקף המידע שנשאר זמין; אי אפשר לייחס אותה אוטומטית למנגנון Active Memory של הדגם.

מה מדד הזיכרון מודד

כרטיס המודל של Meta מציין חלון הקשר של מיליון אסימונים ומתאר את MemoryBench כמבחן פנימי שבו המודל צריך לשלוף מידע חשוב מתוך שיחות מורכבות בהיקף של 64 אלף עד 100 אלף אסימונים. השיחות כוללות פרטים מסיחים ועדכונים שעלולים לסתור פרט קודם, והתשובות מדורגות בידי שופט המבוסס על מודל שפה לפי אמות מידה ייעודיות לכל שאלה. זהו מבחן רלוונטי לזיהוי הפרט הנכון ברצף ארוך, במיוחד כאשר פרט ישן הוחלף.

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

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

שליטה במידע לפני חיבור יומנים ומסמכים

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

לפני חיבור מקורות מידע ארגוניים צריך לברר מי שומר את הזיכרון: המודל, שירות שמפעיל אותו או היישום של הארגון. מכאן נגזרות שאלות שונות על יכולת לצפות בפרטים שנשמרו, לתקן אותם ולמחוק אותם, ועל היחס בין מחיקת מסמך המקור לבין מחיקת מסקנה שהסוכן הסיק ממנו. אין תשובה אחת שאפשר להחיל על כל יישום שמשתמש ב־Wonder, משום שהמוצר שמסביב למודל קובע חלק מזרימת המידע הזאת.

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

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

קראו גם: