에이전트의 메모리를 짧은 코드로 압축하면, 두 AI가 같은 오답에 동의하게 될까?

논문

과거의 대화를 기억하는 에이전트는 그것을 어딘가에 저장하고, 필요한 대목을 빠르게 찾아내야 합니다. FlyHash는 초파리의 후각에서 아이디어를 가져옵니다. 각 기억의 임베딩을 짧고 성긴 코드로 바꾸는데, 이 코드에서는 소수의 "활성 비트"만 켜집니다. 코드가 짧으니 메모리도 작습니다.

논문의 결과는 반가울 만큼 담백합니다. 같은 코드 크기에서 FlyHash는 SimHash보다 올바른 기억을 약 2.5배 더 자주 찾습니다(0.27 대 0.11). 메모리에 여유가 있을 때는 표준 HNSW 인덱스가 여전히 둘 다 앞서며, 저자들은 이 점을 숨기지 않습니다. 자기 방법이 어디서 지는지 밝히는 논문은 있어야 할 만큼 흔하지 않고, 우리가 그들에게 연락한 이유도 바로 그것이었습니다.

코드는 공개되어 있습니다. github.com/mohanji/flyhash-agent-memory.

대화는 이렇게 흘러갔다

시작은 Hugging Face의 논문 아래 댓글이었습니다. 우리는 질문이 정형화된 문장이 아니라 말을 바꿔 표현된 경우 코드가 어떻게 버티는지 물었습니다. Mohan은 지금까지의 테스트가 정형화된 문장을 썼다고 답하며, 어떤 데이터셋이 좋겠느냐고 되물었습니다. 우리는 길고 실제적인 여러 세션의 대화로 만들어진 두 가지, LoCoMo와 LongMemEval을 제안했습니다. 그는 LoCoMo로 먼저 시작하고 LongMemEval을 뒤따르기로 했습니다.

그다음 우리는 그의 작업과 우리 작업을 잇는 질문을 던졌습니다. 가장 짧은 코드는 하나의 사실에 대한 질문보다 시간에 대한 질문("그녀는 언제 이사했지?")에서 더 많이 잃을까요?

서로를 검증하는 두 AI에게 메모리가 중요한 이유

서로 다른 회사의 두 모델이 같은 답에 동의하면 흔히 좋은 신호로 받아들여집니다. 하지만 에이전트에서는 두 모델이 대개 똑같이 검색된 메모리를 읽습니다. 검색이 사실을 놓쳤다면 둘은 더 이상 독립적이지 않습니다. 같은 오답에 자신 있게 동의할 수 있습니다.

이런 일이 얼마나 자주 일어나는지 보려고, 우리는 LoCoMo 위에서 작은 공개 검사 memory-agreement-check를 만들었고, 평범한 키워드 메모리(BM25, 상위 10개 대화 턴)로 한 번 돌렸습니다. GPT와 Claude가 따로 답했고, Kimi가 블라인드로 채점했습니다.

두 모델의 오류는 강한 상관을 보였습니다(φ = 0.81). 리트리버 하나, 시드 하나였으므로 이것은 연관성일 뿐 원인은 아닙니다. 그래도 FlyHash가 답해야 할 정확한 질문을 하나 만들어 줍니다.

우리가 함께 진행하는 실험

Mohan이 검색 쪽을 맡겠다고 했고, 그다음은 우리가 이어받습니다.

1. Mohan이 먼저 검색 성능을 측정합니다. LoCoMo의 카테고리(단일 홉, 다중 홉, 시간)별 recall@k를 FlyHash와 SimHash의 여러 코드 크기, 즉 활성 비트 16, 32, 64, 128개에서 구하며, 첫 실행과 맞춰 질문당 상위 10개 기억을 씁니다.
2. 우리는 상위 5개도 추가하자고 제안했습니다. 기억이 적을수록 놓치는 일이 늘 테고, 자신 있게 틀린 동의 답의 비율이 얼마나 빨리 커지는지 드러날 것입니다.
3. 그가 검색된 문맥을 질문당 한 줄씩 JSONL로 보냅니다.
4. 우리는 각 파일에 일치 검사를 돌려 결과를 그에게 보냅니다.

마지막에 읽어낼 질문은 이것입니다. 코드가 짧아질수록 두 AI가 동의하고도 틀리는 답의 비율이 올라가는가, 그리고 시간에 관한 질문에서 가장 빨리 올라가는가? 그렇다면 작은 메모리에는 두 번째 AI의 검증으로도 걸러지지 않는 숨은 비용이 있는 것입니다. 그렇지 않다면 FlyHash는 논문이 말하는 것보다도 더 좋아 보입니다.

코드

이 검사는 어떤 리트리버의 출력이든 받습니다. 질문당 한 줄입니다.

{"qid": "conv-26/0", "memories": [{"text": "[D1:3 | 1:56 pm on 8 May, 2023] Caroline: I went to a LGBTQ support group yesterday...", "dia_id": "D1:3", "score": 0.82}]}

저장소에는 Mohan의 코드에 있는 FlyHash와 SimHash 클래스로 이런 문맥을 만드는 예제가 이미 들어 있습니다.

git clone https://github.com/mohanji/flyhash-agent-memory
pip install numpy sentence-transformers
python examples/flyhash_contexts.py --flyhash-src flyhash-agent-memory/src \
  --method flyhash --active-bits 32 --out flyhash-k32.jsonl
python -m memcheck run --backend cli --contexts flyhash-k32.jsonl --memory-name flyhash-k32

같은 질문을 여러 코드 크기로 돌리거나 기준선으로 --method dense를 돌려 보면 비교가 됩니다.

첫 숫자가 말해 줄 수 있는 것과 없는 것

• 이 숫자들은 리트리버 하나(BM25), 모델 한 쌍, 심사자 하나, 시드 하나로 200개 질문에서 나왔습니다. 다른 리트리버와 모델이라면 모든 숫자가 움직일 수 있습니다.
• BM25가 근거를 놓치는 질문은 다른 질문들과 성격이 다르므로(다중 홉과 오픈 도메인 질문이 훨씬 더 자주 놓칩니다), 비교는 카테고리 안에서도 따로 합니다.
• 인과를 가리는 검사는 같은 질문에 근거 턴이 있을 때와 없을 때 한 번씩 답하게 하는 것입니다. 여러 코드 크기에서 돌리는 FlyHash는 그쪽으로 가는 자연스러운 한 걸음입니다. 질문도 모델도 같고, 바뀌는 것은 메모리뿐입니다.

타임라인

1. 2026년 11월 4일Mohan Bheemadolu와 Chrisogonas O. Odhiambo가 FlyHash를 arXiv(2611.05791)에 공개합니다.
2. 2026년 11월 10일논문이 Hugging Face Papers에 올라옵니다. 댓글에서 우리는 말을 바꿔 표현한 질문에 대해 묻고, Mohan은 어떤 데이터셋을 쓰면 좋겠느냐고 되묻습니다. 우리가 LoCoMo와 LongMemEval을 제안했고, 그는 LoCoMo를 먼저 고릅니다.
3. 2026년 11월 11일짧은 코드가 시간에 관한 질문에서 더 많이 잃는지 우리가 묻습니다. 공개 검사가 LoCoMo 질문 200개로 처음 돌아가고 FlyHash 예제도 함께 마련되며, 우리는 Mohan에게 숫자를 보냅니다.
4. 2026년 11월 12일Mohan이 계획을 정리합니다. k = 10에서 16, 32, 64, 128비트별 카테고리 검색 재현율을 구하고, 문맥은 JSONL로 보냅니다. 우리는 동의하며 k = 5를 더합니다.