SSUM2

About AI, ML, DL, NLP

Naver Deview 2019 Day-1 발표 정리

13 minute read

키노트

  1. 네이버랩스 소개
    1. A-City (1)
      1. autonomous space
        • AI AR Autonomous space
      2. DATA; Seamless 3D/HD spatial Data
        • 지도데이터를 확보해서 사용자의 위치정보에 따라 원하는 기능을 수행
        • 아웃도어-인도어를 잇는 지도 데이터 구축
      3. Visual Localization
        • 실내 위치정밀도를 15센치 정도로 낮춰 구현 실내에서도 gps구동 가능
      4. 항공사진 + 지상에서 찍은 사진을 결합해서 디테일한 도로맵을 구축
      5. 오늘부터 HD map data를 무상 배포
    2. A-City(2)
      1. 자율주행 머신 플랫폼;
        1. ALT - 플랫폼 (실외)
        2. around 플랫폼 (실내)
          • 5g brain
        3. Around - C
          • 카페 딜리버리
          • 복잡한 공간에서 휴먼-로봇 인터랙션을 테스트하기 위해 개발
          • 심리적인 안정거리, 자연스러운 이동을 구현
          • 심층 강화학습; 딥러닝 기술 접목
          • 사람처럼 점과 선으로 표현되어있는 “눈”을 구현’; 비언어적 표현
      2. 네이버 제2사옥을 1784 프로젝트로 구현
    3. 네이버랩스 유럽; AI R&D BELT
  2. 수아랩 창업 성공 스토리
    1. 수아랩이 지킨 세가지 원칙
      1. 한 우물 파기
        • 제조업에서 딥러닝 기반 비전 검사에만 집중하고 있음
      2. 뛰어난 사람들만 채용
      3. 스스로 결정하는 자율과 책임의 문화
        • 업무 지시를 구체적으로 하지 않고, 어떤 일이 필요하고, 왜 필요한지, 이 일을 수행했을 때 어떤 파급효과가 있을 지 스스로 생각하게 함
        • 언제 출퇴근하는지, 근태는 관리하지 않고 결과물에 대한 평가만 있음
    2. 수아랩이 얻은 세가지 행운
      1. 뛰어난 구성원들
      2. 정부와 투자자의 적극적 지원
        • 정부 창업지원프로그램 이용
      3. 제조 강국 대한민국…
        • 제조업 하나의 시장에 집중해도 충분히 좋은 성과를 얻을 수 있었음
  3. FURIOSA; 고성능 AI칩 개발 회사 소개
  4. 문재인 대통령 연설; IT강국을 넘어 AI강국으로
  5. Naver Search & Clova
    1. 네이버 검색 연혁
    2. 현재의 네이버 검색
      • 모바일서비스를 위한 정교한 검색 알고리즘
      • 컨텍스트 분석한 것을 적극 활용
      • 사용자의 일상언어, 대화에서 문맥을 파악해서 정보를 추출
      • 비전 검색
      • 추천검색 기술
    3. User Understandng
      • 사용자 이해를 기반으로 어떤 정보를 원하는지, 어떤 정보를 제공해주어야 하는지 파악
  6. 컨테이너 기술에 기반한 클라우드 네이티브 컴퓨팅
    1. 네이버는 클라우드 네이티브 컴퓨팅 환경으로 전환
    2. PINPOINT
      • Observability 향상
      • 지원 생태계 확장
  7. 네이버 클라우드 플랫폼
    • https://www.ncloud.com
  8. NAVER Clova AI

Track 1) 엄~청 큰 언어 모델 공장 가동기! (LaRva: Language Representation by Clova)

  1. resources

    • 수많은 요구사항에 따라 만들어야 할 모델도 많고,
    • 주어진 리소스는 V100
    • 비싼 만큼 일의 효율도 중요

  2. LaRva 공정 최적화

    1. 평가
      • 학습이 끝난 후 평가하는 건 위험하다고 생각해서 10만스텝마다 체크포인트를 받아 검증 진행
      • -> 하나의 모델에서 10개의 체크포인트가 나오고, 다운스트림 태스크가 8개일 때 한번 할 때마다 80번씩 파인튜닝 해줘야함
      • 한번에 요구사항을 수렴하기 어렵다는 단점
    2. 이를 해결하기 위해서 평가/성능 리포트를 자동화&시각화
      • Minio; 모델을 저장하는 서버
      • Downstram tasks
      • fine-tuning에 필요한 요구사항
      • https://github.com/naver/claf

  3. 전처리를 효율적으로

    1. 구글에서 발표한 multi-lingual vocab
      • vocab size 10만, 한국어는 2.7%뿐
    2. 한국어에 맞는 vocab을 찾음
    3. MLM 과 NSP
      1. Masked language model
      2. next sentence prediction
        • segment를 중심으로 이진분류
    4. Dynamic data pipeline
      • 매번 결과가 달라지는 영역을 다이내믹 데이터 영역
    5. 한정된 자원을 극대화
      • variable sequence length 를 사용해서 성능향상을 얻을 수 있음
    6. nsp가 필요없다고?
      • 최근연구에서는 NSP가 필요없다는 이야기
      • RoBERTa에서는 랜덤 텍스트 없이 연속된 시퀀스에서 준비하는 full setence를 준비해 LSTM을 하지 않는게 좋다고 제시
      • 새로운 파이프라인에서는 full sentence에서 마스킹만 다이내믹하게
    7. 새로운 다이내믹 데이터 파이프라인
      • 배치사이즈만큼 읽어서 트레이닝 인스턴스 준비
      • 분산학습에서 효율적으로 사용할 수 있는 형태
      • 새로운 방식이 조금 더 빠른 처리가 가능

  4. 학습을 빠르게

    1. BERT base기준으로 최대 10일이 걸렸던 것을 줄여야한다
      • V100 32G 자원으로 32배치씩 8개의 GPU를 사용해야함
      • 싱글 피리시젼당 GPU 하나 당 24개밖에 넣지 못함…
      • Half precision을 사용해서 성능저하는 없고 연산속도 증가, 메모리 절감 가능해짐
    2. Mixed Precision Training
    3. 배치사이즈가 클 수록 성능이 좋아진다
      • 분산학습필요 -> 처음에는 노드만 늘렸는데 데이터 처리량 증가폭이 너무 비효율적이었음
        • 투입 자원 대비 40%의 효율뿐
        • 네트워크 버틀랩 때문 => 네트워크도 엔지니얼이 필요
      • RDMA + GPU
        • 자체적인 프로토콜을 사용하기 때문에 프로토콜 오버헤드를 줄이고, CPU끼리 직접 연결
        • 리니어하게 증가할 수 있었음 -> 자원 효율을 최대치로 끌어올림

  5. 더 좋은 언어모델을 위해

    1. KLUE

    2. 마스킹 전략

      • sapce level masking 추가(어절단위)
      • 기계독해에서는 효과가 컸음

    3. Batch size는 클 수록 성능이 올라감

    4. model size도 클 수록 좋다

    5. 토큰화;

      1. char vs sub-word(워드피스)
        • 감정분석은 캐릭터단위, 그 외에는 비슷한 성능
      2. Cased vs uncased
        • 자모 분해로 토큰수가 늘어나 기계독해 성능이 하락하고 케이스가 우세
        • 감정분석은 언케이스가 우세

    6. vocab size는 64k가 좋은 성능을 보임

    7. Model; BERT vs RoBERTa

      • 초반에는 로버타가 우세하지만 1만 스텝이후로는 비슷함

    8. RoBERTa + Large(L24) + 1024B

      • 기존에 비해 3배정도 성능향상

    9. 파인튜닝 관점

      1. 멀티 태스크 러닝
        • MT-DNN; 태스크를 모두 섞어놓은 레이어에서 태스크를 분리하고, 각 태스크에 파인튜닝
      2. 실험결과

  6. 서비스는 속도

    1. 처리속도, 메모리, 비용이라는 문제
    2. 처리속도; 엔지니어링 접근법
      1. GPU로 성능향상하는 방법
        • cuBERT; 52ms까지 감소
        • TensorRT
    3. 모델 사이즈가 너무 크다! 모바일에 맞는 작은 모델 만들기 (future work)

Track 2) Papago: Engineering BERT into NMT

  1. Attention mechanism
  2. Robustness of MT Models
  3. BERT
    1. MLM
      • Sentence 내 word에 masking하고, transformer encoder에 넘김
    2. Next Setence Prediction Task
  4. hypothesis and questions
  5. BERT를 통해 missing token에 대해서 대처 가능하나 noise는 어떻게 구별할것인가?
  6. 1 Finetuning approach
  7. multi encoder approach
  8. BERT + NMT 아키텍쳐
    • 레이어 6개로 이루어진 버트 인코더 -> to be fair with NMT encoder
    • ReLu, Sinusoidal 임베딩 사용; 오리지널 트랜스포머와 유사하게 함

Track 1) 챗봇 1만 개의 모델 서빙하기: AI 서비스 어디까지 해봤니

  1. 모델의 성격 파악하기

    1. 텍스트? 이미지? 음성?

      • 모델에 들어가는 인풋 형태는 어떤 tensor 형태의 feature일 것
        • 이미지, 음성, 텍스트, 영상이더라도 모두 임베딩을 통해 tensor 특징값으로 변환
      • 규모, 서비스의 형태가 중요
        • 배치성 작업인가? 대량의 파일노드가 꾸준히 들어올 수 있는가 하는 고려가 모델 설계단계부터 되어야 함
      • 서비스 요구사항에 따라 서버, 모바일, 임베디드 등 여러 환경 고려 필요
        • 웨어러블 디바이스를 사용한다고 할때, 엣지 서버 노드를 사용
        • 머신러닝을 서비스화할 때 중요한 건
          • 레이턴시(얼마나 ㄸ빠르게 모델이 계산해서 리턴할것인가); 리터러시
          • 얼마나 많은 양을 계산할 수 있을것인가?

    2. 안되는 것을 빠르게 포기하는 방법

      • 불가능!) 데이터 없이 학습 없이 이루어지는 마술같은 머신러닝
        • 정말 긴 문장에 대해서 질의하고 답변하는 모델
        • 도메인 전용 학습이 필요치 않은 범용 모델
        • 10턴 이상의 긴 문맥을 고려하고 이해하는 모델
      • 제품화하고 시장에 내놓을 때 가능/불가능 타겟을 빠르게 정리

    3. 되는 것을 빠르게 파악하여 집중하자

      • 구축 > 훈련 > 평가 > 개선으로 이어지는 흐름을 자동화함; AutoML
        1. 자동으로 데이터셋을 개선하기, 정리하기 (강재욱님 발표)
        2. 자동으로 모델을 평가하고 튜닝하기 (2018 DEVIEW 이재원님 발표)
        3. 분산 환경과 파이프 라인으로 최대한 빨리 모델 학습하기
        4. 재학습, 운영, 관리, 지표화를 통해서 통제 가능하고 운영 가능한 머신러닝 서비스 만들기
        5. 유저의 암시적 피드백을(IRF) 통해서 데이터 개선하기
          • 챗봇에서 가능한 내용

    4. 모델의 비용 계산하기

      • SOTA 하나로 모든 데이터를 최적으로 서비스하는 것은 무리

      • 어떤 언어에서 이 모델이 적합한가, 언어마다의 특성을 고려한 데이터 규모별 강점을 가지는 다양한 모델을 고려해야함

      • 다양한 모델들을 테스트하고 적용해보면서 최적화

      • 비용부담; 연산장치에서 사용하는 부동소수점 연산으로 비용을 계산

      • 인공지능으로 돈을 벌기 위해서는?

        1. 모델 학습에 필요한 비용이 저렴하고
        2. 사전 학습된 모델을 도메인 별 fine-tuning 하여 이용 가능하며
        3. 모델의 연산 비용이 충분히 작고 최적화 되어 있으며

        4. 모델의 물리적인 용량이 작아 한정된 인프라에서 다수를 서비스 할 수 있으며 5. 동시에 충분한 성능(정확도)를 보장해야 합니다.

        5. 즉 비용을 고려한 최적화가 필요합니다.

  2. Amdahl’s law를 기억하며

    1. 암달의 법칙, 암달의 저주
      • 95%를 병렬화 할 수 있는 코드가 있다고 했을 때에도 성능향상은 20%밖에 없음
      • 무한의 컴퓨팅 자원을 투입하더라도 획기적인 성능 향상은 기대하기 어려움
    2. 범용환경? 전용환경?
    3. 빠른 모델이 좋은 모델일까?
      • RNN과 BERT?
        • BERT가 병렬화 되어있어 빠르지만 모델 사이즈는 BERT가 훨씬 큼
        • 레이턴시와 쓰로풋을 항상 고려해야함! 이를 트레이드 오프 하면서 둘다 고려해야함
        • 베이스라인의 중요성, 여러 모델을 앙상블 해야하는 이유!
    4. 경제적인 모델?
      • 학습과 추론의 성능 최적화가 곧 비용인 시대
      • 연산량 자체가 워낙 많기 때문에 쓰로풋과 비용에 대한 최적화가 가장 어려움…
      • 모델을 설계하는 단계부터 이러한 내용들을 많이 생각해야함 ㅠㅠ

  3. 조금만 더 줄어 주면 안될까?

    1. 모델과 대화하기 그리고 설득하기
      • 모델 레이어, 파라메터 튜닝
      • L1 가지 치기
      • 레이어간 파라메터 공유
      • 컴퓨팅 자원 친화적인 연산으로 교체
      • 특정 장비별 오퍼레이션 최적화
      • BERT는 거대한 모델이기 때문에 최적화를 하는 일이 비용도 많이 들고 시간도 많이 소요됨
        • 양자(quantization)된 모델
    2. 모델러와 소통하기 어렵다
      • 같은 목표와 성과로 이어지면서 서비스와 제품으로 묶여야함
    3. 엔지니어에게 남은 모든 걸 하기
      • 프레임워크의 코드도 커스터마이징
        • 텐서플로, 파이토치를 사용하면서 버전이슈에 대한 파악 필요
      • 수없이 빌드-테스트 하면서 연산 라이브러리도 교체함
      • JNI(Java Native Interface) 수준으로 서비스 코드와 결합도 시도
      • 네이티브 바이너라도 시스템과 환경별로 생성
      • 모델 내부에서 프로파일링을 통해 모델의 계산 비용을 분석
      • 정적분석을 통해서 어디서 연산이 많은지 체크 가능
      • 물리적인 연산장치도 체크해서 필요한 경우에 장비를 추가하거나 직접 intel과 미팅하여 문제 제기
    4. Intel AVX 512
      • 챗봇 서비스에 사용하는 모델 BERT 기준으로 단일 추론 7ms 수준으로 개선
        • batch 1, intel xeon sp2 2.5Ghz 20 core
      • tensorflow 1.2 이상이어야하고 스케쥴링 변수가 잘 지정되어야하는 등의 조건을 만족해야함
    5. AVX 512 VNNI
      • 양자화된 모델 추론 가속을 적용하면 3배정도 빨라질 것이라 예상
    6. TensorRT
      • 특정 환경 런타임을 기반으로 한 추론 라이브러리 등이 존재
      • 범용 연산에서 전용 연산으로 내려온다면 연산 속도가 급격하게 줄어들 수는 있음
      • 서비스에 따라서 비용계산을 유연하게 해야함

  4. 모델 정말 1만개를 서비스했을까?

    • 도메인마다 특화된 서비스 튜닝, 빌드가 필요함 –> 상징적인 숫자 1만
    1. Auto ML + Auto Quantization
      • 모델 튜닝하는 것과 데이터를 튜닝하는 것, 그 외 연구에 대해 필요한 모든 걸 준비하는 사전준비작업을 최대한 자동화함
    2. one source multi environment models
      • 다양한 환경에서 (일반서버, GPU서버, 웨어러블, 가상, 오케스트레이션) 서빙 가능한 모델을 하나의 소스와 빌드 시스템으로 관리
      • 모든 모델과 데이터들을 Freeze 된 버전별로 스냅샷으로 저장해서 관리, 배포, 수정할 수 있게함
      • 네이버 딥러닝 분산 플랫폼 C3DL 기반으로 동작
    3. decentralized clusters - (kaa)
      • 비 중앙화된 분산 클러스터를 이용한 머신러닝 모델 서빙 엔진을 설계
      • Spark, scala, tensorFlow를 하나의 코드베이스로 동작하는 데이터 파이프라이닝과 서빙시스템 구축
      • 공통으로 쓸 수 있는 로지컬한 코드를 다 분리해서 정적모듈화 해서 신속하게 모델 설계를 하고 실험할 수 있도록 함
      • On-premise 등 패키징을 시스템 초기 설계 수준에서 고려
        • 동일한 인터페이스에서 운용할 수 있도록
      • 클러스터는 적어도 두벌 이상의 데이터가 존재
        • 분산 클러스터, 한쪽이 죽어도 다른 부분에서 체크해서 안정적인 배포가 가능하게 함

Track 1) 레이블링 조금 잘못돼도 괜찮아요: Clova가 레이블 노이즈 잡는 법

  1. 레이블 노이즈 그게 왜 문제?
    1. 레이블 노이즈란?
      • 같은 범주의 데이터를 잘못 설명하는 의도되지 않은 미스레이블링
      • 레이블 노이즈는 어디에서나 존재함
    2. 왜 문제인가?
      • 레이블영역에 대한 특징을 모델이 학습하는데 노이즈가 많이 있는 경우 더 복잡한 패턴을 학습하게됨
        • 불필요하게 다른 내용을 학습하게된다는 것
      • 모델의 feature extraction을 어렵게하여 모델 성능을 떨어뜨림
    3. 훈련모델 = 훈련방법(데이터, 모델구조)
    4. 복잡하고 큰 모델을 사용하면 됨(ex. BERT)
      • 노이즈데이터를 알아서 필터링해서 사용
      • 무거운 모델은 훈련비용, 서빙비용이 매우 증가함…
    5. 커리큘럼 러닝; MentorNet
      • 사람이 학습하듯 쉬운 데이터부터 제공해서 학습
      • 커리큘럼을 생성해주는 모델을 본 모델 앞단에 붙임
      • 그러나 훈련 복잡도가 높아지고 추가 어노테이션(데이터셋)필요
    6. 데이터 클리닝! 데이터 자체를 정제하자
      • 그러나 사람이 수동으로 작업해야함
      • active learing for label cleaning
        • 일단 기계가하고 사람이 2차검증
    7. 사람의 개입없이 레이블 노이즈를 제거해보자 => AutoML
  2. 레이블링 바로잡는 AutoML
    1. Project Khan
      • 챗봇 빌더에서 피쳐 엔지니어링, 하이퍼파라미터 튜닝 등을 담당하고 있음
    2. Split - Train - Check 알고리즘
      • 전체 데이터셋을 트레인/밸리드 셋으로 분할
      • 트레인은 콜렉션을 위한 기준데이터, 밸리드는 레이블링 검사대상임
      • checker에 트레인셋을 밀어넣어 학습, 밸리드 셋을 훈련된 체커에 넣어서 레이블링을 체크함
      • 그러나 모든 데이터를 검수할 수 없음
    3. MultiSplit – Train – Check - Vote; 전체 데이터를 빠짐없이 체크할 수 있는 방안
      • 각 체크에서 나온 것들을 보증해서 업데이트함
      • 여러버전의 스플릿 브랜치를 구성하고 각각의 S-T-C결과를 결합해서 Vote
      • 다수결(majority vote)에 따라 결과 레이블을 업데이트
      • 그러나 체커는 클래시피케이션 모델이기 때문에 코스트 밸류를 리턴 -> 이걸 soft-value로 활용할수 있지 않을지?
    4. PICO: Probabilistic Iterative COrrection
      • 확률을 다루는 부분을 다시 사용
      • checker결과를 위한 베이지안 확률 결합
      • 레이블링의 interative probabilistic correction
      • 레이블링 히스토리를 관리하는 모델링;Hidden Markov Model
      • 반복적 확률적 vote를 통해 점진적으로 레이블 노이즈를 제거
        • 주변의 꺠끗한 데이터로부터 correction, 노이즈데이터들도 교정되어감
      • 어떻게 Interation에 따라서 어떻게 확률정보를 전달할까?
    5. 레이블링 히스토리 HMM모델링
      • 현재에 과거의 이력을 알 수 없었음
      • 과거의 확률을 array 형태로 보유해야 체크 가능
        • => 서버 과부하!!
      • N × N per iteration
        • 이전의 단계만 기록함
        • hidden markov process
        • 이 경우에도 서버 과부하 ㅠㅠ
  3. 설계와 구현사이 삽질기
    1. PICO 실제 구현
      • GPU 리소스 이슈
        • 브랜치 마다 데이터셋의 비율을 지켜야하는데(0.05) 약 88개가 필요했음…
        • 아직 해결하진 못했으나 브랜치를 최소화하고 early stopping criterion을 도입할 예정
      • 확률값을 저장하고 읽어와야함 => 메모리 이슈
        • spark에 올리고 sparse matrix로 도입해서 해결
          • sparse matrix; 중요한 정보만 매트릭스로 저장하는 방법
      • 학습된 모델에서 밸리데이션 셋을 통해 결과를 받아와야하는데 inference API가 과부하
        • local에서 모델을 평가하는 방식으로 해결
  4. FAQ 데이터 셋에 적용해 보기
    • 데이터셋 인텐트 분포
      • 클래스 레이블링을 직접하다보면 실수가 발생할 수 있는데 이를 PICO가 잡아줄 수 있음
  5. 개선 방향
    • 클래스 inference issue
      • 주변이 없으면 볼 게 없다보니 고칠 수가 없음
      • 이 문제를 해결하기 위해 문장 생성 프로젝트의 모듈을 가지고와서 문장을 생성해서 그 부분을 채워줌
    • 다양한 metric voting 방식 적용
  6. 요약
    1. 데이터품질전략이없는AI프로젝트는성공하기어려움
    2. AI 데이터 자동정제 파이프라인은 매우 큰 경쟁력
    3. Naver Clova Chatbot Builder는 PICO를 통해서 데이터 자동 정제하여 서비스 품질 개선
    4. PICO 아키텍쳐는 다른 종류 데이터 셋에도 적용 가능
  7. Human-free data cleaning can improve your AI performance
    • 노동에서…벗어나자

Track 1) 모바일 서비스를 위한 가벼운 이미지 인식/검출용 딥러닝 모델 설계

  1. 소개
    • 새로 만든 성능 좋은 가벼운 딥러닝 모델 소개
    • 딥러닝 모델을 축소시키는 데 중요한 팁 공유

  2. Deep Neural Network의 출현으로 도래한 인공지능 (AI) 시대

    1. CNN
      • CNN -> 1026개의 숫자 결과가 나옴 -> 이미지의 feature value
      • CNN을 여러 계층으로 쌓았을 때 기대되는 성능 좋음
      • 나온지는 오래됐지만 학습시키기 어려워서 사용하지 못했음
    2. AlexNet
      • CNN을 처음으로 학습에 성공시킴
      • 10년 이상 지속된 성능 정체를 단번에 해소됨( 10%대가 깨지고 바로 20%대로 도약)
    3. 도래한 AI 시대
      • object detection, segmentation 기술 등이 실생활에 도입
      • 어떻게 deploy할 것인가?
  3. 딥러닝 모델 (backbone)을 통한 이미지 분류/검출기 트레이닝의 개괄

    1. backbone이란?

      • CNN네트워크가 학습된 상태에서 가중치를 품고 있을 때, feature extractor
      • backbone의 성능은 이미지 처리 딥러닝 모델의 성패를 좌우
      • backbone에 이미지 데이터를 넣어주면 어떤 고차원의 벡터가 나옴 –> feature를 뽑아냄 => feature extractor, encoder 라고 볼 수 있음

    2. Transfer learning?

      • backbone 에서 나온 feature를 가져와서 학습
      • backbone의 weight 파라미터들을 그대로 전이(transfer)

    3. finetuning

      • YOLO; 앞단의 backbone의 가중치를 고정하고 뒤쪽을 트레이닝해서 튜닝
      • SDD; backbone의 가중치를 고정치 않고 미세하게 튜닝하기도 함

    4. 서비스에 딥러닝 모델을 적용한다면

      • 어떻게 서비스에서 모델을 사용할 것인가?
      • 큰 모델을 가지고 프리 트레인된 백본을 만들고, 그다음에 타켓에 맞춰진 모델을 파인튜닝 하는 것이 좋다
      • 어떤 딥러닝 모델을 쓰느냐
      • 어떤 빅데이터를 이용해서 모델을 프리트레이닝 할것인가
      • 백본모델의 성능이슈
      • 트레이닝 세팅을 어떻게 정밀화할지

    5. 딥러닝 물체분류 검출기 트레이닝 개요도

      1. 큰 데이터셋 확보; ImageNet 1k
        • ILSVRC 에서 발표하고, 랭크 인 된 backbone들을 실제로 사용하고있음
        • 수많은 사람들이 사용해서 성능이 잘 나온다고 나온 결과물들이 있음
        • 전이학습하기 용이함
        • 클래스 별로 많은 이미지를 쓸 수록, 많은 클래스를 써서 트레이닝 할 수록 모델 전이학습이 더 잘 됨
      2. 딥 러닝 모델 선택, 큰 데이터에 학습 (pretrain)
        • 모델 선택&학습; 연산량 대비 성능(acc)이 높은 모델을 선택해야함
        • Model-zoo; 빠른 개발을 위해서 model을 모아놓은 페이지를 공개함
        • ImageNet 데이터 외 다른 데이터에 모델학습을 할 때에도 ImageNet기준으로 성능이 검증된 모델을 선택하는 것이 좋음
        • 모델을 깎는다? 성능 좋은 모델 설계/개발 + 트레이닝 스킴 최적화
      3. Pretrained backbone 의 성능 관찰 (evaluation)
        • 백본의 성능을 좋은 것을 쓰면 타겟 태스크의 성능이 무조건 좋아짐!

      4. 목표 데이터셋의 학습 데이터로 학습 (finetuning)

      5. 목표 데이터셋에서 검출기 성능 관찰 (evaluation)

  4. 최신 가벼운 딥러닝 모델들 소개와 몇가지 이슈

    1. 최신 가벼운 모델들

      • CNN을 두개로 쪼개서 더 적은 파라미터로 비슷한 성능을 낼 수 있게 함
      • 일반적인 CNN에서도 이를 사용 => SqueezeNet, MobileNetV1, MobileNetV2, MobileNetV3, ShuffleNetV1, ShuffleNetV2, MNasNet, FBNet, CharmNet, EfficientNet 등

    2. 최신 가벼운 모델들의 성능 재현

      • 논문을 따라서 잘 트레이닝 시켜도 리포트도니 성능을 얻기 쉽지 않음

      • 다른 세팅으로 동일 결과를 얻을 수 있게 아래 내용을 세팅해야함

        ※ 트레이닝 세팅 – optimizer 종류, learning rate 값, weight decay 값, epoch 수, learning rate scheduling 방법, data augmentation 방법/강도, 기타 regularizer 유/무

    3. 파인튜닝 성능 이슈
    4. 실제 서비스 이슈; 성능측면
      • Flop에 따라 속도가 비례하진 않음
    5. 실제 서비스 이슈; 모델 크기
      • 모바일에 올리기 위한 기존의 엄격한 기준이 많이 완화됨
      • 모델 크기가 작다해서 실제로 더 빠르지도 않음
    6. 실제로 돌려보고, 성능 측정해보고, Flop을 조정해야함!

  5. 새로 개발한 가벼운 모델과 성능 소개

    1. 모델 설계 배경, 목적&방법

      • 가벼운 모델 사이의 이슈를 해결하고 SOTA 대부분인 모델 전부가 NAS로 찾아낸 모델이며 이미지넷 분류 문제에 피팅되어 설계된 모델임
      • 가벼운 구조 중에서 SOTA를 얻어보자
      • CPU inference 용 모델을 개발해보자
      • 파인튜닝 잘 되는 구조로 개발
      • NAS, Netadpt류 방법의 베이스라인 모델로 제공

    2. 모델설계 디테일

      • 모델 구조 개선; input 쪽의 앞단을 계산량을 줄이기 위해 얇게(?) 되어있는데 이를 조금 더 보완하여 부족한 레이어의 피쳐 수를 보강함
      • 이를 통해서 성능이 매우 올라감

    3. 모델 설계 프로세스 요약

      1) 기존 모델 성능 reproduction - 제일 중요합니다

      2) 비교 모델들 성능 reproduction 3) 신 모델 연구 (설계/트레이닝/테스트 반복)

      – 모델 설계를 계속해서 바꿔가며 성능을 측정합니다

      – ImageNet-1k이 매우 크므로 작은 데이터셋 (예: cifar 등)에서 먼저 실험을 추천합니다.

      4) 모델 트레이닝 방법 (training scheme) 연구/최적화 – 최적 세팅을 연구하는 것이 중요합니다

      5) 모델 정밀 설계 – 추가 모듈을 통한 성능 향상 여지가 더 있는 확인합니다 6) Finetuning 결과 확보 – object detection이나 segmentation 등에 활용하여 성능 확인

    4. 신모델에 쓰인 디테일

      • 다운샘플링, 업샘플링 하나하나가 엘라스틱 모듈

    5. 학습환경

      • MXNet

      • Training 세팅 (MobileNet 등 기본 training 세팅에 더하여):- Mixed precision (fp16 + fp32) 사용

        - Learning rate 등 training hyper parameter들의 최적 세팅 경험적 튜닝 - Tensorflow 기본 세팅인 EMA (exponential moving average) 등 사용하지 않음

      • Test 세팅:

        • 기존 모델과 동일한 standard setting (256 resize 후 224x224 center crop) - 공정한 비교를 위해 찾아낸 세팅들 비교 모델에 모두 적용 후 비교

    6. 성능 비교

  6. 신모델을 활용한 finetuning 성능과 실서비스 적용 예 + 추가팁

    1. object detection 적용

  7. 결론

    • - Backbone 모델의 성능이 목표 task 성능을 크게 좌우하므로 좋은 backbone을 써서 트레이닝 하는 것이 중요합니다

    • - 최신 공개된 모델들은 finetuning 시 성능이 만족스럽지 않을 수도 있습니다

    • - 그러므로 리소스가 충분하면 좋은 backbone 개발을 시도하시고, 그렇지 않으면 공개할 저희

      모델을 쓰시면 됩니다 (ImageNet 성능과 Finetuning 성능까지 모두 좋습니다)

Leave a comment

You may also enjoy