Lightweight and Efficient Memory-Augmented Generation

Agent memory 연구는 무엇을 저장하고 어떻게 검색할지에 집중해 왔어요. A-MEM은 memory note를 그래프로 엮고, MemoryOS는 short/mid/long 계층을 두고, Mem0는 LLM으로 memory 연산을 관리해요. 셋 다 원본 대화를 그대로 LLM에 넣어 요약과 갱신을 수행해요. LightMem은 여기서 비용 문제를 봐요. 대화의 상당 부분이 중복인데 그 중복까지 backbone LLM에 실어 보내고 있어요.

• LightMem: Lightweight and Efficient Memory-Augmented Generation, arXiv, ICLR 2026.
• Code: github.com/zjunlp/LightMem

기존 memory system은 어디서 비용을 쓸까

논문은 memory bank 구축을 세 하위 단계로 정리해요.

\[D^{(g)} = f_{\text{seg}}(D; g), \quad E = f_{\text{sum}}(D^{(g)}), \quad M' = f_{\text{update}}(M, R; U)\]

$D$ 는 원본 대화 기록이에요. $g$ 는 이 기록을 어떤 단위로 잘라 memory에 넣을지 정하는 값이고, 대화에서는 발화와 응답 한 쌍인 turn, 대화 한 묶음인 session, 의미 단위인 topic 중에서 골라요. $D^{(g)}$ 는 그렇게 잘린 조각이에요. $g$ 를 어떻게 잡느냐가 요약 호출 횟수와 요약 품질을 함께 결정해서, 논문 전체에서 계속 등장해요.

$E$ 는 조각을 요약하거나 추출해 만든 memory entry이고, 벡터 DB나 knowledge graph에 저장돼요. $M$ 은 현재 memory bank, $R$ 은 새로 만들어진 entry, $U$ 는 갱신과 망각 정책이고, $M’$ 은 갱신된 memory bank예요.

$f_{\text{sum}}$ 과 $f_{\text{update}}$ 만 backbone LLM 호출이라 비용은 거의 전부 여기서 나와요. $f_{\text{seg}}$ 는 규칙 기반이라 부담이 없어요.

저자들이 지적하는 한계는 세 가지예요.

• Sensory memory가 없어요. 대화에는 downstream task와 무관한 토큰이 많은데, 기존 시스템은 걸러내지 않고 원본을 요약 모델에 넣어요. 토큰만 늘고 in-context learning 성능은 떨어질 수 있어요.
• Short-Term Memory granularity가 고정돼 있어요. Turn 단위로 자르면 호출 횟수가 늘고, session 단위로 묶으면 여러 topic이 섞여 부정확한 memory entry가 나와요.
• Long-Term Memory 갱신이 추론과 붙어 있어요. Test time에 갱신하면 그 지연을 사용자가 그대로 겪어요. Read-after-write 제약 때문에 갱신이 순차로 진행돼서 지연이 쌓여요.

세 모듈이 Atkinson-Shiffrin 모형을 따라요

LightMem은 인간 기억의 sensory, short-term, long-term 3단계를 그대로 모듈로 옮겨요.

Light1은 원본 입력에서 중요한 정보만 남기는 sensory memory, Light2는 topic 단위로 요약을 만드는 STM, Light3는 갱신을 오프라인으로 미루는 LTM이에요. 세 모듈 모두 backbone LLM 호출 횟수를 줄이는 데 맞춰져 있어요.

Sensory memory는 토큰 단위로 걸러내요

Pre-compressing submodule은 압축 모델 $\theta$ 로 각 토큰의 보존 확률을 계산하고, 상위 $r$ 분위에 드는 토큰만 남겨요.

\[\hat{\mathbf{x}} = \{x_i \in \mathbf{x} \mid P(\text{retain } x_i \mid \mathbf{x}; \theta) > \tau\}, \quad \tau = \text{Percentile}(\{x_j\}, r)\]

기본 구현은 LLMLingua-2예요. 압축을 토큰 단위 이진 분류로 두고 retain 클래스의 softmax 확률을 써요.

\[P(\text{retain } x_i \mid \mathbf{x}; \theta) = \text{softmax}(\ell_i)_1\]

생성형 LLM을 압축 모델로 쓰는 대안도 있어요. 이때는 예측 분포와 실제 토큰 라벨 사이의 cross-entropy를 보존 점수로 써요. 조건부 entropy가 높은 토큰일수록 예측하기 어렵고 정보량이 크다고 봐요.

\[P(\text{retain } x_i \mid \mathbf{x}; \theta) = -\sum_{x_i \in \mathcal{V}} q(x_i) \log P(x_i \mid \mathbf{x}; \theta)\]

LLMLingua-2는 BERT 규모라 추론에 2GB 미만 GPU 메모리를 써요. 이 오버헤드도 runtime 지표에 포함했다고 논문에 적혀 있어요.

Topic segmentation submodule은 압축된 정보를 sensory buffer(512 토큰)에 쌓다가 가득 차면 경계를 찾아요. Attention 기반 경계 $\mathcal{B}_1$ 과 similarity 기반 경계 $\mathcal{B}_2$ 의 교집합을 최종 경계로 써요.

\[\mathcal{B}_1 = \{k \mid M_{k,k-1} > M_{k-1,k-2},\ M_{k,k-1} > M_{k+1,k},\ 1 < k < n\}\] \[\mathcal{B}_2 = \{k \mid \text{sim}(s_{k-1}, s_k) < \tau,\ 1 \le k < n\}, \quad \mathcal{B} = \mathcal{B}_1 \cap \mathcal{B}_2\]

$M \in \mathbb{R}^{n \times n}$ 은 turn 단위 attention matrix이고, $\mathcal{B}_ 1$ 은 수열 ${M_ {k,k-1}}$ 의 local maxima예요. 논문은 이 수열을 $M$ 의 sub-diagonal elements라고 부르는데, 주대각선 바로 아래 줄에 놓인 원소들이라 인접한 두 문장 사이의 attention만 모아 놓은 값이에요. 어떤 문장이 직전 문장에 주는 attention이 앞뒤 위치보다 높으면 그 문장을 새 topic의 시작으로 봐요. Attention sink를 줄이려고 앞뒤 3개 토큰을 마스킹하고 LLMLingua-2의 8~11층 attention만 평균해요.

Attention matrix를 user 발화만으로 만든다는 점이 눈에 띄어요. Assistant 응답은 같은 turn 안에서 user의 주제를 따라간다고 봤고, LLMLingua-2의 최대 입력 길이가 512 토큰이라는 제약도 있었어요. 이 선택은 뒤의 category별 결과에 그대로 나타나요.

Short-term memory는 topic 단위로 모아서 한 번에 요약해요

Topic segment는 {topic, message turns} 구조로 STM buffer에 들어가요. Buffer의 토큰 수가 임계값 $th$ 에 도달할 때만 $f_{\text{sum}}$ 을 호출해요.

\[\text{sum}_i = f_{\text{sum}}(S_i), \quad S_i \subseteq \{\text{user}_i, \text{model}_i\},\ S_i \neq \emptyset\] \[\text{Entry}_i = \{\text{topic},\ \mathbf{e}_i := \text{embedding}(\text{sum}_i),\ \text{user}_i,\ \text{model}_i\}\]

요약 호출의 트리거가 turn 수가 아니라 buffer 용량이라는 점이 핵심이에요. 여러 session을 한꺼번에 넣으면 호출은 줄지만 topic이 섞여 요약 품질이 떨어져요. Topic 경계로 내부를 정리한 뒤 buffer 단위로 묶으면 호출 수를 줄이면서 요약 정확도를 지킬 수 있다는 주장이에요.

Long-term memory는 자는 동안 정리해요

Test time에는 갱신을 하지 않아요. 새 entry가 오면 timestamp를 붙여 LTM에 삽입하고 끝이에요. 이걸 soft update라고 불러요. 모든 삽입이 끝나거나 갱신 트리거가 오면 entry마다 갱신 후보 큐를 계산해요.

\[Q(e_i) = \text{Top}_k \{(e_j, \text{sim}(v_i, v_j)) \mid t_j \ge t_i,\ j \neq i\}_{:n}\]

유사도 상위 $k$ 개를 후보로 삼되, timestamp가 더 늦은 entry만 이전 entry를 갱신하도록 제한해요. 이 단계는 유사도 검색뿐이라 가볍고 온라인 추론과 병렬로 돌릴 수 있어요.

두 번째는 offline parallel update예요. 기존 프레임워크는 순서 제약 때문에 갱신을 순차로 실행하지만, LightMem은 entry마다 독립적인 큐를 갖고 큐끼리 대상이 겹치지 않아요. 그래서 $f_{\text{update}}$ 호출을 병렬로 실행해요. 온라인 지연을 오프라인으로 옮긴 게 아니라 전체 지연을 줄인다고 저자들은 설명해요.

절감량은 수식으로 계산돼요

$N$ turn 대화에서 turn당 평균 $T$ 토큰이라고 할 때, 기존 시스템은 turn마다 요약을 호출해요.

\[N(L_{\text{sum-in}} + T + L_{\text{sum-out}}),\quad \text{API calls} = N\]

LightMem은 압축을 $x$ 회 반복해 $r^x T$ 토큰만 남기고 buffer가 $th$ 에 찰 때만 호출해요.

\[\frac{N r^x T}{th}(L_{\text{sum-in}} + th + L_{\text{sum-out}}),\quad \text{API calls} = \frac{N r^x T}{th}\]

호출 수가 $N$ 에서 $\frac{N r^x T}{th}$ 로 줄고, runtime도 $O(N)$ 에서 $O(\frac{N r^x T}{th})$ 가 돼요. 갱신 쪽에서는 timestamp 제약이 갱신을 유발하는 entry 비율 $R_2$ 를 $R_1$ 보다 낮춰서 추가로 절감돼요. 절감량이 $th$ 에 반비례한다는 점은 뒤의 파라미터 분석으로 이어져요.

효율 이득은 크고 정확도 이득은 조건을 타요

실험은 LongMemEval-S와 LoCoMo에서 GPT-4o-mini, Qwen3-30B-A3B, GLM-4.6 백본으로 진행했어요. 대화를 turn 단위로 하나씩 흘려 넣는 incremental feeding 세팅이에요. 효율 지표는 memory bank 구축 단계의 LLM 호출만 재요. 검색과 QA 단계는 모든 방법이 같게 맞춰져 있어서 시스템 설계 차이와 무관하다고 봤어요.

GPT-4o-mini에서 LightMem($r=0.7$, $th=512$)은 ACC 68.64를 기록해요. 최고 baseline인 A-MEM이 62.60, FullText가 56.80, NaiveRAG가 61.00이에요. 토큰은 A-MEM 1,605.81k 대비 온라인 28.25k, 호출은 986.55회 대비 18.43회, runtime은 5,132.06초 대비 283.76초예요. 온라인과 오프라인을 합쳐도 토큰 38배, 호출 30배를 줄이고, 온라인만 보면 106배와 159배로 벌어져요.

숫자를 읽을 때 기준을 확인해야 해요. 38배는 MemoryOS(2,991.75k) 대비이고, A-MEM과 비교하면 합산 기준 14배 수준이에요. 106배는 LightMem의 온라인 비용을 baseline의 전체 비용과 비교한 값이에요. 두 기준을 표에 함께 실은 점은 좋지만 헤드라인 숫자는 가장 유리한 조합에서 나와요.

LoCoMo에서는 양상이 달라요. GPT 백본에서 LightMem(0.8, 768)이 72.99로 A-MEM 64.16, Mem0 61.69를 앞서지만 FullText가 71.83이에요. Qwen 백본에서는 FullText 74.87이 LightMem 72.60보다 높아요. LoCoMo는 대화당 평균 9K 토큰이라 컨텍스트에 통째로 들어가고, 이 조건에서는 memory system이 원본을 그대로 넣는 방식을 이기지 못해요. 효율 이득은 남지만 정확도 우위는 긴 대화에서만 성립해요.

GLM-4.6에서도 같은 신호가 보여요. LightMem이 73.20이고 NaiveRAG도 73.20이에요. 백본이 강해질수록 memory 구조의 기여분이 줄어요.

압축률과 buffer 크기는 서로 얽혀 있어요

Figure 3(a)는 압축된 프롬프트를 그대로 in-context QA에 넣었을 때의 정확도예요. $r$ 이 50~80% 구간이면 원본과 성능이 비슷해요. 압축이 downstream 이해를 해치지 않는다는 전제를 확인한 실험이에요.

$r$ 의 최적값은 $th$ 에 따라 달라져요. $th \in {0, 256}$ 처럼 buffer가 작으면 $r=0.6$ 이 가장 좋고, $th \in {512, 1024}$ 로 커지면 $r=0.7$ 이 좋아요. Buffer가 크면 덜 압축된 정보를 담을 수 있어서 LLM의 long-context 처리 능력을 쓸 수 있다는 해석이에요. 효율 쪽은 반대로 $r$ 이 낮을수록 buffer 임계값에 덜 도달해서 호출과 토큰이 함께 줄어요.

$th$ 의 영향은 방향이 갈려요. 효율은 $th$ 가 커질수록 단조롭게 좋아지지만 ACC는 비단조예요. GPT와 $r=0.6$ 조합에서 $th=0$ 일 때 70.35였다가 $th=1024$ 에서 59.68까지 떨어지고, Qwen과 $r=0.6$ 에서는 $th=768$ 의 73.20이 $th=0$ 의 69.56보다 높아요. 효율만 보면 $th$ 를 키우면 되지만 정확도 최적점은 모델과 $r$ 에 따라 매번 다시 찾아야 해요. 실무에서는 이 튜닝 비용을 함께 계산해야 해요.

Topic segmentation은 정확도를 담당해요

Segmentation 정확도는 LongMemEval의 session 경계를 ground truth로 삼아 측정했어요. Attention만 쓰거나 similarity만 쓰는 경우보다 두 신호의 교집합이 모든 압축률에서 높았고, 절대 정확도는 80%를 넘어요.

Ablation이 이 모듈의 역할을 보여줘요. 제거하면 효율은 나아지지만 ACC가 GPT에서 6.3%p, Qwen에서 5.4%p 떨어져요. 압축이 비용을 줄이는 모듈이라면 topic segmentation은 그 압축으로 잃는 정확도를 되찾는 모듈이에요.

Soft update가 작동하는 이유는 삭제를 안 하기 때문이에요

논문의 case study가 이 설계를 요약해요. 월요일 2시에 “도쿄 여행을 계획 중”이라는 기록이 있고 4시에 “교토행 기차를 문의”한 기록이 들어왔다고 해봐요. Hard update는 두 정보를 충돌로 읽고 앞의 항목을 덮어써서 도쿄 맥락을 잃어요. Soft update는 둘 다 남겨요.

LLM에게 실시간 갱신 판단을 맡기면 모순이 아닌 정보를 모순으로 읽고 삭제하는 경우가 생겨요. 삭제는 되돌릴 수 없어요. LightMem은 test time에 삽입만 하고, 통합과 중복 제거는 오프라인에서 여러 후보를 함께 보며 처리해요.

표를 보면 오프라인 갱신이 항상 이득은 아니에요. GPT $r=0.5$, $th=256$ 에서는 64.29가 64.69로 오르지만 $r=0.6$ 에서는 67.78이 65.39로, $r=0.7$ 에서는 68.64가 67.07로 떨어져요. Qwen에서도 70.20이 65.14가 돼요. LongMemEval에서 오프라인 갱신은 정확도를 유지하거나 낮추면서 비용은 늘려요. LoCoMo에서는 갱신 토큰이 4k 수준으로 작고 갱신 후 수치를 보고했어요. 갱신 메커니즘의 가치는 벤치마크에 따라 달라져요.

Category별로 보면 약점이 드러나요

LongMemEval의 질문 유형별 정확도를 보면 강약이 나뉘어요. GPT 기준으로 LightMem은 Temporal 67.18, Multi-Session 71.74로 A-MEM(47.36, 48.87)을 앞서요. 여러 session에 흩어진 정보를 통합하는 문제에서 topic 단위 memory가 유리하다는 근거예요.

반면 Single-Assistant에서는 32.14예요. A-MEM 96.43, NaiveRAG 98.21과 차이가 커요. Qwen에서도 31.25로 같은 패턴이에요. Assistant 발화 한 곳에만 답이 있는 유형인데, topic segmentation이 user 발화만 쓰고 압축까지 거치는 구조와 맞물린 결과로 보여요. 전체 ACC 우위는 이 손실을 다른 category에서 메운 결과예요.

마무리하며

LightMem의 기여는 새로운 memory 표현이 아니라 파이프라인 재배치예요. 압축 모델을 앞단에 두고, 요약 호출을 buffer 단위로 묶고, 갱신을 오프라인 병렬로 옮겼어요. 세 조작 모두 backbone LLM 호출 횟수 하나를 겨냥해요. Memory 연구가 구조를 키우는 방향으로 움직여 온 가운데 비용을 일급 지표로 놓은 점이 이 논문의 자리예요.

읽으면서 남는 질문은 두 가지예요.

• 효율 이득의 출처가 압축인지 buffering인지 분리되지 않아요. Ablation은 topic segmentation만 다루고, pre-compression을 뺀 조건이나 buffer 임계값만 키운 조건은 비교하지 않아요. $\frac{N r^x T}{th}$ 만 보면 $th$ 를 키우는 것으로도 상당 부분이 설명돼요.
• 정확도 우위의 조건이 좁아요. LongMemEval처럼 115k 토큰짜리 긴 히스토리에서는 이득이 나오지만, LoCoMo에서는 FullText와 비슷하거나 낮고 GLM-4.6에서는 NaiveRAG와 같아요. 효율 주장은 견고한 반면 효과 주장은 벤치마크와 백본에 의존해요.

실용적 함의는 분명해요. LLMLingua-2를 추가하는 비용은 2GB 미만이고, 그 대가로 backbone 호출을 두 자릿수 배수로 줄여요. Memory 시스템을 서비스에 올릴 때 병목이 정확도가 아니라 API 비용인 경우가 많다는 점을 생각하면 해볼 만한 교환이에요. 저자들은 후속 과제로 오프라인 KV cache 사전 계산과 lightweight knowledge graph memory 통합을 남겨 뒀어요.