DEVIEW 2018 2일차 후기


네이버 DEVIEW 2018 2일차 후기입니다 :)

입장

  • 입장해서 받은 물건들! 물과 간단한 간식, 커피 쿠폰
  • 쿠팡에서 준 컵케잌

이미지를 이해하는 이미지검색: 텍스트기반 이미지검색에 CNN 이용하기

  • 조근희님
  • 발표 자료
  • 산티아고 순례길 검색 결과 이상적인 검색 결과가 나왔음
    • 순례길 경로, 풍경 사진
  • 이미지 검색
    • 웹검색, 뉴스, 도영상과 더불어 가장 기본이 되는 검색 서비스
  • 가장 많이 쓰는 검색
    • grep
    • CTRL + F
    • SELECT 쿼리문
    • 위 검색은 Boolean Retrieval Model
      • 이진 값에 근거해 순위 구분없이 연관/비연관으로 결정
      • 높은 Recall, 색인이 필요 없음
      • but 소셜 데이터엔 엉망
  • Term Weighting Models
    • TF-IDF : 어떤 단어가 특정 문서 내에서 얼마나 중요한 것인지를 나타내는 통계적 수치
    • BM25 : TF-IDF와 문서의 길이까지 고려
    • 이 모델도 여전히 제대로된 결과를 보이진 않음
  • Relevance Feedback
    • 사용자 클릭 등 사용자의 피드백을 고려해 검색품질을 향상
    • 잘못된 데이터가 나와서 클릭 로그가 오염될 수 있음
  • 전통적인 정보검색 기법
    • Similarity + 문서의 Quality(조회수, 이웃수, 좋아요, 중복수, 해상도 등) / 사용자 피드백 / 문서 확장
    • 전통적인 방법은 여전히 한계 존재

이미지 검색을 하는 이유

  • Why People Search for Images using Web Search Engines
  • Explore/Learn 또는 Locate/Acquire 또는 Entertain를 위해 검색
  • 인물 질의가 대부분이고 사진, 배경, 캐릭터 등을 찾음
  • 연령대/성별 이미지 검색어 분석
  • 이미지 이해를 위한 내용분석이 필요
    • CNN 사용해서 내용 분석!

CNN 사용

  • 질의를 class로 labeling
    • 고양이 사진에 고양이라고 태깅
    • 학습된 건 잘 찾지만, 텍스트 match는 NLP 영역(더 어려운 문제)
  • CNN Feature를 사용해 이미지 유사도를 구함
  • n개의 대표 이미지로 m개의 후보 이미지를 Re-ranking
    • 발표 자료 공개되면 아키텍쳐 파악하기
    • 검색이 잘 안될 경우, 정답을 사람이 알려주는 시스템

CNN을 사용해 사용자 요구 분류

  • 검색 필터로 보는 사용자 요구
    • 구글, 바이두에서 사용. 아바타 사진 / 일러스트레이션 / 얼굴 / 만화 그림 / 정지 사진 등등
  • 8개의 Label을 가진 CNN 모델 사용
    • 실사, 색칠공부, 컬러만화, 스케치, 클립아트, 상품, 사람, 텍스트
    • 아키텍쳐는 정말 간단하게 사용
  • 질의, 이미지 클릭 정보를 기반으로 공통적으로 클릭한 이미지의 실제 질의를 확인
    • 클릭 로그, 검색 컬렉션을 조인
    • 예를 들어 색칠공부 label은 공주색칠공부, 포켓몬색칠공부, 햄스터그리기 등의 질의로 들어온 것을 확인 가능
  • 37가지 사용자 의도 분류 모델 생성
    • 사용자 의도를 8가지에서 37가지 Label로 확장
    • 검색어를 주제 분류하고, 자주 나오는 쿼리로 label을 추가
    • 악보, 도면, 테이블, 그래프, bj방송, 지도 등
  • 클러스터링 기법 응용
    • 1만개로 확장
    • High Level(100개), Low Level(10000개)
  • 검색 피처로 활용하기
    • Query Time에 구현
    • 1) Rule-based : 특정 질의의 패턴 파악
    • 2) Topic Modeling : 주제 분류를 이용한 동적 weight 부여
    • 3) Re-ranking : Initial search의 속성 분포 벡터를 이용해 동적 weight 부여
  • 이미지 검색에서 중복
    • 이미지가 웹문서보다 큼
    • Gray Mean-Block을 사용해 중복 제거
    • 그러나 여전히 품질적 문제가 있어서 cnn feature를 포함해 PCA해서 추가 보완 작업

추가적으로 관심있는 Task

  • 텍스트를 이미지처럼 검색하기
  • 이미지를 설명하는 텍스트 찾기

TensorRT를 활용한 딥러닝 Inference 최적화

  • 한재근님
  • Inference
    • 다양한 환경에서 사용
    • 모바일 / 데이터 센터
    • 입력된 데이터에 대해 학습된 딥러닝 모델로 예측하는 행위
  • 대용량 Inference를 위해 성능과 최적화에 대한 이해 필요

대용량 Inference를 위한 이해

  • 처리 속도 외에 고려할 것들
    • 처리량(Throughput)
    • 응답 속도(Latency)
    • 고효율(Efficiency) : 메모리 사용
    • 서로 맞물려 있음
  • 고성능과 응답 속도(GPU vs CPU)
    • 응답시간 내에 얼마나 많은 요청을 처리할 수 있는가를 고민
    • GPU의 경우 16 배치까진 리니어하게 처리량이 증가
  • 처리 속도와 정확도의 Tradeoff
    • 연산량과 속도
      • 작은 모델이 속도 빠름
    • 연산량과 정확도
      • 큰 모델이 정확도가 좋음
  • Inference 최적화 방향
    • 가벼운 모델 사용
      • 연산량이 적을수록 속도가 빠름
      • MobileNet, SqeezeNet, SEP-Nets
    • 모델 압축
      • 큰 모델의 성능 획득. TensorRT의 적용 범위
      • Quantization and Binarization, Network Weight PRunning and Sharing, Knowledge Distillation, Low-Rank Factorization and Sparsity

TensorRT를 이용한 Inference 최적화

  • TensorRT 기본 디자인
    • Optimize, Runtime으로 나뉨
  • TensorRT의 일반적인 절차
  • Tensorflow 모델 적용 절차
  • TensorRT에서 제공하는 최적화 기능
  • 성능 향상
    • TensorRT를 사용하면 처리량이 증대

OpenPose TensorRT Plugin Layer 적용사례

  • Realtime pose detection
    • 실시간 Inference에 대한 수요 존재
    • TensorRT만으로 얼마나 성능 향상이 가능할까?
    • 위 궁금증으로 OpenPose 선택
  • 모델 성능 분석
    • Iteration당 실행 시간 확인
  • 지원을 하는 레이어, 못하는 레이어가 있음
    • PReLU 지원 안함
  • TensorRT에 Layer 정보 추가하기
    • 파싱한 후, 네트워크 정보 포함하기
  • Plugin Layer 개발
    • Optimization과 Runtime 2가지 과정에서 Plugin 사용
    • Layer 초기화
    • Enqueue
    • Serialization
    • Deserialization
    • Plugin Factory 구성
    • Parser 연동
  • 적용 모델 Benchmark
    • 메모리 사용량 1/3로 줄음
    • Latency 1.75배 빨라짐
    • Throughput 초당 처리할 수 있는 수 증가

기계독해 QA: 검색인가, NLP인가?

검색으로 찾는 QA

  • 종합적으로 구성
    • 내용 및 제목의 관련성 : 오늘은 이것만 다룰 예정
    • 비슷한 검색을 한 유저가 읽은 문서
    • 웹사이트의 신뢰도
    • 문서의 인기도
    • 검색자의 정보
  • Word Matching
    • 검색한 단어가 존재하는 문서를 가져옴
    • 제목에만 적용할 경우 꽤 효과적
  • TF-IDF
    • 흔하지 않은 단어에 가중치
  • BM25
    • TF-IDF의 업그레이드
  • LSA
    • Latent Semantic ANalysis
    • Dense vector via SVD
    • 단어에 추상적 태그를 달아줌 => 단어끼리 비교 가능
  • 검색의 한계
    • 단어 수준의 정보 습득은 가능하나 문법적 또는 의미적(semantic) 맥락은 파악 못함
    • 문서나 문단 수준 이상으로 답 가져오기 힘듬

NLP로 읽는 QA

  • 기계학습을 적용하기 위해 인풋, 아웃풋 정의
    • 인풋 : 질문
    • 아웃풋 : 답변
    • 생성 or 추출 모델
    • Generative Model은 서비스 퀄리티가 안나오고 평가도 어려움(BLEU가 있긴 하지만..)
      • 데이터 퀄리티 컨트롤이 어려움
    • 결국 Extractive
  • Neural Extractive QA Trend
    • 자세한 내용은 데뷰 자료에서 참고하면 될 듯

검색과 NLP의 접점

  • 검색 엔진이 잘못된 답을 내리면?
    • 전단계의 에러 때문에 다음 단계에도 문제
  • 위키피디아 560만개의 글
    • 탐색할 때 시간이 많이 소요
  • Locality-Sensitive Hasing(LSH)을 통해 충돌 피함
    • Symmetric과 Asymmetric
    • 문서 탐색은 이제 빨라짐
  • 우리는 문서를 원한 것이 아님. 구문으로 변환하면?
    • Phrase를 벡터로 모델링
    • 비슷한 벡터 스페이스에 맵핑
    • 수식으로 볼 경우, Decomposition이 어려움
  • PIQA를 1년간 삽질하셨음
    • 자세한건 발표 자료 참고
  • Dense + Sparse
    • vocab 사이즈를 크게 해서 concat하니 잘 됨

AI Serving Platform하루 수 억건의 인퍼런스를 처리하기 위한 고군분투기

  • 현동석님 양은숙님
  • 발표 자료
  • AiSP
  • 커스텀 서버 만들기
    • 학습하던 코드에 서버 코드를 추가해 서빙하는 방식
    • 장점
      • 있던 코드에 서버 코드를 추가
      • 데이터 전후처리도 기존 코드 사용
      • 인퍼런스 병목일 경우 서버 성능이 덜 중요
    • 단점
      • 비즈니스 로직과 인퍼런스가 커플링
      • 물리 자원이 인퍼런스 성능에 최적화되지 않음
      • 분업이 어려움
      • 서버 자원과 인퍼런스 개별 스케일링 불가
      • 웹서버의 기능을 직접 만들어야 함(톰캣, 아파치)
  • 서빙용 서버 쓰기
    • Tensorflow Serving
    • ZenDesk AnswerBot
    • 데이터 처리나 비즈니스 로직도 분리해 개발, 배포 가능
    • DL Researcher, DL engineer로 분업 가능
    • 인퍼런스만 떼어서 CPU, GPU 옵션 제공
    • 단, 오직 TF만 사용해야 함

서빙 시스템 설계하기

  • 분산 저장용에 개발용 배포용으로 나눠서 저장
  • LOGISS로 A/B Test

AiSP 만들기

  • Docker 환경 지원

프론트엔드 만들기

  • 클래스화 시켜서 저장
  • 삽질1 : httpd + wsgi + django
    • 리서쳐가 파이썬으로 파일 제공
    • 그러나 이 방법은 요청 받을 때마다 죽음
    • gRPC로 넘길 때 stub가 리소스 해제 시점 문제로 프로세스 멈춤
    • 해결했다고 나오지만 사실상 안됨
  • c++ 아파치 모듈로 구현
    • r.18만 적용
    • httpd module로 구현
  • 삽질2 : 응답 데이터 접근하기
    • inception data 접근하는 방법이 나오지 않아서 아래로 해결
        auth lenth = tensor.dim_size(1);
        auto data = reinterpret_cat<cost float*>(tensor.tesnor_data().data());
        // 이제 data[i]로 접근
      
  • 삽질3 : ArgMax
    • 프론트엔드 서버에서 ArgMAx를 사용 불가(computation에서 진행)
    • 그냥 만듬

딥러닝 모델 배포 플로우

  • tf.saved_model.builder.SavedModelBuilder(dir) 사용
  • SignatureDef
    • 딥러닝 모델의 입출력을 정의하는 부분
    • DL 리서쳐가 정의해야 함(어디가 인풋이고 아웃풋인지 서빙에게 알려줘야 함)
    • 하이퍼 파라미터 튜닝시 인풋으로 고려해야 함

컨테이너로 스케일 아웃

모델 관리 및 데이터 관리

  • 사용된 데이터가 오래되면 다시 학습해야 함
  • 주기적 업데이트 필수
  • 검증하는 코드를 만들고 배포 전에 비교용으로 돌려보는 것 추천

인퍼런스 성능 측정하기

  • 응답 시간이 균일하고, 배치 옵션으로 성능 향상
  • 모니터링도 쉽게 가능
    • CPU는 임계치를 정하고 모니터링
    • GPU는 벤더의 진단도구(nvidia-smi) 활용

Papago Internals: 모델분석과 응용기술 개발

  • 발표 자료
  • 모델 연구/개발
  • 응용 기술 연구/개발
  • 앱/웹 서비스 개발
  • 서버 개발

집중하는 것

  • 품질
    • 모델링, 전처리, 데이터 분석, 사용성 분석, CS 처리
  • 편의성
    • 웹 문서 번역, 오프라인 번역, 분석 도구 개발, 언어 감지기, 문장 분리기
  • 최적화
    • 품질 안정성 최적화, 속도 최적화, 서비스 최적화

학습과 수렴

  • 권우님 발표
  • 파파고 기계번역 모델
  • Transformer : Encoder, Decoder
    • 학습이 매우 어렵고 불안정
    • 따라서 학습과 수렴 개선을 위해 파파고에서 연구
  • 연구 목표
    • 품질 안정성 : 신뢰할 수 있는 학습 사이클 구축
  • 연구
    • 일반화된 모델 수렴 지점 선택 방법이 없음
      • 다양한 학습 방법론을 실험
      • 매 iteration마다 BLEU 점수의 추이 확인
    • 각 언어별로도 BLEU 점수 추이 확인
    • 그러나 BLEU 개선이 품질 개선을 보장하지 않음
    • 전문가를 따로 섭외해 평가 추이를 함께 봄(그러나 상관관계가 낮음)
  • 주요 연구 주제
    • 서비스 품질 개선
    • 서비스 속도 개선

인공신경망을 활용한 웹사이트 번역

  • 목표
    • 신경망 기반 번역을 통해 번역 품질 확보 후, 번역문의 적당한 위치에 원문의 태그를 삽입!
  • Attention
    • 적당한 위치를 찾기 위해 사용
  • 기계 번역기가 번역 잘못하면 태그 복원 성능도 하락
  • 실질적인 어려움
    • 지저분한 웹 상의 문서
      • 공백 종류가 20가지
      • 같은 모양인데 표현 방식이 다른 경우
      • 웹 표준을 지키지 않는 경우
    • 번역할 부분만 뽑아내기
      • 번역할 태그와 하지 않을 태그(스크립트) 구분
      • inline 태그만 고려하기
    • 적절한 위치에 삽입
      • 어텐션 매트릭스를 사용해 입력 토큰에 대한 출력 토큰 위치 찾음
      • 한국어는 POS tagger로 조사 처리
    • 빠르게 처리하기
      • Fronted : 번역할 사이트 작게 쪼갬
      • Website Translator : 번역할 텍스트와 태그 추출 / 문장 분리 및 태그 위치 기록
      • GPU Cluster : 분산 요청을 받아서 response
      • Website Translator : 번역문 태그 복원 및 트리 재구성
      • Fronted : 렌더링
  • 앞으로 연구 방향
    • 기계 번역기 자체 성능 높이기
      • 원문의 coverage를 높여 생략 줄이기
      • 외부 지식을 활용해 고유 명사 번역
      • 이전 문장을 고려해 다중 문장 번역
    • Alignment와 태그 복원 품질 높이기
      • phrase table을 활용한 supervised attention
      • 입력 토큰 태그와 관련된 출력 토큰을 선택하는 휴리스틱의 다양화
      • 캐릭터 레벨 기계 번역 모델의 어텐션 활용?

  • 발표 자료
  • 온라인 광고의 Key Mission
    • User의 어텐션을 얻고 싶음
    • 유저에게 매력적인 광고를 전달
  • 얼마나 광고를 많이 클릭할까?
    • CTR
    • 광고를 봤을 땐 impressions
    • 클릭한다 안한다의 binary classification 문제로 변환

Project Mission

  • 뿜, 네이버 뉴스 하단에 광고가 있음
  • 아래 문제에 대한 고민
    • Scalability
      • 광고는 계속 늘어나는데?
    • Cold start problem
      • 새로운 지면이 나올 경우엔?

Case Study

  • Facebook Ad
    • Feature transform한 후, classification
    • Serving 이야기 없음
  • Taboola
    • Target repository에서 천개 정도의 아이템을 따로 뽑은 후(Candidate) 추천
  • YouTube
    • candidate generation
  • Google Play
    • 얘네도 embedding 후 classification

Modeling

  • Key Idea
    • Candidate model
    • Embedding
  • Embedding
    • 그럴법한 광고 덩어리를 뽑아오면 됨
    • user, context 임베딩 벡터와 ad 임베팅 벡터를 비교
  • Feature Preprocessing

Serving

  • Key Idea
    • Online serving 시점엔 분류 예측만 진행
      • Embedding은 제외
    • Candidate selection을 위해 최근접 이웃을 찾음
    • Prediction input size를 감소
  • Architecture
    • Clipper
      • Prediction Server
      • CPU, Memory 이슈
    • TensorFlow Serving 사용
  • NN Search
    • Spotify에서 작성한 ANNOY 구현
      • multiple distance metrics 지원
      • 작은 memory 사용
      • 다양한 프로세스간 memory 공유

전체 후기

  • 전반적으로 재미있고 즐거웠던 행사!
  • 이런 행사를 오면 꼭 공부해야겠단 생각을 엄청 가지고 집으로!!!!!

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)




© 2017. by Seongyun Byeon

Powered by zzsza