![AITech 학습정리-[Day 36] 가벼운 모델 / 팔리는 물건 / 가장 적당하게](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FF7IxE%2FbtrmgRPklAC%2FkNx2FXYFpl6builDmMDFok%2Fimg.png)
===========================================
학습내용
(1강) 가벼운 모델
좀 추상적이고 철학적인 내용들이 들어있음. 타이핑으로 정리해봄.
"청소좀 해줬으면 좋겠다" 라는 결정도 로봇이 알아서 하는 시대가 되었다.
정확도가 높아지면서 중요한 결정도 맡을 수 있게 되었다. 결정할 수 없는 문제도 있는데, 법률이나 조건. 또는 인륜적인 문제.
경량화 (Lightweight) 와 소형화 (Miniaturization)의 차이는 경량화는 불필요한 것 등을 줄여서 가볍게 해주는 거고 소형화는 말 그대로 물체 형태의 크기를 작게 하는 것. 우리가 하는건 경량화. 딥러닝 모델을 작게 해서 작은 곳에서도 수행할 수 있게 한다. 그럼 cloud에서 부담이 줄게되어서 좋음.
또 기계에 넣지 못하더라고 중간에서 처리하고 중심 cloud는 간헐적으로만 일을 함. 중앙 cloud에서 다 처리하는걸 Centralized intelligence 라고 하고 중간에서 처리해주는 걸 Edge intelligence 라고함.
Classification 에서 backbone은 AlexNet, VGG, ResNet, SqueezeNet, DenseNet, Inception v3, GoogLeNet, ShuffleNet v2, MobileNet v2, ResNeXt, Wide ResNet, MNASNet 에서 잘 안벗어난다. 완전히 바닥부터 만들면 그게 정말 성능이 있는지 없는지 확인도 안되고 힘들고 굳이? 하면서 안하는듯.
경량화를 한다고 짜잔! 하고 한번에 되는게 아니고 그 내부에는 여러 과정을 거친다.
https://drive.google.com/file/d/1dNjGa0KxQiWkYcxk8geRaMOzNmRf037R/view?usp=sharing
(2강) 팔리는 물건
개발시간을 고려할 때 개발자 자신은 고려하고 있는가? (밥먹는 시간 등)
잘 만들면 잘 팔릴까? 이것이 진짜 고객이 원하는 것인가?
문제를 풀 때 순서가 있다.
- 스스로 문제를 정의한 다음
- 새로운 기술을 이용해서 그 문제를 풀어보기
- 수업 동영상을 보겠어요!
https://zdnet.co.kr/view/?no=20170616090644
코드를 잘 작성하는게 일의 전부가 아니다. 5~10% 밖에 안되고 다른것들이 더 많다.
학습 시간의 80%는 본질적인 것에 투자하고 나머지 20%를 프레임워크나 라이브러리 등의 도구를 배우는 데에 투자하는 식으로.
| http://www.yes24.com/Product/Goods/67350256?OzSrank=1 |
분담하지 않고 협업하는게 좋은 경우가 많다. "난 이것만 해도 되니까 이 부분만 알아야지!" 하면서 하는게 분담. 모두가 문제를 다 아는 상태에서 같이 하는게 협업. 서로의 구멍과 삽질을 메울 수 있다.
소비자와 개발자 간의 언어장벽이 중요하고, 앞에서 빨리 문제를 잡아 해결하는게 중요하다. 안그러고 뒤에 발견되면 했던게 다 무산이 됨.
성능만 좋으면 무조건 좋은가? 90% -> 99% 로 향상시키는데 50억원이 든다. 그만한 가치가 있는가? 애초에 이 일이 소비자가 원하는 건가?
Cloud-based AI에서 AI Model Compression을 통해 저비용, 사생활 보호, Stand-Alone을 해낼 수 있다.
지금은 AI로 뭐든지 할 수 있을것 같다는 거품단계이지 않을까
https://github.com/mit-han-lab/tinyml
https://arxiv.org/pdf/2007.10319.pdf
Cloud AI > Mobile AI > Tiny AI
ResNet-50 > MobileNetV2 > MobileNetV2(int8)
"진짜" 실생활 문제 해결 솔루션들.
메모리, CPU 제한 실습
https://drive.google.com/file/d/1O1gr2JTISWfOCx_t6Cz14HJ2JEUJpTjh/view?usp=sharing
(3강) 가장 적당하게
| http://www.yes24.com/Product/Goods/8301384?OzSrank=1 |
문제를 푼다는건 초기 상태에서 원하는 상태까지 가는 것. 중간 과정들은 decisions 되면서 감.
우린 거인의 어깨위에 올라가면 되기 때문에 중간 과정은 증명된 사실로 생략 가능하다. 코드에서도 마찬가지.
계속 decision 하면서 최적의 답을 찾아가는게 optimization
요즘엔 성능보다는 모델 크기와 실계산 시간도 고려해서 나와야 한다. 그래서 모델 경량화만 하는 연구도 있음.
https://drive.google.com/file/d/1axseRVXr-86WmO28nRpVPRxENSJAd16i/view?usp=sharing
=====================================
과제 / 퀴즈
https://colab.research.google.com/drive/1qfowcbAyj0HTwBhtW_gvOmcphqAG1Pul?usp=sharing
================================
마스터세션
분업보단 협업.
일의 quality를 높이는데 좋다. 단점이라면 시간이 오래 걸리고 커뮤니케이션 cost가 높다.
서로 다른 관점에서 보며 일의 질이 향상된다. 짝 작업.
https://www.youtube.com/watch?v=1zybuzVgGsA
협업의 목적은 발견. 상황은 불확실하니까. 죽이되든 밥이되든 어쨋든 만들어야 하는건 분업. 너가 없으면 안되는 역할 and조건 분업.
"이거 아니였어요? 저거 아니였어요?" 삔또상하고.. 커뮤니케이션 cost가 높음.
[조교] 코드 리뷰 관련해서 도움이 될만한 영상이 있는데 참고하시면 좋을거 같아요!!
출처: 코드 리뷰 잘하는 법(테크보이 워니) - 16분
짝코딩은 내가 바뀌기 위한 방법
시간축을 통해 self 협업: 회고
나를 통해 배운다. 배우고 휙 배우고 휙 버리지 말고.
분업 협업 완전히 나뉘는 개념이 아님. 적당히 섞일수도 있고..
==============================
피어세션
그냥 내가 지난 과제 했던거 해봄..
===============================
후기
해야할 일들만 하다보면 잘 될까