ReFind Paper review
When Your Agent Opens the Chat App: Agent-Controlled Search over Raw Chat Logs Rivals Structured Memory
https://arxiv.org/abs/2608.12888
ReFind는 중국과기대(USTC)와 MetaStone Technology에서 만든 채팅 기록 검색 방법이다.
2026년 8월 13일에 나왔고 8월 16일에 v2가 올라왔다. 저자 6명에 21쪽이다.
대화 기록을 요약하거나 그래프로 바꾸지 않고, 원본 로그를 그대로 두고 BM25 검색만 에이전트가 잘 돌리게 했더니 구조화 메모리 시스템들보다 잘 나왔다는 논문이다.
앞에서 본 서베이에서는 메모리 형태를 Token-level · Parametric · Latent로 나누고 flat → graph → hierarchical로 올라가는 구조를 정리했는데, 여기서는 그렇게 올라갈 필요가 있냐고 묻는다.
좀 더 자세히 알아보자.
1. Introduction
에이전트 메모리 시스템들은 원본 대화를 요약, 임베딩, 트리, 지식그래프로 바꿔두고 검색한다.
문제는 이 변환이 질문이 오기 전에 일어난다는 것이다.
논문은 이걸 “질문을 알기 전에 거는 내기”라고 부른다. 뭘 남기고 뭘 버릴지 미리 정하는 거라서, 전처리에서 빠진 내용은 나중에 되살리기 어렵다고 한다.
비용도 든다. 인덱스를 오프라인으로 만들어야 하고, 새 메시지가 올 때마다 다시 만들거나 조금씩 갱신해야 한다.
그래서 이런 질문을 한다. 구조화 메모리의 이득이 구조에서 오는 건지, 아니면 그냥 히스토리를 제대로 검색해서 오는 건지.
이걸 확인하려고 의미 구조를 하나도 만들지 않고 어디까지 갈 수 있는지 본다.
아이디어는 개인 정보 재탐색(refinding) 연구에서 가져왔다고 한다.
사람은 아는 걸 다시 찾을 때 키워드 하나로 한 번에 찾지 않는다. 한 연구에서는 참가자가 키워드 검색을 쓴 비율이 39%뿐이었고, 나머지는 조금씩 좁혀가는 orienteering 방식이었다고 한다. 메신저 연구에서도 키워드, 스크롤, 시간·맥락 단서를 섞어 쓴다고 한다.
그래서 원본은 그대로 두고, 미리 인덱스를 똑똑하게 만드는 대신 검색을 그때그때 잘 하도록 만들자는 것이다.
2. Related Work
related work 부분을 보면 기존 시스템을 다섯 가지 기준으로 비교한 표가 있다.
| 시스템 | No prep. | Agentic | Sess. | Time | Dedup |
|---|---|---|---|---|---|
| Sparse / Dense RAG | ✓ | ||||
| RAPTOR, GraphRAG, HippoRAG 2, A-Mem, Mem0, STITCH | |||||
| Zep | ✓ | ||||
| SeCom | ✓ | ||||
| MemGPT, GAM | ✓ | ||||
| ReFind | ✓ | ✓ | ✓ | ✓ | ✓ |
- No prep. : 질문이 오기 전에 LLM으로 인덱스를 만들지 않음
- Agentic : 모델이 스스로 여러 번 검색함
- Sess. : 세션 구조를 랭킹에 반영함
- Time : 시간으로 걸러서 검색할 수 있음
- Dedup : 라운드끼리 중복 결과를 뺌
논문도 각각은 새로운 게 아니라고 한다. 기존 시스템들은 하나씩만 갖고 있고, ReFind는 다 합친 것이다.
3. Method
검색(증거 모으기)이랑 추론(답 만들기)을 두 단계로 나눈다.
3.1 “구조가 없다”는 말의 뜻
구조가 없다고 해서 아무것도 안 쓰는 건 아니다.
채팅 기록에 원래 있는 것들, 턴 경계, 세션 ID, 타임스탬프, 원문 텍스트는 쓴다. 안 만드는 건 학습하거나 LLM으로 생성한 메모리 표현이다.
BM25 인덱스도 원문을 찾아가는 경로일 뿐 메모리를 대신하는 게 아니라고 한다. 메시지가 추가되면 토큰이랑 메타데이터가 붙을 뿐이고, 요약하거나 엔티티를 뽑거나 그래프를 잇지 않는다.
정리하면 구조화 시스템은 질문을 보기 전에 표현을 정하고, ReFind는 그걸 질문이 올 때까지 미룬다.
3.2 검색 엔진
검색 엔진에 채팅 기록에 맞춘 기능 네 개를 넣었다.
먼저 데이터 표현. 대화는 두 층이다. 제일 작은 단위가 턴(사용자 발화 + 어시스턴트 응답)이고, 턴이 모여서 세션(ID와 타임스탬프가 있는 대화 하나)이 된다.
BM25 역인덱스는 턴 단위로 만든다. 소문자화, 공백·구두점 분할, Porter 스테밍, 불용어 제거를 하고 k1=1.2, b=0.75를 쓴다.
sparse를 쓴 이유는 두 가지라고 한다.
- 모델 호출이나 요약이 없어서 기록되자마자 바로 검색할 수 있다. 새 턴은 인덱스에 그냥 붙는다.
- 키워드 매칭은 결과를 이해하기 쉽다. 에이전트가 어떤 단어가 먹혔고 어떤 단어가 안 먹혔는지 보고 다시 검색할 수 있다. 유사도 점수보다 이게 더 좋은 피드백이라고 한다.
-> 2번은 그럴듯하다. 임베딩 검색은 왜 안 걸렸는지 알기 어렵긴 하다.
첫 번째 기능은 RRF 2단 재랭킹이다.
BM25는 턴 단위로 매칭해서 세션 전체가 관련 있는지는 못 본다. 한 세션에서 턴이 여러 개 걸리면 그 세션 자체가 질문이랑 관련 있을 가능성이 크다.
그래서 랭킹을 두 개 만든다.
- 턴 BM25 순위 (
r1) - 세션 총점으로 매긴 세션 순위를 그 세션의 턴이 물려받은 것 (
r2)
둘을 Reciprocal Rank Fusion으로 합친다(k=60, 기본 K=5). 그림 (a)에서 entry D가 세션 #34에 속해 있어서 3위로 올라간다.
두 번째는 컨텍스트 창 확장이다.
걸린 턴 하나만 주면 앞뒤 맥락이 잘린다. 그래서 앞뒤 ±2 턴을 묶어서 주는데, 세션 경계를 넘어가진 않는다(그림 b).
세 번째, 네 번째는 시간 필터와 본 세션 제외다.
에이전트가 시간 범위를 정할 수 있고, 이전 라운드에서 이미 나온 세션은 뺀다(그림 c). 라운드마다 새 정보를 더 많이 얻으려는 것이다.
3.3 두 단계 분리
Stage 1은 ReAct 루프다. LLM이 키워드랑 파라미터를 정해서 여러 번 검색하고, 쓸 만한 내용을 노트에 저장한다.
이전 검색 결과를 보고 다음 검색을 바꿀 수 있다. 안 걸린 단어를 특징적인 엔티티로 바꾸거나, 시간 단서를 찾으면 날짜 범위를 좁히거나, 멀티홉 질문이면 두 번째 사실을 찾으러 가는 식이다.
Stage 2는 모은 노트를 세션별로 묶고 시간순으로 정렬해서 질문이랑 같이 준다.
이렇게 나눈 이유는 답 만드는 쪽이 검색이랑 컨텍스트 공간을 두고 다투지 않게 하려는 것이라고 한다. 답변 모델은 원문 그대로의 증거만 받는다.
4. Experiments
4.1 여섯 벤치마크, GPT-4o-mini
약 2,800문항이고, 모든 시스템을 GPT-4o-mini로 맞췄다. 베이스라인 수치는 MemoryAgentBench(Hu et al., 2025)에서 가져왔다고 한다.
| 분류 | 방법 | SH-QA | MH-QA | LME | EventQA | FC-SH | FC-MH | Avg |
|---|---|---|---|---|---|---|---|---|
| Long-Context | GPT-4o-mini | 64.0 | 43.0 | 30.7 | 59.0 | 45.0 | 5.0 | 41.1 |
| Sparse/Dense RAG | BM25-RAG | 66.0 | 56.0 | 45.3 | 74.6 | 48.0 | 3.0 | 48.8 |
| text-embed-3-large | 54.0 | 44.0 | 50.3 | 70.0 | 28.0 | 4.0 | 41.7 | |
| 구조화 메모리 | RAPTOR | 29.0 | 38.0 | 34.3 | 45.8 | 14.0 | 1.0 | 27.0 |
| GraphRAG | 47.0 | 47.0 | 35.0 | 34.4 | 14.0 | 2.0 | 29.9 | |
| HippoRAG 2 | 76.0 | 66.0 | 50.7 | 67.6 | 54.0 | 5.0 | 53.2 | |
| Mem0 | 25.0 | 32.0 | 36.0 | 37.5 | 18.0 | 2.0 | 25.1 | |
| Zep | 44.0 | 25.0 | 38.3 | 42.5 | 7.0 | 3.0 | 26.6 | |
| Agentic 메모리 | MemGPT | 41.0 | 38.0 | 32.0 | 26.2 | 28.0 | 3.0 | 28.0 |
| MIRIX | 62.0 | 61.0 | 37.3 | 29.8 | 14.0 | 2.0 | 34.4 | |
| ReFind | 83.0 | 69.0 | 51.3 | 74.1 | 62.7 | 8.8 | 58.2 |
표를 보면,
- 구조화 메모리가 그냥 BM25-RAG보다 낮다. RAPTOR 27.0, GraphRAG 29.9, Mem0 25.1, Zep 26.6인데 BM25-RAG가 48.8이다.
- 구조화 메모리 중에는 HippoRAG 2만 53.2로 BM25-RAG보다 높다. 앞에서 본 서베이에서 RAG 쪽이랑 메모리 쪽 양쪽에서 인용된다고 했던 그 논문이다.
- ReFind가 58.2로 제일 높다. 구조 없이 HippoRAG 2보다 5.0점 높다.
-> Mem0랑 Zep이 키워드 검색보다 한참 낮은 건 좀 의외다. 베이스라인 수치를 다른 논문에서 가져온 거라 세팅이 잘 맞았는지는 모르겠다.
4.2 백본을 키우면 격차가 벌어진다
LongMemEval-S(50문항, 문항당 ~115k 토큰)와 M(15문항, ~500k 토큰)에서 GPT-5-mini로 다시 쟀다. 5회 반복이다.
| 방법 | S | M |
|---|---|---|
| GPT-5-mini (long-context) | 82.0 | 53.3 |
| text-embed-3-large (RAG) | 80.0 | 26.7 |
| GraphRAG | 84.0 | 66.7 |
| HippoRAG 2 | 80.0 | 66.7 |
| A-Mem | 74.0 | 66.7 |
| STITCH | 86.0 | 80.0 |
| GAM | 70.0 | 60.0 |
| ReFind (5회) | 93.2 ± 3.3 | 89.3 ± 6.0 |
HippoRAG 2랑 차이가 GPT-4o-mini 때는 0.6점이었는데 여기서는 13.2(S), 22.6(M)으로 벌어진다.
모델이 좋아질수록 검색을 직접 하는 쪽이 유리해진다고 한다. 구조화 시스템은 인덱스를 미리 만들어뒀으니 모델이 좋아져도 얻는 게 적다는 것이다.
4.3 무엇이 효과를 냈나
| 변형 | S | M | ∆S | ∆M |
|---|---|---|---|---|
| 전체 (5회) | 93.2 ± 3.3 | 89.3 ± 6.0 | — | — |
| 일반 agentic BM25 | 78.7 ± 4.6 | 82.2 ± 3.8 | −14.5 | −7.1 |
| 컨텍스트 창 제거 | 84.0 ± 0.0 | 84.4 ± 3.8 | −9.2 | −4.9 |
| 세션 dedup 제거 | 92.0 ± 4.0 | 80.0 ± 6.7 | −1.2 | −9.3 |
| RRF 재랭킹 제거 | 89.3 ± 1.2 | 84.4 ± 7.7 | −3.9 | −4.9 |
| 시간 필터 제거 | 91.3 ± 4.2 | 84.4 ± 3.8 | −1.9 | −4.9 |
| 검색 1회만 (3회) | 84.7 ± 3.1 | 68.9 ± 3.8 | −8.5 | −20.4 |
검색을 한 번만 하면 M에서 −20.4로 제일 많이 떨어진다. 기록이 길수록 한 번에 못 찾는다.
채팅용 기능을 다 빼고 그냥 agentic BM25로 돌리면 S에서 −14.5다. 에이전트가 여러 번 검색하는 것만으로 되는 게 아니고, 세션·시간·맥락·중복을 다루는 기능도 꽤 역할을 한다는 것이다.
검색 백엔드도 바꿔봤는데 BM25 93.2, dense 91.3, hybrid 91.3으로 sparse가 조금 낫거나 비슷했다고 한다.
4.4 비용
| 방법 | 검색 횟수 | LLM 호출 | 토큰/문항 | 시간/문항 |
|---|---|---|---|---|
| 전체 (S) | 2.61 | 4.99 | 69.8K–76.4K | 119.3s / 41.0s |
| 전체 (M) | 2.43 | 4.99 | 83.1K–99.2K | 143.5s / 42.3s |
| 일반 agentic (S) | 2.03 | 4.99 | 17.4K | 31.3s |
| 검색 1회 (S) | 1.00 | 2.00 | 9.6K | 14.5s |
정확도를 토큰으로 사는 셈이다. 검색 1회보다 토큰이 7배, 시간이 3배 든다.
대신 오프라인으로 인덱스 만드는 비용은 0이다. 어느 쪽이 싼지는 기록 크기랑 질문이 얼마나 자주 오는지에 달렸다.
5. 지금 관점: 우리 설계에 무엇을 뜻하나
메모리 구조를 짜기 전에 그게 필요한지부터 보려고 이 논문을 앞에 두고 읽었다.
표에서 Mem0(25.1)랑 Zep(26.6)이 BM25-RAG(48.8)의 절반 정도다. 구조화 메모리를 얹는다고 알아서 좋아지는 건 아니라는 것이다.
다만 그대로 받아들이기 어려운 부분도 있다.
- 여섯 벤치마크가 전부 정확한 사실을 찾는 문제다. conclusion 부분을 보면 논문도 범위를 이렇게 적었다. “for precise, evidence-grounded questions over chat archives”. 앞에서 본 서베이 분류로 치면 factual memory만 본 거고, experiential memory(실패에서 배우기, 스킬 쌓기)는 평가하지 않았다.
- 원본 대화를 다 보관하고 있다는 전제다. 보관 기간 제한이 있거나 개인정보를 지워달라는 요청이 오면 이 방식은 쓰기 어렵다.
- 질문 하나에 70~100K 토큰, LLM 5회 호출이다. 매 턴 메모리를 보는 챗봇에 그대로 넣기는 부담스럽다.
-> 그래도 구조화 메모리를 쓸 거면 BM25 반복 검색보다 나은지는 먼저 확인해봐야 할 것 같다.
네 가지 기능 중 RRF 2단 재랭킹이랑 컨텍스트 창 확장은 구조를 전제하지 않아서 구조화 메모리에 붙여도 된다. Qdrant 같은 벡터 DB를 쓰고 있어도 세션 단위 점수를 더해서 재랭킹하는 건 인덱스를 다시 안 만들고 붙일 수 있을 것 같다.
6. Conclusion
구조를 하나도 안 만들고 끝까지 밀어붙여서, 구조화 메모리의 이득 상당 부분이 구조가 아니라 질문할 때 검색을 잘 하는 데서 온다는 걸 보여준다.
여섯 벤치마크 평균 58.2(구조화 중 제일 높은 게 53.2), LongMemEval-S/M에서 93.2/89.3이다.
부수적인 장점도 있다고 한다. 검색 과정이 노트에 남아서 나중에 확인할 수 있고, 답을 원문 턴이랑 대조할 수 있고, 새 메시지가 오면 바로 반영된다. 앞에서 본 서베이 7.7의 trustworthy memory에서 말한 것들이다.
여태까지 메모리 시스템들이 미리 구조를 만들어두고 검색했다면, 이 방법은 원본을 그대로 두고 질문이 올 때 에이전트가 검색을 여러 번 하면서 찾는다.
다음은 Does Your Agent’s Memory Survive a Model Upgrade?다. 같은 메모리 저장소를 그대로 두고 모델만 바꿨을 때 에이전트가 잊는지를 잰 논문이다.
Leave a comment