By 이태호 in Tech — May 29, 2023

Prompt Engineering의 가치

Photo by Aaron Burden / Unsplash

회사 동료인 홍 님과 논문물어오는아기고양이 님과 4시간 동안 다음 주제에 대해서 토론했다.

Prompt Engineering (PE)은 대체 불가능한 가치가 있는가?

나: PE는 앞으로 절대 없어지지 않을 대체 불가능한 가치를 가진다.

논문물어오는아기고양이: PE는 LLM의 기본을 온전히 이해하고 있는 사람들에게 밀리게 될 것이다. open-source LLM이 OpenAI의 LLM과 유사한 수준일 때를 가정한다.

정말 여러 관점에서 토론을 했는데 간단하게 요약을 해보겠다.

PE의 정의

LLM을 black-box로 생각함
human이 zero-shot inference를 했을 때 스스로 마음에 들 때까지 프롬프트를 튜닝하는 과정
정량적인 metric은 존재하지 않음
Act as 같은, stable diffusion 1.5에서만 먹히는 테크닉 같은 Prompt Engineering은 이번 토론에서 고려하지 않는다. 특정 모델에서만 잘 먹히는 테크닉은 LLM의 발전에 따라 없어질 수 있으므로 이런 것에 대한 가치는 점차 사라지게 됨에 모두가 동의한다.
LLM이 궁극적으로 발전하는 방향은 특정 technic에 좌지우지되는 모델이 아니며 구조적인 프롬프트에 더 잘 동작하는 모델이다.
"구조적인 코드"는 코드를 이해하기 쉽고, 기능 추가 및 수정을 쉽게 만든다. "구조적인 프롬프트"는 구조적인 코드와 같은 가치를 지닌다. fine-tuning(FT) 등과 같은 기법이 적용 불가능한 상황이라면 프롬프트 엔지니어링의 실력에 따라 유저가 얻을 수 있는 가치가 바뀔 수 있음에 모두가 동의한다.

0. open-source LLM FT vs OpenAI LLM PE

현재 open-source LLM과 OpenAI LLM의 성능 차이는 유의미하게 난다.
다만 OpenAI LLM은 general한 모델이므로 open-source LLM을 fine-tuning하여 specific한 domain 으로 가져 가면 open-source LLM이 이길 가능성이 있다.
정확한 성능 비교가 어려우므로 이후로부터는 OpenAI LLM이 open-source라는 가정을 두기로 했다.

=> Assumption: OpenAI LLM이 open-source

1. FT vs PE

1.1. FT vs PE (충분한 데이터가 존재할 때, 단 하나의 태스크만 수행할 때)

Prompt Template (PT)이 다음처럼 존재

Prompt Template
```xxxxxx
{input1}
yyyyy
{input2}
zzzzzzzzz
{input3}
```

=>

{output}

Fine-tuning Data

{input1}
{input2}
{input3}

=> 

{output}

PE는 zero-shot or few-shot이다.
데이터가 충분히 있다면 그 데이터로 하나의 태스크에 최적화시키는 FT가 few-shot PE보다 무조건 더 낫다. general space를 다루는 모델을 specific space로 좁히면서 버린 다른 space에서의 성능 만큼 specific space에서 성능 향상이 존재한다.
fine-tuning하면 xxx, yyy, zzz에 대한 토큰을 처리하지 않게 되므로 cost 절약 가능하다
forward 3번이 backprop 1번과 computational cost가 유사한데 PE로 서비스를 돌리는 것보다 FT를 하고 서비스를 하는 것이 computational cost 절약 가능하다
fine-tuning은 instruction compression 기법 같은 느낌이다

FT >> PE

1.2. FT vs PE (데이터 개수가 적을 때, 단 하나의 태스크만 수행할 때)

Few-Shot Parameter-Efficient Fine-Tuning is Better and Cheaper than In-Context Learning

- https://arxiv.org/pdf/2205.05638

연구에서 few-shot PEFT > PE 라고 함

FT >> PE

1.3. FT vs PE (데이터 개수가 적을 때, 태스크가 많을 때)

태스크가 여러 개라면 fine-tuning했을 때 유저의 인풋이 들어왔을 때 어떤 태스크를 수행해야 될지 라우팅이 불가능하다. PE면 PT를 변경하는 방식으로 라우팅 가능하다.
그렇지 않다. FT일 때 태스크별 adapter를 따로 만들고 adapter로 라우팅하면 된다.

FT >> PE

1.4. FT vs PE (태스크의 난이도가 높을 때)

태스크가 굉장히 복잡하면 FT로 온전히 학습 못할 가능성이 크다.
그러한 경우 데이터를 많이 만들어야 한다.
충분한 퀄리티의 데이터가 많이 있다면 태스크의 난이도가 높아도 fine-tuning이 더 좋다.

FT >> PE

1.5. FT vs PE (coverage)

coverage 측면에서 비교해보자. 공간을 좁히고 성능을 올리는 것이 FT이다. 공간을 안 좁히고 성능을 올리는 방법이 PE이다.
좁혔을 때 공간을 더 좁히고 특별한 케이스를 다루기 위해서는 PE가 필요하다. 하지만 그런 상황이 있다는 것은 태스크가 여러 개인 거고 adapter를 따로 만들면 된다.

FT vs PE 요약:

충분한 퀄리티의 데이터가 많이 존재한다면 FT >> PE이다.

2. Zero-shot

LLM을 활용할 때는 대부분 zero-shot 환경이다.

Software 1.0에서의 알고리즘, Software 2.0에서의 데이터를 디자인하지 않는 것이 Software 3.0의 제일 큰 장점이다. task만 명시적으로 정의되어 있으면 데이터를 디자인하지 않아도 zero-shot으로 LLM을 활용할 수 있다.

충분한 퀄리티의 데이터가 많이 존재한다면 FT >> PE인데 이 데이터는 어떻게 만드는 것이 좋은가에 대한 논의를 해보자.

1번 후보는 사람이 직접 데이터를 만드는 것, 2번 후보는 LLM이 데이터를 만드는 것, 3번 후보는 LLM이 데이터를 만들고 사람이 필터링하는 것이다. 이 때 결과에 대한 평가를 사람이 하므로 당연히 사람이 필터링한 데이터만으로 FT하는 것이 좋다. RLHF와 비슷한 개념이라고 볼 수 있겠다. 그러면 2번 후보를 지우고 1번 후보와 3번 후보와 비교를 해보자.

2.1. Human Labeling vs LLM Labeling

LLM이 GPT3이었다면? 무조건 Human Labeling이 더 좋음
하지만 GPT4라면? GPT4가 만든 데이터의 퀄리티가 사람이 만든 데이터보다 더 창의적일 때가 분명 존재함. 다만 사람 마음에 안 드는 데이터도 분명 존재하므로 그것들만 필터링해준다면 LLM Labeling이 더 좋을 것.
llama처럼 GPT3.5가 만든 데이터로 fine-tuning 하는 사례를 보면 이런 접근 방식이 분명 통한다는 것을 증명함.
아래 논문에서도 비슷한 주장을 하고 있음

ChatGPT-4 Outperforms Experts and Crowd Workers in Annotating Political Twitter Messages with Zero-Shot Learning

- https://arxiv.org/pdf/2304.06588

2.2. LLM Labeling은 어떻게 하는가

LLM이 데이터셋을 만들게 어떻게 할까?
우리가 자연어로만 정의된 task를 넣고 그 task의 적절한 데이터셋을 만들어달라고 해야 함
그 과정에서는 어떠한 기술이 필요한가?
Prompt Engineering이 필요하다. 만약 PE를 잘했다면 task에 적절한 데이터셋을 LLM이 더 잘 만들어낼 수 있을 것이고 만약 그렇지 않다면 데이터셋의 퀄리티가 떨어질 것이다.

2.3. 데이터셋을 만드는 LLM + 원래 LLM을 하나의 LLM으로 본다면?

데이터셋을 만드는 LLM을 PE를 통해 개선하고 데이터를 생성한다. 해당 데이터로 원래 LLM을 FT한다. 유저가 입력을 넣을 때 PE 없이 추론이 가능해진다.

=> 하나의 LLM에 PE를 한다. LLM으로 추론한다.

결국 위상적으로 처음으로 돌아가게 된다. PE는 중요한 가치를 갖게 된다.

2. Zero-shot 요약:

Zero-shot인 대부분의 상황에서 결국 PE가 필요하다.

3. Metric이란

지금까지의 논의를 요약해보자.

데이터셋이 존재하고 그 데이터셋에 최대한 align시키는 것이 objective라면 FT >> PE이다. 이 때는 PE의 가치가 없다. 하지만 실생활에서 zero-shot으로 추론할 때가 많고 사람보다 LLM이 더 좋은 데이터셋을 만들어낼 수 있다. 이 때 PE가 결국 필요하다.

데이터셋에 align시키는 목표라면 metric은 BLEU 같은 score로 정량화될 수 있다. 하지만 "더 좋은 데이터셋"의 기준은 뭘까? input에 대해서 output 정답이 존재해야 정량화할 수 있는데 "더 좋은 데이터셋"은 input/output pair dataset을 의미하므로 정답이 존재하지 않는다. 추상적으로 사람이 프롬프트를 바꿔보면서 결과물을 보고 사람이 평가하게 된다.

물론 이 평가 자체도 LLM이 평가를 하는 논문도 있다.

하지만 결국 이것도 최종적으로는 저 prompt를 평가하는 LLM의 prompt를 사람이 만들어낸다. prompt를 평가를 잘 하는지 아닌지를 사람이 여러번 테스트해보면서 저 evaluate prompt를 만들어낸다. Prompt Engineering이다.

어떤 것이든 아무리 정량화가 잘된 metric이든 사람 마음에 드는 것이 좋은 거고 사람 마음에 안 드는 것이 안 좋은 거다. image classification task를 생각해보자. 99.9% 맞출 수 있는 모델은 사람이 labeling해놓은 class를 99.9% 맞추는 모델이지, 진짜 정답을 99.9% 맞추는 모델이 아니다. inverted pendulum에서 제어를 할 때 빠른 시간 내에 평형점을 찾는 것이 사람 마음에 들었기 때문에 그 기준이 metric으로 잡힐 수 있는거지 그 평형점을 찾는 데까지 걸리는 시간 자체가 task의 근본적인 metric이 아니라는 것을 얘기하고 싶은거다.

어떤 task여도 아무리 metric이 정량화되어 있어도 제일 마지막 단계에서는 human evaluate가 반드시 필수적이며 그 과정을 사람이 해야 하기에 Prompt Engineering은 분명 가치가 있고 필요하다.

그렇다면 이 Prompt Engineering이 engineering이 맞을까? 여기서부터는 아니라고 본다. Engineering이라 함은 보통 사람의 평가 기준을 온전히 정량화된 metric으로 위임한 상황 속에서 최적화하는 것을 엔지니어링이라고 한다. 사람이 직접 평가하는 것이라면 그건 예술이라고 봐야 한다. 글쓰기, 그림그리기를 엔지니어링이라고 하지 않는 이유와 동일하다. "Prompt Writing"이라고 보는 것이 좀 더 맞겠다.

4. Conclusion

결론을 내리기 전 가정들.

GPT4가 open-source이다. ( = SOTA LLM을 fine-tuning할 수 있다.)
사전에 정의된 task에 align된 데이터를 LLM이 사람보다 잘 만들 수 있는 가능성이 존재한다.
사람이 데이터를 만드는 것보다 만들어진 데이터를 보고 yes or no를 정하는 것이 훨씬 빠르다.
최종 평가는 사람이 해야만 한다. LLM이 아무리 사람보다 똑똑해도 사람 마음에 안 들면 그건 LLM이 틀린 거다. LLM이 우리의 고객이 아니므로.

위의 가정들과 함께 아래의 결론을 내릴 수 있다.

Prompt Engineering을 한다면 사람은 task를 보고 prompt를 쓰는 LM인 것이고 LLM의 adapter의 역할을 수행하게 된다. fine-tuning을 한다면 데이터셋을 만드는 LLM을 사용해야 하며 그 때 사람이 하는 adapter의 역할을 데이터셋을 만드는 LLM에게 90% 이상 위임하고 그 LLM의 adapter의 역할을 다시 사람이 수행하면서 Prompt Engineering을 하게 된다. 결과적으로 아무리 fine-tuning을 하건 어떤 ML기법을 쓰건 사람이 최종적으로 평가를 해야 하며 그 평가 과정 속에서 Prompt Engineering이 필요하게 된다.

Software 2.0를 아무리 사용해도 Software 1.0이 없어지지 않는다. 모델이 다루지 못하는 부분은 알고리즘으로 커버해야 하며 이 방법이 지향되어야 하는 방법이 절대 아니다. 마찬가지로 Software 3.0에서도 Prompt Engineering이 중요하지만 Software 2.0에서의 technic들이 없어지지 않는다. PE로 안되는 부분은 머신러닝으로 커버해야 한다.

사람의 생각을 언어로 풀어내는 과정인 PE는 분명 대체 불가능한 가치를 가진다.
사람에게 울림과 감동을 주는 책이 있듯, 음악이 있듯, 그림이 있듯이 사람의 주관적인 평가 기준에 따라 대답하는 LLM을 만드는 과정인 PE는 대체 불가능한 가치이며 필요 역량이다. 다만 PE가 아닌 Prompt Writing이라고 하도록 하자. Engineering은 아니다.

아직 끝나지 않은 뇌절

few-shot example만 가지고 LLM이 직접 데이터를 augmentation한다면? 사람이filtering만 하게 되면 PE가 필요하지 않은 것 아닌가? => few-shot example을 LLM이 더 잘 만들 수 있다면? 그걸 만들기 위해서는 PE 필요하지 않나?
데이터셋이 다 존재한다면 FT >> PE인데 FT + PE > FT > PE일 수도 있지 않을까? FT, PE를 같이 적용한다면?
FT를 할 때 memory를 기억해야 한다는 task는 default로 존재하는데 이것도 잘 반영될 수 있을까?
나중에 알아보도록 하자...

5. Software 3.0 시대를 준비하는 우리

소프트웨어는 신기해서 하위 버전이 절대 없어지지 않으며 절대 100% 대체될 수 없다. 일반적인 모든 버저닝은 하위 버전이 필요가 없지만 소프트웨어는 다르다. 소프트웨어 3.0이 일반적인 시대가 2년 안으로 찾아올 것이지만 (= LLM을 통해 zero-shot으로 문제를 해결하는 것이 일반적인 접근 방법이 되는) software 1.0, 2.0의 역량은 항상 중요하다.

회사에서는 1, 2, 3 engineer를 모두 채용해야 하며 서비스를 만들기 위해서는 알고리즘, 개발, 머신러닝, 데이터, fine-tuning, LLM, Prompt Writing 등에 대한 역량이 모두 필요하다. (prompt writing을 통해 engineer와 non-engineer의 구분이 더 모호해질 것이며 A회사처럼 전세계적으로 problem solver로 모두가 통일되는 날이 올지도 모르겠다.) prompt writing만 할 수 있는 회사보다 fine-tuning도 할 수 있고 알고리즘도 짤 수 있는 회사가 훨씬 더 다양하고 깊이 있는 서비스를 할 수 있다. 때에 맞는 방식을 선택해야 할 것이다.

최종 결론: prompt engineering은 분명 다음 시대를 살아가기 위해 반드시 갖춰줘야 할 중요 역량이며 잘 짜여진 prompt는 그 자체로 가치를 지니고 prompt를 잘 짤 수 있는 사람은 가치를 갖고 있다.