Prompting — Mistral 모델을 이끄는 프롬프트 설계

Mistral 모델을 처음 쓸 때 여러분의 상호작용은 대부분 프롬프트(prompt) 를 중심으로 돌아가요. 좋은 응답을 이끌어내는 핵심은 모델의 능력을 최대로 끌어낼 수 있게 프롬프트를 잘 설계하는 일이에요. 이 페이지에서는 시스템 프롬프트부터 예시 중심 기법까지, 프롬프트의 핵심 개념과 피해야 할 실수를 정리해요.

출처: Mistral Docs — Prompting

핵심 개념

시스템 프롬프트와 사용자 프롬프트

모델에게 지시를 줄 때는 두 가지 입력 레벨이 있어요: system 과 user.

system 프롬프트 는 대화의 시작 부분에 제공되며, 모델 행동의 전반적인 맥락과 지시를 설정해요. 주로 개발자가 관리하죠.
user 프롬프트 는 대화 중에 제공되어 현재 상호작용에 필요한 구체적인 맥락이나 지시를 모델에 전달해요.

개발자로서 필요하면 대화 중에도 user 프롬프트로 추가 맥락을 줄 수 있어요. 만약 system 프롬프트를 통제할 수 없는 상황이라면, 전반적 맥락과 지시를 실제 질문과 이어붙여 user 프롬프트에 함께 넣을 수도 있어요.

역할 분리 예시

{ "role": "system", "content": "system_prompt" }, { "role": "user", "content": "user_prompt" }

이어붙인 예시

{ "role": "user", "content": "system_prompt\n\nUser: user_prompt" }

목적 부여하기 (Roleplaying)

프롬프트의 첫 단계는 명확한 목적(purpose) 을 정의하는 일이에요. 흔히 "You are a <role>, your task is to <task>."처럼 간결한 역할과 과업 정의로 시작해요. 이 단순한 기법이 모델을 특정 도메인과 과업 쪽으로 이끌어, 맥락과 기대 출력을 빠르게 이해하게 만들어요.

구조 잡기

지시를 내릴 때는 계층적이거나 명확한 구조로 정리하세요. 명확한 섹션과 하위 섹션으로 나누는 식이에요.

프롬프트는 명확하고 완결적이어야 해요. 좋은 기준은 사전 맥락이 없는 사람을 위해 쓰고 있다고 상상하는 것—프롬프트만 읽고도 과업을 이해하고 수행할 수 있어야 해요.

구조가 잘 잡힌 프롬프트 예시

You are a language detection model, your task is to detect the language of the given text.
# Available Languages
Select the language from the following list:
- English: "en"
- French: "fr"
- Spanish: "es"
- German: "de"
Any language not listed must be classified as "other" with the code "on".
# Response Format
Your answer must follow this format:
{"language_iso": <language_code>}
# Examples
Below are sample inputs and expected outputs:
## English
User: Hello, how are you?
Answer: {"language_iso": "en"}
## French
User: Bonjour, comment allez-vous?
Answer: {"language_iso": "fr"}

서식 활용하기

서식은 프롬프트 설계에서 매우 중요해요. 다른 섹션을 명시적으로 강조해 모델과 개발자 모두에게 구조를 직관적으로 만들어 주죠. Markdown 이나 XML 스타일 태그가 이상적인 이유는:

읽기 쉬움: 사람이 훑어보기 좋아요.
파싱 쉬움: 프로그램적으로 정보를 추출하기 간단해요.
친숙함: 모델이 학습 중에 많이 봤을 가능성이 높아요.

좋은 서식은 모델이 프롬프트를 이해하는 데 도움을 줄 뿐 아니라, 개발자가 애플리케이션을 반복·유지보수하기에도 편하게 만들어요.

예시 기반 프롬프팅

예시 프롬프팅은 몇 개의 과업 예시를 제공해 모델의 이해도, 정확성, 특히 출력 형식을 개선하는 기법이에요. 구체적으로 few-shot prompting 은 대화 기록에 사용자-모델 간의 인위적 상호작용을 포함하는 방식이에요. 반대로 zero-shot prompting 은 예시 없이 바로 질문하는 방식이죠.

프롬프트 안의 직접 예시

[...]
# Examples
Input: Hello, how are you?
Output: {"language_iso": "en"}
[...]

표준 Few-Shot 구조

[ { "role": "system", "content": "You are a language detection model. Your task is to detect the language of the given text.\n[...]" },
  { "role": "user", "content": "Hello, how are you?" },
  { "role": "assistant", "content": "{\"language_iso\": \"en\"}" },
  { "role": "user", "content": "Bonjour, comment allez-vous?" },
  { "role": "assistant", "content": "{\"language_iso\": \"fr\"}" } ]

구조화된 출력 (Structured Outputs)

프롬프트가 준비되면 이제 출력에 집중할 차례예요. 모델이 구조적이고 예측 가능한 응답을 생성하도록, 특정 JSON 출력 형식을 강제할 수 있어요. 프로그램적으로 파싱·처리하기 쉬운 일관된 구조가 필요한 과업에서 특히 유용하죠. 위 예시에 적용하면 응답 형식이 일관되게 유지되고, 사용할 카테고리를 강제할 수도 있어요.

조언

프롬프트를 만들 때는 유연하게 유지하고 실험해야 해요. 랩마다 다른 모델, 심지어 단순한 업데이트만으로도 모델 행동이 바뀔 수 있고, 한때 잘 맞던 프롬프트도 영향을 받을 수 있어요. 코드와 모델 학습을 반복하듯, 프롬프트도 다시 검토하며 변경의 영향을 평가하는 습관이 필요해요.

피해야 할 것들

주관적·모호한 단어 피하기

"too long", "too short", "many", "few" 같은 모호한 양적 형용사는 피하고, 객관적인 수치를 제시하세요.
"things", "stuff", "write an interesting report", "make it better" 같은 모호한 표현 대신, "interesting"이나 "better"가 무슨 의미인지 정확히 명시하세요.

모순 피하기

시스템 프롬프트가 길어지면 미묘한 모순이 생길 수 있어요. 예를 들어 "새 데이터가 기존 레코드와 관련되면 업데이트하라"와 "데이터가 새 것이면 새 레코드를 만들라"는 규칙이 함께 있으면, 새 데이터가 기존 레코드를 업데이트할지 새로 만들지 불분명해져요. 이런 경우 조건 분기를 명확하게 나누는 게 좋아요.

LLM에게 단어 세기를 요구하지 않기

"레코드가 너무 길면 여러 개로 나눠라" 같은 지시는 규칙을 명확히 하기 어려워요. "레코드가 100자보다 길면 여러 개로 나눠라"처럼 문자 수를 제공하는 편이 낫고, 가능하면 단어 수를 세는 대신 문자 수를 입력으로 제공하는 방식이 더 정확해요.

너무 많은 토큰 생성하지 않기

모델은 토큰을 생성하는 것보다 소화(ingest)하는 쪽이 더 빨라요. 구조화된 출력을 쓴다면 꼭 필요한 것만 생성하도록 요청하세요. 예를 들어 NO_OP 연산에 전체 레코드 내용을 생성한다거나 한 번에 책 전체를 생성하는 건 피하고, 업데이트나 필요한 데이터만 생성하게 해요.

단어형 척도 선호하기

모델에게 무언가를 평가하게 할 때는 숫자 척도보다 단어형 척도가 성능이 더 좋아요. "1~5 척도로 평가하라, 1이 매우 관련 없음, 5가 매우 관련 있음" 같은 지시 대신, 명확한 구간을 단어로 표현하는 게 좋아요.

프롬프팅 예시

Mistral 모델의 대표적인 프롬프팅 능력 네 가지를 예시로 살펴볼게요:

분류(Classification): 텍스트를 정해진 카테고리로 분류하기
요약(Summarization): 긴 내용을 핵심만 추려 요약하기
개인화(Personalization): 사용자 맥락에 맞춘 응답 생성하기
평가(Evaluation): 주어진 기준으로 내용 평가하기

예를 들어 은행 고객 지원 봇의 분류 과업에서, 프롬프트에 미리 정해둔 카테고리 집합을 설정한 뒤 고객 질문을 분류하도록 지시할 수 있어요. "EU에서 카드 사용 가능 여부가 궁금하다"는 질문은 "country_support" 카테고리로 정확히 분류되는 식이에요.

분류용 프롬프트 설계에는 크게 두 가지 전략이 있어요:

라벨 직접 요청: 모델이 한 단어나 문자열로 답하게 하는 방식. 효과적이고 빠르며 저렴하지만, 신뢰성과 유연성은 다소 떨어질 수 있어요.
JSON 출력 요청: 모델이 JSON 객체로 답하게 해 다운스트림에서 쉽게 처리하는 방식. 토큰은 조금 더 쓰지만 복잡한 사용 사례와 유연성에서 더 좋아요.

Prompting — Mistral 모델을 이끄는 프롬프트 설계