프롬프트 작성팁
LLM에게 친절해야 할까?
Sujin_Kang
Category
Empty
Status
Empty
Assignee
Empty
공손한 언어와 프롬프트의 효과
프롬프트를 써오면서 AI에게 예의를 갖추는 것이 혹은 예의바른 문장을 사용하는 것이 가치가 있는 일이라고 말하고 싶습니다. 두 가지 이유인데요,
1️⃣ 공손한 표현 사용은 AI로 부터 더 좋은 결과물을 얻는다.
2️⃣ 공손한 표현은 AI 사용의 윤리적 담화를 형성한다.
"AI는 감정이 없는데, 예의를 차리는 것이 효과가 있을까?" 라고 생각하는 분들도 있을거예요.
하지만 인간은 다른 사람과 감정적으로 연결하려하고, 예의를 갖추려 하기 때문에 생성형 AI를 사용하면서도 예의 바른 표현과 공손한 매너가 기본인 분들도 많죠. (세상에 100%는 없기 때문에, 다수라 저는 믿습니다)
이 글에서는, 공손한 표현의 프롬프팅 효과에 대해 다뤄보겠습니다.
프롬프트를 작성할 때 다음 세 가지 중 한 가지 표현을 사용할 거예요.
(1) 중립적인 어조: 특별히 예의바르지도, 무례하지도 않은 "AI가 해야 할 일"을 명령하는 중립적인 프롬프트
(2) 예의바른 표현: 공손성이 높은 표현이 있는 프롬프트
(3) 무례한 표현: 불공손성(impoliteness)을 표현한 프롬프트
(2) 예의바른 표현: 공손성이 높은 표현이 있는 프롬프트
(3) 무례한 표현: 불공손성(impoliteness)을 표현한 프롬프트
생성형 AI 이용자의 프롬프트 언어 분석을 하고 있습니다. 그 중 "공손성과 불공손성"에 있어서 제가 목격한 것은
대다수가 자연스레 친절하고 공손한 어조로 프롬프트를 작성한다는 점입니다.
"안녕? ~~~좀 해줄 수 있어?"
"고마워~ 너 정말 대단하다"
"안녕하세요 저는 이런 것들이 필요한데, ~ 해주시겠어요?"
그리고, 일부 사람들은 무례한 표현으로 프롬프트를 작성했습니다.
"이 것밖에 못해?"
"너 진짜 멍청하다. 나를 화나게 만들지마" 등등이요.
예의를 "공손성", 무례를 "불공손성"이라 하겠습니다. 공손성을 표현하는 방식 불공손성을 표현하는 방식은 다양하고 범위가 넓습니다. 그리고 대화 분석학의 선행 연구는 "불공손성"이 훨씬 전략적이고 다양한 레이어가 있다고 밝혔습니다.
Q. LLM이 공손한 언어와 불공손한 언어에 다르게 반응할까? 에 대한 합리적 이유
1️⃣ 인간의 다양한 글쓰기와 단어 사용 방식 학습
AI가 인간의 글쓰기 방식에 대해서 이렇게 인식합니다. 시, 소설, 산문, 연구 논문 등 인간이 작성한 글쓰기를 검토하기 위해 많은 데이터를 스캔했죠. 그 안에서, 인간이 사용하는 단어의 패턴을 찾고, A라는 단어가 B라는 단어와 어떻게 사용됐는지를 방향을 학습했습니다.
2️⃣ 인간의 "공손성 표현" 방식 학습
많은 학습 데이터에는 "인간의 공손성"에한 표현이 있습니다. 항상은 아니지만요.
그렇지만, 인간이 "공손할 때"라는 패턴은 충분히 파악할만한 자료겠죠. 예를 들어 "잘 부탁드립니다." "고맙습니다" "굉장히 감사합니다" 등의 표현을, 언제 어떤 상황에서 쓰였는지 학습했을 거예요.
3️⃣ "공손언어" → 패턴 추출
프롬프트를 작성할 때, 공손한 표현을 사용하면 생성형 AI는 자연스레 "공손성"을 인식하고 해당 패턴을 활용하는 방식으로 응답을 할 거예요. 그래서, 사용자가 사용한 단어에 맞는 언어로 대답을 하는 거죠.
그렇다고 해서, 불공손한 언어를 썼다고 AI가 무례하게 답하지는 않아요. ChatGPT가 RLHF (인간 피드백을 통한 강화학습)이라는 기술을 사용했기 때문입니다. GPT가 공개되기 전에, 많은 사람을 고용해 일일히 다양한 종류의 프롬프트와 프롬프트가 생성한 응답을 확인했어요. 응답을 평가하며, 특정 단어는 허용하고 특정 단어는 허용하지 않도록 채점했습니다. 그래서, 유해한 응답을 하지 않도록 했기 때문에, 불공손한 언어를 프롬프트에 썼다고 무례하게 대답하진 않는 거예요. (물론, 이 또한 세상의 유해한 단어와 내용을 완벽하게 필터링 하진 못했겠지만요)
→ 여기서, 프롬프트 엔지니어의 역할과 프롬프트 엔지니어링의 중요성을 언급할 필요가 있습니다.
잘 설계한 프롬프트가 생성형 AI와 LLM에서 더 좋은 결과를 얻을 수 있다는 점은 잘 알려져있죠. 그런데, 유해한 내용을 제거하고 건전한 프롬프트를 고안하는 미묘한 기술과 과학도 프롬프트 엔지니어의 중요한 일입니다.
(이 주제는 AI윤리와 AI법률 관련한 다른 글에서 풀겠습니다!)
Q. 공손한 표현 얼마나 효과가 있을까?
제 경험과 직관은 공손한 표현을 사용하면, 조금 더 길고 자세한 답변을 받았습니다. 그리고 이를 뒷받침한 연구가 있습니다. 2024년 2월 22일에 발표된 "Should We Respect LLMs?" 라는 연구 입니다.
프롬프트에있어서 "공손함의 레벨"이 LLM의 성능에 영향을 미친다는 결과입니다.
✅ 연구 결과
- 인간 의사소통에서 예의 바른 언어는 종종 더 많은 LLM 순응과 효과를 얻는 반면, 무례함은 혐오감을 일으켜 응답 품질에 영향을 줄 수 있음
-LLM이 인간의 의사소통 특성을 반영한다고 생각하며, 이는 LLM이 인간의 문화적 규범과 일치한다는 것을 시사
영어 뿐 아니라 중국어, 일본어 작업에서도 공손한 표현이 영향을 미침을 확인
-무례한 프롬프트가 종종 낮은 성능을 초래하지만, 지나치게 예의 바른 언어가 반드시 더 나은 결과를 보장하지는 않는다는 것을 관찰
-공손함의 레벨은 언어에 따라 다름. 이 현상은 LLM이 인간의 행동을 반영할 뿐만 아니라 특히 서로 다른 -문화적 맥락에서 언어의 영향을 받는다는 것을 시사함.
-LLM이 인간의 의사소통 특성을 반영한다고 생각하며, 이는 LLM이 인간의 문화적 규범과 일치한다는 것을 시사
영어 뿐 아니라 중국어, 일본어 작업에서도 공손한 표현이 영향을 미침을 확인
-무례한 프롬프트가 종종 낮은 성능을 초래하지만, 지나치게 예의 바른 언어가 반드시 더 나은 결과를 보장하지는 않는다는 것을 관찰
-공손함의 레벨은 언어에 따라 다름. 이 현상은 LLM이 인간의 행동을 반영할 뿐만 아니라 특히 서로 다른 -문화적 맥락에서 언어의 영향을 받는다는 것을 시사함.
•
그래프 설명: 영어, 중국어, 일본어 데이터셋에 대해 여러 모델의 요약 성능. 다양한 공손성 레벨에 따른 모델의 성능을 BERTScore (문장 간 의미유사성), ROUGE-L(요약된 텍스트와 텍스트 간 겹치는 부분 측정), Length (요약 텍스트 길이)
•
그래프 결과:
◦
모든 모델은 공손함 관계없이 일관된 요약 길이 유지
◦
BERTScore 와 ROUGE-L은 데이터셋과 모델에 따라 다름, 특정 공손함 수준에서 성능 차이 발생
✅ 연구에서 사용한 공손한 영어 표현
✅ 연구에서 발견한 🍪
Cookie라는 표현은, 무언가의 이득입니다! 이 그래프는 다양한 언어 모델(GPT-3.5, GPT-4, Llama2-70B, ChatGLM3, Swallow-70B)의 성능을 MMLU, C-Eval, JMLLU 세 가지 벤치마크에서 T-테스트로 비교한 결과입니다. Advaned 모델에서 프롬프트의 공손함 수준이 모델 성능에 미치는 영향이 적을 수 있음을 보여줍니다. 실제로 그런지, 다양한 conversation context 에서 연구를 해보면 유의미한 결과가 있을 것 같습니다.
Q. LLM에게 얼마나 공손해야 할까?
그렇다면, 얼마나 공손해야 할까? 라는 생각이 들죠. AI에게 공손성을 표현할 때 지나칠 필요는 없습니다. 적당한 예의만 차리면 된다고 합니다.
골디락스 규칙이 있습니다.
같은 종류로 단계가 다른 3개 이상의 선택지가 있을 경우, 많은 사람들은 평균적인 것을 선택한다는 규칙입니다.
로버트 사우디가 쓴 영국의 유명한 동화 <골디락스와 세 마리 곰>에서 유래한 규칙입니다. “골디락스”라는 이름의 여자아이가 세 마리의 곰이 사는 집으로 들어갑니다. 집에는 아무도 없었어요. 식탁에는 뜨거운 죽, 미지근한 죽, 중간 온도의 죽이 있었는데, 골드락스는 중간 온도의 죽을 먹어요. 의자도, 너무 크거나 너무 작은, 그리고 적당한 의자가 있었는데 적당한 의자를 골랐어요. 침대도 세 종류가 있어요. 너무 부드러운 침대, 중간 정도의 딱딱한 침대, 너무 딱딱한 침대. 침대도 역시 중간 정도를 골랐습니다.
이 이야기의 시사점은, 사람은 선택을 할 때 "적절한 가운데"를 선택한다는 경향성이에요.
불공손한 프롬프트가 종종 낮은 성능을 초래하지만, 지나치게 예의 바른 언어가 반드시 더 나은 결과를 보장하지는 않는다는 것을 말씀 드리고 싶습니다.
<Reference>
Subscribe to 'sujin-prompt-engineer'
Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to 'sujin-prompt-engineer'!
Join Slashpage and subscribe to 'sujin-prompt-engineer'!
4
S
Samuel Yang
좋은 팁 나누어 주셔서 감사합니다. claude로 프롬프트 초안을 생성하다보면 요청하는 맥락에서 please를 꼭 붙이더라구요. 앞으로는 저도 최소한 please 정도는 사용해봐야 겠네요. 예전 통념에 please 붙일 필요 없다는 것이 있어서 주로 명령문으로 작성을 많이 했었거든요.
Sujin_Kang
저도 그런 통념을 본 기억이 나요! Thank you, Please 붙일 필요가 없다. 그러나, 항상 그런 것은 없으니까요! 저는 please 보다는. Thank you 를 많이 쓰는 것 같아요. 한 번 해보시고, 직관과 경험을 또 나누어 주세요.
S
Samuel Yang
음, should, must, have to와 같은 표현에 대해서도 사실 평소부터 궁금했었는데요, 순전히 개인적인 느낌 상으로 이런 표현을 사용하면 llm이 할 일을 빼먹지 않고 하기는 하지만, 뭔가 응답내용의 풍성함에 제한이 걸리거나, 딱 필요한 말만 내뱉는 느낌이 들었거든요. 프롬프트에 이렇게 의무나 강제성을 띄는 표현을 사용했을 때 llm의 반응에 대해서도 어떤 연구결과나 경험칙이 있는지 궁금해서 질문을 남깁니다.
Sujin_Kang
Should/ must/ ought to 저도 이런 표현을 쓰면서 control 을 주는데
이 것에 대한 의견도 많더라고요, 한 번 정리하여 글을 써보겠습니다 ^^ 강제성이 필요한 것은 아무래도 규칙을 줄 때이지 싶어요. 한 연구는 규칙의 정도를 strong- weak 으로 나누어서, 조절하더라구요 SHOULD 의 형태로!
이 것에 대한 의견도 많더라고요, 한 번 정리하여 글을 써보겠습니다 ^^ 강제성이 필요한 것은 아무래도 규칙을 줄 때이지 싶어요. 한 연구는 규칙의 정도를 strong- weak 으로 나누어서, 조절하더라구요 SHOULD 의 형태로!
See latest comments