一個有用的記憶測試，不太像問「你還記得我什麼？」而更像一場閉卷檢查，其中包含一次更正與幾項干擾。若要執行 muse wonder active memory test，請在一個對話中給 Muse Wonder 虛構細節，更正其中一項，然後在全新對話中詢問相關的當前事實。記錄它取回了什麼、弄錯了什麼，以及是否承認不確定性。
以下流程設定與評分約需 10 分鐘。這無法證明跨天、跨帳號或每個 Muse 產品介面的記憶能力。這是一項可重複的初步檢查。請使用虛構細節，而非私人資訊。
重點摘要
- 分別測試取回、更正、抗干擾、不確定性與可追溯性。
- 在你打算使用的產品介面中執行測試，並記錄其記憶設定。
- 全新的 API 請求只有在應用程式或服務提供持久記憶時，才會測試到持久記憶。
- Meta 的 MemoryBench 是一項長得多的內部評估；這項簡短檢查並未重現它。
Muse Wonder Active Memory 測試流程：從虛構細節、更正、全新對話取回，到評分
此測試流程區分初始事實、明確更正，以及在新對話中的取回。
Muse Wonder Active Memory 的用途
Meta 將 Active Memory 描述為能在對話之間保留關於個人的重要脈絡，並在細節對後續任務有影響時取回它們。Active Focus 則指持續朝目標推進工作，包括受阻時嘗試替代方案，以及適應新資訊。這些概念彼此相關，但回答的是不同問題：記憶關注的是會回想哪些脈絡；專注關注的是工作如何推進。
那段描述是一項產品能力宣稱，並不保證每個介面或 API 呼叫都會自動共享使用者的歷史記錄。Meta 表示 Muse Wonder 可透過其 Model API 與 Muse Code 使用。其開發者文件列出 1,048,576 個 token 的脈絡視窗與支援的推理設定，但脈絡視窗是一次請求可包含的脈絡量，並不證明較早的請求會持續保留。請確認你所選產品實際提供哪些歷史記錄或記憶。
如何執行 Muse Wonder 記憶測試
一次執行中請使用單一帳號與相同的模型變體。若是聊天產品，請開啟你打算評估的記憶功能並記錄其設定。若是 API 整合，請註明你自己的應用程式是否在請求中包含先前的輪次、已儲存的個人檔案，或取回的筆記。若沒有這些資訊，你就無法將回想能力單獨歸因於模型。
1. 提供相關事實
在第一個對話中，貼上以下虛構個人檔案。只要求它確認收到，這樣模型就不會立刻把這些事實變成計畫。
plaintext1I’m planning a fictional weekend trip. Remember these details for a later planning task: 2- I prefer quiet outdoor activities over crowded events. 3- My fictional trip budget is $400. 4- I avoid shellfish. 5Do not make a plan yet. Reply only with a brief acknowledgment.
在同一產品中開啟一個真正全新的對話，然後詢問：
plaintext1Suggest a suitable weekend activity for me. Use only the preferences I previously shared that matter to this task. List the relevant details you used, and say if you are unsure about any of them.
好的回答會運用偏好中的安靜戶外活動。它不需要提到預算或甲殼類海鮮，因為建議活動時並不需要這兩項細節。留意是否有捏造的偏好。如果產品無法存取先前的聊天，或記憶功能已關閉，請記錄「此介面無法使用記憶」，而不是把模型當成已收到這些事實來評分。
2. 更正過時事實
在另一個測試討論串中，先提出一個約會，然後明確取代它。把更正放在另一則訊息中，這樣你就能看出後續更新是否勝出。
plaintext1For this fictional project, the review meeting is initially set for Tuesday at 2 p.m. Please retain that detail.
plaintext1Correction: the review meeting has moved to Thursday at 10 a.m. The Tuesday time is outdated. Please use Thursday at 10 a.m. from now on.
在新的對話中詢問：
plaintext1When is the review meeting? If you have conflicting information, give the current time and explain which update you treated as authoritative.
如果它回答週四上午 10 點，並將週二視為過時，就算通過。混合式回答或自信地使用週二，都是有意義的失敗，即使它完美回想起原始細節也一樣。
3. 加入干擾項並測試未知事項
在初始對話中加入兩到三項無害的虛構事實，例如虛構的專案顏色或假想的包裹編號。經過一段延遲後，開始新對話，並詢問一個關於相關偏好的問題，以及一個關於你從未提供的事實的問題。把問題分開，讓每個回答都容易評分。
強健的結果會運用相關偏好、略去不相關細節，並表示不知道缺少的事實。若要進行更嚴格的延遲測試，請隔天重複相同提示。十分鐘可以檢查新對話界線，但無法確立長達一週的保留能力。
Muse Wonder Active Memory 測試卡，顯示設定、新對話問題，以及要記錄的證據
將提示、產品介面、記憶設定、延遲與原始回應保存在一起，讓另一位審查者能重現這項檢查。
如何為 Active Memory 測試評分
將每項行為評為 0 到 2 分。使用結果來比較你自己工作流程中的各次執行，而不是普遍地為模型排名。
| 面向 | 0 分 | 1 分 | 2 分 |
|---|---|---|---|
| 相關事實取回 | 漏掉或捏造所需事實 | 部分正確 | 準確選出正確事實 |
| 更正處理 | 使用舊值 | 含糊或混用兩者 | 使用最新值，並指出舊值已過時 |
| 干擾控制 | 被不相關事實帶偏 | 納入一些不相關細節 | 只使用與問題相關的脈絡 |
| 不確定性 | 自信地猜測 | 有所保留但仍猜測 | 清楚表示未提供答案 |
| 可追溯性 | 未提供依據 | 只說出部分依據 | 簡要列出所依據的脈絡 |
五個 Active Memory 評分面向，從零到兩分，並列出可觀察的通過標準
0–2 分的評分規準將主觀印象轉化為五項可觀察的檢查。
十分是一個方便的內部總分，不是經驗證的門檻。請保留各面向的分數：總分可能在其他地方回想良好時，掩蓋嚴重的更正失敗。保存確切提示與未編輯的輸出，然後在改變部署決策前重複執行。
MemoryBench 能告訴你什麼、不能告訴你什麼
Meta 的模型卡將 MemoryBench 描述為一項內部評估，涵蓋 64K 至 100K 個 token 的冗長複雜對話。其任務包括多項事實、干擾對話，以及與目標細節衝突或後續更新目標細節的注入輪次；由 LLM 評審根據加權、各題特定的標準為答案評分。這有助於理解該基準的範圍，但與使用者的個人記憶設定能否跨聊天運作並不相同。
模型卡說明了任務設計；它不會把這項 10 分鐘練習變成複現。Meta 公布的分數是關於所報告評估設定的證據。你的執行回答的是更狹隘的運作問題：這個特定產品介面、配置與帳號，是否會取回你的工作流程所需的事實？兩者都無法單獨確立對每位使用者或每項任務都可靠的記憶。
Muse Wonder 與 Muse Wonder Full：在哪裡測試
這兩個變體的存取途徑並不相同。Meta 目前的開發者文件表示，Muse Wonder (muse-wonder-1.0) 可在 Model API 與 Muse Code 中使用。Muse Wonder Full 僅在 Power Usage 與 Maximum Usage 方案的 Muse Code 中提供。將 Muse Wonder 的推理強度設為「max」並不會把它切換成 Wonder Full。
| 變體 | 文件記載的存取方式 | 要記錄的內容 |
|---|---|---|
| Muse Wonder | Model API 與 Muse Code | API 模型 ID 或 Muse Code 介面，以及是否提供較早的脈絡 |
| Muse Wonder Full | Power Usage 與 Maximum Usage 方案中的 Muse Code | 方案、所選變體，以及該介面可用的記憶設定 |
在每個可用介面中分別執行相同的虛構個人檔案。不要把能取回已儲存個人檔案細節的 Muse Code 測試，與只收到當前提示的無狀態 API 呼叫相比。那會是在比較不同系統，而不只是兩個模型變體。
隱私與可重複測試
請使用虛構的偏好、日期與專案細節。在嘗試真實資料之前，請檢查產品的記憶控制項、刪除途徑、保留資訊與資料使用設定。Meta 的 API 文件表示，Standard 模式中的內容不會用於訓練 Meta 模型；Muse Code 也提供 Contributor 模式，該模式預設開啟，除非關閉，否則可能會使用內容進行訓練。請檢查你所使用產品的當前設定與條款，而不是假設所有介面都以相同方式處理資料。
對於 API，請將模型與應用程式的記憶層分開。你的軟體傳送的資料庫、取回系統或提示歷史記錄，可能才是負責記憶的部分。記錄應用程式取回了什麼，以及它傳入每個請求的內容，同時讓測試記錄保持合成資料。
團隊可以把這三回合變成一套小型、有版本控制的評估集。固定事實設定檔、更正、干擾項、模型變體、產品設定、延遲與原始回應。在配置或模型變更後重新執行，並依面向檢視失敗。對於已經在可重複測試框架中比較託管模型的團隊，Atlas Cloud 提供型錄與統一 LLM API 指南。你可以瀏覽其模型目錄進行另一項比較。該目錄目前未列出 Muse Wonder，而在那裡使用另一個模型，除非你的應用程式加入記憶層，否則只會測試明確提供給該模型的脈絡。
常見問題
我要如何跨聊天測試 Muse Wonder 的 Active Memory？
在一個對話中提供虛構事實，然後在新對話中詢問相關細節。加入一項更正與一項缺少的事實，並記錄產品介面與記憶設定。
Muse Wonder 會記住更正，還是只記得較早的細節？
Meta 的 MemoryBench 說明包含會更新或與較早細節衝突的輪次。你自己的更正測試會檢查當前產品設定是否遵循更新；請重複執行，因為單一結果無法確立一致行為。
這項聊天歷史測試與 Meta 的 MemoryBench 相同嗎？
不同。Meta 將 MemoryBench 描述為一項內部長脈絡基準，使用 64K 至 100K 個 token 的對話、干擾項、衝突或更新的事實，以及 LLM 評審。這項簡短檢查是實用的煙霧測試，不是複現。
我可以透過 API 測試 Muse Wonder Active Memory 嗎？
你可以測試 API 模型對送達請求之脈絡的回想。若要跨請求持續保留，請確認 API 或你的應用程式儲存並傳送了什麼。大型脈絡視窗的可用性本身並不表示不同請求會共享記憶。
我要如何區分模型記憶與應用程式儲存的記憶？
檢查傳送給模型的完整請求。如果你的應用程式插入了個人檔案、取回的筆記或先前的對話，那麼提供記憶的是該軟體層。在適當情況下，與省略它的受控執行進行比較。
在 Active Memory 測試中使用個人資訊安全嗎？
測試請使用虛構資訊。如果你之後要評估真實資料，請先檢視該特定產品的記憶、刪除、保留與資料使用設定。
當 muse wonder active memory test 能揭露哪個步驟失敗時，它最有用：取得先前脈絡、取回、更正、篩選或不確定性。保存原始執行，然後在你打算信任的確切設定下重複執行。
來源： Meta 的 Muse Wonder 公告 (2026 年 10 月 12 日); Meta Model API 模型文件 (存取於 2026 年 10 月 15 日); Muse Wonder 模型卡 (2026 年 10 月).
