Context Compression

긴 컨텍스트를 요약·압축할 때 무엇을 보존하고 무엇을 잃는가.

Scope

핵심 질문

긴 대화나 Agent 작업에서 컨텍스트를 압축할 때 무엇을 요약하고 무엇을 반드시 보존해야 하는가?

포함 범위

요약 기반 압축
최근성·중요도·의존성
손실 정보
재검색 가능한 원문
Agent 장기 작업에서의 실패모드

제외 범위

특정 제품의 컨텍스트 압축 기능 비교

Research

핵심 근거

컨텍스트 윈도우는 유한하므로 장기 세션에서는 과거 정보를 모두 유지하기 어렵다.
요약은 토큰을 줄이지만 세부조건, 부정문, 예외, 식별자를 잃을 수 있다.
압축된 요약과 원문에 대한 retrieval 경로를 함께 두면 손실을 줄일 수 있다.

참고 자료

Lewis et al., Retrieval-Augmented Generation: https://arxiv.org/abs/2005.11401
Liu et al., Lost in the Middle: https://arxiv.org/abs/2307.03172

Draft

Context Compression은 모델에게 전달할 과거 정보의 양을 줄이면서도 이후 작업에 필요한 의미를 최대한 보존하는 과정이다.

Agent나 장기 대화에서는 모든 메시지, 파일, 도구 결과를 계속 컨텍스트에 넣을 수 없다. 어느 시점부터는 오래된 내용을 요약하거나 외부 저장소로 옮겨야 한다.

왜 압축이 필요한가

컨텍스트 윈도우가 커져도 비용과 성능문제는 남는다.

입력이 길어질수록 처리할 토큰이 늘고, 중요한 정보가 긴 문맥 안에 묻힐 수 있다. 따라서 단순히 최대 길이까지 채우는 것보다 필요한 정보만 선별하는 편이 효율적이다.

가장 단순한 방법: 요약

오래된 대화 여러 턴을 하나의 요약문으로 바꾸면 큰 폭으로 토큰을 줄일 수 있다.

문제는 요약이 본질적으로 손실 압축이라는 점이다. 'A를 사용하기로 했다'는 결론은 남아도 왜 A를 선택했는지, 어떤 조건에서는 B를 써야 하는지 같은 예외가 사라질 수 있다.

무엇이 자주 손실되는가

압축에서 특히 위험한 정보는 다음과 같다.

숫자와 날짜
정확한 파일명·식별자
부정문과 금지조건
예외조건
사용자가 이미 거부한 선택지
아직 해결되지 않은 TODO
이전 단계가 다음 단계에 미치는 의존성

이런 정보는 자연어 요약보다 구조화된 상태로 따로 보존하는 편이 좋다.

요약과 상태는 분리하는 것이 좋다

대화의 의미는 요약으로 보관할 수 있지만, 작업상태는 데이터 구조로 관리하는 편이 안정적이다.

예를 들어 현재 branch, 수정한 파일 목록, 실패한 테스트, 사용자가 승인한 범위 같은 값은 요약문 안에 섞기보다 명시적 필드로 저장할 수 있다.

원문을 버리지 않는다

좋은 압축 시스템은 모델 컨텍스트에서 원문을 제거하더라도, 보관할 권한과 목적이 있는 작업상 중요한 기록은 정해진 기간 동안 별도 저장소에서 재검색할 수 있게 한다. 다만 원문을 무조건 영구 보관하지 않는다. 개인 데이터와 비밀값은 최소화·분리하고 접근을 제한하며, 목적이 끝나거나 삭제 의무가 생기면 삭제·익명화 또는 필요한 비민감 근거만 보존한다.

허용된 기간에 필요한 원문을 다시 검색할 수 있으면 요약에서 빠진 세부정보를 retrieval로 복구할 수 있다.

이 구조는 '짧은 working context + 검색 가능한 긴 기록'으로 볼 수 있다.

언제 압축해야 하는가

무조건 일정 토큰마다 요약하는 것보다 작업 경계가 좋은 압축 지점이다.

하나의 조사단계가 끝났거나, 구현단위가 완료됐거나, 의사결정이 확정된 시점에는 이전 세부과정을 결과와 근거 중심으로 압축하기 쉽다.

반대로 문제 해결 중간에 너무 공격적으로 압축하면 아직 필요한 단서를 버릴 수 있다.

핵심

Context Compression의 목표는 오래된 텍스트를 짧게 만드는 것이 아니라 미래의 의사결정에 필요한 정보를 보존하면서 컨텍스트 비용을 줄이는 것이다. 요약, 구조화된 상태, 허용된 범위와 기간의 원문 retrieval을 함께 사용하는 것이 유용하다.