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인가?
- 서민준님
- Question Answering
- 발표 자료
검색으로 찾는 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]로 접근
- inception data 접근하는 방법이 나오지 않아서 아래로 해결
- 삽질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
- 입력 토큰 태그와 관련된 출력 토큰을 선택하는 휴리스틱의 다양화
- 캐릭터 레벨 기계 번역 모델의 어텐션 활용?
- 기계 번역기 자체 성능 높이기
NAVER 광고 deep click prediction: 모델링부터 서빙까지
- 발표 자료
- 온라인 광고의 Key Mission
- User의 어텐션을 얻고 싶음
- 유저에게 매력적인 광고를 전달
- 얼마나 광고를 많이 클릭할까?
- CTR
- 광고를 봤을 땐 impressions
- 클릭한다 안한다의 binary classification 문제로 변환
Project Mission
- 뿜, 네이버 뉴스 하단에 광고가 있음
- 아래 문제에 대한 고민
- Scalability
- 광고는 계속 늘어나는데?
- Cold start problem
- 새로운 지면이 나올 경우엔?
- Scalability
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를 감소
- Online serving 시점엔 분류 예측만 진행
- Architecture
- Clipper
- Prediction Server
- CPU, Memory 이슈
- TensorFlow Serving 사용
- Clipper
- NN Search
- Spotify에서 작성한 ANNOY 구현
- multiple distance metrics 지원
- 작은 memory 사용
- 다양한 프로세스간 memory 공유
- Spotify에서 작성한 ANNOY 구현
전체 후기
- 전반적으로 재미있고 즐거웠던 행사!
- 이런 행사를 오면 꼭 공부해야겠단 생각을 엄청 가지고 집으로!!!!!
카일스쿨 유튜브 채널을 만들었습니다. 데이터 사이언스, 성장, 리더십, BigQuery 등을 이야기할 예정이니, 관심 있으시면 구독 부탁드립니다 :)
PM을 위한 데이터 리터러시 강의를 만들었습니다. 문제 정의, 지표, 실험 설계, 문화 만들기, 로그 설계, 회고 등을 담은 강의입니다
이 글이 도움이 되셨거나 다양한 의견이 있다면 댓글 부탁드립니다 :)