DEVOCEAN

지난 달 에이닷에 새롭게 추가된 뮤직 에이전트는 Open AI의 GPT 3.5 Turbo 모델을 활용하여 이용자의 요청을 이해하고 응답을 생성하도록 개발되었습니다.

예를 들어 이용자가 음악 추천을 요청하거나 특정 장르에 대해 물어볼 때,

뮤직 에이전트는 이용자의 요청을 정확히 파악하고 마치 음악을 잘아는 친구와 대화하듯 적절하고 매력적인 답변을 제공합니다.

지금부터 뮤직 에이전트 Prompt 개발 과정을 소개드리도록 하겠습니다.

Prompt Chaining

뮤직 에이전트를 개발하기 위해서 다음과 같은 기능들이 필수로 구현되어야 합니다.

• Intent/Control Classification

• Entity Extraction

• Reactive Messaging

본 프로젝트 초기에는 이러한 기능들을 하나의 Prompt로 해결하는 것이 가장 효율적이라는 판단하에 하나의 Prompt로 구성했었습니다.

그러나 내부 검증 과정에서 엄격한 결과를 반환해야 하는 “이용자 질의 이해 요건 (Intent/Control Classification, Entity Extraction)”과

자유도 높은 결과를 반환해야 하는 “응답 메시지 생성 요건 (Reactive Messaging)” 사이에 충돌이 발생하는 것을 알게 되었습니다.

예를 들어 “아이유가 부른 발라드곡 들려줘"라는 이용자 질의가 있을 때 아이유가 아티스트이고 발라드 장르의 음악을 검색하는 요청이라는 부분은

여러차례 반복 요청이 있더라도 항상 결과가 동일해야하는 부분인데 반하여 응답 메시지는 매 요청마다 새롭고 창의적인 메시지가 생성되어야

이용자들에게 자연스러운 대화 경험을 전달할 수 있다는 차이가 있습니다.

이와 같은 기능 간 요건 차이를 고려하여 본 프로젝트에서는 이용자의 질의 내용을 이해하기 위한 질의 분석 Prompt와

이용자에게 반환할 응답 메시지를 생성하기 위한 메시지 생성 Prompt를 구분하고 질의 분석 Prompt의 분석 결과를

메시지 생성 Prompt에게 전달하여 응답 메시지를 생성하는 방식으로 Prompt Chaining을 수행하였습니다.

이렇게 Prompt를 분리함에 따라 질의 분석 Prompt에 대해서는 Temperature를 0.0으로 설정하여 최대한 고정된 결과를 유도하고,

메시지 생성 Prompt에서는 Temperature를 0.8로 설정하여 창의적인 메시지를 생성할 수 있도록 설계되었습니다.

또한 에이전트가 이용자에게 먼저 말을 건네는 선톡(Proactive Engagement) 상황에서는 선톡 메시지 내에서 플레이리스트 생성 조건을 제안하는 경우가 있는데,

해당 조건에 해당하는 플레이리스트를 생성하기 위하여 그림과 같이 선톡 메시지를 질의 분석 Prompt에 전달하여 Intent 및 Entity를 분석할 수 있도록 Chaining을 수행하였습니다.

질의 이해 Prompt

이용자의 질의를 이해하는 Prompt는 다음과 같이 크게 세 개의 구역으로 나누어 구성되어 있습니다.

• Instruction: 에이전트의 Role 및 Task, 출력 포맷(JSON) 정의

• Context: 추출할 Intent/Entity의 종류, 지원하지 않는 기능의 종류 등 분석에 참고할 데이터 정의

• Few-shot Examples: 실제 분석 예시 (Input, Output Pair로 구성)

질의 이해 Prompt의 경우, 경험상 Instruction으로 자세한 설명을 제공하는 것보다는 Few-shot Example을 추가하여

다양한 케이스에 대한 적응력을 높여주는 것이 품질향상에 도움이 되는 것으로 판단되어, 예시 기반으로 프롬프팅을 수행하였습니다.

질의 이해 Prompt는 “신나는 아이유 노래 추천"과 같이 단순한 질의부터 “좋아요한 노래랑 김경호 노래 섞고 셔플해줘"와 같이

복합 질의까지 다양한 형태의 질의에 대하여 이용자의 의도를 분석할 수 있습니다.

다만, 생성형 모델의 특성상 Temperature를 0으로 설정하여도 동일한 발화가 반복 호출시 결과가 간헐적으로 바뀌는 현상이 존재하는데,

질의 뒤에 점(.)을 두 개 붙혔을 때 상대적으로 조금 더 안정적인 결과가 출력되는 것을 확인할 수 있었습니다.

이 부분은 명확한 원인을 증명할 수 없는 부분이지만 내부 QA 과정에서 효과가 있는 방법으로 판단되어 실제 서비스에 해당 방식을 활용하고 있습니다.

또한 동일한 GPT 3.5 Turbo 모델에서도 날짜 버전(예: 0613, 1106 등)이 변경됨에 따라 출력 포맷인 JSON이 비정상적으로 출력되는 현상이 발견되어

출력부 Prompt에 JSON 포맷 유지를 위한 구문을 추가해주어야 정상동작하는 케이스를 경험 할 수 있었습니다.

이와 같이 날짜 버전이 올라가는 경우에도 상당히 큰 변화가 있기 때문에 전체적인 Regression Test가 필요하다는 것을 알 수 있었고,

이에 따라 내부적으로 테스트 데이터 및 모듈을 개발하여 자동 Regression Test를 수행하고 있습니다.

Fine-tuning

프로젝트 초반에는 10개 정도의 Few-shot Example로 대부분의 발화 패턴을 충분히 다룰 수 있을 것으로 기대했었습니다.

하지만 QA(Quality Assurance) 대응 과정에서 예상과 달리 실제로 필요한 예시의 수가 약 8배나 증가하여 최대 토큰 수에 근접하게 Prompt의 길이가 길어지는 이슈가 있었습니다.

이에 따라 새로운 예시를 추가하는 것에 대한 부담으로 Prompt 고도화에 어려움이 있었고,

이러한 어려움을 극복하기 위하여 Open AI 공식 가이드에 따라 Fine-tuning 모델로의 전환을 시도하게 되었습니다.

개인적으로 Fine-tuning 모델은 비싸다는 편견을 지니고 있었으나,

막상 실제 API 건당 호출 비용을 비교해보니 Few-shot Example들이 모두 학습 데이터로 제외되어 토큰 수가 감소함에 따라 오히려 Fine-tuning 모델이 더 저렴한 것으로 나타났습니다.

또한 학습 비용에 있어서도 $11.50 달러 수준으로 상당히 저렴한 비용으로 모델 학습이 가능하다는 것을 알 수 있었습니다.

또한 프롬프팅에서 예시를 추가하여도 잘 해결되지 않던 다양한 패턴의 요청들이 파인튜닝을 통하여 해소되는 케이스들도 발견할 수 있었습니다.

예를 들어 “첫 만남은 계획대로 되지 않아"와 같이 대화 형식의 노래 제목만 질의로 입력된 경우,

기존 모델에서는 이를 자유 대화(Free Talk)에 대한 요청으로 판단한데 반하여 Fine-tuning 모델에서는 이를 노래 제목으로 인식하게 됩니다.

또한 “차탄쿠파 노래 틀어줘"와 같이 존재하지 않는 어휘로 구성된 질의를 입력하면 왼쪽 예시와 같이 JSON 포맷이 생성되다가

API 응답이 돌아오지 않는 현상이 발생했었는데, 이 현상 또한 Fine-tuning 을 통하여 해결되는 것으로 나타났습니다.

마지막으로 “임영웅 김호중 노래로 운동하기 좋은 노래 만들어줘"와 같이 복잡한 발화에 대해서도 기존보다 정확하게 분석이 가능한 것으로 나타났습니다.

사용자와 자연스럽게 소통하는 기술, Reactive Messaging

Reactive Messaging은 사용자에게 기존의 규칙 기반 챗봇과는 다른 새로운 사용자 경험을 제공하는 것을 목표로 개발되었습니다.

Reactive Message 생성을 위해 Prompting 작업 시 중요하게 생각한 요소는 다음과 같습니다.

• 사용자 중심의 메세지 생성

  • Reactive messaging은 사용자의 요청에 친절하고 재치있는 반응을 제공합니다.

    사용자의 음악 관련 요청에 적합한 응답을 생성하여, 사용자와의 소통을 원할하게 합니다.

• 멀티턴 대화의 자연스러움

  • Reactive messaging 은 여러 차례의 대화 과정에서도 자연스럽게 연결되도록 하여,

    이를 통해 사용자와의 의사소통을 더욱 원활하게 만드는데 도움을 줍니다.

• 메세지 생성의 창의성

  • 음악 관련 요청에 대해 이모티콘을 활용한 다양한 메세지를 생성하여 사용자에게 즐거운 경험을 제공하고 소통을 더욱 풍부하고 유쾌하게 만듭니다.

Reactive Messaging의 Prompt

Reactive Messaging Prompt는 크게 Task 정의, 도메인 제한, Tone&Manner 정의, 메시지 생성 조건(이모티콘, 문장 길이 등), 비윤리적 메시지 생성 제한 등으로 구성되어있습니다.

해당 Prompt는 뮤직 에이전트에 대한 페르소나, 대화 스타일, 역할, 제약 조건 등을 정의함으로써 이용자의 요청에 대한 응답 메시지를 실시간으로 생성하도록 설계하였습니다.

특히 Tone&Manner를 정의하는 부분과 이모티콘을 활용하여 이용자와 소통하는 부분 등에 있어서 기획과 의견을 교환하며 정교한 튜닝을 진행하였고, 

이러한 감성적 터치가 기존의 규칙 기반 챗봇과 차별되는 새로운 사용자 경험을 제공하고 있다고 판단하고 있습니다.

Reactive Messaging의 진화: 설명력 확보를 위한 호출 방식 변경

• 최초 설계: 병렬 호출 방식

  • Reactive Messaging의 초기 설계에서는 대화 응답 시간, 즉 Latency를 최소화하는 것이 목표였습니다.

    사용자의 질의를 받고, 이에 대한 Prompt와 메시지를 동시에 처리하는 '병렬 호출' 방식을 사용하였습니다.

    이 방식은 질의 해석과 응답 메세지 생성을 동시에 처리함으로서 빠른 응답 시간을 제공하였지만,

    사용자 요청과 연계되지 않은 메세지가 생성되는 한계가 있었습니다.

• 개선 설계: 직렬 호출 방식

  • 자연스러운 대화를 위해 질문 해석 Prompt를 통해 해석된 질의 기반으로 메시지를 생성하는 '직렬 호출' 방식을 도입하였습니다.

    이 방식은 사용자의 질의를 먼저 해석하고, 그에 맞는 메시지를 생성함으로써 질의에 더욱 부합하는 결과를 제공하였습니다.

• 추후 목표: 검색 및 추천 결과 기반 메시지 생성

  • 앞으로의 목표는 검색/추천 결과를 바탕으로 연계된 메시지를 생성하는 것입니다.

    최종 검색과 추천 결과까지 반영하여 메시지를 생성함으로써 결과와 메시지 사이의 일관성을 더욱 강화할 계획입니다.

    이를 통해 사용자 질의와 연계된, 더욱 풍부하고 섬세한 메시지를 제공할 것입니다.

미지원 기능 및 도메인 외 질의에 대한 대응 전략

Reactive Messaging이 효율적으로 작동하기 위해서는 음악 도메인 외의 요청에 대한 적절한 대응이 필요합니다.

'Unsupported 발화 관리'와 'Free-talk 발화 관리'라고 불리는 두 가지 주요 전략을 살펴봅시다.

• Unsupported 발화 관리

  • 사용자가 음악 도메인에 속하지만 시스템이 지원하지 않는 요청을 하는 경우, 이런 상황을 'Unsupported' 상황이라 부릅니다.

    이 때 시스템은 미지원 상황임을 명확하게 사용자에게 전달해야 합니다.

    현재는 서비스 정책상 LLM으로 생성된 메시지를 사용하는 것이 아니라 미리 정해둔 고정 메시지를 전달합니다.

• Free-talk 발화 관리

  • 또 다른 상황은 음악 도메인 외의 발화에 대한 대응입니다. 이런 경우에는 시스템이 자유롭게 대화를 유도합니다.

    Unsupported 발화와는 달리 이 경우에는 LLM으로 생성된 메시지를 활용할 수 있습니다.

이와 같이 Reactive Messaging은 도메인 외의 질의에 대해 적절히 대응하면서 사용자 경험을 최적화하는 방법을 탐구하고 있습니다.

이 기능은 뮤직 에이전트가 안정적으로 서비스 되는 과정에서 중요한 역할을 담당하며, 사용자와의 원활한 소통을 가능하게 합니다.

멀티턴 대화의 히스토리 관리와 세부 파라미터 제어

멀티턴 대화 시스템의 성능 향상을 위해서는 대화 히스토리 관리와 세부 파라미터의 조정이 필수적인 요소입니다.

이 두 요소는 대화의 자연스러움과 전반적인 대화 품질에 결정적인 영향을 미칩니다.

• 대화 히스토리 관리

  • 간결하면서도 효과적인 멀티턴 대화를 제공하기 위해 적절한 최대 대화 활용 개수를 설정하고

    이에 더해 Query Understanding에서 전달 받는 신규 세션 여부에 대한 정보를 활용함으로써,

    이전 대화와 무관한 신규 요청에 대해 새로운 세션을 시작할 수 있고 이를 통해 이전 히스토리와 현재 요청이 섞이는 현상을 줄일 수 있습니다.

• 세부 파라미터 조정

  • Presence penalty와 Frequency penalty는 GPT 모델의 예측을 조절하는 데 중요한 역할을 합니다.

    Presence penalty는 모델이 반복 예측을 줄이고 이미 생성된 단어의 확률을 조정하는 것이며,

    Frequency penalty는 새로운 예측을 유도하여 이미 예측된 텍스트에 단어가 나타난 경우 해당 단어의 확률을 조정하는 역할을 합니다.

이렇게 세부 파라미터 제어와 최적화를 통해 멀티턴 대화의 품질을 높일 수 있으며, 사용자와의 자연스러운 상호작용을 위한 기반을 제공할 수 있습니다.

사용자 중심의 음악 권유, Proactive Engagement

Proactive Engagement는 대화방 진입시 자연스럽게 대화를 시작하며 사용자의 상황과 음악 취향을 고려하여 음악을 권유하는 방법에 대한 기술입니다.

• 자연스러운 대화의 시작

  • Proactive Engagement는 사용자와의 대화를 자연스럽게 이끌어내며, 음악을 권유하는 과정에서 사용자에게 친절하고 따뜻한 메세지를 전달합니다.

• 사용자 선호도를 반영한 개인화 대화

  • 사용자의 음악 선호도를 파악하여 사용자 선호에 맞는 음악을 권유합니다.

    사용자가 특정 아티스트나 장르를 선호한다면, 해당 선호도를 고려한 추천을 통해 만족도를 높힙니다.

• 현재 Context에 어울리는 유동적인 음악 추천

  • Proactive Engagement는 시간과 음악 청취 여부 등을 고려하여 음악을 권유하거나 추가 요청에 대한 질문을 합니다.

Proactive Engagement의 Prompt

Proactive Engagement는 사용자와의 상호작용을 미리 예측하여 적절한 대화를 제공하는 기능이며 음악 청취 여부에 따라 다른 응답을 제공하는 방식으로 구성됩니다.

사용자가 현재 음악을 청취하고 있는지 여부를 파악하고, 이에 맞게 이모티콘과 자연스러운 인사말을 활용하여 사용자와의 대화를 이끌어내는 방식이 적용됩니다.

이를 통해 사용자와의 상호작용을 보다 유연하고 자연스럽게 만들어내며, 맞춤형 서비스를 제공함으로써 사용자 경험을 향상시킬 수 있습니다.

Proactive Engagement의 현재와 향후 발전 방향

선톡은 고객과의 상호작용을 더욱 효과적으로 시작하기 위한 전략으로 사용자 정보를 기반으로 한 맞춤형 대화를 제공하는 것이 주요 목표입니다.

현재 선톡 구조는 사용자가 음악을 청취하고 있는지 여부에 따라 다양한 응답을 제공하는 방식으로 이루어져 있습니다.

이러한 방식을 통해 사용자와의 대화를 유연하게 이끌어내고, 상호작용을 더욱 자연스럽게 만들어내는 데 주력하고 있습니다.

향후에는 시간과 현재 음악 청취 여부를 기반으로 한 기본적인 선톡 구조를 보다 풍부하게 고도화하여 사용자에게 더 다양한 대화 경험을 제공할 계획입니다.

UPS 정보를 통해 더욱 세밀하게 사용자에게 개인화된 경험을 제공하고, 날씨나 위치 등의 추가적인 Context 정보를 활용하여 선톡 기능을 고도화할 계획입니다.

일하는 방식의 변화

본 프로젝트를 진행하면서 가장 큰 변화를 느낀 부분은 일하는 방식의 변화였던 것 같습니다.

그 변화의 핵심은 바로 Prompt였습니다.

Prompt는 기존과 달리 자연어로 기계와 소통할 수 있는 도구이기 때문에 기획 요건을 정의할 때 기획자가 직접 가능성을 검증해볼 수도 있고,

더 나아가면 기획자가 직접 Prototyping 하는 것도 가능하게 해줍니다.

또한 자연어이다 보니 기존에 개발자들만의 문화라 여겨졌던 Code Review와 유사한 형태의 Prompt Review도 가능하게 되었습니다.

실제로 QA 막바지에 기획자분께서 함께 Prompt를 리뷰하면서 오류를 발견해주신 경우도 있어서

Prompt Engineering 분야에서 기획자와 개발자가 함께하는 Prompt Review도 상당히 의미있는 새로운 문화로 정착하지 않을까 싶은 생각이 듭니다.

다만 이러한 상황이 개발자 입장에서는 다소 생소하고 본인의 영역을 침범당한다는 거부감을 느낄 수도 있습니다.

그럼에도 불구하고 여전히 개발자의 역할은 명확하다고 생각합니다. 바로 Prompt 고도화와 안정화 부분인데요.

이 부분 만큼은 여전히 개발자들이 직접 수행해야만하는 영역인 것 같습니다.

예를 들어 초반부에 설명드린 바와 같이 하나의 Prompt를 효율적인 시스템 구성을 위하여 여러개의 Prompt로 분리하고

이를 Chaining하는 작업이 대표적인 예시가 될 수 있을 것 같습니다.

또한 체계적인 LLMOps를 위해서 운영팀과의 협업도 매우 중요한 포인트라고 생각합니다.

저희도 현재 지속적 Fine-tuning을 통한 품질 고도화를 위하여 운영팀에서 다양한 에러 케이스를 발견하고 이를 개발팀에서 반영하는 프로세스를 만들어 가는 중에 있으며,

이러한 과정을 통하여 이용자분들이 더욱 편리하고 새로운 음악 소비 경험을 얻을 수 있도록 에이닷 뮤직 에이전트를 더욱 발전시켜 나가고자 합니다.

• 작성자

  • 강온유 (onyu@sk.com)

  • 백종범 (jongbum.baik@sk.com)