섬
섬세한 갈색 바람
Category
Empty
GPT base 에서 지시문이 앞에 와야 한다는 건 이해가 되긴 하는데,Gemini 구조에서는 왜 뒤쪽에 오는 게 좋은지 이해가 되지 않습니다. Transformer 형태라면 어쨌든 인코더, 디코더를 다 쓰니 괜찮지 않나요? gemini 기반이 뭔지 몰라서 문의드립니다. :)
3
Sujin_Kang
섬세한 갈색 바람 안녕하세요 ~바람님.
Gemini 역시 기본적으로는 GPT와 같은 '디코더 전용(Decoder-only)' 아키텍처를 기반으로 합니다. 즉, 인코더-디코더를 다 쓰는 게 아니라, 앞서 나온 토큰이 뒤에 나올 토큰에 영향을 주는 인과적 자기주의(Causal Attention) 방식을 사용하죠.
그럼에도 왜 Gemini(특히 긴 문맥을 다룰 때)에서 지시문을 뒤에 두는 것이 유리할 수 있는지, 그 기술적 배경을 짚어드릴게요.
어
어두운 베이지 산들바람
지금 말씀하시는, Gemini의 내용은 gemini 서비스에 대한 내용인건가요? 엔진에 대한 이야기인건가요?
API로서 활용할때 알아둬야할 지식인지 궁금합니다!
Sujin_Kang
아키텍처의 오해: Gemini도 '디코더 전용'입니다
모델은 모든 입력 토큰 간의 관계를 계산합니다. 하지만 실제 추론 시에는 '마지막에 입력된 정보'가 생성될 첫 번째 토큰과 물리적으로 가장 가깝고, 어텐션 메커니즘 상에서 강한 신호를 남기는 경향이 있습니다.
Lost in the Middle 현상과 최신성 편향
Gemini의 강점은 수백만 토큰에 달하는 압도적인 컨텍스트 창(Context Window)입니다. 하지만 모델도 '집중력'의 한계가 있습니다.
정보의 유실: 논문 'Lost in the Middle'(1회차때 소개드린)에 따르면, 모델은 입력값의 맨 앞과 맨 뒤 정보를 가장 잘 기억하고 중간 정보는 쉽게 놓칩니다.
지시문의 명확성: 방대한 양의 데이터(예: 수십 페이지의 문서)를 먼저 던져주고 마지막에 "위 내용을 요약해"라고 명령하면, 모델은 방금 읽은 데이터의 잔상을 유지한 채 바로 작업에 착수할 수 있습니다. 반대로 지시문이 맨 앞에 있으면, 긴 데이터를 읽는 동안 지시문의 세부 사항이 '희석'될 가능성이 생깁니다.
구조적 이유와 인지적 이유로 gemini-based model 프롬프트를 설명드렸습니다. 단, 보편적인 것이 모든 task 에 적용은 되지 않음을 생각해주시면 좋겠습니다.
See latest comments