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 사용
- NN Search
- Spotify에서 작성한 ANNOY 구현
- multiple distance metrics 지원
- 작은 memory 사용
- 다양한 프로세스간 memory 공유
- Spotify에서 작성한 ANNOY 구현
전체 후기
- 전반적으로 재미있고 즐거웠던 행사!
- 이런 행사를 오면 꼭 공부해야겠단 생각을 엄청 가지고 집으로!!!!!
카일스쿨 유튜브 채널을 만들었습니다. 데이터 분석, 커리어에 대한 내용을 공유드릴 예정입니다.
PM을 위한 데이터 리터러시 강의를 만들었습니다. 문제 정의, 지표, 실험 설계, 문화 만들기, 로그 설계, 회고 등을 담은 강의입니다
이 글이 도움이 되셨거나 의견이 있으시면 댓글 남겨주셔요.