[FSDL 정리] 머신러닝 프로젝트 테스트(Testing) 하기 : 시스템 영역

ML 시스템 Testing

---

머신러닝의 경우 일반적인 소프트웨어 프로그램보다 Testing이 어렵다. 소프트웨어는 소스 코드를 프로그램으로 바꾸는 것이 주목적이지만, 머신러닝의 경우 추상적인 데이터와 모델을 활용하기 때문이다.

실제로 소스 코드 관리보다는 데이터를 관리하는 것이 추상적이고 난도가 높다. 또한 모델 학습 과정은 잘 정의되지 않아 복잡한 경우가 많고, 관련 디버깅 툴도 부족한 상황이다.
따라서 ML 시스템에선 주요 기능이 정상적으로 동작하는지 간단히 확인하는 Smoke test 기법을 주로 활용한다.

 

Smoke test : 데이터 확인하기

---

데이터가 원하는 형태(null 값 여부, 칼럼 여부 등)로 잘 있는지 확인한다. 과정에서 상태를 기록하는 리포트를 작성하거나, 알림을 보낼 수 있도록 설정한다. 자동화하여 처리하고 싶다면 greatexpectations이라는 툴을 활용하면 좋다고 한다.

데이터 관리

프로젝트가 진행될수록 기존 벤치마크 데이터 대신 점차 새로운 데이터를 활용하게 된다.
이 과정에서 새로운 annotation 작업이 필요하다. 모델 개발자는 데이터를 잘 이해하기 때문에 가장 정확하게 annotation을 할 수 있는 사람이지만, annotation 업무에만 집중하다 보면 프로젝트 진행이 더뎌지는 문제가 생긴다.

따라서 전문 annotation 팀을 회사 내부에 두고, 주기적으로 모델 개발자와 소통을 하여 데이터 품질을 관리하는 것이 필요하다. 물론 회사 규모가 커 모델 개발자가 많아 주기적으로 돌아가며 annotation을 수행할 수 있다면, 가장 이상적으로 데이터를 관리할 수 있을 것이다.

 

Smoke test : 학습 과정 점검하기

---

데이터의 일부만 활용해 과적합시켜 모델이 제대로 학습되고 있는지를 확인한다.
과적합 데이터임에도 수렴까지 긴 시간이 걸린다면 분명 어딘가 오류가 있을 것이다. label이 섞이거나 하는 등의 오류는 학습을 통해서만 확인할 수 있기 때문에, 이러한 테스트를 주기적으로 진행하는 것이 중요하다.

학습 과정 점검을 빠르게 진행하는 방법

주기적으로 진행하기 위해선 테스트 과정이 빠르게 끝나야 한다. 빠른 테스트를 위해선 더 좋은 성능의 장비로 교체하거나, 학습할 데이터의 양을 줄이면 된다. 또한 과적합이 목적이기에 regularization 기능을 제거하는 등의 방법도 활용할 수 있다.

이러한 점검 과정에서 CI툴을 활용하면 변경 전 코드와 새로운 코드 모두를 확인하여 문제를 파악하기 쉬워진다. 하지만 사용하는 CI 툴에 따라 GPU를 지원하지 않는 경우가 있으니 주의해야 한다. 참고로 CircleCI에서는 GPU 환경이 지원된다고 한다.

이러한 점검 과정에선 기존 데이터만 활용하기보다는 새로 입력된 데이터도 활용하는 것이 좋다. data flywheel이 잘 동작하고 있는지 점검할 수 있어야 한다.

 

Regression Test : 모델

---

ML 시스템이 정상적으로 동작하는지 확인했으면, 이제 모델이 잘 동작하는지도 확인해야 한다. 모델은 결국 입력과 출력이 있는 일종의 함수이기 때문에, 변경 사항이 생겼을 때도 동일한 출력이 나오는지 확인하는 방식으로 테스트를 진행할 수 있다.

이를 위해선 테스트 케이스를 설정하고, 출력의 Loss와 metric를 개선하기 노력하는 과정이 반복된다. 일종의 TDD(Test-Driven-Development)인 셈이다. 이때, Loss와 metric를 그냥 참고하는 것 만으론 문제가 무엇인지 정확하게 파악하기 어렵다. 따라서 테스트에 활용된 데이터 중 어떤 데이터가 Loss를 많이 유발했는지 파악한 뒤, 개선 방향을 설정하는 것이 필요하다.

자율 주행 시스템을 예시로 들면 어두운 곳 - 그림자 - 반사 등의 케이스 중 어떤 경우에서 Loss가 많이 생겼는지, 먼저 확인한 다음에 개선 방향을 설정하는 것이 중요할 것이다.

 

Test in Production

---

시스템과 모델 모두 정상적으로 자동하는 것을 확인했다면, 서비스에 배포할 차례다. 배포를 하게 되면 기존에 발견하지 못했던 새로운 종류의 문제점을 발견하게 된다. 따라서 배포 과정에서 문제가 발생할 경우에도 문제를 해결해야 한다. 배포 과정 중에 발생한 문제는 가능한 한 빨리 파악하고 해결할 수 있어야 하기에 모니터링, continual-learning 등의 기술이 필요하다.

지금까지 다룬 내용 외에도, 머신러닝 테스트 과정에 고려할 사항이 매우 많다고 한다. 자세한 내용은 구글이 작성한 논문을 참고하면 된다.

The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction – Google Research

 

Troubleshooting

---

최종적으론, Testing을 통해 발견한 문제를 해결할 수 있어야 한다. 일반적으로 모델에서 문제가 생길 일이 많아, 강의에선 모델과 관련된 문제 해결 방법만 다뤘다고 한다.
모델의 문제를 해결하는 과정은 크게 3 단계로 구성된다. 오류가 없는지, 빠르게 동작하는지, 성능을 올릴 수 있는지. 각각의 경우에서 확인해야 할 점과 대처(방지) 방안에 대해 정리하면 다음과 같다.

• 오류가 있나?
  • Tensor의 차원이 맞는지 → 코드에 Tensor 차원 적어두기
  • 메모리가 충분한지 → FP16으로 변경하기, 배치 사이즈 변경하기, gradient accumulation 활용하기, tensor parallelism 활용하기, gradient checkpointing 이용하기
  • 수치가 정상적인지(NaN, INF 값 발생하는지) → Normalization 부분의 gradient 확인하기

• 빠르게 동작하나?
  • 멀티 프로세싱을 적용해 개선할 수 있는지
  • 어떤 연산 과정에서 병목 현상이 일어나는지
• 성능을 올릴 수 있나?
  • 과적합을 개선할 수 있는지 → 데이터를 늘려보기
  • underfitting을 개선할 수 있는지 → 모델의 Scale을 키워보기
  • distribution shift를 개선할 수 있는지 → 데이터, 모델 모두 키워보기
  • 위에 언급한 문제가 아닐 경우, 모델의 특성에 맞게 파인튜닝을 진행하기
   

파인 튜닝 시 일반적으로 고려할 사항들