광고된 Window vs Effective Window

박스의 숫자는 ceiling일 뿐

모형이 1M token 받을 수 있어도, 모든 token에 같은 fidelity로 reasoning한다는 뜻은 아니야. 광고된 window는 API 한도, effective window는 모형이 *아빠* task에 정보를 안정적으로 쓸 수 있는 범위.

NIAH가 misleading한 이유

고전 NIAH(needle in a haystack) 테스트는 긴 문서에 한 문장('the secret code is 42') 끼우고 retrieve 시킨다. 현대 flagship 모형은 1M token에서 95%+ 점수. 근데 그게 retrieval task지 reasoning이 아니야. 한 문장 verbatim 끌어오는 건 흩어진 사실 여러 개 합치는 것보다 훨씬 쉽지.

더 어려운 benchmark가 보여주는 것

RULER는 multi-needle, variable-tracking, aggregation을 긴 input에 걸쳐 테스트 — 대부분 flagship 모형이 128K에서 50% 아래로. NoCha(Novel Challenge)는 책 길이 텍스트의 narrative reasoning, 점수 64K 넘으면 평탄/감소. LongBench v2 mixed reasoning은 effective context가 광고의 30-50% 정도.

실제 워크로드를 평가해

task가 legal cross-reference, codebase refactor, long-session agent work면 그 task 직접 테스트해. 질문은 'needle 찾을 수 있나?' 가 아니라 '전체 일을 가로질러 intent 보존하나?' 야.

큰 context window는 ceiling이지 균일한 reasoning quality 보장이 아니야. 광고된 숫자는 마케팅, effective 숫자는 엔지니어링으로 다뤄.

Code

workload별 eval scaffold·yaml

effective_context_test:
  task: "multi-hop code review"
  lengths: [32_000, 64_000, 128_000, 256_000]
  measure:
    - cites_required_files
    - preserves_constraints
    - avoids_stale_assumptions
    - finishes_within_output_budget
  baseline: "single-file review at 8K"
  fail_threshold: "effective accuracy < 60% of baseline"

감 잡는 법칙·text

Advertised window = ceiling for *what fits*
Effective window  = roughly 30-50% of advertised for *reasoning*
                  = closer to 80-95% of advertised for pure *retrieval*

Use evals on YOUR task, not provider marketing.

광고된 Window vs Effective Window

박스의 숫자는 ceiling일 뿐

NIAH가 misleading한 이유

더 어려운 benchmark가 보여주는 것

실제 워크로드를 평가해

Code

External links

Exercise

Progress

댓글 0