에이전트 메모리 벤치마크

AI 에이전트가 여러 세션에 걸친 대화와 작업에서 정보를 얼마나 잘 저장하고, 찾고, 고치고, 활용하는지 재는 평가 세트로, 메모리 시스템을 고르거나 직접 만든 메모리를 개선할 때 기준점으로 쓴다. 벤치마크마다 재는 능력이 달라 하나의 점수로 모든 걸 판단할 수 없으니 내 에이전트가 할 일과 맞는 것을 골라야 한다.

컨텍스트가 커지면서 '읽기 시험'이 됐다

LoCoMo와 LongMemEval은 컨텍스트 창이 작던 시절에 만들어졌다. 지금은 모델이 100만 토큰을 읽을 수 있어서, 대화 전체를 그냥 컨텍스트에 넣어도 점수가 잘 나오는 경우가 많다. 이 경우 점수는 메모리 구조가 아니라 모델의 읽기 능력을 재게 된다. 그래서 회귀 테스트용으로는 여전히 쓸 만하지만, 대규모 기억은 BEAM처럼 컨텍스트에 다 안 들어가는 시험으로 따로 확인해야 한다.

점수는 채점 환경에 따라 크게 흔들린다

대부분 다른 LLM이 답을 채점하는 방식이라, 채점 모델·채점 프롬프트·데이터 부분집합만 바뀌어도 점수가 두 자릿수씩 달라진다. 같은 시스템이 너그러운 채점 한 번으로 훨씬 높게 나온 사례도 있다. 검색 개수(top-k)를 고정해 둔 탓에 특정 데이터셋에서만 점수가 떨어진 경우도 있었다. 업체가 발표한 점수는 설정과 날짜까지 함께 봐야 한다.

내 메모리 시스템은 이렇게 잰다

오픈소스 평가 도구 AMB는 문서를 메모리에 넣고(Ingest), 질문마다 꺼내고(Retrieve), 답을 만들고(Generate), 정답과 비교해 채점(Judge)하는 순서로 돈다. 정확도만 보지 말고 질의당 토큰과 비용, 검색 속도도 같이 기록하는 게 좋다.

AMB가 든 예시. 비용까지 보면 B가 더 나은 선택일 수 있다.

벤치마크가 못 잡는 실패

벤치마크를 통과한 에이전트가 사용자가 두 번 전에 고쳐 준 직함을 여전히 옛날 것으로 말하는 일이 생긴다. 실제 장애는 꺼내는 단계보다 쓰고 고치는 단계에서 많이 난다. 벤치마크는 검색 품질 확인에 쓰고, 정보 갱신과 충돌 처리는 실제 대화 기록을 사람이 직접 검토해 확인한다.

메모리를 고를 때와 고친 뒤에 돌린다

가장 흔한 건 메모리 시스템 후보를 같은 조건에서 비교하거나, 메모리 구조를 바꾼 뒤 점수가 떨어지지 않았는지 확인하는 용도다. 내 서비스에 맞는 벤치마크를 골라 채점 설정을 고정해 두고 반복해서 돌린다.