11. 개발/테스트 데이터셋과 평가 지표를 변경해야하는 시점

필자는 새로운 프로젝트를 시작할 때면, 개발 데이터셋과 테스트 데이터셋을 가능한 빨리 준비하려 노력합니다. 그 이유는 이것이 팀에 명확한 목표를 제공하기 때문입니다.

좋은 개발/테스트 데이터셋 수집과 프로젝트 목표를 반영한 완벽한 평가 지표를 오랫동안 고민하는 것보다는 불완전한 무엇인가를 신속하게 제시하고 빨리 시작하는 것이 더 좋습니다. 필자는 기초 준비에 가능한 일주일을 넘기지 않습니다. 그러나 성숙한 애플리케이션 분야에 이 일주일 전략을 적용하는 것은 맞지 않습니다. 예를 들어서, 스팸 방지 시스템은 대표적인 성숙한 딥러닝 애플리케이션 분야입니다. 성숙한 딥러닝 애플리케이션 분야에서 작업하는 팀의 경우에는 더 좋은 개발/테스트 데이터셋을 만들기 위해서 몇 달을 투자하는 경우도 있습니다.

여러분이 만든 초기 개발/테스트 데이터셋 혹은 평가 지표에 중요한 것이 빠진 것을 파악했다면, 신속하게 변경하면 됩니다. 예를 들어서, 개발 데이터셋과 평가 지표가 분류기 A를 분류기 B보다 우수하다고 평가했습니다. 그런데 실제 개발팀은 분류기 B가 분류기 A보다 제품에 실제로 더 적합하다고 판단하고 있습니다. 이런 상황이 발생한다면 이것이 바로 개발/테스트 데이터셋 혹은 평가 지표를 변경해야 한다는 신호입니다.

개발 데이터셋과 평가 지표가 분류기 A를 더 성능이 좋다고 잘못 평가한 원인은 다음 3가지에서 찾을 수 있습니다.

1. 모델에 잘 동작해야 하는 실제 데이터 분포가 개발/테스트 데이터셋과 다르다.

초기 개발¹/테스트 데이터셋은 대부분 어른 고양이 사진으로 만들어졌다고 가정해 보겠습니다. 고양이 앱을 배포했는데, 사용자들은 예상과 달리 새끼 고양이 이미지를 더 많이 올리고 있음을 알게 되었습니다. 이것은 개발/테스트 데이터셋 분포와 실제 환경에서 수행해야 하는 실제 데이터 분포가 서로 다르다는 것을 의미합니다. 이 경우에 개발팀은 개발/테스트 데이터셋를 실제 데이터를 더 잘 표현하도록 업데이트해야 합니다.

2. 개발 세트에 과적합 된 상태다.

개발 데이터셋을 이용하여 알고리즘을 반복적으로 평가하는 과정에서, 알고리즘은 개발 데이터셋에 점진적으로 과적합 되는 경향을 보입니다. 개발이 완료된 다음 알고리즘을 테스트 데이터셋으로 평가합니다. 만약 개발 데이터셋으로 평가한 성능이 테스트 데이터셋으로 평가한 성능보다 훨씬 더 좋은 상황이 발생한다면, 이것은 알고리즘이 개발 데이터셋에 과적합 되었다는 신호입니다. 이 경우 새로운 개발 데이터셋을 만들어야 합니다.

팀의 진행 상황을 추적해야 하는 경우 시스템을 정기적으로 평가할 수도 있습니다. 예를 들어, 테스트 세트로 일주일에 한 번 또는 매월 한 번씩 시스템을 평가할 수 있습니다. 그러나 지난주의 시스템으로 롤백할지 여부와 같은 알고리즘과 관련된 결정을 내릴 때 테스트 세트를 사용하면 안 됩니다. 만약 이런 결정에 테스트 세트를 사용하게 된다면, 시스템은 테스트 세트에 과적합 하기 시작할 것이고², 더 이상 시스템 성능에 대한 공정한 평가 지표를 제공할 수 없을 겁니다. (이런 부분은 연구 논문을 발표해야 하거나, 아마도 비즈니스 의사 결정을 내릴 때 이런 측정 항목을 사용해야 하는 상황에서만 필요합니다)

3. 평가 지표는 프로젝트를 최적화하는 항목 이외에 다른 항목도 평가한다.

고양이 애플리케이션의 평가 지표가 분류 정확도라고 가장하겠습니다. 이 평가 지표는 현재 분류기 A가 분류기 B보다 우수하다고 평가합니다. 그러나 여러분이 두 분류기를 모두 사용해 보니, 분류기 A는 가끔 포르노 이미지를 통과시킨다는 사실을 발견했습니다. 분류기 A가 더 정확하기는 하지만, 분류기 A 성능을 그대로 수용할 수는 없습니다. 포르노 이미지가 서비스에 등록된다면 서비스 사용자는 고양이 앱에 대한 나쁜 인상을 받게 될 것입니다. 어떻게 대응해야 할까요?

여기에서 사용한 평가 지표는 알고리즘 B가 실제로 알고리즘 A보다 우수하다는 사실을 식별하지 못했습니다. 따라서 초고의 알고리즘을 결정하는 평가 지표를 이제 더는 신뢰할 수 없게 되었습니다. 이런 상황이 바로 평가 지표를 변경해야 하는 시점입니다. 예를 들어, 평가 지표를 계산하는 공식에 포르노 이미지를 허용하는 시스템에 높은 벌점을 부과하는 평가 항목을 추가할 수 있습니다. 신뢰할 수 없는 평가 지표를 사용하면서 수작업으로 분류기를 선택고 되돌리는 것과 같이 너무나 느리고 긴 프로세스를 사용해서는 안 됩니다. 이보다는 새로운 평가 지표를 만들고, 팀의 새로운 목표를 명확하게 정의하는 것이 좋습니다.

프로젝트를 진행하면서 개발/테스트 데이터셋과 평가 지표를 변경하는 것은 일반적인 과정입니다. 프로젝트 초기에 신속하게 만든 개발/테스트 데이터셋과 평가 지표를 사용하여, 개발 주기를 빠르고 민첩하게 반복할 수 있습니다. 그러나 어느 순간 기존에 사용하던 개발/테스트 데이터셋과 평가 지표가 더는 프로젝트에 적합하지 않다고 해서, 이것 자체가 문제가 되는 것은 아닙니다. 이런 문제를 파악했다면 바로 적합한 개발/테스트 데이터셋과 평가 지표을 재정의하면 됩니다. 데이터셋과 평가 지표를 재정의했다면, 개발에 침여하는 구성원들 모두가 새로운 데이터와 목표에 대해서 알고 있는지 반드시 확인해야 합니다.