많은 Gemini 모델에는 100만 개 이상의 토큰으로 구성된 대규모 컨텍스트 윈도우가 제공됩니다. 지금까지 대규모 언어 모델 (LLM)은 한 번에 모델에 전달할 수 있는 텍스트 (또는 토큰) 양에 의해 크게 제한되었습니다. Gemini 긴 컨텍스트 윈도우는 많은 새로운 사용 사례와 개발자 패러다임을 제공합니다.
텍스트 생성 또는 멀티모달 입력과 같은 사례에 이미 사용 중인 코드는 긴 컨텍스트와 함께 변경 없이 작동합니다.
이 문서에서는 컨텍스트 윈도우가 100만 개 이상의 토큰인 모델을 사용하여 얻을 수 있는 이점에 대해 간략히 설명합니다. 이 페이지에서는 컨텍스트 창을 간략히 살펴보고 개발자가 긴 컨텍스트에 대해 생각하는 방식, 긴 컨텍스트의 다양한 실제 사용 사례, 긴 컨텍스트 사용을 최적화하는 방법을 살펴봅니다.
특정 모델의 컨텍스트 창 크기는 모델 페이지를 참고하세요.
컨텍스트 윈도우란 무엇인가요?
Gemini 모델을 사용하는 기본 방법은 정보 (컨텍스트)를 모델에 전달하여 이후에 응답을 생성하는 것입니다. 컨텍스트 윈도우는 단기 메모리에 비유할 수 있습니다. 개인의 단기 메모리에 저장할 수 있는 정보 양은 제한되어 있으며 이는 생성 모델에서도 마찬가지입니다.
모델이 작동하는 방식에 대한 자세한 내용은 생성 모델 가이드를 참조하세요.
긴 컨텍스트 시작하기
이전 버전의 생성형 모델은 한 번에 8,000개의 토큰만 처리할 수 있었습니다. 최신 모델은 토큰 32,000개 또는 128,000개를 허용하여 이를 더욱 발전시켰습니다. Gemini는 토큰 100만 개를 수용할 수 있는 최초의 모델입니다.
실제로 토큰 100만 개는 다음과 같이 표시됩니다.
- 코드 50,000줄(줄당 표준 80자)
- 지난 5년 동안 보낸 모든 문자 메시지
- 평균 길이의 영어 소설 8권
- 평균 길이 200분이 넘는 팟캐스트 에피소드 스크립트
다른 많은 모델에서 일반적으로 사용되는 더 제한적인 컨텍스트 창은 종종 이전 메시지를 임의로 삭제하거나, 콘텐츠를 요약하거나, 벡터 데이터베이스에서 RAG를 사용하거나, 프롬프트를 필터링하여 토큰을 저장하는 등의 전략이 필요합니다.
이러한 기법은 특정 시나리오에서 여전히 유용하지만 Gemini의 광범위한 컨텍스트 창을 사용하면 더 직접적인 접근 방식을 사용할 수 있습니다. 즉, 모든 관련 정보를 미리 제공하는 것입니다. Gemini 모델은 대규모 컨텍스트 기능을 갖추도록 설계되었기 때문에 강력한 컨텍스트 내 학습을 보여줍니다. 예를 들어 문맥 교육 자료 (500페이지의 참조 문법, 사전, 약 400개의 대응 문장)만 사용하여 Gemini는 영어에서 200명 미만의 사용자가 사용하는 파푸아어인 Kalamang으로 번역하는 법을 학습했으며, 품질은 동일한 자료를 사용하는 인간 학습자와 비슷했습니다. 이는 Gemini의 긴 컨텍스트가 제공하는 패러다임 전환을 보여주며, 이를 통해 강력한 컨텍스트 학습을 통해 새로운 가능성을 열 수 있습니다.
긴 컨텍스트 사용 사례
대부분의 생성형 모델의 표준 사용 사례는 여전히 텍스트 입력이지만 Gemini 모델 제품군은 멀티모달 사용 사례에 새로운 패러다임을 제공합니다. 이러한 모델은 기본적으로 텍스트, 동영상, 오디오, 이미지를 이해할 수 있습니다. 편의를 위해 멀티모달 파일 형식을 사용하는 Gemini API도 함께 제공됩니다.
긴 형식 텍스트
텍스트는 LLM과 관련된 많은 모멘텀을 뒷받침하는 인텔리전스 레이어로 입증되었습니다. 앞에서 언급했듯이 LLM의 실질적인 제한사항 중 상당수는 특정 태스크를 수행하기에 충분히 큰 환경설정 기간이 없기 때문입니다. 이로 인해 모델에 관련 컨텍스트 정보를 동적으로 제공하는 검색 증강 생성(RAG) 및 기타 기술이 빠르게 채택되었습니다. 이제 더 큰 컨텍스트 윈도우를 통해 새로운 사용 사례를 활용할 수 있는 새로운 기술이 제공되고 있습니다.
긴 컨텍스트 기반 텍스트에 대한 몇 가지 새로운 표준 사용 사례는 다음과 같습니다.
- 대규모 텍스트 코퍼스 요약
- 이전의 소규모 컨텍스트 모델을 사용한 요약 옵션에서는 새 토큰이 모델에 전달될 때 이전 섹션 상태가 유지되도록 슬라이딩 창이나 다른 기법이 필요했습니다.
- 질문 및 답변
- 이전에는 컨텍스트가 제한되어 있고 모델의 사실에 기반한 재현율이 낮기 때문에 RAG를 통해서만 가능했습니다.
- 에이전트 워크플로
- 텍스트는 에이전트가 수행한 작업과 필요한 작업의 상태를 유지하는 방법의 기반이 됩니다. 현실에 대한 정보와 에이전트의 목표에 대한 정보가 충분하지 않으면 에이전트의 안정성에 제약이 됩니다.
다중샷 컨텍스트 내 학습은 긴 컨텍스트 모델에서 제공하는 독보적인 기능 중 하나입니다. 연구에 따르면 모델에게 하나 또는 몇 가지의 태스크 예시를 제공하는 일반적인 '싱글샷' 또는 '멀티샷' 예시 패러다임을 수백, 수천, 또는 수십만 개의 예시로 확장하면 새로운 모델 기능으로 이어질 수 있습니다. 이 다중샷 접근 방식은 특정 태스크에 맞게 미세 조정된 모델과 유사하게 작동하는 것으로 나타났습니다. Gemini 모델의 성능이 프로덕션 출시에 아직 충분하지 않은 사용 사례의 경우 다중샷 접근 방식을 시도할 수 있습니다. 나중에 긴 컨텍스트 최적화 섹션에서 살펴볼 수 있듯이 컨텍스트 캐싱을 사용하면 이러한 유형의 높은 입력 토큰 워크로드를 훨씬 더 경제적으로 실행할 수 있으며 경우에 따라 지연 시간을 줄일 수도 있습니다.
긴 형식 동영상
동영상 콘텐츠 유용성은 오랫동안 매체 자체의 접근성 부족으로 인해 제한적이었습니다. 콘텐츠를 훑어보기 어려웠고, 스크립트가 동영상의 미묘한 차이를 포착하지 못하는 경우가 많았으며, 대부분의 도구는 이미지, 텍스트, 오디오를 함께 처리하지 못했습니다. Gemini를 사용하면 긴 컨텍스트 텍스트 기능이 지속적인 성능으로 멀티모달 입력에 대한 질문을 추론하고 답변하는 기능으로 변환됩니다.
동영상의 긴 컨텍스트에 대한 몇 가지 새로운 표준 사용 사례는 다음과 같습니다.
- 동영상 질문 및 답변
- Google의 Project Astra에 표시된 것과 같은 동영상 메모리
- 동영상 자막
- 새로운 멀티모달 이해로 기존 메타데이터를 보강하는 동영상 추천 시스템
- 데이터 및 관련 동영상 메타데이터 코퍼스를 살펴본 후 시청자와 관련이 없는 동영상 부분을 삭제하는 방식으로 동영상 맞춤설정
- 동영상 콘텐츠 검토
- 실시간 동영상 처리
동영상 작업을 수행할 때는 동영상이 토큰으로 처리되는 방식을 고려하는 것이 중요합니다. 이는 결제 및 사용량 한도에 영향을 미칩니다. 동영상 파일로 프롬프트를 입력하는 방법은 프롬프트 가이드를 참고하세요.
긴 형식 오디오
Gemini 모델은 오디오를 이해할 수 있는 최초의 네이티브 멀티모달 대규모 언어 모델이었습니다. 지금까지 일반적인 개발자 워크플로는 오디오를 처리하기 위해 음성 텍스트 변환 모델 및 텍스트 간 변환 모델과 같은 여러 도메인별 모델을 결합하는 방식으로 진행되었습니다. 이에 따라 여러 왕복 요청을 수행하는 데 필요한 추가 지연 시간이 발생하고, 다중 모델 설정의 연결 해제된 아키텍처로 인해 성능이 저하되었습니다.
오디오 컨텍스트에 대한 몇 가지 새로운 표준 사용 사례는 다음과 같습니다.
- 실시간 스크립트 작성 및 번역
- 팟캐스트/동영상 질문 및 답변
- 회의 스크립트 작성 및 요약
- 음성 지원
오디오 파일로 프롬프트를 입력하는 방법에 대한 자세한 내용은 프롬프트 가이드를 참조하세요.
긴 컨텍스트 최적화
긴 컨텍스트와 Gemini 모델을 사용할 때의 기본 최적화 방법은 컨텍스트 캐싱을 사용하는 것입니다. 이전에는 단일 요청에서 많은 토큰을 처리하는 것이 불가능했으며 또 다른 제약조건은 비용이었습니다. 사용자가 10개의 PDF, 동영상, 일부 작업 문서를 업로드하는 '데이터와 채팅' 앱이 있는 경우 기존에는 이러한 요청을 처리하기 위해 더 복잡한 검색 증강 생성(RAG) 도구 /프레임워크를 사용해야 했고, 컨텍스트 윈도우로 이동되는 토큰에 대해 상당한 비용을 지불해야 했습니다. 이제 사용자가 업로드한 파일을 캐시하고 시간 단위로 저장 비용을 지불할 수 있습니다. 예를 들어 Gemini Flash를 사용한 요청당 입력 / 출력 비용은 표준 입력 / 출력 비용보다 약 4배 낮으므로 사용자가 데이터와 충분히 채팅하면 개발자에게는 비용이 크게 절감됩니다.
긴 컨텍스트 제한사항
이 가이드의 여러 섹션에서는 Gemini 모델이 다양한 건초 더미에서 바늘 찾기 검색 평가에서 높은 성능을 달성하는 방법을 설명했습니다. 이러한 테스트에서는 하나의 바늘을 찾는 가장 기본적인 설정을 고려합니다. 찾고자 하는 '바늘', 즉 특정 정보가 여러 개 있는 경우 모델의 정확성은 동일하지 않습니다. 성능은 컨텍스트에 따라 크게 달라질 수 있습니다. 올바른 정보 검색과 비용 사이에는 고유한 절충점이 있으므로 이를 고려하는 것이 중요합니다. 단일 쿼리에서 최대 99%까지 얻을 수 있지만 쿼리를 전송할 때마다 입력 토큰 비용을 지불해야 합니다. 따라서 100개의 정보를 검색하는데 99%의 성능이 필요하다면 100개의 요청을 보내야 할 가능성이 높습니다. 이는 컨텍스트 캐싱이 성능을 높게 유지하면서 Gemini 모델 사용과 관련된 비용을 크게 줄일 수 있는 좋은 예시입니다.
FAQ
컨텍스트 창에 쿼리를 배치하기에 가장 좋은 위치는 어디인가요?
대부분의 경우, 특히 전체 컨텍스트가 긴 경우 프롬프트 끝 (다른 모든 컨텍스트 뒤)에 쿼리 / 질문을 배치하면 모델의 성능이 향상됩니다.
쿼리에 토큰을 더 추가하면 모델 성능이 저하되나요?
일반적으로 토큰을 모델에 전달할 필요가 없는 경우 전달하지 않는 것이 가장 좋습니다. 하지만 정보가 포함된 대량의 토큰이 있고 이 정보에 관해 질문하고 싶다면 모델이 이 정보를 매우 효과적으로 추출할 수 있습니다 (대부분의 경우 최대 99% 의 정확도).
긴 컨텍스트 쿼리로 비용을 줄이려면 어떻게 해야 하나요?
여러 번 재사용하려는 유사한 토큰 / 컨텍스트 세트가 있는 경우 컨텍스트 캐싱을 사용하면 해당 정보에 관한 질문과 관련된 비용을 줄일 수 있습니다.
컨텍스트 길이가 모델 지연 시간에 영향을 미치나요?
크기와 관계없이 모든 요청에는 일정량의 지연 시간이 있지만 일반적으로 쿼리가 길수록 지연 시간 (첫 번째 토큰까지의 시간)이 더 길어집니다.