프롬프트 엔지니어링 기법

01

프롬프트는 무엇으로 이루어지나

프롬프트는 AI에게 보내는 글입니다. 질문이어도 되고 부탁이나 지시여도 됩니다.

요즘 쓰는 대화형 AI의 바탕에는 대규모 언어 모델(LLM)이 있습니다. LLM은 답을 한 번에 쓰지 않습니다. 앞에 놓인 글을 보고 다음에 올 말 조각을 하나 고르고, 그걸 붙인 다음 또 다음 조각을 고릅니다. 휴대폰 자판이 다음 단어를 추천해 주는 기능을 아주 크게 키운 것과 비슷합니다. 그래서 프롬프트에 어떤 말이 들어 있느냐에 따라 모델이 고르는 말이 달라집니다. 프롬프트 엔지니어링은 이걸 이용해서, 원하는 답이 나올 가능성이 높아지도록 글을 짜는 일입니다.

잘 짠 프롬프트를 뜯어 보면 보통 아래 재료가 들어 있습니다. 매번 다 넣어야 하는 건 아닙니다.

이해를 돕기 위해 이 글에서는 예제 하나를 끝까지 씁니다. 쇼핑몰 리뷰를 읽고 손님이 만족했는지, 불만인지, 둘 다인지 AI에게 가려 달라고 하는 일입니다. 처음에는 한 줄짜리 부탁으로 시작해서, 답이 마음에 안 들 때마다 왜 그런지 따져 보고 그걸 고치는 방법을 하나씩 붙여 갑니다. 표의 오른쪽 칸이 이 예제에 들어갈 재료입니다.

장마다 이 예제를 3D 그림으로 볼 수 있습니다. 왼쪽에 쌓인 블록은 우리가 보낸 글(프롬프트), 가운데 구슬은 AI 모델, 오른쪽 막대는 모델이 내놓을 수 있는 답입니다. 막대가 높을수록 그 답이 나올 가능성이 큽니다. 막대 높이는 흐름을 보여 주려고 정한 예시 값입니다.

첫 그림에서는 재료를 하나씩 더해 보세요. 지시와 리뷰만 있을 때는 막대가 여기저기 흩어져 있습니다. 재료가 늘수록 우리가 원하는 답인 'JSON으로 된 mixed' 막대가 올라갑니다.

프롬프트를 쓸 때 기본 요령

AI 서비스를 만드는 회사들이 안내서에서 공통으로 권하는 요령입니다.

• 할 일을 짧고 분명하게, 빠뜨리지 말고 씁니다.
• 질문이나 지시는 글 맨 끝에 둡니다.
• 지시와 처리할 데이터 사이를 구분 기호로 나누고, 답의 모양을 구체적으로 적습니다.
• 답을 모를 때 어떻게 할지 정해 줍니다. 예: "모르면 '모르겠습니다'라고 답하세요."
• 프롬프트는 연습용 데이터로 다듬고, 마지막 확인은 따로 남겨 둔 데이터로 한 번만 합니다.

어떤 재료를 넣느냐에 따라 기법 이름이 달라집니다. 지시와 입력만 넣으면 제로샷, 예시를 더하면 퓨샷, 풀이 과정을 쓰라고 하면 사고의 연쇄입니다. 가장 적게 넣는 제로샷부터 봅니다.

02

예시 없이 시키기 (제로샷)

예시를 하나도 주지 않고 할 일만 말하는 방식입니다. 제로(0)는 예시 개수를 뜻합니다. 우리가 평소 AI 채팅창에 질문을 던질 때 대부분 이렇게 씁니다.

리뷰의 감정을 분류하세요.
리뷰: 배송은 늦었지만 제품은 훌륭해요

모델은 이미 엄청난 양의 글을 읽고 학습했기 때문에 이 정도 부탁은 예시가 없어도 알아듣습니다. 요약, 번역, 흔한 분류처럼 모델이 원래 잘하는 일은 제로샷으로 충분할 때가 많습니다. 준비할 게 없고 글이 짧아서 비용도 가장 적게 듭니다.

아쉬운 건 답의 모양입니다. 위 부탁에는 어떤 형식으로 답하라는 말도, 칭찬과 불만이 섞인 리뷰는 어떻게 하라는 말도 없습니다. 그러면 모델은 그때그때 그럴듯한 답을 냅니다. 한 번은 "긍정", 한 번은 긴 설명 문단, 한 번은 JSON이 나옵니다. 사람이 읽을 때는 괜찮아도, 프로그램이 답을 받아서 처리해야 한다면 곤란합니다.

답이 들쭉날쭉한 건 모델이 우리가 원하는 답을 모르기 때문입니다. 원하는 형식과 기준을 글로 길게 설명할 수도 있지만, 원하는 답을 직접 보여 주는 편이 더 빠릅니다.

03

원하는 답을 보여 주기 (원샷·퓨샷)

제로샷 프롬프트에 "이런 입력에는 이렇게 답하라"는 본보기를 붙이는 방식입니다. 본보기가 1개면 원샷, 2개 이상이면 퓨샷이라고 부릅니다. 퓨(few)는 '몇 개'라는 뜻입니다. 시험에 따라 원샷을 single-shot, 단일 샷이라고 쓰기도 합니다.

리뷰의 감정을 분류하세요.

리뷰: 포장이 꼼꼼해요
답: {"label":"positive"}

리뷰: 맛은 좋은데 양이 적어요
답: {"label":"mixed"}

리뷰: 배송은 늦었지만 제품은 훌륭해요
답:

본보기만 보여 줘도 왜 따라 할까

1장에서 모델은 앞의 글을 보고 다음 말을 고른다고 했습니다. 위 프롬프트에는 "리뷰 다음 줄에 JSON 한 줄"이 두 번 반복됩니다. 그러면 세 번째 리뷰 뒤에 올 가장 자연스러운 글은 같은 모양의 JSON입니다. 모델은 따로 배운 게 없는데도 프롬프트 안의 패턴을 이어 씁니다. 이걸 맥락 내 학습(in-context learning)이라고 합니다.

이름에 '학습'이 들어가지만 모델은 바뀌지 않습니다. 다음 요청에서 예시를 빼면 모델은 아무것도 기억하지 못합니다. 그래서 예시는 요청할 때마다 다시 넣어야 하고, 그만큼 보내는 글이 길어져 비용이 늘어납니다.

아래 그림에서 예시를 0개부터 5개까지 늘려 보세요. 답의 모양(JSON)은 예시 한두 개만 넣어도 금방 맞춰집니다. 그런데 "칭찬과 불만이 섞이면 mixed"라는 기준은 그런 리뷰가 담긴 세 번째 예시가 들어가야 잡힙니다. 예시는 몇 개를 넣느냐보다 무엇을 보여 주느냐가 더 큰 차이를 만듭니다.

예시는 어떻게 고르나

• 실제로 들어올 리뷰와 비슷한 예시를 고릅니다.
• 헷갈리는 경우를 꼭 넣습니다. 쉬운 예시만 있으면 어려운 리뷰가 들어왔을 때 다시 흔들립니다.
• 답이 한쪽으로 몰리지 않게 섞습니다. 예시가 전부 positive면 답도 positive 쪽으로 기웁니다.
• 예시끼리 형식을 똑같이 맞춥니다. 예시 모양이 제각각이면 답 모양도 제각각입니다.

예시를 주면 답의 모양과 기준은 잡힙니다. 그런데 계산을 여러 번 거쳐야 답이 나오는 문제는 예시만으로 부족합니다. 예시에 정답만 적혀 있으면 모델은 중간 계산을 건너뛰고 정답처럼 보이는 숫자를 바로 고르다가 틀리곤 합니다.