2018년 8월 29일 수요일

Production Deep Learning 서비스 Pain Point 에 대한 단상 - E-Commerce Product Overview 기능을 통한 분석

요즘 해외 배송이 빨라지고 저렴해 지면서, 전자 제품 및 노트북 액서서리 등등 은 거의 Amazon 및 Alibaba 를 이용하고 있다. 특히 고가의 IT기기의 경우 국내가격대비 20% 이상 저렴한 것을 감안하면, 가격 Save 도 큰 역할을 한다. 하지만 그 무엇보다, Amazon 및 Alibaba 의 IT 기기 Search와 상품상세 view에 있어서의 site 의 편리함과 Data Driven Overview 기능의 사용성은 그 모든것을 능가하는 쐐기를 박는 요소가 아닐 수 없다.
우선 alibaba 는 IT 기기들의 경우 카테고리별로 사용자들이 주로 보는 속성들을 Quick Details 라는 메뉴로 요약해서 보여준다. 사실 이 부분만 보면 거의 98%에 가까운 확인 사항을 모두 확인 할 수 있어서, 상품상세를 모두 봐야 할 필요가 없다.

우리나라 e-commerce 의 경우 무겁고 어마어마한 크기의 카탈로그 scan 이미지를 모두 봐야 제품 상세 정보를 알수 있는 경우가 많고, 요약 속성을 제공하는 경우에도, 업자가 자체적으로 제공하여, 상품마다, 노출 위치나 항목, 요약 정보의 제공 패턴이 모두 제각각이다. 불리한 속성은 일부러 언급하지 않는 경우도 있고, 그 경우에는 어마어마한 크기의 카달로그를 죄다 뒤져야 한다.
Amazon 은 한단계 더 진화 했다. 최근 보았던 2개를 포함하여 총 3개를 비교하여 한눈에 difference 의 요약 정보를 일목 요연 하게 보여 준다.

이는 비단, 사용성과 편리함의 문제로 그치지 않는다. 상품 카테고리별로 중요한 속성이 뭔지를 아는것, 그리고 각 상품별로 그 속성의 값이 무엇인지를 아는 것은 e-commerce site 에서 어마어마한 자산일 수 있다.
일반적인 e-commerce site 의 대부분이 상품별로 제목, 상품상세 text, 카테고리, 브랜드 등만을 관리하는 것과 달리, 위 선진 site 들 처럼 각각의 대표속성, 대표 키워드 등을 관리한다는 것은 Semantic Search , 자연어 기반 챗봇 검색, 속성기반 유사도 추천, 품절 대체 추천, 기타 검색 품질 관리에 있어서도 많은 유리함을 가져다 준다. 다차원의 속성이 있으면, 모든 상품을 N차원 공간에 배치할 수도 있다. 그리고, 그런 유사 상품의 공간 백터 상 관리는, 상품별로 가격, 배송,물류 관리 등 다방명의 Data Driven Model 을 만듦에 있어, 매우 큰 기초 Data 역할을 한다. 약간의 Deep Learning NLP 를 가미하면, 상품명을 몰라도 그 상품을 수식하는 형용사 만으로도 상품을 찾아들어갈 수 있다.
최근의 e-commerce Text NLP AI use case 관련 논문들은 자연어 문장에서 단순하게 NER 만 뽑아내는 것이 아닌, NER 을 뽑아냄과 동시에 이러한 중요 속성을 함께 뽑아내는 연구가 이루어지고 있음을 보여준다. 문장중에 언급이 없어도, 성별을 찾고, 어른용을 찾는지 아이들용을 찾는지, 선물용인지 등등의 중요속성 정보를 NER 뽑아내듯, 화자 혹은 검색 사용자의 일부 단서나 나열된 keyword sequence 로부터 뽑아준다는 의미이다.
해당 논문을 몇달 전부터 구현레벨에서 검토하였는데, 역시, 구현보다 어려운것이, 그 데이타의 Training 을 위한 Input Data 가 legacy 에 존재하지 않는 다는 점이다. 요즘 내가 alibaba 나 amazon 의 저런 제품 속성 기반 Generated(or Model Managed) Overview 기능에 관심을 갖는 이유라 하겠다.
그렇다면, 해당 속성 데이타가 없다는 것은 누구의 잘못인가? 의사결정자의 잘못인가? 기획자? 전략부서? 데이타부서? AI부서? 그 누구의 잘못도 아니다. 그걸 100% 수작업으로 만들어 내려는 시도는 10년전에도 많은 기획자들이 고민했던 ROI 답 안나오는(그래서 검색 Tag 정도만 최소로 관리하는) 문제 중 하나이다. 그래서 그런것을 만들어내는 것 또한, 요즘은 Deep Learning Model 로 접근하고 있다. 혹은 Model 이 95% 정도를 자동으로 해주고, 소수의 운영자 및 알바생들이, Accuracy 점수가 낮은 순으로 정렬하여, quick 하게 eye checking 만 하면서, click, drag 가 대부분 작업이도록 하면서 supervised learning 되도록 operation 관리자 페이지를 구성하여 구성하는 사례가 선진사례에서 등장하고 있다. 즉, ROI 안나오던 작업이 AI Assist 로 인하여, ROI 가 나오는 해볼만 한 작업이 된 것이다.
하루에 수천건의 신규 상품이 들어와도 자동 분류 되고, 자동 tagging 되고, 공간상에 자동으로 꼳혀 들어가야 하고, operator 에 의한 정교화 보정 작업은 후처리 사항이며 모든것을 전수 관리할 필요가 없어졌다. 이를 프로세스화 하고 입력시점에 업체들에게 위임 할 수도 있으나, 업체는 낚시성 Tag 를 다는데 더 최적화 되어 있으며, 이는 Noise 에 해당한다. 감지된 데이타에 대한 보정 작업은, Supervised Learning, 좀더 구체적으로는 online learning 의 재료로 쓰이며, 모델 진화에 기여 한다. 그것보다 더 잘 기획된 AI 서비스는 그 과정에서, 모든 training 진화를 Operator가 죄다 하는 것이 아닌, 사용자의 반응 및 행위가 model 의 진화에 기여 하도록 UI 기획을 하는 것이라 할 수 있다.(요즘 기획자들은 그래서 Deep Learning 개념을 좀 알고 있어야 한다.)

결론을 내 보겠다.
Production AI 서비스를 하다보면,
  1. Main Problem 의 model 을 만드는 일이 사실 제일 쉬운 문제이다. 연구도 많이 되어 있고, 논문 혹은 바로 쓸 수 있는 오픈소스나 github 구현체를 찾아서 활용할 수도 있다.
  2. 그보다 어려운 부분이 다수동접처리 및 빠른 서빙, 무중지 배포, Auto Scale Out 등의 문제이다. 여기서부터는 Lab 에서 연구하지 않는 분야이고, 참고 자료가 많지 않기 때문이다. 이를 위한 방법론은 여러차례 블로깅 한 적이 있었다.
  3. 그보다 더 어려운 부분은 만드는 AI Production 서비스에 Freshness 와 personalization 을 추가하는 문제이다. Freshness 는 병렬성이 핵심이며, realtime 인입이 필요하여 kafka, spark streamming 등의 도움이 필요할 수 있으며, 람다 아키텍처가 필요하고, 요즘 스타일로는 Serverless Microservice 기술이 필요하고, kubernetess 및 docker 를 끌여들여야 할 수 있다. Personalizaion 으로 가면, 모델의 차원이 커지고, 사람별로 혹은 상품별로 Training 을 하기 위해 BigData Scale 의 Computing 과 분산 Deep Learning 을 위한 BigData 기술 연계가 동원된다. (개발 생산성과 low level tensorflow 직접 분산처리보다 더 빠른 컴퓨팅을 위해서 이기도 하거니와, 수많은 heavy pre-processing 을 위해서이기도 하다.) 이를 위한 방법론은 여러차례 블로깅 한 적이 있었다.
  4. 그보다 더 어려운 문제는 양질의 Data 를 확보하는 문제이다. 결국은 Production 직전에 혹은 직 후에 이 부분에 직면하게 된다. Garbage in Garbage out 이다. 모델에 집중하면 정확도 3% 올리는데 반년이 걸릴 수 있지만, Input Data 에 집중하면 몇달을 투자하여 정확도가 10%가 올라갈 수도 있다. 국내에 AI Production Service 를 잘하는 곳도 여기까지 와서 주저 앉는 경우가 많다. 일반적인 IT 프로젝트 처럼 오픈 이후 바로 결과를 확인 하는 습관 때문이기도 하다. AI 프로젝트는 여기서부터 시작이라고 해도 과언이 아니다. 반응을 보지 않고, 상상으로 개발한 1차 결과물보다, 실 데이타가 3달 이상 쌓인 후 이를 보면서, 2차 3차 고도화를 통해, 상상 Training Data 와 Real Input Data 간의 괴리를 줄이는 작업이 이후에 지속적으로 투자 되어야 하는데, 이를 기달리지 못하고, 초기 결과를 보고 스폰을 받지 못하여 Operation 과 이와 맞물린 관리적 고도화가 되지 못하는 AI 서비스를 주변에서 많이 보았다.
  5. 그보다 더 어려운 문제는 양질의 Data를 수작업을 통해서가 아닌 자동으로 혹은, 자동80% 수동 20% 정도로 확보하게 만드는 일이다. e-commerce 를 예를 들자면, OCR, 댓글 텍스트, 크롤링 등등 다양한 방식으로 이런한 Data 를 Generation 화 할 수 있으며, 중요속성을 뽑아내는 다양한 알고리즘이 존재한다. 하지만, 이 부분은 경험해 보니, 모델이 어려운게 아니라, 이것 자체가 또하나의 프로젝트가 되어버리는 것이 문제였다. A 프로젝트를 잘하기 위해 B 프로젝트를 또 해야 해요! 가 조직에 잘 설득되지 않는 경우가 많았다. 사실 할일도 많고, 인력도 없는데, A 프로젝트도 겨우 인력 짜내서 하는 형국에 B 는 Minor 로 치부되는 것이, 당연한 현실 일 수 있다.
  6. 그것보다 더 어려운 문제는 양질의 Data 와 이후 Production 중 보정 후 재 Training 이 사용자들에 의하여 원순환으로 알아서 진화되도록 UI를 잘 만드는 일이다. 덧붙여 이에 맞는 원순환 맞춤 관리자 페이지도 나와줘야 한다. 덧붙여 모델 자체도 원순환 training 이 가능하도록, 람다 아키텍처 및 batch training, 그리고, 무중지 online training 이 삼박자가 잘 맞게 개발되어야 한다. 아쉽지만, 이는, R&R 지옥을 뚫고 기획을 개발자가 하거나, 기획자가 개발자가 되거나 하는 정도의 Mix 된 융합 Co-Work 이 필요하며, 딱 그 만큼(정말로 개발자가 기획을 하고, 기획자가 개발하는 것 만큼이나)이나 어렵다.
오늘 언급한 Production Deep Learning 서비스의 Pain Point 에 대한 단상은 결국, 기획과 모델링과 개발의 유기적인 결합이 중요한 Key 라는 결론으로 귀결 되었다.
경험해 보건데, 현실적으로 이를 위해 제일 쉬웠던 방법은....
  1. 끊임없이 개발자나 모델러들이, 기획자를, 윗분들을 설득하고 , 또 말하고, 또 설득하고... 그 과정에서 싸우기도 하고, 장문의 편지도 많이 쓰고.. 설레발도 많이 떨고, 페이스북에 기사같은것도 막 퍼 날라주고....TT 지난한 일이지만, 그래야....느린속도로 라도 둘 간에 혹은 셋간에(경우에 따라서 넷 이상이 될 수도 있는게 현실이다. TT) 바라보는 곳이 같아지고, Over lap 되어 일하는 부분이 늘어나는 것 같다.
  2. 그리고, 그들을 설득하고, 우리들의 가장 큰 약점인 말빨에서 밀리지 않기 위해서는, 우리들도 끊임없이 문과적으로 사고하고, 비지니스도 좀 가중치를 올려주고, 기획적인 사고도 더 연습하고 더 자주해야 한다는 점이다.
  3. 기획자에게 Deep Learning 에 대한 꿈과 밝은 미래를 자주 주입해주고, 공짜 컨퍼런스 티켓도 좀 사비로라도 사서 나 시간없어서 사놓고 못간다고 하면서 좀 던져 주고, 기획자에게 패스트캠퍼스나 모두의 연구소 같은것도 좀 추천해주고.... 이것이 은근히 정말 큰 도움이 된다. 기획자가 50%를 이해하면, 회의시간이 3배 이상 줄어 들고, 서로 딴이야기를 하지 않을 확률이 200% 이상 증가하는 듯 하다. 실제 경험담이다.
  4. 위 6단계를 warter fall 로 한다는 것은 말도 안되는 일이다. 외주에 맞기고, Production 시점부터 즉, 위 6단계의 4부터 외주업체가 나간체로 내부에서 한다는 것도 말이 안되는 일이다. 물론 협력하면서 프로젝트를 한 경우는 가능할 수 있다. 결국 초반엔 첫 프로젝트는 개고생을 감수해야 할지도 모르겠다. 역시 경험담이다. 개고생한만큼 기술도, 그리고 위를 이끌어 낼려는 간절함의 동인으로 부터 야기된 설레발 능력(1에서 많이 활용되는 능력이다)도 성숙해지는 듯 하다.
  5. 성공을 한번 맞보게 하는것이 매우 중요해 보인다. 그런데 매우 초기에 빨리 맛보게 해줘야 한다. 그렇지 못한다면 자멸할 수도 있다. 이후 그것을 발판삼아야 스폰도 받고, 시간도 얻고, 인력도 얻어서, 시간을 Parallel 화 시킬 수 있다.(초기에는 누구도 기달려주는 사람이 없다.) 결국 AI 서비스는 아이에게 말을 가르치듯, 단계를 하나하나 잘 밟고, 시간 투자를 해야 하는데, 그런데 시간을 기달려주지 않는다....그렇다면, 조직에서 스폰서쉽이라도 받아서 Parallel 하게 모델들을 개발 하는게 중요하다.
요즘 박항서가 2002년도 히딩크 만큼이나 베트남에서 축구 감독으로 활약을 하고 있다. 우리나라에서 AI 하기는 우리나라 대표팀으로 월드컵 16강 가기 정도로, 생각할게 많은 듯 하다. AI와 축구는 멀티플레이어가 매우 중요한것도 닮아 있다. 그리고, 골을 넣는것도 중요하다. 결국 골을 못넣으면, 과정이 어찌 되었든 비난 받는다. 수많은 시선과 실시간으로 쏟아지는 매우 short-term 의 비판을 뚫고서도, long term 의 전략을 세우지 않으면, 본질적으로 결코 쉬운일이 아니다. 너무 log term 의 전략은 자칫 Short-term 의 비판에 나가 떨어지거나, 포기하거나, 이직하거나, 인사고과 D 맞기 십상이다. 하지만...본질적으로 우리나라는 16강 가기 위해, Long term 의 전략과 본질적인 기본기 확충을 위한 시간 투자와, 시스템의 개편과, 축구 협회의 성찰과 혁신도 필요하다.

대한민국 AI 개발자 화이팅 합시다.!!!!