컨텍스트 언어 모델 — 모델이 직접 관리하는 문맥

AI 요약

Context Language Models(CLM)는 모델이 자신의 문맥을 직접 관리하도록 설계한 언어 모델입니다. 연구진은 문맥을 파일로 취급하고 모델이 파일 내용을 자유롭게 갱신하도록 했습니다. 모델이 작업에 필요한 정보를 문맥에 남기고 불필요한 내용을 바꾸는 방식입니다. 여러 에이전트가 각자의 문맥 파일을 함께 쓰는 구성으로도 확장합니다.

기존 방식과 비교

기존 언어 모델은 대개 외부 하네스(harness)가 문맥을 요약하거나 교체합니다. CLM은 문맥 관리 결정을 모델 자체의 행동으로 옮깁니다. 연구진은 기존 모델을 별도 학습 없이(zero-shot) CLM 방식으로 구성했고, 여러 작업에서 최신 문맥 관리 전략보다 나은 결과를 보고했습니다.

BrowseComp-Plus에서는 정확도가 11.4% 높았고 FLOPs는 21.5% 적었습니다. 12시간 동안 수행하는 EdgeBench에서는 점수가 5% 높으면서 FLOPs를 59% 줄였습니다. 24시간짜리 다중 저장소 에이전트 스웜 작업에서는 같은 연산량으로 개선 폭이 65% 컸습니다.

문맥 관리 학습과 추론 비용

문맥 관리를 모델 안의 행동으로 다루면, 문맥 관리 전략을 입력 중에 익히는 방식과 모델 파라미터에 학습시키는 방식을 모두 적용할 수 있습니다. 연구진은 일반적인 스킬 최적화(skill-optimization) 반복 과정에서 자연어 지시를 발전시켰습니다. 이 방법은 문맥 관리 작업에서 보류 데이터의 정확도를 최대 35.9%포인트 높이면서 연산량도 줄였습니다.

온라인 강화학습(online reinforcement learning)도 적용했습니다. Qwen3.5-9B의 BrowseComp-Plus 성능은 47.6% 개선됐고 FLOPs는 12% 감소했습니다. 서빙 단계에서는 CLM에 맞춘 Suffix Cache Reuse를 제안했습니다. 같은 성능을 유지하면서 표준 SGLang보다 서버 측 연산을 35% 줄였습니다.

구현과 캐시 관련 쟁점

문맥 파일을 자주 수정하면 접두부가 바뀌어 KV 캐시를 재사용하기 어려워질 수 있습니다. Hacker News 댓글에서는 캐시 무효화와 재계산 비용을 걱정하는 의견이 나왔습니다. 반면 논문이 유효하지 않은 캐시 접미부를 그대로 둬도 성능이 나빠지지 않았다는 점이 더 흥미롭다는 반응도 있었습니다. 모델이 문맥을 직접 고치는 방식을 일반 API 호출만으로 구현하기 어렵고, 추론 구조나 서빙 인프라 변경이 필요할 수 있다는 지적도 제기됐습니다.

댓글에는 별도 에이전트가 문맥 관리를 맡으면 주 에이전트가 작업에 집중하고 캐시 무효화 시점도 제어하기 쉽다는 제안이 있었습니다. 이에 논문 코드가 문맥 관리 전략 제안에 별도 모델을 쓰는 구성을 지원한다는 답변이 달렸습니다. 또 파일에 기록을 쌓고 필요한 부분만 조회하는 접근, 세션 사이에 인계 메모를 남기는 방식과 비슷하다는 경험담도 나왔습니다. 일부는 CLM이 기존 요약·검색 기반 에이전트나 Recursive Language Models와 얼마나 다른지 질문했습니다.

Hacker News 반응

• @svachalek — 문맥 관리는 최신 LLM에서 아직도 번거로운 문제 중 하나라서, 이 방법이 큰 영향을 줄 수도 있겠습니다. 다만 캐시 무효화가 뻔한 난점인데, 해결책도 살펴봤다니 기대됩니다.
• @Bolwin — 가장 큰 발견은 일반적인 캐시 규칙을 무시하고 유효하지 않은 캐시 접미부를 유지해도 성능이 나빠지지 않았다는 점일 수도 있습니다.
  • @TeMPOraL — 바뀐 캐시 부분만 정확히 다시 채우고 RoPE 처리를 통째로 무시하면 성능이 얼마나 나빠질지 궁금합니다. 모델이 망가지거나 혼란스러워할까요, 아니면 내부적으로 보정할까요?
  • @dist-epoch — RoPE 문제는 단순 회전이라 계산 비용이 낮으니 건너뛸 이유가 없습니다. 이런 건 에이전트에게 로컬에서 시험해보라고 하면 됩니다.
• @visarga — 오늘날 어떤 모델이든 다음 문맥으로 파일을 보내면 똑같이 할 수 있지 않나요? 수정 범위에 따라 캐시 미스 비용을 치르겠지만, CLM은 재계산을 무시하는 것 같습니다.
  • @nsingh2 — 비슷한 근사 방식으로 Codex가 실험 중인 문맥 관리가 있습니다. 요약·압축에 기대는 대신 모델이 작업 중, 문맥 한도에 가까워질 때 메모를 유지합니다. 새 세션은 그 메모와 이전 세션을 가리키는 포인터를 붙인 새 문맥으로 시작합니다. 논문 방식과 똑같지는 않지만, 무엇을 어떻게 저장할지 모델이 결정하게 한다는 점은 비슷합니다.
• @bob1029 — 문맥 관리가 제한된 주의력을 소모할까 걱정됩니다. 에이전트가 기억 문제를 해결하게 할까요, 실제 작업을 하게 할까요? 둘 다 할 수 있겠지만 비용이 상당할 수 있습니다. 별도 하이퍼바이저 에이전트가 주 에이전트의 문맥을 관리하는 편이 제 경험상 더 낫습니다. 일정을 따로 돌릴 수 있고 주 에이전트는 토큰을 전혀 쓰지 않아도 됩니다. 캐시 미스 시점도 통제하기 쉽습니다.
  • @theroadnotbacon — 논문에서 그 방식도 시험한 것 같습니다. 코드도 지원합니다. 다만 제가 이해한 바로는 실제 문맥 관리가 아니라 문맥 관리 전략을 제안하는 용도입니다.
• @plastic-enjoyer — 문맥을 파일로 취급하고 모델이 마음대로 갱신한다면, LLM용 RAM 같은 건가요? LLM을 위한 MMU와 그에 딸린 추상화까지 다시 만들어야 하나요?
• @_jayhack_ — 모델이 문맥을 관리하게 하는 건 ‘쓴 만큼 확장하는’ 접근과 잘 맞습니다. 가장 큰 문제는 에이전트 문맥이나 접두부를 자주 수정하면 캐시 적중률이 크게 낮아진다는 점입니다. 그래서 Anthropic API 같은 방식으로 효율적으로 구현할 수 없습니다. 원리상 해결할 수는 있겠지만 트랜스포머 구조 변경이 필요할 수 있고, 서빙 인프라는 분명히 바꿔야 합니다.
  • @f_devd — KV 캐시는 긴 문맥에서 사실상 필수라서, 조기 최적화라고 보기는 어렵습니다.
• @sayamss — 허술해 보입니다. 이거 그냥 Recursive Language Models 아닌가요? 변수 대신 파일을 쓰는 것뿐인가요?

원문: arXiv / 번역·요약: Trawling