큰 컨텍스트 윈도우는 용량 한계일 뿐, 검색 전략이 아니다. 모델이 수십만 토큰을 받아들인다는 사실이 그것을 고르게 주의를 기울여 읽는다는 뜻은 아니며, 그만큼을 돈을 내고 보내야 한다는 뜻은 더더욱 아니다. 위치와 길이를 측정한 롱 컨텍스트 벤치마크는 하나같이 같은 말을 한다. 입력이 커질수록 정확도는 떨어지고, 프롬프트 중간에 묻힌 근거는 가장 적게 쓰인다.

새겨야 할 재구성은 이것이다. 컨텍스트 윈도우는 조회하는 데이터베이스가 아니라 써버리는 예산이다. 이를 저장소로 취급하는 팀은 자신이 건너뛴 검색 파이프라인보다 느리고 비싸고 부정확한 시스템을 만들게 된다.

두 가지 실패 양상은 서로 다르다

이 둘은 자주 뒤섞이지만 해결책이 다르다.

  • 위치 저하. Liu et al. (2023)이 밝힌 lost-in-the-middle 효과다. 관련 구간이 입력의 맨 앞이나 맨 뒤에 있을 때 정확도가 가장 높고 중간으로 갈수록 처지면서 U자 곡선을 그린다. 같은 사실을 가장자리에서 중앙으로 옮기기만 해도, 다른 조건이 그대로여도 답의 질은 떨어진다.
  • 길이 저하. 근거가 고정돼 있고 좋은 위치에 있어도 입력이 커지면 정확도는 떨어진다. RULER(Hsieh et al., 2024) 같은 후속 연구는 여러 개의 바늘을 찾고 컨텍스트 전반에 걸쳐 추론해야 하는 과제로 롱 컨텍스트 모델을 시험했고, 실질적으로 쓸 수 있는 컨텍스트 길이가 광고된 숫자보다 일관되게 짧다는 것을 확인했다.

위치 저하는 순서를 바꿔 어느 정도 우회할 수 있다. 길이 저하는 그럴 수 없다. 문제 자체가 건초더미의 크기이기 때문이다. 해결책은 넣는 양을 줄이는 것뿐이다.

벤치마크 숫자가 오해를 부르는 이유

needle-in-a-haystack 테스트가 인기를 끈 이유는 실행하기 쉽고 통과하기 쉬웠기 때문이다. 긴 문서 곳곳에 이질적인 문장 하나를 숨겨두고 모델에게 그대로 되풀이하라고 시킨 뒤 초록색 격자를 그린다. 모델은 이 테스트에서 거의 만점을 받으면서도 실제로 필요한 일은 해내지 못할 수 있다. 진짜 질문은 단순한 어휘 검색이 아니기 때문이다.

사용자가 묻는 것은 코퍼스 전반에 흩어진 서로 관련된 네 가지 사실을 찾아내고, 그중 둘이 충돌한다는 것을 알아채고, 나머지에 대해 추론하는 일이다. RULER가 측정하는 것이 바로 이 과제이며, 광고된 윈도우와 실제로 쓸 수 있는 윈도우가 벌어지는 지점도 여기다. 단일 바늘 재현율은 스모크 테스트로만 취급하고, 윈도우가 제대로 작동한다는 증거로 삼지 말아야 한다.

비용 문제는 애매하지 않다

검색 성능 저하는 논쟁의 여지가 있다. 청구서는 아니다. 입력 토큰은 호출마다 과금되므로, 매 요청에 20만 토큰의 컨텍스트를 밀어 넣는 설계는 답에 열두 개의 토큰이 필요했든 하나도 필요 없었든 20만 토큰 전부에 대해 매번 값을 치른다.

# Stuff-the-window: whole handbook, every turn
200,000 input tokens x 50,000 calls/month = 10,000,000,000 tokens

# Retrieve-then-answer: system prompt + 6 chunks
  3,000 input tokens x 50,000 calls/month =    150,000,000 tokens

입력 항목만 놓고 봐도 66배 차이다. 지연 시간을 세기도 전에 이 정도다. 첫 토큰까지 걸리는 시간은 모델이 읽어야 하는 양에 비례해 늘어나므로, 잔뜩 채운 프롬프트는 느리기까지 하다. 더 나쁜 답을 더 늦게 받으면서 더 비싼 값을 치르는 셈이다. 이 방식이 이기는 축은 하나도 없다.

프롬프트 캐싱은 딱 한 가지 경우에서만 이 셈법을 복잡하게 만든다. 호출마다 반복되는, 진짜로 안정적인 프리픽스라면 크게 할인된 값으로 읽을 수 있다. 이건 실제로 유효하고 활용할 가치도 있다. 하지만 이것이 구제하는 건 고정된 서두의 비용이지, 부풀려진 건초더미의 재현율이 아니다. 캐시된 나쁜 프롬프트는 그저 더 저렴한 나쁜 프롬프트일 뿐이다.

대신 해야 할 일

이 원칙은 화려하지 않지만 효과가 있다.

  • 검색한 뒤 답하라. 모델 앞에 검색 단계를 두고 상위 몇 개 청크만 전달하라. Bedrock Knowledge Base는 인덱스를 직접 소유하지 않고도 이 일을 해준다. 좋은 청크 여섯 개가 그저 그런 청크 육백 개보다 항상 낫다.
  • 순위를 매기되 진심으로 매겨라. 청크 열 개를 전달한다면 순서가 중요하다. 위치가 중요하기 때문이다. 가장 강력한 근거는 맨 위에, 그다음으로 강력한 근거는 맨 아래에 두어라. 주의가 가장 잘 닿는 자리들이다. 중간은 핵심 사실이 아니라 부차적인 자료로 채워라.
  • 한 단계가 볼 수 있는 양에 상한을 둬라. 호출당 강제된 토큰 상한은 검색 계층이 선별적으로 움직이게 만든다. 상한이 없으면 컨텍스트는 무언가 터질 때까지 계속 커지고, 대개 최악의 순간에 터진다.
  • 안정적인 프리픽스만 캐시하고, 가변적인 본문은 캐시하지 마라. 시스템 프롬프트와 도구 스키마는 매 호출마다 동일하므로 캐시에 넣을 대상이다. 검색된 근거는 질문마다 달라지므로 그렇지 않다.
  • 자신의 질문으로 재현율을 측정하라. 실제 코퍼스에 실제 쿼리를 돌려보고 답을 채점하라. 벤더가 내세우는 컨텍스트 길이는 마케팅용 숫자이고, 자신의 시스템을 설명하는 것은 자신이 만든 평가뿐이다.

큰 윈도우가 정답일 때

윈도우를 채우는 것이 옳은 경우도 있고, 원칙적으로 거부하는 것 자체가 실수가 되는 경우도 있다. 문서 하나를 처음부터 끝까지 요약하려면 문서 전체가 필요하다. 모든 내용이 관련 있으니 검색할 것이 없다. 코드베이스나 계약서 전체를 한눈에 담아야 하는 추론도 진짜로 그 범위를 필요로 한다. 검색 파이프라인을 설계하는 비용이 그냥 토큰을 쓰는 비용보다 큰 일회성 분석이라면, 의도적으로 게을러도 괜찮은 지점이다.

기준은 이것이다. 중요한 부분집합을 구체적으로 짚어낼 수 있는가. 그렇다면 그것만 검색하라. 정말로 짚어낼 수 없다면, 즉 과제가 코퍼스의 일부가 아니라 전체에 걸쳐 있다면, 그때는 윈도우가 실제로 제 몫을 하는 것이니 그대로 활용하면 된다.

요약

더 큰 컨텍스트 윈도우는 실제로 대단한 엔지니어링 성과이며 앞으로도 계속 커질 것이다. 동시에 검색 단계를 작성하지 않으려고 쓸 수 있는 가장 비싼 방법이기도 하다. 재현율은 길이와 위치 모두에서 떨어지고, 청구서는 보내는 모든 토큰에 비례해 늘어나며, 지연 시간은 프롬프트 크기를 따라간다. 모델이 봐야 할 것이 무엇인지 정하고, 그것만 보내고, 용량을 역량으로 착각하는 일을 그만두어야 한다.

이어서 읽으면 좋은 글

대규모로 검색을 운영하는 인프라 쪽 이야기는 ercan.cloud의 클라우드/플랫폼 필드 노트에 있고, 허브는 ercanermis.com이다.