HELMET 소개: 장기 컨텍스트 언어 모델의 포괄적 평가

논문: https://arxiv.org/abs/2410.02694

웹사이트: https://princeton-nlp.github.io/HELMET

코드 및 데이터: https://github.com/princeton-nlp/HELMET

우리가 지난 10 월에 HELMET 을 처음 공개한 이후, 장기 컨텍스트 언어 모델 (Long-context Language Models) 에 대한 개발은 이전보다 훨씬 더 활발해졌으며, 헬멧의 채택을 매우 기쁘게 생각합니다. 예를 들어 Microsoft 의 Phi-4 와 AI21 의 Jamba 1.6 과 같은 커뮤니티의 사례를 들 수 있습니다. 초기 공개 이후, 우리는 평가 세트에 더 많은 모델을 추가하고 추가 분석을 수행했습니다. 우리는 새로운 결과를 공유하고 ICLR 2025 에서 HELMET 을 발표하는 데 매우 기대합니다.

이 블로그에서는 HELMET 의 구성, 주요 발견사항, 그리고 연구자와 응용 분야에서 다양한 장기 컨텍스트 언어 모델 (LCLMs) 을 구별할 수 있도록 전문가들이 HELMET 를 사용하는 방법을 설명하겠습니다. 마지막으로, HuggingFace 와 함께 HELMET 를 사용하는 빠른 시작 가이드를 결론으로 제시하겠습니다.

요약 문서 여러 개부터 새로운 작업을 실시간으로 학습하기까지, 장기 컨텍스트 언어 모델 (LCLMs) 은 우리가 언어 모델을 사용하고 상호작용하는 방식을 변화시킬 수 있는 막대한 잠재력을 가지고 있습니다. 언어 모델은 컨텍스트 윈도우가 약 2K 에서 8K 토큰 (예: ChatGPT, Llama-2/3) 으로 제한되어 왔습니다. 최근에는 모델 개발자들이 자신의 모델의 컨텍스트 윈도우를 지속적으로 증가시키고 있으며, 최근 모델들인 GPT-4o, Claude-3, Gemini-1.5 는 수백만 토큰까지 지원하는 컨텍스트 윈도우를 지원합니다.

그러나 더 긴 컨텍스트 윈도우가 있는 경우, 이전 자연어 벤치마크 (예: Scrolls) 는 LCLMs 를 평가하는 데 더 이상 적합하지 않습니다.
결과적으로, perplexity 와 합성 작업 (예: needle-in-a-haystack) 은 최근 LCLMs 의 가장 인기 있는 평가 지표로 등장했지만, 종종 실제 세계의 성능을 반영하지 않습니다.
모델 개발자는 또한 임의의 데이터셋에서 평가할 수 있으며, 이는 모델 비교를 복잡하게 만듭니다.
또한, 기존 LCLMs 벤치마크는 혼란스럽고 직관적이지 않은 결과를 보여줄 수 있어 서로 다른 모델의 강점과 약점을 이해하는 것이 어렵습니다 (Figure 1).

이 작업에서 우리는 HELMET (How to Evaluate Long-Context Models Effectively and Thoroughly) 을 제안합니다. 이는 기존 벤치마크를 여러 가지 방식으로 개선한 장기 컨텍스트 언어 모델을 평가하기 위한 포괄적인 벤치마크입니다—다양성, 통제 가능성, 신뢰성.
우리는 59 개의 최근 LCLMs 를 평가하고, 다양한 응용 분야에서 모델을 평가하는 것이 그들의 능력을 이해하고 프론티어 LCLMs 는 여전히 복잡한 작업에 제한되어 있다는 것을 발견했습니다.

산업계와 오픈 소스 커뮤니티 모두에서 LCLMs 의 발전으로 인해 이러한 모델을 평가하고 비교할 수 있는 신뢰할 수 있는 방법을 갖는 것이 중요합니다. 그러나 현재 모델들은 다른 벤치마크에서 종종 평가됩니다 (Table 1).

장기 컨텍스트 언어 모델을 평가하는 일반적인 관행은 perplexity 나 합성 작업을 사용하는 것입니다, 예를 들어 needle-in-a-haystack (NIAH). 그러나 최근 연구들은 perplexity 가 다운스트림 성능과 잘 상관관계가 없음을 보여줍니다 (Fang et al., 2024). Figure 2 에서 우리는 합성 작업인 NIAH 가 실제 세계의 성능과 상관관계가 없음을 보여주지만, 더 복잡한 합성 작업은 실제 세계의 작업과 더 높은 상관관계를 달성함을 보입니다.

실제적인 응용을 가진 기존 벤치마크들 (예: ZeroScrolls (Shaman et al., 2023), LongBench (Bai et al., 2024), InfiniteBench (Zhang et al., 2024)) 중에도 여전히 중요한 제한사항이 있습니다:

다운스트림 작업의 불충분한 커버리지: 특정 도메인에 주로 집중됨

프론티어 LCLM(장문맥 대형 언어 모델) 테스트를 위한 부적절한 길이: 오래된 QA 데이터셋은 종종 <32K 토큰으로 제한됨 (예: QASPER, QuALITY)

신뢰할 수 없는 지표: N-gram 매칭 지표인 ROUGE는 노이즈가 많으며 인간 판단과 상관관계가 없으며 (Goyal et al., 2023) 모델 간 구별이 불가능함

기저 모델과의 호환성 부재: 인스트럭션 튜닝을 필요로 함, 이는 기저 모델 개발에 사용할 수 없음

따라서 우리는 이러한 한계를 해결하고 LCLM(장문맥 대형 언어 모델) 의 종합 평가를 제공하기 위해 HELMET 를 제안함.

우리는 다음과 같은 요구사항을 고려하여 HELMET 을 설계함:

• 다운스트림 작업의 다양한 커버리지
• 길이와 복잡성의 제어 가능성
• 기저 및 인스트럭션 튜닝 모델에 대한 신뢰할 수 있는 평가

표 2 는 벤치마크 개요를 보여줌. 우리의 실험에서는 토큰 길이를 8K 에서 128K 로 평가하지만, HELMET 은 더 긴 문맥 길이로 쉽게 확장될 수 있음.

• 다양한 커버리지*: HELMET 은 리트리벌-오그mented 제네레이션 (실제 리트리벌 패스저 포함), 인용과 함께 제네레이션, 요약 등 다양한 작업 집합을 포함함. 우리는 실제 응용을 반영하는 자연스럽게 긴 문맥이 있는 데이터셋을 신중하게 선택함. 이러한 데이터셋은 모델 기반 평가와 인간 연구와 같은 신뢰할 수 있는 평가 설정으로 보완됨.

• 제어 가능한 길이와 난이도*: LCLM 을 평가할 때 고려해야 할 중요한 차원은 입력 길이로, 더 긴 입력은 더 많은 정보를 제공하면서도 모델의 노이즈 문맥 처리 능력을 도전을 줄 수 있음. 우리의 작업에서 우리는 리트리벌 패스저 수 (RAG, Cite, Re-rank), 데모스트레이션 수 (ICL), 또는 입력 문서 길이 (LongQA, Summ) 를 변경하여 입력 길이를 제어할 수 있음. LongQA 와 Summ 은 더 긴 문맥으로 쉽게 확장할 수 없으나, 우리는 여전히 프론티어 LCLM 을 평가할 수 있도록 100K 토큰 이상의 자연스러운 문서 길이가 있는 데이터셋을 의도적으로 선택함.

• 신뢰할 수 있는 평가*: 많은 기존 벤치마크는 인간 판단과의 낮은 상관관계 (Goyal et al., 2023) 를 가지고 있음에도 불구하고 ROUGE 와 같은 N-gram 기반 지표를 사용함. 우리는 모델 기반 평가를 사용하여 모델과 다른 입력 길이 간의 더 나은 구별성을 보여줌 (Figure 3). 또한, 우리의 인간 연구는 우리의 지표가 인간 판단과 높은 일치도를 보임.

• 견고한 프롬프팅*: 기존 장문맥 벤치마크는 종종 모델을 인스트럭션에 따르도록 요구하지만, 많은 모델 개발은 기저 모델을 중심으로 이루어지며, 이는 평가에 대해 합성 작업이나 퍼플렉시티에 의존해야 함. 따라서 우리는 우리의 작업의 일부 subset 을 위해 in-context 학습 예제를 통해 기저 모델을 지원함. 이는 기저 모델의 성능을 크게 개선하며, 이는 실제 응용을 더 잘 반영함.

우리의 실험 및 분석은 59 개의 LCLM 의 종합적인 집합을 포함함. 우리의 지식에 따르면, 이는 다양한 응용 프로그램에서 장문맥 모델에 대한 가장 철저하고 통제된 비교임. 이러한 모델은 선도적인 프로프리아리 및 오픈소스 모델을 모두 포함하며, 우리는 또한 다른 아키텍처 (예: 풀-아텐션 트랜스포머, 하이브리드 아키텍처) 와 위치 외삽 기술을 고려함. 이 섹션에서는 우리의 실험에서 몇 가지 주요 발견을 강조할 예정임.

Long-context benchmarks 는 요약이나 질문 답변과 같은 특정 응용 프로그램을 염두에 두고 종종 구성되므로, LCLMs 의 광범위한 맥락 이해를 제한합니다. 우리는 다양한 실제 작업에 대한 모델 성능을 검토하고, 서로 다른 범주가 항상 서로 상관관계를 가지지 않는다는 것을 발견했습니다 (Figure 4).

일부 작업은 검색 기반 특성에 의해 서로 중등도 상관관계를 보입니다 (예: RAG 와 MS-MARCO), 다른 작업은 거의 상관관계를 보이지 않습니다 (예: Summ 과 Cite). 특히 ICL 은 다른 작업과 가장 낮은 상관관계를 가지며, 이는 모델에서 다른 능력을 필요로 하는 고유한 작업임을 시사합니다. 따라서 모델 개발자는 모델의 능력을 더 포괄적인 그림을 그릴 수 있도록 이러한 구분된 축을 통해 평가해야 합니다.

우리는 HELMET 에서 프론티어 프로PRIETARY 모델과 몇 개의 오픈소스 모델의 결과를 제시합니다. 추가 결과는 논문과 웹사이트에서 찾을 수 있습니다.

첫째, 우리는 오픈소스 모델이 복잡한 작업에서 클로즈드 소스 모델을 뒤처짐을 관찰했습니다. 단순한 작업 (예: Recall) 에서 차이는 작지만, 더 복잡한 작업 (예: Cite) 에서 차이는 넓어집니다.

또한, 길이 증가에 따른 성능 저하는 범주 의존적입니다. GPT-4o 와 Gemini 와 같은 가장 발전된 모델조차도 re-ranking 과 같은 작업에서 상당한 성능 감소를 경험합니다. 이 성능 변화는 합성 작업 성능을 단순히 살펴보기로는 관찰할 수 없습니다.

마지막으로, 모든 범주에 걸쳐 명확한 승자가 없음이 있어, 다른 축을 통한 평가가 필요합니다. 추가 분석 (예: 다른 위치 외삽 방법의 성능과 중간에서 잃어버린 현상) 은 논문에서 찾을 수 있습니다.

HELMET 을 사용하는 것은 쉽습니다! 단순히 GitHub 저장소를 복제하고 환경 설정을 완료하면 모든 것이 준비됩니다!

우리는 많은 다양한 모델을 로드하는 방법을 제공하며, 이는 config 파일에서 구성할 수 있습니다:

• HuggingFace 의 transformers 라이브러리를 사용하여 - HuggingFace 의 TGI 를 사용하여 머신에서 모델 엔드포인트를 시작합니다.
• HuggingFace 의 Inference Endpoints 를 사용하여 원격 모델 엔드포인트를 시작합니다.
• vllm 을 사용하여 머신에서 모델 엔드포인트를 시작합니다. 참고: Intel Gaudi 가속기에서 vllm 엔드포인트를 시작할 수 있습니다.
• 모델 제공자의 API 를 사용합니다

우리의 저장소에서 config yamls 만 사용하고 다음 평가를 실행하세요:

python eval.py --config configs/rag.yaml --model_name_or_path <model_name>

배경에서 HuggingFace 의 transformers 라이브러리가 사용되며, 로컬 및 원격 모델이 자동으로 지원됩니다.

먼저 TGI github 의 지침을 따라 모델 엔드포인트를 시작하세요. 그런 다음 config 파일에서 엔드포인트 URL 을 지정합니다. 예를 들어, 다음과 같은 config.yaml 을 가질 수 있습니다:

input_max_length: 131072
datasets: kilt_nq
generation_max_length: 20
...

그런 다음 벤치마크를 실행하기 위해 아래 명령어를 사용하세요:

export LLM_ENPOINT=<your-tgi-endpoint> # 예: "https://10.10.10.1:8080/v1"
python eval.py --config configs/config.yaml --endpoint_url $LLM_ENDPOINT

먼저 여기의 지침을 따라 엔드포인트를 설정하세요. 엔드포인트 URL 과 API 키를 가져오세요. 그런 다음 위의 Option 2 에서 보인 동일한 config yaml 을 사용하고 아래 명령어를 실행하세요.

export LLM_ENPOINT=<your-hf-inference-endpoint> # 예시: "https://XXXX.us-east-1.aws.endpoints.huggingface.cloud/v1"
export API_KEY=<your-hf-api-key>
python eval.py --config configs/config.yaml --endpoint_url $LLM_ENDPOINT --api_key $API_KEY

vllm 를 사용하여 Intel Gaudi2 와 Gaudi3 가속기를 포함한 시스템에서 모델 엔드포인트를 시작할 수 있습니다. Intel Gaudi 가속기에서 HELMET 을 vllm 으로 실행하는 방법에 대한 지침은 여기 참조하세요.

Option 2 의 예제 config.yaml 과 동일한 것을 사용할 수 있지만, 아래 두 줄의 변경 사항만 제외합니다:

model_name_or_path: meta-llama/Llama-3.1-8B-Instruct # 접두사 불필요
use_vllm_serving: true # tgi 대신 vllm 사용

그 다음 벤치마킹을 실행하기 위해 아래 명령어를 사용하세요.

export LLM_ENPOINT=<your-vllm-endpoint>
python eval.py --config configs/config.yaml --endpoint_url $LLM_ENDPOINT

OpenAI, Anthropic, Google, 그리고 TogetherAI 의 API 를 지원합니다. 지침은 우리 리포지토리에 참조하세요.

모델 개발 중 빠른 반복을 위해 Recall 과 RAG 작업을 사용하는 것을 권장합니다. 이 작업들은 빠른 평가와 다른 현실적인 작업과의 상관관계 사이의 좋은 균형을 달성합니다. 다음으로 이러한 평가를 쉽게 실행할 수 있습니다:

python eval.py --config configs/rag.yaml --model_name_or_path <model_name>

LCLMs 를 평가하기 위해 모든 베이스라인을 실행하는 것은 특히 긴 컨텍스트를 고려할 때 계산 및 메모리 비용으로 인해 비싸게 될 수 있습니다. 예를 들어, 70B 모델에서 HELMET 을 모든 길이에 실행하려면 8 * 80GB GPU 가 있는 노드가 수백 개의 GPU 시간 동안 필요하며, 이는 비용이 많이 들 수 있습니다. HELMET 에서 평가함으로써 연구자는 우리의 결과를 참조하여 기존 모델과 직접 모델을 비교할 수 있습니다. 우리는 59 개의 다른 크기와 아키텍처의 모델을 포함합니다. 리더보드는 우리 웹사이트에서 찾을 수 있습니다.

HELMET 은 긴 컨텍스트 언어 모델을 더 포괄적인 평가로 가는 단계이지만, LCLMs 의 여전히 많은 흥미로운 응용 프로그램이 있습니다.
예를 들어, 우리는 최근 LongProc 를 출시했습니다. LongProc 는 장문 생성 및 절차 따르기를 평가하기 위한 벤치마크이며, 이는 수만 개의 토큰을 생성하는 추론 모델을 개발하는 데 필수적입니다.
요약 작업은 긴 출력 (최대 1K 토큰) 을 가지지만, LongProc 는 더 긴 출력을 목표로 합니다. 최대 8K 토큰입니다.
HELMET 과 유사하게, LongProc 는 또한 신뢰할 수 있는 평가 설정과 다양한 작업을 설계했습니다.
우리는 LongProc 를 HELMET 의 평가 스위트에 통합하고 있으며, 이것이 LCLMs 의 장문 작업에 대한 더 포괄적인 평가를 제공할 것을 기대합니다.

우리는 Princeton Language and Intelligence (PLI) 그룹의 Mengzhou Xia, Howard Chen, Xi Ye, Yinghui He, Lucy He, Alexander Wettig, Sadhika Malladi, Adithya Bhaskar, Joie Zhang 및 기타 구성원들의 유용한 피드백을 감사드립니다. 이 작업은 Azure OpenAI 크레딧과 Intel 보조금에 대한 Microsoft Accelerate Foundation Models Research (AFMR) 의 지원으로 감사합니다.

HELMET 이 유용하다고 생각하신다면, 우리 논문을 인용하는 것을 고려해 주세요:

@inproceedings{yen2025helmet,
title={HELMET: How to Evaluate Long-Context Language Models Effectively and Thoroughly},
author={Howard Yen and Tianyu Gao and Minmin Hou and Ke Ding and Daniel Fleischer and Peter Izsak and Moshe Wasserblat and Danqi Chen},
...