유용한 메모리 테스트는 “내가 무엇을 기억하니?”라고 묻는 것보다, 한 번의 수정과 몇 가지 방해 요소가 있는 책을 덮고 하는 점검에 가깝습니다. Muse Wonder Active Memory 테스트를 실행하려면 한 대화에서 Muse Wonder에 가상의 세부 정보를 제공하고, 그중 하나를 수정한 다음, 새 대화에서 관련된 현재 사실을 질문하세요. 무엇을 인출하는지, 무엇을 틀리는지, 불확실성을 인정하는지 기록하세요.
아래 순서는 설정하고 채점하는 데 약 10분이 걸립니다. 이는 며칠, 계정, 모든 Muse 제품 인터페이스에 걸친 메모리의 증거가 아닙니다. 반복 가능한 첫 점검입니다. 개인 정보 대신 만들어낸 세부 정보를 사용하세요.
핵심 요약
- 인출, 수정, 방해 요소 저항, 불확실성, 추적 가능성을 각각 테스트하세요.
- 사용하려는 제품 인터페이스에서 테스트를 실행하고 메모리 설정을 문서화하세요.
- 새 API 요청은 애플리케이션이나 서비스가 지속 메모리를 제공하는 경우에만 지속 메모리를 테스트합니다.
- Meta의 MemoryBench는 훨씬 더 긴 내부 평가이며, 이 짧은 점검은 이를 재현하지 않습니다.
테스트 흐름은 초기 사실, 명시적 수정, 새 대화에서의 인출을 분리합니다.
Muse Wonder Active Memory의 목적
Meta는 Active Memory를 대화 전반에 걸쳐 사람에 관한 중요한 맥락을 유지하고, 이후 작업에 중요할 때 세부 정보를 인출하는 것으로 설명합니다. Active Focus는 목표를 향한 지속적인 작업을 말하며, 막혔을 때 대안을 시도하고 새로운 정보에 적응하는 것을 포함합니다. 이 아이디어들은 관련이 있지만 서로 다른 질문에 답합니다. 메모리는 어떤 맥락이 회상되는지를 다루고, 포커스는 작업이 어떻게 진행되는지를 다룹니다.
그 설명은 제품 기능 주장이며, 모든 인터페이스나 API 호출이 사용자의 기록을 자동으로 공유한다는 보장은 아닙니다. Meta는 Muse Wonder가 자사의 Model API와 Muse Code를 통해 제공된다고 말합니다. 개발자 문서에는 1,048,576토큰 컨텍스트 창과 지원되는 추론 설정이 나열되어 있지만, 컨텍스트 창은 한 요청이 담을 수 있는 맥락의 양일 뿐, 이전 요청이 지속된다는 증거는 아닙니다. 선택한 제품이 실제로 어떤 기록이나 메모리를 제공하는지 확인하세요.
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. 방해 요소를 추가하고 알려지지 않은 것을 테스트하기
첫 대화에 해가 없는 가상 사실 두세 개를 추가하세요. 예를 들어 만들어낸 프로젝트 색상이나 가짜 소포 번호 같은 것입니다. 지연 후 새 대화를 시작하고 관련 선호에 관한 질문 하나와 제공한 적 없는 사실에 관한 질문 하나를 하세요. 각 답변을 쉽게 채점할 수 있도록 질문을 분리하세요.
강한 결과는 관련 선호를 사용하고, 관련 없는 세부 정보는 빼놓으며, 누락된 사실을 모른다고 말합니다. 더 엄격한 지연 테스트를 원하면 다음 날 같은 프롬프트를 반복하세요. 10분은 새 채팅 경계를 확인할 수 있지만 일주일간의 보존을 입증할 수는 없습니다.
다른 검토자가 점검을 재현할 수 있도록 프롬프트, 제품 인터페이스, 메모리 설정, 지연, 원시 응답을 함께 보관하세요.
Active Memory 테스트 채점 방법
각 동작을 0~2점으로 채점하세요. 결과는 자체 워크플로에서 실행을 비교하는 데 사용하고, 모델을 보편적으로 순위 매기는 데 사용하지 마세요.
| 차원 | 0점 | 1점 | 2점 |
|---|---|---|---|
| 관련 사실 인출 | 필요한 사실을 놓치거나 만들어냄 | 부분적으로 정확함 | 올바른 사실을 정확히 선택함 |
| 수정 처리 | 오래된 값을 사용함 | 모호하거나 둘을 섞음 | 최신 값을 사용하고 오래된 값을 구식으로 식별함 |
| 방해 요소 통제 | 관련 없는 사실에 끌림 | 일부 관련 없는 세부 정보를 포함함 | 질문에 관련된 맥락만 사용함 |
| 불확실성 | 확신을 갖고 추측함 | 얼버무리지만 여전히 추측함 | 답변이 제공되지 않았다고 분명히 말함 |
| 추적 가능성 | 근거를 제시하지 않음 | 근거의 일부만 언급함 | 의존한 맥락을 간략히 나열함 |
0–2 루브릭은 주관적 인상을 다섯 가지 관찰 가능한 점검으로 바꿉니다.
10점은 편리한 내부 점수일 뿐 검증된 임계값이 아닙니다. 개별 차원 점수를 보관하세요. 총점은 다른 곳의 좋은 회상 뒤에 심각한 수정 실패를 숨길 수 있습니다. 정확한 프롬프트와 편집하지 않은 출력을 저장한 다음, 배포 결정을 바꾸기 전에 실행을 반복하세요.
MemoryBench가 알려줄 수 있는 것과 없는 것
Meta의 모델 카드는 MemoryBench를 64K~100K 토큰의 길고 복잡한 대화에 대한 내부 평가로 설명합니다. 그 작업에는 여러 사실, 방해 대화, 대상 세부 정보와 충돌하거나 나중에 이를 업데이트하는 주입된 턴이 포함됩니다. LLM 심사자가 가중치가 적용된 질문별 기준에 따라 답변을 채점합니다. 이는 벤치마크의 범위를 이해하는 데 유용한 맥락이지만, 사용자의 개인 메모리 설정이 채팅 전반에서 작동하는 것과는 다릅니다.
모델 카드는 작업 설계를 설명할 뿐, 이 10분 연습을 재현 실험으로 만들어 주지는 않습니다. Meta가 공개한 점수는 보고된 평가 설정에 관한 증거입니다. 여러분의 실행은 더 좁은 운영 질문에 답합니다. 이 특정 제품 인터페이스, 구성, 계정이 워크플로에 필요한 사실을 인출하는가? 어느 하나만으로 모든 사용자나 작업에 대해 신뢰할 수 있는 메모리를 입증할 수는 없습니다.
Muse Wonder vs. 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 토큰의 대화, 방해 요소, 충돌하거나 업데이트된 사실, LLM 심사자를 사용하는 내부 장문맥 벤치마크로 설명합니다. 이 짧은 점검은 실용적인 스모크 테스트이며 재현 실험이 아닙니다.
API를 통해 Muse Wonder Active Memory를 테스트할 수 있나요?
요청에 도달한 맥락에 대한 API 모델의 회상을 테스트할 수 있습니다. 요청 간 지속성을 확인하려면 API 또는 애플리케이션이 무엇을 저장하고 보내는지 확인하세요. 큰 컨텍스트 창을 사용할 수 있다는 사실만으로 별도 요청이 메모리를 공유한다는 것을 보여주지는 않습니다.
모델 메모리와 앱에 저장된 메모리를 어떻게 구분하나요?
모델에 전송된 전체 요청을 검사하세요. 애플리케이션이 프로필, 검색된 노트, 이전 대화를 삽입한다면 그 소프트웨어 계층이 메모리를 제공한 것입니다. 적절한 경우 이를 생략한 통제 실행과 비교하세요.
Active Memory 테스트에 개인 정보를 사용해도 안전한가요?
테스트에는 가상 정보를 사용하세요. 나중에 실제 데이터를 평가한다면 먼저 해당 제품의 메모리, 삭제, 보존, 데이터 사용 설정을 검토하세요.
Muse Wonder Active Memory 테스트는 이전 맥락에 대한 접근, 인출, 수정, 필터링, 불확실성 중 어느 단계가 실패했는지 드러낼 때 가장 유용합니다. 원시 실행을 저장한 다음, 신뢰할 계획인 정확한 설정에서 반복하세요.
출처: Meta의 Muse Wonder 발표 (2026년 10월 12일); Meta Model API 모델 문서 (2026년 10월 15일 접속); Muse Wonder 모델 카드 (2026년 10월).
