광고된 Window vs Effective Window

상자에 적힌 숫자는 천장일 뿐

모형이 1M token을 받을 수 있다고 해서, 그 token 전부를 같은 정확도로 따져본다는 뜻은 아니야. 광고된 window는 API가 허용하는 한도고, 실제로 쓰이는 window는 모형이 네 일에 그 정보를 안정적으로 써먹을 수 있는 범위지.

NIAH가 사람 헷갈리게 하는 이유

고전적인 NIAH(needle in a haystack) 테스트는 긴 문서 안에 문장 하나('the secret code is 42')를 끼워놓고 그걸 찾아오게 시켜. 요즘 주력 모형은 1M token에서도 95%를 넘겨. 근데 그건 retrieval 과제지 추론 과제가 아니야. 문장 하나를 그대로 끌어오는 건, 여기저기 흩어진 사실 여러 개를 합치는 것보다 훨씬 쉽거든.

더 어려운 benchmark가 하는 말

RULER는 바늘을 여러 개 심고, 변수를 따라가게 하고, 흩어진 걸 합치게 해 — 긴 input 전체에 걸쳐서. 주력 모형 대부분이 128K에서 50% 밑으로 떨어져. NoCha(Novel Challenge)는 책 한 권 길이 글을 놓고 줄거리를 따져 묻는데, 64K를 넘어가면 점수가 눕거나 내려가. LongBench v2로 섞어서 재보면 실제로 쓰이는 context는 광고된 값의 30-50% 정도야.

네 일로 직접 재봐

하려는 게 법령 상호 참조든, 코드베이스 리팩터링이든, 오래 도는 agent 작업이든 — 그 일 자체로 테스트해. 물어야 할 건 "바늘을 찾아내나?"가 아니라 "일 전체를 가로지르는 동안 의도를 붙들고 있나?"야.

큰 context window는 천장이지, 어디서나 똑같이 잘 생각한다는 보장이 아니야. 광고된 숫자는 마케팅으로 보고, 실제로 쓰이는 숫자는 공학으로 다뤄.

Code

일 종류별 평가 뼈대·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.

Exercise

관심 있는 워크플로에 맞는 테스트를 하나 설계해봐. 문장 하나 찾아오기보다 어렵게 — 떨어져 있는 사실을 둘 이상 합쳐야 답이 나오게.

Hint

네가 실제로 겪은 실패 패턴을 골라. 겪은 게 없으면 긴 session을 일부러 돌려보고 뭐가 빠지는지 봐.

상자에 적힌 숫자는 천장일 뿐

NIAH가 사람 헷갈리게 하는 이유

더 어려운 benchmark가 하는 말

네 일로 직접 재봐

Code

External links

Exercise

Progress

댓글 0