우리는 자체 요약이라고 하는 강화 학습 과정을 통해 장기 작업을 위해 Composer를 훈련합니다. 자체 요약을 Composer의 훈련 일부로 만들면, 모델의 최대 컨텍스트 window보다 훨씬 긴 궤적에서 훈련 신호를 얻을 수 있습니다. 이는 Composer가 수백 개의 행동이 필요한 도전적인 코딩 작업을 수행하는 법을 학습할 수 있음을 의미합니다.

#압축 기법의 한계

Cursor의 내부 벤치마크 모음인 CursorBench에서, 도전적인 실제 코딩 과제에서 더 높은 성능은 더 많은 사고와 더 폭넓은 코드베이스 탐색과 직접적으로 연관되어 있음을 확인할 수 있습니다. 사용자가 에이전트와 함께 더 어렵고 더 야심 찬 과제를 수행할수록, 사고와 탐색의 효과는 더욱 커질 것으로 예상합니다.

하지만 가장 큰 과제는 에이전트의 실행 궤적이 모델의 컨텍스트 길이보다 더 빠르게 늘어나고 있다는 점입니다. 많은 에이전트 하네스는 이를 해결하기 위해 에이전트 워크플로우의 중간 단계로 압축을 사용합니다. 에이전트가 컨텍스트 한계에 도달하면, 하네스가 컨텍스트를 더 짧게 압축한 뒤 에이전트가 중단된 지점부터 생성을 계속하도록 합니다.

실제로 압축은 보통 하네스에서 두 가지 방식 중 하나로 처리됩니다. 하나는 프롬프트 기반 요약 모델을 사용하는 텍스트 공간 방식이고, 다른 하나는 모델이 오래된 컨텍스트를 버리는 슬라이딩 컨텍스트 윈도우 방식입니다. 연구자들은 또한 잠재 공간에서의 압축 방법도 살펴보기 시작했으며, 이 방식에서는 모델이 텍스트가 아니라 벡터로 컨텍스트를 기억하지만, 현재로서는 이러한 접근법이 텍스트 기반 방법보다 훨씬 느립니다.

이러한 압축 방식들은 공통적으로 모델이 컨텍스트의 중요한 정보를 잊게 만들어, 장시간 실행되는 과제를 진행할수록 성능이 떨어질 수 있다는 단점이 있습니다.

#학습된 행동인 자기 요약

Composer는 에이전트 기반 코딩에 특화된 모델로, Cursor 에이전트 하니스에서 강화 학습을 통해 훈련됩니다. 이를 통해 compaction-in-the-loop 방식으로 훈련될 수 있고, 요약하고 보존해야 할 가장 중요한 정보를 판단하는 능력이 향상됩니다.

Composer가 작업을 수행하다 정해진 컨텍스트 길이 임계점에 가까워지면, 계속 진행하기 전에 잠시 멈춰 자신의 컨텍스트를 요약합니다. 좀 더 정확히 말하면, 자기 요약 과정은 다음과 같이 작동합니다.

1. Composer는 정해진 토큰 길이 임계점에 도달할 때까지 프롬프트를 바탕으로 생성합니다.

2. 현재 컨텍스트를 요약하라고 요청하는 합성 쿼리를 모델에 삽입합니다.

3. 모델에 최적의 요약을 생각할 수 있는 작업 공간이 주어지고, 이후 압축된 컨텍스트를 생성합니다.

4. Composer는 요약과 대화 상태(플랜 상태, 남은 작업, 이전 요약 횟수 등)를 포함한 압축된 컨텍스트로 1단계로 다시 돌아갑니다.

Composer가 추론 시점에 이 과정을 잘 수행할 수 있도록, 학습에도 동일한 요약 절차를 포함합니다. 각 학습 롤아웃은 하나의 프롬프트-응답 쌍이 아니라, 요약으로 이어진 여러 생성으로 구성될 수 있습니다. 즉, 자기 요약 자체도 보상에 반영됩니다.

기술적으로 보면, 이를 위해 학습 방식을 크게 바꿀 필요는 없습니다. 우리는 이 체인에서 모델이 생성한 모든 토큰에 최종 보상을 적용합니다. 이렇게 하면 좋은 궤적에서의 에이전트 응답뿐 아니라, 그 응답이 제대로 작동하도록 만든 자기 요약에도 더 높은 가중치가 부여됩니다. 반대로 중요한 정보를 놓친 좋지 않은 요약은 가중치가 낮아집니다. Composer는 학습이 진행될수록 이 자기 요약 과정을 활용해 더 긴 컨텍스트를 구성하는 법을 익힙니다. 어려운 예제에서는 자기 요약을 여러 번 수행하는 경우도 많습니다.

#토큰 효율적 압축

자체 요약(self-summarization)을 테스트하기 위해, 이를 고도로 최적화된 프롬프트 기반 압축 베이스라인과 비교합니다. 압축 trigger를 바꿔 가며 어려운 소프트웨어 엔지니어링 task 세트를 대상으로 이 문제를 살펴봅니다.

베이스라인 압축 접근 방식에서는 요약 프롬프트가 수천 토큰에 달하며, 요약에 보존해야 할 내용을 설명하는 신중하게 다듬은 섹션이 거의 12개 포함됩니다. 출력되는 압축된 컨텍스트 역시 평균적으로 5,000토큰이 넘고, 컨텍스트의 핵심 정보를 설명하는 구조화된 섹션도 다수 포함합니다.

반면 Composer는 자체 요약을 하도록 학습되어 있기 때문에, "대화를 요약해 주세요"라는 문장 외에는 거의 내용이 없는 매우 짧은 프롬프트만 있으면 됩니다. 또한 어떤 정보를 유지해야 가치가 높은지 문맥에 따라 판단하도록 학습되므로, 출력되는 요약은 평균적으로 약 1,000토큰에 불과합니다.

자체 요약의 효과를 측정하기 위해, Composer를 컨텍스트 제약이 있는 두 가지 테스트 환경에서 테스트했습니다. 하나는 80k 토큰 trigger가 있는 환경이고, 다른 하나는 40k trigger가 있는 환경(즉, 요약이 더 자주 발생함)입니다. 두 시나리오 모두에서 자체 요약은 훨씬 더 토큰 효율적인 압축본으로 CursorBench에서 유의미하게 더 나은 결과를 냈습니다. 자체 요약은 목표에 맞춘 베이스라인 접근 방식과 비교해도, 압축으로 인한 오류를 일관되게 50% 줄이면서 토큰은 1/5만 사용하고 KV 캐시(이전 토큰에서 저장된 중간 계산값)도 재사용할 수 있습니다.

#어려운 문제 해결

컴팩션의 더 큰 가능성은 긴 추론 체인이 필요한 어려운 문제를 모델이 한 번에 해결할 수 있게 하는 데 있습니다. 현재 진행 중인 Composer 2 학습에서, 우리는 이것이 자주 일어나는 것을 확인했습니다. 사례 연구로 Terminal-Bench 2.0의 make-doom-for-mips라는 문제를 살펴보겠습니다. 이 문제는 짧게 설명할 수 있지만 그만큼 어렵습니다:

/app/doomgeneric/에 doom의 소스 코드를 제공해 두었습니다. 또한 렌더링된 각 프레임을 /tmp/frame.bmp에 저장하는, 제가 사용하길 원하는 특별한 doomgeneric_img.c도 작성해 두었습니다. 마지막으로 doomgeneric_mips라는 파일을 받아 실행하는 vm.js도 제공했습니다. 나머지는 알아서 해결해 주세요…

설명은 비교적 쉽지만, 이 문제는 공식 보고 수치에서 몇몇 강력한 모델조차 정답을 맞히지 못할 만큼 어렵습니다.

Composer의 초기 연구 체크포인트를 테스트했을 때, 우리는 이 문제가 올바르게 해결되는 것을 확인했습니다. 이 해법에는 상당한 양의 코드를 구현하고 테스트하는 작업뿐 아니라, 몇 가지 대안 구현을 탐색하는 과정도 필요했습니다. 다음은 이 문제를 해결하는 과정에서 렌더링된 이미지입니다:

전체적으로 Composer는 정확한 해법을 찾기 위해 170턴 동안 작업했고, 그 과정에서 간결하면서도 사람이 읽을 수 있고 구조화된 형태의 self-summaries를 생성했습니다. 100,000개가 넘는 토큰을, 문제 해결에 가장 도움이 될 것이라고 판단한 1,000개로 self-summarization했습니다:

#장기 미래를 향해

압축을 훈련 루프에 통합함으로써 Composer는 핵심 정보를 효율적으로 앞으로 전달하는 명시적 메커니즘을 학습하고, 도전적인 작업을 더 잘 수행할 수 있게 됩니다. 자체 요약에 대한 우리의 연구는 다중 에이전트 조율과 같이 더 길고 복잡한 과정에 걸쳐 Composer를 훈련하는 더 광범위한 목표를 향한 한 걸음입니다. 우리는 더 나은 모델 훈련이 이러한 에이전트형 시스템의 범위와 지능을 향상시킨다고 계속해서 보고 있습니다.

또한 곧 Composer의 다음 버전에 대해 더 자세히 공유할 예정입니다.