이번 주는 추석 연휴 때문에 이틀 밖에 없어서인지 특강으로만 구성되어 있다. 마음 편하게 들으면서 알아두면 좋을 내용들 위주로 정리하였다.
서비스 향 AI 모델 개발
강연자 : 이활석 Upstage CTO님
서비스에서 사용되는 AI vs 연구에서 쓰는 AI
일반적으로 수업/학교/연구에서는 정해진 Dataset/Evaluation 방식 에서 더 좋은 Model을 찾는 걸 목표로 한다.
서비스 개발 시에는 Train,Test dataset / Inference 가 없다.
서비스 요구사항으로부터 직접 데이터셋을 정의해야한다.
- 요구사항에 따라 데이터셋의 카테고리를 나누고, 각각 수량을 어떻게 할 지 정해야 한다.
- 수식을 예로 들면, 수식의 수준이 초중고, 대학교 수준으로 다양하게 나뉠 수 있고, 프린트냐 손글씨냐로 나뉠 수 있고, 낙서, 그림자 등 여러 변수들도 카테고리로 나눌 수 있다. 적절한 판단이 필요
데이터셋을 정의했을 때, 어떤 데이터셋을 모으고 처리하는 게 좋을 지 판단해야 한다.
- 수식의 경우, 수식 하나가 담긴 이미지를 사용할 수도 있지만, 수식 여러 개가 담긴 이미지를 사용해 여기서 각각의 수식을 검출해 활용할 수도 있다. 이 경우 수식 이미지 형태 제한이 좀 느슨해져서 데이터셋을 모으기 편해진다.
각각의 AI 모델 별로 성능을 판단하고, 데이터셋에 맞게 출력을 정의하고 이에 맞게 모델을 설계해야 한다.
- 영역 검출의 경우 직사각형의 좌표뿐만 아니라, 회전된 경우를 가정해 회전값도 출력하거나, segmentation처럼 영역에만 1로 masking할 수도 있다.
입력에 대한 출력을 하나의 모델로 구현하기 어렵다면, 여러 모델을 조합해 볼 수 있다. 이 경우 사용한 여러 모델 각각의 입출력을 정의해야한다.
- image to symbol의 경우 모델 하나로는 어려울 수 있으니, 검출, 인식, 정렬, 변환 등 과정을 나눠 모델로 만들 수 있고, 이 때 각각의 입출력을 정의해야 한다.
모델 설계를 하려면 데이터셋이 필요하고, 데이터셋은 모델에 맞춰져야 하니, 결국 데이터셋과 모델 설계는 각 과정의 반복을 통해 진행할 수 있다.
데이터셋 작업은 외주 업체에 맡기는 경우도 많은데, 이 경우 작업 가이드, 단가, 수량 등을 고려하여 진행하여야 한다.
테스트 데이터셋은 학습 데이터셋의 일부를 사용할 수 있지만, 테스트 방법은 따로 정의하여야 한다.
개발 환경에서의 테스트(Offline test)와 실제 환경에서의 테스트(Online test)는 정의에 따라 굉장히 차이가 클 수 있으므로, 두 결과가 유사하도록 잘 설계하여야 한다.
- 대전게임에서 프로게이머를 따라하도록 학습했을 때, offline은 정확도가 높은데 online에선 완패를 해서 분석하니, 프로게이머는 스킬을 가끔 사용하여 모델은 스킬을 안 쓰는 것으로 예측하도록 학습해버린 것이었다. 잘못된 설계의 예시
Offline 모델은 완벽하지 않기 때문에 후보로서 모아두고, 이들을 모아 면밀 분석 후 서비스 출시 버전을 선택하는 게 위험도를 낮출 수 있다.
Online 환경으로 가면 사용하는 AI 모델을 서비스 시나리오에서 자동으로 정량 평가하고, 소비자의 평가나 피드백을 통해 모델의 개선 포인트를 파악해야 한다.
모델에도 처리시간, 목표 정확도의 요구 사항이 있다. 그리고 이들은 offline test, online test냐에 따라 목표가 달라진다.
- 처리 시간 : 입력으로부터 출력이 나오는 데 걸리는 시간, offline과 online의 경우에 따라 처리 시간의 기준이 달라진다.
- offline의 경우 이미지 입력 후 수식 정보가 출력되는 데 걸리는 시간이 처리 시간이라면, online에서는 이미지 촬영 후 수식 영역 정보가 출력 되는 데 걸리는 시간이 처리 시간이다.
- 목표 정확도 : 해당 기술 모듈의 정확도
- 신용카드 인식의 경우, offline의 경우 입력된 이미지 내 카드 번호/유효기간에 대한 edit distance가 정확도의 기준이 되지만, online의 경우 AI 모델의 결과값을 수정할 확률이 기준이 된다.
목표 qps는 queries per second의 약자로, 초당 처리 가능한 요청 수를 의미한다. 이는 장비를 늘리거나, 처리 시간을 줄이거나, 모델 크기를 줄임으로서 올릴 수 있다.
- 모델 크기가 줄어들면 GPU에 올라가는 모델 수가 그만큼 증가하여 qps를 상승시킬 수 있다.
모델이 어느 하드웨어에서 serving되는지, cpu or gpu, local or cloud에 따라 모델 요구사항이 달라진다.
서비스에서 사용되는 AI 모델을 개발하기 위한 바람직한 조직 구성
각각 Modeling, Data 작업, Tool 개발을 담당하도록 분담하는 것이 좋다.
그리고 이를 총괄하는 Manager가 필요하다.
만약 serving까지 필요하면, serving하기 위한 작업을 담당하는 사람이 필요하다.(강의에서는 Model engineer라 표현하셨다.)
- Mobile, GPU등의 환경에서 구동하기 위해 pytorch를 TFLite, TensorRT 등으로 변환
- 변환하기 힘든 경우 직접 custom layer를 구현하여 재학습
- Distillation, quantization등의 경량화 작업
- gpu 고속 연산을 위한 cuda programming, 아예 c/c++로 변환도 함
모델링으로 싶은 분은 다른 영역(ML engineer, tool 개발 등)부터 시작해 천천히 모델링에 익숙해진 후 modeler로 전환하는 것을 추천하셨고, 반대로 modeler는 모델링 분야가 AutoML등으로 자동화 되고 있으니 다른 분야로 역량을 늘리길 바란다는 말씀도 해주셨다.
특히, AI 기술 트렌드에 민감해야 한다.
캐글 노하우
강연자 : 김상훈 Upstage data scientist님
우승하기 위해 필요한 것
- 파이프라인의 빠른 반복
- 아무래도 파이프라인을 빠르게 반복하며 개선하는 게 상위권을 위해선 유리하고, 이를 위해 좋은 장비가 필요하다...
- 경쟁자들도 아주 많은 시간을 투자하므로 우리 또한 그렇게 해야 한다.(강연자님 기준 대회 기간 2~3달 동안 평일 4시간, 주말 8시간)
- 본인만의 기본 코드
- 어떤 대회를 가든 기본 코드에서 일부만 수정하면 되고, 이를 통해 빠르게 파이프라인을 구축할 수 있고 실수가 적어진다.
- 점수 개선 아이디어
- 캐글의 Notebook 탭이나 Discussion 탭을 참고하여 좋은 정보를 얻을 수 있다.
- 탄탄한 검증 전략
- 최종 순위 하락을 위해 필요하다.
- Training score와 Test score의 차이를 줄이는 것을 검증 전략이라 한다.
- k-fold validation set을 활용할 수 있다.
- 아무리 검증 전략을 잘 세워도 overfitting의 가능성이 있으므로, local CV와 public LB가 함께 올라가는 방법을 선택하는 것이 안전하다.
- Ensemble 사용
- single model보단 거의 항상 더 좋은 성능
- 코드 관리
- v1, v2, v3... 순서로 개별 폴더로 만들어 코드 관리
- 버전 별로 전처리 된 데이터, 모델을 저장할 수 있고, 이를 통해 여러 버전의 모델을 ensemble하기 좋다.
- github도 좋지만 잦은 rollback이 필요하고, 중간 파일 저장 이슈가 있다.
AI + ML과 Quant Trading
강연자 : 구종만님(종만북의 그분)
퀀트 트레이딩 분야에 대한 설명과 분야의 특성 때문에 딥러닝이 어렵다는 점 등을 설명 해주셨다.
이론적으로 알아둬야 할 내용은 많지 않아 따로 정리하지 않았고, 가볍게 들었다.
내가 만든 AI 모델은 합법일까 불법일까
사회에선 내가 풀고 싶은 문제에 적합한 데이터는 내가 직접 만들어야 한다. 이 경우 합법적인 데이터를 사용해야 하는데, 이런 데이터를 구하기 쉽지 않다.
그리고 현재 저작권법은 AI 모델을 고려하고 있지 않기 때문에, 위반 사항이 많아 잘 체크해야 한다.
