11 Fri

현업 실무자에게 배우는 Kaggle 머신러닝 입문

실제로 회사에서 진행하는 머신러닝 업무 프로세스

• Raw한 데이터로부터 수집, 정리, 정제까지 해야하는 경우가 대부분

  • 데이터만을 보고 중간에 의사결정이 언제든 바뀔 수 있다

    • 프로젝트 중단도 가능

  • 따라서, 중간 보고가 필수적이다

• 모델링 결과에 대해 비즈니스 적으로 의미가 있어야 하며 이를 도메인 전문가들에게 설득시켜야 한다

  • 도메인 전문가의 제대로 된 동의를 얻지 못한 모델은 본격적으로 사용화되기 어렵다

• 개발한 ML 모델이 상용화 되는 것은 또 다른 문제이다. 개발 이슈가 아주 많기 때문에 많은 지원이 필요하다

가장 중요한 것은 데이터, 두 번째로 중요한 것도 데이터

• 애초에 데이터가 부적합해서 시작하지도 못하거나 지연되는 경우가 매우 매우 아주 빈번히 많다

  • 기획의 요구사항을 충족시키는 데이터나 데이터 feature가 raw데이터를 직접 보니 없는 경우

  • 이미 존재한다고 생각했던 데이터 feature가 타 부서 입장에서는 중요하지 않은 feature여서 제대로 개발되지 않은 경우

  • 데이터 feature는 존재하나 계속된 코드 버전업으로 인해 데이터 형태와 값이 계속 바뀌어 온 경우

• 수집한 데이터에서 발생할 수 있는 문제

  • 일관성 없는 데이터

  • 예외 값들에 대한 해석

    • 0또는 -1, None, N/A, Nan에 대한 의미 파악

  • 데이터 값이 밀림

  • 중복

• 데이터 전처리 중에 발생할 수 있는 문제

  • 전처리를 위해 하나의 파일이 아닌 여러 개의 파일을 참조하고 해석해야 하는 경우

  • Naive 하게 구현하면 한달~1년이 넘는 처리시간이 걸릴 수도 있다

• 데이터 관련 문제는 반드시 있을 수 있음을 미리 인지할 것

Kaggle/데이콘과 다르게, 실제 업무에서 중요하게 여기는 것은?

• 캐글/데이콘 등의 데이터 경진대회는 성능 지표를 제일 중요하게 여긴다

  • Accuracy, F1-score

  • 성능 지표를 올리기 위해 마지막까지 경쟁이 치열

• 실제 업무에서는 0.05 ~ 0.1 정도의 성능 지표 차이는 결코 중요하지 않다

• score 0.05를 올리는 것 보다 유용한 결론들이 더 많은 것이 중요하다

  • 유용한 결론들은 비즈니스나 의사결정에 도움이 되는 데이터 분석 및 모델링 결과를 의미

  • 어느 정도 사용할만한 실사용 성능이 나올 때 까지는 성능 지표를 개선하지만 그 이후에는 인사이트 분석에 집중

  • 이 과정에서 ML 모델과 비즈니스를 잘 연관시켜 설득/발표하여야 하는데, XAI가 많이 사용된다

    • XAI : eXplainable AI, 설명 가능한 인공지능

• 두 경우, 다 모델의 강인함은 매우 중요하다

  • 강인함 : 어떤 데이터셋에 적용하든지 준수하고 안정적인 성능

  • 따라서 검증에 노력을 많이 기울인다.

머신러닝 엔지니어, 일잘러로 거듭나보자

• 데이터 수집 및 처리 과정에 대해 Data Engineer와 함께 이야기하자

  • 머신러닝 과정에서 필요한 부분을 미리 조율할 것

  • 때로는 아이디어도 제안 가능

• 머신러닝은 문제 정의에서부터 출발한다. 문제를 어떻게 정의하느냐에 따라 풀어가는 방향이 달라진다.

  • 문제 정의가 잘못되면 이후의 접근법도 쓸모가 없어지는 경우 많다

• 머신러니으이 결과 모델이 비즈니스적으로 어떠한 의미를 가지는지, 처음부터 고민하자

  • 제대로 된 문제 를 잡더라도 비즈니스적으로도 의미가 있어야 성과 라고 할 수 있다.

• 다양한 모델링 및 기법 적용을 많이, 빨리 해야한다. 그리고 이를 잘 공유하고 방향성을 협의해야 한다

  • 머신러닝 모델링은 중간 결과이지만 다른 동료들의 업무와 의사결정에 큰 도움이 되는 경우가 많다 => 공유할 것

더 똑똑하게 일 잘하는, 머신러닝 코드 만드는 방법

• 전처리 코드를 1회용으로 짜지 말고, 조금이라도 고민하여 쓸모 있게 짜보기

  • 반대로 너무 처음부터 완벽한 코드를 짜려고 하면 안된다

  • 전처리 코드는 1회성인 부분도 상당부분 존재하기 때문이다

    • 소 잡는 칼을 닭 잡는 칼로 쓰지 말기

• 데이터 수집, 전처리를 많이 해 보면, 어느 정도 반복되는 패턴이 보이는데, 이것들을 모듈(라이브러리)화 하면 좋다

  • 보통 Jupyter Notebook에서 프로토타이핑을 하고

  • 완벽하게 모듈화 할 때는 Python IDE에서 개발한다

• EDA 및 시각화 코드를 짜는 경우에도 고민해서 코드를 짜고, 반복해서 발생하면 모듈화 한다

  • 한번 잘 만들어두면 feature나 컬럼명만 바꾸어서 사용해도 되는 경우가 아주 많다

  • 계속 발전시킬 수도 있다

• 조금씩 쌓이는 재사용가능한 코드 / 모듈들은 모든 업무를 더 빠르게 처리할 수 있게 해준다

  • 재사용 가능한 모듈들이 쌓여있는 A 엔지니어와 그렇기 않은 B 엔지니어의 생산성 차이는 매우 크다

• 학습을 수행하는 Training 코드는 꾸준히 사용하게 될 가능성이 높으므로, 미리 이를 염두해두기

  • 바뀌는 주요 변수들 : Dataset, Epoch, Validation N-group, Model, Parameters, Features, etc

• Training과 Validation, Parameter Optimization은 무수하게 많이 하기 때문에 반복작업에 대해서는 자동화 할 수 있는 부분은 자동화 하기

• 이미 만등러진 좋은 라이브러리나 프레임워크가 있을 가능성이 크므로 직접 개발하기 전 꼭 리서치 해보기

• 가장 바람직한 구조는 데이터 - 머신러닝 훈련 - 검증 & 최적화 - 시각화 의 연속적인 Pipeline 을 자유자재로 뗏다 붙였다 할 수 있는 유연하게 수정이 가능한 코드

  • 업무 초반 보다는 프로젝트 서너개를 완료했을 무렵부터 고민해보기

가장 몸 값이 비싼 Role, 역량이 무엇일까?

• DS/ML/SW End-to-End Engineer

  • Data Science, Machine Learning, SW개발에 대해 모든 과정을 이해하고 있는 인재

• DS/ML Competition Winner, Optimization Professional

  • Optimization 관점에서 남들과 다른 탁월함을 보여줄 수 있는 인재

• Machine Learning, Product S/W Engineer

  • 머신러닝을 단순 연구로만 수행하는 것이 아니라 실제 제품에 이를 적용하고 운용해본 경험이 있는 인재