꺼내먹는지식 준
Lifecycle of AI project _ 데이터의 중요성 본문
다음의 목차를 따른다.
1. Lifecycle of AI project
AI Research VS AI Production
보통 수업/학교/연구에서 정해진 데이터셋/평가 방식에서 더 좋은 모델을 찾는일을 한다.
하지만, 서비스 개발시에는 데이터셋이 준비되어 있지 않고 요구사항만 존재한다.
이에 따라 서비스에 적용되는 AI 개발 업무의 상당 부분이 데이터셋을 준비하는 작업이다.
Production Process of AI Model
서비스향 AI 모델 과정은 크게 4가지 단계이다.
$\rightarrow$ 결국 골자는 바로 요구사항을 충족시키는 모델을 지속적으로 확보하는 것이다.
이러한 요구사항을 충족시키기 위해 다음의 두가지 방법을 시도해볼 수 있다.
1. Data-Centric
2. Model-Centric
모델 성능 달성에 있어 데이터와 모델에 대한 비중
1. 모델 출시 전
50 : 50
2. 모델 출시 후
주로 속도 같은 측면은 초기에 확인하여 개선을 완료하나, 정확도는 해결되지 않았을 확률이 크다.
정확도 개선을 위해 모델 구조를 변경하면 , qps, 처리속도, memory 크기로 인해 새로운 문제가 발생해서 서비스 출시 후에는 model을 최대한 안건드리고 데이터를 더 건드리는 경우가 많다.
데이터 관련 업무가 왜 이렇게 많을까?
1. 상대적으로 어떻게 하면 좋은지에 대한 정보가 알려져 있지 않다.
- 맨땅에 해딩하는 경우가 많다.
왜?
출간되는 논문의 비율
학계에서 데이터를 다루기 힘든 이유
1) 좋은 데이터를 많이 모으기 힘들다.
2) 라벨링 비용이 크다.
3) 작업 기간이 오래 걸린다.
2. 데이터 라벨링 작업은 생각보다 많이 많이 어렵다.
데이터가 많다고 모델 성능이 향상 올라가는 것은 아니다.
1) 라벨링 노이즈를 상쇄할 정도로 깨끗한 라벨링 데이터가 많아야 한다.
라벨링 노이즈: 라벨링 작업에 대해 일관되지 않음의 정도
잘못된 작업의 라벨링 결과를 학습 시 무시하게 하려면 적어도 깨끗이 라벨링 된 결과가 2배 이상 필요
적은 데이터가 깨끗해도 골고루 있어야지 너무 유사한 데이터만 있으면 안 된다.
샘플 수가 적을 수록 라벨링 노이즈가 큰 이유
샘플이 희귀한 케이스일수록 실수하기 좋다.
예시)
위에서 아래로 내려갈 수록 어려운(희귀한) 케이스
이에 따라 엄격하고 모든 경우를 고려한 일관된 가이드라인이 필요하다.
골고루 즉 희귀 케이스도 담아야 하지만 동시에 라벨링이 일정해야 한다.
즉 특이한 샘플을 특히 신경써서 모으기도 해야하고, 깨끗한 라벨링을 얻기 위하여 라벨링 노이즈를 제거해서 특이한 경우를 어떻게 처리할지에 대한 라벨링 가이드가 필요하다.
작업의 효율화
해당 테스크에 대한 경험치가 잘 쌓여야 한다.
결국 도메인 지식이 많을 수록 예외 경우에 대해서 미리 인지할 수 있다.
테슬라의 경우 자율 주행에서 예외 경우를 트리거라 지정하고 221가지를 정의해 놓고 세심히 관리한다.
즉, 라벨링은 interative process이다. (Data Engine, FlyWheel이라 부른다.)
IDE (Integrated Development Environment)
Software 1.0: Visual Studio 등
Software 2.0의 IDE는 아직 없지만, 필요한 기능은 나열해볼 수 있다.
- 데이터셋 시각화
- 데이터/ 레이블 분포 시각화
- 레이블 시각화
- 데이터 별 예측값 시각화
- 데이터 라벨링
- 라벨링 UI
- 태스크 특화 기능
- 라벨링 일관성 확인
- 라벨링 작업 효율확인
- 자동 라벨링
- 데이터셋 정제
- 반복 데이터 제거
- 라벨링 오류 제거
- 데이터셋 선별
- 어떤 데이터를 모델 성능 향상을 위해서 라벨링해야 하나?
해당 작업은 필수인데, 도와줄 수 있는 기능이 있지 않을까?