ML 프로젝트를 계획하는 것은 일반적인 소프트웨어 엔지니어링 프로젝트를 계획하는 것과 다릅니다. ML 프로젝트는 특성상 비선형적이며 불확실성의 정도가 다릅니다. 이를 위해서는 반복적인 접근 방식과 실험적인 사고방식이 필요합니다
프로젝트 불확실성
최선의 접근 방식은 일반적으로 프로젝트를 시작할 때 명확하지 않기 때문에 초기 단계 계획은 어려울 수 있습니다. 이러한 내재적인 불확실성으로 인해 타임라인을 예측하기가 어렵습니다.
최근 진행된 Kaggle 경연에서는 ML 프로젝트의 불확실성을 잘 보여줍니다 대회가 시작된 후 처음 몇 주 동안 350개 팀이 참가했습니다. 일부 팀은 벤치마크 예측 품질을 35% 에서 65%로 높일 수 있었습니다. 그 후 2주 동안 문제를 해결하는 팀 수가 350개에서 1, 400개로 증가했습니다. 하지만 최상의 모델에서는 68%의 예측 품질만 얻었습니다
그림 3은 상당한 노력이 필요하지만 모델 품질의 이득은 최소한으로만 증가하여 ML 개발의 불확실성을 보여줍니다.
그림 3. 2주 동안 문제를 해결한 팀 수가 4배 늘어났지만 모델의 품질은 거의 동일하게 유지되어 ML 솔루션의 노력을 예측하기가 어려웠습니다.
즉, 각각 다양한 데이터 변환, 아키텍처, 초매개변수를 실험하는 1,000여 개의 팀에서 68% 의 예측 품질을 갖춘 모델만 생성했습니다.
업계의 예는 출력이 입력에 비례하지 않는 ML 프로젝트의 비선형성을 보여줍니다. 두 팀이 모델을 90% 예측 품질로 학습시키는 데 몇 개월이 걸렸습니다. 하지만 여러 팀에서 99.9% 의 예측 품질로 모델을 프로덕션용으로 준비하는 데 5년 넘게 걸렸습니다.
이러한 예시는 프로덕션에 즉시 사용 가능한 ML이 과학적 사고방식과 공학적 사고방식을 모두 필요로 하는 탐색적 프로세스임을 잘 보여줍니다.
실험적 접근 방식
대부분의 경우 ML 개발은 기존 소프트웨어 엔지니어링을 연습하기보다 실험 수행에 더 가깝습니다. ML을 사용하려면 다양한 기능을 테스트하고, 여러 아키텍처를 시도하고, 초매개변수를 적절하게 조정해야 합니다. 기본적으로 실험이 반드시 성공하는 것은 아닙니다. 따라서 실험용 프레임워크를 사용하여 계획하는 것이 가장 좋습니다.
일반적인 소프트웨어 엔지니어링 계획을 살펴보고 ML 프로젝트 계획과 어떻게 다른지 알아보겠습니다
소프트웨어 엔지니어링 프로젝트 계획
일반적인 소프트웨어 엔지니어링 계획에서는 요구사항을 정의하고, 구성요소의 개요를 설명하고, 작업을 추정하고, 작업을 예약합니다. 여기에는 명확한 솔루션 경로가 있습니다 예를 들어 엔지니어는 설계 사양을 충족하는 애플리케이션을 빌드하기 위해 완료해야 하는 작업을 매우 확실하게 알고 있습니다.
작업을 완료하는 데 걸리는 시간을 예측하면 유사한 프로젝트를 바탕으로 작업을 추정할 수 있습니다. 때로는 추정을 어렵게 만드는 알 수 없는 종속 항목이나 변경 요구사항과 같은 문제가 항상 발생하지만, 일반적으로는 명확한 솔루션 경로가 존재합니다.
반면에 ML 프로젝트에는 성공을 향한 확실한 경로가 없는 경우가 많습니다.
ML 프로젝트 계획
대부분의 ML 프로젝트에서는 시행착오 과정을 거치며 여러 접근 방식을 실험하여 가장 적합한 솔루션을 찾을 수 있습니다. 일반적으로 문제를 해결하려고 시도하기 전에는 문제에 대한 최적의 솔루션을 알 수 없습니다. 예를 들어 최적의 솔루션의 아키텍처는 간단한 선형 모델, 신경망 또는 결정 트리일 수 있습니다. 각 접근 방식을 시도해야만 최상의 솔루션을 찾을 수 있습니다.
이러한 모호함으로 인해 계획을 세우는 것이 어려워집니다. 앞서 설명한 것처럼 ML 프로젝트에 필요한 노력을 예측하기는 어렵습니다 문제 해결을 시도해야만 솔루션에 필요한 시간과 리소스를 더 잘 파악할 수 있습니다.
다음은 ML 작업 계획에 권장되는 전략입니다.
작업의 타임 박스. 작업을 완료하거나 특정 솔루션을 시도할 명확한 기간을 설정합니다. 예를 들어, 올바른 종류의 데이터에 액세스할 수 있는지 확인하기 위해 2주를 배정할 수 있습니다. 데이터를 얻을 수 있으면 2주를 더 지정하여 단순한 모델에서 ML 솔루션 실현 가능 여부를 확인할 수 있습니다. 간단한 모델이 실패하면 2주를 추가로 지정하여 신경망을 사용하도록 할 수 있습니다. 각 기간이 끝나면 문제에 리소스를 계속 적용하는 것이 가치 있는지 판단할 수 있는 자세한 정보가 제공됩니다.
프로젝트 요구사항의 범위를 좁힙니다. ML 솔루션이 유망해 보이지만 제품 또는 서비스에 중요한 기능은 아닌 경우 요구사항을 다시 지정합니다. 예를 들어 다음 분기의 작업을 계획할 때 매우 간단한 솔루션을 시도해 볼 수 있습니다. 그런 다음 이후 분기에 솔루션을 반복적으로 개선할 계획을 세울 수 있습니다. 장기간에 걸쳐 점진적으로 개선함으로써 ML 솔루션을 구현하는 것이 많은 팀이 영향력 있는 ML 솔루션에 도달한 방법이었습니다.
인턴 또는 신입 Google 직원 프로젝트. 인턴이나 누글러에게 ML 솔루션을 시도하도록 지시하고 안내하는 것은 결과를 알 수 없는 새로운 분야를 탐구하는 좋은 방법이 될 수 있습니다. 프로젝트가 끝나면 ML 솔루션에 필요한 노력과 추구할 가능성이 있는 접근 방식 또는 리소스를 다른 곳에 배치해야 하는지 여부를 더 잘 이해할 수 있습니다.
어떤 전략이든 빠르게 실패하는 것이 현명합니다. 가장 저렴하지만 가장 높은 효과를 얻을 수 있는 접근 방식을 먼저 시도합니다. 이 접근 방식이 효과가 있다면 좋은 솔루션을 찾은 것입니다 그렇지 않으면 많은 시간과 리소스를 낭비하지 않은 것입니다.
팀이 실험 실행을 경험하고 경험하면 실험에 필요한 노력을 더 잘 예측할 수 있으므로 보다 예측 가능한 계획을 세울 수 있습니다. 하지만 실험 결과는 거의 항상 알 수 없으므로 최적의 솔루션을 찾는 데 필요한 실험의 수를 미리 예측할 수는 없습니다.
실험적 사고방식으로 접근 방식을 계획하면 팀이 성공을 거둘 수 있도록 준비할 수 있습니다. 한 접근 방식이 막다른 골목으로 이어지는 경우 팀원들은 낙담하지 않고 막다른 길로 이끌 때 ML 솔루션을 찾는 과정의 일부임을 이해합니다. 무엇보다도 ML 개발의 근본적인 불확실성에 대해 이해관계자와 논의함으로써 보다 현실적인 기대치를 설정할 수 있습니다.
주의사항
여러 ML 접근 방식을 확률론적으로 계획하는 방법을 학습하려면 시간과 경험이 필요합니다. 프로젝트 계획을 자주 업데이트해야 할 수 있습니다. 팀이 여러 접근 방식을 실험하는 동안 지속적으로 진화하는 동적 문서라고 생각하세요. 다음과 같은 핵심 아이디어에 집중하면 성공 가능성이 높아집니다.
- 각 접근 방식의 비용과 성공 가능성을 추정합니다.
- 다양한 접근방식을 시도해 봅니다.
- 그간 얻은 교훈을 바탕으로 한 번에 하나씩 시스템을 개선해 나가세요.
- 실패에 대비합니다.
때로는 초기 접근 방식이 획기적인 발전으로 이어집니다. 누군가 데이터 생성 파이프라인 또는 학습-검증 분할에서 버그를 발견할 수도 있습니다. 적절한 계획과 철저한 문서를 통해 예상보다 빨리 비즈니스 문제를 해결하는 모델을 찾을 가능성을 높일 수 있습니다.