created: 2023-05-11 19:54 modified: 2023-05-11 19:54 title: Write Here tags: (default: [])

• tag1
• tag2 featured: false published: false

복잡한 모델 또는 기술이 능사는 아니다.

비즈니스는 그런걸 신경쓰지 않는다.

비즈니스 부서들은 모델의 디테일따위 관심이 없다. 당신이 Naive Bayes를 쓰던 Random Forest를 쓰던 비즈니스 목표를 달성만 해주면 된다. 우선 빠른게 좋다. 데이터 모델링의 특성상 정확도를 완전히 담보하기는 어렵기 때문에 데이터 과학자가 전체 개발일정을 단축시킬 수 있다면 모두에게 좋다.

그리고 모델이 복잡하면 설명하기 어렵다. 그리고 개선하기도 어렵다. 매번 비즈니스 미팅에 가서 모델을 설명하고 싶지 않다면 최대한 설명가능성을 고려해야 한다. State-Of-The-Art(SOTA)를 모두가 환호하고 좋아하지는 않는다.

이를 해결하고 싶다면 비즈니스 부서와 친하게 지내고 자주 대화하면서 데이터과학자로서 생각하는 가설이 중요한지를 확인하는게 좋다. 그리고 데모를 만들어서 새로운 기능을 자주 보여주면서 작은 의사결정이 쌓여서 큰 의사결정이 되도록 하는게 좋다. 그러면 최대한 방향성을 유지하면서 성과를 낼 수 있을 것이다.

모델의 복잡도가 성능을 보장해주지 않는다.

모델을 잘, 복잡하게 만들면 성능은 오를 수 있다. 하지만 운영하기 버거울 정도로 리소스를 차지할 경우 배보다 배꼽이 클 수 있다. 종종 주니어들이 오버엔지니어링을 하는 경우가 있다. 열심히 만들고 쓰지도 못할 수 있다.

차라리 모델을 간결하게 만들고 재학습구조 및 개선을 위한 파이프라인에 더 집중하는게 좋다.그렇게 중요하지 않은 프로젝트라면 다른 프로젝트를 그 사이 진행해도 좋다. 성과를 내는 것이 중요하지 아주 완벽한 모델을 만드는 것이 중요하지는 않다.

복잡한 모델은 운영의 수고로움을 크게 늘린다.

이게 중요하다. 컨설팅이나 SI가 아니고서야 유지보수 등의 운영은 너무나도 중요하다. 지루할 수도 있지만 시간을 많이 잡아먹기 때문에 중요하다. 복잡한 모델을 통해 1%의 정확도를 올리면 좋지만 간단한 모델 대비 수 배의 운영공수를 요구할 필요가 있다.

비즈니스 부서는 데이터 과학자가 그간 쌓아온 신뢰자산을 바탕으로 모델 작업을 기다려준다. 다시 말해서 기다리는 시간의 일정 한계치를 넘어가면 데이터 과학자의 신뢰자산은 조금씩 깎이기 시작할 것이다.

MVP(Minimum Viable Product) 만들기

개발 전 요구사항 파악하기

파악해야할 요구사항은 간단하다. 목적과 기대하는 결과를 파악해야 한다.그리고 평가지표와 관련 평가지표를 물어볼 Contact Point(주관부서)를 반드시 알아야 한다.

적절한 문서화 꾸준히 하기

그림은 전문가, 비전문가 할 것없이 대화하기 적절한 시각화수단이다. 그림으로 간단하게 표현하고 지속해서 업데이트함으로써 커뮤니케이션에 드는 비용을 줄일 수 있다.

MVP Scope 바꾸지 말기

MVP가 만들어질 때까지 Scope를 바꾸는 것은 모델의 성공가능성을 크게 저하시킨다.  앞서 언급한 MVP의 요구사항부터 우선 빠르게 볼 수 있도록 Scope는 한번 확정되면 놔둬야 한다.  MVP가 만들어지면 그 때 가서 고쳐도 된다.

References

• Simplify Your Machine Learning Projects