이 네모박스에 적힌 글은 책의 내용 중 제가 중요하다고 생각된 부분을 그대로 옮긴 것입니다.
"더 보기"로 나타나는 내용은 제 생각이 담겨 있습니다.
본문
모든 머신러닝 제품의 유용성에 큰 영향을 미치는 네 가지 성능에는 비즈니스 성능, 모델 성능, 최신성, 속도가 있습니다. 이 지표를 명확히 정의해야 작업을 반복할 때마다 성능을 정확하게 측정할 수 있습니다.
비즈니스 성능
목표가 명확하다면 측정 대상을 정의하여 목표가 달성되었는지 판단해야 합니다. 이 지표는 모델의 성능 지표와는 다르며, 오직 제품의 성공만을 반영해야 합니다.
✔️ 모델을 학습시킬 때 손실, 메트릭(비즈니스 성능)을 바라보며 모델의 성능을 측정한다.
✔️ 손실이 최소화된 지점이 반드시 메트릭이 최대화 된 지점을 의미하는것은 아니다.
모델 성능
대부분의 온라인 제품에서 모델의 성능을 결정하는 궁극적인 측정 지표는 전체 방문자 중 모델의 출력을 사용한 사람의 비율입니다. ... 모델을 만들었지만 아직 배포 전이라면 사용 횟수 기반의 지표를 측정할 수 없습니다. 그럼에도 성능이 향상되었는지 평가하기 위해 오프라인 메트릭 또는 모델 메트릭이라 부르는 별도의 성능 지표를 정의하는것이 중요합니다.
✔️ 결국 모델은 어떤 예측을 만들어내며, 그 예측이 활용되어야만 의미가 있는것이다.
✔️ 이 지표를 애초에 얻을 수 있으면 좋겠지만, 그럴 수 없기 때문에 모델 학습시 쓸 수 있는 메트릭이 필요하다.
모델과 제품 사이의 상호작용을 조금만 바꿔 더 쉬운 모델링 방식을 사용하면 안정적인 결과를 제공할 수 있습니다. 다음은 모델링 작업을 쉽게 만들기 위해 애플리케이션을 수정하는 세 가지 사례입니다.
⎆ 신뢰도가 기준 이하인 경우 모델의 출력 결과를 생략할 수 있도록 인터페이스 바꾸기
⎆ 최상의 모델 예측뿐만 아니라 다른 예측이나 경험적인 규칙으로 만든 결과를 제시하기
⎆ 모델이 실험적인 경우 피드백을 받을 수 있도록 사용자와 소통하기
✔️ 궁극적인 목표의 제품에 필요한 데이터, 모델링 등 실현이 어려운 부분이 있다면, 제품을 약간 쉽게 수정하는것도 방법이다.
✔️ 또한 사용자 경험을 항시 염두에둬야하며, 모델의 성능에 도취되어서는 안된다. 모델을 만드는게 아니라 제품을 만드는것이다.
최신성과 분포 변화
모델이 적절한 데이터셋에서 훈련했더라도 시간이 지남에 따라 데이터 분포가 변한다면 많은 문제가 발생합니다. 데이터 분포가 변할 때도 성능을 동일하게 유지하기 위해 모델도 종종 바뀔 필요가 있습니다.... 비즈니스 문제에 따라서 모델을 최신으로 유지하는것이 얼마나 어려울지 고려해야 합니다. 얼마나 자주 모델을 다시 훈련해야 하고 훈련할 때마다 드는 비용은 얼마일까요?
... 최신성에 대한 요구사항은 특정 도메인을 대상으로 할 경우 바뀔 수 있습니다. 예를 들어 수학에 대한 올바른 질문 방법은 음악 트렌드에 대한 질문 방법보다 훨씬 더 느리게 바뀔 것입니다.
✔️ 흔히 데이터/컨셉 드리프트 라고도 알려진 현상이다.
✔️ 기존 데이터와 새로 유입되는 데이터간 분포 유사성을 검사할 수도 있으며,
✔️ 또는 현재 배포된 모델로 예측을 수행하여, 신규 데이터에 대한 모델 성능이 어느정도나 낮아졌는지 파악한다.
✔️ 실시간적으로 이를 평가하는것은 어렵고, 데이터가 어느정도 쌓였을 때 진행되어야 한다.
✔️ 따라서 그 시점을 정하기 위한 정책을 수립해야 한다.
✔️ 또한 배치 예측 수행 => 모델을 새로 학습시킬 때 컴퓨팅 자원이 다량 투입되어야 한다.
✔️ + 유입된 데이터 분석에 투입되는 인력 비용도 감안해야한다.
기준 모델과 단순한 모델은 입력과 타깃이 쌍을 이루지 않은 데이터에서 학습할 수 있어 데이터 수집 과정이 간단합니다. 복잡한 모델은 입력과 타깃 쌍이 필요합니다. 최신성 요구 사항을 만족시키려면 입력 타깃 쌍을 구하는 것보다 훨씬 어렵습니다. 업데이트된 데이터셋을 준비하는 데 시간이 훨씬 많이 필요하기 때문입니다.
✔️ 현실적으로 어느정도 까지 전 자동화 파이프라인을 구축할 수 있을지 생각해야한다.
✔️ 데이터를 수작업으로 어느정도 들여다보는 과정이 필요한 경우가 많다.
✔️ 제품 구상단계에서는 완전한 최종 목표 모델을 만들 필요는 없다.
✔️ 전체 제품 서비스 중 일부로 삽입되는 형식으로 디자인하고,
✔️ 점진적으로 복잡한 모델로 교체해 나갈 수 있는 유연한 구조를 채택하는것이 좋을 수 있다.
애플리케이션의 인기가 높으면 데이터 수집 요구 사항을 줄일 수 있습니다.
✔️ 약간 새로운 시야로 볼 수 있는 대목이다.
✔️ 다만 인기가 높으려면, 초기 배포 모델의 성능이 꽤 뛰어나야한다.
✔️ 그리고 인기를 얻는다면 손쉽게 다량의 데이터 수집이 가능하다.
속도
모델의 추론 시간은 모델의 복잡함에 따라 증가합니다. 자연어 처리처럼 개별 샘플의 크기가 비교적 작은 분야에서도 이 차이는 큽니다. ... 개별 샘플로 보면 이 차이는 작지만 동시에 많은 샘플에 대해 추론을 수행하면 금방 누적되어 차이가 커져버립니다.
✔️ 컴퓨팅 리소스를 어떻게 할당할지에 대한 고민 포인트가 된다.
✔️ 모델의 추론 도출 속도는 느릴 수 있으며, 특히 GPU 까지 관여된 경우라면 고려사항이 더 많아진다.
✔️ 단순 쿠버네티스 서비스로 해결 가능한 문제인지도 생각해 볼만한 부분인것 같다.
비슷한 입력과 출력 형태를 가진 데이터셋을 의미합니다. 종종 비슷한 입/출력을 사용한 모델을 완전히 다른 상황에 적용할 수 있습니다. ... 유사 데이터셋에서 모델을 훈련하면 빠르게 프로토타입을 만들고 결과를 검증할 수 있습니다. 어떤 경우에는 유사 데이터에서 모델을 학습한 다음, 이 모델의 성능 일부를 최종 데이터셋으로 이전할 수도 있습니다.
✔️ 목표와 100% 일치하지 않더라도, 유사 데이터로 잘 작동한 모델이 어느정도 잘 작동할것이라고 믿을 수 있다.
✔️ 이 또한 새로운 (약간은 복잡한) 기준 모델을 정의하는 하나 방법으로도 볼 수 있을것이다.
✔️ 우선 종단간 1 Cycle을 완전히 경험한 후 점진적으로 기준선의 기준치를 높여나가는게 좋을것이다.
제품의 목표와 동일한 문제를 해결하는 파이프라인과 앞서 선택한 데이터셋을 다루는 코드를 검색해보는 것이 좋습니다. 예제 코드를 찾았다면 먼저 직접 그 결과를 재현해보세요. ... 비슷한 코드를 찾는 좋은 방법은 당면한 문제를 입력과 출력 종류로 표현하고, 그 다음 비슷한 종류의 문제를 다루는 코드를 찾는 것입니다.
✔️ "소스코드가 돌아간다" 까지의 확인이 전부가 아니다.
✔️ 반드시 소스/논문 저자가 주장한 성능이 거의 완벽하게 재현 가능한지를 실험해 봐야만한다.
1️⃣ 비슷한 오픈소스 모델을 찾습니다. 훈련된 데이터셋도 함께 찾아 직접 훈련 결과를 재현해보는게 이상적입니다.
2️⃣ 결과를 재현하고 나면 주어진 문제에 가장 가까운 데이터셋을 찾습니다. 그리고 이 데이터셋으로 앞에서 찾은 모델을 훈련합니다.
3️⃣ 데이터셋과 훈련 코드를 통합했다면 사전에 정의한 측정 지표를 사용하여 모델의 성능을 판단하고 반복을 시작합니다.
✔️ 기존 결과물의 재현, 내 데이터로의 적용, 성능 개선의 반복 실험
'머신러닝 파워드 애플리케이션' 카테고리의 다른 글
| 4장 초기 데이터셋 준비하기 (0) | 2021.11.29 |
|---|---|
| 3장 엔드투엔드 파이프라인 만들기 (1) | 2021.11.27 |
| 1장 제품의 목표를 머신러닝 문제로 표현하기 (0) | 2021.11.25 |
