모든 AI 메모리 제공업체는 자신들의 LongMemEval 시계열 추론 (temporal-reasoning) 점수를 인용합니다.
선두 주자들은 약 90% 정도의 점수를 기록하고 있습니다. 저는 벤치마크를 직접 실행하는 대신, 오후 시간을 할애하여 실제 데이터셋을 읽어보았고, "시계열 추론 (temporal reasoning)"이 실제로는 하나의 정확도 수치 아래 최소 세 가지의 서로 다른 역량이 결합되어 있다는 사실을 발견했습니다.

이를 뒷받침할 JSON 및 터미널 출력 결과와 함께 실제 내용을 소개합니다.

내가 한 것과 하지 않은 것

저는 벤치마크를 실행하지 않았습니다. 이것은 질문 유형, 답변 형식, 그리고 함정이 어떻게 구성되어 있는지에 대한 데이터셋 자체의 분석입니다.

이 점은 명확한 한계점이며, 미리 밝혀두고 싶습니다. 저는 LongMemEval이 무엇을 '테스트'하는지는 말해줄 수 있습니다. 하지만 제가 직접 실행하지 않았기 때문에, 특정 제공업체가 어떤 질문에서 실패하는지는 말씀드릴 수 없습니다.

아래의 모든 내용은 데이터셋과 함께 제공되는 500개의 질문 파일에서 가져온 것이며, MemoryBench의 list-questions 명령과 텍스트 에디터로 읽을 수 있습니다. API 키도 필요 없고, 비용도 들지 않습니다.

벤치마크의 42%가 시간에 의존적임

Total questions:      500
temporal-reasoning:   133  (27%)
knowledge-update:      78  (16%)

두 가지 카테고리 모두 사실이 시간에 따라 어떻게 변하는지에 관한 것입니다. 이 둘을 합치면 전체 벤치마크의 5분의 2가 조금 넘습니다.

하나의 역량에 매우 큰 비중이 실려 있습니다. 이는 또한 제공업체의 헤드라인 수치가 시간을 어떻게 처리하느냐에 따라 크게 좌우된다는 것을 의미하며, 여기서 "시간 처리"가 실제로 무엇을 요구하는지 아는 것이 가치 있다는 것을 뜻합니다.

함정 1: 상태 변화 쌍 (state-change pairs)

일부 질문은 동일한 시나리오를 공유하며 그 안의 서로 다른 시점에 대해 묻는 쌍으로 구성되어 있습니다.

07741c44   "내 오래된 운동화는 처음에 어디에 보관하나요?"
           answer: 내 침대 밑

...

동일한 객체. 동일한 대화 기록. 두 질문 모두 동일한 두 개의 답변 세션을 가리킵니다. 유일한 차이점은 처음에 (initially) 와 현재 (currently) 의 차이입니다.

(참고할 점: 이 두 가지 모두 데이터셋에서 temporal-reasoning이 아닌 knowledge-update로 태그되어 있습니다. 상태 변화 (state-change) 패턴은 두 카테고리 모두에서 나타나며, 이것이 이들을 하나의 범주로 취급할 때 정보가 손실되는 이유 중 일부입니다.)

이것은 깔끔한 테스트이며, 흔히 쓰이는 설계 방식에는 매우 가혹합니다. 최신성 (recency)에 따라 충돌을 해결하는 메모리 시스템 — 즉, 가장 최신 사실이 승리하고 이전 사실은 대체되는 방식 — 은 구조적으로 두 번째 질문에는 올바르게 답하지만 첫 번째 질문에는 틀리게 답하게 됩니다.

첫 번째 언급만을 유지하는 시스템은 그 반대의 경우에 실패합니다.

두 질문 모두 통과하려면 타임스탬프 (timestamp)와 함께 두 상태를 모두 저장하고, 질문이 어떤 상태를 묻고 있는지 판별해야 합니다.

데이터셋 전체에 걸쳐 연속된 ID 쌍으로 구성된 질문이 44개 있습니다. 모두가 상태 변화 (state-change)인 것은 아니지만, 이 패턴은 의도적입니다.

두 번째 함정: 시간 필터링을 통한 모호성 해소 (time-filtered disambiguation)

모든 시간 관련 질문이 사실의 변화에 관한 것은 아닙니다. 어떤 질문들은 여러 유사한 이벤트 중에서 올바른 이벤트를 선택하는 것에 관한 것입니다.

0bc8ad92   "친구와 마지막으로 박물관에 방문한 지 몇 달이 지났나요?"
           질문 시점 2023/03/25 → 답변: 5
...

기록에는 여러 번의 박물관 방문이 있습니다. 의미론적 유사성 (semantic similarity)만으로 "박물관 방문"을 검색하는 것으로는 충분하지 않습니다. 시간 범위 (time window)로 필터링해야 하며, 일치하는 특정 이벤트에 대해 속성 (친구가 있었는지 여부)을 확인해야 합니다.

이 두 질문은 답변 세션이 다르고 질문 날짜가 2주(fortnight) 차이가 난다는 점에 주목하세요. 이들은 단순히 같은 건더기(haystack)를 두 번 물어보는 것이 아니라, 동일한 함정 설계(trap design)의 두 가지 사례입니다.

세 번째 함정: 기권 유도 (abstention decoys)

30개의 질문에는 _abs 접미사가 붙어 있습니다. 이 질문들은 실제 질문과 거의 동일하지만, 하나의 엔티티(entity)가 대화에서 언급된 적 없는 다른 것으로 교체되어 있습니다.

2698e78f       "제 상담사인 Dr. Smith를 얼마나 자주 만나나요?"
2698e78f_abs   "Dr. Johnson을 얼마나 자주 만나나요?"

Dr. Johnson은 대화 기록(conversation history)에 존재하지 않습니다. 정답(ground truth)은 다음과 같습니다:

제공된 정보가 충분하지 않습니다. Dr. Smith를 만난다고 언급하셨지만, Dr. Johnson에 대해서는 언급하지 않으셨습니다.

이것은 시스템이 null을 반환하는지를 측정하는 것이 아닙니다. 시스템이 거절할 수 있는지, 그리고 혼란을 야기했을 법한 근접 오류(near-miss)를 설명할 수 있는지를 측정하는 것입니다. "상담사"라는 패턴을 매칭하여 빈도를 지어내는(confabulates) 시스템은 실패합니다. 단지 "모릅니다"라고만 말하는 시스템도 마찬가지입니다.

벤치마크의 6%는 추론된 거절(reasoned refusal)을 테스트합니다. 이는 주목할 만한 설계 결정입니다. 기권(abstention)이 예외적인 사례(edge case)가 아니라, 일급 능력(first-class capability)으로 취급되고 있습니다.

10개 질문 샘플에서 산술(arithmetic)이 검색(retrieval)보다 약 2:1로 더 많음

저는 10개의 시계열 추론 (temporal-reasoning) 질문을 추출하여 그 답변 형식을 소스 JSON과 직접 대조해 보았습니다:

08f4fc43   30일. 31일 (마지막 날 포함)도 허용됨.
0bb5a684   7일. 8일 (마지막 날 포함)도 허용됨.
0db4c65d   18일. 19일 (마지막 날 포함)도 허용됨.
...

7개는 날짜 산술 (date arithmetic)입니다. 3개는 이 샘플의 70/30 분할에서 시간 창 (time window)에 의해 필터링된 검색된 사실 (retrieved facts)입니다. 이는 진정으로 서로 다른 두 가지 능력입니다:

날짜 산술 (Date arithmetic): 이벤트를 찾고, 해당 타임스탬프 (timestamp)를 추출한 뒤, 질문의 날짜에서 이를 빼고, 차이를 올바른 단위로 표현합니다.

시간 필터링 검색 (Time-filtered retrieval): 명시된 시간 창에 해당하는 특정 이벤트를 찾은 다음, 그에 대한 질문에 답합니다.

어떤 시스템은 한 가지에는 탁월하지만 다른 한 가지에는 미흡할 수 있으며, 이 경우 카테고리 평균값은 그 차이를 완전히 가려버릴 것입니다.

이 수치가 무엇이고 무엇이 아닌지에 대해 솔직해지고 싶습니다. 이 수치는 133개의 시계열 추론 (temporal-reasoning) 질문 중 10개 질문으로 구성된 샘플이며, 이번 단계에서는 전체 카테고리 비용을 소모하는 API 예산을 감당할 수 없었기에 대규모로 프로그래밍 방식으로 추출하는 대신 수동으로 읽은 것입니다. 70/30이라는 비율은 정밀한 벤치마크 전체 비율이 아닌 방향성을 나타내는 것으로 받아들여 주십시오. "시계열 추론"이 두 가지 서로 다른 기술을 묶고 있다는 질적인 핵심은 정확한 분할 비율과 상관없이 유효합니다.

답변의 허용 오차 또한 주목할 만합니다. "마지막 날을 포함하여 31일도 허용 가능합니다." 데이터셋 저자들은 오프 바이 원 (off-by-one) 오류를 위해 여유를 두었는데, 이는 그들이 날짜 산술이 실제로 오류가 발생하기 쉽다는 점을 예상했음을 말해줍니다.

모든 것의 근저에 있는 검색 문제

이 모든 것을 재구성하는 수치가 하나 더 있습니다.

0bc8ad92
  haystack sessions:  49
  answer sessions:     3

모든 질문에는 대략 50개의 대화 세션 (conversation sessions)이 포함되어 있습니다. 정답은 그중 2~3개에만 들어 있습니다. 나머지는 피치 덱 (pitch decks), 레시피, 여행 계획 등에 관한 의도적인 방해 요소 (distractors)인 무관한 채팅들입니다.

이는 어떠한 시계열 추론이 일어나기도 전의 신호 대 잡음비 (signal-to-noise ratio)가 6%라는 것을 의미합니다. 시스템은 50개의 건초더미에서 3개의 바늘을 찾아야 하며, 그 후에야 비로소 날짜에 대한 추론을 시작할 수 있습니다.

따라서 시계열 질문에 실패했다면 다음 세 단계 중 어느 단계에서든 실패했을 가능성이 있습니다:

1. 대화에서 올바른 사실이 추출되지 않음
2. 사실이 추출되었으나 검색되지 않음
3. 사실이 검색되었으나 시계열 추론이 틀림

단일 정확도 수치만으로는 이들을 구분할 수 없습니다.

이것이 중요한 이유

메모리 시스템을 구축하고 있다면, "시계열 추론 (temporal reasoning) 점수가 91%입니다"라는 말은 실행 가능한 정보가 아닙니다. 실패한 나머지 9%가 날짜 산술 (date arithmetic), 모호성 해소 (disambiguation), 상태 변화 쌍 (state-change pairs), 또는 검색 (retrieval) 문제일 수 있으며, 각각에 대한 해결책은 완전히 다르기 때문입니다.

평가하는 입장에서도 마찬가지입니다. 시계열 점수가 동일한 두 제공업체라도 강점 프로필은 정반대일 수 있습니다.

명확한 개선 방법은 하위 점수 (sub-scores)를 활용하는 것입니다. 산술, 검색, 상태 변화를 각각 별도로 보고하십시오. 이 데이터셋은 이미 질문 유형과 ID 패턴을 통해 이를 지원하고 있습니다.

다음에 알고 싶은 것

데이터셋만으로는 답할 수 없는 질문은 다음과 같습니다: 시스템이 시계열 질문에 실패했을 때, 파이프라인(pipeline)의 어느 단계에서 문제가 발생했는가?

이에 답하려면 벤치마크를 실행한 다음, 소스(source)에서 말한 내용과 실제로 저장된 내용을 대조하여 추출 실패 (extraction failures)와 검색 실패 (retrieval failures)를 분리하여 검사해야 합니다. 이는 더 큰 규모의 작업이며 실제 API 예산이 필요합니다.

누군가 이미 이 작업을 수행했다면, 저는 그것을 읽어보고 싶습니다.

재현 방법

여기에 있는 모든 것은 자유롭게 검증할 수 있습니다:

git clone https://github.com/supermemoryai/memorybench
cd memorybench
bun install
...

데이터셋은 처음 사용할 때 다운로드되며 (265 MB), data/benchmarks/longmemeval/datasets/questions/ 아래에 500개의 개별 질문 파일로 분할됩니다.

파일을 직접 읽어보십시오. 위의 모든 내용은 거기에서 나왔습니다.

저는 AI 메모리의 충실도 게이트 (faithfulness gate)인 MiniEval을 만들고 있습니다. 이는 추출 단계 (extraction step)에서 작동하며, 저장된 사실이 출처가 된 메시지에 충실한지 확인합니다. 이는 이 벤치마크가 측정하는 것보다 한 단계 아래의 계층입니다. 저는 이 분야가 메모리를 어떻게 평가하는지 이해하기 위해 LongMemEval을 살펴보았고, 점수보다 카테고리 구조가 더 흥미롭다는 것을 발견했습니다.