구글 ML 유니버설 가이드 - 머신러닝의 규칙

 

developers.google.com/machine-learning/guides/rules-of-ml/?hl=ko

머신러닝의 규칙:  |  ML 유니버설 가이드  |  Google Developers

 

구글에서 제시한 머신러닝 개발의 가이드라인 입니다.

개발자를 위한 글이지만 머신러닝 기능이 포함된 서비스를 기획하는 입장에서도 귀감이 되는 글이다. 

 

긴 내용이라 인상 깊었던 파트를 몇 개 인용해 보고자 합니다. 

 

규칙 #1: 머신러닝 없이 제품을 출시하는 것을 두려워하지 말라.

"서비스에서 발생하는 대부분의 이슈는 직관에 의존한 휴리스틱 방법도 효과가 있다. 

머신러닝은 데이타가 존재해야 의미있는 성능을 보여줄 수 있다.

초기 데이타가 없다면, 간단한 로직으로 제품을 출시하고 데이타를 모아라. "머신러닝은 멋진 도구이지만 우선은 데이터가 필요합니다. 다른 문제로부터 데이터를 가져와서 모델을 약간 수정하여 새 제품에 적용하는 방법은 이론적으로는 가능하지만 기초적인 휴리스틱보다도 성능이 떨어질 가능성이 높습니다. 머신러닝의 효과를 100%로 기대한다면 휴리스틱도 50%의 효과는 낼 수 있습니다.

 

머신러닝은 서비스의 품질을 높이기 위한 도구이지, 머신러닝이 서비스 그 자체는 아닙니다. 

현실에서 상당수의 문제는 직관에 의해 해결이 가능합니다. 

그리고 간단한 로직일 수록 출시 타이밍과 유지보수 관점에서 이득이 있습니다.

 

우선 휴리스틱한 로직으로 서비스를 출시하고,

예외 케이스와 데이타를 수집한 다음,

기계학습 로직 적용을 검토해 보는 경로가 바람직합니다. 

 

규칙 #2: 가장 먼저 측정항목을 설계하고 구현하라.

"머신러닝의 기능과 역할을 공식화하기 전에 현재 시스템의 상황을 최대한 자세히 추적해야 합니다. 그 이유는 다음과 같습니다.

1. 시스템 사용자로부터 미리 사용 권한을 받는 것이 여러모로 수월합니다.
2. 향후 발생할 것으로 예상하는 문제점이 있다면 지금부터 이전 데이터를 수집해 두는 편이 좋습니다.
3. 측정항목 계측을 염두에 두고 시스템을 설계한다면 나중에 작업이 편해집니다. 구체적으로, 측정항목을 계측하기 위해 로그에서 문자열을 일일이 grep으로 추출할 필요가 없어집니다.
4. 무엇이 변하고 무엇이 그대로인지 알게 됩니다. 예를 들어 1일 활성 사용자 수를 직접 최적화하려 한다고 가정해 보겠습니다. 그러나 시스템을 미리 조작해 보는 과정에서, 사용자 경험을 크게 바꾸더라도 이 측정항목에는 눈에 띄는 변화가 없다는 사실을 발견할 수도 있습니다."

사실 머신러닝을 사용하지 않더라도, 어떤 지표를 측정하고 쌓을지는 사전에 정의되어야 합니다. 수집해야 되는 지표가 명확하지 않다면 허용된 범위 내에서 세부적인 로그를 수집해야 합니다. 

 

서비스 도중에 수집 데이타를 추가하는 일이 얼마나 어렵고 고비용의 작업인지... ㅡ.ㅜ이미 알았을 때는 손을 쓸 수 없을 때도 있습니다.

 

이용자로부터 추가적인 접근 권한을 얻어야 한다든지... 개발자가 다른 프로젝트에 투입되었다든지.데이타 수집이 가능하더라도, 충분한 데이타를 얻기 위해 일정 시간을 기다려야 할 수도 있습니다. 

 

규칙 #10: 조용한 실패에 주의하라.

 

"다른 종류의 시스템보다 특히 머신러닝 시스템에서 자주 나타나는 문제입니다. 조인 대상이 되는 특정 테이블이 더 이상 업데이트되지 않는다고 가정해 보겠습니다. 이 테이블에 따라 머신러닝 시스템을 조정하면 겉보기에는 특별한 문제가 없더라도 실제로는 성능이 점점 떨어집니다. 때로는 몇 달 동안 그대로였던 테이블을 찾아내서 갱신하는 것만으로도 놀라운 성능 개선 효과를 거둘 수 있습니다. 구현 변경으로 인해 특성의 포함 범위가 바뀌기도 합니다. 예를 들어 특성 열이 입력된 예시의 비율이 90%에서 60%로 급락할 수 있습니다. Play의 경우 6개월 동안 그대로였던 테이블을 갱신했더니 설치율이 2%나 상승했습니다. 데이터의 통계를 추적하고 경우에 따라 직접 조사하면 이러한 유형의 실패를 줄일 수 있습니다."

 

기계학습 관련 서비스 운영자 입장에서 특히 주의해야 되는 부분입니다. 

다른 부서와의 소통에 문제가 있어서 테이블 업데이트가 중단되었는지 몰랐거나,
어떤 이유로 이력 수집에 문제가 있어서 부정확한 데이타이 섞이게 된다면,서비스 전체가 멈추지는 않지만 기계학습의 품질을 하락시킬 수 있습니다. 

 

이런 류의 문제는 외부에서 인지하기 쉽지 않은 문제입니다. 관련 지표를 유심히 관찰하여 이런 '조용한 실패'를 회피해야 합니다. 

 

어쩌면 기계학습 관련 서비스가 개발 보다는 운영이 더 중요할 수 있습니다. 

 

규칙 #14: 해석 가능한 모델부터 시작하면 디버깅이 쉬워진다.

"선형 회귀, 로지스틱 회귀, 푸아송 회귀는 확률론 모델로부터 직접 유래한 것입니다. 각 예측은 확률 또는 기대값으로 해석할 수 있습니다. 이렇게 하면 분류 정확성 또는 순위 결정 성능을 직접 최적화하려는 0-1 손실, 다양한 힌지 손실 등의 목표를 사용하는 모델보다 디버깅이 쉬워집니다. 예를 들어 학습 시스템의 확률이 병렬로 운용되거나 별도로 조사된 프로덕션 시스템의 확률과 차이가 난다면 이를 통해 문제점을 드러낼 수 있습니다."

 

경험적으로 대부분의 문제는 단순회귀로 80% 이상의 목표를 달성할 수 있습니다.

서비스의 핵심적인 부분이 아니라면, 가성비를 따져서 단순 회귀 모델을 적용해도 무방합니다. 

서비스 성공에 핵심적인 부분이더라도,
사용자가 적은 초기에 단순 모델을 사용하고 그것을 기준으로 업데이트하는 전략도 괜찮습니다. 

 

 

규칙 #15: 정책 레이어에서 스팸 필터링과 품질 순위화를 분리하라.

"품질 순위화가 예술이라면 스팸 필터링은 전쟁입니다. 시스템 사용자들은 게시물의 품질을 판단하는 데 사용하는 지표를 금방 알아차리고 게시물을 적당히 손질하여 이러한 속성을 갖게 만듭니다. 따라서 품질 순위화에서는 정상적인 의도로 게시된 콘텐츠의 순위를 매기는 데 집중해야 합니다. 스팸의 순위를 높게 매겼다고 해서 품질 순위화 학습 시스템을 평가절하해서는 안 됩니다. '선정적인' 콘텐츠도 마찬가지 이유로 품질 순위화와 별도로 처리해야 합니다. 스팸 필터링은 완전히 다른 분야입니다. 생성해야 하는 특성은 끊임없이 변화하게 마련임을 받아들여야 합니다. 때로는 시스템에 도입해야 하는 규칙이 분명합니다. 예를 들어 스팸 신고가 3회를 초과한 게시물은 제외해야 합니다. 학습 모델은 최소한 하루에 한 번 이상 업데이트해야 합니다. 콘텐츠 작성자의 평판도 큰 역할을 합니다."

 

반드시,,, 고객센터로 부터 긴급 전화를 받을 준비를 해야 합니다. 거의 100%입니다. 

일반적인 모델링과 별개로 긴급히 휴리스틱한 정책을 적용할 수 있는 필터를 앞뒤에 달아두는게 정신 건강에 좋습니다. 

 

규칙 #41: 성능 개선이 한계에 봉착했다면 기존 신호를 다듬기보다는 본질적으로 새로운 정보 출처를 찾아서 추가하라.

"사용자의 인구통계 정보를 추가했습니다. 문서에 포함된 단어에 관한 정보도 추가했습니다. 템플릿 탐색을 수행하여 정규화를 조정했습니다. 그런데 핵심 측정항목이 1% 이상 개선된 출시가 몇 분기 동안 단 한 번도 없었습니다. 이제 어떻게 해야 할까요?

이제 완전히 다른 특성을 위한 인프라 구축을 시작할 때입니다. 예를 들면 사용자가 어제, 지난주, 작년에 액세스한 문서 내역, 다른 출처에서 가져온 데이터 등입니다. 위키데이터 항목 또는 사내 보유 데이터(예: Google의 지식 정보)를 사용해 보세요. 딥 러닝을 활용하세요. 투자수익에 관한 기대치를 조정하고 그에 따라 업무량을 늘려야 합니다. 다른 엔지니어링 프로젝트와 마찬가지로, 새 특성을 추가하는 데 따르는 편익과 복잡성이 올라가는 데 따르는 비용을 저울질해야 합니다."

 

기존의 연료를 다 썼다면 다른 연료를 찾아야 합니다. 새로운 데이타 소스를 채굴해야 합니다. 

데이타가 비슷하다면 여러 모델들의 성능은 크게 차이가 안납니다. 

같은 환경이라면 당연히 최신 모델의 성능이 우수하겠지만, 우리의 서비스에 적용하는 것은 다른 의미입니다. 

최신 모델을 구현할 개발자가 없을 수도 있고, 너무 많은 리소스가 소요될 수 있습니다. 

 

오랫동안 해당 업계에 있었던 도메인 전문가와 협의해서 새로운 데이타 소스를 찾는 것이 더 나은 결정 일 수 있습니다..