Pi에서의 압축 기능 작동 방식

코딩 에이전트에서의 컨텍스트 관리

대규모 언어 모델(LLM)은 고정된 컨텍스트 창 내에서 작동하기 때문에, 단일 요청 시 처리할 수 있는 입력의 양에 제한이 있습니다. 코딩 에이전트 세션에서는 시스템 프롬프트, 도구 정의, 대화 기록, 도구 출력이 계속 누적되면서 입력이 지속적으로 증가합니다. 이 총합이 컨텍스트 창의 크기를 초과하면, LLM은 크기 오류로 인해 요청을 거부하게 됩니다.

세션 실패를 방지하기 위해 에이전트는 새로운 대화를 시작해야 하며(모든 누적된 컨텍스트와 이전 결정을 버림), 또는 압축(compaction)을 구현해야 합니다. 압축은 기존 기록의 더 작은, 압축된 표현을 만들어 새로운 메시지를 위한 공간을 확보합니다.

Pi의 압축 구현 방식

Pi는 최근 메시지의 특정 예산을 유지하면서 오래된 대화 내용을 요약함으로써 압축을 구현합니다. 이 과정은 컨텍스트 한도가 창의 전체 크기에 근접할 때 자동으로 트리거되거나, /compact 명령어를 수동으로 사용하여 실행됩니다.

압축 프로세스

Pi의 압축은 에이전트가 중요한 정보를 유지하면서 토큰을 낭비하지 않도록 보장하기 위해 특정 워크플로우를 따릅니다:

유지 예산: Pi는 사용자 설정 가능한 최근 메시지 수(기본값은 20,000 토큰, 약 5~20턴)를 변경 없이 유지합니다.
직렬화: 유지 예산 이전의 모든 메시지를 추출하고 요약을 위해 직렬화합니다.
특화 요청: Pi는 표준 코딩 어시스턴트가 아닌, "컨텍스트 요약 어시스턴트"에 별도의 요청을 보냅니다. 이를 통해 요약에 더 비용 효율적인 LLM 모델을 사용할 수 있습니다.
구조화된 출력: 압축 프롬프트는 목표, 진행 상황, 핵심 결정 세 가지 섹션으로 나누어진 구조화된 요약을 명시적으로 요청합니다. 이는 다음 대화 단계에 대한 "핸드오프 브리핑" 역할을 합니다.

통합 및 이식성

결과로 생성된 요약은 세션 내 평문으로 저장됩니다. 이 방식은 압축된 컨텍스트가 사용자에게 읽기 쉬우며, 다양한 LLM 모델 간에 이식 가능하게 하여, 사용자가 모델을 전환해도 요약된 기록을 잃지 않도록 합니다.

프롬프트 캐싱에 미치는 영향

프롬프트 캐싱은 LLM 제공업체가 대화의 접두사 부분을 재사용함으로써 비용과 지연 시간을 줄입니다. 그러나 캐싱은 토큰 단위로 정확한 일치가 필요합니다.

압축은 오래된 대량의 기록을 새로운 요약으로 대체하기 때문에 대화의 접두사가 변경됩니다. 이는 기존 프롬프트 캐시를 무효화하게 되며, 요약 이후의 모든 토큰(유지된 최근 턴 포함)은 압축 후 첫 번째 요청 시 다시 계산되어야 합니다. 새로운 상태가 확립된 후에는 이후 요청에서 다시 캐싱의 이점을 누릴 수 있습니다.

다른 컨텍스트 전략과 커뮤니티의 시각

Pi는 LLM 기반 요약을 사용하지만, 개발자와 사용자들은 컨텍스트 오버플로우를 관리하기 위한 여러 대안 전략을 제안했습니다.

절단 vs. 요약

일부 사용자는 절단(저가치 메시지의 결정론적 제거)이 요약보다 우수하다고 주장합니다.

"요약된 대화는 LLM이 의도나 맥락을 놓치기 때문에 향후 대화가 더 짜증나는 경향이 있습니다."

제안된 절단 전략에는 "사고 흔적", 도구 호출 출력, 코드베이스 탐색 로그를 제거하면서 사용자 메시지와 최종 어시스턴트 결론은 유지하는 것이 포함됩니다.

아키텍처적 대안

중첩 스레딩: 오래된 메시지를 자가 요약하는 하위 스레드로 이동시키는 접근 방식으로, 부모 스레드는 깔끔하게 유지하면서 전체 기록은 자식 스레드에서 접근 가능하게 합니다.
동적 절단: 도구 호출 및 채팅 기록의 요약을 레이블을 사용해 동적으로 접고 펼 수 있는 일부 구현 방식.
KV 캐시 조작: 로컬 스택을 실행하는 사용자를 위한 제안으로, GPU에 직접 접근하여 추론 중 오래된 도구 호출을 요약으로 교체하거나 제거함으로써 전체 새로운 LLM 요청이 필요 없도록 하는 방식.
핸드오프: 압축 대신 현재 LLM에게 새로운 대화 세션에 필요한 모든 내용을 요약하도록 지시하는 "핸드오프" 방식을 선호하는 사용자도 있습니다.

현재 접근 방식의 한계

표준 압축에 대한 비판자들은, 로컬 LLM이 작은 요약을 생성하기 위해 128k 토큰을 분석하는 데 계산 비용이 매우 크다고 지적합니다. 또한 일부 사용자는 도구 호출 루프가 길 경우, 루프가 완료될 때까지 압축 한도를 확인하지 않아 Out-of-Memory(OOM) 오류가 발생할 수 있다고 보고했습니다.