🏃🏻♂️ (원티드x네이버 클라우드) 2024 프롬프톤
에 참가한 내용과 관련 개발 내용을 포함하고 있습니다.
본편은 아래의 내용을 포함하고 있습니다.
- 왜 AI 성형 코디네이터를 만들게 되었는지 (개발동기)
- 개발한 RAG 시스템 기획 & 개발
- 개발한 웹서비스 기획 & 개발
본편은 아래의 내용으로 이어집니다.
모든 편의 글의 양이 조금 많습니다. 이해 부탁드립니다.
개발 동기
1. 늘어난 성형에 대한 관심
최근 성형에 대한 관심이 부쩍 높아졌습니다. 얼마 전 여의도 더현X에 놀러갔을 때 수많은 일본, 중국인 관광객이 성형을 마친 후, 붕대를 감고 구경을 하고 있는 것을 보았습니다. 제 친구에게 물어보니, 실제로 한국에 성형을 하러 많은 외국인이 방문을 하고 있으며 한국의 의료 기술이 뛰어나다는 답변을 들을 수 있었습니다.
저도 마침 피부관리로 인해 성형 수술/시술에 관심이 많은 상태였고, 저는 다양한 의견과 추천을 받고자 '미용 성형'하면 떠오르는 대명사 '강남언X'에서 여러 병원을 알아보고 있었습니다. 그리고, 성형과 관련된 커뮤니티가 있는 것을 확인하였습니다.
2. 다들 궁금한게 많구나?
커뮤니티에는 다양한 의견들이 있었습니다. 특히 본인의 궁금함을 물어보기 위한 질문이 많았고, 그 중 일부 답변들은 의사선생님들께서 친절하게 답변을 달아주시고 계셨습니다.
하지만 이 성형이라는 분야가 본인의 신체와 관련된 문제이다보니, 질문에 대한 정확한 답변이 필요하다고 생각합니다. 하지만, 의사 선생님의 답변은 법적 책임(실제 진료를 보았을 경우)으로 인해 다소 제한적이고, 강남언X와 다르게 의사가 없는 커뮤니티는 '카더라'하는 이야기가 많이 돌고 있음을 알 수 있었습니다.
저희팀은 "성형에 대한 정보를 정확하게 알 수 있는 방법이 없을까?"에서 출발했습니다.
3. 성형과 관련된 정확한 정보는 어디에서?
구글, 네이버에 각 수술에 대한 정보를 검색하면 많은 정보가 나옵니다. 특히, 수술후기 등이 많았고, 부정확한 정보도 사이사이 끼어있었습니다. 물론 공신력 있는 정보들도 많이 있었지만, 병원 광고이거나 정확한 답변을 얻기 위해서는 여러 소스를 뒤져야만 했습니다.
그러다, 다음과 같은 자료를 발견했습니다.
대한성형외과학회, 한국보건의료연구원에서 주관하여 제작한 미용성형시술 이용자 정보집이었습니다. 안에는 각 수술에 대한 다양한 정보와 내용이 포함되어 있었고, 이곳에서는 정확한 정보를 얻을 수 있었습니다.
저희팀은 이를 바탕으로 사용자들이 질문을 했을 때, 정확한 정보집으로부터 데이터를 추출하여 해당 내용만을 기반으로 인공지능을 통해 답변해준다면, 사용자들은 보다 정확한 정보를 빠르게 얻을 수 있으리란 판단을 했습니다.
마침 wanted LaaS를 통해 프롬프팅으로 개발하는 대회인 2024 원티드x네이버클라우드 프롬프톤에 참여하게 되어, 이에 출품할 프로젝트로 개발에 착수하게 되었습니다.
이를 통해 일반 사용자가 성형에 대한 보다 정확한 정보를 얻을 수 있도록 하고 싶었습니다.
LaaS를 활용한 RAG 시스템 구축
1. 기획 단계
저희는 솔루션을 기획하며 LLM 기술의 기획 단계에서 답변의 품질과 관련한 부분에서 2가지를 고려했습니다.
-
부정확한 답변을 만들지 말아야 한다.
저희는 사용자가 한 질문에 적절한 답변을 해주고 싶었습니다. 특히 LLM 모델의 hallucination(환각현상)에 적절하게 대응하여 부정확한 답변을 생성하지 않도록 하는 것이 목표였습니다. -
사용자의 고민성 질문에도 답변해주어야 한다.
예를 들어, 사용자들은 "피부가 좋아지고 싶어요. 어떻게 해야할까요?와 같이 본인이 어떤걸 하고 싶은지를 이야기 하기도 하지만, "피부가 너무 안좋아서 고민이야"와 같이 실제 본인의 고민을 이야기 하기도 합니다. 이런 답변도 잘 되는 RAG를 구축하고 싶었습니다. 왜 2번이 중요한 고려사항인지는 아래에 등장합니다.
2. Retrieve 기술 소개 및 한계 (RAG)
우선 정확한 답변을 만들기 위해 무엇을 해야할까요? 물론 대회중 사용한 네이버의 HyperClova X의 경우 매우 정확한 한국어 LLM이었습니다. 성형과 관련된 최신의 다양한 정보들을 포함하고 있었습니다.
그러나, 이후 더 최신의 다양한 정보가 등장한다면 어떨까요? 아니면, 실제 LLM이 학습한 정보가 부정확하거나, 혹은 성형 시술에 대한 일반적이지 않은 정보를 포함해야 한다면 어떨까요? 이럴 경우, 정확한 생성이 어렵거나 그럴듯한 말을 생성하는 환각현상(Hallucination)이 발생할 것입니다.
그러므로, 저희는 최신 기술인 RAG를 도입하고자 하였습니다.
RAG는 Retrieval-Augmented Generation 기술로, 언어모델이 답변을 생성할 때, 질문과 관련된 정보를 주고 해당 정보를 바탕으로 생성하는 기술입니다. 위의 그림처럼, 어떤 질문이 들어왔을 때, 탐색기(Retriever)가 데이터베이스에서 사용자의 질문과 유사한 문서를 찾아 언어모델에 넘겨주어 지식을 확장(Augmented)하여 답변을 생성(Generation)하는 기술입니다.
그러나 여기서 고려사항 2번이 등장한 이유가 나옵니다. 만약 사용자의 질문이 위의 그림과 같을때, Retriever가 기존 RAG의 방식을 사용하여 가장 유사한 문서를 골라준다면 아마 문서2: 유방 축소 수술에 대한 문서를 골라줄 것입니다. 왜냐하면 가슴, 작아서와 같은 단어가 유방 축소와 유사하기 때문입니다. 이를 해결하기 위해 저희는 기존 유사도 기반 탐색이 아닌 LLM 기반 탐색 방식을 고안하여 적용하였습니다.
3. LLM 기반 탐색 방식
저희는 이를 개선하기 위해 위와 같은 LLM 기반의 탐색 방식을 고안하였습니다.
간략하게 소개드리면, 다양한 문서 중 정확한 문서를 고르기 위해, LLM에게 프롬프팅을 통해 어떤 정보를 사용해줄지 고르도록 하는 방식입니다. 그러나, 어떤 정보를 사용할지 판단하기 위해 실제 모든 내용을 입력으로 주는 것이 아닌 원래 문서에 요약 정보를 제공하여 LLM이 실제 어떤 정보를 사용할지 고르는 방식입니다. 이를 통해 사용량을 절감하여 효과적인 사용이 가능합니다.
이 방식을 사용하여, 저희는 더욱 정확한 문서를 사용할 수 있도록 선별할 수 있었습니다. 또한, 더욱 세밀한 정보탐색을 위하여, 선별된 문서에서 어떤 문단을 사용하면 좋을지 LLM을 통해 탐색하도록 하였으며, 이 방식 역시 요약 정보를 바탕으로 한개 이상의 문단을 고르도록 했습니다.
Retrieve 방식에 사용된 모든 프롬프트 제작과 A/B 테스트는 wanted에서 개발한 LaaS 솔루션을 통해 개발, 실험되었습니다. 이를 활용하여 매우 효과적이고 편하게 웹 환경에서 프롬프트 제작을 할 수 있었습니다.
3. Generation 기술 설계 (RAG)
이제 선별된 정보를 바탕으로 질문에 대한 생성을 수행했습니다. 또한, 저희는 다양한 정보와 사람들의 의견을 한번에 보도록 하여 사용자의 편의성을 증가시키고 싶었습니다. 이를 위해, 주어진 정보를 바탕으로 사용자의 질문에 답하는 프롬프트, 온라인 뉴스, 성형 커뮤니티에서 질문 관련된 시술에 대한 내용을 크롤링하고 그에 대한 요약 정보를 제공하는 생성 프롬프트와 주어진 정보를 바탕으로 해볼 수 있는 다른 질문을 생성하도록 하였습니다.
왜 추가 질문에 대한 프롬프트를 개발했는가에 대한 생각을 하실 수 있을 것 같습니다. 사실 대부분의 사람들은 '성형'에 대해 구체적으로 알지 못하는 사람들입니다. 내가 어떤 시술을 해야하는지, 어떤 질문을 해봐야하는지 모릅니다. 저도 그렇습니다. 그렇기 때문에, 사용자에게 먼저 "이런건 궁금하지 않으세요?"하고 알려주는 것이죠. 이를 통해 사용자는 이 코디네이터 서비스를 자주 사용하게 될 것이고, 다양한 비즈니스 가치 창출 효과를 가져올 수 있는 것이죠.
커뮤니티나 뉴스 등도 마찬가지였습니다. 실제 많은 서비스들이 충성 고객을 확보하고자, 자체 커뮤니티를 운영하고 활성화하고 있습니다. 이런 상황에서 커뮤니티의 의견이나 정보를 요약해서 보여주고, 이 RAG 서비스를 특정 회사에 탑재한다면 해당 회사의 커뮤니티 활성화에도 기여할 수 있는 것이죠.
이를 통해 저희는 다양한 프롬프트, RAG 시스템을 만들었습니다. 개발 과정에서 다양한 시행착오와 문제가 있었습니다. 그럼에도 네이버의 HCX 모델과 wanted의 LaaS 서비스로 인해 더 편하고 빠르게 시행착오를 해결할 수 있었습니다. 이에 대한 내용은 2, 3편을 확인해주세요.
LaaS, RAG 기반의 웹 서비스 구축
1. 기획단계
이제 이 RAG 시스템과 wanted LaaS의 API를 활용하여 새로운 서비스를 제공하고자 하였습니다. 이를 위해, 사용자의 입력을 받아 LaaS API와 통신하여 정보를 전달하고, 생성된 결과를 시각화하여 보여주는 웹서비스를 제작하고자 하였습니다. 이를 위해 저희는 단 하나의 원칙으로 개발에 착수하였습니다.
사용자의 체감 대기시간을 줄여야한다
실제로 저희는 다양한 프롬프트를 개발하고 이를 복합적으로 활용하기 때문에, 하나의 답변만 생성하는 것에 비해 속도가 느립니다. 실제 생성까지 시간은 오래 걸리더라도, 사용자가 이를 체감하지 못하게 만드는 것을 통해 극복할 수 있다고 생각했습니다. 마치 엘리베이터 거울과 같은 효과를 기대하는 것이죠.
2. 서비스 구조 설계
저는 우선 인공지능 개발을 중심으로 하다보니, 프론트엔드에는 조금 약한 편입니다. 그래서, 파이썬과 간단한 HTML을 사용하여 개발할 수 있는 Flask를 선호하는 편입니다. 그래서 저희는 우선 아래와 같은 구조를 고안하였습니다.
Flask를 사용해서 서버에서 HTML 페이지를 랜더링하여 전달하는 방식을 채택하였습니다. 유저가 정보를 보내면, 서버에서 입력을 받고, LaaS서버와 통신하며 정보를 주고 받는 구조입니다. 이런 방식은 위와 같은 문제가 있었습니다. 사용자가 요청을 보내면 자체 서버 및 LaaS서버가 내용을 처리하는 동안 사용자가 너무 오랜 시간 기다리는 것이었습니다. 답변이 긴 경우 10초 이상을 기다리는 경우도 발생하였습니다. 또한 Flask자체의 속도도 느린 편이었습니다.
저희는 이런 구조를 개선하고자 다음과 같이 백엔드와 프론트 엔드를 분리하여 개발했습니다. 서버를 flask에서 fastAPI로 변경하고, 실제 사용자는 1번의 request를 보내지만 React로 개발된 프론트에서 request를 여러번으로 쪼개어 API 서버로 request를 보내고, 서버에서는 먼저 처리가 되는대로 반환을 하는 구조를 채택하였습니다. 그리고 프론트엔드에서는 백엔드서버로부터 정보가 오는대로 사용자에게 전달합니다.
또한, UX적인 개선이 동반되었습니다. Flask를 사용한 경우, 서버에서 모든 처리가 끝나는 동안 유저가 하얀색 로딩화면을 보고 있어야 하는 반면, 이 방식을 통해 사용자에게 실제 어디까지 처리가 되었는지, 혹은 로딩중이라는 시각적 모션을 전달할 수 있게 되었습니다. 다양한 소스와 HCX 언어모델을 활용하여 첫 React 개발임에도 수월하게 원하는 기능을 개발할 수 있었습니다.
3. 완성된 최종 구조
최종적으로 저희는 위의 그림과 같은 구조로 간단한 토이 서비스를 개발 완료하였습니다. 사용자가 입력을 보내면, React 프론트 서버가 입력을 쪼개어 백엔드로 전달하며, 백엔드 서버에서는 wanted LaaS서버, 커뮤니티 웹페이지, 네이버 뉴스, 그리고 AWS S3에 저장된 성형 정보를 활용해 정답과 생성 결과를 가공하여 프론트에 전달합니다.
4. 서비스 소개
위의 영상은 저희가 개발한 서비스를 실제 사용하는 영상입니다. 웹 서비스이며, 아직은 개발 서버에서만 작동이 가능합니다. 실제 제출일 이후 해당 서버를 오픈할 계획에 있습니다.
아직은 첫주다보니 기능 개발을 우선적으로 진행하였습니다. 이후 프롬프트 개선과 네이버 HCX 사용에 대한 글도 2, 3편에서 진행됩니다.
다음편 읽기
