빠른 개발을 위해서 깨달은것

2021-10-30  수정 

2021-10-31 수정

ML workflow 관점에서 볼 때 , 저의 문제점은 단 방향 개발만 가능하고 , 순환적인 개발흐름(?) 이 익숙하지 않다는 것을 깨달았습니다.

ML workflow에서 데이터수집, 가공 , 모델개발, Train, Test (배포,문제정의는 일단 제외하겠습니다.) 이 흐름이 한방향으로 진행되고 끝나는게 아니라 , 순환적인 구조로 계속 반복이 됩니다.
후진 없이 직진만 하는것은 , 숙달이 되었다고 생각합니다.
하지만, 뒤로 갔다가 앞으로 갔다 이를 계속 반복하는 과정에서 버벅거림이 있다는것을 느꼇습니다.

Boostcoure KLUE RE, MRC를 진행하면서 , 두번 다 비슷하게 baseline과 다른 모델을 시도하는 역할을 하게 되었고, RE에서는 어느정도  그 시도가 부분 성공하 였고 , MRC에서는 정한 기한내에 완료하지 못했습니다.
MRC의 generation based 모델에 대해  잘 몰라서 못했다 라고 생각도 할 수 있지만 , 모델 전체를 scratch 부터 짜는게 아니라, pretrained block을 가져다 쓰는것이기 때문에 근본적인 원인이 있다고 생각이 들었습니다.
여러 자료들을 찾아보았고, 현재 저의 문제점이 무엇인지 나름 결론을 내려봤습니다.

 

1.남이 작성한 Baseline코드임에도 불구하고, process flow를 visualization 해서 요약하지 않았다.
 

  
BoostCourse를 하기전에 는 , 어떤 project를 하게 되면 저 스스로가 scratch 부터 짜는게 너무 당연했기에 , 자신이 만든 코드의 흐름을 잘 알고 있어서, 이러한 필요성을 못느꼇습니다. 
회사나 혹은 연구실 혹은 다른 단체 에서 일을 하게 되면, 생산성을 위해 기존의 코드를 가져다 쓰는 경우가 많습니다. 사람은 배운것을 직접 해보고 ,  약한 부분을 공략하는 등의 과정에서 단기기억이 장기기억으로 바뀝니다. 그저 순간의 이해를 위해서 읽는 과정으로 그 순간의 단기기억이 장기기억으로 전환되지는 않을거라 생각합니다.
시각화를 하면서 눈으로 보고, 요약하고 , 등등의 과정을 통해 장기기억으로 전환되고,  더 중요한 점은 기록은 자기 자신이 해놓았기 때문에, 시각화된것을 보면서 , process flow가 더 잘 떠오를 것이다 라고 생각이 듭니다.

 

 

2.Refactor을 해야하는지 말아야하는지 , Pretrained Model의 이점을 잘 누려야 한다.

 

 

RE task에서는 Refactoring이 필요가 없이 block 단위로 모듈 구성이 되어있어서 , block을 갈아 끼우듯이  , pretrained_model을 갈아끼우듯이 개발했으면 됬습니다. preprocess , postprocess등의 과정이 바뀌어도 각 block단위로 해결하고 , 연결된 부분을 잘 고쳐주면 해결이 되었습니다.  하지만, MRC에서는 한가지 함수 안에 다른 여러 함수들이 nested 안에 정의되어 있었고 , DataSet Class, DataCollator Class를 이용해서 refactoring을 했더라면, 좀더 다른 모델들을 실험할때 빠른 실험을 할 수 있었을 것이다 라고 생각이 듭니다.
그리고, 다양한 모델의 실험을 전제를 하고 있었지만,
모델 교체를 할 때 어떻게 자연스럽게 할 것인가에 대해 고민을 잘 안해봤기 때문에 ,  물 흐르듯이 프로젝트를 진행하게 되어서 발생한 문제점이지 않나 싶습니다.

 

3. 처음부터 일정 계획을 세워본다음에, limit이 무엇인지 파악한다.

 

MRC task는 일정이 4주가 주어졌습니다. 대충 여유롭게 해도 되지 않아? 라는 안일한 마음가짐으로 프로젝트에 임했습니다. 사실 , 이 BoostCourse는 공부하는게 주 목적이기 때문에, 이렇게 해도 별로 상관은 없다고 생각합니다.

하지만, Engineer라는 관점에서 본다면 얘기는 좀 다릅니다. GCP professional certificate를 요즘 공부중인데 ,거기서는 선택지를 항상 1개로 좁히는 것을 전제로 설명을 합니다.  engineer들은 항상 결론을 1가지로 좁힐 필요가 있습니다. 이렇게 하는게 Optimal한데 ? 보다는 이러한 limitations으로 인해 이러는게 효율적이다. 기존의 것을 어떻게 잘 활용할 수 없을까? 와같은 decision tree를 잘 정해놓는 사고방식이 필요합니다. limit이  파악이 되면 필요한것 , 필요하지 않은것 .   필요한것중에서 현재 가능한것, 불가능한것, . 불가능한것중에서 시간을 들여서 가능한것으로 바꿀 수 있는것 의 계획을 세워놓고 프로젝트를 진행해야 한다고 생각합니다. 물론, 프로젝트 진행 중에 바뀔 수도 있습니다. 하지만, 미리 알고 하는것과 모르고 하는것의 차이는 분명히 있습니다.(어떤 사람의 도플갱어가 존재한다고 할 때 , 두 사람이 시험범위를 알고 공부하는것과 시험에 나오는것만 공부하는것의 성적차이는 여러 학습 연구에서도 증명되었습니다.) 문제 정의를 ai업계에선 많이 강조합니다. 하지만, 그 뿐만 아니라 Limitation의 정의도 많이 중요하다 생각합니다.