Abstract

최근 LM들은 긴 contexts를 input으로 받을 수 있기는 하지만, 그것을 얼마나 잘 활용하는지에 대해서는 잘 알고 있지 않다.

우리의 input text 내에 관련된 정보가 있는 2가지 task에 대해 성능을 분석함.

• multidocument question answering
• key-value retrieval
  
  

관련 정보가 input context의 시작 또는 끝에 있는 것이 성능 🔺

중간에 있는 정보에 접근해야 할 경우 성능🔻

긴 context를 다루는 모델에서도 입력 context가 길어질수록 성능 🔻

💡 논문에서 하고자 하는 일

• LM이 input context를 어떻게 활용하는 지에 대한 더 나은 이해 제공
• long context model을 평가하기 위한 새로운 평가 프로토콜 제공

Introduction

LM은 일반적으로 Transformer로 구현 (입력 시퀀스의 길이에 따라 self-attention complexity가 제곱으로 증가 → 긴 시퀀스 처리 불가능)

하드웨어 개선 및 알고리즘 발전 → larger context windows 가능 & downstream task를 어떻게 할지에 대한 문제가 남아있음

experiment

💡multidocument question answering

모델이 제공된 문서를 기반으로 추론하고 관련 정보를 찾아 주어진 질문에 답하는 task

input context size와 관련된 정보의 위치를 변경하며 모델 성능 평가

• input context에 더 많은 문서를 추가하여 input context length 증가시킴
• 관련된 정보의 위치를 context의 처음, 중간, 끝으로 변경해가면서 배치

위치 정보를 변화시켰을 때의 성능 그래프

관련 정보가 context의 처음과 끝에 있을 때 성능이 올라가고, input context의 중간에 있는 정보에 접근해야 할 경우, 성능이 크게 저하됨. (문서 없이 예측하는 것보다 성능이 낮아짐)

• extended-context model이라고 해서 input context를 더 잘 활용하는 것은 아님.

(context가 길어질 수록 성능이 점차 낮아짐)

🤔 Given that language models struggle to retrieve and use relevant information in the multi-document question answering task, to what extent can language models even retrieve from their input contexts❓

✔️ input context에서 retrieve matching token을 최소한의 basic ability로 testbed 설계함.
✔️ JSON-formatted key-value pairs을 받고 특정 키의 연결된 값을 반환

❓ 왜 context 중간에 관련 정보가 있으면 정보에 접근하는 데 어려움이 생길까?

1️⃣ 모델 구조의 역할 (decoder-only vs encoder-decoder)

encoder-decoder 모델이 training time sequence length 내에서 평가될 때 input context 내에 관련 정보의 위치 변화에 대해서는 robust함. 그러나 training 때 본 길이보다 긴 시퀀스가 주어지면 평가될 때 U자형 곡선을 보임.
2️⃣ query-aware contextualization

query-aware contextualization(쿼리를 문서나 key-value 쌍의 앞이나 뒤에 위치하게 함)은 모델이 e synthetic key-value task를 완벽하게 수행하지만, multi-document QA에 미미함.
3️⃣ instruction fine-tuning

instruction fine-tuning 없이도 input context와 관련된 정보의 위치의 다양함은 U자 곡선을 보임.

✔️ 추론 ↔ 정보 추가 (trade off 관계)

✔️ 정보의 양이 일정한 수준에 도달하면 결과가 더 이상 크게 변화하지 않음

Language Models

대부분의 LM은 Transformer의 구조로 구현되어있음.

• input contexts가 self-attention으로 인코딩 되어있어 시간과 메모리 복잡도가 input의 길이의 제곱적으로 증가함.
• 긴 시퀀스에 적용하기에 한계가 있음.
• 작은 context window를 사용 → 최대 길이를 설정에도 한계

Increasing language model maximum context length.

→ 최근 하드웨어와 알고리즘의 발전으로 maximum context length가 급격히 증가함.

Multi-Document Question Answering

• multi-document QA
• input context의 길이와 관련 정보의 위치를 변경해가면서 성능을 측정함.

Experimental Setup

commercial search & questoin answering app (예: Bing Chat)을 기반으로 한 retrieval-augmented generation setup과 유사함.

model inputs

1️⃣ a question to answer

2️⃣ k documents

k개의 documents가 있고, 1개의 document에만 Question에 대한 정보가 있음.

(K-1)개의 documents에는 Q에 대한 정보 X → “distractor” document

NaturalQuestions 벤치마크에서 데이터 사용 (NaturalQuestions-Open에서 query를 가져와 사용)

1) 정답이 담긴 document 수집

NaturalQuestions 주석에서 답변이 포함된 위키피디아 단락을 사용

2) distractor documents 수집

Contriever 검색 시스템을 사용하여 질문과 관련성이 높은 위키피디아 paragraph 중에서 NaturalQuestions 답변 중 Question에 대한 Answer이 포함되지 않은 것을 k-1개 검색

💡 input context length 조절 → distractive document의 수를 증가 시키거나 감소시킴
관련된 정보의 위치를 조절 → document의 순서를 조절

✔️ accuracy를 primary evaluation metric으로 사용

✔️ 단순히 답을 copy하는 것을 방지하기 위해 처음 생성된 newline을 제거함.

✔️ 생성은 new line character 없이 end-of-sequence 토큰을 사용해서 종료함.

✔️ 관련된 paragraph가 input context의 처음에 위치하거나 random하게 놓였을 때 성능이 어떤 지에 대한 연구가 있는데, 본 논문은 위치를 미세하게 조정한다는 측면에서 다름.

Models

open models.

MPT-30BInstruct와 LongChat-13B (16K)에 대한 실험 내용

• MPT-30BInstruct은 최대 8192토큰의 문맥 길이를 가지며, 초기에는 2,048 token seq로 1조 개의 토큰에 대한 사전 훈련
• LongChat-13B (16K)는 LLaMA-13B를 기반으로 하며, 문맥 창을 16,384 토큰까지 확장하기 위해 rotary positional embedding을 사용했고, 이후 16,384 token seq로 미세 조정

closed models.

• GPT-3.5-Turbo: 최대 4,000 토큰의 문맥 길이를 처리할 수 있는 모델
• GPT-3.5-Turbo (16K): 최대 16,000 토큰의 문맥 길이를 다룰 수 있는 확장된 버전
• Claude-1.3: 최대 8,000 토큰의 문맥 길이를 가지는 모델
• Claude-1.3 (100K): 최대 100,000 토큰의 확장된 문맥 길이를 가지는 버전

Results and Discussion

closed-book 설정: 모델은 입력 문맥에 어떤 문서도 주어지지 않으며, 매개 변수 기반 메모리를 활용하여 올바른 답변을 생성

oracle 설정: 언어 모델에게 답변이 포함된 단일 문서가 주어지며, 이를 사용하여 질문에 답해야 함

💡Model performance is highest when relevant information occurs at the beginning or end of its input context

input context의 처음과 끝 부분에 나타나는 정보를 식별하고 활용하는 데 성능이 좋음

중간 부분에 있는 정보를 사용하려고 할 수록 성능 저하

⇒ downstream task를 수행할 때 전체 context window를 효과적으로 추론 X

⇒ input context의 처음이나 끝에 있는 정보를 사용하는 것이 더 쉬움.

💡Model performance substantially decreases as input contexts grow longer

⇒ input context의 길이가 길어질 수록 성능🔻

💡Extended-context models are not necessarily better at using input context

model과 extende-context model 모두 input context를 처리할 수 있는 경우 성능이 거의 동일함.

⇒ 더 긴 maximum context window를 가진 모델이 context를 더 잘 활용하는 것 X

How Well Can Language Models Retrieve From Input Contexts?

synthetic key-value retrieval task에 대한 연구

Experimental Setup

input

(i) k 개의 키-값 쌍을 가진 문자열로 직렬화된 JSON 객체 (각 키와 값은 고유한 무작위 생성 UUID)

(ii) 언급된 JSON 객체 내에서 특정 키

goal

speicified key와 연결된 value 반환

✔️ 각 JSON 객체는 하나의 관련 키-값 쌍을 포함, k - 1개의 관련 없는 "distractior" 키-값 쌍을 포함

✔️ accuracy 사용

✔️ synthetic key-value retrieval task는 input context에서 일치하는 토큰을 검색하는 것을 testbed로 함.

💡 input context length 조절 → distractor key-value pairs의 수를 증가 시키거나 감소시킴
관련된 정보의 위치를 조절 → 검색할 key의 위치를 조절

Results and Discussion

• synthetic key-value retrieval task는 input context 내에서 정확히 일치되는 것을 확인하는 것만 필요하지만, 모든 모델이 높은 성능을 달성한 것은 X (특히 140개 이상의 키-값 쌍에서 키를 검색할 때 어려움이 있었음)
  
• 키-값 검색 작업에서 완벽한 성능을 보이는 모델은 제외하고 multi document QA에서와 유사한 경향을 보임. → U자 곡선 (key-value pairs가 input context의 중간에 있을 때 성능이 가장 낮음)

Why Do Language Models Struggle To Use Their Entire Input Context?

긴 input context에서 관련 정보가 중간에 위치해있을 때 언어 모델의 성능이 저하됨.

이러한 원인을 더 잘 이해하기 위해 다음의 것들을 실행함.

Effect of Model Architecture

decoder only vs encoder-decoder

사용된 모델:

• Flan-T5-XXL: 512 토큰의 시퀀스로 훈련 (인코더 및 디코더 포함)
• Flan-UL2: 초기에는 512 토큰의 시퀀스로 훈련 / 추가적으로 100,000 단계 동안 1024 토큰의 시퀀스로 사전 훈련 / 그 후 2048 토큰의 인코더 시퀀스와 512 토큰의 디코더 시퀀스로 instruction-tuning

✔️ relative positional embedding 사용

⇒ 2048 토큰까지는 input context내에 관련 정보의 위치를 바꿔도 robust함 (2048 토큰보다 시퀀스가 길어지면 middle에서 다시 성능 저하)

⇒ encoder-decoder 모델은 양방향 인코더로 인해(prior token뿐 아니라 그 후에 있는 token도 참조할 수 있기 때문에) context window를 더 잘 활용할 수 있을 것

Effect of Query-Aware Contextualization

질문이나 키를(즉, 답변할 질문이나 검색할 키) 처리하는 데 있어서 데이터 (즉, 문서나 키-값 쌍) 다음에 질문이 오도록 설정

⇒ decoder 모델은 query token에 attend 할 수 없음 → prior token에만 attend 할 수 있기 때문에

(질문에 대한 프롬프트는 끝에 나옴)

⇒ encoder-decoder 모델이 위치가 변경되어도 더 robust함. (양방향 인코더를 사용하므로)

Effect of Instruction-Tuning

• instruction은 주로 input context의 시작 부분에 위치함 → instruction-tuned LM은 input context의 시작 부분에 더 많은 가중치를 둠.
• MPT-30B와 MPT-30B-Instruct 모두 U자형의 성능 곡선을 나타내는데, 관련 정보가 입력 문맥의 맨 처음이나 맨 끝에 발생할 때 성능이 가장 높음
• instruction이 없는 모델은 최근 토큰들에 편향되어있음. (long-range information에 좋지 않음)
• instruction-formatted data로 프롬프트될 때 언어 모델은 longer-range information 사용 가능

Is More Context Is Always Better? A Case Study With Open-Domain QA

✔️ trade-off

input context length를 증가 → LM에 더 많은 정보 제공 & 모델이 추론해야 하는 content의 양 🔺

❓ LM이 16,000개의 토큰을 처리할 수 있으면 실제로 16,000개의 토큰을 제공하는 것이 좋은가?

downstream task마다 다름 & 추가된 context의 가치와 긴 input context를 효과적으로 활용할 수 있는 지에 대한 모델의 능력에 따라 다름.

실험

• standard retriever-reader setup을 사용
• retriever recall과 reader accuracy를 평가

reader 모델의 성능이 retriever 모델의 성능 보다 더 빨리 포화됨 → readers가 추가된 context를 효과적으로 사용X

⇒ 모델들이 input context의 시작 또는 끝에서 정보를 검색하고 사용하는 데 더 능숙함

⇒ "effective reranking of retrieved documents"와 "ranked list truncation”이 context를 활용하기 위한 더 나은 방향

❓ "Effective Reranking of Retrieved Documents"

: 검색된 문서들을 다시 정렬하여 관련 정보를 input context의 시작 부분에 더 가깝게 위치시키는 것

ex) 관련 정보가 있는 문서를 먼저 나열하거나 가중치를 조절하여 중요한 정보에 더 집중

❓ "Ranked List Truncation"

: 검색된 문서들의 리스트를 필요에 따라 줄이는 것

ex) 모델이 다루기에 너무 많은 문서가 있는 경우, 중요한 정보만을 포함하는 작은 리스트로 줄일 수 있음

Related Work

Long-context language models

How do language models use context?

The serial-position effect

Conclusion