잡담 (왜 ML은 실패하는가 / Auto ML / Declarative ML까지)

 

최근에 친구와 나눈 대화로 시작해 보겠습니다.

제 친구는 미국 대기업에서 일하고 있는 7년차 데이터 엔지니어인데요. data pipeline을 구축하는 것이 사실 ML보다 사실 더 쉽다고 말하더군요. 그러면서 performance metric 차원에서 ML보다 더 측정이 쉽다라고 이야기 하더라구요. 그리고 ML 프로젝트 대부분이 사실 기대치보다 잘 perform하지 못한다는 점도 덧붙였습니다.

사실 이 친구는 좀 극단적으로 이야기한 측면이 없지 않아 있습니다. 하지만, 일부 맞는 말도 있었는데요.  최근 KDNugget 설문조사에 따르면 대기업에서 일하는 데이터 사이언티스트의 75%가 대부분의 모델이 실제 production에 도달하지 못했다고 말했습니다. 

이유에 대해서 각자 생각해보다가 저희들이 종합적으로 내린 결론은 총 3가지 이유 때문입니다: 

1) Raw data is never good enough.

큰 회사라고 한다면 사실 데이터는 어디에나 존재합니다. 하지만, source가 각기 다른 데이터들을 한데 모아서 분석/모델링 가능한 수준까지 끌어올리는 것은 꽤 쉽지 않은 이슈입니다. 데이터 사이언티스트는 이 'make data useful'하게 만드는 과정 속에서 많은 어려움을 겪습니다.

2) Your first model is highly likely not a good model.

첫 번째 모델을 구축하는 것은 어렵지 않지만 비즈니스에서 주어진 문제를 해결하는 솔루션을 반복하고 구축하는 것은 어려운 문제입니다. iteration에는 많은 시간과 엔지니어링 리소스가 필요하며 일부 모델은 프로토타입 단계까지만 유효한 경우도 많습니다.

3) Good model couldn't be implemented in the production level

데이터 사이언티스트는 소프트웨어 엔지니어와는 사뭇 다른 skill sets와 toolbox를 가지고 있습니다. ML 모델과 프로덕션 환경의 격차는 Jupyter 노트북의 모델이 production environment에 진입하지 못한 가장 큰 이유 중 하나입니다.

오늘날 기업은 ML R&D에 돈을 쏟아붓는 것이 아니라 ROI를 보고 싶어합니다. 데이터 사이언티스는 또한 ML workflow에서 조금이라도 더 빠르게 iterate할 수 있는 방법을 모색하기 위해 노력하고 있구요.

 

 

데이터 사이언티스들은 보통 ML 솔루션을 구축할 때
모델을 improve하기 위해 보통 다음 두 가지를 시도하고 있습니다.

1) 데이터 과학자의 커스텀 "레고" 작품 이슈

보통 유사한 활용 사례를 보면 이전에 만든 일부 스크립트를 재사용합니다. 데이터 사이언티스트들은 대부분 자신만의 "레고" 조각들을 가지고 있는데요. (저도 마찬가지... ㅎㅎ) 같은 문제를 두 번 해결하려고 하지 않습니다. 누구에게나 시간은 다 소중하니까요. 하지만, 주의해야 할 점이 있습니다. 이 스크립트는 보통 팀과 공유되거나 peer-reviewed 되지 않는 경우가 많습니다. 따라서, 경우에 따라 가독성이 너무 떨어진다거나 (팀에게 공유하기 힘든 상태) 또는 이 스크립트가 맞는지 테스트가 안된 경우도 많구요.

일전에 친구가 computer vision 관련 프로젝트를 진행하고 있을 때, 같은 팀의 동료가 자신이 했던 비슷한 프로젝트에 대해 TensorFlow의 스크립트를 친구와 공유했다고 합니다. 그래서 그 친구는 이번 프로젝트는 쉽게 할 수 있겠다고 생각했다고 해요. 하지만, 동료의 코드를 보니까 그걸 고칠 바에는 차라리 내가 새로 작성하는게 더 빠르겠다라는 사실을 깨달았다고 합니다 ㅎㅎ ... 

나만의 "레고" 작품을 만드는 방법은 내 커피를 만드는 방법과 유사하다고 생각합니다. 원하는 것은 무엇이든 할 수 있지만, 프로세스를 확장하고 자동화하는 것은 역시 쉬운 문제가 아닙니다.

AutoML은 어떨까요?

2) AutoML에 현재 수준에선 한계가 있다

많은 사람들이 AutoML에 대해 들어보았을 것입니다. 하지만, 정말 사용해 보신 적이 있나요? 다음은 UC 버클리의 한 연구원이 작성한 논문을 가져와 보았습니다. 

"작업이 너무 복잡해지면 Auto-ML이 고장납니다. (중략) 최고의 결과를 얻지 못할 것입니다. 우리가 수행하는 작업에 문제가 발생하면, 대부분 역시 수동 (manual)로 전환합니다. ML은 이러한 경우에 어떤 종류의 성능을 기대해야 하는지 직관을 얻을 수 있는 좋은 방법입니다. 그런 다음 이를 능가하려고 합니다."

- AutoML은? 기계 학습 워크플로에서 자동화의 역할 이해​

 

전에 친구가 computer vision 관련 프로젝트를 진행하고 있을 때, 같은 팀의 동료가 자신이 했던 비슷한 프로젝트에 대해 TensorFlow의 스크립트를 친구와 공유했다고 합니다. 그래서 그 친구는 이번 프로젝트는 쉽게 할 수 있겠다고 생각했다고 해요. 하지만, 동료의 코드를 보니까 그걸 고칠 바에는 차라리 내가 새로 작성하는게 더 빠르겠다라는 사실을 깨달았다고 합니다 ㅎㅎ ... 

나만의 "레고" 작품을 만드는 방법은 내 커피를 만드는 방법과 유사하다고 생각합니다. 원하는 것은 무엇이든 할 수 있지만, 프로세스를 확장하고 자동화하는 것은 역시 쉬운 문제가 아닙니다.

 

저도 비슷한 경험을 가지고 있는데요. 모델링을 어디서부터 시작해야 하나를 생각해 봤을 때 어떤 기준점이 필요하고, 그 기준점을 빠르게 얻기 위해 Auto ML을 시도했지만, 저는 사실 단 한 번도 AutoML 모델을 실무에 사용해 본 적은 없습니다. 그리고 제 주변에서도 여태 Auto ML을 실제 프로덕션 단계에서 사용해 본 적이 있는 사람을 아직까지 본 적이 없는 것 같아요.

사실, Auto ML이 정말 잘 되면 얼마나 편하고 좋을까요? (저 같은 사람은 이제 뭘 해야 하나요...) 좀 더 많은 사람들이 쉽게 모델을 구현할 수 있을테니까요. 하지만, Auto ML은 간단한 명제와는 달리 블랙박스인 것이 현실입니다. 데이터 사이언티스트는 항상 simplicity를 추구하지만, flexibility를 놓치고 싶지는 않을테니까요. 

Auto ML은 마치 이미 제조가 완료된 커피를 따라 마시는 것과 같습니다. 커피이긴 한데, 내 취향에 맞게 커스텀을 할 수 없다는 단점이 존재합니다. 꽤 좋은 모델일 수는 있겠으나, 내가 '가장' 원하는 커피는 아닌 것이죠.

항상 우리는 내 입맛에 딱 맞는 커피를 남이 타줬으면 좋겠는 마음을 가지고 있습니다 ㅎㅎ 즉, 우리는 모델에 대한 variety나 control도 가지고 싶으면 어떡해야 할까요? 

커스텀이 잔뜩 들어간 스벅 주문...

 

그러다 최근에 Declarative ML에 대해서 알게 되었습니다. 여러분은 혹시 들어보신 적이 있으실까요? Declarative ML은 ML 알고리즘의 사용을 단순화하기 위해 ML 보다 한단계 높은 수준/퍼포먼스를 목표로 합니다. 그리고 프레임워크는 데이터의 타입과 무관합니다. 즉, 텍스트, 이미지, 오디오, 테이블 등에 대해 동일한 프레임워크를 사용할 수 있다는 것입니다. (Declarative ML aims at a high-level specification of ML tasks to simplify the usage of ML algorithms. What’s more, the framework is independent of the data types. It means that the you can use the same framework for texts, images, tabular, audio, etc.) Declarative ML이 좀 더 궁금하시다면, 다음 링크를 통해 확인하실 수 있습니다: https://arxiv.org/abs/2107.08148

Declarative Machine Learning Systems

 

아직도 이게 신기술(?)처럼 보인다면, 사실 우리는 이미 오늘 아침에 스벅 앱을 통에서 이 선언 작업 (declarative work)을 했습니다. 우리가 스벅 앱을 켜고 우리가 가장 좋아하는 커피 한 잔을 마시기 위해서 여러 옵션을 더하거나 빼고 결제를 하면 원하는 음료를 얻을 수 있죠. 참 simple 하고 flexbile 하지 않나요?

사실 Declarative ML에 대해서 처음 들으셨을 수도 있지만 사실 이미 Apple, Meta, Uber 같은 회사에서 채택했습니다. 예를 들어, Apple은 데이터 사이언티스트와 개발자가 코드를 작성하지 않고도 ML/DL을 구축하고 운영할 수 있도록 Overton을 개발했죠. 데이터 인풋, 보델 작업 및 이러한 워크플로를 지원하는 데이터 흐름을 표현하는 스키마도 제공하구요. 그런 다음 Overton은 TensorFlow 또는 Apple의 CoreML 과 같은 프레임워크에 대한 스키마를 compile하고 그 스키마를 support하는 올바른 architecture와 hyper parameters를 탐색합니다.

그럼 우리들의 사이드 프로젝트에도 Declarative ML을 사용할 수 있을까요? Apple과 Meta에서 만든 Declarative ML은 내부용이지만 Uber AI는 Ludwig라는 오픈소스 Declarative ML 프로젝트를 제공하고 있습니다: https://github.com/ludwig-ai/ludwig

GitHub - ludwig-ai/ludwig: Data-centric declarative deep learning framework

 

어떻게 작동되는 지 한 번 예시를 통해 파악해 볼게요. 간단한 텍스트 분류 예시입니다.

Language model이 처음이라면 아래 이미지와 같은 구성으로 간단하게 시작할 수 있습니다.

이전에 NLP에 대해서 알고 있는 경우, Declarative ML을 사용하여 PyTorch 또는 TensorFlow 코드를 작성하지 않고 더 빠르게 학습하고 반복하려는 경우에는 specification을 더 추가할 수 있습니다.

여러분이 만약 최신 모델을 사용하고 싶은 researcher라면 Ray를 사용하여 distributed training을 지원한다고 하네요. 더 큰 규모의 클러스터로 확장해서 GPU에서 train 할 수도 있습니다.

 

앞서 Declarative ML이 input data의 종류를 가리지 않는다고 말했는데요. 도대체 Declarative는 어떻게 이를 처리하기에 이게 가능한 걸까요? Ludwig는 ECD (Encoder-Combiner-Decoder) 아키텍쳐를 사용한다고 합니다. 다양한 유형의 데이터를 encoding하고 combine 합니다. 이후, decoder로 이동시켜 prediction을 하는 것 같습니다.

 

Declarative ML이 시사하는 점은 무엇일까요? 데이터 사이언티스트에게 data preprocessing은 항상 산과 같습니다. 하지만, 이 부분에서 우리의 시간과 노력 및 골치아픔을 아낄 수 있다면 더이상 이미지, 텍스트, 테이블 형식 등의 데이터를 불러오기 위해 다른 스크립트를 만들 필요가 없어지겠죠. 단지, config file에서 데이터 유형만을 지정해 주기만 하면 되니까요. 이 config file을 이용하면, model iteration process를 표준화하고 데이터 사이언티스트 팀 내에서뿐만 아니라 데이터 엔지니어와도 협업이 좀 더 수월해질 수도 있을 것 같습니다. ML beginner부터 researcher까지 사용할 수 있지 않을까 내심 기대해봅니다. 좀 더 다양한 사람들이 쉽게 ML/DL 모델을 만들고 사용해 볼 수 있길 기대해 봅니다.

 

 

 

 

 

 

 

 

#영어이력서 #영문이력서 #이력서 #Cover #coverletter #resume #레주메 #데이터분석 #데이터애널리스트 #미국데이터분석석사 #미국석사 #데이터과학자 #네트워킹이벤트 #GMAT #링크드인 #미국데이터분석 #데이터사이언스 #미국 #GRE #해외취업 #데이터사이언티스트 #미국현지취업 #데이터분석석사 #글래빈 #미국데이터사이언티스트 #글래빈미국 #글래빈미국데이터사이언티스트 #브라이언 #브라이언미국데이터사이언티스트 #스테이시미국데이터사이언티스트 #미국대학원 #해외취업마스터 #미국생활 #데이터사이언스석사 #미국유학생 #유학생 #미국데이터 #애널리틱스석사 #데이터석사 #미국데이터석사유학 #뉴욕직딩 #미국유학 #미국직장인 #미국취업 #미국현지취업 #prerequisites #선수과목 #미국대학원선수과목 #리트코드 #테크니컬인터뷰 #코딩인터뷰 #leetcode #커피챗 #대학원진학컨설팅 #데이터분석대학원 #데이터사이언스인터뷰 #데이터분석가인터뷰 #datascientistinterview #datascientisttechnicalinterview