컨텍스트 저하

컨텍스트 저하 패턴

컨텍스트 오류가 연쇄적으로 발생하기 전에 진단하고 수정합니다. 컨텍스트 저하는 이진적이지 않습니다. 중간 내용 손실, 중독, 주의 산만, 혼란, 충돌이라는 다섯 가지 뚜렷하고 예측 가능한 패턴으로 나타나는 연속체입니다. 각 패턴에는 특정 감지 신호와 완화 전략이 있습니다. 저하를 예측 불가능한 오류 모드가 아닌 측정 가능한 임계값을 가진 엔지니어링 문제로 취급하십시오.

활성화 시기

다음과 같은 경우 이 스킬을 활성화하십시오:

• 긴 대화 중 에이전트 성능이 예기치 않게 저하될 때
• 에이전트가 부정확하거나 관련 없는 출력을 생성하는 디버깅 사례
• 대규모 컨텍스트를 안정적으로 처리해야 하는 시스템 설계
• 프로덕션 시스템을 위한 컨텍스트 엔지니어링 선택 평가
• 에이전트 출력에서 '중간 내용 손실' 현상 조사
• 에이전트 동작에서 컨텍스트 관련 오류 분석

다른 스킬이 담당하는 인접 작업에는 이 스킬을 활성화하지 마십시오:

• 활성 오류 없이 기본 컨텍스트 메커니즘 설명: context-fundamentals.
• 오류 패턴 파악 후 토큰 효율성 전략 적용: context-optimization.
• 압축 또는 핸드오프 요약 전략 설계: context-compression.
• 프롬프트 외부에 대규모 출력, 로그 또는 임시 상태 저장: filesystem-context.

핵심 개념

컨텍스트 배치를 주의 U-곡선에 맞춰 구성하십시오. 시작과 끝 위치는 안정적인 주의를 받지만, 중간 위치는 긴 컨텍스트 실험에서 실질적으로 낮은 재현 정확도를 보입니다(claim-context-degradation-lost-middle-ruler). 이는 모델 버그가 아니라 주의 메커니즘의 결과입니다. 첫 번째 토큰(종종 BOS)은 '주의 싱크' 역할을 하여 불균형적으로 많은 주의 예산을 흡수하며, 컨텍스트가 길어짐에 따라 중간 토큰은 덜 주의를 받게 됩니다.

컨텍스트 중독을 회로 차단기 문제로 취급하십시오. 일단 환각, 도구 오류 또는 잘못 검색된 사실이 컨텍스트에 들어오면, 반복적인 자기 참조를 통해 악화됩니다. 중독된 목표 섹션은 모든 하위 결정이 잘못된 가정을 강화하도록 만듭니다. 감지에는 주장 출처 추적이 필요하며, 복구는 중독 지점 이전으로 잘라내거나 검증된 컨텍스트만으로 다시 시작해야 합니다.

컨텍스트를 로드하기 전에 적극적으로 필터링하십시오. 단 하나의 관련 없는 문서라도 관련 작업의 성능을 측정 가능하게 저하시킵니다. 모델은 관련 없는 컨텍스트를 '건너뛸' 수 없습니다. 제공된 모든 항목에 주의를 기울여야 하므로 관련 콘텐츠와 관련 없는 콘텐츠 간에 주의 경쟁이 발생합니다. 즉시 필요하지는 않지만 필요할 수 있는 정보는 사전 로드하는 대신 도구 호출 뒤에 배치하십시오.

혼란을 방지하기 위해 작업 컨텍스트를 분리하십시오. 컨텍스트에 여러 작업 유형이 포함되거나 목표 간 전환이 있을 때, 모델은 잘못된 작업의 제약 조건을 통합하고, 다른 컨텍스트에 적합한 도구를 호출하거나, 여러 소스의 요구 사항을 혼합합니다. 별도의 컨텍스트 창을 사용한 명시적 작업 분할은 교차 오염을 제거합니다.

컨텍스트 충돌을 누적이 아닌 우선순위 규칙을 통해 해결하십시오. 올바르지만 상충하는 여러 소스가 컨텍스트에 나타날 때(버전 충돌, 관점 충돌, 다중 소스 검색), 모델은 어느 것이 적용되는지 결정할 수 없습니다. 모순을 명시적으로 표시하고, 소스 우선순위를 설정하며, 오래된 버전이 컨텍스트에 들어오기 전에 필터링하십시오.

상세 주제

중간 내용 손실: 감지 및 배치 전략

중요 정보는 컨텍스트의 시작과 끝에 배치하고 중간에는 절대 배치하지 마십시오. U자형 주의 곡선은 중간에 위치한 정보의 재현 정확도가 10-40% 감소함을 의미합니다. 4K 토큰을 초과하는 컨텍스트에서는 이 효과가 중요해집니다.

주요 결과를 주의 선호 위치에 표시하는 요약 구조를 사용하십시오. 명시적인 섹션 헤더와 구조적 마커를 추가하십시오. 이는 주의 앵커를 생성하여 모델이 긴 컨텍스트를 탐색하는 데 도움이 됩니다. 문서 전체를 포함해야 하는 경우, 주요 포인트에 대한 요약을 앞에 추가하고 중요한 결론을 끝에 추가하십시오.

중간 내용 손실 증상을 모니터링하십시오. 올바른 정보가 컨텍스트에 있지만 모델이 무시하거나, 응답이 제공된 데이터와 모순되거나, 긴 프롬프트의 앞부분에 주어진 지침을 모델이 '잊는' 경우입니다.

컨텍스트 중독: 예방 및 복구

모든 외부 입력을 컨텍스트에 들어오기 전에 검증하십시오. 도구 출력, 검색된 문서, 모델 생성 요약은 세 가지 주요 중독 경로입니다. 각각은 이후 추론에서 기본 진실로 취급되는 검증되지 않은 주장을 도입합니다.

다음 신호를 통해 중독을 감지하십시오. 이전에 성공했던 작업에서 출력 품질 저하, 도구 정렬 불량(잘못된 도구 또는 매개변수), 명시적 수정에도 지속되는 환각. 이러한 신호가 군집되면 모델 능력 문제보다 중독을 의심하십시오.

중독된 콘텐츠를 제거하여 복구하고, 위에 수정 사항을 추가하지 마십시오. 중독 지점 이전으로 잘라내고, 검증된 정보만 보존하여 깨끗한 컨텍스트로 다시 시작하거나, 중독된 섹션을 명시적으로 표시하고 처음부터 재평가를 요청하십시오. 중독된 컨텍스트 위에 수정 사항을 계층화하는 것은 거의 효과가 없습니다. 원래 오류는 주의 가중치를 유지하기 때문입니다.

컨텍스트 주의 산만: 누적보다 선별

모델이 관련 없는 콘텐츠를 무시할 것이라고 기대하지 말고, 무엇이 컨텍스트에 들어올지 선별하십시오. 연구에 따르면 단 하나의 방해 문서라도 측정 가능한 성능 저하를 유발합니다. 효과는 선형 곡선이 아니라 계단 함수를 따릅니다. 여러 방해 요소는 문제를 악화시킵니다.

검색된 문서를 로드하기 전에 관련성 필터링을 적용하십시오. 네임스페이스 지정과 구조적 구성을 사용하여 섹션 경계를 명확히 하십시오. 사전 로드보다 도구 호출 기반 액세스를 선호하십시오. 참조 자료를 검색 도구 뒤에 저장하여 현재 추론 단계와 직접 관련이 있을 때만 컨텍스트에 들어오도록 하십시오.

컨텍스트 혼란: 작업 분리

다른 작업을 별도의 컨텍스트 창으로 분할하십시오. 컨텍스트 혼란은 주의 산만과 다릅니다. 단순한 주의 분산뿐만 아니라 모델이 현재 작업에 잘못된 컨텍스트 제약 조건을 적용하는 것과 관련됩니다. 징후로는 쿼리의 잘못된 측면을 다루는 응답, 다른 작업에 적합한 도구 호출, 여러 소스의 요구 사항을 혼합한 출력이 있습니다.

작업 컨텍스트 간에 명확한 전환을 구현하십시오. 작업별로 목표, 제약 조건, 도구 정의를 분리하는 상태 관리를 사용하십시오. 단일 세션 내에서 작업 전환이 불가피한 경우, 현재 세그먼트에 어떤 제약 조건이 적용되는지 알리는 명시적인 '컨텍스트 재설정' 마커를 사용하십시오.

컨텍스트 충돌: 충돌 해결 프로토콜

충돌이 발생하기 전에 소스 우선순위 규칙을 수립하십시오. 컨텍스트 충돌은 중독과 다릅니다. 여러 정보가 개별적으로는 올바르지만 상호 모순됩니다(버전 충돌, 관점 차이, 다양한 사실을 포함한 다중 소스 검색).

오래된 정보가 컨텍스트에 들어오기 전에 제외하는 버전 필터링을 구현하십시오. 모순을 피할 수 없는 경우, 구조화된 충돌 주석을 사용하여 명시적으로 표시하십시오. 무엇이 충돌하는지, 각 주장이 어느 소스에서 왔는지, 어느 소스가 우선하는지 명시하십시오. 명시적인 우선순위 규칙이 없으면 모델은 충돌을 예측할 수 없게 해결합니다.

경험적 벤치마크 및 임계값

이러한 벤치마크를 설계 제약 조건을 설정하는 데 사용하고, 보편적 진리로 취급하지 마십시오. RULER 스타일 증거는 광고된 긴 컨텍스트 지원이 해당 길이에서 만족스러운 작업 성능을 보장하지 않음을 보여줍니다(claim-context-degradation-lost-middle-ruler). 거의 완벽한 바늘-건초 더미 점수는 실제 긴 컨텍스트 성능을 예측하지 못합니다.

모델별 저하 임계값

저하 시작은 모델 제품군과 작업 유형에 따라 크게 다릅니다. 일반적인 규칙으로, 복잡한 검색 작업의 경우 광고된 컨텍스트 창의 60-70%에서 저하가 시작될 것으로 예상하십시오(RULER 벤치마크에 따르면 32K+ 컨텍스트를 주장하는 모델 중 50%만이 해당 길이에서 만족스러운 성능을 유지합니다). 주요 패턴:

• 확장 사고를 가진 모델은 단계별 검증을 통해 환각을 줄이지만 대기 시간과 토큰 비용이 더 높습니다.
• 에이전트/코딩에 최적화된 모델은 도구 출력이 많은 컨텍스트에서 더 나은 주의 관리를 보이는 경향이 있습니다.
• 매우 큰 컨텍스트 창(1M+)을 가진 모델은 더 많은 원시 컨텍스트를 처리하지만 여전히 U자형 저하 곡선을 따릅니다. 창이 더 크다고 문제가 사라지지 않고 지연될 뿐입니다.

항상 게시된 벤치마크에 의존하지 말고 특정 워크로드로 저하 임계값을 벤치마킹하십시오. 모델별 임계값은 각 모델 업데이트와 함께 만료됩니다(고트차 2 참조).

반직관적인 발견

컨텍스트 전략을 설계할 때 이러한 연구 기반의 놀라운 점을 고려하십시오.

섞인 컨텍스트가 일관된 컨텍스트보다 나을 수 있습니다. 연구에 따르면 일관성이 없는(섞인) 건초 더미는 일부 검색 작업에서 논리적으로 정렬된 것보다 더 나은 성능을 보일 수 있습니다(claim-context-degradation-distractor-shuffled). 일관된 컨텍스트는 검색을 혼란스럽게 하는 잘못된 연관성을 만들 수 있는 반면, 일관성 없는 컨텍스트는 정확한 일치를 강제할 수 있습니다. 더 잘 구성된 컨텍스트가 항상 더 나은 결과를 낳는다고 가정하지 말고 두 배열을 모두 테스트하십시오.

단일 방해 요소는 불균형적인 영향을 미칩니다. 하나의 관련 없는 문서로 인한 성능 저하가 첫 번째 이후에 방해 요소를 추가할 때보다 불균형적으로 큽니다. 방해 요소 방지는 이진법으로 취급하십시오. 컨텍스트를 깨끗하게 유지하거나 심각한 저하를 감수하십시오.

낮은 바늘-질문 유사성은 저하를 가속화합니다. 서로 다른 콘텐츠 간의 추론이 필요한 작업은 표면적 유사성이 높은 작업보다 컨텍스트 길이에 따라 더 빨리 저하됩니다. 쿼리와 검색된 콘텐츠 간의 의미적 중첩을 최대화하도록 검색을 설계하십시오.

더 큰 컨텍스트가 해로울 때

더 큰 컨텍스트 창이 성능을 향상시킨다고 가정하지 마십시오. 성능은 모델별 임계값까지 안정적으로 유지되다가 급격히 저하됩니다. 곡선은 완만한 경사가 아니라 절벽 가장자리가 있는 비선형입니다. 많은 모델의 경우 창이 훨씬 더 큰 크기를 지원하더라도 8K-16K 토큰에서 의미 있는 저하가 시작됩니다.

비용을 고려하십시오: 400K 토큰 컨텍스트 처리는 200K보다 시간과 컴퓨팅 측면에서 기하급수적으로 더 많은 비용이 들며 선형적으로 증가하지 않습니다. 많은 애플리케이션에서 이는 대규모 컨텍스트 처리를 경제적으로 비실용적으로 만듭니다.

인지 병목 현상을 인식하십시오. 무한한 컨텍스트가 있더라도 단일 모델이 수십 개의 독립적인 작업에서 품질을 유지하도록 요청하는 것은 더 많은 컨텍스트로 해결할 수 없는 저하를 만듭니다. 컨텍스트를 확장하는 대신 작업을 하위 에이전트에 분할하십시오.

실용적인 지침

4-버킷 완화 프레임워크

활성 저하 패턴에 따라 다음 네 가지 전략을 적용하십시오.

쓰기 — 스크래치패드, 파일 시스템 또는 외부 저장소를 사용하여 컨텍스트를 창 외부에 저장하십시오. 컨텍스트 사용률이 창의 70%를 초과할 때 사용하십시오. 이는 도구 호출을 통한 정보 액세스를 유지하면서 활성 컨텍스트를 가볍게 유지합니다.

선택 — 검색, 필터링 및 우선순위 지정을 통해 관련 컨텍스트만 창으로 가져오십시오. 주의 산만 또는 혼란 증상이 나타날 때 사용하십시오. 로드하기 전에 관련성 점수를 적용하십시오. 사용 가능한 모든 항목을 포함하는 대신 임계값 미만은 제외하십시오.

압축 — 요약, 추상화 및 관찰 마스킹을 통해 토큰을 줄이면서 정보를 보존하십시오. 컨텍스트가 커지지만 모든 콘텐츠가 관련될 때 사용하십시오. 장황한 도구 출력을 간결한 구조화된 요약으로 바꾸고 반복되는 패턴을 단일 참조로 추상화하십시오.

격리 — 단일 컨텍스트가 저하 임계값을 초과하여 커지는 것을 방지하기 위해 하위 에이전트 또는 세션 간에 컨텍스트를 분할하십시오. 혼란 또는 충돌 증상이 나타나거나 작업이 독립적일 때 사용하십시오. 이는 가장 공격적인 전략이지만 복잡한 다중 작업 시스템에 가장 효과적인 경우가 많습니다.

복원력을 위한 아키텍처 패턴

적시 컨텍스트 로딩을 구현하십시오. 현재 추론 단계에 필요할 때만 정보를 검색하고 선제적으로 검색하지 마십시오. 관찰 마스킹을 사용하여 처리 후 장황한 도구 출력을 간결한 참조로 바꾸십시오. 각 에이전트가 작업 관련 컨텍스트만 보유하는 하위 에이전트 아키텍처를 배포하십시오. 증상이 나타난 후가 아니라 모델별 저하 시작 임계값을 초과하기 전에 압축을 트리거하십시오.

예제

예제 1: 저하 감지

# 긴 대화 중 컨텍스트 증가
turn_1: 1000 토큰
turn_5: 8000 토큰
turn_10: 25000 토큰
turn_20: 60000 토큰 (저하 시작)
turn_30: 90000 토큰 (심각한 저하)

예제 2: 중간 내용 손실 완화

# 중요한 정보를 가장자리에 배치하여 컨텍스트 구성

[현재 작업]                      # 시작 부분
- 목표: 분기별 보고서 생성
- 마감: 주말까지

[세부 컨텍스트]                  # 중간 (주의 감소)
- 50페이지 분량 데이터
- 여러 분석 섹션
- 뒷받침 증거

[주요 결과]                     # 끝 부분
- 수익 15% 증가
- 비용 8% 감소
- A 지역 성장

예제 3: 컨텍스트 중독 회로 차단기

증상: 에이전트가 수정 후에도 잘못 검색된 주장을 계속 인용
진단: 중독된 컨텍스트, 누락된 지침 문제가 아님
조치:
  1. 잘못된 주장이 들어온 첫 번째 턴 식별
  2. 해당 지점 이전으로 잘라내거나 다시 시작
  3. 검증된 소스만 다시 로드
  4. 거부된 주장과 소스 출처 기록

예제 4: 컨텍스트 충돌 주석

conflict:
  topic: 결제 API 버전
  source_a: docs/v1.md의 엔드포인트는 /charges
  source_b: docs/v2.md의 엔드포인트는 /payments
  precedence: docs/v2.md
  reason: 현재 프로덕션 버전

지침

1. 개발 중 컨텍스트 길이와 성능 상관 관계 모니터링
2. 중요한 정보는 컨텍스트의 시작 또는 끝에 배치
3. 저하가 심각해지기 전에 압축 트리거 구현
4. 컨텍스트에 추가하기 전에 검색된 문서의 정확성 검증
5. 버전 관리를 사용하여 오래된 정보가 충돌을 일으키지 않도록 방지
6. 다른 목표 간 컨텍스트 혼란을 방지하기 위해 작업 분할
7. 갑작스러운 실패보다는 우아한 저하를 위해 설계

[번역을 위해 잘림]