Day1 - Prompt Engineering

Created at : 2025-04-11 18:23
Auther: Soo.Y

---

📝메모

Day1 자료

Prompt Engineering | Kaggle Day 1 - Prompting Day 1 - Evaluation and structured output

Prompt engineering

LLM은 일종의 예측 엔진이다. 입력되는 연속된 텍스트를 바탕으로 다음에 오는 단어(토큰)을 하나씩 예측한다. 예측된 토큰은 입력 뒤에 추가되어 다음 토큰을 예측하는데 사용된다. 이 모든 예측은 모델이 훈련 중에 본 데이터를 기반으로 이루어진다.

프롬프트란?

프롬프트(prompt) - 모델에게 작업을 지시하는 입력 문장

• 프롬프트는 LLM이 어떤 응답ㄷ을 생성할지 방향을 제시한다.
• 프롬프트가 잘 설계될수록 더 정확하고 유용한 출력을 얻을 수 있다.

프롬프트 엔지니어링이란?

프롬프트 엔지니어링 = LLM이 원하는 결과를 잘 생성하도록프롬프트를 설계 및 최적화하는 과정 주요 작업

• 고품질의 프롬프트 설계
• 프롬프트 길이 최적화
• 문체 및 구조 조정
• 다양한 시도와 실험을 통해 가장 적합한 형태 찾기

프롬프트로 가능한 작업들

프롬프트를 통해 LLM은 아래와 같은 다양한 작업 수행이 가능하다.

작업 종류	설명
텍스트 요약	긴 문장을 간단하게 요약
정보 추출	문장에서 특정 정보 뽑아내기
질의응답 (QA)	질문에 답변 생성
텍스트 분류	감정 분류, 주제 분류 등
언어/코드 번역	영어 → 한국어, Python → Java 등
코드 생성/설명/추론	코드 작성, 주석 추가, 동작 설명 등

프롬프트 작성 시 유의사항

• 사용하는 모델이 따라 최적화 전략이 다름
  • Gemini, GPT, Claude, Gemma, LLaMA 등
• 모델 설정값(온도, 토큰 수, Top-p 등)도 함께 조절하면 효과적

LLM output configuration

모델을 선택한 후엔? 모델을 선택했다면, 이제 모델 설정을 조정해야 한다. 대부분의 LLM은 출력에 영향을 주는 다양한 설정 옵션을 제공한다. 효과적인 프롬프트 엔저니어링을 위해서는 이 설정들을 과엽(task)에 맞게 조정해야 한다.

Output length

출력 길이(Output length)은 생성할 토큰의 최대 수를 정하는 설정이다.

왜 중요한가? 출력 길이가 길어질수록

• LLM의 계산량이 많아지고
• 에너지 소비 증가
• 응답 시간 지연
• 운영 비용 상승 반대로 출력 길이가 줄인다고 해서 모델이 더 간결하게 글을 쓰는 것은 아니다. → 단지, 정해진 토큰 수에 도달하면 멈출 뿐이다.

프롬프트와의 관계

• 만약 짧은 응답이 필요한 경우, 단순히 출력 길이를 제한하는 것만으로는 부족할 수 있다.
• 이럴 때는 프롬프트 자체도 간결하게 구성해야 원하는 길이의 응답을 유도할 수 있다.

ReAct 등의 기법에서는?

• 일부 프롬프트 전략에서는 원하는 응답 이후에도 LLM이 불필요한 토큰을 계속 생성하는 문제가 발생했다.
• 이때는 출력 길이 제한 설정이 매우 중요하다.

Sampling controls

LLM은 어떻게 토큰을 생성할까? LLM은 다음 토큰을 하나만 정확히 예측하지 않는다. 대신, 모든 토큰에 대해 확률 분포를 예측한다.

• 각 토큰은 다음에 나올 수 있는 확률을 가지고 있음
• 그 확률 분포에서 하나의 토큰을 샘플링해서 출력한다. → 즉, 무작위성이 반영된 예측이다.

LLM의 샘플링 방식은 주로 다음 세 가지 설정으로 조정할 수 있다.

1. Temperature(온도)
2. Top-K
3. Top-P

Temperature

온도(Temperature)는 다음 토큰을 선택할 때 무작위성(randomness)의 정도를 조절하는 설정이다. LLM은 각 토큰에 대해 예측 확률을 계산한다. 온도는 이 확률 분포를 날까롭게 또는 부드럽게 조정해서, 결과가 더 결정적이거나 창의적이 되도록 유도한다.

온도 값에 따른 특징

• 0(zero) : 완전히 결정적(deterministic)으로 항상 가장 높은 확률의 토큰을 선택함. 단, 두 토큰이 동일한 최고 예측 확률을 가질 경우, 동점 해결 방식에 의해 온도 0일 때도 항상 동일한 출력을 얻지 못할 수 있다.
• 최댓값에 가까운 온도는 더 많은 무작위 출력을 생성하는 경향이 있다. 그리고 온도가 높아질수록 모든 토큰이 다음에 예측될 토큰으로 동일한 가능성을 갖게 된다.

Gemini에서의 온도는 Softmax의 T와 유사함

언제 어떤 온도를 쓰면 좋을까?

사용 목적	추천 온도
정답이 정해진 과업 (QA, 분류 등)	0 ~ 0.3
자연스러운 대화, 일반 응답	0.7 ~ 0.9
창의적인 글쓰기, 스토리 생성	0.9 ~ 1.3

Top-K and top-P

LLM이 다음 토큰을 예측할 때 확률이 높은 후보들 중에서만 선택하도록 제한하는 기법들이다.

Top-K 샘플링

• 가장 확률이 높은 K개의 토큰만 후보로 사용
• 그 안에서 무작위로 1개 선택

Top-K 값 K = 1 : Greedy decoding (무조건 확률 1위 토큰 선택) K 작을수록 : 덜 창의적, 더 정확하고 안정적인 응답 K 클수록 : 더 다양한 표현, 창의성 증가

Top-P 샘플링

• 누적 확률이 P 이하가 될 때까지 확률이 높은 토큰들을 유동적으로 선택

예:

• P = 0.9 → 상위 도큰들의 누적 확률이 90%에 도달할 때까지 후보군 생성
• 이 중 무작위로 1개 선택

Top-P 값

• P=0 : Greedy decoding
• P 작을수록 : 보수적, 단정적인 결과
• P 클수록 : 유연하고 창의적, 다양한 후보 고려(P = 1이면 전체 토큰 중 선택 가능)

Top-K, Top-P 무엇을 써야 할까?

• Top-K는 정해진 수(k개)만 고려함
• Top-P는 누적 확률(P) 기준으로 상황에 따라 후보 수가 달라짐 → Top-P가 더 유연하고 자연스러운 결과를 내는 경우가 많음

Tip

• 두 기법은 함께 사용해도 좋다. → 예 : Top-K : 50 and Top-P : 0.95

✅ 요약 비교표

항목	Top-K	Top-P (Nucleus Sampling)
기준	확률 상위 K개의 토큰	누적 확률이 P 이하인 토큰들
고정/유동	고정된 개수	유동적인 개수
K/P 작을 때	더 정확하고 보수적인 출력	더 정제된 예측
K/P 클 때	더 창의적이고 다양한 출력	더 유연하고 풍부한 언어 생성 가능
K=1 or P=0	Greedy decoding (가장 확률 높은 토큰만 사용)

🧾 LLM 샘플링 설정 요약 카드

설정 항목	역할	값이 낮을 때	값이 높을 때	특징 요약
🌡️ Temperature	무작위성 조절	더 결정적이고 예측 가능한 결과 (정확, 일관)	더 창의적이고 다양성 있는 결과 (예측 불가, 실험적)	확률 분포를 날카롭게/부드럽게 만듦
🔢 Top-K	상위 K개 중 선택	상위 몇 개만 선택 → 보수적	선택 폭 넓음 → 창의적	고정된 개수만 후보로 사용
🎯 Top-P (Nucleus Sampling)	누적 확률 P 이내에서 선택	상위 확률 토큰만 선택 → 안정적	다양한 후보 포함 → 풍부한 표현	누적 확률 기준, 동적 후보 수

---

✅ Greedy Decoding 조건

방식	설정
Temperature = 0	무조건 확률 1위 선택
Top-K = 1	1개만 후보
Top-P = 0	누적 확률이 0 넘으면 컷 →

모두 결정적(deterministic) 결과 생성

---

🧠 사용 팁

사용 목적	추천 설정
정답이 있는 작업 (분류, 요약, QA 등)	Temperature = 00.3 Top-K = 1020 Top-P = 0.8~0.9
자연스러운 대화	Temperature = 0.70.9 Top-K = 4050 Top-P = 0.9~0.95
창의적인 글쓰기	Temperature = 1.0 이상 Top-K = 100 이상 Top-P = 0.95~1.0

Putting it all together

Temperature, Top-K, Top-P그리고 생성할 토큰 수를 어떻게 설정할지는 사용 목적과 워하는 출력 결과에 따라 달라집니다. 이 설정들은 서로 영향을 주기 때문에, 선택한 모델이 이 샘프링 설정들을 어떻게 함께 처리하는지 이해하는 것도 중요하다.

설정들이 함께 작동하는 방식

• Temperature, Top-K, Top-P가 모두 사용 가능한 경우
  • 모델은 Top-K 및 Top-P 기준을 모두 통과한 토큰들을 후보로 설정한 뒤, Temperature 값을 적용해 그 후보들 중 하나를 샘플링한다.
• Top-K 또는 Top-P만 사용 가능한 경우
  • 마찬가지로 해당 조건만 적용해 토큰을 선택한다.
• Temperature가 없는 경우
  • Top-K 및/또는 Top-P 기준을 만족하는 토큰들 중 무작위로 하나를 선택해 다음 토큰을 생성한다.

극단적인 설정 값의 영향

샘플링 설정 값이 극단적으로 설정되면, 그 설정이 다른 설정을 무력화하거나 의미 없게 만들 수 있다.

Temperature 관련

• Temperature = 0일 경우
  • Top-K와 Top-P는 무의미해진다.
  • 가장 확률이 높은 토큰이 무조건 선택된다.
• Temperature가 매우 높은 값(예: 1이상, 10대 수치)일 경우
  • Temperature 자체가 무의미해지고, Top-K/Top-P 조건만 만족하면 완전히 무작위로 선택된다.

Top-K 관련

• Top-K = 1일 경우
  • Temperature와 Top-P는 무의미해진다.
  • 가장 확률 높은 1개 토큰만 후보가 되므로, 항상 그 토큰이 선택된다.
• Top-K가 매우 큰 값(예: 모델 전체 어휘 수)일 경우:
  • 확률이 0이 아닌 모든 토큰이 후보가 되며, 실질적으로 선택에서 제외되는 토큰이 없음

Top-P 관련

• Top-P = 0일 경우
  • 대부분의 구현에서 가장 확률 높은 단 하나의 토큰만 후보가 됨
  • Temperature 및 Top-K는 무의미해짐
• Top-P = 1일 경우
  • 확률이 0이 아닌 모든 토큰이 후보가 되며, 실질적으로 제거되는 토큰 없음

🎯 추천 시작점 (설정 예시)

목적	추천 설정
균형 잡힌 결과 (적당히 창의적이고 논리적인 응답)	Temperature = 0.2 Top-P = 0.95 Top-K = 30
창의성 강조	Temperature = 0.9 Top-P = 0.99 Top-K = 40
정확성 강조 (논리적 문제 해결 등)	Temperature = 0 (Top-K, Top-P는 무의미해짐)
덜 창의적인 응답 희망 시	Temperature = 0.1 Top-P = 0.9 Top-K = 20

주위! 설정을 더 자유롭게 할수록 모델이 덜 관련성 있는 문장을 생성할 위험도 커진다.

반복 루프 현상(Repetition Loop Bug)

LLM 응답이 같은 단어 또는 문장을 반복하며 끝나는 현상, 즉 채움말(Filler word)이 길게 이어지는 버그를 경험한 적 있나요? 이것이 바로 Repetition Loop Bug 즉 모델이 반복적인 구조에 갇히는 일반적인 현상이다. 이 현상은 다음과 같은 설정에서 발생할 수 있다.

Temperature가 낮을 때(과도한 결정성)

• 모델이 항상 가장 높은 확률인 경로만 고집하게 되고 이전 출력과 반복되는 경로로 빠지게 된다.

Temperature가 높을 때(과도한 무작위성)

• 무작위로 선택된 단어가 우연히 이전 문장을 다시 유도할 수 있음
• 후보 토큰 수가 많아질수록, 이전 상태로 돌아갈 가능성도 커짐 → 순환 루프에 빠지게 됨

해결방법

• Temperature, Top-K, Top-P 값을 세심하게 조정하여 결정성과 무작위성 사이의 균형점을 찾아야 한다.

Prompting techniques

LLM은 지시를 따르도록 튜닝되어 있으며, 방대한 데이터로 학습되어 있기 때문에, 프롬프트를 이해하고 그에 따른 응답을 생성할 수 있다. 하지만 LLM은 완벽한 존재는 아니다. 따라서 프롬프트가 명확하고 구체적일수록 LLM이 적절한 다음 텍스트를 예측하는 데 더 도움이 된다.

또한, LLM이 어떻게 학습되고 작동하는지를 이해하고 그에 맞춰 프롬프트를 설계하는 특정 기술들을 사용하면 훨씬 더 정확하고 원하는 결과를 얻을 수 있다. 이제 우리는 프롬프트 엔지니어링이 무엇인지, 그리고 어떤 요소들이 필요한지를 이해했으니, 지금부터는 가장 핵심적인 프롬프팅 기법들에 대해 알아보겠다.

General prompting / zero shot

제로샷(Zero-shot) 프롬프트는 가장 간단한 형태의 프롬프트이다. 이 방식은 단순히 작업에 대한 설명과 시작할 텍스트만 LLM에게 제공한다. 이 입력은 질문, 이야기의 시작, 지시문 등 어떤 형태든 가능하다. 제로샷이라는 이름은 예시가 전혀 없다는 뜻이다.

실습 예시(Vertex AI Studio 사용)

예를 들어 Vertext AI의 Vertex AI Studio(언어용)를 사용하면 프롬프트를 실험해볼 수 있는 플레이그라운드 환경이 제공된다. 아래 표에는 영화 리뷰를 분류하는 제로샷 프롬프트의 예시가 나와 있다.

프롬프트 문서화 Tip 위와 같은 표 형태로 프롬프트를 정리하는 것은 프롬프트를 기록하고 관리하는 데 매우 좋은 방법이다. 프롬프트는 코드베이스에 들어가기 전까지 여러 번 수정과 실험을 거치게 되므로, 구조화된 방식으로 프롬프트 엔지니어링 과정을 기록하는 것이 중요하다.

예시 프롬프트의 포인트

• 문장에 disturbing(불편한)과 masterpiece(걸작)라는 상반된 단어가 함께 포함되어 있어 모델에게는 조금 더 어려운 분류 작업이 된다.

다음 단계: One-shot / Few-shot

• 만약 제로샷 프롬프트가 제대로 작동하지 않는다면, 프롬프트에 예시를 한두 개 추가할 수 있다.
• 이런 방식이 바로 원샷(one-shot) 또는 퓨삿(few-shot) 프롬프팅으로 이어진다.

One-shot & few-shot

AI 모델을 위한 프롬프트를 만들 때, 예시를 함께 제공하는 것이 매우 도움이 된다. 이러한 예시는 모델이 무엇을 요구하는지 이해하고 원하는 출력 구조나 패턴을 따르도록 유도하는 데 효과적이다.

One-shot 프롬프팅

• 예시 1개만 제공하는 방식
• 이름처럼 한 번의 샷으로 모델이 참고할 수 있는 패턴을 단 하나 보여주는 프롬프팅
• 모델은 그 예시를 모방(imitate)하여 작업을 수행

Few-shot 프롬프팅

• 2개 이상의 예시를 제공하여, 모델이 따라야 할 명확한 패턴을 학습한다.
• One-shot과 원리는 같지만, 예시가 여러 개이기 때문에 모델이 패턴을 더 잘 파악하고 일관성 있는 응답을 생성할 확률이 높아진다.

Few-shot에서 필요한 예시 수는?

예시 개수는 아래 조건에 따라 달라질 수 있습니다:

조건	설명
🧩 작업의 복잡도	복잡할수록 더 많은 예시 필요
✨ 예시의 품질	고품질 예시일수록 적은 수로도 가능
🧠 사용하는 모델의 성능	고성능 모델일수록 적은 예시로도 학습 가능
🔠 입력 길이 제한	예시가 많아지면 전체 입력 길이를 초과할 수 있음

📌 일반적으로는 3~5개의 예시가 권장되지만, 작업에 따라 더 많거나 적게 조절할 수 있습니다.

Parse a customer's pizza order into valid JSON:
 
EXAMPLE:
I want a small pizza with cheese, tomato sauce, and pepperoni.  
JSON Response:  
{
  "size": "small",
  "type": "normal",
  "ingredients": [["cheese", "tomato sauce", "peperoni"]]
}
 
EXAMPLE:
Can I get a large pizza with tomato sauce, basil and mozzarella  
JSON Response:  
{
  "size": "large",
  "type": "normal",
  "ingredients": [["tomato sauce", "bazel", "mozzarella"]]
}
 
Now, I would like a large pizza, with the first half cheese and mozzarella.  
And the other tomato sauce, ham and pineapple.  
JSON Response:
{
  "size": "large",
  "type": "half-half",
  "ingredients": [["cheese", "mozzarella"], ["tomato sauce", "ham", "pineapple"]]
}
 

예시 선택 시 유의사항

• 예시는 반드시 과업과 밀접하게 관련된 내용이어야 한다.
• 예시는 다양성 있게, 잘 작성된 문장으로, 명확하게 정확하게 구성되어야 한다.
• 예시 중 작은 실수 하나만 있어도, 모델이 혼란을 겪어 원하지 않는 출력을 생성할 수 있다.

엣지 케이스 포함하기

• 다양한 입력에 유연하게 대응하는 출력을 원한다면, 예시에 엣지 케이스를 포함시키는 것이 중요하다.
• 엣지 케이스란? 일반적이지 않거나 예상치 못한 입력이지만 모델이 여전히 올바르게 처리해야 하는 경우이다.

System, contextual and role prompting

시스템 프롬프트(system prompting), 컨텍스트 프롬프트(contextual prompting), 역할 프롬프트(role prompting)는 LLM의 출력 결과를 조절하는 데 사용하는 대표적인 프롬프트 기법들이다. 이들은 모두 모델이 어떤 식으로 텍스트를 생성할지 유도하지만, 각각 초점이 다른다.

1. 시스템 프롬프트
   • 모델의 전체 목적과 동작 범위를 설정한다.
   • “모델이 전반적으로 어떤 역할을 해야 하는지”를 정의한다.
   • 예
     • 너는 영어 문장을 한국어로 번역하는 번역가야
     • 너는 사용자의 리뷰를 분류하는 AI야
2. 컨텍스트 프롬프트
   • 현재 대화나 작업에 구체적인 배경 정보를 제공한다.
   • 요청의 뉘앙스나 세부 사항을 이해하는 데 도움을 준다.
   • 예
     • 이 영화 리뷰는 10대가 작성한 것이며, 감정 분석을 요청받았어
     • 이 문장을 1800년대 고전 문학에서 발췌된 것이야
3. 역할 프롬프트
   • 모델에게 특정 인물이나 정체성을 부여한다.
   • 이를 통해 출력의 어조, 스타일, 지식 수준 등을 일관되게 유지할 수 있다.
   • 예
     • 너는 유명한 세프야. 요리 레시피를 설명해줘.
     • 너는 AI 의사야. 증상 기반 진단을 도와줘

서로 섞어서 사용할 수도 있다. 이 세가지는 때때로 서로 겹칠 수 있다. 예를 들어, 역할을 설정하는 프롬프트가 동시에 배경 정보(컨텍스트)를 담고 있을 수 있다. 하지만, 각 유형을 구분해서 설계하면 다음과 같은 이점이 있다.

• 프롬프트의 목적이 더 명확해지고,
• 조합이 더 유연해지며,
• 어떤 요소가 모델의 출력에 영향을 주는지 분석하기 쉬워진다.

System prompting

표3에서는 시스템 프롬프트의 예시가 포함되어 있으며, 여기서 나는 출력을 어떻게 반환해야 하는지에 대한 추가 지침을 명확히 지정했다.

• 더 높은 창의성을 유도하기 위해 temperature 값을 증가시켰고
• token 제한도 늘렸다. 하지만 출력 형식에 대한 명확한 지시를 했기 때문에, 모델은 불필요한 텍스트 없이 지정한 형식대로만 응답을 생성했다.

시스템 프롬프트의 역할 시스템 프롬프트란 이름은 실제로 시스템에게 추가 작업을 부여하는 프롬프트를 의미한다. 예를 들어, 다음과 같은 목적으로 사용할 수 있다.

• 특정 프로그래밍 언어에 호환되는 코드 스니펫 생성
• 출력이 특정 구조나 형식(예: JSON, table 등)을 따르도록 유도

예시 - JSON 형식 출력(표4) 표 4에서는 모델이 JSON 형식으로 출력을 생성하도록 유도했다. 이러한 형식은 특히 데이터 추출 과제에서 매우 유용하다.

JSON 출력의 장점

• 애플리케이션에서 수동으로 JSON을 생성할 필요 없음
• 정렬된 데이터를 자동으로 반환 가능
• 예 : datetime 객체를 시간순 형태로 받기 쉬움
• 가장 중요한 점 : 모델이 구조화된 형식으로 출력하도록 강제하므로 환각(hallucination)을 줄이는 데 큰 효과

시스템 프롬프트의 또 다른 장점: 안전성 제어

• 시스템 프롬프트는 출력의 톤이나 어조를 조절하는 데도 매우 유용하다.
• 예

"You should be respectful in your answer."

이와 같은 한 줄을 추가하는 것만으로도 모델이 생성하는 응답을 더 정중하고, 비폭력적이며, 편향 없는 방향으로 유도할 수 있다.

Role prompting

역할 프롬프트는 프롬프트 엔지니어링 기법 중 하나로, 생성형 AI 모델에게 특정 역할(Role)을 부여하는 방식이다. 역할을 부여하지만, 모델이 그 역할에 맞춰 더 관련성 있고 정보성 있는 응답을 생성할 수 있게 된다. 즉, 응답의 어조, 내용, 방식이 역할에 따라 달리지는 것이다.

예시

• 책 편집자 (Book editor)
• 유치원 선생님 (Kindergarten teacher)
• 동기부여 강사 (Motivational speaker)

역할 변경에 따른 응답 차이

• 동일한 프롬프트라도, 예를 들어 역할을 “지리 교사”로 바꾸면, 모델의 응답은 지리 교육 중심의 설명으로 바뀌게 된다.
• 이처럼 역할을 정해주는 것만으로도 모델의 전문성, 말투, 표현 방식이 눈에 띄게 달라진다.

역할 프롬프트의 효와 역할을 정의하는 것은 모델에게 어떤 톤, 스타일, 전문성 범위를 사용할지에 대한 설계도를 제공하는 것이다. 이를 통해 다음을 향상시킬 수 있다.

• 출력의 품질
• 응답의 적절성
• 결과의 효과성

추천 스타일 목록 다음은 다양한 역할 스타일 중 효과적이라고 여겨지는 예시들이다.

• Confrontational (직설적이고 논쟁적인)
• Descriptive (묘사 중심)
• Direct (직접적이고 간결한)
• Formal (격식 있는)
• Humorous (유머러스한)
• Influential (영향력 있는)
• Inspirational (영감을 주는)
• Persuasive (설득력 있는)

Contextual prompting

컨텍스트 프롬프팅(Contextual Prompting)은 프롬프트 안에 배경 정보나 상황(context)을 함께 제공하여 모델이 사용자의 의도를 더 빠르고 정확하게 이해하고, 더 관련성 높은 응답을 생성할 수 있도록 돕는 기법이다.

목적

• AI와의 상호작용을 더 자연스럽고 효율적으로 만들기 위해 사용된다.
• 배경 정보를 함께 주면, 모델은 사용자의 요청을 더 잘 파악하고 실제 상황에 맞는 정확한 응답을 생성할 수 있다.

Step-back prompting

스텝백(Step-back) 프롬프팅은 LLM의 성능을 향상시키기 위한 기법으로, 지금 당장 해결하려는 구체적인 문제로 바로 들어가지 않고, 먼저 그와 연관된 일반적인 질문을 모델에 던져 그 일반 질문에 대한 응답을 바탕으로 다음 단계의 실제 작업을 수행하는 방식이다.

왜 “Step-back”이 필요한가?

• 이 “한 걸음 물러서기(step-back)” 과정은 LLM이 문제를 해결하기 전, 관련된 배경지식과 사고과정을 활성화하게 도와준다.
• 덕분에 모델은 더 정확하고 깊이 있는 응답을 생성할 수 있다.

효과와 이점

• 배경 지식 활성화 : 모델이 보유한 일반적인 개념을 먼저 떠올릴 수 있게 유도
• 비판적 사고 강화 : 모델이 단순 응답보다 더 논리적인 구조로 사고하게 함
• 창의력 향상 : 더 넓은 맥락을 고려해 새롭고 유용한 방식으로 지식을 적용
• 편향 완화 : 구체적인 정보 대신 일반 원칙에 집중함으로써 편향을 줄임

📊 Step-back Prompting 예시 비교 (표 8 vs 표 9)

✅ 표 8: 기존 프롬프트 (기본 접근 방식)

항목	내용
🎯 Goal	1인칭 슈팅 게임의 새로운 레벨을 위한 스토리라인 작성
🧠 Prompt	Write a one paragraph storyline for a new level of a first-person shooter video game that is challenging and engaging.
🔧 설정	Model: gemini-pro / Temperature: 1 / Token Limit: 1024 / Top-K: 40 / Top-P: 0.8
📝 Output	도심에서 매복 공격 → 골목과 폐허 건물 돌파 → 적 제거 및 은신 → 함정과 엄폐물 활용 → 적의 공격 계획을 탐지 후 시간 내에 본부로 복귀

▶️ 즉각적인 요청 → 직접 생성,
하지만 아이디어의 창의성이나 다양성 측면에선 제한적일 수 있음.

✅ 표 9: Step-back 프롬프트

항목	내용
🎯 Prompt	Based on popular first-person shooter action games, what are 5 fictional key settings that contribute to a challenging and engaging level storyline in a first-person shooter video game?
📝 Output

1. 버려진 군사 기지 – 돌연변이 병사와 로봇이 있는 포스트 아포칼립스 배경
2. 사이버펑크 도시 – 첨단 기술과 해킹, 밀집된 도시 공간
3. 외계인 우주선 – 중력 없음, 외계 생명체와의 조우
4. 좀비 도시 – 퍼즐과 근접 전투 중심의 생존
5. 해저 연구소 – 잠수, 은신, 물속 괴물들 회피

▶️ 먼저 일반적인 맥락을 모델에게 제시한 뒤, 그 결과를 기반으로 다음 단계 프롬프트에 활용 가능

🧠 효과 비교 요약

항목	기존 프롬프트 (표 8)	Step-back 프롬프트 (표 9)
접근 방식	바로 스토리 작성 요청	먼저 배경 아이디어 수집 후 사용
창의성	비교적 단일한 흐름	다양한 설정과 구조 창출 가능
정보 활용	제한적	모델의 잠재 지식 적극 활용
응답 다양성	중간	높음
응답 품질	실용적이나 평범할 수 있음	풍부하고 독창적인 배경 제시 가능

✅ 결론: Step-back Prompting의 강점

• 모델이 일반적인 원칙이나 배경지식을 먼저 떠올릴 수 있게 유도하면
  👉 더 정확하고 창의적인 결과 생성 가능

• 결과적으로, Step-back 프롬프팅은
  단순 생성 요청보다 더 뛰어난 아이디어와 통찰을 유도합니다.

Chain of Thought(CoT)

Chain of Thought(CoT) 프롬프팅은 LLM의 추론 능력을 향상시키기 위해 중간 단계의 추론 과정(reasoning steps)을 생성하도록 유도하는 기법이다. 이러한 방식은 LLM이 더 정확한 정답을 내놓을 수 있도록 도와준다.

CoT 기법이 유용한 이유

• 특히 복잡한 작업에서는 zero-shot만으로는 한계가 있기 때문에, few-shot 프롬프팅과 CoT를 함께 사용하면 훨씬 좋은 결과를 얻을 수 있다.

CoT의 장점

• 쉽고 효과적 : 별도 미세조정 없이도, 기본 LLM으로 가능
• 해석 가능성 향상 : 중간 추론 과정을 통해 어디서 문제가 생겼는지 파악 가능
• 버전 간 호환성 : 다른 LLM 버전에서도 출력 일관성 유지 가능
• 복잡한 문제 해결 : 단계별 사고를 통해 계산, 논리 문제에서 성능 향상

CoT의 단점

• 비용 증가 : 추론 과정이 길어져서 토큰 수 증가 → 비용, 지연 시간 증가
• 응답 길이 증가 : 모든 단계가 출력에 포함되기 때문에 출력이 더 김

예시로 보는 CoT의 효과

표 11 : CoT없이 단순 정답만 요청한 경우

Prompt

When I was 3 years old, my partner was 3 times my age. Now, I am 20 years old. How old is my partner?

Output

63 years old ← ❌ 틀린 답

표 12: Zero-shot CoT 적용 예

Prompt

When I was 3 years old, my partner was 3 times my age. Now I am 20 years old. How old is my partner?
Let’s think step by step.

Output (요약)

1. 내가 3살일 때, 파트너는 3 × 3 = 9살
2. 이후 나는 17살이 더 많아졌고
3. 파트너도 똑같이 17살 더 나이 먹음 → 9 + 17 = 26살

🟢 최종 정답: 26세 ← 정확!

표 13: One-shot CoT 적용 예

Prompt

Q: When my brother was 2 years old, I was double his age. Now I am 40 years old. How old is my brother? Let’s think step by step. A: 나이 차는 2세. 지금 나는 40살 → 동생은 38살.

Q: When I was 3 years old, my partner was 3 times my age. Now, I am 20 years old. How old is my partner? Let’s think step by step. A:

Output (생략 요약)
→ 파트너는 26세

📌 한 가지 예시를 먼저 보여주면 모델이 유사한 사고 흐름을 따라가기 쉬워짐

CoT가 잘 작동하는 상황

• 수학 문제, 논리 추론, 단계별 코딩, 텍스트 생성
• 예:
  • 코드 생성 시 → 요구사항을 단계별로 분해
  • 상품 설명 생성 시 → 이름 기반 가정들을 하나씩 유도
  • 데이터 가공 시 → 입력 → 전처리 → 출력 포맷 단계로 분리

결론적으로 문제 해결 과정을 말로 설명할 수 있다면, Chain of Thought를 적용할 수 있다.

Self-consistency

대형 언어 모델은 다양한 자연어 처리 과제에서 인상적인 성능을 보였지만, 추론 능력은 여전히 모델 크기만으로 극복하기 어려운 제한점으로 간주된다. 앞서 설명한 CoT 프롬프팅에서는 모델이 사람처럼 문제를 해결하는 방식의 중간 추론 과정을 유도할 수 있다. 하지만 CoT는 주로 Greedy decoding(가장 높은 확률의 토큰을 순차적으로 선택하는 방식)을 사용하기 때문에 출력 다양성과 창의성이 제한된다는 단점이 있다.

Self-consistency란? Self-consistency(가지 일관성)는 이러한 한계를 보완하기 위해 다양한 추론 경로를 생성한 후, 다수결 방식을 통해 가장 일관된 정답을 선택하는 기법이다. 즉, 같은 프롬프트를 여러 번 모델에 입력하여 다양한 응답을 받고, 그 중 가장 많이 등장한 정답을 최종 답으로 채택한다.

**Self-Consistency 프롬프팅 절차 **

1. 다양한 추론 경로 생성
   • 동일한 프롬프트를 여러 번 모델에 전달
   • Temperature 값을 높게 설정하여 다양한 경로와 관점을 유도
2. 각 응답에서 최종 정답 추출
   • 응답마다 모델이 도출한 최종 판단 값을 추출
3. 다수결 방식으로 최종 정답 결정
   • 가장 빈도가 높은 답변을 최종 정답으로 간주

Self-Consistency 적용법

• 같은 프롬프트를 여러 번 모델에 전달
• 예를 들어 5~10회 반복
• 각 결과에서 나온 최종 판단만 추출
  • 예: “IMPORTANT”, “NOT IMPORTANT”
• 가장 많이 나온 결과 선택

왜 이 기법이 필요한가?

• 예시 이메일에 친근한 말투, 유머, 역설적인 표현등을 사용하여 모델을 혼란스럽게 만들 수 있다.
• 어떤 LLM은 이 메시지를 유쾌한 리뷰로 해석할 수 있고 보안 위협으로 판단할 수 있기 때문이다.
• Self-consistency는 이러한 애매한 상황에서 모델의 응답 안정성과 일관성을 향상시키는 데 큰 도움이 된다.

Tree of Thoughts(ToT)

ToT는 단순히 한 줄로 이어지는 사고 경로(CoT) 대신, 다양한 사고 경로를 동시에 탐색할 수 있도록 LLM을 유도한다.

Tree of Thoughts란? 하나의 문제 해결을 위한 사고 흐름을 나무 구조(tree)로 표현하는 방식이다.

• 각각의 thought는 문제 해결을 향한 중간 언어 시퀀스를 의미한다.
• 이 “생각”들은 “노드(node)“로 삼아, 다양한 경로로 브랜칭하며 탐색을 진행한다.
• 모델은 특정 경로에 얽매이지 않고 서로 다른 방향의 사고 흐름을 병렬로 탐색할 수 있다.
• 이러한 점에서 단일 선형 흐름을 따르는 CoT보다 훨씬 유연하고 강력한 구조라고 할 수 있다.

ToT가 적합한 상황

• 복잡한 문제 해결 : 다양한 조건이나 해석이 가능한 문제
• 탐색 기반 문제 : 최적 경로, 전략 수립, 조합적 문제
• 대화 설계 : 사용자 목적을 파악해 여러 후보 응답 생성 후 평가 가능
• 게임, 추론, 플래닝 : Tree 구조나 사고 확장의 자연스러운 도구가 되는 문제들

ReAct(reason & act)

Automatic Prompt Engineering

Code prompting

Prompts for writing code

Prompts for explaining code

Prompts for translating code

Prompts for debugging and reviewing code

What about multimodal prompting?

Best Practices

Provide examples

Design with simplicity

Be specific about the output

Use Instructions over Constraints

Control the max token length

Use variables in prompts

Experiment with input formats and writing styles

For few-shot prompting with classification taks, mix up the classes

Adapt to model updates

Experiment with output formats

JSON Repair

Working with Schemas

Experiment together with other prompt engineers

CoT Best practices

Document the various prompt attempts

---

📜출처(참고 문헌)

---

🔗연결 문서