DEVIEW 2018

DEVIEW 2018

작년에도 deview를 가고싶어 신청했지만 결과는 이틀 모두 실패했고 이번에는 꼭 듣겠다고 다짐했다. 신청 5분전에 수강신청을 하는 마음으로 컴퓨터 앞에 앉아 대기했다. 네이버 기술에 대한 궁금증이 많아 day 1, day 2 모두 신청을 하려고 했지만 day 1을 실패하고 day 2만 신청이 확정됐다.

사실 day2 보다는 day1에 가고 싶었는데 그 이유는 day2의 내용이 너무 어려웠기 때문이다. day1이 쉽다기보단 day1 중에서도 그나마 내가 알고있는 HTML Canvas나 웹 성능 최적화 부분 관련해서 들을 생각이었다. day2는 머신러닝이나 빅데이터에서도 세부적이면서 그 플랫폼 자체를 다루기 때문에 이미 머신러닝, 빅데이터와 관련된 직장을 다니고 있는 사람에게 좋을 것 같았다. 그러나 어렵게 신청이 된 deview 2018 자체를 포기하고 싶진 않았다. 가기로 마음을 먹었다.

아예 단어조차 모른 채로 가는 건 안 가는 것보다 못하기 때문에 대충 어떤 의미인지라도 알고 가는 게 낫다고 생각해서 몇 가지 단어를 찾아봤다.

클러스터링 - 패턴 공간에 주어진 유한 개의 패턴들이 모여서 무리를 이루고 있는 패턴 집합을 ‘클러스터’라 하고 이런 무리지어나가는 처리 과정을 클러스터링이라고 한다. 데이터 클러스터링에서는 하나의 데이터를 여러 개의 부분집합(clusters)으로 분할하는 것이며 각 부분집합에 있는 데이터는 몇 가지 공통된 특징을 공유하는데 그것은 몇 가지 거리 측정법을 사용하여 유사도를 계산하여 이루어진다.
파라미터 튜닝 - 보통 ML 알고리즘은 데이터를 보고 배워야하는 파라미터를 가지고 있다. 그 파라미터는 SVM의 지원 벡터, 결정 노드, 가중치다. 이 알고리즘은 사람이 짜야하는데 이런 하이퍼 파라미터는 모델의 성능에 크게 영향을 미치므로 올바른 값을 찾는 것이 중요하다. 이렇게 올바른 하이퍼 파라미터를 찾는 걸 파라미터 튜닝이라고 한다.
AutoML - 인공지능으로 또 다른 인공지능을 맏드는 기술. 인공지능에게 몇 가지 핵심 키워드만 주어진다면 스스로 프로그램을 설계할 수 있는 수준까지 진화했다
MapReduce - 대용량 데이터 처리를 분산 병렬 컴퓨팅에서 처리하기 위한 목적으로 제작된 소프트웨어 프레임워크. 페타바이트 이상의 대용량 데이터를 신뢰도가 낮은 컴퓨터로 구성된 클러스터 환경에서 병렬 처리를 지원하기위해서 개발되었다.
HBase - 하둡 플랫폼을 위한 공개 비관계형 분산 데이터베이스. 압축, 인메모리 처리, 빅 테이블에 제시되어 있는 bloom 필터 기능. 하둡에서 동작하는 맵 리듀스 작업을 위한 입출력을 제공한다
YARN - 자바스크립트의 새로운 패키지 매니저. npm의 대체자. 보다 빠르고 안정적이며 보안성이 뛰어나다.
Apache Slider - 기존 분산 응용 프로그램을 YARN 클러스터에 배포하고 응용 프로그램이 실행되는 동안에도 모니터링하고 크기를 줄이고 늘릴 수 있다.
…

찾아보다가 이건 아니라고 생각했다. 모르는 단어를 찾으면 그 모르는 단어 안에 모르는 단어가 한 5개는 더 있었다. 모르는 단어가 많아도 너무 많았다. 그냥 최대한 쉬운 TRACK을 듣는 것이 최선이었다. 결국 최대한 한국어로 되어있으면서 그나마 쉬워보이는? 것으로 선택했다. (하지만 절대 쉽지 않았다)

용어를 몰라 아예 이해가 안 가는 부분도 있었지만 PPT 덕분에 이해가 가는 부분도 조금 있었다. deview 2018의 각 트랙을 들으면서 최대한 이해하고 적으려고 했지만 쉽지 않았다. (개인적으로 이해한 부분과 흐름을 알 수있는 부분을 적었기에 행사의 내용과 틀린 부분이 있을 수 있습니다.)

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

네이버에서 이미지 검색을 할 때 어떤 이미지가 먼저 나오도록 어떻게 우선순위를 정할까?

Boolean Retrieval Model.
- 이진 값에 근거해서 연관과 비연관으로 구분
Term Weighting Models(Boolean 보다 나은 모델)
- TF-IDF : 어떤 단어가 특정 문서 내에서 얼마나 중요한 것인지를 나타내는 통계적 수치.
- BM 25 : TF및 IDF 뿐만 아니라 문서의 길이까지 고려한다.
- 하지만 여전히 피아노악보를 쳤을 때 다른 이미지가 나오는 걸 알 수 있다.
Relevance Feedback
- 사용자 클릭등 사용자의 피드백을 고려하여 검색 품질을 향상하는 방법
- 그러나 수지 사진이 있다면 보통은(?) 클릭하기 때문에 검색 품질이 오염될 수 있다.

지금까지가 전통적인 정보검색 기법이다. 전통적인 정보검색 기법이란 위에서 말한 다양한 검색 모델의 조합(Boolean Retrieval Model, TF-IDF, BM25)과 사용자의 피드백 및 질의 확장/문서 확장이다. 그러나 이는 한계가 있다. 이미지 이해를 위한 내용 분석이 필요하다

이미지 분석의 필요성

예를 들어, ‘우도 배시간표’를 검색했을 때 ‘우도 배시간표’가 안 나오고 우도 사진이 처음에 들어가 있다. 그 이유는 그 우도 사진을 클릭했을 때 ‘우도 배시간표’ 라는 텍스트가 들어있는 문서에서 찾았기 때문이다. 그래서 이와 같은 걸 분석하기 위해 CNN을 이용했다고 하셨다.

이미지 검색을 위한 CNN

Supervised Leaning 기반 Classification 기술을 응용
Classification을 이용한 이미지 태깅
- 데이터가 충분히 많아야 하는데 이것을 학습시키고 평가하는 것을 반복한다.
- 서비스 배포를 하고 질의가 추가되면 다시 데이터를 준비한다.
그러나 이것은 모델이 바뀌면 80억개의 inference가 필요하다. 즉, 불가능

CNN feature 활용하기

이미지 유사도
- CNN Feature에 대표 이미지와 후보 이미지들을 넣는다.
- n개의 대표 이미지로 m개의 후보 이미지를 Re-ranking한다

CNN을 이용한 사용자 요구 분류

검색 필터는 정확한 검색 결과를 찾기 위해 사용자의 검색 요구를 분류한다.
주요 검색 필터 8종을 선정하여 8개의 label을 가진 CNN 모델 학습시킨다.
사용자 의도를 세분화 하기 위해 검색 질의를 또한 세분화하여 이미지 유형을 37가지로 분류한다.

클러스터링 기법의 응용과 검색 피처로 활용은 이해를 못 했다.

Visual-text Semantic Embedding - 사진 위 아래에 텍스트가 있다면 어느 것이 더 관련이 있나?

PPT - https://www.slideshare.net/deview/221-cnn-119084683

누구나 만드는 내 목소리 합성기(부제 : 그게 정말 되나요?)

음성합성

인공적으로 사람의 음성을 만드는 것
TTS(Text To Speech)

하지만 쉽지가 않다. 텍스트에 존재하지 않는 발음, 속도, 호흡, 운율 등의 정보를 추정하여 녹음된 화자와 가장 비슷한, 자연스러운 음성을 생성해야되기 때문.

네이버 음성 합성기인 nVoice는 어떻게 음성을 합성했을까

화자 선정
1. 짧은 문장, 긴 문장을 다 듣는다.
2. 최종적으로 선정할 때 호감가는 목소리, 정확한 발음, 일관된 목소리를 기준으로 삼는다.
발성 스크립트 선정
1. 서비스 도메인에 따라 내용과 분량 선정
2. 읽기 쉬운 스크립트
3. 모호한 발음은 미리 알려준다
4. 보강 어휘
녹음
1. 숨소리(습 같은…)
2. 노이즈 제거(심지어 전원 노이즈도 있음)
3. 좋은 녹음실과 훌륭한 사운드 엔지니어
전사
1. 음소 전사
2. 음소별로 음성 분할(200분의 1초)
3. 장르(친구와 대화하듯이 읽었는지? 등)
4. 감성(슬프게 읽었는지? 등)
언어처리 모듈 구현(모름…)
1. Preprocess
2. Sentence split
3. 예를 들어 두음법칙할 때 어떻게 발음해야 되는가 등..
4. … 등등등
운율 모델링(개인의 특성을 가장 잘 나타내는 요소)
1. pitch - 톤이 높다, 낮다.
2. energy - 강세
3. Duration - 길게 읽을 것인가, 짧게 읽을 것인가
음소 접합
1. 가장 자연스러운 합성 단위 찾기
2. 각 음소별로 꼭 붙어야 하는 것 vs 떨어져도 상관 없는것을 구분한다
3. 연결성 vs 추정값 등..

개인화 음성 합성

짧은 시간 쉽게 녹음하여 개인의 특성을 살리는 자연스러운 음성 합성이 필요하다.
이런 서비스가 왜 없을까?
- 화자를 한 사람으로 정하고 위에 말했던 작업을 하더라도 엄청난 돈이 필요하다.
- 녹음 시간만 거의 90시간 정도가 필요하다.
일반인 개인 화자가 가능할까?
- 그 사람이 일정한 톤을 유지할 수 있나?
- 그 사람이 깨끗한 발성인가?
- 기존의 녹음 또한 극한의 녹음 환경을 가지고 있나?
- 개인의 전사 작업 또한 품질이 안 좋을 것이다.
- 구현 또한 그렇다. 제작 시간또한 년 단위이다.
- 결론 : 현재의 방법으로는 어렵다.

그렇다면 어떻게 해야하나? -> NES(Natural End-to-End Speech Synthesis System)

합성방식을 모든 음소 조합에 대한 샘플이 필요한 Concatation에서 음성을 분석하여 파라미터로부터 음성을 생성하는 Statisical Parametric으로 바꿈. (이해가 안 가기 시작…)
Statiscal Parameteric
- Voice와 Unvoice -> Parameter 성대가 울리는지 안 울리는지 구분
- FO, LSF, BAP 등…
End to End
- 추가적인 정보 없이 waveform과 text 만으로 음성 합성
- attention 기반의 seq2seq 네트워크
Vocoder
- 품질은 WaveNet이 가장 좋지만 합성 속도나 학습 속도가 Vocoder가 가장 낫다.
- 잘못 추정된 파라미터에 의한 품질 저하가 크기 때문에 저하를 줄이기 위해 전 구간 F0값을 사용한다.
- 짧은 구간을 통합하여 개선한다.
Speaker Adaptation
- 대량의 추가적인 음성 데이터와 개인의 적은 음성 데이터를 사용하여 모델 구현

NES base Model이 upper bound라고 최적으로 잘 낼수 있는 상태다. (사람 목소리와 정말 비슷하다.)

PPT - https://www.slideshare.net/deview/222-119159969

Fashion Visual Search

소비자가 궁금해하는 상품을 사진 찍었을 때 어떻게 찾을까?

문제

카테고리 혼동
배경색에 따라 상품 검색이 달라질 수 있다.
형태가 너무 강해서 형태만 맞고 색이 다르게 나올 수도 있다.
실제로 사용자의 쿼리는 너무나도 다양하고 환경도 달라 그 자체로 찾기가 쉽지 않다.

전략

DB 이미지 개수 줄여서 인덱싱하는 시간을 줄이기.
문제를 나눠서 해결하기.
1. 의류 -> 상의, 하의 -> 원피스, 티셔츠, 바지
2. 디텍터를 통해 카테고리 혼동 해결(브랜드 탐지, shape Color Pattern 또한 구분, 그 외에도 성별, 면적도 구별)
변화에 유연한 검색 시스템(다시 모르는 것이 튀어나옴.)

다른 검색 방법은 없을까?

속성을 더하여 검색하기
Feature Vector 조작은 어렵다. 다른 속성이 안 보일 수 있다.
서로 다른 속성을 공유하는 Fake feature Vector

나머진 영어…

PPT - https://www.slideshare.net/deview/213fashionvisualsearch-reduced

네이버 검색과 개인화

검색이 이루고자 하는 목적은 검색 의도에 맞는 검색결과를 제공한다는 것

최대 다수의 최대 만족

그랜저ig를 검색했을 때 사용자의 질의는 자동차 외관 33%, 자동차 연비 5% 등등…
하지만 문제는 모두에게 동일한 결과를 주고 있다.

검색 의도에는 다양한 검색의도가 있다.

최대 다수의 최대 만족 -> 개인의 최대 만족으로 바꾸자.

펜타곤을 입력했을 때 누군가는 미국 국방부를 생각하지만 누군가는 아이돌 펜타곤을 생각한다.
또 누군가는 이미지를 많이 보는 성격이니 이미지가 바로 나오도록 맞춤형으로 제공하자.

개인화는 10년간 많은 연구가 있었다.

클릭 엔트로피

‘덴마크’를 검색했을 때 클릭의 Precision이 일상 40%, 여행 30%, 일상 10% 정도가 나온다.
‘구글’을 검색한다면 그냥 구글사이트로 가는게 거의 90%이상이다.
하지만 이건 전체적으로 Precision 80%를 넘지 못한다.

개인화가 필요한 경우 3 Level Query Ambiguity를 적용한다.

쿼리가 있다면 Entity -> Property -> Document로 들어간다.

Entity Level이면 ‘김비서가왜그럴까’를 검색했을 때 웹툰 OR 드라마 중 어느 걸 먼저 보여줄 지.
Property Level이면 ‘전국날씨’를 검색했을 때 날씨 아래에 누군가는 뉴스 누군가는 동영상탭 먼저.
Document Level는 ‘정해인 사진’을 검색했을 때 사용자의 의도대로 정해인이 미소짓는 사진이 나오도록… 하지만 이것은 Precision이 70% 이하가 나온다.

결국 검색 의도는 사용자의 마음속에 있다

아무런 힌트없이 얘길한다면 알아차리기 힘들다. 어떤 사용자가 ‘여자친구 사귀고 싶어요’ 라는 글을 적는다면 네이버 입장에서는 그게 진짜 고민이라고 생각하겠지만 실제로 그 이름의 책이 나왔다면? 그 사용자의 의도는 책을 검색하려고 검색할 확률이 높다.

이처럼 사용자의 검색 의도를 파악하기 위해 사람의 기억 방식을 모방하여 검색 로직을 3개의 계층으로 구성한다.(HuMM)

User action -> Immediate memory -> Working memory -> LongTerm memory

‘디오’를 입력 -> 근데 LongTerm Memory에 주식회사 디오라는 걸 검색한 게 있다. -> Working memory에 찾아봤는데 없음. 그렇다면 판단 보류 -> Immediate memory에 사람들이 판단할 거 같은 걸 보기 위해 실시간 검색어를 본다. 실시간 검색어에 가수 디오가 사고친 게 있다. 그러면 가수관련 페이지를 띄워준다.

결론 : 데이터가 SPARSE해서 개인의 의도 파악은 어렵다.

PPT - https://www.slideshare.net/deview/224naver-search-npersonalizationfinal

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

머신러닝을 하기 위해서는 keras나 tensorflow를 설치하는 것부터 해야할 것이 너무 많다. 설치과정에서 모두 포기하는 경우도 있다.

완전 DEPENDENCY Hell이다

NSML은 MLaas(Machine Learning as a Service)로 환경세팅 등과 같은 진입장벽을 없애고 협업하며 모델 서비스까지 쉽게 하기위해서 만들어졌다.

Containerized ML
- 리눅스 컨테이너를 이용하면 빠르고 정확한 환경 세팅이 가능하다
- 같은 환경을 컨테이너 이미지를 이용해서 저장한다.
서버 공유
- 컨테이너를 통해 비전에 상관없이 서버 공유가 가능하다.
- On demand로 관리하는 자원 할당 시스템을 통해 자원을 효율적으로 사용한다.
Engineering issue
- Scalability
- Security
- Stability

뒤 부터는 완전 이해 불가… 진짜 어려웠다.

PPT - https://www.slideshare.net/deview/225nsml-machine-learningntuningautomize

Search Reliability Engineering(부제 : 지진에도 흔들리지 않는 네이버 검색 시스템)

검색시스템의 목표

많은 사용자가 동시에 검색어를 입력해도 서비스에 문제가 없어야 한다.
네이버 검색창에 검색어를 입력하면 1초 이내에 나와야 한다.

네이버 검색 시스템에는 수백 개의 검색 서비스, 수만대의 서버 장비, 하루 수십억건의 검색 요청, 수백억 건의 컨텐츠, 수십개의 조직, 수백명의 구성원이 있다.

시스템이 거대해질수록 어려워지는 부분

문제 원인 핀포인트 추적이 어려움
문제 영향 범위 확정이 어려움
장애 복구 완료후에도 모든 구성요소가 정확히 고쳐졌는지 어려움

SRE란?

글로벌 스케일의 서비스를 제공하면서 어떻게 하면 시스템의 신뢰성을 보장할지 고민하는 기술분야이자 문화

네이버 검색 시스템에서 바라보는 SRE는?

아래와 같은 목표 달성을 위한 모든 활동

모든 검색서비스 정상동작
1년 10분 이하 다운타임
고비용 사후처리보다 저비용 사전예방

네이버 검색 시스템에서 SRE를 도입하기 전에는?

시스템 운영지표 관측에는 검색요청트래픽, 서버응답시간, CPU 사용량, 디스크 I/O등등… 너무나도 많다.

단일 Host 또는 단일 서버 대상 지표 수집 -> 특정 서비스의 전체 레이어 및 서비스 군, 전체 시스템을 볼 수 있는 방법이 없었다 -> 효율적인 정보 체계를 도입

서비스 ID 발급
구조 가시화
성능/비용 측정

정보가 모이니 다양한 응용 방법 고민 시작 -> 네이버 검색 시스템만의 가용량 지표 개발했다.

기존 방식은 MTTR + MTBF분의 MTBF으로 이게 99.998%가 나와도 1년으로 환산하면 10분이라 큰일난다.
대용량 분산 시스템 특성은 특정 서버에 문제가 생기면 다른 서버들이 영향을 받는다.
부하증가배수가 최대가용배수보다 크면 임계 상황으로 판단한다.

새로운 가용량 지표를 활용해 가용량 경보 시스템 운영했더니 실제로 위험이 감소됐다.

게다가 검색 시스템 통합 대시보드 개발해서 한눈에 보기 쉽도록 했다.

그러나 엄청난 양의 경보 발생. 필요해서 도입한 지표인데, 너무 많은 경보로 우리가 괴롭다.

거짓 경보가 있었다.

장애가 발생했으나 경보가 울리지 않는 경우
색인 업데이트, 캐시 갱신등 시간이 흐르면 정상화되는 상황… 큰일 남

거짓 경보를 줄이기 위해 많이 사용하는 방법은 휴리스틱이나 더 이상적인 방법은 아예 경보 분석을 자동화하는 것.

실제 사례

트래픽은 사람들의 생체 주기를 따라간다. 주말에는 트래픽이 적다.
또한 점심시간과 저녁시간에는 트래픽이 감소한다.

분석이 필요한 이상 지표를 anomaly 지표라고 한다.

천재지변이 있을 때 엄청난 트래픽이 발생한다.
중복된 검색어가 많이 들어온다.
중복된 검색어는 캐시 서버를 사용해 처리해준다.
월드컵은 경기중에는 트래픽이 감소한다.
경기 후에 트래픽이 증가한다.
하프타임 때도 트래픽이 증가한다. 중간에 핸드폰으로 검색하니까.
방송에서 기안84 프로필이 변경됐다고 해서 그 1분동안 트래픽이 엄청 올라갔다.

그외 흔히 겪는 다양한 이슈들

버전 변경 시 트래픽 양상이 변화, 그러면 통계치가 무효화 된다.
부하 테스트 시 실제 사용자 트래픽이 아님에도 서비스에 영향을 줄 수 있다.
지표 수집에 문제가 생겨서 거짓 정보가 올 수도 있다.

SRE의 고민

지금까지 겪어본 적 없는 문제들
언제 어디서 어떻게 발생할 지 모르는 incident
모든 경우의 수를 다 자동화하거나 시스템화 하는 것은 불가능

SRE는 시스템이 안정적으로 돌아가게 만들기 위한 모든 활동이다. 결국 사람이 하기에 새벽이나 주말, 24시간, 365일 대응할 수는 없다.

IC와 Scribe가 개별적으로 로테이션이 돌아간다. incident를 감지하면 IC와 Scribe에게 경보를 알려준다. 그러나 보통 집에 있을 때 일어나기 때문에 원격으로 하는 경우가 많다.

PPT - https://www.slideshare.net/deview/216sresearchreliabilityengineering

후기

꼭 가보고 싶었던 행사였기에 기대가 컸는데 그 기대를 저버리지 않았던 deview였다.

스케줄에 맞춰놓았던 세션들이 이해도 못할 만큼 어려울거라 생각했는데 구현 부분과 머신러닝을 제외하면 꼭 그렇지만도 않았다. 설명에 PPT까지 잘 나와있어서 발표하려는 주제가 뭔지, 뜻은 정확히 관객들에게 전달된 것 같다고 생각한다.

기대를 저버리지 않았던 이유중에 솔직히 사은품도 해당된다. deview 입구 앞에는 여러 가지 기술들을 홍보하는 부스가 많은데 각 부스마다 많은 사은품들을 준비해놓으셨다. 그리고 받을 때마다 채용에 관심있냐고 엄청 물어보셨는데 그 질문에 피한 내 자신이 아쉬웠다. 실력이 많이 없으니 섣불리 답하기도 뭐해서 피할 수 밖에 없었다. 이처럼 deview에 대한 단점, 아쉬웠던 점은 바로 내 자신이다. 인공신경망이나 빅데이터 쪽의 프레임워크도 알고 갔으면 좋으련만.

내년에도 갈 생각이다. 강연 내용을 확실히 이해하면서 들을 수 있도록 공부해야겠다.

DEVIEW 2018 정리 및 후기