Data Centric

더이상 성능을 미세하게 올리는 것에 집착하는 AI 엔지니어링은 요구되지 않는다. 과연 어떤 능력이 더 중요할 것인가?

• 수학을 임성빈 교수님만큼 해야 AI를 할 수 있는가? Nope
• 대신에 ML/AI Engineer들은 이제는, 코딩을 잘해야 한다. 네트워크에 대한 지식이나, CS에 대한 지식들이 더 많은 Area에서 기회를 줄 것임.

실전 AI에서는 매우 복잡한 단계를 거쳐서 프로젝트가 진행된다.

Issues

• Data
  • 실제 ML 프로젝트에서는 양질의 데이터 확보가 관건임.
  • Production time 데이터(프로젝트가 끝난 후 Serving 단계에서의 데이터) 와 Experiment 데이터가 다를 때 발생하는 문제들
  • 데이터 생성에 관한 문제
    • User generated data: inputs, clicks for recommendation
    • System generated data: logs, metadata, prediction
    • Data Flywheel (데이터 선순환): 사용자들 참여로 데이터 개선
      • 구글 포토를 사용하면 가족들의 얼굴을 계속 같은 사람인지 물어보게 하여 사람들이 직접 태깅하게 하는 것. 데이터가 스스로 라벨링을 하게 하는 작업.
    • Data augmentation: 데이터를 임의로 추가 확보
  • Data drift: 시간이 지나면서 데이터는 계속 바뀔 것임. 어떻게 production 레벨과 experiment 레벨의 데이터 간극을 맞출지가 중요한 문제이다.
    • 2주나 4주 등 일정 간격을 정한 뒤 새로운 데이터로 새로운 모델을 뽑아냄. 이 때 새로운 모델을 뽑아낼 때는 hyper parameter tuning이 되어있을 것임. 이것을 가지고 Dynamic 하게 학습을 시키는 등 대책이 있으면 좋음.
  • Data Feedback Loop
    • 사용자로부터 오는 데이터를 자동화하여 모델에 피딩해주는 것이 중요함.
• Model
• Algorithms
• Metrics
• Hyper parameter tuning

앞으로 알아야 할 것들.

• MLOps 도구들
• 당연히 데이터베이스!! SQL
• Cloud - AWS, GCP, Azure
• Spark (+ Hadoop)
• Linux + Docker + 쿠버네티스
• Scheduling 도구 (KubeFlow, MLFlow, AirFlow)

위의 것들을 써보는 것을 추천하지만, 전문가가 되라는 것은 아님. 최근엔 이러한 역량들을 전부 요구하기 때문이다.

하나의 시스템으로서의 ML/DL 개발

1. 개발자???

2013 문화체육관광부 우수학술도서 - 프로그래머로 산다는 것(황상철, 하호진, 이상민, 김성박 - 로드북)

해당 책이 출판되고 나서 많은 개발자들이 화를 냈음. 책 표지가 화장실에서 노트북을 하는 장면이었기 때문임. 미래도 없고 꿈도 없듯이 밤낮없이 화장실에서도 일하면서 과로로 쓰러지라는 것이냐! 라는 느낌이었기 때문. 기존 개발자들은 연봉도 오르지 않고 쇠퇴하는 경우가 많았기 때문에 프로그래머를 평가절하한 것이냐는 의견이었음. 프로그래머가 왜 되려고 하는 것인가? 대부분의 경우 프로그래밍이 어렸을 때부터 너무 재밌었기 때문에 프로그래머가 된다고 한다. 보통 모바일 게임의 경우 화장실에서도 볼일을 다보고도 계속 하듯이, 프로그래머가 되려고 한 자체는 결국에 이 일이 재밌고 즐거워서, 평생 할 수 있어서이기 때문이어야 할 것이다. 해당 책 소개를 의도한 이유는, 재밌다면 그 일을 계속 하라는 것을 이야기하고 싶어서이다. 코딩이 재밌다면 화장실이 아니라 어디에서 하든 상관없다. 하지만 나를 소진해가면서 밥벌이를 위해서라면 하지 마라는 것을 이야기하고 싶었다.

1.1 개발자??? or ?????

보통 신입사원 면접을 진행할 때 겪는 일이다. 기술면접 할 때 아이스브레이킹 시간을 가지고 간단한 기술문제를 푼 이후 난이도 조절을 통해 다음단계를 진행하게 된다. 아래는 3-5년차 자바 개발자를 대상으로 면접을 할 때 냈던 문제이다.

위의 문제를 가지고 해당 자료구조(스택)를 만들어보라는 문제를 냈다. 하지만 클래스 선언도 못하는 경우가 허다했다. 이력서는 화려한데 왜 못하지..? 라고 물어보면 “최근에는 개발보단 관리를 많이 하느라..” 라는 답변이 돌아온다. 이런 상황이 이해가 되지 않았음. ‘읭?’

1.2 개발(놈) Begins - 업무 할당

프로그래밍 관련 학과를 졸업하고, 현업에서의 시간도 어느정도 지났는데 왜 하지 못할까라는 고민에 대한 고찰.

회사에 처음 가서 어떤 과제를 받았다고 해보자. 정상적이지 않은 회사라고 한다면 대부분 “이 일을 언제까지 끝낼 수 있겠니? 참고로 시간이 없어.” 라면서 일을 시킨다. 무조건 그 시간안에 다 해야 하고, 심지어 충분한 레퍼런스나 리소스도 없다. 관리자가 시간만 관리하고 기술적 지원/교육도 없는 상태에 데드라인에 맞춰서 일을 끝내야 하는 상황에 놓였다고 상상해봐라..

1. 제목 & 저자

제목을 통해 해당 논문이 어떤 내용을 담고 있을지 상상해 보는 것이 좋음.

• 예를들어 Show, Attend and Tell: Neural Image Caption Generation with Visual Attention 해당 논문의 제목만 보고 ‘’아 이 논문은 Image Caption에 대한 논문이겠구나. 오 근데 시각적인 Attention을 이용했네?’ ‘Attention이 뭐지? 그냥 읽을까?’ ‘조금 찾아보고 읽을까?’ ‘아 이건 완벽하게 공부하고 다시 읽자’ 와 같이 모르는 용어가 나타났을 때 어떻게 대처할지 등 논문을 읽을 방향성을 잡을 수 있다.
• 멘토님은 아주 조오오오금 (사전지식 정도만) 서치하고 읽는다고 하심

또한 제목과 더불어 저자를 보면 논문의 신뢰성을 대략적으로 추정할 수 있음.

• ex) 조경현교수님: RNN의 축을 그으셨던 대가가 참여했으니 이 논문의 수식이나 피쳐들에는 오류가 없겠구나!
• 신뢰성이 중요한 이유 중 하나: 매우 유명한 GAN 논문에는 수식의 오류가 있었음. 즉, 저자를 보고 의심할 수 있는 능력이 있어야 함.

2. Abstract

2. Abstract

최대한 꼼꼼하게 읽자. Abstract 부분은 논문에서 가장 처음으로 읽게 되는 파트다. 해당 파트를 읽고 이 논문을 계속 읽을지 말지 판단할 수 있기 때문이다.

• ‘Abstract만 읽었는데 재밌네’ -> 논문을 읽어봐야겠다!
• ‘이거 Abstract 너무 어려운데..?’ 혹은 ‘하나도 이해 못하겠다..’ -> 읽지 않는 편이 좋음.

3. Instruction

CV 도메인에 대하여 (박선규)

흔히 볼 수 있는 컴퓨터비전 태스크에 대한 사진

Taskonomy (CVPR 2018 Best Paper)

• 컴퓨터 비전에 관련된 26개의 태스크를 하나하나 정의하고, 한 태스크로의 모델을 학습시킨 후 전이학습에 대한 성능을 기준으로 두 태스크에 대한 관계(유사도)를 분석한 논문임.
• 태스크에 대한 연관관계보다는 태스크가 이렇게 많았구나..라는 인사이트를 얻게 됨.
• 이렇게 태스크가 많은데도, 학회를 가면 항상 새로운 것을 보게 됨. 연구분야가 굉장히 넓고 다양하다.

이미지에 관련된 것은 Convolution에 굉장한 의존성을 가지고 있다. 즉, Detection과 Segmentation 정도만 배우더라도 다른 컴퓨터비전 태스크를 접할 때 큰 어려움 없이 접할 수 있다.

OCR

ViT