000. 느낀점

인싸들만 간다는 네이버 데뷰. 2일차의 주제가 AI 위주여서 주위에 왜 가냐는 의문을 들었지만 이 분야에 대해 견문을 넓혀보고 싶은 욕심이 있어서 신청했다.

느낀 점은 개발자가 아닌 연구 + 개발자들이 많이 있다는 것과 데이터 과학을 공부해봐야겠다는 생각이 들었다.

1. 인공지능이 인공지능 챗봇을 만들다.

1. 챗봇이 뜨는 이유

금융, 커머스, 유통, 기업관리 등에 챗봇 적용중

2. 스스로 언어 배우는 챗봇 만들기

각 언어마다 문법과 구조가 달라 일반화 어려움. 단어의 의미를 파악하고, 주변을 통해서 feature를 추출할 수 있다. 즉, 단어의 주변을 이해해야 이 문장에서의 의미를 이해할 수 있다.

3.인공지능이 언어를 배우는 과정

Vector Representation

AI가 특정 상황에서 어떻게 대치해야 하는지를 배워야 한다. n차원의 공간에 n개의 원소는 문장의 특징이다. Embeding vector은 학습할 말뭉치를 의미한다.

각각의 언어구를 vector 거리로 파악한다. 말뭉치를 만들고, 학습시키고, 학습된 모델의 평가를 진행해야 해서 오랜 시간이 걸린다. 이를 인공지능 스스로가 학습할 수 있는지 알고 싶다. 내가 학습한 게 embedding vector이므로, 이걸 알아서 배우자.

4. AutoML

자신의 환경에 대해 학습하는 알고리즘을 생성하는 신경망 프로세스 말뭉치 -> 전처리(Data cleaning) -> Feature 선택, 추출, 확립 (형태소 분석을 통해 어순 파악) -> 모델 선택 -> 파라미터 최적화 -> 모델 확정 좋은 학습 리소스는 좋은 선생님이다. (질문 - 답변 시나리오) 스스로 학습, 평가 및 수정, 모델 평가 등을 모두 자동화 시킴. NLP 깃헙에 있는 거 쓰다보면, hyper parameter 바꾸고, 말뭉치 바꿔도 결과가 원하는대로 안 나온다. 이걸 AutoML으로 해결할 수 있다. 알아서 Hyper-Parameter tuning 과 서로다른 피쳐들을 합쳐 평가한 weight(앙상블 웨이트)를 통해 학습시킬 수 있으니 가능하다. 그런데 말뭉치를 주는 것만해도 졸라 힘들다. 몇억개를 어떻게넣냐.

말뭉치 만들기 & Model Validation 효율적 관리만 잘하면 된다.

5. AutoML 도와줄 프레임워크

Q&A Scenario -> 전처리 -> 모델링 -> 모델 앙상블 -> 답변 후보자

즉, Q&A Scenario의 Clustering 과 Model Tuning만 할 것인데, 이걸 자동화시키자.

모듈 설명해주겠다.

  • Feature Extraction : 언어 피쳐 추출
  • Query Pre-processing : 쿼리 전처리 및 학습 컨트롤러
  • Predict Answers with Dialogue Model : 전처리 된 쿼리를 통해 한국어 및 대화형 데이터에 최적인 SeqSeq 기반 텐서플로우 모델에 학습.

모델에는 저장되어 있는 정보는 ‘밥’ ‘을’ ‘먹다’ 와, POS 정보, EOMI(어미 정보)(X,X,다) 를 학습시키고 있다. cf) 어미 변형이 담고 있는 정보를 따로 적용하고 있다. 이런 여러 모델의 답변을 앙상블하여 답변 제공. 다양한 경로로 인입되는 쿼리를 실시간 처리 후 플랫폼으로 답변.

6. Chatbot 성능평가

발화 의도(대화 소재에 관련된 답변을 하고 있는가), 발화 소재(나/너 등의 지칭을 이해했는가) (사용자가 요청하느 것을 정확히 이해했는가), 답변 품질(이 질의에 대해 해당 답변이 최선의 품질인가) 이걸 자동 평가 해야 한다.

모델 스스로 각각의 쿼리를 Embedding Vector space(clustering완료된 애들) 시나리오에 포함된 쿼리 중 1~2개를 제외하고, 그 쿼리는 오직 모델 학습에만 사용한다. 클러스터링을 MSE로 평가하겠다. 매번 Clustering 할 때마다 Validation SET을 정하고, 자동학습 점수가 최대가 되는 Cluster K 를 선정할 수 있다.

군집 내 Cluster K - 군집 밖 Cluster K 를 한 것이 자동학습 점수 최대. 설계하기 나름. 해당 시나리오가 어느 클러스터에 가장 좋은지 알 수 있다.

Embedding vector의 Cosine-similarity 를 통해서 평가 진행.

코사인 유사도와 평균 제곱근 오차 -> 모델이 쿼리를 주어진 벡터 공간에 제대로 표현했는지 나타냄.

7. 클러스터링은?

아무 정보없는 질문-답변을 어디에 포함시킬 것인지, EN 알고리즘. 최대한 효율적으로 활용. Gaussian Mixture Models 데이터가 가우시안 분포의 믹스쳐로 구성, 밀도 방식의 크러스터링. K-means로 잘 묶어주니까 좋은 말뭉치가 생긴다.

8. Hyper parameter

Seq2Seq-based Retrieval Model

2. TesnorRT를 활용한 딥러닝 Interface

딥러닝 추론은 로보틱스, 모바일, 데이터 센터 등 다양한 환경에서 사용된다. 딥러닝 추론은 입력된 데이터에 대해 학습된 딥러닝 모델로 예측을 하는 행위다. 속도가 빠르지만 높은 정확도의 전제하에 좋은 효율이 요구됨.

1. 대용량 Inference에 대해

고려사항은 : 처리량, 응답속도, 고효율 고성능과 응답속도

CPU와 GPU의 Inference 성능 비교 -> GPU가 개중요

  • 처리속도와 정확도의 TradeOff
    • 작은 모델링은 정확도가 낮고, 큰 모델이 정확도가 높음.

결국, Inference의 최적화 방향은 가벼운 모델을 사용하거나, 모델 압축(큰 모델 성능 획득, 컴퓨팅 파워 따라가기)을 해야 한다.

2. TensorRT를 위한 Inference 최적화

ML 이후 Optimiizer를 위해 학습한 환경에서 Inference 하기 위해 TensorRT를 사용한다.

  • TNN을 TensorRT Optimizer
  • TensorRT Optimizer

모델 적용 절차(7단계)

  • TF 모델을 TRT 포맷으로 변환
  • 모델 Parser 생성
  • 입/출력 레이어 정보 입력
  • 모델 최적화 및 런타임 Engine 생성
  • 엔진을 파일로 저장
  • 엔진을 파일에서 읽음
  • Inference 수행

OpenPose에서 실시간 Inference에 대한 수요가 있었다. TensorRT만으로 얼마나 성능 향상이 가능한가.

3. Plugin Layer 개발

  • Layer 초기화
  • Enqueur
  • Serial, Deserial

플러그인 레이어 초기화 하려면 필요한 웨ㅔ이트의 개수를 복사해서 넣어주고, 메모리 할당.

3. 네이버 검색과 개인화

1. Word Matching

Word Matching 이 생각보다 효율적임.

Query에 단어가 많이 들어가면 조금 문제가 생긴다.

‘탑항공 폐업 리얼?’

에서 가장 중요한 단어가 무엇인지 이해해야한다.

TF-IDF(Term Frequency - Inverse Document Frequency)

흔하지 않은 단어에 대해 좀 더 높은 가중치를 준다. 단어를 Sparse vector라고 본다면, dense vector로 적은 스페이스 비교를 하도록 LSA란 테크닉을 쓴다. 각 단어에 추상적인 태그를 닮으로써, 폐업과 망하다를 클러스터링하는 것.

검색 != 문장 독해

문장을 읽는 것이 아니라, 단어를 통해 문서를 찾아주는 것이다 그래서 NLP가 필요하다.

2. NLP로 읽는 QA

왜 폐업했대? -> 읽어보니 대내외적인 경영환경 악화로 폐업했다.

1) 기계학습의 1번째. Input & Output

생성 모델 or 추출 모델?

  1. 생성모델(사람이 박아주는 거)
    • 서비스 퀄리티가 안 나온다.
    • 데이티 QA 가 안되어서 마음대로 답변을 다느라고 평가가 불가능하다.
    • 서술형 답변
  2. 추출 모델(Neural Extractive QA Trend)
    • 지금까지 7개정도의 마일스톤이 있었따.
    • Task Definition(Sentence, Phrase)
    • Models(Cross-attention, self-attention, Transfer learning, Super-human level)

1) Sentenence-level QA

  • 문장을 토큰화해서, 이 질문의 최고의 답변은 한 문장. (누가 ~를 만들었는가? -> 문장) 2) Phrase-level QA
  • 구로 정답을 내놓기. 3) Cross-attention
  • 문서를 읽으면서 질문을 참고, 질문을 읽으면서 문서를 참고하는 방식.
  • 누가 ~를 썼는가? 그러면.. 폴이 .. wrote..
  • 문서를 읽으면서 문서의 다른 부분을 참고.
  • Unlabeled corpose 를 공부할 수 있을까? (Wikipedia 같은 unlabeled 3 billion words) 4) Super-Human level
  • Ensemble 을 이용해서 이해
  • Data Augmentation (영 -> 한 -> 영 으로 데이터 또 생성)
  • 이것도 이제 끝났따 5) 다음 레벨은?
  • 이제는, 좀 더 복합적인 질문과 연계적인 질문을 이겨야 한다.
  • 또한, 문서에 대해서 질문하는 것은 참 빠른데, 질문은 그냥 노베이스로 온다.
  • 즉, 모든 문서에서 해당하는 질문을 찾아야 하는 것인가?
  • 그래서, 검색이 필요하다. 적당한 문서를 찾고, 그 안에서 답을 찾아야 한다.
  • 찾고나서 읽자!
  • 그런데, 검색에서 망하면 여러가지 pipeline을 가져서 Error Propagation 생긴다.
  • 이걸 어떻게 하면 한번에 할 수 있을까?
  • 서칭의 효율을 높이려면 벡터를 정리하면 된다.
  • 결국 라벨링에 대한 점수를 매겨서 Locality-Sesitive Hashing 을 통해 비슷한 아이템의 충돌을 최소화.
  • Symmetric : distance functions
  • Asymmetric : inner producte(MIPS)

문서 d와 쿼리 q 가 주어졌을 때, ^a = argmax P₩~~~~~

a,d : Barack Obam was 44th president from 2009 to 2017.

H H(a,d) -> Q1: Who was president in 2009? Q2: who was 44th president? 1:다 관계다.

즉, 문서를 통해 질문을 생성하는 것이 좋을 수도 있다(seq2seq을 통해서)

Multimodality

3. 네이버 개인화

1. 지금까지 못했던 이유

  • Privacy 측면 때문에 개인화가 힘들었다.
  • Privacy < Convenient 의 자신감이 있어야 한다.
  • Filter Bubble 로 인해 획일화된 데이터만 볼 수 있다.

검색의 목표 : 사용자의 검색 의도에 맞는 검색결과를 제공한다.

‘그렌져lg’ 를 검색했을 때 수백여개의 질의 의도를 파악해서 퍼센트로 나뉜뒤 설정해놨다. 그런데, ‘펜타곤’을 검색했을 때, 장소를 찾는지 아이돌을 찾는지 알 수가 없다. 이제 사용자의 만족을 위해선 개인화가 필요함을 인지했다.

이제는 최대 다수의 최대 만족 -> 개인의 최대 만족 지금, 이미지를 선호하는 사람은 이미지 위주로, 동영상을 선호하는 사람은 동영상을 위주로 올렸다.

Click Entropy 를 보면, 덴마크를 검색했을 때 검색 의도에 따라 엔트로피가 크고, 구글이라고 검색한 것은 엔트로피가 작아서 개인화 필요가 없다.

이것처럼, 개인화가 필요한 경우는 3-Level Query Ambiguity 로 파악한다. Query 가 디오 일 때, Entity2가 가수 디오, Entity2->Property1 은 가수 디오 사진. Propert1 -> Document1 은 가수 디오 사진.

즉, Entity Level Ambiguity 를 개인화하면 효과가 가장 크다.

  • Entity Level -> 김비서가 왜그럴까 웹툰/드라마
  • Property Level -> 전국날씨 동영상 / 사진

4. 개인의 검색의도 파악

1. 여자친구 사귀고 싶어요

질문인줄 알았는데 헐 책이 생겼다. Entity 가 생겼다. 즉, 이제는 질문 의도를 파악하기 위해 뇌를 먼저 알아보자.

1) 기억은 단기 기억 -> 집중 -> 인코딩 ->장기 기억

사람의 기억 방식을 모방해 3개의 계층으로 구성. HuMM(Human Memory Mirror) 사람의 Action -> Working memory -> Logn term memory

디오를 검색했을 때, Logn term memory 에 주식을 검색했었다. 그러면 주식회사 디오로 판정하면 되고, 만약 Immediate Memory 에서 디오가 사고를 쳤으면 디오를 보여준다. 만약 이전에 Working memory에서 삼성전자를 검색했다면, 결국 주식회사를 보여준다. 현재는 Long Term 과 Immediate memory 가 구동되고 있다. 이제 언제, 누구에게 줄 지 결정되었다.

그러나, 데이터가 너무 SPARSE 하다.

현재 Working memory 는 session-based 인데, 이 또한 숫자가 너무 적어서 힘들다.

5. 개인화 검색 확장

1. 정확도 담보하는 방향으로 확장

특정 질의에 대한 선호가 없어도 다른 Long term memory를 참조해서 결정함.

개인화 2019. 이제는 네이버 틀에 얽매일 필요가 없다. 결국, 3-level ambiguity를 정의해서 HuMM을 통해 개인의 검색의도를 파악하는 서치 엔진이 될거다.

4. NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기

어디가 가장 최적인지를 찾아가는 것.

그런데, 실제로 하는 건 라이브러리 쓰기만 하면 된다. 케라스를 import 하자. 이제 dependency hell 이 생긴다. 머신러닝이 설정하기 개빡친다.

그래서, MLaas(Machine Learning as a Service)

결국 머신러닝을 서비스 해야 한다. NSML: MLaaS

  • 환경 세팅같은 진입장벽을 없애고, 서비스할 수 있게 한다. NSML 커맨드 한 줄로 머신 러닝 모델을 학습시킬 수 있다. Containerized ML, 리눅스 컨테이너를 이용하면 빠르고 정확한 환경 세팅이 가능하다.

1) Naver AIHackathon 2018

250개 모델을 서버 다운 없이 진행했다.

NSML 만 있었더니 웹개발자들이 훌륭한 모델을 만들었다. 머신러닝 연구의 진입장벽을 없앨 수 있다. Challenge 를 통해 환경을 제공했다. 이 만들어진 모델을 사용할 때 어떻게 할 것인가??

2) 모델 서비스 파이프라인(AS-IS)

데이터 수집-> 모델 학습 -> 모델다운로드 -> 서비스용 서버 구축 -> APP 연결

모델 학습 -> 모델다운로드 -> 서비스용 서버 구축 을 NSML에서 해주겠다.

3) 무슨 모델을 서비스하지? 만 고민해라

뭐가 좋은 모델인지 모른다. 하이퍼 파라미터의 개수가 너무 많아졌다. 어떤 모델로 자동화할 것인지에 대해서 알아보자. 모델 튜닝의 방법.

결국 하이퍼 파라미터와 모델 튜닝을 쉽게 하는 프레임워크를 만들었다. Hyper Parameter Tuning의 방법은 GSD Optimization 를 쓸거다.

CHOPT Agent 가 알아서 튜닝해준다. 결국, 유저는 NSML 에이전트에게 튜닝을 맡긴다. config 파일을 최대한 간단하게 했다.

4) 튜닝의 방법은?

Fine Tuning

  • Expanding : Hyper Parameter 를 추가하면서 최적화
  • Shirinking : ‘‘를 줄여나가면서 최적화

6. NAVER 광고 deep click prediction: 모델링부터 서빙까지

1. 온라인 광고란?

1-1) Components of Online Advertising

광고주와 소비자들, Ad를 어떻게 전달할 것인가.

파는놈과 사는 놈이 있다 네이버는 뭐하냐? 많은 걸 한다.

1-5) Key mission of Ad Markert

수요와 공급, 유저의 이목을 끌고 싶다. 어떻게 매력적인 광고를 유저에게 줄 것인가

function(User, Context) -> Ad 뭐가 Attractive 한가? 클릭이 가장 좋은 지표. CTR(click through rate) = clicks / impressions

1-7) Click Prediction Problem

사용자가 어떤 상황에서 클릭하는가? 모두 모아서, click 과 unclick 으로 label 시킨다. binary classification problem으로 간단하게 전환된 것이다.

1-8) Specialty of Ad Click Prediction

근데 살짝 다르다.

  • 광고는 애초부터 조금 Annoying 하다. very low CTR
  • 많은 익명과 다양한 contexts
  • 퍼포먼스가 높으면 수입이 높아진다.
  • Utility function’s multi-dimensional.
    • 많이 샀으면 좋겠다.
    • 어우 이상한 건 사기 싫다
    • 이 중간을 조정하는 것.

2. 이제 광고를 하려면 어떻게 할까?

2-1. 배경

수천 개의 광고를 어디에 어떻게 배치 할 것인가?

2-2. Naive Approach

  1. Scalability User, context 에 대해 Classifier 를 모두 계산해서 가장 좋은 광고를 보내주면 되지 않을까? 네이버 쇼핑, 통합 검색, 모바일 앱, 텍스트, 이미지, 비디오 광고 다 계산 할거냐?

  2. Cold start 새로운 광고와 처음 보는 사람은 뭘 보여줄거냐

2-4. Others Approach

페북은 클릭 한 인풋을 feature transform 하고 classification 한다. 이걸 서빙 어케 했냐?

타불라는 수백만개에서 target repository 으로 1000개 정도로 축약 시킨다.

유투브는 candidate 를 하나 꺼내서 수백개로 drill down 이후 전달한다. 결국 모델 아키텍쳐를 전달하는 방법은 큰 틀에서 비슷하다. 얘네는 NN을 이용해 한다.

3. 모델링

3-1. Key idea

  1. Candidate model 해서 drill down 하자.
  2. Embedding
    • feature space 가 너무 넓어서, 그냥 쓸 수가 없으니 임베딩 시키자.

3-2. Model Architecture

입력 벡터를 받은 다음에 임베딩 네트워크 3개에 통과시킨다. 얘네들을 embedding 시키고 classifier 시키자.

3-3. Objective of Embedding

  1. Good classification

3-4. Learning of Preference and Similarity

Loss function : preference loss 와 similarity loss 에 대해 학습

label이 1일 때, 유저 컨텍스트와 광고가 가까워지는 방향으로 가고, 0일 때는 반대.

3-5. Candidate Model

user, context 줬을 때 가장 가까운 벡터 찾는 게 캔디데이트다.

3-8. Classifier Variations

뭐 분류 잘했다.

4. Serving

4-1. Key idea

  1. Only perform classifier prediction when online serving.
    • separates model export
    • 임베딩은 미리 계산해놓자
  2. Nearest neighbor search for candidate selection
    • 프레딕션 코스트가 가장 중요하다.
  3. Reduce prediction input size.
    • Embeding 하고 커먼 request 썼다.

4-2. Serving Architecture

임베딩 다 계산해놓고, User, context, 넣고 Ad 를 Prediction Server 에 내리고, Model Trainer 가 열심히 가리킨다.

Spring boot가 Ranker, Ad candidates embedded feature, 등등

5. Result

5.1 Embedding Space: User

나이대와 성별로 묶였다. 광고를 뿌려보면, 업종마다 분포되는 결과가 다르다.

5.6 Discussion

결국 많은 A/B test 로 합의를 보자.