질문
에이전트 메모리에 기록을 쌓아두면 필요할 때 조회로 꺼낼 수 있다고 가정한다.
그 가정을 운영 데이터로 검사하면 얼마나 남는가.
판정
의미 조회는 완전성을 보장하지 않는다. 누락이 비용이면 조회가 아니라 시간 필터 직조회를 1차 경로로 둔다.
근거
운영 실측이 가정을 깼다. 온프렘 요건 고객사에 직원별 personal / team 메모리 뱅크를 구성하고
1주 트라이얼을 돌렸다. 211건 축적 상태에서 recall 기반 조회의 완전성을 측정했고
재현율 15.6% 였다. 이 수치를 받고 두 가지를 확정했다.
범위 질의 문제다
요약을 얹으면 못 찾은 것이 요약에서 사라진 것과 구별되지 않는다
- 조회 경로가 아니라 시간 필터 직조회를 원칙으로 세웠다. "지난주 내가 뭘 했나"는 검색 문제가 아니라
- 요약 레이어(
reflect)는 정보 오염 방지 근거로 OFF 로 결정했다. 원본을 못 찾는 상태에서
8/8 은 반례가 아니다. /Users/bkan/workspace/memory-bench 의 eval-mini 실측에서
Hindsight 와 mem0 는 모두 8/8 을 기록했지만(2026-08-25, Python 3.13.14 동일 호스트),
그 셋은 8문항 single-hop 이고 retain 한 사실을 그대로 되묻는 구성이다.
게다가 LLM 구성이 비대칭(Hindsight LLM=none vs mem0 로컬 Ollama qwen2.5:0.5b, retain infer=False)이라
LLM 추출 품질 비교도 아니다. 즉 8/8 은 조회 경로가 살아 있음을 증명하지, 실사용 코퍼스의 재현율을
증명하지 않는다. 두 수치는 서로 모순되지 않는다. 같은 시스템의 서로 다른 질문에 대한 답이다.
조회 경로는 운영 조건에서 물리적으로도 깨졌다. 무필터 recall 이 후보 69~73개를 컨테이너 CPU
크로스인코더로 채점하면서 55.8s 가 걸려 MCP 클라이언트 30s 타임아웃에 걸렸다
(/Users/bkan/workspace/Hindsight-Crew/docs/plans/2026-07-26-rerank-mps-cutover.md).
리랭크를 맥 호스트 MPS 사이드카로 옮겨 왕복 1.19~1.24s 로 내려서야 조회가 실사용 가능해졌다.
"조회가 있다"와 "조회가 시간 안에 끝난다"는 별개 사실이다.
- Hindsight recall 지연 실측(eval-mini,
LLM=none): p50 399.3 ms / p95 1190.0 ms - 조회 대신 시간 범위로 긁을 때는 리랭커 비용이 아예 발생하지 않는다
한계·재검토 트리거
15.6% 는 한 고객사의 한 주치 코퍼스와 그 조직의 쿼리 분포에서 나온 값이다. 다른 코퍼스·다른 쿼리
분포에서 같은 값이 나온다는 근거는 없고, 임베딩·리랭커 구성이 바뀌면 값 자체가 바뀐다.
eval-mini 8/8 은 표본이 너무 작아 이 판정을 뒤집는 근거로 쓸 수 없다.
2026-08 기준 / 재검토 트리거: (1) 같은 조직 코퍼스에서 재현율 50% 이상이 관측되거나,
(2) 임베딩·리랭커를 교체한 뒤 동일 프로토콜로 재측정해 유의한 개선이 확인되거나,
(3) 100문항 이상 멀티홉 셋에서 조회 단독으로 누락 없는 회수가 증명되면 이 판정을 내린다.