제미니 2.0 프로

Prompt Engineering 구독자 190,000명

요약

이 영상은 구글의 최신 AI 모델 ‘제미니 2.0 프로’ 실험판에 대한 리뷰와 테스트를 담고 있다. 모델은 텍스트 외에도 이미지 생성, 음성 및 코드 실행 등 다양한 멀티모달 기능을 기본적으로 갖추고 있으며, 특히 복잡한 추론 및 문제 해결 능력이 돋보인다. 리뷰어는 파이썬, 자바스크립트, HTML을 활용한 코딩 테스트와 윤리 및 논리 퍼즐을 통해 모델의 성능과 프롬프트 엔지니어링의 중요성을 상세하게 보여줍니다. 또한 모델의 속도와 활용성에 대한 평가와 함께 실제 사용 전 직접 테스트해볼 것을 권장합니다.

주요 키워드

제미니 2.0 프로 멀티모달 코드 실행 프롬프트 엔지니어링 추론 트롤리 문제 몬티홀 러셀 역설 AI 모델 실험판

하이라이트

🚀 제미니 2.0 프로 실험판은 구글의 최신 멀티모달 AI 모델로, 이미지, 텍스트, 음성 등 다양한 입력을 처리하는 기능을 갖추고 있습니다.
⚡️ 코드 실행 기능이 탑재되어 API를 통해 파이썬 코드를 생성하고 실행하는 점은 다른 모델에서는 보기 드문 강점입니다.
🌟 프롬프트 엔지니어링을 통해 모델의 추론 능력이 크게 향상되는 사례를 다양한 논리 퍼즐과 코딩 테스트를 통해 보여줍니다.
📌 수정된 버전의 윤리적 딜레마(트롤리 문제), 몬티홀 문제, 러셀 역설 등 복잡한 문제들에서도 올바른 결론을 도출하는 모습을 확인할 수 있습니다.
🚀 모델은 방대한 토큰 컨텍스트(최대 2백만 토큰)와 구조화된 출력 지원 등 현재 업계에서 가장 긴 문맥을 처리할 수 있는 점이 인상적입니다.

용어 설명

제미니 2.0 프로 실험판

구글이 공개한 최신 실험용 멀티모달 AI 모델로, 다양한 입력 형식을 지원하고 코드 실행까지 가능한 강력한 기능을 탑재함.

멀티모달

텍스트, 이미지, 음성 등 여러 유형의 데이터를 동시에 처리하고 이해할 수 있는 기술을 의미함.

코드 실행 기능

모델이 생성한 파이썬 코드를 실제로 실행하여 결과를 반영하는 기능으로, 결과의 정확도 및 응용 가능성을 높임.

프롬프트 엔지니어링

시스템 메시지나 추가 지시를 통해 AI 모델의 응답 및 추론 능력을 개선하는 기법을 말함.

오류 유도(attention) 퍼즐

모델의 추론 한계를 테스트하기 위해 의도적으로 혼동을 주는 문제들로, 수정된 프롬프트를 통해 올바른 답변을 유도할 수 있음.

초반부에서는 제미니 2.0 프로 실험판이 발표된 배경과 모델의 기본 멀티모달 기능, 토큰 컨텍스트, 구조화된 출력 및 코드 실행과 같은 주요 특징들을 소개함.

[00:00] 구글이 Gemini 2.0 Pro 실험 버전을 발표했으며, 이는 멀티모달 기능을 갖춘 가장 강력한 모델입니다.

[00:24] 이 모델은 이미지 생성, 이미지 이해, 텍스트-음성 변환 등 다양한 기능을 지원하지만, 현재는 텍스트 출력만 가능합니다.

[01:44] 최대 200만 토큰의 컨텍스트 윈도우를 지원하며, 구조화된 출력과 코드 실행 기능도 포함되어 있습니다.

[02:27] 네이티브 함수 호출 기능이 있어 에이전트로 활용하기 적합하며, 구글 검색 통합으로 더욱 정확한 답변이 가능합니다.

[03:01] RTX GPU 사례를 통해 구글 검색 기능의 실제 활용 사례를 보여줍니다.

[03:25] GPT 모델의 학습 데이터와 검색 기능에 대해 설명하며, 이 모델이 추론 모델은 아니지만 시스템 프롬프트를 통해 추론 능력을 향상시킬 수 있다는 점을 강조합니다.

파이썬을 이용한 바운싱 볼 시뮬레이션, 자바스크립트로 구현한 낙하하는 문자 애니메이션, 그리고 HTML 페이지 생성 등 다양한 코딩 테스트를 수행하며 모델의 실시간 코드 생성 및 실행 능력을 검증함.

[04:11] 첫 번째 코딩 테스트로, 삼각형 안에서 빨간 공이 튀어다니는 파이썬 스크립트를 작성했습니다. 모델은 빠른 속도로 응답을 생성했지만, 공이 삼각형 밖으로 나가는 문제가 있었습니다.

[05:10] 두 번째 테스트에서는 JavaScript를 사용하여 물리 법칙을 적용한 떨어지는 글자 애니메이션을 구현했습니다. 화면 크기 조정, 충돌 감지 등 모든 요구사항을 성공적으로 충족시켰습니다.

[06:15] Claude 3 Opus와의 비교에서 Gemini 2.0 Pro는 외부 패키지 없이 단일 시도로 과제를 완수했으나, 구글의 복잡한 작명 방식은 개선이 필요하다고 지적했습니다.

[06:33] HTML 페이지 생성 테스트를 진행했습니다. 랜덤 농담을 표시하고, 배경색을 변경하며, 애니메이션을 추가하는 버튼 기능을 요구했고, LLM이 이를 성공적으로 구현했습니다.

[07:16] Strawberry의 'R' 개수 세기 문제를 통해 코드 실행 기능을 테스트했습니다. 처음에는 잘못된 답을 제시했지만, Python 코드 실행을 통해 정확한 결과(4개)를 도출하고 수정했습니다.

[08:05] Gemini의 코드 실행 기능은 현재 독보적이며, AI Studio와 API 모두에서 사용 가능한 강력한 도구입니다.

수정된 트롤리 문제와 같이 윤리적 딜레마 및 논리 퍼즐을 통해 모델이 프롬프트 엔지니어링의 도움을 받아 합리적인 추론결과를 도출하는 모습을 보여줌.

[08:24] 추론 능력 테스트를 위해 misguided attention 리포지토리의 사고 실험을 사용했습니다. 이는 기존 문제의 변형된 버전으로, 모델의 논리적 추론 능력을 평가합니다.

[09:03] 수정된 트롤리 문제를 통해 모델의 윤리적 추론을 테스트했습니다. 모델은 기존의 윤리적 프레임워크에 따라 응답했지만, 문제의 핵심 변경사항(이미 죽은 사람들)을 인지하지 못했습니다.

[09:46] 프롬프트 엔지니어링의 중요성을 설명하며, 질문을 먼저 읽고 분석한 후 답변하는 것의 필요성을 강조합니다.

[10:31] 트롤리 문제에서 5명이 이미 사망한 상황이므로, 레버를 당겨 추가 사망자를 만들 필요가 없다는 결론을 도출합니다.

[10:43] 수정된 몬티 홀 문제를 소개하며, 기존 문제와의 차이점과 확률적 결과의 변화를 설명합니다.

몬티홀 문제, 러셀 역설, 살아있는 고양이 실험, 물통 문제, 농부 퍼즐 등 복잡한 사고 실험을 통해 모델이 다양한 문제 조건 하에서 올바른 결론을 도출하는 과정을 상세히 검토함.

[12:02] 러셀의 역설의 수정된 버전을 분석하며, 이발사 규칙의 변화로 인한 논리적 차이를 설명합니다.

[12:51] 이발사 패러독스에서 '자신을 방문하는 것'은 이발사의 선택이므로 모순이 없다고 설명합니다.

[13:09] 슈뢰딩거의 고양이 사고실험 변형 문제에서 Gemini 2.0 Pro는 이미 죽은 고양이의 상태를 정확히 파악하고, 방사성 동위원소나 독약의 상태가 무관함을 설명했습니다.

[14:10] 6리터와 12리터 용기 문제에서 단순히 6리터 용기만으로 해결 가능함을 인식하고, 12리터 용기가 불필요함을 지적했습니다.

[14:45] 늑대, 염소, 양배추 문제에서 염소만 운반하면 된다는 단순한 해결책을 제시하고, 전체 해결책도 추가로 설명했습니다.

전반적인 테스트 결과와 모델의 장단점을 정리하며, 사용자가 직접 다양한 문제를 통해 모델 성능을 검증해볼 것을 권장하는 마무리 발언을 전달함.

[16:00] Gemini 2.0 Pro의 뛰어난 추론 능력을 평가하며, 약간의 지시만으로도 효과적인 문제 해결이 가능함을 강조했습니다.

[00:00] 지난 12월 구글이 Gemini 2.0을 발표했지만

[00:02] 지금까지는 기본 모델들만 사용할 수 있었습니다.

[00:06] 하지만 오늘, 드디어

[00:09] Gemini 2.0 Pro 실험 버전이 발표되었습니다.

[00:11] 이것은 그들의 가장 강력한 모델이며,

[00:14] 저는 운 좋게도

[00:16] 얼리 액세스를 받을 수 있었습니다. 이 영상에서는

[00:19] 제가 초기에 테스트해본 내용과

[00:22] 모델에 대한 생각을 공유하려고 합니다. 이 모델은

[00:24] 처음부터 멀티모달로 설계되어

[00:27] 이미지 생성과 이미지 이해 기능이

[00:30] 기본적으로 탑재되어 있습니다.

[00:32] 텍스트를 음성으로 변환할 수 있고 도구도 기본적으로

[00:35] 사용할 수 있지만, 이번 초기 출시에서는

[00:38] 텍스트 출력만 가능합니다.

[00:40] 비록 특별히 추론에 초점을 맞춘

[00:42] 모델은 아니지만, 제가 초기에 테스트해본 결과

[00:45] 추론 작업에서 정말 뛰어난 성능을 보여주었고

[00:48] 제가 본 모델 중 최고라고 할 수 있습니다.

[00:50] 다만 약간의 도움이 필요한 부분도 있습니다.

[00:54] 녹화 당시에는 벤치마크 결과에

[00:57] 접근할 수 없었지만, 최고 수준일 것으로

[01:00] 예상됩니다. 이제

[01:02] 모델의 성능과

[01:04] 제가 초기에 테스트한 내용을 보여드리겠습니다.

[01:08] 이 영상을 녹화할 당시

[01:11] 모델명은 Gemini 2.0 Pro Experimental

[01:14] 0205였습니다.

[01:18] 뒷부분의 숫자는 예상

[01:21] 출시일을 나타내며, 이름에서 알 수 있듯이

[01:24] 아직 실험 단계에 있는 모델입니다.

[01:27] Gemini 앱에서 이용 가능한

[01:29] Gemini 2.0 Flash는 이미

[01:32] 안정화된 버전이 있습니다.

[01:34] 따라서 곧 Pro 버전도

[01:37] 안정화된 버전이 나올 것으로 기대됩니다.

[01:40] 최대 200만 토큰의 컨텍스트 윈도우를 지원하는데

[01:44] 이는 상당히 큰 규모이며

[01:46] 현재 업계에서 가장 긴 수준입니다.

[01:49] 또한 구조화된 출력을

[01:51] 활성화하거나 비활성화할 수 있으며

[01:54] 코드 실행도 지원합니다.

[01:57] 기본적으로 API는 파이썬 코드를 생성하고

[02:01] API 뒤에서 실행할 수 있으며

[02:04] 응답을 생성할 때 그 결과를 활용할 수 있습니다.

[02:08] 이것은 현재

[02:10] Gemini API에만 있는 독점 기능입니다.

[02:13] 다른 제공업체에서는 보지 못했고

[02:15] 이것이 가장 좋은 기능 중 하나라고 생각합니다.

[02:18] 특히 근거 있는 답변을 원할 때 유용하며

[02:21] 현재 출력은 8,000 토큰으로 제한됩니다.

[02:27] 또한 네이티브 함수 호출이

[02:29] 가능하여

[02:30] 에이전트로 사용하기에

[02:32] 매우 적합합니다.

[02:33] 저는 이전에 다른 이름으로

[02:37] 같은 모델에 접근할 수 있었는데

[02:40] 당시에는 구글 검색과의 연동이

[02:42] 활성화되지 않았지만 이제는

[02:45] 구글 검색으로 답변의 근거를

[02:47] 찾을 수 있게 되었습니다. 이것은

[02:50] 구글 검색을 활성화하면

[02:53] 검색 결과를 사용하여

[02:56] 답변을 보강할 수 있다는 의미입니다. 예를 들어

[02:59] 구글 검색이 도움이 되는 경우를 보여드리겠습니다.

[03:01] 최신 RTX GPU의 VRAM에 대해 물어보았는데

[03:05] 이 경우 구글 검색을 통해 최신 RTX GPU가

[03:09] 50 시리즈라는 것을 파악하고

[03:11] 이전 세대인 40 시리즈와 비교했습니다.

[03:16] 검색어를 보시면

[03:19] 최신 RTX GPU와

[03:21] RTX 40 시리즈를 검색했음을 알 수 있습니다.

[03:25] 시리즈 VRAM 대 30 시리즈를 비교했는데,

[03:28] 이것은 학습 데이터에서 나온 것 같습니다.

[03:30] 이 검색어를 통해 가장 최신 정보를 얻었고,

[03:33] 이 두 가지 소스를 사용하여

[03:36] 최종 답변을 생성했습니다.

[03:39] 이것은 추론 모델이 아니기 때문에

[03:41] 이전 모델처럼 추론할 수는 없습니다.

[03:44] 다음으로 몇 가지 빠른 테스트를 보여드리겠습니다.

[03:45] 그리고 제가 발견한 놀라운 점 하나는

[03:49] 추론 모델이 아님에도 불구하고

[03:51] 시스템 프롬프트를 추가하면

[03:53] 추론 능력이 크게 향상된다는 것입니다.

[03:57] 나중에 몇 가지 예시를

[03:59] 영상에서 보여드리겠습니다.

[04:01] 이것은 또한 약간의 도움만으로

[04:04] 거의 모든 잘못된 주의 프롬프트를

[04:06] 해결할 수 있었던 첫 번째 모델입니다.

[04:08] 하지만 먼저 몇 가지 코딩 프롬프트를 살펴보겠습니다.

[04:11] 코딩 테스트를 시작해보겠습니다.

[04:13] 먼저 시도한 것은

[04:15] 빨간색 공이 삼각형 안에서 튀어다니는

[04:18] 파이썬 스크립트를 작성하는 것이었습니다.

[04:20] 공은 빨간색이어야 하고 삼각형 안에 있어야 하며

[04:23] 충돌 감지를 제대로 처리해야 하고

[04:25] 공이 삼각형 안에 머물도록 해야 합니다.

[04:28] 이것은 현재

[04:30] X와 Reddit에서 바이럴한 프롬프트입니다.

[04:33] Gemini 2.0 Pro 실험 버전의 생성 속도는

[04:37] 매우 뛰어납니다.

[04:39] 응답을 생성하는 속도를 보시면

[04:43] 약 32,100개의 토큰을

[04:46] 24초 만에 생성했습니다.

[04:49] 결과는 흥미롭습니다.

[04:53] 공이 삼각형 안에서 머무는 것을 볼 수 있지만

[04:56] 시간이 지나면

[04:58] 삼각형 밖으로 나가버립니다.

[05:01] 이는 많은 모델들이

[05:03] 이 특정 테스트에서 보이는 문제입니다.

[05:06] 다음 테스트로

[05:07] JavaScript를 사용하여

[05:10] 실제 물리 법칙을 적용한

[05:12] 떨어지는 글자 애니메이션을 만들어보았습니다.

[05:15] 이전보다 훨씬 더 복잡한 시나리오입니다.

[05:17] 글자들이 상단에서 무작위로 나타나야 하고

[05:19] 지구 중력의 영향을 받아 떨어져야 하며

[05:22] 충돌 감지가 있어야 합니다.

[05:24] 바닥, 화면 경계,

[05:27] 다른 글자들과의 상호작용이 있어야 하고

[05:29] 화면 크기 변화에

[05:30] 동적으로 적응해야 하며

[05:34] 배경은 검정색이어야 합니다.

[05:36] 여기 생성된 코드를 보시면

[05:38] 결과가 꽤 좋습니다.

[05:41] 글자들이 무작위 순서로 떨어지고

[05:43] 바닥과 다른 글자들과

[05:45] 상호작용하는 것처럼 보입니다.

[05:48] 화면을 조정하면

[05:50] 실제로 동적으로 조정되는 것을

[05:52] 확인할 수 있습니다.

[05:57] 모든 요구사항이 충족된 것 같습니다.

[06:00] 무작위로 글자가 떨어지고

[06:02] 바닥, 다른 글자들,

[06:04] 그리고 화면 경계와

[06:06] 상호작용하고 있습니다.

[06:08] 같은 프롬프트로 Claude 3 Opus를

[06:10] 고성능으로 테스트했지만

[06:12] 실행하지 못했고

[06:15] 외부 패키지를 많이 사용했습니다.

[06:18] 하지만 Gemini 2.0 Pro 실험 버전은

[06:21] 한 번에 이것을 해낼 수 있었습니다.

[06:24] 다만 구글이 이런 작명 방식을

[06:26] 개선할 필요가 있다고 생각합니다.

[06:29] 다음 프로그래밍 테스트는

[06:31] HTML 페이지를 만드는 것이었습니다.

[06:33] HTML 페이지를 만들어달라고 요청했는데

[06:36] 버튼이 있어야 하고

[06:38] 페이지에 랜덤한 농담을 표시하고

[06:41] 배경색을 임의로 변경하며

[06:43] 랜덤 애니메이션도 추가해야 했습니다.

[06:46] 이는 LLM에게는 상당히 간단한 작업이었고

[06:49] 아무 문제없이 이를 수행할 수 있었습니다.

[06:52] 그래서 이것이 그 특정 작업의

[06:55] 출력 결과입니다.

[06:57] 실행 버튼을 클릭하면

[07:00] 랜덤한 농담이 표시됩니다. 저는 이것이

[07:04] 딥 리서치와 같은 것에 포함되면 좋겠습니다.

[07:06] 특히 다음 섹션에서 보시게 될

[07:09] 사고나 추론 버전이 있다면 더욱 좋겠죠.

[07:11] 약간의 프롬프팅만으로도

[07:14] 정말 좋은 추론을 할 수 있습니다.

[07:16] 이제 LLM에게 'Strawberry'에 있는 'R'의 개수를 세도록 하면

[07:19] 아마도 3개라고 답할 것입니다.

[07:21] 하지만 제가 'R'을 하나 더 추가했고

[07:23] 그럼에도 원래 철자로 돌아가서

[07:26] 오타가 있었음에도

[07:29] 여전히 원래 철자로 되돌아갔습니다.

[07:31] 실제로는 답이 틀렸지만

[07:34] 제가 필요한 경우 코드를 사용하도록 했고

[07:37] 코드 실행을 활성화했습니다.

[07:40] Gemini 모델들은 API 뒤에서

[07:43] Python 인터프리터를 사용할 수 있기 때문입니다.

[07:46] 이 경우에는 Python 코드를 작성하고

[07:48] 실행하기로 결정했고, 코드 실행 결과

[07:51] 값이 4가 나왔습니다. 이제

[07:54] 올바른 철자를 사용하면서

[07:57] '죄송합니다. 코드 도구가 정확하게'

[08:00] 'Strawberry에 R이 4개 있다고 계산했습니다.'

[08:03] '이전에는 이를 놓쳤네요.'

[08:05] 코드 실행은

[08:08] 현재 Gemini에서만 사용 가능한

[08:10] 매우 강력한 기능입니다. 다른

[08:13] 모델 제공업체들도

[08:15] 이와 같은 것을 구현했으면 좋겠습니다.

[08:18] AI Studio 내에서뿐만 아니라

[08:21] API를 통해서도 사용할 수 있습니다.

[08:24] 다음으로 Gemini 2.0 Pro의

[08:25] 추론 능력을 테스트해보고 싶습니다.

[08:30] misguided attention 리포지토리를

[08:31] 사용할 건데요, 이전 영상을 보지 않으신 분들을 위해 설명하자면

[08:34] 이것들은 일반적으로 알려진 사고 실험이나

[08:37] 함정 문제입니다.

[08:39] 유일한 차이점은

[08:41] 단어 표현에 약간의 변형이 있어

[08:43] 의미가 실제로 변경된다는 점입니다.

[08:46] 모델이 충분히 똑똑하다면

[08:48] 논리적 추론을 사용하여

[08:51] 답을 도출할 것입니다. 하지만

[08:54] 제가 테스트한 많은 LLM들은

[08:56] 수정되지 않은 원래 문제로

[08:58] 돌아갈 것입니다. 왜냐하면

[09:00] 학습 데이터에서 많이 봤기 때문이죠.

[09:03] 첫 번째는

[09:04] 트롤리 문제의 수정된 버전입니다.

[09:06] 이 경우에는 5명이 이미 죽어있고

[09:08] temperature를 1로 설정했습니다.

[09:11] 모델이 창의적인 자유를 가질 수 있도록요.

[09:14] 어떤 답이 나오는지 봅시다.

[09:17] 모델은 '이것은 고전적인 트롤리 문제의 공식입니다.'

[09:19] 윤리적 사고 실험으로

[09:21] 서로 다른 도덕적 원칙들 간의 충돌을 탐구하기 위해 설계되었고

[09:24] 하나의 정답이나 최선의 답은 없다고 합니다.

[09:26] 다른 LLM들처럼

[09:29] 서로 다른 프레임워크에서 관점을 제시하지만

[09:33] 사람들이 이미 죽어있다는 사실을

[09:35] 인지하지 못했습니다.

[09:37] 하지만 매우 간단한 프롬프트로

[09:40] 이를 수정할 수 있습니다.

[09:44] 사용자의 질문을 잘 읽어보라고 요청했습니다.

[09:46] 질문을 있는 그대로 읽고 출력한 다음

[09:49] 답변을 생성하면서 주의 깊게

[09:52] 살펴보세요. 보이는 것과 다를 수 있습니다.

[09:54] 동일한 프롬프트와

[09:57] 이 작은 시스템 메시지를 추가하니

[10:01] 다시 한번 동일한 다른

[10:04] 원칙들을 제시하지만 마지막에

[10:06] 질문에서 언급된 사람들에 대해

[10:08] 다섯 명은 이미 사망했고

[10:11] 한 명은 살아있다고 합니다. 따라서

[10:13] 레버를 당기면 한 사람이 죽고

[10:16] 레버를 당기지 않아도 아무도 구할 수 없으므로

[10:18] 레버를 당기지 말아야 합니다.

[10:20] 결론적으로 다섯 명이

[10:23] 이미 사망했기 때문에

[10:25] 레버를 당기는 것은 이점이 없고

[10:27] 한 사람의 죽음을 초래할 것이므로

[10:29] 레버를 당기지 말아야 합니다.

[10:31] 이처럼 이렇게 큰 모델도

[10:33] 약간의 방향 설정과 프롬프트 엔지니어링이

[10:36] 필요할 수 있습니다. 저는

[10:39] 다른 역설들에서도 프롬프트 엔지니어링의

[10:42] 유사한 효과 패턴을 봤습니다.

[10:43] 예를 들어, 여기 수정된

[10:46] 몬티 홀 문제 버전이 있는데

[10:49] 주요 차이점은 이 경우

[10:52] 문을 선택할 때, 예를 들어

[10:54] 1번 문을 고르면 몬티가

[10:56] 같은 문을 열고, 당신이 다른 문을 고른 후

[10:59] 몬티가 당신에게

[11:02] 그 문을 바꿀 기회를 줍니다.

[11:04] 원래 설정에서는

[11:06] 문을 바꾸면 자동차를 얻을 확률이 2/3라고 합니다.

[11:09] 기존의 몬티 홀 문제를

[11:12] 보면 그렇죠.

[11:14] Gemini 2.0 Pro는 실제로

[11:17] 원래 문제와 같은 논리로

[11:20] 접근해서 원래 몬티 홀 문제에서의

[11:22] 동일한 확률을 제시합니다.

[11:25] 원래 문제에서는 바꾸는 것이

[11:27] 실제로 더 좋지만, 이 설정에서는

[11:29] 아무런 차이가 없습니다.

[11:32] 이 간단한 시스템 프롬프트로

[11:34] 사고 과정이 완전히 달라지고

[11:36] 올바른 결론에 도달하는 것을 볼 수 있습니다.

[11:39] 이렇게 설정이 바뀌었기 때문에

[11:41] 제시된 문제는 이제 50/50이 되었고

[11:42] 2번 문으로 바꾸거나 3번 문을 고수하는 것이

[11:46] 중요하지 않다고 합니다.

[11:48] 2번 문으로 바꾸거나

[11:50] 3번 문을 유지하는 것 같이

[11:52] 프롬프트 엔지니어링이나 시스템 프롬프트가

[11:55] Gemini 2.0 Pro에

[11:57] 영향을 미치는 것으로 보입니다. 다른

[12:00] 예시들도 빠르게 살펴보겠습니다. 여기

[12:02] 러셀의 역설의 수정된 버전이 있는데

[12:05] 주요 차이점은 이발사가 가진

[12:07] 간단한 규칙입니다.

[12:09] 그를 방문하는 마을의 모든 남자의

[12:12] 면도를 해준다는 것인데, 시스템 프롬프트 없이는

[12:15] 원래 버전으로 돌아가서

[12:18] 스스로 면도하지 않는 마을의 모든 남자의

[12:21] 면도를 해준다는 규칙을 선택합니다.

[12:23] 이 규칙을 기반으로

[12:24] 답변할 수 있습니다. 이 경우

[12:27] 역설이나 원래 질문을 출력한 후

[12:31] 이것은 약간 수정된

[12:32] 고전적인 러셀의 역설의 결함이 있는 버전이며

[12:35] 이는 집합론의 러셀 역설의

[12:38] 수정된 버전이라고 합니다.

[12:40] 원래의 역설은

[12:42] 모순을 제시하지만

[12:43] 이것은 그렇지 않습니다. 프롬프트를 검토해보면

[12:46] 이발사가 모든 사람의 면도를 해준다는 것을

[12:48] 정확히 인식하고 있습니다.

[12:51] 그가 방문하는 모든 남성을 면도한다는 이 표현은

[12:53] 모순이 없습니다. 왜냐하면 이는

[12:56] 이발사가 자신을 방문하기로 한 선택이기 때문입니다

[12:58] 따라서 이발사가 자신을 면도한다면

[13:01] 그는 자신을 방문한 남성이며 규칙 안에 포함됩니다

[13:04] 그리고 이어서 설명하기를

[13:07] 만약 우리가 고전적인 패러독스인

[13:09] 상자 속 죽은 고양이 문제를 다룬다면, 이는

[13:12] 슈뢰딩거의 고양이 사고실험을 변형한 것인데

[13:14] 실제로 Gemini 2.0 Pro는

[13:20] 고양이가 이미 죽어있다는 것을 파악했고

[13:23] 따라서 다음날 상자를 열었을 때

[13:25] 고양이가 살아있을 확률이

[13:28] 0이 될 것이라고 했습니다

[13:29] 이 시스템 프롬프트로

[13:31] 다시 한 번 고양이가 이미 죽어있다는 것을 인식하고

[13:34] 고양이가 상자에 들어갈 때 이미 죽어있기 때문에

[13:36] 방사성 동위원소의 상태나

[13:38] 독약, 그리고 검출기는

[13:41] 완전히 무관하며

[13:42] 고양이의 상태는 이미 결정되어 있다고 설명합니다

[13:45] 그런 다음 원래의 슈뢰딩거의 고양이

[13:47] 사고실험에 대해 이야기합니다

[13:50] 보시다시피

[13:52] 작은 힌트만으로도 문구에 더 많은 주의를 기울일 수 있고

[13:55] 한 번에 변형이나 수정사항을

[13:58] 파악할 수 있으며

[14:01] 그것이 최종 결과에 어떤 영향을 미치는지

[14:04] 이해할 수 있습니다

[14:08] 다른 예시로

[14:10] 6리터와 12리터 용기가 있고

[14:13] 정확히 6리터를 측정하고 싶다는 문제가 있습니다

[14:16] 이 수정된 버전 또는

[14:18] 추가 시스템 프롬프트를 통해 기본적으로

[14:21] 우리가 찾는 답을 알려주지만

[14:23] 수정되지 않은 버전에서는

[14:25] 12리터 용기를 완전히 채운 다음

[14:28] 6리터 용기에 가득 찰 때까지 부어야 한다고 합니다

[14:30] 이 경우 시스템 프롬프트를 통해

[14:34] 6리터 용기를 사용하면

[14:36] 정확한 양의 물이 남게 되며

[14:39] 12리터 용기는 완전히 불필요하다고 설명합니다

[14:41] 늑대, 염소, 양배추가 있는 농부 문제에서

[14:45] 우리는 염소만

[14:48] 반대편으로 옮기는 것에

[14:49] 관심이 있는데

[14:53] Gemini 2.0 Pro는 다시 한 번

[14:57] 복잡한 단계들을 제시합니다

[14:59] 염소를 데려가고 혼자 돌아온 다음

[15:01] 늑대나 양배추 중 선택해야 하지만

[15:04] 문제는 우리가 나머지 단계에는

[15:06] 전혀 관심이 없고

[15:09] 단지 염소만 운반하기를 원한다는 것입니다

[15:10] 하지만 추가 시스템 프롬프트를 통해

[15:13] 이것이 고전적인 늑대, 염소, 양배추의

[15:15] 강 건너기 퍼즐이지만

[15:18] 주어진 질문은 매우 간단하며

[15:20] 염소에만 초점을 맞추면 됩니다

[15:23] 전체 문제는 셋 모두를 건너게 하는 것이지만

[15:26] 구체적인 질문에 답하고

[15:28] 맥락을 위해 전체 해결책을 설명하겠습니다

[15:30] 이 특정 질문에 대한 답은

[15:33] 농부는 단순히 첫 번째 여행에서

[15:35] 염소를 강 건너편으로 데려가면 됩니다

[15:37] 농부는 염소만 안전하게

[15:40] 운반하라는 요구사항을 받았고

[15:42] 다른 것은 불필요하므로

[15:44] 이것으로 요구사항이 충족됩니다

[15:47] 정말 똑똑하네요. 다른 어떤 모델도

[15:50] 이런 답변을 해주는 것을 본 적이 없습니다

[15:53] 그리고 나서 원래 문제를

[15:55] 해결하려는 경우를 위해

[15:58] 전체 해결책을 제시합니다

[16:00] 이는 제가 본 모델 중

[16:03] 잘못된 주의력 문제에서

[16:05] 가장 인상적인 모델 중 하나이며

[16:08] 약간의 지시만 있으면 실질적으로

[16:11] 해결할 수 있다는 점이 놀랍습니다

[16:14] 만약 구글이 Gemini 2.0 Pro의

[16:16] 사고 버전을 만든다면

[16:19] 아마도 이러한 잘못된 주의력 문제를

[16:22] 기본적으로 해결할 수 있을 것 같습니다

[16:24] 하지만 저는 이 모델이

[16:26] 약간의 도움만으로도 추론을 잘 한다는 점이

[16:28] 인상적이라고 생각합니다

[16:31] 아직 벤치마크는 보지 못했지만

[16:33] 항상 제가 권장하듯이

[16:36] 이 모델이 좋은지 결정하기 전에

[16:38] 직접 문제를 테스트해보시기 바랍니다

[16:41] 여러분의 테스트 결과는

[16:43] 제가 여기서 본 것과 매우 다를 수 있지만

[16:46] 제가 빠르게 실험해본 결과

[16:49] 코딩 측면에서는

[16:51] Flash 2.0 Thinking이

[16:54] 더 나은 모델일 수 있다고 생각합니다

[16:57] 하지만 이는 2-3가지 테스트를 기반으로 한 것이며

[17:00] 추론 능력 면에서는

[17:02] 이 모델이 약간의 도움만 있다면

[17:04] 훨씬 더 나은 것 같습니다

[17:07] 하지만 더 큰 모델이기 때문에

[17:10] 속도가 많이 느리고

[17:14] 대부분의 경우 이런 좋은 모델을

[17:16] 계획 작업에 사용하고

[17:19] Flash와 같은 더 빠른 모델을

[17:22] 작업을 하위 작업으로 나누고 실행하는 데

[17:25] 조합해서 사용하고 싶을 것입니다

[17:28] 어쨌든 여러분의 생각을 들려주시고

[17:30] 이 영상이 도움이 되길 바랍니다

[17:32] 시청해주셔서 감사하며 다음 영상에서

[17:34] 만나뵙겠습니다