메모리 벤치마크 해부: LoCoMo와 LongMemEval은 어떻게 만들고, 돌리고, 채점하나

메모리 벤치마크가 실제로 재는 것

메모리 벤치마크는 “AI가 오래전 대화 내용을 기억해서 맞게 답하는가”를 잽니다. 그런데 점수 하나에는 세 단계가 한꺼번에 들어 있습니다.

1. 저장(retain). 수십 개 세션의 대화 기록을 메모리 시스템에 넣습니다. 시스템마다 원문을 그대로 두기도 하고, 사실을 뽑아 정리하기도 합니다.
2. 회상(recall). 질문이 들어오면 메모리에서 관련 기억을 꺼냅니다. 몇 개를, 몇 토큰까지 꺼내느냐도 시스템 설정입니다.
3. 답변(answer). 꺼낸 기억을 답변 모델(LLM)에 주고 답을 쓰게 합니다.
4. 채점(judge). 정답과 비교해 맞았는지 판정합니다. 요즘은 대부분 또 다른 LLM이 판정합니다.

그래서 “메모리 점수”는 메모리 시스템 혼자의 실력이 아니라 메모리 + 답변 모델 + 프롬프트 + 채점 모델의 합작입니다. 같은 메모리라도 답변 모델을 바꾸면 점수가 크게 달라지고, 채점 모델이 너그러우면 점수가 올라갑니다. 이 자료의 나머지는 대부분 이 사실에서 출발합니다.

벤치마크를 이루는 다섯 가지

어떤 메모리 벤치마크든 아래 다섯 가지로 나눠 보면 구조가 보입니다. 결과를 비교할 때도 이 다섯 가지가 같은지부터 확인하면 됩니다.

증거 표시는 채점에는 쓰이지 않지만 매우 유용합니다. 답을 틀렸을 때 “기억을 못 꺼냈는지(회상 실패)” “꺼냈는데 답을 잘못 썼는지(답변 실패)”를 나눠 볼 수 있기 때문입니다. 09에서 실제로 이렇게 나눠 본 결과를 보여 드립니다.

LoCoMo: LLM 두 명이 몇 달 동안 나눈 대화

LoCoMo는 Snap Research가 ACL 2024에 발표한 벤치마크입니다(Maharana 외, “Evaluating Very Long-Term Conversational Memory of LLM Agents”). 이름은 Long Conversational Memory에서 왔습니다.

대화는 어떻게 만들었나

• 페르소나. 기존 다중 세션 대화 데이터셋(MSC)의 짧은 인물 설명을 늘려 두 명의 가상 인물을 만들었습니다.
• 시간에 따른 사건 그래프. 인물마다 6~12개월에 걸친 최대 25개의 사건(이직, 여행, 가족 일 등)을 인과 관계로 이어 미리 정해 두었습니다. 대화는 이 사건 순서를 따라 진행됩니다.
• LLM 에이전트끼리 대화. 두 에이전트가 세션마다 그 사이에 일어난 사건을 이야기합니다. 각 에이전트는 이전 세션 요약과 관찰을 기억 모듈로 갖고 있고, 사진을 검색해 공유하기도 합니다.
• 사람의 검수. 사람이 대화를 읽고 사건 그래프와 맞지 않거나 어색한 부분을 고쳤습니다. 논문에 따르면 대화 턴의 약 15%를 수정했고, 이미지의 약 19%를 빼거나 바꿨습니다.

논문의 데이터와 공개된 데이터는 다릅니다

논문 본문의 통계는 대화 50개 기준입니다(대화당 평균 19.3세션, 약 9,209토큰, 질문 7,512개). 그런데 GitHub에 공개된 locomo10.json은 그중 가장 길고 주석 품질이 좋은 10개만 남긴 버전입니다. 이 파일을 직접 세어 보면 대화당 세션은 19~32개(평균 27.2), 턴은 평균 588개, 질문은 1,986개입니다. 요즘 논문과 업체가 말하는 “LoCoMo 점수”는 거의 이 10개 버전입니다. 논문의 표 숫자와 공개 파일의 숫자를 섞어 인용하면 안 됩니다.

질문 유형: 번호와 이름이 어긋나 있습니다

질문에는 정답, 증거 턴, 그리고 1~5의 category 번호가 붙어 있습니다. 문제는 공개 파일에 번호의 뜻이 적혀 있지 않다는 점입니다. 원 저자의 채점 코드와 데이터 내용으로 보면 아래 대응이 맞습니다.

그런데 Hindsight 팀이 만든 공개 하네스 AMB(Agent Memory Benchmark)는 논문에 적힌 순서대로 1 = 싱글홉, 3 = 멀티홉, 4 = 오픈 도메인으로 이름을 붙입니다. 증거 수를 보면 1번은 거의 전부 여러 턴을 엮어야 하는 질문인데 “싱글홉”으로, 가장 쉬운 4번 841개는 “오픈 도메인”으로 표시되는 셈입니다. 전체 점수에는 영향이 없지만 유형별 점수의 이름이 바뀝니다. 어떤 표에서 “오픈 도메인 95%”를 보면 그게 원 코드 기준의 4번(쉬운 싱글홉)인지 확인해야 합니다. 이 어긋남은 다른 연구(arXiv 2511.21726)에서도 지적됐습니다.

적대적 질문 446개는 보통 빠집니다

5번 질문 446개 중 444개에는 answer 필드가 아예 없고, 함정 답(adversarial_answer)만 있습니다. 올바른 반응은 “대화에 나오지 않는다”입니다. Mem0 논문 이후 대부분의 비교는 이 유형을 빼고 1,540개만 채점합니다. 그래서 분모가 1,986인지 1,540인지가 점수 비교의 첫 확인 사항입니다.

원래 채점은 F1이었습니다

LoCoMo 논문의 지표는 답과 정답을 정규화(소문자, 문장부호·관사 제거, 어간 추출)한 뒤 겹치는 단어로 계산하는 토큰 F1입니다. 멀티홉은 쉼표로 나눈 여러 답을 각각 맞춰 보고, 적대적 질문은 “not mentioned” 같은 표현이 있으면 맞은 것으로 봤습니다. 논문의 기준점은 사람이 F1 87.9, GPT-4-turbo(4K 문맥) 32.1, GPT-3.5-turbo-16K 37.8, 가장 좋은 RAG 설정 41.4였습니다(모두 1회 실행). 지금 업계에서 말하는 70~90%대 LoCoMo 점수는 이 F1이 아니라 06에서 설명하는 LLM 판정 정확도입니다. 두 지표는 서로 비교할 수 없습니다.

LongMemEval: 사용자와 AI 비서의 긴 대화 속에 숨긴 단서

LongMemEval은 ICLR 2025에 발표된 벤치마크입니다(Wu 외, “LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory”). LoCoMo가 두 사람의 대화라면, LongMemEval은 한 사용자가 AI 비서와 몇 주 동안 나눈 대화에서 필요한 정보를 찾는 상황을 흉내 냅니다.

다섯 가지 능력, 일곱 가지 질문 유형

질문과 대화 기록은 이렇게 만들었습니다

• 속성 목록에서 출발. 5개 범주, 164개의 사용자 속성(직업, 취미, 건강 등) 목록을 만들고, Llama-3-70B로 사용자 배경과 질문 씨앗을 생성했습니다.
• 사람이 거르고 다시 씀. 전문가가 질문을 고르고 고쳤고, 정답을 근거 문장으로 나눴습니다. 생성된 질문 중 살아남은 것은 약 5%입니다.
• 근거 세션. 정답이 들어간 대화는 Llama-3-70B의 자기 대화로 만들고 약 70%를 사람이 손봤습니다.
• 건초 더미(haystack). 근거 세션 사이에 관계없는 대화를 채웠습니다. ShareGPT 25%, UltraChat 25%, 시뮬레이션 대화 50%이고, 날짜는 2023년 5월 안에서 무작위로 붙였습니다.

S, M, 오라클: 같은 질문, 다른 길이

LongMemEval_S는 질문마다 약 11만 5천 토큰의 대화 기록을 줍니다. 공개 파일을 세어 보면 세션은 38~62개(평균 47.7), 그중 정답이 든 세션은 1~6개(평균 1.9)입니다. LongMemEval_M은 약 500세션, 150만 토큰으로 문맥 창에 넣을 수 없는 크기입니다. 오라클은 정답이 든 세션만 줘서 “찾기”를 빼고 “읽고 답하기”만 재는 상한선입니다. 보통 메모리 시스템 비교는 S 버전입니다. 2025년 9월에는 대화 기록을 정리한 _cleaned 파일이 추가돼, 원본 파일과 정리된 파일 중 무엇을 썼는지도 확인할 거리가 됐습니다.

공식 채점: GPT-4o와 유형별 프롬프트

공식 채점은 GPT-4o가 유형마다 다른 프롬프트로 판정합니다. 시간 질문은 날짜 계산의 하루 차이를 봐주고, 지식 갱신은 예전 정보를 함께 말해도 최신 답이 맞으면 정답으로, 선호 질문은 “원하는 답의 방향”이라는 기준(rubric)에 맞으면 정답으로 봅니다. 답할 수 없는 질문은 모델이 “알 수 없다”고 했는지를 따로 판정합니다. 논문은 이 판정이 사람 판단과 0.97~0.98 일치한다고 보고했고, 가장 낮은 칸은 선호와 답할 수 없는 질문(각 0.90)이었습니다.

논문의 핵심 발견: 상용 비서(ChatGPT)는 같은 정보를 바로 읽을 때보다 37%, 긴 문맥 GPT-4o는 오라클(0.870) 대비 S(0.606)에서 30% 떨어졌습니다. 저자들은 세션을 대화 라운드 단위로 쪼개 저장하고, 기억에 추출한 사실을 키로 덧붙이고, 질문의 시간 범위를 확장하는 설계를 제안했습니다.

벤치마크는 실제로 어떻게 돌아가나

데이터만으로는 점수가 나오지 않습니다. 데이터를 메모리에 넣고, 질문하고, 답을 받고, 채점하는 프로그램, 즉 하네스(harness)가 필요합니다. 여기서는 Hindsight 팀(vectorize-io)이 공개한 AMB를 예로 실제 순서를 따라가 보겠습니다. 이 순서는 다른 하네스도 크게 다르지 않습니다.

1. 데이터 적재. 대화 파일을 읽어 세션별 문서로 만들고, 각 문서에 세션 날짜를 붙입니다. LongMemEval은 질문마다 별도의 사용자(메모리 공간)를 만들고, LoCoMo는 대화 하나가 한 공간입니다.
2. 메모리에 저장. 평가 대상 메모리 시스템의 저장 API를 부릅니다. 저장 방식(원문 그대로, 사실 추출, 그래프 구성)은 시스템 몫입니다.
3. 질문마다 회상. 질문 문장과 질문 시각을 주고 기억을 꺼냅니다. 이때 몇 토큰까지 꺼낼지(회상 예산)는 하네스 설정입니다. AMB는 Hindsight에 32,768토큰을 줍니다.
4. 답변 생성. 꺼낸 기억을 정해진 답변 프롬프트에 넣어 답변 모델에게 보냅니다.
5. 판정. 질문, 정답, 생성된 답을 판정 프롬프트에 넣어 판정 모델에게 보내고 맞음/틀림을 받습니다.
6. 집계. 질문별 결과를 파일로 남기고 유형별·전체 정확도를 계산합니다.

답변 프롬프트가 점수를 만든다

AMB의 LongMemEval 답변 프롬프트에는 이런 지시가 들어 있습니다.

For recommendation questions (“can you recommend…”, “suggest…”, “any tips…”): DO NOT give actual recommendations. Instead, describe what KIND the user would prefer based on their context. Example answer format: “The user would prefer recommendations for [category] that focus on [their interest]. They would not prefer [what to avoid based on context].”

선호 질문의 정답이 바로 “The user would prefer …” 형식의 기준 문장이기 때문에, 이 지시는 답을 채점 기준의 모양에 맞춥니다. 개수 세기 질문에는 “항목을 하나씩 나열한 뒤 세라”, 날짜 계산에는 “양쪽 날짜를 다 찾았을 때만 답하라” 같은 지시도 있습니다. 이런 프롬프트는 공정하게 모든 시스템에 똑같이 쓰인다면 문제가 아니지만, 다른 프롬프트로 얻은 점수끼리는 비교할 수 없다는 뜻입니다. AMB의 README도 프롬프트나 모델의 작은 변화가 정확도를 두 자릿수로 흔들 수 있다고 적고 있습니다.

채점: F1에서 LLM 판정으로

토큰 F1은 계산이 결정적이고 누가 돌려도 같지만, “Adoption agencies”와 “She looked into adoption agencies”를 다르게 취급합니다. 그래서 Mem0 논문(2025) 이후 대부분의 비교는 LLM 판정(LLM-as-a-judge)으로 바뀌었습니다. 판정 모델에 질문, 정답, 생성된 답을 주고 맞음/틀림을 받는 방식입니다.

LLM 판정은 사람 판단에 더 가깝지만 새로운 변수를 만듭니다.

• 판정 모델. LongMemEval 공식은 GPT-4o, Hindsight 논문은 GPT-OSS-120B, AMB 기본값은 Gemini입니다. Mem0 논문은 판정 모델 이름을 밝히지 않았고, 재현 감사는 gpt-4o-mini로 봤습니다. 같은 답도 판정 모델에 따라 결과가 달라집니다.
• 너그러움. LoCoMo 판정 프롬프트는 “주제가 같으면 정답”이라고 지시합니다. 앞의 감사에서 주제만 맞힌 오답의 62.81%가 정답 처리된 이유입니다.
• 무작위성. 온도 0으로 고정해도 API 모델은 완전히 결정적이지 않습니다. Mem0 논문은 판정을 10번 돌려 평균과 표준편차를 보고했습니다.
• 판정이 볼 수 없는 것. 판정 모델은 답이 “기억에서 왔는지, 상식으로 찍었는지”를 모릅니다. 그래서 증거 기반의 회상 지표를 따로 보는 것이 좋습니다.

같은 벤치마크인데 숫자가 서로 다른 이유

업체 발표, 논문, 블로그의 LoCoMo·LongMemEval 점수는 대개 직접 비교할 수 없습니다. 다음 중 하나라도 다르면 다른 실험입니다.

업체가 스스로 발표하는 “SOTA” 수치는 대부분 자기 하네스, 자기 프롬프트, 자기가 고른 판정 모델로 잰 것입니다. 하네스 공개 여부와 위 설정이 함께 공개되지 않았다면 참고치로만 보는 편이 안전합니다. AMB도 README에서 하네스를 만든 팀이 평가 대상 중 하나인 Hindsight의 개발사라는 점을 밝히고 있습니다.

정확하고, 일관되고, 재현 가능하게 만드는 법

직접 벤치마크를 돌리거나 결과를 발표할 때 지키면 좋은 원칙입니다. 하나하나가 앞에서 본 문제를 막기 위한 것입니다.

1. 무엇을 돌렸는지 고정하고 기록하기

• 데이터: 파일 이름과 버전(예: longmemeval_s_cleaned.json), 가능하면 SHA-256 해시. 분할(split)과 제외한 유형도 함께 적습니다.
• 코드: 하네스와 메모리 시스템의 커밋. 실행 중에 코드가 바뀌지 않도록 고정된 작업 폴더에서 돌립니다.
• 모델: 답변·판정·임베딩 모델의 정확한 버전, 온도, 최대 토큰. 프롬프트 원문도 결과와 함께 보관합니다.
• 예산: 회상 예산과, 실제로 답변 모델에 들어간 평균 토큰 수. 설정값과 실측값은 다를 수 있습니다.

2. 결과가 완전한지 기계로 확인하기

• 개수 일치: 채점된 고유 질문 수가 기대값(LoCoMo 1,540, LongMemEval 500)과 같은지 확인합니다. 중간에 죽은 질문을 빼고 계산하면 점수가 부풀 수 있습니다.
• 중복 거부: 같은 질문 ID가 두 번 나오면 결과 파일 자체를 거부합니다. 재시도가 섞이면 생깁니다.
• 실패는 오답으로: 답변 모델이 시간 초과 등으로 답을 못 냈다면 판정이 뭐라 하든 틀린 것으로 셉니다. 그리고 그 질문 목록을 따로 남겨 다시 돌립니다.

3. 불확실성을 숫자와 함께 보고하기

질문 수가 유한하기 때문에 같은 시스템이라도 점수에 오차가 있습니다. 정확도 86.3%, 질문 1,540개라면 95% 신뢰구간(Wilson)은 약 84.5~87.9%, 질문 500개에서 80.6%라면 약 76.9~83.8%입니다. 두 시스템의 차이가 이 폭보다 작으면 “더 좋다”고 말하기 어렵습니다. 유형별 점수는 질문 수가 더 적어서(LongMemEval 선호 질문은 30개, 한 문제가 3.3점) 폭이 훨씬 넓습니다. LoCoMo 질문은 대화 10개에 묶여 있어 서로 독립이 아니라는 점도 기억해 둘 만합니다.

4. 같은 조건에서만 비교하기

• 비교하는 모든 시스템에 같은 답변 모델, 같은 프롬프트, 같은 판정 모델, 같은 분모를 씁니다. 다른 논문의 점수를 표에 옮겨 올 때는 그 점수의 조건을 함께 적습니다.
• 가능하면 같은 설정으로 두 번 이상 돌려 실행 간 변동을 봅니다.

5. 정확도 외의 지표를 함께 보기

• 증거 회상률: 정답 근거가 된 대화가 꺼낸 기억 안에 들어 있었는지. 틀린 답을 “회상 실패”와 “답변 실패”로 나눌 수 있습니다.
• 문맥 토큰과 지연 시간, 비용: 3만 토큰을 넣어 90%와 2천 토큰으로 85%는 다른 제품입니다.
• 원자료 공개: 질문별 답, 판정 사유, 꺼낸 기억을 파일로 남기면 다른 사람이 판정만 다시 돌려 검증할 수 있습니다. 단, 개인 데이터가 들어간 평가라면 이 파일은 공개 저장소 밖에 둡니다.

직접 돌려 보며 실제로 걸린 문제들

2026년 10월, 제 에이전트들이 공유하는 클라우드 메모리 시스템을 AMB로 측정했습니다. 답변 모델은 GPT-OSS-120B, 판정 모델은 Gemini 2.5 Flash-Lite입니다. Hindsight 논문과 답변 모델은 같지만 판정 모델이 달라서, 아래 숫자는 논문 표와 완전히 같은 조건의 비교가 아닙니다. 이 과정에서 실제로 부딪힌 문제가 위의 원칙이 왜 필요한지 잘 보여 줍니다.

문제 1: 하네스가 기억 대신 통계를 답변 모델에 보냈다

AMB는 메모리 시스템이 “원본 응답(raw response)”을 함께 돌려주면, 답변 프롬프트의 기억 자리에 꺼낸 기억 대신 그 원본 응답을 JSON으로 넣습니다. 우리 연동 코드가 진단용 통계를 원본 응답으로 돌려주자, 답변 모델은 기억 없이 통계만 보고 답했습니다. 그때 나온 점수(LoCoMo 49.5%, LongMemEval 3.3%)는 전부 무효로 처리했습니다.

문제 2: 날짜를 글자로 정렬해서 세션이 숨었다

LoCoMo의 세션 날짜는 “1:56 pm on 8 May, 2023” 같은 글자입니다. 하네스가 질문 시각을 계산할 때 이 날짜를 글자 순서로 정렬했고, 우리 시스템은 “질문 시각 이후의 기억은 보지 않는다”는 규칙을 엄격하게 지켰기 때문에, 실제로는 이전인 세션 일부가 숨겨졌습니다. 두 문제 모두 원인을 고쳐 테스트로 고정한 뒤 처음부터 다시 측정했습니다.

문제 3: 유형별 비교의 이름이 틀렸다

처음 결과를 보고 “싱글홉이 약점”이라고 정리했는데, 03에서 설명한 번호 대응 때문에 실제로는 멀티홉(1번) 질문이었습니다. 질문당 증거 수를 세어 보고서야 알았습니다.

측정 결과와, 결과를 읽는 법

• 신뢰구간을 보면: 3k → 8k의 +1.0점은 구간이 겹쳐서 “더 좋다”고 말할 수 없습니다. 유형별로는 여러 세션 종합(71.4 → 75.2)과 시간(78.2 → 82.0)이 오르고 선호(56.7 → 43.3)와 지식 갱신(91.0 → 87.2)이 내려가, 기억을 더 넣는 것이 공짜가 아니었습니다. 같은 실험에서 기억을 1만 8천 토큰까지 넣으면 30문항 중 23개 → 20개로 오히려 떨어졌습니다.
• 실행 간 변동: 예산 8k로 여러 세션·시간 유형 266문항만 따로 한 번, 전체 500문항 실행 안에서 또 한 번 돌렸더니 같은 설정·같은 질문인데 여러 세션 종합이 77.4와 75.2로 2점 넘게 달랐습니다. 한 번 돌린 점수의 2점 차이는 잡음일 수 있다는 뜻입니다.
• 증거로 원인 나누기: 예산 3k 실행에서 LongMemEval의 틀린 여러 세션 질문은 정답 근거 턴의 65%만 꺼낸 기억에 들어 있었고, 맞힌 질문은 91%였습니다. 이 유형의 실패는 주로 회상 문제입니다. 반대로 선호 질문은 틀린 경우에도 근거의 77%를 꺼냈기 때문에, 주로 답변·판정 단계의 문제였습니다.

메모리 벤치마크 숫자를 볼 때 확인할 10가지

1. 어느 데이터인가? (LoCoMo 공개 10개 / LongMemEval S·M·오라클, 원본·cleaned)
2. 분모는? (LoCoMo 1,986 vs 1,540, 실패한 질문을 오답으로 셌나)
3. 채점은 F1인가 LLM 판정인가? 판정 모델과 프롬프트는?
4. 답변 모델은? 비교 대상과 같은가?
5. 답변 프롬프트는 공개됐나? 비교 대상과 같은가?
6. 회상 예산과 실제로 들어간 토큰 수는?
7. 몇 번 돌렸나? 신뢰구간이나 표준편차가 있나?
8. 유형별 점수의 이름은 어느 번호 대응을 따랐나?
9. 표의 다른 시스템 점수는 같은 하네스로 다시 잰 것인가, 다른 보고서에서 옮긴 것인가?
10. 질문별 결과 파일과 코드 커밋이 공개됐나?

출처와 확인 방법

질문 수, 세션 수, 증거 수는 공개 데이터 파일(locomo10.json, longmemeval_s_cleaned.json)을 직접 세었고, 프롬프트는 AMB 저장소(커밋 20751fa)의 코드에서 확인했습니다. 논문 수치는 각 논문의 해당 절과 표를 기준으로 했습니다.

• Maharana 외, Evaluating Very Long-Term Conversational Memory of LLM Agents (ACL 2024) · snap-research/locomo
• Wu 외, LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory (ICLR 2025) · xiaowu0162/LongMemEval
• Chhikara 외, Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory (2025)
• Zep, Lies, Damn Lies, & Statistics: Is Mem0 Really SOTA in Agent Memory? (2025-05)
• Hindsight Technical Report (2025-12) · vectorize-io/agent-memory-benchmark
• Penfield Labs, LoCoMo audit (2026-04)
• LoCoMo 번호 대응 문제를 다룬 연구: arXiv 2511.21726 (Table E2)
• 함께 보면 좋은 벤치마크: MSC, MemGPT의 DMR, MemoryAgentBench, BEAM, LoCoMo-Plus