Memora knowledge-rag 벡터 검색 AI 에이전트 메모리 bge-m3
🔍 결론부터 말씀드리겠습니다
Microsoft Research가 ICML 2026에 발표한 장기 메모리 프레임워크 Memora의 헤드라인 주장 — 6~8단어짜리 짧은 추상화 핸들만 임베딩하면 검색 정확도를 높이면서 토큰도 대폭 절감할 수 있다 — 을 저희 자체 에이전트 메모리 시스템 knowledge-rag에 직접 적용해 실측했습니다. 결과는 예상과 달랐습니다. 핸들 단독 변형(C)은 4가지 variant 중 전 지표 최하위였고, cue-anchor 멀티벡터를 함께 쓴 C+ 변형만이 현행 시스템을 소폭 앞섰습니다.
논문 벤치마크 수치만 보고 도입을 결정하지 않고, 자기 데이터로 직접 검증한 과정과 그 결과를 공개합니다.
Microsoft Research가 ICML 2026에 발표한 에이전트 장기 메모리 프레임워크. 제목: “A Harmonic Memory Representation Balancing Abstraction and Specificity”. 저자 9명 전원 Microsoft, 2026-02-03 제출. MIT 라이선스, github.com/microsoft/Memora에서 공개.
📋 Memora가 무엇을 주장하는가
Memora는 메모리 엔트리를 세 요소로 분리합니다. Primary Abstraction(6~8단어 핸들, 검색 인덱스 키로 임베딩), Memory Value(원본 콘텐츠, 비임베딩 보관), Cue Anchors(엔티티·키워드 태그, 다중 접근 경로 제공)입니다. 신규 정보는 기존 엔트리에 병합(consolidation)해 파편화를 방지하고, 검색은 정적 top-k 대신 policy-guided 반복 검색을 사용합니다. 논문은 “표준 RAG와 KG 기반 메모리 시스템은 Memora 프레임워크의 특수 케이스”라고 주장합니다.
공개 벤치마크 수치는 인상적입니다. LoCoMo 86.3%(600턴 장기 대화 평가, 인간 천장 ~87.9%), LongMemEval 87.4%(500개 큐레이션 쿼리, 5가지 장기 기억 능력 평가), 풀 컨텍스트 인퍼런스 대비 토큰 최대 ~98% 절감(lab 측정치)입니다. Microsoft Research 공식 블로그는 2026년 6월 29일에 이를 발표했고, GitHub 레포지토리는 2026-07-02 기준 Stars 90을 기록하고 있습니다.
🏗️ 우리 knowledge-rag와의 비교
저희 knowledge-rag는 2-레이어 구조입니다. 하단에 오픈소스 임베더 bge-m3(BAAI 제작, 100+언어, 1024차원, dense+sparse+multi-vector 동시 지원, L2 정규화 시 cosine=dot product) + reranker, 메타데이터는 PostgreSQL, 벡터는 LanceDB(오픈소스 임베디드 멀티모달 벡터 DB, Lance 컬럼형 포맷, 하이브리드 검색 지원)를 사용합니다. 상단에는 인간이 큐레이션한 SOP 문서 레이어가 있습니다.
대화 메모리에는 importance 스코어링, decay, pin, 충돌 해소(conflict resolution), cosine≥0.7 자동 링크 memory-graph, 야간 dreaming consolidation이 포함되어 있습니다. 여기서 핵심은 하나입니다. 저희는 이미 원본 텍스트 전체가 아니라 LLM이 추출한 자기완결 팩트 문장(fact.text)을 임베딩하고, 원본(original_content)은 PostgreSQL·LanceDB에 비임베딩으로 보관합니다. Memora의 abstraction/value 분리와 구조적으로 이미 부분적으로 겹칩니다. 결정적 차이는 Cue Anchors 같은 다중 접근 경로가 없다는 점이었습니다. 그래서 질문은 명확했습니다. “핸들을 더 짧게 가는 Memora 방식이 우리 추출 팩트 임베딩에 추가 이득을 줄까?”
| 차원 | knowledge-rag (현재) | Memora |
|---|---|---|
| 임베딩 대상 | LLM 추출 fact.text |
6~8단어 핸들 |
| 원본 저장 | PostgreSQL + LanceDB (비임베딩) | Memory Value 필드 (비임베딩) |
| 멀티 접근 경로 | 단일 벡터 | Cue Anchors (다중) |
| 중요도 스코어링 | ✅ decay / pin / importance | ❌ |
| Consolidation | ✅ 야간 dreaming | ✅ 실시간 병합 |
| Memory graph | ✅ cosine≥0.7 auto-link | ❌ |
| Conflict resolution | ✅ importance≥0.5 기준 | ❌ |
| 성숙도 | production 매일 가동 | 연구 단계 |
🧪 PoC 설계
라이브 DB에 전혀 손대지 않고, 기존 데이터를 읽기 전용으로만 사용했습니다. 프로덕션 변경은 없습니다.
- 표본: 메모리 뱅크에서 50개 항목(여러 사실이 섞인 compound 위주)
- 쿼리: 100개 anti-circular 간접 쿼리 — 원본 콘텐츠에서만 생성해 특정 variant에 유리한 lexical home-field 이점이 생기지 않도록 설계
- 핸들·cue anchor 생성: 로컬 DGX Spark에 올린 오픈 LLM qwen3.6-35B-A3B (
192.168.0.123:8082) - 임베더: bge-m3 (mlx, L2 정규화 → cosine=dot product)
- 평가 지표: Recall@1 / @3 / @5 / MRR (높을수록 좋음)
비교한 4개 variant는 다음과 같습니다.
📊 실험 결과
4개 variant의 Recall@1/3/5, MRR 비교 결과입니다. C+(핸들+cue 멀티벡터)를 제외한 결과는 기대를 빗나갔습니다.
| Variant | R@1 | R@3 | R@5 | MRR |
|---|---|---|---|---|
| A — 원본 임베딩 | 0.06 | 0.23 | 0.40 | 0.220 |
| B — 추출 팩트 (현행) | 0.08 | 0.22 | 0.27 | 0.196 |
| C — 핸들 단독 | 0.06 | 0.17 | 0.23 | 0.170 |
| C+ — 핸들 + cue, max-sim | 0.09 | 0.26 | 0.42 | 0.255 |
개별 쿼리 단위에서는 차이가 더 극명하게 드러납니다. 아래는 간접 쿼리 유형별 정답 항목의 검색 순위입니다(숫자=순위, 낮을수록 좋음, 전체 50개 항목 중).
| 간접 쿼리 유형 | A | B | C | C+ |
|---|---|---|---|---|
| 특정 인스턴스의 설정 파일 경로·DB 크기를 묻는 쿼리 | 1 | 33 | 48 | 1 |
llama.cpp 빌드 b8946 vs b9006 파라미터 지원 차이 |
23 | 19 | 27 | 6 |
| Qwen3.6 Thinking Mode 샘플링 설정을 묻는 쿼리 | 20 | 2 | 10 | 1 |
첫 번째 쿼리에서 C가 48위까지 밀린 것이 이번 실험에서 가장 주목할 데이터 포인트입니다.
🔬 해석
C(핸들 단독)가 전 지표 최하위인 이유부터 짚겠습니다. 저희 메모리에는 파일 경로, 버전 번호, 파라미터 이름, 빌드 해시 같은 짧고 특수한 기술 식별자가 많습니다. 이런 정보를 6~8단어 추상화 핸들로 치환하면 lexical surface가 과도하게 손실됩니다. Memora 논문의 벤치마크(LoCoMo는 600턴 일상 대화, LongMemEval은 자연어 질문 중심)와 저희 도메인의 성격이 다르다는 것이 핵심 원인이었습니다.
C+가 현행 B를 앞선 이유는 핸들의 단축이 아닙니다. 다중 접근 경로와 max-sim 검색 방식이 이득의 핵심입니다. 엔티티·키워드를 별도 벡터로 인덱싱해두고 쿼리 시 가장 유사한 벡터를 취하는 구조가 효과를 냈습니다. Memora 논문에서 말하는 “표준 RAG와 KG 기반 메모리는 Memora의 특수 케이스”라는 주장의 일부를 실증한 결과이기도 합니다.
단, 한계를 명확히 해야 합니다. C+의 R@1 차이는 단 1개 쿼리에 불과하고, n=50/100 규모는 decision-grade 결론을 내리기에 부족합니다. 현 상태에서 production 변경은 보류입니다.
2차 발견도 있습니다. 원본 임베딩(A)이 추출 팩트(B)를 R@3/R@5/MRR에서 앞섰습니다. fact-extraction 단계의 recall 이득이 기대보다 작을 수 있다는 신호입니다. 다만 anti-circular 설계 자체가 lexical surface가 풍부한 원본에 유리하게 작용했을 가능성이 있어, 별도 평가 설계가 필요합니다.
📚 참고 문헌
- Memora 논문 (arXiv:2602.03315, ICML 2026) — Microsoft Research, 2026-02-03 제출
- Memora GitHub (MIT 라이선스) — Python 3.10+, Stars 90 (2026-07-02 기준)
- Microsoft Research 공식 블로그 — 2026-06-29 발행
- LoCoMo 벤치마크 점수 현황 — EmergentMind
- LongMemEval 논문 (arXiv:2410.10813) — 500 curated questions, 5가지 장기 기억 능력 평가
- AI 메모리 벤치마크 2026 비교 — mem0.ai
- Memora 실제 배포 분석 — InfoWorld
- bge-m3 — BAAI, HuggingFace
- LanceDB 공식 사이트
✅ 결론
세 가지로 정리하겠습니다. 첫째, Memora의 추상화 핸들(C)은 저희 시스템에서 regression입니다. 채택하지 않습니다. 저희 메모리 도메인(짧은 기술 식별자 다수)과 Memora가 검증된 도메인(자연어 대화 중심)의 성격이 다릅니다. 둘째, 전이 가능한 아이디어는 cue-anchor 멀티벡터 인덱싱입니다. 핸들 단축이 아니라 다중 접근 경로 + max-sim이 핵심이었습니다. 셋째, C+는 더 큰 n과 실제 recall 쿼리로 decision-grade 재실험이 필요합니다. 신호는 있으나 결론을 내리기에 데이터가 부족합니다.
이번 실험의 진짜 가치는 Memora가 정답인지 아닌지가 아닙니다. 화제의 연구를 자기 데이터로 직접 검증했더니 헤드라인은 regression이었고, 곁가지 아이디어만 소폭 유효했다 — 그것도 아직 신호 수준이라는 것을 실측으로 확인한 데 있습니다. AI 에이전트 메모리 아키텍처의 다른 설계 접근에 대해서는 ai-girls.org 테크 카테고리에서도 다루고 있으니 참고하시기 바랍니다. 벤치마크 숫자만 보고 결정하지 않는 습관 — 그것이 요점입니다.