컨텍스트 윈도우
context length · context limit
한 줄로
컨텍스트 윈도우는 모델이 한 번의 요청에서 처리할 수 있는 최대 토큰 수다. 시스템 프롬프트, 도구 정의, 대화 이력, 첨부 문서, 그리고 생성되는 출력이 모두 그 안에 들어간다. 윈도우 밖의 것은 모델에게 존재하지 않는다.
컨텍스트 윈도우는 단단한 천장이고, 공유 예산이다. 시스템 지시, 도구 스키마, 지금까지의 대화, 검색된 대목, 첨부 파일, 그리고 생성 중인 답이 모두 같은 자리를 두고 다툰다.
마지막 항목에서 사람들이 걸린다. 아주 긴 입력은 긴 답변을 위한 자리를 남기지 않고, 그래서 뚜렷한 이유 없이 문장 중간에 끊긴 출력이 나온다.
긴 컨텍스트는 고르게 나빠지지도 않는다. 관련 연구는 U자 형태의 정확도 곡선을 발견했다. 긴 입력의 처음과 끝에 있는 사실이 중간에 있는 사실보다 훨씬 잘 회수된다. 실무 규칙이 곧바로 따라온다 — 지시는 앞에, 지금의 질문은 뒤에, 그리고 채우지 말 것.
비용도 같은 예산을 따른다. 대부분의 채팅 API 는 매 턴 대화 전체를 다시 보내므로, 긴 스레드는 메시지 수가 시사하는 것보다 빨리 비싸진다. 프롬프트 캐싱이 바뀌지 않는 앞부분의 값을 깎아주지만, 요청 사이에 그 앞부분이 바이트 단위로 같을 때만 걸린다.
한도에 닿았을 때의 통상적 해법은 더 큰 윈도우가 아니라 검색이다. 질문과 관계있는 몇 대목만 가져와 보내는 것이다.
자주 묻는 질문
- 윈도우가 크면 답이 좋아지는가?
- 자동으로 그렇지는 않다. 긴 입력에서는 앞과 뒤에 놓인 정보를 중간보다 잘 회수하므로, 양보다 관련성이 중요하다.
- 대화가 윈도우를 넘으면?
- 애플리케이션이 오래된 턴을 버리거나 요약하거나 외부로 옮겨야 한다. 모델은 윈도우 밖을 볼 수 없고, 무언가 잘려 나갔다고 알려주지도 않는다.