Deview 2019

2019-10-28

Deview2019 참석 후 작성한 세션 요약글 입니다.

세션1: 외산 클라우드 없이 AI 플랫폼 제공하기: features, training, serving, and AI Suite. - 현동석님

모델을 연구하는 사람들이 모델 연구에만 집중할 수 있도록 다양한 ml 서비스들을 제공하기 위한 플랫폼

1. 자체 AI 플랫폼이 필요한 이유

  • security - 데이터에 대한 보관, 반출 제한 등
  • cost - 연산량이 적은 경우 클라우드 사용이 유리. 그러나 대용량 데이터 처리를 지속 수행한다면 비용이 큼
  • demand - 머신러인 수요는 기하급수적으로 증가. 초기 각자 구축하던 부분에서 공통적인 부분을 플랫폼에서 제공

2. 어떻게 만들어야 할지 생각해보기 > AI Suite

이미 구축된 플랫폼이 많았음

  • 분산저장 플랫폼
  • 분산 처리 플랫폼
  • 피쳐 엔지니어링 플랫폼 > 없음
  • 모델 학습 플랫폼
  • 모델 서빙 플랫폼

하면서 알게 된 머신러닝 모델 제품화의 세 단계

  1. 데이터 처리
    • 데이터 수배, 검토, 처리
  2. 모델 학습
    • 모델 학습, 평가, 튜닝
  3. 서빙
    • 성능 평가(응답, 처리량)과 용량 산정 후 서비스로 제공

실제로 모델을 제품화할 때 필요한 것들

모델성능을 최적화하는 것보다 인프라를 만들고 처리하는 시간이 오래걸림

  1. 데이터 처리가 오래 걸립니다.
  2. 자동화를 고려해야합니다.

3. 머신러닝 데이터 준비 자동화하기: AI Features

(네이버는 분산 저장 플랫폼에 데이터가 다 저장되어있고 카탈로그를 웹에서 볼 수 있음)

  • DUMP: 데이터를 어딘가로 가져와서 (hive QL)
  • ANALYZE: 잘못됐거나 biased 데이터는 없나 보고, 간단한 가시화를 통해 데이터에 대한 인사이트를 얻은 후 (facet, jupyter)
  • BATCH: 잘못된 데이터는 버리고, 나머지는 가공해서 피쳐벡터를 만듦 (pyspark)

데이터 스냅샷 떠놓기 > DUMP

데이터 분석하기(검증) & 가공하기

Problem

  • facet은 데이터를 클라이언트에서 처리
  • 10만건 이상의 데이터는 엄청 느려짐

Solution

  • 데이터를 가시화는 인사이트를 얻기 위함
  • 모든 데이터를 다 볼 필요는 없고, 샘플링된 데이터로만 보면 됨.

Tip1

  • jupyter notebook에서 pyspark를 실행하면 cluster mode로 돌지 않음. (client mode임)
  • 노트북에서는 샘플데이터에 대해 수행하고, batch 기능을 통해 클러스터 모드로 수행하도록 지원함.

Tip2

  • 텍스트데이터는 대부분 NLP가 필요함
  • NLP는 사전 데이터와 함께 사용함. > 분산 처리에 적합하지 않음. (수행될 노드에 사전이 설치되어 있어야함)
  • NLP API + Throttling proxy(nginx) + mapParition(for bulk request) + UDF로 해결

4. 머신러닝 모델 학습

모델 연구 때와는 다른 제품화 때의 관점

연구시

  • 가능한 자원을 모두 사용하여 빨리 학습하고 평가하는 과정을 반복
  • 최대한 동시에 실행해서 제일 성능 좋은 모델과 파라미터를 얻는 것이 목적
  • 데이터는 고정 되므로 캐싱하면 이득이 있음

제품화시

  • 학습에 걸리는 시간을 이미 알고 있음.
  • 다음 번 갱신 전까지만 학습이 완료되면 됨
  • 일정 시간 내 최소의 자원을 사용하면 좋음
  • 배포 전/후 모델의 품질을 검증할 필요가 있음 (validation 필요 - ex. hamming distance 등)
  • 매번 새로운 데이터로 학습하는 경우가 많아 데이터 개싱 이득이 없음

학습 자동화

ML code => docker image => resource 입력 후 학습

5. 머신러닝 모델 서빙하기

서빙 아키텍처 소개

서빙 = APS 서빙 + 모델 서빙

  • TFS(TFserving), CFS(Caffe servinf) 등 사용
  • PyTorch model > onnx converting > .onnx
  • TF -> SavedModelBuilder > .pb

APS 서버: 전처리 후처리 전담 서버

  • APS 서버 에서 전처리 및 후처리 작업을 한 후, serving 서버에 inference 요청을 날림.
  • APS 서버가 inference 서버의 frontend 역할을 함 (비지니스 로직, 메타 데이터 정보를 가짐)

인퍼런스 서버 띄우기

  • 사용자는 모델과 resource 만 입력

데이터 전후 처리 서버 띄우기

  • git 저장소의 코드 -> CI/CD
  • json -> gRPC로 매핑해서 날려줌

6. 모든 단계를 자동화하기

각 단계를 API로 만들기

드래그 앤 드롭으로 파이프라인 작업 코드 자동 생성하기

  • MNIST 데모 시연함

알아서 자동으로 배포하게 만들기

최종 데모

세션2: 신호처리 이론으로 실용적인 스타일 변환 모델 만들기 (Better Faster Stronger Transfer) - 유재준님

1. 스타일 트랜스퍼란?

이미지에서 스타일은 뭘까? 컨텐츠는 뭘까? 그리고 어떻게 옮기지?

Artistic style transfer vs. Photo-realistic style transfer

  • Artistic style transfer: 이미지를 예술적으로 변환하는 문제 (ex. Gatys et al. CVPR 16)

  • Photo-realistic style transfer: 이미지를 사실적으로 변환하는 문제 (ex. 낮에서 저녁으로 등)

Style transfer 왜 중요한데?

Style transfer: Generative model

  • Unsupervised Learning
  • Representation Learning
  • Feature extraction

질감 생성: 옛날에는 어떻게 했을까?

  • 어떤 선형 필터들의 조합으로 표현
  • 질감마다 필터 정의가 필요했음

최초로 CNNs을 사용한 연구 - Neural Style Algorithm

  • Gatys et al., NIPS 2015
  • Gatys et al., CVPR 2016

2. 스타일 트랜스퍼, 왜 되는걸까?

How it works?

  • Minimizing Maximum Mean Discrepancy (MMD) (Li et al., IJCAI 2017)
  • 두게의 분포 사이의 거리를 최소화하는 것과 같음을 밝혀냄

Why VGG만 잘되나?

  • 아직 밝혀지지 않음.
  • CNNs 가 texture에 편향되어 있음을 밝혀낸 논문이 있음 (Gerihos et al., ICLR 2019)
  • CNN이 사실 구조를 보는 것이 아니라 texture를 봄. 사람은 구조를 보고 판단.
  • VGG가 특히 texture에 민감

3. 스타일 트랜스퍼: 최신 연구 흐름 한 눈에 살펴보기

Artistic Style Transfer: recent trends, why & how?

  • 하나의 스타일마다 네트워크 하나씩 학습하는 것이 필요. 실용적이지 않음
  • Instance Normalization: 스타일 변환 결과가 컨텐츠 이미지의 Contrast에 따라 바뀌지 않게 하자
  • Conditional Instance Normalization (CIN): 하나의 모델이 하나의 스타일만 변환하던 문제해결을 시도
  • Adaptive Instance Normalization (AdaIN): Scaling과 Shifting 값을 구하는 과정을 학습과 분리함. (고양이, 사자를 따로 encoding 후 사자 스타일을 고양이에 입힘)
  • Whitening and Coloring Transforms (WCT): AdaIn에서 평균과 분산만 맞추던 것을 공분산까지 맞춤

Photorealistic Style Transfer: recent trends, why & how?

  • Deep Photo Style Transfer: 스타일 변환 전후 픽셀 간의 관계를 맞춰줌. gram matrix를 영역별로 나눠서 최적화.
  • PhotoWCT: decoding 할때 어디서 max pooling이 일어낫는지 알려줌 > 후처리에서 다 보정됨.

WCT via Wavelet Corrected Transforms (WCT2): 후처리 없이 기존 모델보다 성능이 좋은 모델을 개발.

  • Pooling과 비슷한 역할을 하면서 Encode-decode 과정에서 정보를 잃지 않아야하고, 입력이미지의 특징을 잘 표현할수 있는 모듈 -> Wavelet 변환 활용함. (신호 처리 이론)
  • Multi-level 대신 한번의 feed-forward만 수행
  • 비디오 스타일 변환도 잘 됨.

세션3: 문자인식(OCR), 얼마나 정확하지? (문자인식 성능을 정확하게 측정하는 방법) - 최찬규님

1. 성능평가의 중요성

성능 평가의 중요성

  • 성능을 개선하기 위해 (문제점을 정확하게 파악)
  • 모델 선택 (많은 모델 중 어떤 모델을 서비스 할 것인가?)
  • 다른 연구 그룹과의 성능 비교 (ImageNet, Kaggle)

어떻게 하나?

  • 눈으로 (사람이 직접 평가): 시간과 비용이 많이 들고, 평가에 오류가 있을 수 있음
  • 컴퓨터 (자동 평가 시스템): 시간과 비용이 거의 들지 않으며, 평가에 오류가 없음

2. 문자인식 개론

문자인식: 오프라인의 글자를 기계가 읽을 수 있도록 디지털화 한것

응용분야

  • 자동차 번호판, 명함, 신용카드, 신분증 인식, 이미지 번역 등

문자인식 과정

  • 문자검출: text detection
  • 문자 인식: text recognition

3. 기존의 성능 측정 방법

Precision & Recall

ex) 암진단 - TP, FN, FP, TN

Precision: 예측한 True 중에서 True를 올바르게 예측한 비율 Recall: 실제 True 중에서 True를 올바르게 예측한 비율

검출기/인식기/End-to-End 성능 측정방법

문자검출

  • IoU (Intersection over Union): 정답(Ground Truth)와 예측 박스의 영역이 얼마나 겹치는지 확인 (50%이상이면 hit)

문자인식

  • WEM(Word based Exactly Matching): 정답과 예측 단어가 정확히 일치하는지 체크 (단어기반)
  • 1-NED(Normalized Edit Distance): 두 단어간 편집거리(삽입, 교환, 삭제)를 측정한 뒤, 긴 단어의 길이로 정규화 (글자기반)

End-to-End (검출+인식) 평가

  • 순차(Cascade) 평가 처리: 검출 평가(IoU) -> 인식 평가(WEM, 1-NED)

4. 기존 방법의 문제점 (사례와 그 빈도)

  • 정교한 성능 측정 불가 (IoU에서 겹치는 영역이 50%가 넘지만 필요한 글자를 인식하지 못한 경우)
  • One-to-Many, Many-to-One 문제
    • One-to-Many: 하나의 정답 박스가 여러개의 박스로 나뉘어 예측되는 경우 (split) e.g) Riverside -> River, side
    • Many-to-One: 여러개의 정답 박스가 한개의 박스로 합쳐져 예측되는 경우 (Merge)
  • end-to-end에서 잘못된 오류가 전파됨.

5. 신규 제안 방법 : PopEval

설계시 고려한 점

  • End-to-End 평가
  • One-to-Many, Many-to-One 문제 해결
  • 정교하게 세부적으로 성능 측정 가능
  • 기존 평가셋과 호환되어야 함

신규 방법

  • 겹치는 영역의 글자 중에서, 같은 글자(=맞춘 글자)를 하나씩 지움
  • Recall: 맞춘 글자수 / 정답 글자수
  • Precision: 맞축 글자수 / 예측한 글자수

엣지 케이스

  • 제거해야할 글자가 중복될 경우 어떤 글자부터 제거할 것인가? e.g. N”A”VER, P”A”PAGO
  • 중복이 없는 박스 우선 제거, 교집합이 클수록 우선

6. 신규 성능 평가 방법의 검증 실험

  • One-to-Many, Many-to-One 문제는 얼마나 발생하나? 전체 2~9%. 리더보드 TOP10 순위에 영향을 줌
  • 기존 평가셋(=단어 단위)과 호환 가능한가? 호환 가능
  • 신규 평가 방법은 믿을만 한가? (평가자를 모집해서 기존/신규 평가 방법에 대한 평가)

실험 환경

  • OCR 평가셋 - IC13, IC15 평가셋 사용
  • 예측 모델:
    • 검출기: EAST, PixelLink
    • 인식기: GRCNN, ASTER

세션4: 레이블링 조금 잘못돼도 괜찮아요: Clova가 레이블 노이즈 잡는 법 - 강재욱님

데이터 전략에 대한 노하우가 실제 경쟁력이라고 생각함.

1. 레이블 노이즈가 무엇인가?

레이블 노이즈: 같은 범주의 데이터를 잘못 설명하는 의도되지 않은 Mislabel

왜 문제인가?

  • 레이블 노이즈는 모델의 feature extraction 을 어렵게함
  • 모델의 성능을 떨어뜨리게 함

어떻게 해결할 것인가?

  • 훈련모델 = 훈련방법 (데이터, 모델구조)

Approach1: 모델구조:

  • 복잡한 패턴도 잘 인식하는 모델 구조를 쓴다
  • 서빙 및 훈련 계산량이 증가함

Approach2: 훈련방법

  • 커리큘럼을 만들어서 학습시킨다. (쉬운 데이터 부터 학습)
  • 훈련 계산량 증가 + 추가 데이터 필요

Approach3: Data Cleaning Method

  • Human Data Cleaning
  • Active Learning (모델이 1차로 labeling -> 사람이 re-labeling)

사람의 도움 없이 레이블 노이즈를 제거 할 수 없을까?

  • Model inference
  • Relabeling by model

2. 레이블링 바로잡는 AutoML (in project Khan)

  • 문제: 흰 오리 한마리가 mislabeled 되어있을 때 어떻게 고칠 수 있을까?

Split -Train - Check 알고리즘

  • Split: 전체 dataset을 train /valid set으로 분할
  • Train: correction을 위한 “기준 데이터”
  • Checker : 레이블 Correction용도로 훈련한 모델. valid set를 훈련된 checker에 입력하여 labeling 검사!

MultiSplit – Train – Check - Vote

  • 여러버전의 Split branch를 구성
  • Vote: Label update를 위해서 각 branch의 “Split-Train-Check” 결과를 결합

어떻게 Vote하면 좋을까?

  • Majority Vote: 가장 단순한 방법.
  • checker 의 soft-value 값을 활용! -> PICO

3. PICO: Probabilistic Iterative COrrection

  • checker의 결과 베이지안 확률 결합
  • labeling의 Iterative Probabilistic correction
  • 레이블링 히스토리의 hidden markov modeling을 통한 반영
  • 반복적 확률적 Vote를 통해서 점진적으로 레이블 노이즈를 제거함.

설계와 구현사이 삽질기

  • 많은 checker를 학습해야함. (GPU 리소스 이슈)
  • 확률값 저장 시 메모리 이슈 (Spark, sparse matrix 활용)
  • inference 서버 부하 이슈 (local serving project)

PICO Architecture

4. FAQ 데이터 셋에 적용해 보기

  • LINE 사용에 관한 FAQ 톡 서비스 데이터 set에 적용
  • 일반적인 답변 인텐트 -> 구체적인 답변 인텐트로 변화함.

5. 개선 방향

  • 효율개선 - 데이터 셋 품질 사전 검증 모듈(PICO-trigger)
  • 품질개선: 생성모델를 통한 Imbalance Dataset 문제 해결
  • 품질개선: 다양한 Metric voting 방식 적용

6. 요약

  • 데이터 품질 전략이 없는 AI 프로젝트는 성공 하기 어려움
  • AI 데이터 자동정제 파이프라인은 매우 큰 경쟁력
  • Naver Clova Chatbot Builder는 PICO를 통해서 데이터 자동 정제하여 서비스 품질 개선
  • PICO 아키텍쳐는 다른 종류 데이터 셋에도 적용 가능

세션5: 자율주행 시뮬레이터를 개발하면서 경험한 한계점 및 활용 방안 - 홍준님

0. 전달하고자 하는 내용

시뮬레이터의 한계점과 효과적으로 활용할 수 있는 방법

1. 자율주행 시뮬레이터란?

  • Real-World를 대체하는 것이 시뮬레이터의 역할임.
  • 구현하기 어려운 Edge case(차량에 비친 차량, 도로 위에 날아다니는 비닐 등) 들이 존재함

시뮬레이터가 필요한 이유?

  • 실차를 이용하는 필드 테스트의 한계점이 있기 때문에

시뮬레이터에서의 이슈

  • 실제와 얼마나 비슷한가?
  • GT를 얻을 수 있는가?

2. “인지” 분야에서의 이슈

질문1: 가상 센서의 완벽한 정답 데이터를 얻을 수 있는가?

3D map

  • 실제 존재하는 맵을 만들 경우 시간, 비용이 매우 많이 듦
  • 해당 지역 촬영 및 3D 복원 -> 3D 리터치, 오브젝트 분리작업 -> 텍스쳐, 머티리얼, 라이팅 작업
  • 표지판, 차량 등 오브젝트 생성

GPS

  • 정밀한 HD Map이 있어야 구현 가능함
  • 신호가 약/강한 지역 구현
  • Sensor Noise modeling (Multipath error)

Camera

  • 아직은 현실 데이터와 차이가 많이 남
  • GT를 얻기 쉽기 때문에 virtual data를 많이 활용하려고 함.
  • Dataset으로써 역할은 충분히 가능함
  • Future work: 사용자의 카메라와 같은 “스타일”의 이미지로 데이터를 Translation해야한다

Lidar

  • Distance + Intensity
  • Noise의 모델링이 실제와 너무 달라 어려움

질문2: 센서는 몇개나 사용할 수 있나요?

  • 환경 모사를 위한 CPU가 따로 필요함 (사용자의 PC성능에 달려있음)

3. “판단” 분야에서의 이슈

질문3: 시뮬레이터의 주변 차량들이 사람처럼 움직였으면 좋겠어요.

  • 주변 차량이 사람처럼 주행하려면 결국 완전 자율 주행이 가능해야 함.
  • 실제 도로에는 다양한 차량, 성향의 사람이 존재함.

방법

  • 주변 차량의 파라미터 자유도를 높이자
  • 멀티플레이로 “진짜”사람이 운전하는 상대 차량
  • 딥러닝 적용

질문4: 시나리오는 어떤것이 있나요?

  • 시나리오를 튜닝할 수 있도록 함.

4. “제어” 분야에서의 이슈

질문5: 실제 차량과 가상의 차량의 Dynamics가 얼마나 동일한가요?

  • 꽤나 비슷하지만 필드 테스트는 꼭 필요함.
  • 검증된 시뮬레이터들이 많음.

5. 알고리즘 개발 (넘김)

좋았던 점/새로 알게됨 점/시도해볼 것

  • facet으로 샘플 데이터 시각화
  • 대용량 분산처리가 어려운 사전 NLP 작업의 경우(라이브러리 설치 등) API화 하여 호출하여 사용
  • 모델 서빙 시 inference 서버 외 전/후 처리(비즈니스 로직 등)를 담당하는 서버 따로 사용
  • Labeling 오류 수정 자동화 > PICO 알고리즘 테스트 해보기