백만 토큰의 컨텍스트 창 (context window)을 광고하는 모델은 자신이 무엇을 수용할 수 있는지에 대한 주장을 하는 것이지, 실제로 무엇을 사용할 수 있는지에 대해 말하는 것이 아닙니다. 긴 컨텍스트 (long-context) 벤치마크는 그 격차를 측정하기 위해 존재하며, 특정 사실을 찾을 수 있는지 테스트하는 것과 전체 컨텍스트에 대해 추론할 수 있는지 테스트하는 것으로 명확히 나뉩니다. 오직 두 번째 종류만이 사람들이 실제로 '긴 컨텍스트'라고 의미하는 바를 측정합니다.

이 벤치마크들이 답하는 질문

"긴 컨텍스트를 처리한다"는 능력 안에는 분리 가능한 세 가지 역량이 있으며, 벤치마크는 보통 그중 하나를 테스트합니다.

모델은 동일한 길이에서 첫 번째 역량은 뛰어날 수 있지만 세 번째 역량은 부족할 수 있습니다. 이는 모순이 아니라 서로 다른 작업이기 때문입니다. 또한 128k에서 완벽한 니들 검색 (needle retrieval)을 보여주는 차트가 128k 문서의 요약 (summarising) 능력에 대해서는 거의 알려주는 바가 없는 이유이기도 합니다.

건초더미 속의 바늘 (Needle in a haystack), 그리고 그 한계

2023년 Greg Kamradt에 의해 대중화된 니들 테스트 (needle test)는 오후 한때면 작성할 수 있을 정도로 충분히 간단하며, 바로 그 점 때문에 널리 퍼졌습니다. 길이 L의 채우기 텍스트 (filler text)를 준비합니다. 상대적 깊이 d에 하나의 독특한 문장을 삽입합니다. 그 문장이 답이 되는 질문을 던집니다. L과 d를 훑으며 통과 또는 실패의 히트맵 (heatmap)을 그립니다.

for length in [4_000, 8_000, 16_000, 32_000, 64_000, 128_000]:
    for depth in [0.0, 0.1, 0.25, 0.5, 0.75, 0.9, 1.0]:
        haystack = filler_of_exactly(length)
...

이것은 진정으로 유용한 스모크 테스트 (smoke test)이지만, 그것이 증명할 수 있는 것에는 명확한 한계가 있습니다.

• 단 하나의 바늘(One needle)은 난이도의 하한선입니다. 정답이 문맥 내에 토씨 하나 틀리지 않고 그대로 존재하며, 그 외의 어떤 것도 정답과 유사하지 않은 상태입니다. 이 경우 어텐션(Attention) 메커니즘은 찾기 쉬운 목표를 갖게 됩니다. 여러 사실을 결합해야 하거나, 여러 유사한 사실 중 하나를 찾아야 하는 멀티 니들(Multi-needle) 변형 방식은 훨씬 더 어려우며, RULER는 바로 이 점을 일반화합니다.
• 채우기 텍스트(Filler)는 방해 텍스트(Distractor text)가 아닙니다. 만약 건초더미가 에세이이고 바늘이 샌드위치에 관한 것이라면, 바늘은 의미론적으로 고립되어 있습니다. 실제 문서에는 관련 있어 보이는 구절이 많이 포함되어 있습니다. 바늘과 동일한 도메인에서 추출한 채우기 텍스트를 사용하면 테스트 난이도가 몇 배로 높아지지만, 대부분의 공개된 니들 차트(needle charts)는 그렇게 하지 않습니다.
• 합격 또는 불합격 판정은 성능 저하를 숨깁니다. 이진 판정(Binary judgement) 방식으로는 바늘은 찾아냈지만 세부 사항을 엉망으로 만드는 모델의 상태를 보여줄 수 없으며, 이것이 실제 발생하는 흔한 실패 유형입니다.
• 최적화(Optimised)의 대상이 되었습니다. 이 테스트는 매우 유명하며, 그 패턴은 학습하기 쉽습니다. 완벽한 니들 성능은 이제 기본 요건(Table stakes)에 가까워졌으며, 그에 따라 정보 가치도 낮아졌습니다.

RULER 및 유효 컨텍스트 길이 (Effective context length)

2024년 NVIDIA 연구진이 발표한 RULER는 이를 체계화한 버전입니다. RULER는 단일 합성 작업 대신 4가지 카테고리에 걸친 일련의 작업군을 정의하며, 이들은 모두 절차적으로 생성됩니다. 따라서 길이를 임의의 값으로 설정할 수 있고 실행할 때마다 항목이 새로워지며, 이는 부수적으로 데이터 오염(Contamination)을 구조적으로 불가능하게 만듭니다.

RULER의 핵심적인 기여는 '유효 (effective)' 컨텍스트 길이(context length)라는 개념입니다. 이는 모델이 짧은 길이에서의 참조 모델(reference model) 성능으로 정의된 임계값을 여전히 통과할 수 있는 가장 긴 길이를 의미합니다. RULER를 널리 알린 발견은 개별 모델에 대한 것이라기보다 카테고리 차원의 발견이며, 이는 여전히 유효합니다. 매우 큰 윈도우(window)를 광고하는 많은 모델이 광고된 수치의 아주 일부 수준에서 임계값 아래로 떨어지며, 집계(aggregation) 작업의 경우 성능 저하가 완만하게 일어나지 않습니다.

광고된 길이와 유효한 길이 사이의 이러한 차이점은 effective context length versus advertised context length에서 상세히 다루어지며, 위치(positional) 측면의 문제는 lost in the middle에서 다루어집니다.

LongBench 및 실제 작업 (real tasks)

RULER는 설계상 합성(synthetic) 방식입니다. 즉, 정밀하고 제어 가능하지만 실제로 수행하는 작업과는 다릅니다. LongBench (Tsinghua, 2023)는 다른 경로를 택하여, 영어와 중국어로 구성된 실제 작업들을 대량으로 모았습니다. 여기에는 단일 문서 및 다중 문서 질의응답 (question answering), 요약 (summarisation), 퓨샷 학습 (few-shot learning), 코드 완성 (code completion), 그리고 일부 합성 작업들이 포함되며, 각 작업은 고유의 관습적인 지표 (conventional metric)를 가집니다.

수치를 읽을 때 두 가지 구성 세부 사항이 중요합니다. 첫째, 지표는 작업별(per-task)로 산출되며 대부분 중첩 기반(overlap-based)입니다 (추출형 QA의 경우 F1, 요약의 경우 ROUGE). 이는 해당 측정 방식들이 가진 알려진 모든 약점을 그대로 물려받습니다 — ROUGE와 BLEU가 실제로 무엇을 측정하는지를 참조하세요. 둘째, LongBench는 컨텍스트 윈도우(window)가 항목보다 짧은 모델들을 위해 절단(truncation) 규칙을 정의합니다: 중간을 잘라내고 앞부분(head)과 뒷부분(tail)을 유지하는 방식입니다. 이는 합리적인 기본 설정이며, 윈도우가 짧은 모델도 0이 아닌 점수를 얻게 된다는 것을 의미합니다. 이는 절단율(truncation rates)이 보고되지 않는 한, 고정된 길이에서의 모델 간 비교를 미묘하게 불공정하게 만듭니다.

두 번째 버전은 전문가의 인간 기준선(human baselines)과 함께 매우 넓은 길이 범위에 걸쳐 객관식(multiple-choice) 형식으로 전환되었으며, 이는 모호하지 않은 채점(unambiguous grading)을 위해 현실성을 일부 희생한 것입니다. 이 장르의 다른 항목들 — 검색 스타일(retrieval-style) 작업 위주로 구축된 긴 컨텍스트 스위트(long-context suites)나 극단적인 길이까지 밀어붙이는 것들 — 도 유사한 절충을 합니다. 비교하기 전에 버전을 확인하십시오.

위치는 변수이며, 반드시 전수 조사(swept)되어야 합니다

긴 컨텍스트 평가에 관한 가장 중요한 단일 방법론적 지점은 다음과 같습니다: 만약 관련 정보를 특정 위치에 배치한다면, 당신은 그 위치를 측정한 것입니다.

깊이(depth)의 함수로서의 정확도는 일반적으로 U자형을 띱니다 — 시작 부분에서 강하고, 끝 부분에서 강하며, 중간 부분에서 가장 약합니다. 정답을 맨 위에 두는 테스트는, 정답이 40% 깊이에 있는 문서와는 아무런 관련이 없는 수치를 보고하는 것입니다. 깊이 전수 조사(depth sweep)가 없는 모든 긴 컨텍스트 결과는 표의 단 하나의 셀(cell)을 보고하면서 그것을 표 전체라고 부르는 것과 같습니다.

긴 컨텍스트 테스트를 위한 최소한의 정직한 설계:

  lengths   x  depths   x  repeats
...

평균 깊이(mean-depth) 대신 최악의 깊이(worst-depth)를 보고하는 것은, HELM이 최악의 경우의 강건성(worst-case robustness)에 대해 주장하는 것과 동일한 논리입니다: 사용자는 문서의 어느 위치에 정답이 있을지 선택할 수 없기 때문입니다.

자신만의 긴 컨텍스트 테스트 설계하기

공개된 긴 컨텍스트 (Long-context) 벤치마크는 판결문(verdicts)보다는 템플릿으로서 더 유용합니다. 왜냐하면 당신이 알아야 할 핵심은 당신의 문서가 컨텍스트 창(window) 내에서 살아남느냐 하는 것이며, 문서 구조는 매우 다양하기 때문입니다. 계약서, 채팅 로그, 코드베이스(codebases), 전사 데이터(transcripts)는 각각 서로 다른 방식으로 성능이 저하됩니다.

1. 당신이 중요하게 생각하는 길이의 실제 문서 20개를 준비하세요. 채우기용 데이터(filler)가 아닌, 당신만의 포맷, 상용구(boilerplate), 반복 문구가 포함된 실제 문서여야 합니다.
2. 문서당 세 개의 질문을 작성하세요: 하나는 검색 (retrieval, 한 곳에 명시된 사실), 하나는 추적 (tracking, 떨어진 두 곳의 정보를 결합해야 함), 하나는 집계 (aggregation, 문서 전체를 필요로 함)입니다.
3. 검색 및 추적 질문의 경우, 관련 구절을 최소 세 가지 이상의 깊이(depth)로 재배치하여 변형을 만드세요. 이것은 모두가 건너뛰는 단계이지만, 바로 여기서 유의미한 결과가 나옵니다.
4. 가능한 경우 정확하거나 거의 정확한 규칙으로 채점하세요. 집계 질문에 대해서만 판사(judge) 모델에 의존하되, 판사의 채점 샘플을 직접 읽어보세요 — 판사 모델도 고유의 편향(biases)을 가집니다.
5. 질문 유형별, 깊이별 정확도를 보고하세요. 단일 수치만 제시하면 가장 흥미로운 결과, 즉 집계(aggregation) 성능이 검색(retrieval) 성능보다 훨씬 일찍 무너진다는 사실을 숨기게 됩니다.

깊이 스윕(depth sweep)은 매우 많은 요청을 필요로 합니다. 위의 그리드는 모델당 126회의 호출을 의미하며, 여러 길이에서 4개의 모델을 비교하면 수천 건의 긴 프롬프트(long-prompt) 요청이 발생하여 비용이 크게 발생합니다. 요청당 토큰 수와 비용을 보고하는 하나의 API를 통해 이를 실행하면, 스윕 과정에서 정확도 곡선과 함께 비용 곡선도 생성됩니다. 긴 컨텍스트에서는 비용 곡선이 종종 핵심적인 발견 사항이 됩니다. 품질이 저하되기 훨씬 전부터 입력 토큰(input tokens)이 비용의 대부분을 차지하기 때문입니다.

마지막으로 주의할 점이 하나 있습니다. 긴 컨텍스트 (Long-context) 평가 결과는 다른 결과들보다 더 빠르게 노후화됩니다. 컨텍스트 처리 (context handling) 영역은 아키텍처 (architectures)가 가장 빠르게 변화하고 있는 지점이기 때문입니다. 특정 모델 제품군에 대해 18개월 전에 나온 결과는 증거가 아니라 과거의 기록일 뿐입니다. 다시 실행하십시오. 위에 제시된 테스트 프레임워크 (harness)는 하루 정도의 작업 분량이며, 이는 누군가의 합성 데이터 건초더미 (synthetic haystack)가 아닌 여러분의 문서에 대한 해답을 제공할 것입니다.

관련 항목

• BIG-bench, BBH 및 어려운 하위 집합 (Hard Subsets)
• MMLU: 무엇을 테스트하며 점수가 의미하는 바는 무엇인가
• 공개 벤치마크 (Public Benchmark) 직접 실행하기