프롬프트 엔지니어링 가이드 - 입문부터 고급까지

Matthew Berman 구독자 419,000명

요약

이 영상은 Google이 제시한 프롬프트 엔지니어링 가이드를 토대로 LLM의 작동 원리와 최적화 기법을 입문부터 고급 단계까지 체계적으로 설명한다. 토큰 예측 기반 모델의 출력 길이·샘플링 설정(온도, Top-K, Top-P)부터 Zero/Few-shot, 시스템·맥락·역할 프롬프트, Chain of Thought, Self-Consistency 등 다양한 전략을 사례와 함께 다룬다. REACT 프레임워크, Tree of Thoughts, 자동 프롬프트 엔지니어링, 코드 활용 기법 등 최신 기법도 소개하여 실무에 바로 적용 가능한 팁을 제공한다. 마지막으로 예시 제공, 간결 설계, 출력 명시, 변수 사용 등 모범 사례를 정리하며 최적의 프롬프트 작성법을 제안한다.

주요 키워드

Prompt Engineering Large Language Model(LLM) Token Output Length Temperature Top-K Top-P Zero-shot Chain of Thought Self-Consistency

하이라이트

🔑 프롬프트 엔지니어링은 AI 모델에 입력 구조, 예시, 단어 선택 등을 최적화해 원하는 결과를 얻는 기술이다.
⚡ 토큰(token) 기반 예측 모델인 LLM의 출력 길이 설정은 응답 분량뿐 아니라 비용과 속도에도 큰 영향을 준다.
🌡️ 온도(temperature), Top-K, Top-P 설정으로 모델의 창의성과 일관성을 조절할 수 있다.
📝 Zero/Few-shot 기법은 예시 수에 따라 프롬프트를 구성해 모델의 특정 패턴 학습을 돕는다.
🎭 시스템·맥락·역할 프롬프트로 전역 목적, 배경 정보, 캐릭터 역할을 제공해 응답 퀄리티를 높인다.
🔄 ‘Think step by step’ 체인 오브 소트로 논리·수학 문제를 단계별로 풀어 더 정확한 답변을 얻는다.
🗳️ Self-Consistency는 동일 프롬프트를 반복 실행하고 다수결을 통해 일관성 높은 결과를 선별한다.
🌳 Tree of Thoughts는 여러 추론 경로를 동시에 탐색해 최적 경로를 선택하는 고급 기법이다.
🤖 REACT framework는 추론 후 외부 도구를 활용해 에이전트 방식으로 복잡한 작업을 자동화한다.

용어 설명

Prompt Engineering

AI 대형 언어 모델에 최적의 입력(prompt)을 설계해 원하는 출력을 얻는 기술

LLM

Large Language Model(대형 언어 모델). 방대한 텍스트를 학습해 다음 토큰을 예측하는 AI 모델

Token

LLM이 처리하는 기본 단위. 보통 단어의 3/4 정도 분량의 문자열 조각이다

Output Length

모델이 응답으로 생성할 최대 토큰 수. 비용·속도와 직접 연관된다

Sampling Controls

모델이 다음 토큰을 선택하는 확률적 제어 매개변수(온도, Top-K, Top-P 등)

Zero-shot

예시 없이 작업 설명만으로 모델에게 지시하는 기본 프롬프트 방식

Few-shot

하나(one-shot) 또는 여러 예시(few-shot)를 제공해 모델이 원하는 형식·패턴을 학습하도록 하는 기법

Chain of Thought

모델에게 단계별 추론 과정을 출력하도록 유도해 복잡한 문제 해결 정확도를 높이는 기법

Self-Consistency

동일 프롬프트를 여러 차례 실행하고 다수결로 가장 일관된 답변을 선택하는 방법

REACT

Reason+Act. 모델이 추론 후 외부 도구(검색, 코드 실행 등)를 활용해 에이전트 형태로 동작하게 하는 프레임워크

프롬프트 엔지니어링이란 무엇인지 정의하고, LLM이 입력 토큰을 예측해 응답을 생성하는 작동 방식을 소개한다. 기본 개념과 중요성을 설명한다.

[00:00] 프롬프트 엔지니어링의 정의와 기본 개념을 소개합니다. 인공지능을 최대한 활용하기 위한 전략 모음으로, Google에서 제작한 가이드를 통해 프롬프트 엔지니어링의 달인이 되는 방법을 설명합니다.

[00:20] ChatGPT, Gemini, Claude 같은 AI 모델과의 상호작용 방식을 설명합니다. 자연어 입력에 대해 자연어 출력을 받는 기본 원리와 프롬프트의 중요성을 강조합니다.

[01:04] LLM의 작동 원리를 자세히 설명합니다. 예측 엔진으로서 순차적 텍스트를 받아 토큰을 예측하는 방식과, 토큰의 개념을 이해하기 쉽게 설명합니다.

[01:43] 프롬프트 엔지니어링의 정의와 실제 경험을 통한 이해를 제공합니다. 원하지 않는 결과를 얻었다가 프롬프트를 수정하여 원하는 결과를 얻는 과정이 바로 프롬프트 엔지니어링임을 설명합니다.

출력 길이(output length) 설정의 의미를 설명하고, 토큰 제한이 응답 분량·비용·속도에 미치는 영향을 예시와 함께 보여준다.

[02:09] 각 언어 모델의 차이점과 설정의 중요성을 강조합니다. 모델마다 다른 특성을 가지고 있어 올바른 설정이 프롬프트 활용도를 높인다고 설명합니다.

[02:25] 출력 길이 설정의 개념과 중요성을 설명합니다. 간단한 질문과 복잡한 코드 요청의 차이를 통해 출력 길이가 어떻게 결과에 영향을 미치는지 보여줍니다.

[02:50] 토큰 출력량과 비용의 관계를 설명하며, 출력 길이 제한이 단순히 토큰 생성을 중단시킬 뿐 내용을 더 간결하게 만들지는 않는다는 중요한 차이점을 강조합니다.

Temperature(온도), Top-K, Top-P 등 샘플링 컨트롤의 작동 원리와 창의성·일관성 조절 방법을 사례와 함께 제시한다.

[03:27] Google AI Studio를 통해 실제 예시를 보여주며, 5토큰과 50토큰으로 제한했을 때 판다 이야기가 어떻게 중간에 끊어지는지 시연합니다.

[04:21] 샘플링 제어의 개념을 소개하고, LLM이 단일 토큰을 예측하는 것이 아니라 모든 토큰에 대한 확률을 계산한다는 작동 원리를 설명합니다.

[04:58] 온도, Top K, Top P 세 가지 주요 샘플링 제어 설정을 소개하고, 특히 온도가 가장 중요한 설정이라고 강조합니다.

[05:08] 온도 설정의 작동 방식을 설명하며, 온도가 높을수록 창의적이고 온도가 낮을수록 덜 창의적인 응답을 생성한다는 원리를 실제 예시로 보여줍니다.

[05:48] 온도를 0으로 설정했을 때의 실험 결과를 보여주며, 같은 프롬프트로 판다곰 이야기를 생성했을 때 매우 유사한 결과가 나오는 것을 확인했습니다. 온도가 높으면 다양한 응답이, 낮으면 일관성 있는 응답이 나온다고 설명합니다.

[06:30] top K와 top P 설정에 대해 설명하며, 개인적으로는 온도 설정만 사용한다고 언급합니다. top K는 상위 K개 토큰을 선택하는 방식이고, top P는 누적 확률 기반으로 어휘를 제한하는 방식이라고 간단히 소개합니다.

[07:20] 권장 시작 설정값으로 온도 0.2, top P 0.95, top K 30을 제시하며, 창의성과 일관성의 균형을 맞출 수 있다고 설명합니다. 더 창의적인 결과를 원하면 값을 높이고, 더 일관적인 결과를 원하면 낮추라고 조언합니다.

예시를 전혀 주지 않는 zero-shot, 단일 예시를 주는 one-shot, 다중 예시(few-shot) 프롬프트 전략과 활용 시나리오를 설명한다.

[07:56] 본격적인 프롬프팅 기법 설명의 시작으로, 제로샷(zero shot) 프롬프팅을 소개합니다. 제로샷은 모델에게 예제를 전혀 주지 않고 과제 설명만 제공하는 가장 간단한 프롬프팅 방식이라고 설명합니다.

[08:27] 제로샷 프롬프팅의 개념을 설명하면서, 이는 단순히 달성하고자 하는 작업에 대한 철저한 설명만 제공하는 것이라고 합니다. 소설 쓰기나 수학 문제 풀이 같은 간단한 작업은 많은 예시가 필요하지 않다고 설명합니다.

[08:51] 제로샷 프롬프트의 실제 예시를 보여줍니다. 영화 리뷰를 긍정적, 중립적, 부정적으로 분류하는 작업에서 AI 관련 영화 리뷰를 제시하고, 모델이 정확히 감정을 분류했다고 설명합니다.

[09:20] 원샷과 퓨샷 프롬프팅을 소개합니다. 원샷은 하나의 예시를 제공하여 모델이 이를 모방하게 하고, 퓨샷은 두 개 이상의 예시로 모델이 원하는 패턴을 더 정확히 파악할 기회를 제공한다고 설명합니다.

[09:48] 퓨샷 프롬프팅에 필요한 예시 수는 작업의 복잡성, 예시의 품질, 사용하는 AI 모델의 능력에 따라 달라진다고 설명합니다. 일반적으로 3-5개의 예시를 사용할 것을 권장합니다.

System 메시지로 전역 목적, Contextual prompting으로 배경 정보, Role prompting으로 특정 역할을 부여해 응답 품질을 높이는 방법을 안내한다.

[10:11] 피자 주문을 JSON으로 파싱하는 구체적인 예시를 제시합니다. 예시 없이 프롬프트만 제공하면 모델이 다양한 JSON 구조를 생성할 수 있지만, 명확한 예시를 제공하면 일관된 구조(크기, 타입, 재료 배열)를 얻을 수 있다고 설명합니다.

[11:16] 퓨샷 프롬프팅에서 모델 출력을 요청하는 방법에 대해 설명하며, 크기, 종류, 재료 등의 구조화된 정보를 예시와 동일하게 사용하는 것이 효과적임을 보여줍니다.

[11:29] 시스템 메시지, 컨텍스트 프롬프팅, 역할 프롬프팅의 개념을 소개하며, 이들의 핵심은 모델이 특정 역할(시니어 개발자, CEO, 선생님 등)을 수행하도록 하는 것임을 설명합니다.

[11:55] 시스템 프롬프팅이 언어 모델의 전반적인 맥락과 목적을 설정하는 방법을 설명하고, Google AI Studio의 시스템 지시사항 기능을 예시로 제시합니다.

[12:24] 컨텍스트 프롬프팅의 정의와 작동 방식을 설명하며, 레트로 80년대 아케이드 게임 블로그 작성 예시를 통해 맥락과 실제 작업을 분리하는 방법을 보여줍니다.

먼저 일반적 질문으로 배경지식을 활성화한 뒤, 이를 바탕으로 본문 프롬프트를 수행해 더 풍부하고 정확한 결과를 유도하는 기법을 설명한다.

[13:14] 역할 프롬프팅의 개념과 효과를 설명하고, Crew AI 프레임워크에서의 실제 적용 사례를 소개하며, 에이전트 정의에서 역할, 목표, 배경 스토리 등의 속성 활용법을 제시합니다.

[14:07] 역할 프롬프팅의 강력함을 보여주는 여행 가이드 역할 예시를 설명합니다. 암스테르담 박물관 추천 요청에 대해 모델이 적절한 역할을 수행하여 맞춤형 답변을 제공하는 과정을 보여줍니다.

‘Think step by step’으로 모델이 추론 과정을 단계별로 표현하도록 유도해, 복잡한 논리·수학 문제 해결 정확도를 크게 향상시키는 방법을 소개한다.

[14:40] 스텝백 프롬프팅이라는 새로운 기법을 소개합니다. 이 방법은 특정 작업 전에 먼저 일반적인 질문을 고려하게 하여 모델이 관련 배경 지식과 추론 과정을 활성화하도록 돕는 기법입니다.

[15:37] 스텝백 프롬프팅의 실제 비교 예시를 시작합니다. 1인칭 슈팅 게임의 스토리라인 작성 요청에 대해 일반적인 프롬프팅과 스텝백 프롬프팅의 차이를 보여주기 위해 먼저 기본 프롬프트를 실행합니다.

[16:15] 창의적 글쓰기에서 모델이 일반적인 응답을 주는 한계를 언급하고, 스텝백 방법을 시도합니다. 실제 작업 전에 1인칭 슈팅 게임의 핵심 설정에 대한 일반적인 질문을 먼저 던져 더 나은 결과를 얻고자 합니다.

[16:47] 이전 단계에서 얻은 5가지 허구의 핵심 설정들을 복사하여 새로운 프롬프트의 맥락으로 활용하고, 1인칭 슈팅 게임의 새로운 레벨을 위한 도전적이고 흥미로운 스토리라인을 요청하는 과정을 보여줍니다.

[17:05] AI가 생성한 우주 정거장 배경의 1인칭 슈팅 게임 스토리라인 예시를 소개하며, 이러한 방식이 대형 언어 모델에서 더 정확하고 폭넓은 지식을 얻는 좋은 방법임을 설명합니다.

[17:21] 대형 언어 모델을 완전히 바꾼 핵심 프롬프팅 기법인 체인 오브 소트(Chain of Thought)를 소개하며, 현재 많은 모델에 내장된 테스트 타임 컴퓨트와 추론 시간 컴퓨트의 개념을 설명합니다.

동일 프롬프트를 여러 차례 실행하고 다수결로 최종 답을 선택하는 self-consistency 기법을 통해 응답의 일관성과 정확성을 높이는 방식을 다룬다.

[17:47] 과거에는 프롬프트에 '단계별로 생각하고 작업을 보여달라'는 간단한 문구를 추가하는 것만으로도 훨씬 더 정확하고 고품질의 출력을 얻을 수 있었던 체인 오브 소트 기법의 효과를 설명합니다.

[18:31] 작은 모델이나 사고 모드가 없는 모델에서는 여전히 체인 오브 소트가 강력한 프롬프팅 방법이며, 최신 모델들은 사고 모델이 아니더라도 기본적으로 이런 방식으로 작동한다고 설명합니다.

[18:40] Gemini 2.0 Flash Light를 사용한 실제 예시를 통해 나이 계산 문제를 제시하고, 모델이 자동으로 단계별 사고 과정을 보여주며 정확한 답(26세)을 도출하는 과정을 보여줍니다.

[19:07] 문서의 다른 예시와 비교하며, 단계별 사고 과정 없이는 잘못된 답(63세)을 얻었지만 '단계별로 생각해달라'고 요청했을 때는 올바른 답을 얻을 수 있었음을 설명합니다.

[19:22] 작은 모델이나 오래된 모델도 추론 속도나 비용 등의 특정 사용 사례에서는 여전히 가치가 있으며, 올바른 모델 선택 시 고려해야 할 다양한 요소들이 있음을 강조합니다.

[19:42] 프롬프팅 전략을 통해 작은 모델에서도 뛰어난 성능을 얻을 수 있으며, 원샷/퓨샷 프롬프트와 체인 오브 쏘트를 결합하는 등 다양한 기법을 조합할 수 있습니다.

[19:55] 나이 계산 문제를 예시로 체인 오브 쏘트 기법을 설명합니다. 단계별 사고 과정을 제시하면 모델이 동일한 패턴으로 문제를 해결하게 됩니다.

여러 추론 분기를 동시에 탐색하고 최적 경로를 선정하는 tree of thoughts 기법으로, 복잡한 탐색 문제에서 효율적으로 해결책을 찾는 방법을 제시한다.

[20:30] 체인 오브 쏘트는 STEM 분야(과학, 기술, 공학, 수학)뿐만 아니라 논리와 추론이 필요한 모든 영역에서 매우 강력한 성능을 보입니다.

[20:51] 셀프 컨시스턴시는 LLM의 추론 한계를 극복하기 위한 기법입니다. 기존 체인 오브 쏘트의 단순한 그리디 디코딩 전략의 한계를 보완합니다.

[21:24] 셀프 컨시스턴시는 샘플링과 다수결 투표를 결합하여 동일한 프롬프트를 여러 번 실행하고, 모델이 가장 일관된 답변을 선택하도록 하여 정확성과 일관성을 향상시킵니다.

[21:52] 이메일 분류 예시를 통해 셀프 컨시스턴시를 설명합니다. WordPress 웹사이트의 연락처 폼 버그에 관한 이메일을 '중요함'으로 분류하는 과정을 단계별로 보여줍니다.

모델이 자체 추론 후 외부 도구(검색, 코드 실행 등)를 활용해 액션을 수행하는 에이전트형 프레임워크 REACT를 통해 실세계 작업을 자동화하는 방법을 안내한다.

[22:26] 이메일 분류 작업의 단계별 접근법을 설명합니다. 이메일의 목적은 연락 양식의 버그를 알리는 것이며, 버그의 잠재적 영향과 발신자의 신뢰도를 평가한 결과 중요하다고 분류됩니다.

[22:50] 자기 일관성(Self-Consistency) 기법을 소개합니다. 모델에 동일한 프롬프트를 여러 번 실행하여 가장 자주 나오는 답변을 최종 결과로 선택하는 방법으로, 3번 중 2번이 '중요'라고 판단한 경우를 예시로 설명합니다.

[23:34] 자기 일관성 기법의 단점을 언급합니다. 모든 작업에 대해 프롬프트를 여러 번 실행하면 높은 비용과 지연시간이 발생하므로, 이런 절충점을 고려해야 한다고 설명합니다.

[23:48] 사고의 나무(Tree of Thoughts) 개념을 소개합니다. 단일한 선형적 연쇄 사고 대신 여러 추론 경로를 동시에 탐색할 수 있는 방법으로, 자기 일관성과 연쇄 사고의 조합을 사용합니다.

[24:25] 사고의 나무의 작동 방식을 구체적으로 설명합니다. 각 단계에서 여러 옵션을 생성하고 가장 좋은 것을 선택하는 과정을 반복하여 최종 출력에 도달하는 방법을 안내합니다.

[24:43] 사고의 나무 구현의 현실적 제약사항을 설명합니다. 단순한 프롬프트 입력으로는 실행이 어려우며, 코드나 프레임워크를 사용해야 하는 복잡한 방법이라고 언급하며, 탐색이 필요한 복잡한 작업에 특히 적합하다고 결론짓습니다.

[25:11] React(Reason and Act) 프롬프팅 패러다임 소개. 이는 대형 언어 모델이 자연어 추론과 외부 도구(검색, 코드 인터프리터 등)를 결합해 복잡한 작업을 해결하는 방식입니다.

[25:38] React는 인간의 사고방식을 모방하는 에이전트로, 핵심 언어모델에 다양한 도구들을 제공합니다. 생각-행동 루프를 통해 문제를 추론하고, 계획을 생성하며, 행동을 수행하고 결과를 관찰합니다.

[26:10] 최신 모델들(Gemini 2.5 Pro 등)은 이미 React 기능을 내장하고 있어 다양한 도구들을 켜고 끌 수 있습니다. 하지만 비용과 지연시간이 높다는 단점이 있습니다.

[26:49] React 프레임워크를 사용하면 더 작고 빠른 모델에서도 동일한 이점을 얻을 수 있습니다. 실제 Python 코드 예시를 들어 메탈리카 밴드 멤버들의 자녀 수를 찾는 과정을 보여줍니다.

[27:28] 몇 줄의 코드만으로 LLM에게 계획, 실행, 검토, 재실행 능력을 부여할 수 있습니다. 실제 출력에서는 각 밴드 멤버별로 검색을 수행하고 결과를 종합하는 과정을 확인할 수 있습니다.

AI에게 프롬프트를 자동 작성하도록 유도해, 간단한 설명만으로 상세 PRD 작성→코드 생성 같은 복잡한 프롬프트 제작을 간소화하는 전략을 다룬다.

[28:06] React는 본질적으로 에이전트이며, 대부분의 경우 에이전트 프레임워크를 직접 작성할 필요가 없다고 강조합니다.

[28:14] LangChain이나 CrewAI 같은 프레임워크를 사용하여 에이전트 시스템을 구축할 수 있으며, 이들이 프레임워크 구성을 훌륭하게 처리해준다고 설명합니다. 모든 프롬프팅 기법들이 복잡하고 시간이 많이 걸릴 수 있지만, AI가 직접 프롬프트를 작성하는 자동 프롬프트 엔지니어링 방법을 소개합니다.

[28:40] LLM에게 코드를 작성하게 할 때 상세한 PRD(Product Requirements Document) 작성을 피하는 방법을 설명합니다. 몇 문장으로 간단히 설명한 후, 모델에게 PRD를 작성하게 하고, 그것을 다른 모델에 넣어 코드를 작성하게 하는 2단계 접근법을 제시합니다.

[28:55] 기존 프롬프팅 기법들(chain of thought, self-consistency 등)을 자동으로 적용하는 방법을 설명합니다. 기본 프롬프트를 제공하고 특정 기법을 적용해달라고 요청하면, 모델이 해당 기법이 적용된 프롬프트를 작성해준다고 합니다.

[29:03] 새로운 프롬프팅 기법을 소개합니다. 이는 모델에게 언제 코드를 작성/실행하게 할지, 언제 자연어로 답변하게 할지를 결정하는 기법입니다. 'strawberry에 R이 몇 개 있나요?' 같은 문제를 예시로 들어 설명을 시작합니다.

[29:25] 코드를 활용한 프롬프팅의 장점을 구체적으로 설명합니다. 많은 모델들이 코드 작성/실행 능력을 가지고 있으며, 문자 세기 같은 작업에서는 직접 답변하는 것보다 코드를 작성하게 하는 것이 훨씬 정확하다고 강조합니다. 실제 예시를 통해 이 방법의 효과를 보여줍니다.

모델의 코드 작성·실행 기능을 이용해, 예컨대 문자열 분석처럼 오류 없는 답변을 보장하는 code prompting 기법을 설명한다.

[30:54] 코드 실행을 통한 프롬프팅 기법을 소개하며, 코드를 작성하고 실행하여 정확한 결과를 얻는 방법에 대해 설명합니다.

[31:01] 프롬프트 엔지니어링의 모범 사례들을 제시합니다. 첫 번째로 제로샷, 원샷, 퓨샷 예시를 통해 모델에 예시를 제공하는 것의 중요성을 강조합니다.

예시 제공, 간결 설계, 출력 명시, 변수 사용 등 주요 모범 사례와 최신 모델 동향 파악의 중요성을 정리한다.

[31:16] 단순함으로 설계하는 원칙을 설명하며, 간단한 프롬프팅에서 시작해서 필요할 때만 복잡한 지시사항을 추가하라고 조언합니다.

[31:34] 결과물에 대한 구체적 명시의 중요성을 강조합니다. JSON 형식이나 특정 문자로 시작하는 응답 등 원하는 출력 형태를 명확히 지정해야 한다고 설명합니다.

[31:53] 제약보다는 지시사항을 사용하라는 원칙을 설명합니다. 하지 말아야 할 것보다는 해야 할 것을 명시하는 것이 더 효과적이라고 조언합니다.

[32:11] 최대 토큰 길이 제어와 변수 사용에 대해 설명합니다. 대규모 프로덕션 환경에서 지연 시간과 비용 최적화를 위해 토큰 길이를 제어하고, 프롬프트에서 변수를 활용하는 방법을 제시합니다.

[32:41] 모델의 최신 능력과 한계에 대한 지속적인 학습의 중요성을 강조하며, 자신의 채널 구독과 뉴스레터를 홍보합니다.

[00:00] 프롬프트 엔지니어링에 대해 알아야 할 모든 것을 알려드리겠습니다.

[00:01] 프롬프트 엔지니어링이라는 용어가

[00:03] 생소하시다면, 이는

[00:04] 인공지능을 최대한 활용하기 위한

[00:07] 멋진 전략들의 집합입니다.

[00:09] Google에서 이 프롬프트 엔지니어링 가이드를

[00:11] 만들었는데, 이를 자세히 살펴보겠습니다.

[00:13] 더 깊이 들어가서

[00:14] 마지막에는 여러분이 프롬프트 엔지니어링의 달인이 될 겁니다.

[00:17] 기본부터 시작해보겠습니다.

[00:20] ChatGPT, Gemini,

[00:22] Claude 같은 모델과 대화할 때

[00:25] 자연어로 입력을 하면

[00:28] 역시 자연어로 된

[00:30] 출력을 받게 됩니다.

[00:34] 이러한 모델들이 작동하는 방식은

[00:36] 여러분의 입력, 즉 프롬프트를 받아서

[00:38] 그 프롬프트를 바탕으로

[00:41] 어떤 출력이 나올지 예측하는 것입니다.

[00:43] 따라서 프롬프트가 정말 중요합니다.

[00:46] 어떻게 구성하는지, 어떤 단어를 사용하는지,

[00:48] 어떤 예시를 제공하는지, 이 모든 것이

[00:51] 프롬프트 엔지니어링입니다.

[00:54] 검증된 프롬프트 엔지니어링 전략들이

[00:56] 여러 가지 있는데, 이는 어떤 모델을 사용하는지,

[00:58] 얼마나 좋은지, 토큰 제한이 얼마인지에 따라

[01:00] 달라지며, 이 모든 것을 살펴보겠습니다.

[01:02] LLM이 어떻게 작동하는지 기억하세요.

[01:04] 이는 예측 엔진입니다.

[01:06] 모델은 순차적인 텍스트를 입력으로 받고,

[01:08] 즉 여러분의 프롬프트를 받아서

[01:10] 학습된 데이터를 바탕으로

[01:12] 다음에 올 토큰이 무엇인지 예측합니다.

[01:14] 토큰이 생소하시다면, 기본적으로

[01:18] 단어라고 생각하시면 됩니다.

[01:20] 보통 단어의 3/4 정도입니다.

[01:23] 기술적인 세부사항에 너무 깊이 들어가지는 않겠지만,

[01:24] 토큰은 단어라고 생각하시면 됩니다.

[01:25] 모델은 다음 토큰을 예측하려고 하고

[01:28] 그 토큰이 초기 프롬프트에 추가되면

[01:30] 원래 프롬프트와 추가된 토큰을 포함하여

[01:32] 그 다음 토큰을 예측하려고 합니다.

[01:35] 그리고 이를 계속 반복해서

[01:37] 적절한 출력을 생성했다고

[01:40] 판단할 때까지 계속합니다.

[01:43] 프롬프트 엔지니어링은

[01:45] LLM이 정확한 출력을 생성하도록

[01:47] 안내하는 고품질 프롬프트를

[01:49] 설계하는 과정입니다.

[01:52] 정말 좋은 정의입니다.

[01:54] 대형 언어 모델에 프롬프트를 입력했는데

[01:56] 원하는 답을 얻지 못하고,

[01:58] 프롬프트를 바꿨더니

[02:00] 원하는 답을 얻었다면,

[02:02] 그것이 바로 프롬프트 엔지니어링입니다.

[02:04] 구체적인 프롬프트 엔지니어링 전략을

[02:07] 살펴보기 전에 몇 가지 기본 용어를

[02:09] 설명하겠습니다. 모든 대형 언어 모델은

[02:12] 서로 다릅니다. 어떤 것은 매우 다르고,

[02:14] 어떤 것은 조금씩 다르며,

[02:16] 이러한 차이점들은 모두 중요합니다.

[02:18] 이러한 설정들을 올바르게 하면

[02:20] 프롬프트를 최대한 활용하는 데

[02:22] 도움이 됩니다. 첫 번째는 출력 길이입니다.

[02:25] 출력 길이는 모델이 프롬프트에 대한 응답으로

[02:27] 출력해야 하는 최대 토큰 수입니다.

[02:30] 출력 길이가 길수록

[02:32] 프롬프트에 대한 응답이 더 길어질 수 있습니다.

[02:35] 2 더하기 2가 뭐냐고 물어보면

[02:38] 답이 간단하고 짧기 때문에

[02:40] 몇 단락에 걸쳐 답을 설명하지 않습니다.

[02:42] 하지만 코드를 요청한다면

[02:43] 이 출력 길이 설정이

[02:45] 큰 차이를 만들 수 있습니다.

[02:48] 모델이 더 많은 토큰을 출력하면

[02:50] 모델이 더 많은 토큰을 출력하면

[02:52] 더 많은 비용이 들고

[02:53] 시간도 오래 걸리고 더 많은 에너지와 전력을 사용합니다

[02:56] 하지만 여기서 흥미로운 점이 있습니다

[02:58] 염두에 둬야 할 중요한 차이점이요

[03:01] LLM의 출력 길이를 줄이는 것이

[03:03] LLM을 더 간결하게 만들거나

[03:05] 텍스트적으로 더 간결한 출력을

[03:08] 만들어내게 하는 것은 아닙니다. 대신에

[03:11] 제한에 도달하면 LLM이 더 이상

[03:13] 토큰을 예측하지 않고 멈추게 할 뿐입니다

[03:15] 출력 길이를 정말 짧게 설정하면

[03:18] 더 짧고 간결한 답변을 주는 게 아니라

[03:20] 그냥 제한에 도달하면

[03:23] 출력을 멈추게 됩니다

[03:25] 예시를 보여드리겠습니다

[03:27] 여기 Google AI Studio가 있습니다

[03:29] 여기 출력 길이 설정이 있네요

[03:31] 지금은 65,000 토큰으로 설정되어 있습니다

[03:34] 이걸 5 토큰으로 설정해보겠습니다

[03:37] 판다 곰에 대한 이야기를 써보라고 하니

[03:39] 저는 사고하지 않는 모델인 Gemma 327B를 사용하고 있습니다

[03:42] 그냥 '대나무 속삭이는 자'라고만 나옵니다

[03:45] 말도 안 되고 이게 최대 5 토큰입니다

[03:47] 이제 50 토큰으로 늘려보겠습니다

[03:50] 같은 프롬프트를 다시 해보겠습니다

[03:52] 그러면 이렇게 나옵니다

[03:55] 대나무 속삭이는 자, 린은 미스티 피크

[03:58] 보호구역의 다른 판다들과는 달랐습니다

[04:00] 등등 이어지다가 여기서 멈춥니다

[04:02] 그는 단지 맛을 보지 않았다

[04:05] 이게 최대 50 토큰이었습니다

[04:08] 물론 5,000 토큰으로 설정하면

[04:10] 이야기를 완성할 것입니다

[04:12] 하지만 여기서 보듯이 간결한 이야기를

[04:14] 쓴 게 아니라 그냥 출력을 멈춘 것입니다

[04:18] 이게 정말 중요한 점입니다

[04:21] 다음 설정은 샘플링 제어입니다

[04:23] 대형 언어 모델이 다음 토큰을

[04:26] 예측하는 방식의 핵심은 이렇습니다

[04:29] LLM은 공식적으로 단일 토큰을 예측하지 않습니다

[04:32] 오히려 LLM은 다음 토큰이 될 수 있는

[04:34] 것들의 확률을 예측하며

[04:37] LLM 어휘의 각 토큰이 확률을 갖게 됩니다

[04:40] '소가 뛰어넘었다'라고 하면

[04:43] 그냥 '달'을 예측하는 게 아니라

[04:45] 어휘의 모든 단일 토큰에

[04:48] 확률 점수를 부여합니다

[04:51] 그리고 가장 높은 확률을 가진 것이

[04:53] 여러분이 보게 되는 것입니다

[04:56] 그리고 이 샘플링 제어에는

[04:58] 세 가지 주요 설정이 있습니다

[05:00] 온도, Top K, Top P입니다

[05:02] 이 세 가지 모두를 살펴보겠습니다

[05:04] 개인적으로 온도가

[05:06] 샘플링 제어에서 가장 중요한 설정이라고 생각합니다

[05:08] 온도는 토큰 선택의 무작위성을 제어합니다

[05:11] 하지만 더 간단하게 생각하면

[05:13] 온도가 높을수록

[05:15] 응답이 더 창의적이거나 독특해집니다

[05:18] 온도가 낮을수록

[05:20] 덜 창의적이 됩니다

[05:23] 다시 한번 판다 곰에 대한 이야기를 써보라고 하겠습니다

[05:25] 온도를 1로 설정했습니다

[05:27] 이게 가장 창의적인 설정입니다

[05:29] 해보겠습니다

[05:31] 결과가 나왔습니다

[05:33] 대나무 숲의 비는 그냥 이슬비가 아니라 대홍수였습니다

[05:36] 여기서 멈추고 같은 프롬프트를

[05:38] 다시 해보겠습니다. 어떻게 될까요?

[05:40] 똑같은 모델, 똑같은 프롬프트입니다

[05:42] 보시다시피 완전히 다른 이야기가 나왔습니다

[05:46] 그럼 온도를 0으로 설정하면 어떻게 될까요?

[05:48] 온도를 0으로 설정하면 어떻게 될까요? 확인해보겠습니다.

[05:50] 같은 프롬프트를 다시 입력하겠습니다.

[05:51] 판다곰에 대한 이야기를 써달라고 했습니다.

[05:53] 대나무 숲이 나뭇잎의 부드러운 바스락거림과

[05:55] 보이지 않는 새들의 지저귐으로 윙윙거렸습니다.

[05:57] 좋네요. 이제 온도 0으로 다시 해보겠습니다.

[06:00] 그리고 보세요. 대나무 숲이

[06:03] 매미의 낮은 웅웅거림으로 윙윙거렸습니다.

[06:05] 매우 유사하죠. 온도 0일 때의 이전 결과와

[06:08] 매우 비슷합니다. 그리고 이것이

[06:10] 여러분이 얻게 될 결과입니다.

[06:12] 온도가 높을 때는 같은 프롬프트를 줘도

[06:13] 매번 매우 다른 응답을 얻게 되고

[06:15] 온도가 낮을 때는

[06:17] 그 반대가 됩니다.

[06:18] 매우 일관성 있는 응답을

[06:20] 얻게 됩니다.

[06:22] 따라서 여러분이 사용하는

[06:24] 용도에 따라 온도를 조정하는 것을

[06:27] 기억하세요. 자, 다음은 top K와 top P입니다.

[06:30] 솔직히 말하면, 저는 top P와

[06:32] top K 설정을 전혀 사용하지 않습니다.

[06:34] 온도만 사용하면 충분합니다.

[06:36] 하지만 간단히

[06:38] 그것들이 무엇인지 설명해드리겠습니다.

[06:41] top K는 온도와 매우 유사하게 작동합니다.

[06:43] top K 샘플링은 모델의 예측 분포에서

[06:46] 가장 가능성이 높은 상위 K개 토큰을 선택합니다.

[06:48] 예측 분포는 단순히

[06:50] 어휘 집합과 할당된

[06:52] 확률입니다. top K가 높을수록

[06:54] 모델의 출력이 더 창의적이고

[06:55] 다양해집니다. 낮을수록 더 제한적이고

[06:57] 사실적이 됩니다. 매우 유사하죠.

[07:00] 창의성을 위한 또 다른

[07:02] 설정입니다. top P 샘플링은

[07:05] 모델이 선택할 어휘 집합을

[07:07] 누적 확률을 기반으로

[07:09] 제한하는 방법입니다. 이해하지 못해도

[07:11] 걱정하지 마세요. 솔직히

[07:12] 저는 top P를 거의 사용하지 않습니다.

[07:15] 그것이 무엇을 하는지 대략적으로

[07:16] 아는 것으로 충분합니다.

[07:18] 이 세 가지 설정을 가지고

[07:20] 실험해보세요. 이 문서에서는

[07:22] 이 세 설정 모두에 대한

[07:25] 권장 시작점을 제공합니다. 그리고 일반적으로

[07:27] 여러분이 사용하는 채팅 인터페이스에서

[07:29] 기본 설정도 제공합니다.

[07:31] 하지만 여기서 일반적인 시작점으로

[07:33] 온도 0.2인데, 이는 제가

[07:35] 보통 시작하는 것보다 훨씬 낮습니다.

[07:37] 저는 보통 0.6부터 시작하고, top P 0.95, top K 30으로

[07:40] 상대적으로 일관성 있는

[07:42] 결과를 얻을 수 있습니다. 창의적이지만

[07:44] 과도하지 않은 결과를 말이죠.

[07:46] 더 창의적인 결과를 원한다면

[07:48] top P와 top K를 높이세요.

[07:51] 더 일관적이고 덜 창의적인

[07:53] 결과를 원한다면 반대로

[07:54] 그 설정들을 낮추세요.

[07:56] 자, 이제 여러분이 여기 온 이유인 프롬프팅 기법들입니다.

[08:00] 먼저 이야기할 것은

[08:01] 일반적인 프롬프팅 또는 제로샷입니다.

[08:04] 제로샷을 들어보셨다면, 이것이

[08:06] 모델에게 한 번의 기회를 주는 것을 의미하지 않습니다.

[08:09] 그런 면에서 조금 혼란스럽죠.

[08:11] 샷이라는 용어는 모델에게

[08:14] 얼마나 많은 예제를 주느냐를 의미합니다.

[08:17] 제로샷에서는 가장 간단한 형태의

[08:18] 프롬프팅입니다. 모델에게

[08:20] 원하는 출력의 예제를

[08:22] 전혀 주지 않습니다. 제로샷에서는

[08:25] 기본적으로 과제에 대한 설명만

[08:27] 달성하고자 하는 작업에 대한 설명입니다.

[08:29] 소설 쓰기든, 수학 문제 풀이든,

[08:30] 코드 작성이든, 다른 건 없습니다.

[08:33] 단지 원하는 것에 대한

[08:35] 철저한 설명뿐입니다. 일반적으로

[08:37] 더 많은 예시가 필요할수록, 대형

[08:40] 언어 모델에게 요청하는

[08:42] 작업이 더 복잡하다는 뜻입니다.

[08:44] 만약 소설 쓰기처럼

[08:46] 비교적 간단한 작업이라면, 아마도

[08:48] 많은 예시가 필요하지 않을 겁니다.

[08:51] 그럼 제로샷 프롬프트의 예시를 보겠습니다.

[08:54] 모델에게 영화 리뷰를

[08:57] 긍정적, 중립적, 또는 부정적으로

[08:59] 분류하도록 요청합니다. 그리고

[09:02] 여기 리뷰가 있습니다. '이것은 인류가

[09:04] 향하고 있는 방향을 보여주는

[09:06] 충격적인 연구입니다. AI가 계속해서

[09:07] 통제 없이 진화한다면, 이런

[09:09] 걸작 같은 영화가 더 많았으면 좋겠습니다.'

[09:11] 감정: 이렇게 요청하는 겁니다.

[09:13] 감정이 무엇인지, 그리고

[09:15] 긍정적, 중립적, 부정적을 사용하라고 했죠.

[09:17] 그리고 정답을 맞췄습니다. 완벽하네요.

[09:20] 이제 제로샷보다 많은 것, 원샷이나

[09:22] 퓨샷은 대형 언어 모델에게

[09:24] 더 많은 예시를 제공한다는 뜻입니다.

[09:26] 원샷은 하나의 예시를 주는 것이고,

[09:29] 퓨샷은 두 개 이상입니다.

[09:31] 원샷에서는 모델이 당신이 제공한

[09:34] 예시를 최대한 모방하려고 합니다.

[09:36] 그리고 퓨샷을 사용할 때는

[09:38] 모델이 당신의 예시에서 원하는

[09:41] 패턴을 정확하게 파악할

[09:42] 기회를 더 많이 줍니다. 만약

[09:44] 특정 형식의 출력을 원한다면,

[09:46] 이는 훌륭한 방법입니다.

[09:48] 퓨샷 프롬프팅에 필요한

[09:50] 예시의 수는 몇 가지 요인에 따라

[09:52] 달라집니다. 앞서 이야기한 작업의 복잡성,

[09:54] 예시의 품질도 포함됩니다.

[09:56] 훌륭한 예시를 제공할 수 있다면,

[09:58] 대형 언어 모델의 작업이

[10:00] 그만큼 쉬워집니다. 그리고

[10:04] 사용하는 생성형 AI 모델의 능력도

[10:05] 중요합니다. 일반적인 경험칙으로는

[10:07] 퓨샷 프롬프팅에 최소

[10:09] 3~5개의 예시를 사용해야 합니다.

[10:11] 그럼 이 문서에서 제공하는

[10:14] 예시를 살펴보겠습니다.

[10:16] 목표는 피자 주문을 JSON으로

[10:18] 파싱하는 것입니다. 여기 있습니다.

[10:22] 프롬프트는 이렇습니다. '고객의 피자 주문을

[10:25] 유효한 JSON으로 파싱하세요.

[10:27] 예시: 치즈, 토마토 소스, 페퍼로니가 들어간

[10:30] 작은 피자를 원합니다.' 이제

[10:34] 이 정확한 프롬프트를 다른 것 없이

[10:36] 모델에게 제공한다면, 모델은

[10:39] JSON 객체의 구조가

[10:40] 어떻게 되어야 하는지 추론할 것입니다.

[10:43] 문제는 이걸 천 번의 다른 주문으로

[10:46] 천 번 수행한다면, 서로 다른

[10:49] JSON 객체 구조를 얻을 수 있다는

[10:52] 점입니다. 하지만 여기처럼

[10:54] 예시를 제공한다면, 우리는

[10:56] 크기, 타입, 재료를 원합니다.

[10:59] 그리고 재료 안에는

[11:01] 재료들의 배열을 원합니다. 그러면

[11:03] 모델이 정확히 이 구조를

[11:05] 사용할 가능성이 훨씬 높아집니다.

[11:08] 그리고 여기 같은 프롬프트의

[11:11] 연속입니다. '예시: 토마토 소스,

[11:13] 바질, 모차렐라가 들어간

[11:14] 라지 피자를 주문할 수 있나요?'

[11:16] 모델에서 출력을 요청하는 부분입니다.

[11:18] 크기, 종류, 재료 등이죠.

[11:21] 예시에서 사용한 것과 정확히 같은 구조입니다.

[11:23] 이것이 퓨샷 프롬프팅의 훌륭한 사용 사례입니다.

[11:26] 이제 시스템 메시지에 대해 이야기해보겠습니다.

[11:29] 다음으로,

[11:30] 컨텍스트 프롬프팅과 역할 프롬프팅에 대해 알아보겠습니다.

[11:33] 이러한 기법들의 핵심은

[11:35] 본질적으로 모델이 특정 역할을 수행하도록 하는 것입니다.

[11:38] 시니어 개발자 역할을 하라, CEO 역할을 하라,

[11:43] 선생님 역할을 하라고 하는 것입니다.

[11:46] 역할 설명을 주는 순간,

[11:48] 모델은 해당 역할의

[11:50] 행동과 특성을 취하기 시작합니다.

[11:53] 그 역할이 어떨 것이라고 생각하는 대로 말이죠.

[11:55] 먼저 시스템 프롬프팅은

[11:57] 언어 모델의 전반적인 맥락과 목적을 설정합니다.

[11:59] 모델이 해야 할 일의

[12:01] 큰 그림을 정의합니다.

[12:02] 언어 번역이나

[12:04] 리뷰 분류 등과 같이 말이죠.

[12:06] Google AI Studio를 보면

[12:08] 여기 작은 클립보드가 있고

[12:10] 시스템 지시사항이라고 되어 있습니다.

[12:12] 이것이 시스템 메시지와 같은 것입니다.

[12:13] 클릭하면 여기에 모델을 위한

[12:16] 선택적 톤과 스타일 지시사항이라고 나와 있고,

[12:17] 여기서 달성하려는 목표의

[12:19] 전반적인 주제를 설명하게 됩니다.

[12:21] 다음은 컨텍스트 프롬프팅입니다.

[12:24] 컨텍스트 프롬프팅은 현재 대화나

[12:26] 작업과 관련된

[12:27] 구체적인 세부사항이나 배경 정보를 제공합니다.

[12:29] 모델이 요청 사항의 뉘앙스를 이해하고

[12:31] 그에 맞게

[12:33] 응답을 맞춤화하는 데 도움이 됩니다.

[12:35] 문서에서 이런 예시를 제공합니다.

[12:37] 여기 맥락이 있습니다,

[12:39] 컨텍스트 프롬프팅 맥락입니다.

[12:42] 당신은 레트로 80년대

[12:44] 아케이드 비디오 게임에 관한 블로그를 작성하고 있습니다.

[12:47] 그다음 실제 작업은

[12:49] 기사를 쓸 세 가지 주제를 제안하는 것입니다.

[12:50] 이 기사에 포함되어야 할 내용에 대한

[12:53] 몇 줄의 설명과 함께 말이죠.

[12:55] 실제 작업에서는

[12:57] 레트로 80년대 아케이드 비디오 게임

[13:00] 블로그를 작성해야 한다고 명시하지 않지만,

[13:02] 그것이 맥락에 있습니다. 실행해보면

[13:05] 여기 나옵니다. 숨겨진 영웅들 5:

[13:08] 픽셀에서 파워까지, 코인 오프 컬처 클래시.

[13:11] 맥락을 실제 당면한 작업과 분리하는 것입니다.

[13:14] 마지막으로 역할 프롬프팅입니다.

[13:16] 역할 프롬프팅은 언어 모델이

[13:18] 채택할 특정한 캐릭터나 정체성을 할당합니다.

[13:20] 이는 모델이 할당된 역할과

[13:22] 그와 관련된 지식 및 행동에

[13:23] 일치하는 응답을 생성하는 데 도움이 됩니다.

[13:26] 제가 가장 많이 보는 곳은

[13:29] Gentic 프레임워크, 특히 Crew AI입니다.

[13:32] Crew AI는 실제로 이것을

[13:34] 한 단계 더 발전시키는 일을 잘 합니다.

[13:37] 그리고 이를 뒷받침하는 많은 데이터를 가지고 있습니다.

[13:39] 이 전략은 직접적인

[13:41] 대형 언어 모델 프롬프팅에서도

[13:43] 똑같이 작동합니다. 이것을 보세요.

[13:45] 에이전트 정의에서 사용할 수 있는

[13:48] 역할 속성이 있습니다.

[13:50] 크루 내에서 에이전트의 기능과 전문성을 정의합니다.

[13:52] 또한 목표나 작업도 있습니다.

[13:55] 에이전트의 의사결정을 안내하는

[13:57] 개별 목표입니다.

[13:59] 심지어 배경 스토리도 있어서

[14:01] 에이전트에게 맥락과 개성을 제공하여

[14:03] 상호작용을 풍부하게 만듭니다. 그래서 역할 프롬프팅은 매우

[14:07] 매우 강력합니다. 문서에서 가져온

[14:09] 또 다른 예시를 보여드리겠습니다. 여행 가이드 역할을

[14:11] 해달라고 요청했습니다. 제가 위치를 알려드리면

[14:13] 근처에서 방문할 만한 세 장소를

[14:15] 추천해달라고 했죠. 실제 역할은 여행 가이드이고

[14:17] 작업은 방문할 세 장소를 추천하는 것입니다.

[14:20] 제안을 해보겠습니다. 저는 암스테르담에

[14:22] 있고 박물관만 방문하고 싶다고

[14:25] 여행 제안을 요청했습니다. 실행해보겠습니다.

[14:27] 그리고 결과가 나왔네요. 암스테르담 박물관 가이드가

[14:29] 되어드릴 준비가 되었다고 하며 요청에 따라

[14:31] 세 개의 박물관을 추천해주었습니다.

[14:33] 이것이 바로 역할 프롬프팅이

[14:35] 정말 강력해지는 순간입니다.

[14:37] 다음으로는 제가 실제로 들어본 적이 없던

[14:38] 기법을 소개하겠습니다. '스텝백 프롬프팅'이라고

[14:40] 불리는 방법입니다. 제가 알고 있는 다른

[14:42] 프롬프팅 기법들과 유사하지만 독특한 면이 있습니다.

[14:45] 보여드리겠습니다. 스텝백 프롬프팅은

[14:47] 모델에게 먼저 특정 작업과 관련된

[14:49] 일반적인 질문을 고려하도록 요청한 다음

[14:51] 그 일반적인 질문에 대한 답변을

[14:54] 특정 작업을 위한 후속 프롬프트에

[14:56] 입력하는 방식입니다. 복잡하게 들린다면

[14:59] 곧 예시로 보여드리겠습니다.

[15:01] 그렇다면 이것의 목적은 무엇일까요?

[15:04] 이는 대형 언어 모델이 관련된

[15:05] 배경 지식과 추론 과정을 활성화할 수

[15:07] 있게 해줍니다. 특정 문제를 해결하기 전에

[15:10] 말이죠. 더 광범위하고 근본적인

[15:12] 원리들을 고려함으로써

[15:13] 대형 언어 모델은 더 정확하고

[15:15] 통찰력 있는 응답을 생성할 수 있습니다.

[15:18] 이는 LLM이 비판적으로 사고하고

[15:20] 지식을 새롭고 창의적인 방식으로

[15:23] 적용하도록 격려합니다. LLM의 매개변수에

[15:25] 있는 더 많은 지식을 활용함으로써

[15:27] 작업을 수행하는 최종 프롬프트를

[15:29] 변화시킵니다. 직접적으로 프롬프트를 주었을 때보다

[15:31] 더 많은 지식이 작동하게 되죠.

[15:33] 정말 흥미롭습니다. 먼저 기본 프롬프트

[15:35] 예시를 보겠습니다. 이것은 스텝백

[15:37] 프롬프팅이 아닙니다. 도전적이고 흥미로운

[15:40] 1인칭 슈팅 게임의 새로운 레벨을 위한

[15:42] 한 문단짜리 스토리라인을 작성해달라고

[15:45] 요청했습니다. 이것은 일반적인 프롬프팅이지

[15:47] 스텝백이 아니라는 점을 기억하세요.

[15:49] 실행해보겠습니다.

[15:50] 결과를 보니 폐허가 된 우주정거장

[15:52] 이카루스가 치명적인 미로가 되었고

[15:54] 거대한 중력 이상현상이 정거장을

[15:57] 찢어놓았다는 내용으로 시작합니다.

[15:59] 꽤 좋은 결과입니다. 여기서 흥미롭고

[16:01] 제가 항상 마주치는 점이 있습니다.

[16:03] 모델에게 정말 창의적인 작업을 요청할 때마다

[16:06] 온도를 1로 설정해도

[16:07] 정말 일반적인 응답을

[16:09] 주는 경향이 있습니다. 그래서 창의적 글쓰기는

[16:11] 제가 대형 언어 모델을 가장 적게

[16:13] 활용하는 분야 중 하나입니다.

[16:15] 앞으로는 스텝백 방법을

[16:16] 시도해보겠습니다. 이제 실제 할당된

[16:19] 작업을 주기 전에 이 주제 영역에 대해

[16:21] 먼저 생각하게 해보겠습니다. 인기 있는

[16:23] 1인칭 슈팅 액션 게임을 바탕으로

[16:25] 도전적이고 흥미로운 레벨 스토리라인에

[16:27] 기여하는 다섯 가지 가상의 핵심 설정은

[16:30] 무엇인가요? 1인칭 슈팅

[16:32] 비디오 게임에서 말이죠. 매우 포괄적인

[16:35] 다섯 가지 가상의 핵심

[16:36] 답변을 주었습니다.

[16:38]

[16:40]

[16:42]

[16:44]

[16:47] 설정들을 얻었습니다. 이제 이 모든 출력을

[16:51] 복사해서 여기 맥락으로 붙여넣었습니다.

[16:53] 그리고 맨 아래에 이렇게 말했습니다.

[16:55] 테마 중 하나를 선택해서 1인칭 슈팅 게임의

[16:58] 새로운 레벨을 위한 도전적이고 흥미로운

[17:01] 스토리라인을 한 문단으로 작성해달라고 했습니다.

[17:03] 결과를 보면 어떻게 나왔는지 확인해보겠습니다.

[17:05] 플레이어는 버려진 우주 정거장의 중심부에서

[17:07] 자신을 발견하게 되는데, 방금 전 빠르게 진화하는

[17:10] 나노봇 떼로 가득한 무중력 구간에서

[17:12] 끔찍한 경험을 한 후 나온 상황입니다.

[17:14] 대형 언어 모델에서 더 정확하고

[17:17] 더 폭넓은 지식을 얻을 수 있는

[17:18] 좋은 방법입니다. 자, 이제 다음으로

[17:21] 대형 언어 모델을 완전히 바꾼

[17:24] 프롬프팅 기법에 대해 설명하겠습니다.

[17:26] 바로 체인 오브 소트(Chain of Thought)입니다.

[17:28] 이것에 대해 설명하기 전에, 체인 오브 소트는

[17:32] 오늘날 많은 모델에 내장되고 있습니다.

[17:34] 테스트 타임 컴퓨트나 추론 시간 컴퓨트에

[17:37] 대해 들어본 적이 있다면, 이것이 바로

[17:39] 그들이 말하는 것입니다. 모델들은

[17:41] 실제 출력을 제공하기 전에 사고 과정을

[17:43] 체인 오브 소트 형태로 출력 섹션의

[17:46] 사고 부분에서 보여줍니다.

[17:47] 하지만 이것들이 모델에 내장되기 전에는

[17:49] 우리가 표준 출력 형태로 모델에

[17:52] 이렇게 하도록 프롬프트를 주었습니다.

[17:54] 실제로는 꽤 간단하지만 정말 강력합니다.

[17:56] 제가 6개월이나 1년 전의

[17:59] 모델 벤치마크를 기억해보면

[18:01] 모든 프롬프트에 '단계별로 생각하고

[18:03] 단계별로 작업을 보여달라'고

[18:05] 추가했었습니다. 그리고 프롬프트에

[18:08] 그것만 추가해도 훨씬 더 나은,

[18:12] 훨씬 더 정확하고 고품질의

[18:14] 출력을 모델에서 얻을 수 있었습니다.

[18:17] 말씀드린 바와 같이 많은 모델들이

[18:19] 이것을 내장하고 있지만 전부는 아닙니다.

[18:22] 작은 크기의 모델이나 사고 모드나

[18:24] 테스트 타임 컴퓨트 모드가 없는 모델의 경우

[18:26] 이것은 여전히 매우 강력한

[18:28] 프롬프팅 방법입니다.

[18:31] 재미있는 것은 대부분의 최신 모델들이

[18:33] 소위 '사고' 모델이 아니더라도

[18:36] 기본적으로 이렇게 작동한다는 것입니다.

[18:38] 한 번 보겠습니다.

[18:40] 이것은 Gemini 2.0 Flash Light입니다.

[18:42] 이것은 사고 모델이 아닙니다.

[18:44] 여기 프롬프트가 있습니다. 제가 3살이었을 때

[18:47] 제 파트너는 제 나이의 세 배였습니다.

[18:49] 즉, 3살 대 9살이었죠.

[18:51] 지금 저는 20살입니다. 제 파트너는

[18:55] 몇 살일까요? 문제를 해결하는 방법은 다음과 같습니다.

[18:58] 파트너의 나이를 찾아보겠습니다.

[19:00] 단계별로 생각하고 있는 것을 볼 수 있습니다.

[19:03] 답은 26살이고 이것이 맞습니다.

[19:07] 문서의 예시를 보면 출력이

[19:09] 작업 과정을 보여주지 않아서

[19:12] 63세라는 잘못된 답을 얻었습니다.

[19:14] 하지만 '단계별로 생각해달라'고 요청했을 때

[19:17] 실제로 각 사고 단계를 출력하고

[19:20] 올바른 답을 얻을 수 있었습니다.

[19:22] 따라서 작은 모델이나 오래된 모델을

[19:25] 사용할 때마다, 그리고 말씀드리지만

[19:27] 추론 속도가 중요할 때나

[19:29] 비용이 중요할 때와 같은

[19:31] 특정 사용 사례에 대해서는

[19:33] 여전히 이런 모델들을 사용해야 합니다.

[19:36] 올바른 모델을 선택할 때

[19:38] 고려해야 할 사항이 많습니다.

[19:40] 이런 작은 모델들에서도 많은 것을

[19:42] 지능형 모델들로부터 더 많은 성과를 얻을 수 있습니다

[19:44] 이러한 프롬프팅 전략들만으로도 말이죠. 그리고

[19:46] 뿐만 아니라, 프롬프팅 기법들을 조합할 수도 있습니다.

[19:49] 따라서 원샷이나 퓨샷 프롬프트를

[19:51] 체인 오브 쏘트와 결합할 수 있습니다.

[19:53] 그 예시를 살펴보겠습니다.

[19:55] 질문입니다. 제 형이 2살이었을 때,

[19:57] 저는 그의 나이의 두 배였습니다. 지금 저는 40살입니다.

[19:59] 제 형은 몇 살일까요? 단계별로 생각해봅시다.

[20:01] 그리고 예시를 제공합니다.

[20:03] 답변은 다음과 같습니다. 제 형이 2살이었을 때,

[20:05] 저는 2 곱하기 2는 4살이었습니다.

[20:08] 이는 2살의 나이 차이이고 제가 형보다 나이가 많습니다.

[20:10] 지금 저는 40살입니다. 따라서 제 형은

[20:13] 40에서 2를 뺀 38살입니다.

[20:16] 답은 38입니다. 그 다음, 질문을 해봅시다.

[20:18] 제가 3살이었을 때, 제 파트너는

[20:19] 제 나이의 3배였습니다. 지금 저는 20살입니다.

[20:21] 제 파트너는 몇 살일까요? 단계별로

[20:23] 생각해봅시다? 그러면 모델은 기본적으로

[20:26] 우리가 제공한 예시와 정확히 같은 사고 방식을

[20:28] 모방했습니다. 그리고 체인 오브 쏘트는

[20:30] 다양한 사용 사례에서 정말 강력합니다.

[20:32] 기본적으로 STEM 카테고리에 속하는 모든 것,

[20:35] 즉 과학, 기술, 공학, 수학 분야에서

[20:37] 체인 오브 쏘트는 매우 강력합니다.

[20:39] 하지만 논리와 추론 분야에서도 마찬가지입니다.

[20:41] 그리고 모델이 단계별로 생각하도록 하는 것이

[20:44] 결과를 크게 개선시키는

[20:45] 수많은 다양한 카테고리들이 있습니다.

[20:47] 모든 모델의 출력을 크게 향상시킵니다.

[20:49] 좋습니다. 다음으로는

[20:51] 셀프 컨시스턴시(자기 일관성)에 대해 이야기해보겠습니다.

[20:53] 이것도 또 다른 매우 강력한 프롬프팅 기법입니다.

[20:56] LLM의 추론 능력은 종종

[20:58] 모델 크기를 늘리는 것만으로는 극복할 수 없는

[21:00] 한계로 여겨집니다.

[21:03] 모델은 문제를 해결하는 인간처럼

[21:04] 추론 단계를 생성하도록 프롬프트할 수 있습니다.

[21:06] 하지만 체인 오브 쏘트는 단순한

[21:09] 그리디 디코딩 전략을 사용하여

[21:11] 효과를 제한합니다. 그리고 그리디 디코딩은

[21:14] 가장 높은 확률의 토큰을 선택하는 것을

[21:16] 의미합니다.

[21:19] 그리고 문서에 따르면, 이는

[21:21] 효과를 제한합니다. 이제 셀프 컨시스턴시가 등장합니다.

[21:24] 셀프 컨시스턴시는

[21:27] 샘플링과 다수결 투표를 결합하여

[21:30] 다양한 추론 경로를 생성하고

[21:32] 가장 일관된 답변을 선택합니다.

[21:34] 이것이 기본적으로 의미하는 바는 같은 프롬프트를

[21:36] 모델에 대해 예를 들어

[21:39] 5번 다르게 실행한 다음,

[21:41] 모델이 어떤 것이 올바른 답변이라고 생각하는지

[21:44] 또는 최고의 해결책이라고 생각하는지에 대해

[21:46] 투표하도록 하는 것입니다.

[21:49] 그리고 이것은 대형 언어 모델에 의해 생성된

[21:51] 응답의 정확성과 일관성을 향상시킵니다.

[21:52] 좋습니다. 예시를 살펴보겠습니다.

[21:56] 이메일을 중요하거나 중요하지 않음으로

[21:58] 분류하는 작업이 있습니다. 그리고 여기 이메일이 있습니다.

[22:00] 안녕하세요, 귀하가 웹사이트에 WordPress를

[22:02] 사용하시는 것을 봤습니다. 훌륭한 오픈소스

[22:04] 콘텐츠 관리 시스템입니다. 저도 과거에

[22:05] 사용해본 적이 있습니다. 등등. 여기가 중요한 부분입니다.

[22:07] 연락처 폼에서 버그를 발견했는데

[22:09] 이름 필드를 선택할 때 발생합니다.

[22:11] 따라서 이것은 중요한 이메일이 될 것입니다.

[22:13] 누군가가 잠재적인 버그에 대해

[22:15] 연락하고 있는 것입니다. 따라서

[22:17] 위의 이메일을 중요하거나 중요하지 않음으로

[22:19] 분류하세요. 단계별로 생각해보고

[22:21] 이유를 설명해보세요. 여기 출력 결과입니다.

[22:24] 1단계, 목적을 파악합니다.

[22:26] 이메일의 목적은 수신자에게

[22:27] 연락 양식의 버그를 알리는 것입니다.

[22:30] 2단계, 버그의 잠재적 영향을 평가합니다.

[22:32] 3단계, 발신자의

[22:34] 신뢰도를 고려합니다. 결론:

[22:36] 중요합니다. 좋습니다. 버그의 잠재적

[22:39] 영향과 발신자의 신뢰도를 바탕으로

[22:41] 이 이메일은

[22:42] 중요하다고 분류되어야 합니다. 수신자는

[22:43] 버그를 즉시 수정하고

[22:45] 웹사이트를 공격으로부터

[22:46] 보호하기 위한 조치를 취해야 합니다. 이제 두 번째

[22:49] 결과를 살펴보죠. 다시 말씀드리지만, 우리는

[22:52] 모델에 여러 번 프롬프트를 보내고

[22:54] 모델이 어떤

[22:56] 결과가 가장 좋은지 결정하도록 할 것입니다.

[22:59] 결과 2번은: 긴급성 부족, 중요하지 않은 버그 리포트

[23:02] 개인적 영향 부족, 행동 요청 없음

[23:05] 그리고 발신자의 의도. 결론:

[23:08] 중요하지 않음. 그리고 세 번째 시도에서는

[23:11] 중요하다고 판단했습니다. 대형 언어 모델의

[23:14] 세 가지 결과 중 두 개가

[23:16] 중요하다고 판단했습니다. 이를

[23:18] 3번, 5번, 심지어

[23:20] 50번까지도 할 수 있습니다.

[23:22] 그리고 기본적으로 가장 자주

[23:24] 나온 결과나 응답을

[23:27] 진실이나 최선의 응답으로 취하는 겁니다.

[23:30] 이 경우 3개 중 2개가 중요했으므로

[23:32] 중요하다고 분류해봅시다.

[23:34] 하지만 큰 비용이 따릅니다.

[23:36] 명백히 모든 단일 작업에 대해

[23:38] 이런 프롬프트를 여러 번 실행한다면

[23:40] 높은 비용과 높은 지연시간이 발생합니다.

[23:43] 이 프롬프팅 전략의 사용을

[23:45] 결정할 때 고려해야 할

[23:47] 절충점들입니다.

[23:48] 이제 연쇄 사고와

[23:50] 자기 일관성에 익숙해졌으니

[23:52] 사고의 나무에 대해 얘기해봅시다.

[23:54] 이것은 LLM이 단일한 선형적인

[23:58] 연쇄 사고를 따르기보다는

[23:59] 여러 다른 추론 경로를

[24:01] 동시에 탐색할 수 있게 해줍니다.

[24:03] 이런 모습입니다.

[24:05] 여기는 연쇄 사고입니다: 입력,

[24:07] 여러 단계들, 그다음 출력.

[24:09] 하지만 여기는 사고의 나무입니다. 입력이 있고

[24:11] 각 단계에서 다음 결과 세트로 이어지는

[24:15] 서로 다른 출력들을 테스트하여

[24:17] 최종적으로 최종 출력에 도달합니다.

[24:20] 이것은 자기 일관성과

[24:22] 연쇄 사고의 조합을 사용합니다.

[24:25] 이렇게 상상해볼 수 있습니다.

[24:27] 입력이 있고, 첫 번째 단계,

[24:29] 여러 첫 번째 단계들을 생각해내고

[24:32] 어떤 것이 가장 정확하거나

[24:34] 최선인지 결정하게 합니다. 그다음

[24:37] 다음 단계로 넘어가서

[24:38] 계속 반복하여

[24:40] 최종적으로 최종 출력을 얻습니다.

[24:43] 이제 사고의 나무를 사용자와

[24:46] 모델에 입력할 수 있는

[24:48] 프롬프트 박스 사이에서만 엄격하게 하는 것은

[24:51] 실제로는 실행 가능하지 않습니다.

[24:53] 너무 복잡하기 때문입니다.

[24:55] 정말로 코드로 사고의 나무를 구현하거나

[24:57] 어떤 종류의 프레임워크를 사용해야 합니다.

[24:59] 이런 접근법은 사고의 나무를

[25:01] 탐색이 필요한 복잡한

[25:04] 작업에 특히 적합하게 만듭니다.

[25:06] 더 복잡한 작업, 더 정교한 작업이 있다면

[25:09] 사고의 나무가

[25:11] 당신에게 완벽할 수 있습니다. 좋습니다, 다음으로

[25:13] React에 대해 알아보겠습니다. 이는 Reason과

[25:17] Act의 줄임말입니다. Reason and Act 프롬프팅은

[25:19] 대형 언어 모델이 자연어 추론을 사용하여

[25:21] 복잡한 작업을 해결할 수 있도록 하는

[25:23] 패러다임입니다. 이는 외부 도구들과 결합되어

[25:25] 작동합니다 - 검색, 코드

[25:27] 인터프리터 등등요. 도구들은 대형 언어 모델의

[25:31] 원시 지능을 가져와서

[25:32] 실제 세계의 작업을

[25:35] 수행할 수 있게 하는 데 매우 중요합니다.

[25:38] React는 인간이 실제 세계에서 작동하는 방식을 모방합니다.

[25:41] React를 에이전트로

[25:42] 생각해볼 수 있습니다. 기본적으로는

[25:45] 로직, 즉 핵심 대형 언어 모델이 있고,

[25:48] 그 다음에 도구들을 제공합니다. 새로운 지식을 얻는

[25:50] 도구들이나 기억을 저장하는 도구들,

[25:53] 또는 다른 에이전트들과 소통하는 도구들 말입니다.

[25:56] 기본적으로 원하는 모든 것이죠.

[25:57] React 프롬프팅은 추론과 행동을

[26:00] 생각-행동 루프로 결합함으로써 작동합니다.

[26:02] LLM은 먼저 문제에 대해 추론하고

[26:04] 행동 계획을 생성합니다.

[26:05] 그 다음 계획의 행동들을 수행하고

[26:07] 결과를 관찰합니다. 이제,

[26:10] 이것이 익숙하게 들린다면, 요즘의 많은

[26:13] 최신 모델들이 이것을 내장하고 있기 때문입니다.

[26:15] 다양한 도구들을 켜고 끌 수 있고,

[26:18] 사고 연쇄가 생각 모드에 내장되어 있습니다.

[26:21] 그래서, 여기 5월 6일 기준

[26:23] Gemini 2.5 Pro 프리뷰가 있습니다.

[26:28] 그리고 여기 그것의 도구들이 있습니다 - 구조화된

[26:30] 출력, 코드 실행, 함수

[26:32] 호출, 구글 검색. 그래서 이것은

[26:35] React가 자동으로 수행되는 완벽한 예시입니다.

[26:38] 하지만 물론, 최신 모델들을 사용할 때는

[26:41] 가장 많은 비용을 지불하게 되고

[26:43] 아마도 가장 오래 기다려야 할 것입니다.

[26:45] 그래서 가장 높은 비용,

[26:47] 가장 높은 지연시간이죠. 하지만

[26:49] 이러한 많은 이점들을 더 오래된, 또는

[26:52] 더 작고, 빠르고, 덜 지능적인

[26:55] 모델들에서도 얻을 수 있습니다

[26:58] 단순히 React 프레임워크를 사용함으로써 말이죠.

[27:01] 그래서 React는 정말 단지 에이전트입니다.

[27:02] 그리고 이 예시에서는

[27:04] 이것의 가장 기본적인 버전을 보고 있습니다.

[27:06] 여기 Python 코드가 있습니다. 우리는

[27:08] lang chain의 에이전트들을 로딩하고 있습니다.

[27:10] 여기 프롬프트가 있습니다. 메탈리카 밴드

[27:12] 멤버들은 총 몇 명의 아이를 가지고 있나요? 이제 여기

[27:14] LLM이 있습니다. 우리는 구글의 제품인

[27:16] Vertex AI를 사용하고 있습니다. 그리고 우리는

[27:19] SERP API라는 도구를 사용하고 있는데, 이는 구글 검색

[27:22] API로 웹 검색을 모델에게 도구로

[27:25] 제공합니다. 그래서 우리가 실행하면

[27:28] 괜찮습니다. 이제 이 몇 줄의 코드만으로

[27:30] 우리는 LLM에게 계획하고, 실행하고, 검토하고,

[27:35] 무슨 일이 일어났는지 확인한 다음 필요하면

[27:37] 다시 실행할 수 있는 능력을 주었습니다.

[27:39] 그래서 여기 출력이 있습니다.

[27:42] 메탈리카는 4명의 멤버가 있습니다. 그래서 검색해봅시다.

[27:44] 여기 검색이라는 도구가 있습니다

[27:47] 행동 입력. 제임스 헷필드는

[27:49] 몇 명의 아이를 가지고 있나요? 관찰. 세 명의

[27:51] 아이들. 생각 메탈리카 밴드 멤버들은

[27:53] 세 명의 아이를 가지고 있습니다. 다른 검색을 해봅시다.

[27:57] 라스나 커크 해밋 등등

[28:00] 계속해서. 그래서 밴드 멤버마다

[28:02] 하나씩 검색하고, 총 아이 수를 찾고,

[28:04] 모두 더해서, 그것이 답입니다.

[28:06] 그리고 네, 이것은 정말 단지 에이전트입니다.

[28:09] 그리고 10번 중 9번은

[28:11] 에이전트 프레임워크를 직접 작성할 이유가 없습니다.

[28:14] 랭체인이나 크루AI 같은 도구들을 사용할 수 있고, 이들은 여러분을 위해 이런 프레임워크들을 환상적으로 구성해줍니다.

[28:18] 이 모든 프롬프팅 기법들은 분명히 매우 복잡하고 지루해질 수 있고,

[28:20] 수동으로 작성하는데 오랜 시간이 걸릴 수 있습니다.

[28:22] 하지만 AI가 여러분을 위해 프롬프트를 작성해준다면 어떨까요?

[28:24] 이것은 제가 항상 하는 일입니다.

[28:27] 이를 자동 프롬프트 엔지니어링이라고 합니다.

[28:29] 제가 어떻게 하는지 말씀드리겠습니다.

[28:31] 저는 자주 대형 언어 모델에게 코드를 작성해달라고 요청합니다.

[28:33] 하지만 매우 상세한 PRD를 작성하고 싶지는 않습니다.

[28:35] PRD는 제가 작성하고 싶은 코드의 요구사항 목록입니다.

[28:38] 그래서 제가 하는 방식은 먼저 몇 문장으로 제가 만들고 싶은 것을 설명합니다.

[28:40] 그다음 모델에게 저를 위해 PRD를 작성해달라고 요청합니다.

[28:42] 그리고 그 PRD를 가져다가 다른 모델에 넣고,

[28:45] 이 PRD를 바탕으로 코드를 작성해달라고 말합니다.

[28:49] 그러면 제가 만들고 싶은 것에 대한 광범위한 세부사항을 작성하는 일을 해줍니다.

[28:51] 이는 여러분이 작성하는 프롬프트에 훨씬 더 많은 세부사항을 추가하는 좋은 방법입니다.

[28:53] 하지만 그것뿐만 아니라, 오늘 우리가 이야기한 프롬프팅 기법들 중 어떤 것이든 활용할 수 있습니다.

[28:55] 단순히 '여기 제 가장 기본적인 프롬프트가 있습니다. 이것으로 사고의 연쇄를 하거나 자기 일관성을 적용해주세요'라고 말하면

[28:58] 여러분이 대형 언어 모델에 다시 넣어서 실제로 그 프롬프팅 기법을 수행할 수 있는 프롬프트를 작성해줄 것입니다.

[29:00] 좋습니다. 다음으로 제가 사용하는 프롬프팅 기법에 대해 이야기하고 싶습니다.

[29:03] 이것이 무엇이라고 불리는지 확실하지 않습니다.

[29:05] 하지만 기본적으로는 모델에게 언제 코드를 작성하고 실행하도록 요청할지

[29:08] versus 자연어 솔루션을 제공하도록 할지를 결정하는 것입니다.

[29:12] 제가 항상 사용하던 프롬프트 테스트를 사용해보겠습니다.

[29:15] 하지만 이제는 모든 모델이 맞추고 있습니다.

[29:17] 이것은 GPT-4o이고 'strawberry'라는 단어에 R이 몇 개 있냐고 물어봅니다.

[29:19] 맞게 답했네요. strawberry에는 R이 3개 있습니다.

[29:21] 하지만 자주 다른 모델들은 이것을 틀렸습니다.

[29:22] 그래서 여기 항상 올바른 답을 얻을 수 있는 다른 방식으로 생각해보는 방법이 있습니다.

[29:25] 많은 모델들이 코드를 작성하고 실행할 수 있는 능력을 가지고 있습니다.

[29:27] 그래서 단순히 strawberry에 R이 몇 개 있냐고 묻는 대신,

[29:29] 주어진 단어에서 R의 개수를 세는 코드를 작성하라고 명시적으로 말할 것입니다.

[29:31] strawberry라는 단어부터 시작해서요.

[29:33] 이제 단어를 입력받아서 그 단어 안의 R의 개수를 셀 수 있는 코드를 작성한다면,

[29:34] 코드가 올바른 한 항상 맞을 것입니다.

[29:36] 그리고 이런 사용 사례에서는 모델의 코드 작성 능력이

[29:38] 실제로 코드 없이 이런 질문에 올바르게 답하는 능력보다 훨씬 뛰어납니다.

[29:40] 여기 예시가 있습니다. 주어진 단어에서 R의 개수를 세는 코드를 작성하세요.

[29:42] strawberry라는 단어부터 시작해서 그 코드를 실행하세요.

[29:45] 분석을 열어보면, 단어를 정의하고 코드를 작성했습니다.

[29:48] 그리고 여기 출력이 있습니다.

[29:49] 그래서 실제로

[29:51]

[29:52]

[29:54]

[29:56]

[29:59]

[30:01]

[30:03]

[30:05]

[30:06]

[30:08]

[30:10]

[30:12]

[30:14]

[30:16]

[30:18]

[30:20]

[30:22]

[30:24]

[30:27]

[30:29]

[30:30]

[30:33]

[30:35]

[30:37]

[30:39]

[30:41]

[30:43]

[30:45]

[30:48]

[30:51]

[30:54] 코드를 작성하고 실행했고, 이제

[30:56] 정확할 것이라는 걸 알고 있습니다. 저는

[30:58] 이것을 코드를 활용한 프롬프팅이라고 부릅니다.

[31:01] 자, 이제 마무리로 몇 가지

[31:03] 모범 사례에 대해 이야기해보겠습니다. 첫 번째,

[31:05] 예시를 제공하세요. 제로샷, 원샷,

[31:07] 퓨샷에 대해 이야기했습니다. 가능하다면,

[31:10] 모델에 예시를 제공해보세요,

[31:12] 특히 일관된

[31:14] 결과물을 얻으려고 할 때 말입니다.

[31:16] 단순함으로 설계하세요. 저는 이 점에

[31:18] 정말 동감합니다. 간단한 프롬프팅으로 시작해서

[31:21] 더 많은 지시사항이나 더 세밀한

[31:23] 지시사항은 절대 필요할 때만 추가하세요.

[31:25] 그리고 모델에 대한 작업이나

[31:28] 프롬프트를 작성할 때마다

[31:29] 이것이 내가 요청하는 것의

[31:32] 가장 간단한 버전인지 생각해보세요.

[31:34] 결과물에 대해 구체적으로 명시하세요.

[31:36] 이것은 정말 중요합니다. JSON을

[31:38] 기대한다면, JSON을 기대한다고 말하세요.

[31:41] 결과물의 첫 번째 단어의

[31:43] 모든 글자가 B라는 글자이길 기대한다면

[31:45] 반드시 그렇게 말하세요. 무엇이든 간에

[31:48] 결과물을 명시하세요. 그렇지 않으면

[31:50] 모델은 단지 당신이

[31:51] 무엇을 요청하는지 추측하려고 할 것입니다.

[31:53] 제약보다는 지시사항을 사용하세요.

[31:56] 지시사항은 원하는

[31:58] 형식, 스타일, 또는 응답의 내용에 대한

[32:00] 명시적인 지시를 제공합니다.

[32:03] 제약은 한계나 경계를 설정합니다.

[32:05] 따라서 하지 말아야 할 것을 말하기보다는

[32:08] 해야 할 것을 말하세요. 다음으로,

[32:11] 최대 토큰 길이를 제어하세요.

[32:13] 이것은 제가 적극적으로 하지는 않는 것이지만

[32:16] 특히 대규모 프로덕션 사용 사례의 경우

[32:18] 지연 시간과 비용을 최적화하는 데

[32:20] 정말 중요합니다. 그리고 대규모나

[32:22] 프로덕션 사용 사례에 대한 또 다른 참고사항은

[32:25] 변수를 사용하는 것입니다.

[32:27] 프롬프트에서 변수를 사용하세요.

[32:28] 여기 예시가 있습니다. 변수들은 다음과 같습니다.

[32:30] 도시 암스테르담 프롬프트, 당신은

[32:33] 여행 가이드입니다. 이 도시에 대한 사실을

[32:35] 말해주세요. 도시, 그리고 앞으로

[32:37] 프로그래밍적으로 원하는 어떤 도시든

[32:39] 여기에 삽입할 수 있습니다. 마지막으로

[32:41] 제가 제안하고 싶은 것은

[32:43] 이 모든 모델들, 그들의

[32:45] 능력이 무엇인지, 한계가 무엇인지에 대해

[32:47] 최신 정보를 유지하는 것입니다. 왜냐하면 그것이

[32:49] 당신이 찾고 있는 것을 얻기 위해

[32:51] 프롬프트를 가장 효과적으로 포맷하는 방법을

[32:53] 아는 데 도움이 될 것이기 때문입니다.

[32:55] 아직 구독하지 않으셨다면 제 채널을

[32:57] 팔로우해주세요. 왜냐하면 그것이

[32:59] 제가 매일 하는 일이기 때문입니다.

[33:00] 제가 여러분께 계속 정보를 제공할 수 있기를 바랍니다.

[33:04] 저는 또한 future.ai를 위한 뉴스레터도

[33:05] 운영하고 있습니다. 같은 내용을 다룹니다.

[33:08] 구글과 특히 이 문서의 저자인

[33:10] 리 본스트라에게 이 프롬프트 엔지니어링

[33:12] 가이드에 대해 감사드립니다.

[33:13] 정말 훌륭합니다. 한번 확인해보세요.

[33:15] 아래 설명란에 링크를 남겨두겠습니다.

[33:17] 이 영상이 마음에 드신다면 좋아요와 구독을