컨텍스트 윈도우가 커질수록 중간에 '데드 존'만 커질 뿐이다
Bigger context windows just give you a bigger dead zone in the middle
핵심 요약
컨텍스트 윈도우가 커져도 모델의 주의력 한계와 압축 오류로 인해 성능이 저하되는 현상을 분석하고 해결책을 제시함.
- 주의력 한계 — 모델이 컨텍스트의 시작과 끝에만 집중하고 중간을 무시하는 U자형 주의력 문제 발생함
- 압축의 함정 — 무분별한 요약은 에이전트가 필요한 세부 정보를 삭제하여 오히려 성능을 저하시킴
- 해결 전략 — 전체 기록을 재주입하는 대신 필요한 정보만 선별하여 토큰 예산 내에서 관리해야 함
- 성능 측정 — 턴 5와 턴 50의 정확도를 비교하여 주의력 문제인지 압축 문제인지 파악해야 함
r/LocalLLaMA의 한 개발자가 에이전트 실행 847건을 추적해서 컨텍스트 윈도우가 찰수록 지시사항을 얼마나 잘 따르는지 측정해 봤거든. 처음엔 94%로 시작했는데 윈도우가 꽉 찰 때쯤엔 41%까지 곤두박질쳤어. 근데 이게 서서히 떨어지는 게 아니라 잘 버티다가 갑자기 절벽에서 떨어지듯 확 망가지는 거야. 사람들이 흔히 긴 대화에서 에이전트가 멍청해진다고 말하는 게 바로 이거거든. 사실 에이전트가 멍청해진 게 아니라 주변 컨텍스트가 개판이 된 거지.
왜 윈도우를 키워도 해결이 안 될까
어텐션(Attention)은 U자 형태라 모델이 앞부분이랑 뒷부분은 잘 보는데 중간은 다 까먹거든. 윈도우를 키운다는 건 그냥 무시당하는 중간 영역만 더 넓어진다는 뜻이야. 내가 본 어떤 팀은 토큰 예산의 60% 이상을 매 턴마다 똑같은 내용을 다시 집어넣는 데 쓰고 있더라고. 뭐가 필요한지 판단하는 놈이 아무도 없으니까.
압축의 함정
뻔한 해결책은 기록이 쌓일 때마다 압축하는 건데, 무작정 요약만 하면 전체적인 줄거리만 남고 세부 정보는 다 날아가 버려. 에이전트가 구체적인 사실을 바탕으로 행동해야 할 때는 이게 정반대 효과를 내거든. 내가 18,282 토큰짜리 대화를 122 토큰으로 압축해 봤는데, 아예 기억이 없는 것보다 더 못하더라. 에이전트는 그럴싸하게 말하는데 정작 내용은 틀린 거 있지.
조용한 실패
어떤 팀은 메모리 계층에 문서가 3,000개 넘게 있고 대시보드에는 메모리 91개가 떠 있는데, API 검색 호출을 하면 죄다 빈 결과만 나오는 거야. 근데 어디가 고장 났는지 알려주는 놈도 없고. 절벽에서 떨어지는 건 눈에라도 보이지, 이건 눈치채기도 힘들어.
내가 Synap에서 이걸 처리하는 방법
매 턴마다 기록을 다시 재생하는 대신, 에이전트가 Synap을 호출해서 토큰 예산 안에 들어오는 우선순위 높은 메모리 세트를 받아오게 했어. 벡터, 그래프, 파일 저장소 전체를 뒤져서 예산만큼 채우고, 토큰 값어치 없는 건 다 잘라버리는 거지. 압축할 때마다 매번 체크해서 사실 정보가 얼마나 살아남았는지 알려주니까, 너무 많이 날아갔다 싶으면 압축 강도를 낮춰서 다시 시도하면 돼. 그냥 압축이 잘 됐겠지 하고 기도하는 거랑은 차원이 다르지. 검색은 P75 기준으로 15ms 미만으로 끊기고, 에이전트가 물어보기도 전에 미리 다 끝나 있어서 기다릴 필요도 없어. 실제 운영 환경에서는 토큰 비용을 대략 절반으로 줄여주는데, 진짜 핵심은 에이전트가 다 무너져가는 꽉 찬 윈도우 대신 쓸모 있는 컨텍스트를 가지고 일하게 된다는 거야.
내가 확인해 볼 것들
똑같은 작업으로 5번째 턴이랑 50번째 턴의 정확도를 측정해 봐. 만약 성능이 떨어졌다면 그게 어텐션 절벽 때문인지, 아니면 압축 과정에서 중요한 정보가 날아간 건지 확인해야 해. 밖에서 보면 똑같아 보여도 해결책은 완전히 다르거든.
(추신: 저는 Maximem Synap에서 일합니다. 847건의 실행 데이터는 제가 측정한 게 아니라 r/LocalLLaMA의 한 개발자가 올린 겁니다.)
