"우리도 AI 도입해 보자"는 과제를 받은 기획자(5)
답변을 통제하겠습니다
지난번에는 Open AI의 Response API 중에 Boolean 값으로 설정할 수 있는 것들을 알아보았다.
이번에는 답변을 통제하고 제어하는 방법에 대해서 알아보려고 한다.
1편에서 시스템 프롬프트와 RAG, 펑션 콜링 세 가지를 배웠다. 이를 참고로 해서 잘 설정했음에도 테스트를 하다 보면 엉뚱한 답변이 나올 때도 있다. 예를 들면 고객이 "이 상품 다음 달에 할인하나요?"라고 질문했을 때 실제 관련 데이터가 없으면 실제 할인 계획과 상관없이 "네, 할인합니다"라고 답변하는 경우가 생기기도 한다. 거짓말이다. '할루시네이션(hallucination)' 현상이다. 복잡한 질문일수록 이상한 답변이 껴있을 가능성도 높아진다.
이 글을 읽고 있는 분들은 '할루시네이션(hallucination)'이라는 말을 한 번쯤은 들어봤을 것 같다. 할루시네이션은 AI가 사실이 아닌 내용을 꾸며내서 맥락에 맞지 않거나 없는 말을 그럴싸하게 지어내는 것이다.
할루시네이션은 AI가 언어를 이해하는 방식 때문에 발생한다.
AI는 언어를 사람처럼 이해하는 게 아니라 확률적으로 다음에 올 단어를 예측하는 방식으로 동작한다.
예를 들어서 "나는 사과를 ??????" 라는 문장이 있다고 했을 때,
?????? <- 여기 들어갈 단어를 확률적으로 계산한다.
먹는다 - 0.72점
산다 - 0.15점
던진다 - 0.02점
이런 식으로. 그래서 확률이 가장 높은 "먹는다"는 단어를 선택하게끔 되어있는 것이다. 그런데, AI가 이 확률을 선택할 때 "언어적으로 자연스러운 확률"이 무엇인지가 중요한 것이지, 그게 팩트인지 아닌지는 중요하지가 않기 때문에 자꾸 거짓말을 한다. 사실처럼 들리고 문장이 어색하지 않지만 틀린 말을 하는 것이다.
이런 할루시네이션 현상을 보면 기획자는...?
.. 일단 스트레스를 받는다..ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ
정확하게 답변해줘야 하는 영역에서 거짓말을 해버리면 더 큰 민원으로 이어질 수 있다. AI의 가짜 답변으로 인해 고통받는 것은 그다음에 상담을 이어할 진짜 사람 상담사다. 그런 불상사를 만들 수 없다.
전통적인 기획이라고 하면 A를 입력했을 때 B가 나와야 하는데 자꾸 엉뚱한 Z가 나와버리니 미쳐버린다. 왜 이런 답변을 했는지 추적하는 것도 쉽지가 않다.
그래서 이번 편에서는 AI의 답변을 통제할 수 있는 방법들을 정리해보겠다.
AI는 내 통제를 따르라1. prompt instructions
앞에서 시스템 프롬프트에 대해서 배웠는데, 이 옵션도 시스템 프롬프트와 비슷하다고 보면 된다. 시스템 프롬프트가 AI가 답변해야 할 전반적인 기본 규칙을 설정하는 것이라면 프롬프트 인스트럭션은 특정 질문별로 규칙을 정할 수 있는 것이 다르다. 시스템 프롬프트보다 더 세밀하게 답변을 컨트롤할 수 있다.
예를 들면 이렇게 기획할 수 있다.
상품을 추천할 때에는 친절한 어투로 가격과 특징, 재고를 포함한다.
배송 문의에는 신뢰감 있는 어투로 배송 상태를 조회하고 예상 배송일을 안내한다.
환불 문의에는 공감과 정중하게 말하고 환불 정책서를 참고한다. 필요한 경우 고객센터 연결로 안내한다.
유저의 질문이 어떤 것인지에 따라 상세한 지시사항을 컨트롤할 수 있다.
시스템 프롬프트가 모든 질문에 일관되게 적용되는 규칙을 정한다면, 프롬프트 인스트럭션은 질문 유형별로 다르게 적용할 수 있는 규칙을 정할 수 있다는 의미다.
2. temperature
온도라는 뜻인데, 예를 들면 우리가 "분위기가 왜 이렇게 싸해?" 할 때처럼 감정 상태나 분위기를 쓸 때도 춥다, 덥다를 쓰는 것처럼 이 옵션을 이용해서 답변의 온도를 설정할 수 있다. 온도가 낮을수록 항상 같은 문장을 쓰고, 온도가 높을수록 더 다양한 말들을 사용한다.
앞에서 AI가 언어를 이해할 때 다음에 올 단어 후보에 수치를 매겨서 가장 높은 수치를 답변에 사용한다고 했다. temperature는 0~2 사이의 값으로 조정할 수 있다.
조금 더 자세히 말하자면, temperature는 말투의 온도보다는 답변으로 올 단어들의 확률 분포표를 조절하는 값에 가깝다고 한다. 물리학에서 입자가 많이 움직이면 온도가 높아지는 것처럼 온도가 높으면 전혀 다른 단어도 비슷한 값으로 치환을 해준다. 즉, 모험적인 답변들을 가져오게 되는 것이다.
설명을 할수록 어렵다. 예를 들어서 확인해 보자.
예를 들어서 "주문 취소를 하고 싶어요"라는 질문이 있다고 하면,
temperature= 0 이면 항상 같은 말을 한다. "주문 취소를 도와드리겠습니다. 주문번호를 알려주세요."라고 지정하면 이 말만 한다.
temperature=2에 가까울수록 재치 있는 표현을 한다. "앗, 주문 취소요? 번호만 알려주시면 OK!" 혹은 "후다닥 처리할게요"와 같이 엉뚱한 말도 할 수 있게 된다.
우리는 통제를 해야 하기 때문에 너무 자유도를 주지 않고 1 미만으로 설정하는 게 좋을 듯하다.
3. top_p
여기서 'p'는 'probability(확률)'이다. 확률 기준으로 후보를 얼마나 많이 고려할지 조절하는 값이다. 즉, 가장 높은 확률 범위로 답변을 좁히는 옵션이다. 0~1 사이의 값으로 조정할 수 있다.
top_p=0 이면 아무 값도 고르지 않으므로 현실적으로는 0.1 이상으로 써야 한다.
top_p=1 이면 후보 단어들을 모두 고른다. 사실상 이 값도 아무런 조정을 하지 않겠다는 의미이거나 모든 값을 사용하므로 창의적인(?) 답변이 나올 가능성이 높다.
우리가 정한 범위 내에서만 답변하게끔 하려면 0.2~0.5 사이를,
조금 더 자연스럽거나 친근하게 하고 싶다면 0.6~0.8 정도를 권장한다.
temperature에서 모험적인 답변들의 점수를 조정하고, top_p로 가장 높은 확률의 범위로 답변을 지정하게끔 하는 것이다.
통제하고 싶다면 싶을수록 점수를 낮추면 된다.
4. frequency_penalty / presence_penalty
이 두 가지 값은 비슷해서 하나로 묶어봤다.
'frequency_penalty'는 같은 단어를 반복해서 쓰지 못하게 억제하는 것이다. 0이면 같은 말만 반복하고, 수치가 높을수록 다른 말을 사용한다. "도와드리겠습니다", "안내해 드리겠습니다", "처리해 드리겠습니다"와 같은 비슷하지만 다른 문장을 사용하고 싶을 때 설정할 수 있다. 0~2 사이의 값을 넣을 수 있다. 1 이상이면 반복 단어가 거의 안 나오기 때문에 오히려 더 부자연스러울 수 있다. 통제하고 싶다면 값을 낮추면 된다.
'presence_penalty'는 이전에 쓰지 않은 단어를 쓰도록 하는 것이다. 값이 높을수록 새로운 단어를 쓰게 되므로 마찬가지로 통제하고 싶다면 값을 낮추면 된다.
하지만 이 값을 너무 낮춰버리면 AI의 장점이 가려질 수도 있다. 적절하게 자연스러우면서 통제 범위 안에 들어오는 비중을 선택하는 게 좋겠다.
5. max_tokens
이 값은 답변의 길이를 조정하는 값이다. 토큰이라는 개념을 따로 정리하지는 않았지만.. 앞서 AI가 언어를 이해할 때 문자별로 수치화해서 처리한다고 설명했다. 이렇게 문장을 단어 단위로 쪼개고, 이 단어들 혹은 단어나 기호들을 처리하는 값을 '토큰(token)'이라고 한다. 보통 LLM 모델들이 토큰 단위로 과금을 하기 때문에 너무 길어지면 비용이 많이 나온다. 게다가 너무 답변이 길어지면 그 답변을 읽는 고객도 불편하기 때문에 답변 일이를 조정해 주는 것이 좋다.
토큰이 적을수록 답변이 간결해지고, 토큰이 클수록 길고 장황하게 설명하기 때문에 적절한 값을 정해야 한다. 챗GPT 설명으로는 짧은 내용은 20~40, 상세한 안내는 60~100 정도가 적당하다고 한다.
토큰 계산은 이 토크나이저라고 하는 문장을 토큰으로 쪼개주는 Open AI 링크를 참고하면 된다.
https://platform.openai.com/tokenizer
앞에서 배웠던 RAG나 펑션 콜링도 사실은 답변을 제어하는 방안 중에 하나이기도 하다.
창의적으로 답변하지 말고, 우리가 제공하는 문서와 API를 통해 조회되는 범위 내에서 답변하라고 지정하는 것이기 때문이다. 앞서 설명했던 부분은 중복이라 넣지 않았다.
위의 1~5개 값들은 Response API에서 파라미터 값으로 설정하는 항목들이다.
Response API를 호출할 때 설정하는 것 외에도 답변이 생성되면 그 이후에 챙겨야 할 것들도 있다.
Moderation API(Open AI의 정책대로 욕설, 폭력, 혐오, 민감 정보를 검사하는 API)를 한번 더 호출하거나,
회사 내의 자체적으로 쓰고 있는 금지어나 정책을 필터링하는 부분으로 통제를 강화할 수 있다.
이 부분은 다음 편에서 조금 더 자세히 살펴보고 지금은 이런 게 있구나~ 정도만 알고 넘어가려고 한다.
전통적 기획 관점에서는 통제가 가장 중요하다. A를 누르면 B가 와야 한다. 예측할 수 있어야 한다. 그런데 AI는 이런 전통적인 제약과 좀 다르다. 내부가 어떻게 돌아가는지도 잘 모르겠다. 그래서 통제를 하려는 수단을 정리해봤다.
그런데 또 AI의 가장 큰 장점이 창의성과 다양성이라 너무 통제하면 사람 같지가 않고 단조로워져서 시나리오 기반의 답변과 무엇이 다른 건가.. 싶은 생각도 든다.
어느 범위로 통제하고 제한을 둘 지는 여러 가지 테스트를 거치고, 서비스 특성에 맞춰 조정이 필요할 것 같다.