중간에 길을 잃다: 더 큰 컨텍스트 윈도우가 항상 LLM 성능을 향상시키는 것은 아니다

Source: Dev.to

Overview

모든 내용을 하나의 긴 프롬프트에 넣고 동작하길 기대하는 것이 흔한 관행이지만, 종종 역효과를 낳습니다. 더 많은 컨텍스트를 추가하면 실제로 모델의 답변이 악화될 수 있으며, 명확히 작성된 제약 조건조차 무시될 수 있습니다.

The “Lost in the Middle” Study

Experimental setup

연구자들은 언어 모델에 여러 문서를 제공하고 관련 정보를 세 가지 가능한 위치에 배치했습니다:

• 컨텍스트의 시작 부분
• 컨텍스트의 중간 부분
• 컨텍스트의 끝 부분

만약 긴 컨텍스트 처리가 완벽하다면, 위치에 관계없이 성능은 동일해야 합니다.

Findings

• 최고 성능: 필요한 정보가 프롬프트의 시작 또는 끝에 있을 때.
• 최악 성능: 정보가 중간에 있을 때; 경우에 따라서는 문서를 전혀 제공하지 않은 것보다 성능이 더 낮았습니다.

이 효과는 상당히 크며 특정 모델 패밀리에만 국한되지 않습니다.

Parallel in Human Memory

이 패턴은 인간 인지에서 관찰되는 연속 위치 효과와 유사합니다:

• 우리는 책이나 대화의 시작과 끝을 중간 부분보다 더 생생하게 기억합니다.
• 중간 부분의 세부 사항은 더 빨리 사라지는 경향이 있습니다.

이론적으로 트랜스포머 구조는 모든 토큰에 동일하게 주의를 기울일 수 있지만, 입력의 시작과 끝에 편향된 유사한 경향을 보입니다.

Implications for Larger Context Windows

• 토큰이 많다고 해서 추론이 더 좋은 것은 아니다. 컨텍스트 윈도우를 (예: 100 k 또는 200 k 토큰) 확장한다고 해서 입력이 작은 윈도우 안에 들어갈 경우 성능이 자동으로 향상되지 않습니다.
• 큰 코드 파일, 긴 로그, 많은 제약 조건, 혹은 방대한 채팅 기록을 제공할 때, 중간에 배치된 중요한 정보는 가중치가 낮아질 수 있습니다.
• 이는 모델이 명확히 작성된 규칙을 무시하는 현상을 설명합니다—우연이 아니라 체계적인 편향 때문입니다.

Practical Prompt Design Recommendations

Prompt structure

Example of a strict output schema

{
  "type": "object",
  "properties": {
    "result": { "type": "string" },
    "metadata": {
      "type": "object",
      "properties": {
        "timestamp": { "type": "string", "format": "date-time" },
        "source": { "type": "string" }
      },
      "required": ["timestamp"]
    }
  },
  "required": ["result"]
}

Guidelines for using the schema

• 출력은 반드시 유효한 JSON이어야 합니다.
• 설명이나 기타 추가 텍스트를 포함하지 마세요.
• 스키마를 정확히 따르세요.

Additional tips

• 대화가 매우 길어지면, 거대한 스레드를 계속 이어가기보다 새롭고 깔끔한 프롬프트를 시작하는 것을 고려하세요.
• 가장 중요한 지시사항을 가장 앞에 배치하고, 끝에서도 반복하거나 강화하세요.
• 프롬프트의 중간은 “지원 데이터” 섹션으로 취급하세요; 모델이 이 부분에 덜 집중합니다.

프롬프트를 명확한 계층 구조(핵심 지시사항 → 지원 정보 → 강화)로 구성하면 “중간에 사라지는” 효과를 완화하고 보다 신뢰할 수 있는 출력을 얻을 수 있습니다.