토큰 소비 32% 절감 및 성능 15%p 향상시킨 Hybrid Retrieval 기반 Memory 설계

Your OpenClaw Bill Is Bleeding Tokens. Here’s What We Measured — and How to Fix It.

Charles Wu2026년 5월 14일13분intermediate

AI 요약

Context

OpenClaw의 기본 메모리 구조는 MEMORY.md 파일을 System Prompt에 전체 주입하는 방식을 채택하여 세션이 길어질수록 Input Token 비용이 기하급수적으로 증가하는 구조임. 또한 Lossy Compression 방식의 Compaction과 단순 길이 기반 Slicing으로 인해 문맥 유실과 재학습 비용이 발생하는 악순환이 반복되는 한계가 있음.

Technical Solution

Full-load 방식에서 벗어나 현재 토픽과 연관된 메모리 슬라이스만 선택적으로 주입하는 Retrieval-first Path 설계
BM25 Keyword Scoring과 Vector Similarity를 결합한 Hybrid Retrieval을 통해 컨텍스트 정밀도 확보
Tool Call 결과물과 같은 대규모 중간 데이터를 배제하고 사용자-어시스턴트 대화에서만 Atomic Fact를 추출하는 Phase 1 로직 구현
추출된 사실을 기존 메모리와 대조하여 ADD, UPDATE, DELETE, NONE으로 분류하는 Phase 2 Decision 프로세스로 데이터 중복 및 모순 방지
시간 정보 보존 및 원문 언어 유지 원칙을 통해 정보 손실을 최소화하는 추출 규칙 적용
세션 외부의 Cloud Database에 메모리를 저장함으로써 기기 간 연속성 확보 및 세션 리셋 시의 컨텍스트 재구축 비용 제거

실천 포인트

- System Prompt에 정적 파일 전체를 주입하고 있는지 확인하고 Vector DB 기반의 Dynamic Injection으로 전환 검토 - LLM 요약(Compaction) 시 발생하는 정보 유실을 방지하기 위해 Atomic Fact 단위의 추출 및 저장 프로세스 도입 - Tool Output과 같은 고용량 중간 데이터를 메모리 저장 대상에서 분리하여 컨텍스트 오염 방지

태그

#Context Window #Hybrid Retrieval #LLM Memory #vector-embedding #Token Optimization

원문 읽기