LLM을 이용한 인플루언서 추천 (1/2)부

Abstract

• 피처링에서는 2억개 이상의 SNS 데이터를 가지고 있으며, 인플루언서 탐색뿐만 아니라 직접 캠페인 등을 진행하고 있습니다. 이를 바탕으로 Data Analysis 파트에서는 여기서의 데이터들을 통해 인플루언서 마케팅과 캠페인 운영의 효율화를 도모하고 있습니다.

• 현재는 내부의 작업을 개선하는데 초점을 맞추고 있습니다. 피처링 캠페인 팀은 이러한 사내 서비스를 활용함에도 캠페인 운영시 많은 작업들이 수작업으로 이뤄지고 있습니다. 이러한 수작업들을 개선하여 운영팀의 생산성을 향상시키고, 퀄리티를 올려 클라이언트의 만족도도 올릴 수 있도록 하고자 합니다.

Problem

기존 방식의 한계 (데이터가 많으나 활용도는 낮다)

 

• 피처링의 인플루언서 찾기 서비스는 그동안 많은 발전을 해왔습니다. 그럼에도 피처링에서는 많은 데이터를 가지고 있지만 실제 캠페인 운영에서 적합한 인플루언서를 찾을 때의 활용도는 높지 않습니다. 그 이유는 피처링에서 제공하는 “검색”서비스가 “키워드, “필터” 같은 단순한 구조로 되어 있고, 조건이 명확해야만 좋은 결과를 볼 수 있기 때문입니다.

• 캠페인팀에서의 인플루언서 선정 방식은 일반적으로 DA파트에 따로 요청을 하거나 필요한 경우 “카테고리”만 필터를 걸어 광범위한 인플루언서 리스트를 만듭니다. 그 이후 입맛에 맞도록 정렬을 이리 저리 섞어서 최종적으로 후보를 선정합니다. 다른 회사의 경우에도 크게 다르지 않을 것이라 생각합니다.

해결목표 ( 인플루언서 탐색의 고도화 )

• chatGPT처럼 인플루언서를 편히 찾을 수 있도록 하게하면 위의 공수가 줄어들지 않을까?

  • 검색엔진 고도화를 기다리는건?

    • 동의어, 유사어, 유사동의어 등 검색엔진의 고도화가 이루어진다면 어느 정도 편의를 제공해줄 수 있겠지만 난이도가 높은 일이라 쉽게 이루어지진 않는 스텝입니다.

    • 동의어의 정의, 동의어 찾기 등 고도화를 위한 기능 하나하나를 구현하기 위해 제법 많은 리소스가 들어가게 됩니다.

    • 심지어 이 과정도 지속적인 모니터링이 필요해 운영면에서도 만만찮은 리소스가 필요하게 됩니다.

    • 안 그래도 할일이 많은 스타트업의 데이터팀에서 이런 일을 하기엔 부담이 됩니다.

  • 그러던 중 생각해낸 것이 chatGPT 처럼 검색엔진 쪽에 달아보는 것이었습니다.

    • LLM을 이용한다면 구축에 큰 리소스를 붓지 않고도 자유도를 높게하여 구현이 가능하고, 운영면에서도 많은 리소스는 들지 않을 것이라 판단했습니다.

  • 여기에 추가적인 고민, LLM을 사용하되 우리가 가진 데이터도 100% 활용할 수 있으면 좋겠다!

    • 2억의 데이터가 아깝다!

Architecture

 

• 해결목표를 달성하기 위한 간략한 구조는 위와 같습니다.

• 해결목표에서의 목적들을 달성하기엔 aws의 Bedrock이 최적이라 판단했습니다.

  • 그 이유 중 가장 큰 이유는 우리가 가진 데이터를 100% 활용이 쉽게 가능하다는 이유였습니다.

  • 어떻게? → knowledge Base를 이용해서!

  • LLM에서 자신이 가진 데이터를 활용하는 방법으로는 RAG(Retrieval-Augmented Generation)를 가장 많이 사용하고 있습니다.

  • 검색 증강 생성이란?

    • RAG(Retrieval-Augmented Generation)는 대규모 언어 모델의 출력을 최적화하여 응답을 생성하기 전에 학습 데이터 소스 외부의 신뢰할 수 있는 지식 베이스를 참조하도록 하는 프로세스입니다. 대규모 언어 모델(LLM)은 방대한 양의 데이터를 기반으로 학습되며 수십억 개의 매개 변수를 사용하여 질문에 대한 답변, 언어 번역, 문장 완성과 같은 작업에 대한 독창적인 결과를 생성합니다. RAG는 이미 강력한 LLM의 기능을 특정 도메인이나 조직의 내부 지식 기반으로 확장하므로 모델을 다시 교육할 필요가 없습니다. 이는 LLM 결과를 개선하여 다양한 상황에서 관련성, 정확성 및 유용성을 유지하기 위한 비용 효율적인 접근 방식입니다.

      • ref: https://aws.amazon.com/ko/what-is/retrieval-augmented-generation/

  • RAG의 중요성을 알지만 이를 고려한 아키텍처 설계는 사실 굉장히 복잡합니다.

    • RAG의 일반적인 구조

      

    • RAG를 이용하기 위해선 가장 중요한 것은 Vector DB와 Vector Embedding입니다.

      • 하지만 적절한 Embedding model 선정, Vector DB 선정도 어려운 일이며

      • Vector Embedding을 위해서 Embedding Model이 상시 이용 가능하도록 세팅되어 있어야 합니다.

  • 2023년 12월 12일에 발표한 AWS의 Bedrock knowledge bases는 위의 과정 중 RAG에 해당하는 부분을 단순화시켜 적은 리소스로도 구현히 가능하도록 되어 있습니다.

  • 이를 통해 기존의 데이터를 knowledge base용으로 data transform하는 것만으로 embedding부터 vector db 구성까지 “선택”하는 것만으로 구성이 가능했습니다.

Data Prepare and Preprocessing

• 인플루언서 포스팅, 인플루언서 정보를 추출합니다.

  • 데이터 컬럼 예시

    • content_id, taken_at, like_count, comment_count, content_type, …

• 데이터 전처리를 통해 쿼리 검색을 용이하게 해둡니다.

  • UTC → KST

  • csv 파일 사이즈를 50MB로 제한해 분할

  • metadata 제작

  • 좋아요, 댓글 수

    • 좋아요, 댓글이 비공개인 경우 0으로 처리

  • 인게이지먼트 피처

  • 포스팅 정보에 포스팅 저자인 인플루언서의 정보 연결

Consist of LLM model

모델 선정

• 모델은 Anthropic의 Claude 3.5 Sonnet을 이용했습니다.

  • 처음 시작할 때엔 Claude와 Titan 외에는 제공되는 모델이 없었습니다.

    • knowledge base의 임베딩 모델의 경우는 Titan 말고는 여전히 없네요!

      

  • aws bedrock에서 현재는 굉장히 많은 모델이 제공되고 있습니다!

    

• 글로벌 서비스화를 목표로 하고 있으면서도 base는 한국어이기에 한국어에 대한 처리가 잘 되는 것을 선호합니다.

• 이에 따라 선택한 것이 Claude 3.5 Sonnet 이었습니다.

에이전트

• chat 방식의 경우 instant로 주로 이용되며, system prompt를 이용하기가 다소 어렵습니다.

• instant여도 상관없을 것 같지만 질문하는 내용을 기록하고, 이를 바탕으로 답변했던 내용들을 기억해두는 것이 앞으로 유저들이 사용하는데 더 좋을 것이라 판단했습니다.

• Agent를 이용하는 경우는 system prompt 세팅이 별도로 존재하며, 대화를 저장할지에 대한 옵션도 달려있어 지속적인 대화가 이루어지는 경우가 많은 저희 회사 서비스에는 적합하다고 판단했습니다.

Service (Demo)

실제 데이터를 넣고 사용해보면 기대했던 결과만큼 나올까? ( 제발 나오길… )
이런 바람으로 먼저 데이터 일부만 넣어 서비스화 했을때를 가정해 환경을 구성하여 보았습니다.

Knowledge base에는 knowledge base 데이터 동기화만 되면 바로 모델을 붙여 테스트 해볼 수 있는 기능이 제공됩니다.

knowledgebase에서는 Claude 계열의 모델만 제공되는 것으로 보이네요. 저흰 실제로 Claude 모델을 앞단에 사용할 생각이었어서 큰 문제는 없었습니다.

결과비교

• “겨울 패션에 어울리는 인플루언서”라는 동일한 input을 넣고, knowledge base를 연결한 버전과 안한 버전을 비교해보았습니다.

• knowledge base가 붙지 않는 경우는 전반적으로 잘 알려져 있는 인플루언서를 선정한 반면

• knowledge base가 붙은 경우는 데이터를 기반으로 인플루언서를 찾아주었습니다.

  • 추가적으로 어떤 소스를 기반으로 찾았는지도 나와 있어 인플루언서 리스트업에 근거까지 붙일 수 있는 유용한 도구라 판단됩니다.

1부 마무리

어떻게 하면 검색을 좀 더 편하게 제공할 수 있을까로 출발하여 LLM까지 붙게된 생각보다 큰(?) 프로젝트였습니다. 비록 소량의 데이터로 테스트만 해보았으나 그 결과는 기대 이상으로 긍정적이었습니다. 이를 통해 검색의 퀄리티는 물론 캠페인 팀의 업무효율화 향상 또한 도모할 수 있지 않을까라 생각합니다.

또한, 본 프로젝트의 경험과 사례가 LLM 도입을 고민하고 있는 다른 회사들에도 의미 있는 참고 자료가 되기를 바랍니다. 특히, 제한된 리소스와 현실적인 제약 속에서도 aws bedrock을 통한 효율적인 아키텍처 구성을 통해 복잡한 RAG 등 LLM을 위한 구성을 비교적 적은 리소스 투입으로 높은 성과를 달성할 수 있는 가능성을 확인할 수 있었습니다.

다음에는 실제 데이터를 부어보고 post processing을 통해 “인플루언서 추천”을 하는 과정으로 찾아오도록 하겠습니다. 감사합니다.