AI 에이전트 문맥 관리, '나중에 압축' 대신 '미리 골라 담기'가 낫다
가 작업할 때 문맥 창(대화 기록을 담아두는 공간)이 점점 차오르는 문제를 다루는 두 가지 방식이 있다. 하나는 '반응형'으로, 문맥이 꽉 찰 때까지 기다렸다가 한꺼번에 압축하는 방식이다. 다른 하나는 '능동형'으로, 매 턴마다 무엇을 문맥에 추가할지 까다롭게 골라서 애초에 불필요한 정보가 쌓이지 않게 하는 방식이다. 대부분의 는 반응형을 쓰지만, 개발자는 몇 달에 걸쳐 능동형 방식을 만들었다. 핵심 원칙은 3번째 턴에서 에이전트가 내린 결정이, 이미 끝난 15번째 턴의 도구 실행 결과보다 훨씬 더 중요한 정보라는 것이다.
이를 똑같이 취급하면 '', 즉 중요하지 않은 정보가 쌓여 성능이 떨어지는 문제가 생긴다. PRAANA라는 시스템의 컴파일러는 작업 메모리를 활성(active), 소프트(soft), 하드(hard) 세 단계로 나눈다. 각 문맥 조각에 정보 밀도 점수를 매기고, BM25(키워드 기반 검색 알고리즘)와 의미 기반 유사도(s.js를 이용해 자체 프로세스 내에서 실행)를 함께 써서 어떤 정보를 다시 활성 문맥으로 불러올지 결정한다. 개발 과정에서 실수도 있었다. 초반에 급하게 만든 해시 기반 임베더(텍스트를 숫자로 변환하는 도구)를 임시로 썼는데, 이게 조용히 검색 순위를 망치고 있었다.
관련 없는 항목이 관련 있는 항목보다 위로 올라오는 등 순서가 뒤죽박죽이었다. 문제는 오류 메시지 하나 없이 그럴듯해 보였다는 점이라, 문제를 알아채는 데만 3주가 걸렸다. 결국 s.js 기반 임베더로 교체해 해결했다.
핵심 포인트
- 문맥 관리 방식은 '반응형'(꽉 차면 압축)과 '능동형'(매 턴 선별해 추가)으로 나뉜다
- 최근 턴의 결정은 이미 끝난 예전 턴의 도구 결과보다 우선순위가 높게 취급해야 한다
- PRAANA 컴파일러는 문맥을 active/soft/hard 3단계로 나누고 정보 밀도로 점수를 매긴다
- BM25()와 의미 기반 유사도(s.js)를 함께 써서 재호출 대상을 정한다
- 초기에 쓴 임시 해시 기반 임베더가 검색 순위를 조용히 망가뜨려 3주간 발견되지 않았다