긴 문서 분석 시 핵심 증거를 잃지 않고 "컨텍스트 창 초과" 오류를 해결하는 방법

긴 보고서를 업로드하고 심층 분석을 요청했는데, 답변 대신 "컨텍스트 창 초과", "최대 컨텍스트 길이 초과" 또는 요청 크기가 너무 크다는 경고 메시지가 표시됩니다. 더 답답한 점은 파일 업로드는 성공했을 수도 있고, 심지어 동일한 문서로 더 간단한 질문에는 문제없이 답변이 가능했을 수도 있다는 것입니다.

이유는 간단하지만 간과하기 쉽습니다. 업로드 제한과 모델의 컨텍스트 창은 서로 다른 개념입니다. 모델은 제한된 토큰 예산 내에서 현재 분석 중인 자료를 처리해야 합니다. 이 예산에는 사용자의 지침, 대화 기록, 파일에서 가져온 텍스트, 도구 정의, 검색된 구절, 추론 토큰, 그리고 답변을 위한 공간 등이 포함될 수 있습니다. 따라서 문서가 업로드 제한을 충족하더라도 한 번에 분석하기에는 너무 클 수 있습니다.

최선의 해결책은 대개 동일한 거대한 프롬프트를 계속해서 재시도하는 것이 아닙니다. 가장 방해가 적은 변경부터 시작하고, 더 간단한 접근 방식이 여전히 실패할 경우에만 청킹, 검색 또는 더 큰 컨텍스트 워크플로로 넘어가십시오.

먼저, 오류가 실제로 컨텍스트 창 문제인지 확인하십시오.

문서를 수정하기 전에 컨텍스트 오류와 업로드 또는 저장 용량 제한을 구분하세요. OpenAI의 현재 파일 업로드 지침에 따르면 ChatGPT 또는 GPT에 업로드하는 파일은 파일당 512MB의 용량 제한이 있으며, 텍스트 및 문서 파일은 파일당 200만 토큰으로 제한됩니다. 이는 업로드 용량 제한일 뿐이며, 모든 텍스트가 모델의 활성 컨텍스트에 한 번에 배치된다는 보장은 아닙니다.

OpenAI의 파일 업로드 FAQ는 현재 업로드 제한을 확인하는 데 가장 정확한 자료입니다. 정확한 제한은 제품, 요금제, 모델 및 제공업체에 따라 다르므로 이전 문서에서 복사한 수치가 여전히 유효하다고 가정하지 마십시오.

1단계: 변경하기 전에 문서의 크기를 측정하세요.

페이지 수와 메가바이트 용량은 유용한 단서이지만, 텍스트의 맥락을 파악하는 데 중요한 것은 토큰 수입니다. 토큰화는 언어, 서식, 구두점, 그리고 모델의 인코딩 방식에 따라 달라지므로 100페이지 분량의 기술 매뉴얼과 100페이지 분량의 슬라이드 자료는 매우 다른 수의 토큰을 사용할 수 있습니다.

OpenAI의 토큰 카운팅 가이드라인은 대상 모델의 컨텍스트 창을 확인하고 출력 공간과 추론 모델의 경우 추론 토큰을 위한 공간을 확보할 것을 ​​권장합니다. 또한 메시지 구조, 도구, 파일, 이미지 및 스키마로 인해 계산하는 일반 텍스트 토큰 외에 추가 토큰이 발생할 수 있음을 언급합니다.

빠른 분류를 위해 파일의 페이지 수, 대략적인 단어 수, 주요 섹션 수, 그리고 부록, 반복적인 법률 용어, 미완성 로그, 녹취록, 표 또는 작업에 실제로 필요하지 않은 참고 자료가 포함되어 있는지 여부를 기록해 두십시오.

2단계: 파일을 열기 전에 활발한 대화를 줄이세요.

문서 크기가 지나치게 크지 않다면 파일을 분할하는 것보다 누적된 컨텍스트를 제거하는 것이 가장 저렴한 해결책일 수 있습니다. 새 채팅이나 요청을 시작하고 중요한 지침만 전달하세요. 길고 지루한 대화 대신 "첨부된 보고서를 분석하여 매출 동인, 주요 위험 요소 및 경영진 지침을 파악하세요. 다섯 가지 주요 결과를 페이지 또는 섹션 참조와 함께 제출해 주세요."와 같이 간결하게 전달하세요.

또한 반복되는 배경 자료, 더 이상 필요하지 않은 예시, 중복 붙여넣기된 텍스트 및 이전 초안 출력물을 제거하십시오. API 워크플로를 사용하는 경우 문서만 계산하지 말고 전체 요청을 계산하십시오. 간신히 들어맞는 요청은 답변을 위한 공간이 부족하여 지침이나 도구 스키마가 커짐에 따라 예기치 않게 오류가 발생할 수 있습니다.

성공의 징후: 동일한 파일이 새 스레드에서 특정 프롬프트에 집중하여 실행했을 때 정상적으로 작동하는 경우. 그렇다면 문제는 문서 자체에 있는 것이 아니라 누적된 컨텍스트에 부분적으로 기인한 것입니다.

3단계: 질문과 원하는 결과물을 구체화합니다.

"이 400페이지짜리 문서의 모든 내용을 분석하고 종합 보고서를 작성하세요"와 같은 명령은 시스템이 여러 주제를 동시에 고려하도록 강요합니다. 대신 한 번에 하나의 질문만 하세요. 예를 들어, 먼저 문서의 주요 위험 요소를 요청하고, 그다음 재무적 가정을 요청하고, 마지막으로 경영진의 주장과 이를 뒷받침하는 데이터 간의 모순점을 요청하는 식입니다.

답변 형식은 제한적으로 작성하세요. 20페이지 분량의 결과물을 요청하는 것은 10줄짜리 증거표를 요청하는 것보다 훨씬 더 많은 출력 예산을 소모합니다. 증거 수집이 완료된 후에는 언제든지 최종 답변을 확장할 수 있습니다.

유용한 집중형 질문은 다음과 같습니다. "이 문서만을 사용하여 고객 이탈과 관련된 주장을 최대 8개까지 찾아내십시오. 각 주장에 대해 섹션 또는 페이지 참조, 한 문장으로 된 설명, 그리고 명시된 제한 사항을 제시하십시오. 문서에 충분한 증거가 없는 경우, 그 사실을 명시하십시오."

다음 단계로 넘어가야 할 시점: 특정 질문에 집중해도 동일한 오류가 계속 발생하거나, 특정 주제가 아닌 문서 전체에 대한 신뢰할 수 있는 분석이 필요한 경우, 자료를 분할하십시오.

4단계: 단순히 페이지 수를 동일하게 나누는 것이 아니라, 문서의 의미를 기준으로 나누십시오.

문서 전체를 덩어리로 나누는 것은 매우 긴 문서를 처리하는 가장 확실하고 보편적인 방법입니다. 장, 보고서 섹션, 계약서, 부록, 날짜 범위 또는 발언 순서와 같은 자연스러운 경계를 기준으로 파일을 나누세요. 논리적인 덩어리로 나누는 것이 50페이지마다 임의로 자르는 것보다 문맥을 더 잘 보존합니다.

이전 섹션에 크게 의존하는 섹션은 약간의 중복이나 이전 섹션을 설명하는 짧은 연결 주석을 포함하십시오. 각 부분의 이름은 명확하게 지정하십시오(예: 01_Executive_Summary.pdf, 02_Financial_Results.pdf, 및 03_Risk_Factors.pdf). 최종 종합본을 검토할 수 있도록 가능한 한 원본 페이지 번호를 유지하십시오.

5단계: 동일한 증거 체계를 사용하여 각 데이터 덩어리를 분석합니다.

각 부분에 대한 자유 형식의 요약을 단순히 요청하지 마십시오. 모든 부분에 동일한 구조를 사용하여 중요한 차이점을 잃지 않고 결과물을 병합할 수 있도록 하십시오. 실용적인 구조에는 섹션 이름, 주요 결과, 뒷받침 증거, 페이지 또는 제목 참조, 불확실성 및 미해결 질문이 포함될 수 있습니다.

예를 들면 다음과 같습니다. “3부만 분석하십시오. 다음을 제출하십시오. (1) 5개 이하의 주요 발견 사항, (2) 각 발견 사항에 대한 증거, (3) 원래 페이지 또는 섹션 참조, (4) 저자가 언급한 주의 사항, (5) 다른 섹션에서 확인해야 하는 질문. 이 부분에 없는 사실을 추론하지 마십시오.”

이러한 접근 방식은 품질 판단을 더욱 쉽게 해줍니다. 만약 청크 요약에 출처 위치가 없는 클레임이 포함되어 있다면, 최종 합성이 이를 자동으로 수정해주기를 기대하기보다는 진행하기 전에 해당 청크를 수정해야 합니다.

6단계: 전체 청크를 다시 로드하는 대신 요약의 요약을 만듭니다.

분석이 완료되면, 각 부분의 출력 결과를 종합하여 간결한 증거 자료를 만드십시오. 모든 원본 부분과 요약본을 하나의 최종 요청으로 자동 전송하지 마십시오. 그렇게 하면 동일한 컨텍스트 문제가 재발할 수 있습니다.

종합 과정에서 모델에게 불일치 및 누락된 부분을 유지하도록 지시해야 합니다. 예를 들어, "이 섹션 분석들을 하나의 보고서로 통합하세요. 중복되는 결과는 병합하고, 상충되는 증거는 별도의 항목으로 유지하며, 모든 출처를 보존하고, 요약에서 해결할 수 없는 질문은 표시하세요."와 같이 작성할 수 있습니다.

이 계층적 방법은 특히 서적, 규제 관련 서류, 증거 자료, 장기 인터뷰 모음, 다중 문서 연구에 유용합니다. 하지만 주요 한계점은 정보 압축입니다. 즉, 요약 과정에서 생략된 세부 정보가 나중에 마법처럼 다시 나타날 수는 없습니다. 따라서 증거 체계와 출처 참조가 중요합니다.

7단계: 더 큰 맥락의 모델을 고려하되, 이를 완전한 해결책으로 간주하지 마십시오.

컨텍스트 윈도우가 더 큰 모델을 사용하면 청킹을 얼마나 적극적으로 해야 하는지를 줄일 수 있습니다. OpenAI의 최신 모델 문서에는 API 모델의 컨텍스트 윈도우 및 최대 출력 제한이 명시되어 있으며, 이러한 수치는 모델 업데이트에 따라 변경될 수 있습니다.

하지만 모델의 헤드라인 컨텍스트 크기는 제품이 프롬프트에 직접 배치하는 업로드된 파일의 양과 반드시 ​​일치하는 것은 아닙니다. OpenAI의 엔터프라이즈 전용 파일 가이드라인에서는 현재 업로드된 텍스트 문서에 대한 별도의 "컨텍스트 스터핑" 프로세스를 설명하고 있습니다. 업로드된 문서에서 최대 110,000개의 토큰이 컨텍스트에 직접 배치될 수 있으며, 추가 자료는 비공개 검색 인덱스를 통해 이용할 수 있습니다. OpenAI는 이 동작이 현재 활발히 개발 중이며 변경될 수 있다고 명시적으로 밝히고 있습니다. 자세한 내용은 ChatGPT Enterprise의 파일 업로드 최적화를 참조하십시오 .

실질적인 교훈은 워크플로를 실질적으로 단순화할 수 있다면 더 넓은 맥락의 모델을 선택하되, 관련 섹션이 실제로 고려되었는지 여부를 검증해야 한다는 것입니다. 더 넓은 맥락을 사용한다고 해서 적절한 범위 설정, 출처 참조 또는 검증의 필요성이 사라지는 것은 아닙니다.

8단계: 매우 큰 코퍼스의 경우 "모든 것을 담기"에서 "검색"으로 전환하십시오.

수백 또는 수천 페이지에 달하는 방대한 자료를 다뤄야 하는 경우, 전체 자료를 하나의 질문에 억지로 끼워 맞추려 하기보다는 검색 기반 아키텍처가 일반적으로 더 효과적입니다. 검색 시스템은 자료를 색인화하고, 현재 질문과 관련된 구절을 검색하여, 해당 구절들만을 활성 컨텍스트에 배치합니다.

OpenAI의 파일 검색 문서에는 벡터 저장소를 통해 업로드된 파일을 검색하는 호스팅 도구가 설명되어 있습니다. 이 도구는 "편의상 계약 해지를 정의하는 섹션은 어디인가요?" 또는 "보고서에서 공급망 집중도에 대해 논의하는 부분은 어디인가요?"와 같은 구체적인 질문에 특히 유용합니다.

특정 주제가 전혀 등장하지 않음을 증명하거나, 방대한 자료에서 모든 표의 셀을 비교하거나, 모든 행을 한 줄씩 완벽하게 변환하는 등 모든 구절을 동시에 파악해야 하는 작업의 경우, 검색의 신뢰도가 떨어집니다. 이러한 경우에는 검색 외에도 체계적인 배치 처리나 코드 기반 전처리를 사용하는 것이 좋습니다.

고급 API 수정: 의도적인 컨트롤 잘림 현상 해결

OpenAI Responses API를 사용하는 개발자는 추가적인 선택권을 갖습니다. API 참조 문서에는 다음과 같은 truncation설정이 있습니다. disabled기본값인 `--`로 설정하면 모델의 컨텍스트 창을 초과하는 요청은 실패합니다. `--`로 설정하면 auto이전 대화 항목을 삭제하여 요청을 컨텍스트 창에 맞출 수 있습니다. 자세한 내용은 Responses API 참조 문서를 확인하세요 .

자동 잘림 기능은 심각한 오류를 방지할 수 있지만, 모델에서 사용할 수 있는 정보를 변경합니다. 문서 분석의 경우, 초기 컨텍스트를 조용히 삭제하는 것은 오류를 수신하는 것보다 더 나쁠 수 있습니다. 따라서 애플리케이션이 오래된 대화 항목을 삭제해도 되거나 이미 다른 곳에서 요약된 경우에만 자동 잘림 기능을 사용하십시오.

해결책이 실제로 효과가 있었는지 확인하는 방법

요청이 성공적으로 처리되는 것만으로는 충분하지 않습니다. 목표는 증거를 조용히 없애지 않으면서 적절한 자료를 다루는, 타당한 분석을 하는 것입니다. 문제가 해결되었다고 판단하기 전에 결과를 검증하십시오.

• 범위 확인: 분석 계획 또는 최종 증거표에 필요한 모든 장, 날짜 범위 또는 원본 파일이 포함되어 있는지 확인합니다.
• 추적성 검사: 중요한 내용을 샘플링하고 해당 내용이 참조하는 페이지, 섹션 또는 파일 정보가 원본 출처와 일치하는지 확인합니다.
• 경계 검사: 개념이 여러 부분으로 나뉘거나 서로 모순되지 않았는지 확인하기 위해 청크 경계 근처의 결과를 검사합니다.
• 음성 대조 검사: 답이 없는 것으로 알려진 질문 하나를 던집니다. 좋은 워크플로는 증거를 만들어내는 대신 증거가 없다고 말해야 합니다.
• 반복성 확인: 몇 가지 대표적인 질문을 다시 실행해 보세요. 인용된 근거에 큰 변화가 있다면 정보 검색이 미흡하거나 질문이 지나치게 포괄적이었음을 나타낼 수 있습니다.
• 예산 점검: API를 사용하는 경우, 대략적인 단어 수 추정치에만 의존하지 말고 실제 입력 및 출력 토큰 사용량을 검사하세요.

하지 말아야 할 일

동일한 크기의 요청을 계속해서 재전송하고 토큰 제한이 달라질 것이라고 기대하지 마십시오. 청킹 과정에서 소스 참조를 삭제하지 마십시오. 파일이 승인되었다고 해서 모든 페이지가 컨텍스트에서 활성화되어 있다고 가정하지 마십시오. 또한 분석이 더 이상 작업을 만족시킬 수 없을 정도로 응답을 지나치게 단축하여 오류를 해결하지 마십시오.

또한 자동 데이터 삭제 기능을 마치 마법처럼 여기지 마십시오. 시스템이 오래된 항목을 삭제하면 요청은 성공하더라도 중요한 지침이나 증거를 잃을 수 있습니다. 중요한 분석의 경우, 명시적인 데이터 분할 및 검색 방식이 일반적으로 감사하기 더 쉽습니다.

실용적인 결정 규칙

새로운 스레드를 만들고 질문을 구체화하면 워크플로를 단순하게 유지할 수 있습니다. 긴 문서를 광범위하게 분석해야 하는 경우, 논리적인 섹션으로 나누어 구조화된 분석을 수행하세요. 매우 큰 문서 모음을 반복적으로 조회해야 하는 경우, 검색 기능을 활용하세요. API를 제어할 수 있는데도 한계에 가까워진다면, 토큰 수를 측정하고, 출력 공간을 확보하고, 적절한 모델을 선택하고, 잘림 현상을 명시적인 설계 결정 사항으로 고려하세요.

가장 강력한 결과는 단일 요청에 가장 많은 텍스트를 담는 것이 아닙니다. 필요한 증거를 모두 포함하고, 추적성을 유지하며, 정보가 부족했을 때 이를 명확히 드러내는 결과입니다.

공식 참고 자료

• OpenAI: 토큰 이해 및 개수 세기
• OpenAI: 파일 업로드 FAQ
• OpenAI: ChatGPT Enterprise에서 파일 업로드 최적화
• OpenAI API: 모델 문서
• OpenAI API: 파일 검색
• OpenAI API: 응답 참조