머신러닝 지침!

https://developers.google.com/machine-learning/guides/rules-of-ml/#top_of_page

머신러닝 엔지니어링 실무지침서

Martin Zinkevich

본 문서의 목적은 머신러닝에 관한 기초 지식을 갖춘 독자들이 Google의 머신러닝 관련 권장사항을 참고할 수 있도록 돕는 것입니다.

이를 통해 Google C++ 스타일 가이드 등의 인기 있는 실무 프로그래밍 가이드와 마찬가지로 머신러닝에 관한 스타일을 제시합니다.

머신러닝 수업을 들은 적이 있거나 머신러닝 모델을 개발하거나 다뤄본 경험이 있다면 이 문서를 읽는 데 필요한 배경지식을 갖춘 것입니다.

용어

효과적인 머신러닝을 논하는 본 문서에서는 다음과 같은 용어가 반복적으로 사용됩니다.

- 인스턴스 : 예측하려는 대상물을 가리킵니다.

예를 들어 '고양이와 관련됨' 혹은 '고양이와 무관함'으로 분류하려는 웹페이지가 인스턴스가 될 수 있습니다.

- 라벨 : 예측 작업에 관한 답으로서, 머신러닝 시스템이 도출한 답이거나 학습 데이터에 제공된 정답입니다.

예를 들어 웹페이저에 관한 라벨은 '고양이와 관련됨' 일 수 있습니다.

- 특성 : 예측 작업에 사용되는 인스턴스 속성입니다. 예를 들어 웹페이지는 '고양이라는 단어를 포함'한다는 특성을 가질 수 있습니다.

- 특성 열 : 사용자가 거주할 수 있는 모든 국가의 집합과 같이 서로 관련된 특성의 집합입니다. 예를 들어 하나 혹은 그 이상의

특성이 특성 열에 나타날 수 있습니다. '특성 열' 은 Google 에서만 쓰는 용어입니다.

Yahoo/Microsoft의 VW시스템에서는 특성열을 '네임스페이스'라고 하며, Field라고 지칭하는 경우도 있습니다.

- 예시 : 인스턴스(특성 포함) 및 라벨을 함께 지칭합니다.

- 모델 : 예측 작업의 통계적 표현입니다. 예시를 사용하여 모델을 학습시킨 후 그 모델을 사용하여 예측을 수행합니다.

- 측정항목 : 중요하게 다뤄지는 수치입니다. 직접 최적화될 수도 있고, 그렇지 않을 수도 있습니다.

- 목표 : 알고리즘에서 최적화하려는 측정항목입니다.

- 파이프라인 : 머신러닝 알고리즘의 기반을 이루는 인프라입니다. 프런트 엔드에서 데이터를 수집하고,

데이터를 학습 데이터 파일에 넣고, 하나 이상의 모델을 학습시키고, 모델을 프로덕션 환경으로 내보내는 과정이 포함됩니다.

- 클릭률 : 웹사이트 방문자 중 광고의 링크를 클릭하는 비율입니다.

개요

훌륭한 제품을 만드는 비결을 아래와 같습니다.

머신러닝을 활용하면서 머신러닝 전문가의 흉내를 내지 말고 엔지니어로서 본인의 장기를 살리세요.

실제로 직면하게 될 문제들은 대부분은 엔지니어링 문제입니다. 뛰어난 머신러닝 전문가의 모든 리소스를 갖추었다 해도,

결국 실익을 안겨주는 것은 좋은 머신러닝 알고리즘이 아니라 좋은 특성입니다.

따라서 기본적인 접근법은 다음과 같습니다.

1. 파이프라인에 처음부터 끝까지 빈틈이 없는지 확인합니다.

2. 하비적인 목표부터 시작합니다.

3. 상식선에서 단순한 방식으로 특성을 추가합니다.

4. 파이프라인에서 빈틈이 없는지 확인합니다.

이 접근법은 사용하면 오랫동안 효과를 볼 수 있을 것입니다. 단순한 방식으로 더 이상 진전을 기대할 수 없는 경우에만

이외에 다른 접근법을 모색해야 합니다. 복잡성이 더해지면 개발은 느려집니다.

단순한 방식으로는 부족하다면 이제 최첨단 머신러닝 기법에 도전할 때입니다.

3단계 머신러닝 프로젝트의 섹션을 참조하자.

1. 1부에서는 머신러닝 시스템을 구축하기에 적절한 시점인지 판단하는데 도움을 드립니다.

2. 2부에서는 첫 번째 파이프라인을 구축하는 방법을 설명합니다.

3. 3부에서는 출시와 반복을 거듭하면서 파이프라인에 새 특성을 추가하고 모델 및 학습-서빙 격차를 평가하는 방법을 설명합니다.

4. 끝으로 관련 저술 목록 및 이 문서에서 예시로 자주 사용되는 시스템에 관한 배경지식을 소개하는 부록이 준비되어 있습니다.

머신러닝 시작 전

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

머신러닝은 멋진 도구이지만 우선은 데이터가 필요합니다. 다른 문제로부터 데이터를 가져와서 모델을 약간 수정하여

새 제품에 적용하는 방법은 이론적으로는 가능하지만 기초적인 휴리스틱보다도 성능이 떨어질 가능성이 높습니다.

머신러닝의 효과를 100%로 기대한다면 휴리스틱도 50%의 효과는 낼 수 있습니다.

예를 들어 앱 마켓플레이스에서 앱의 순위를 매길 때는 설치율 또는 설치 횟수를 휴리스틱으로 사용할 수 있습니다.

스팸을 감지할 떄는 전에 스팸을 보낸적이 있는 발사나를 걸러내면 됩니다.

사람이 직접 편집하는 방법도 얼마든지 가능합니다.

연락처의 순위를 매기려면 최근에 자주 사용한 연락처 순으로 하거나, 단순한 알파벳 순으로 해도 됩니다.

머신러닝이 제품에 절대적으로 필요한 기능이 아니라면 데이터를 충분히 수집하기 전까지는 사용하지나 마세요.

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

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

그 이유는 다음과 같습니다.

1. 시스템 사용자로부터 미리 사용권한을 받는 것이 여러모로 수월합니다.

2. 향후 발생할 것으로 예상하는 문제점이 있다면 지금부터 이전 데이터를 수집해 두는 것이 좋습니다.

3. 측정항목 게측을 염두에 두고 시스템을 설계한다면 나중에 작업이 편해집니다. 구체적으로, 측정항목을 계측하기 위해

로그에서 문자열을 일일이 정규식으로 추출할 필요가 없어집니다.

4. 무엇이 변하고 무엇이 그대로인지 알게 됩니다. 예를 들어 1일 활성 사용자 수를 직접 최적화하려 한다고

가정해 보겠습니다. 그러나 시스템을 미리 조작해 보는 과정에서, 사용자 경험을 크게 바꾸더라도 이 측정항목에는

눈에 띄는 변화가 없다는 사실을 발견할 수도 있습니다.

Google+팀은 읽기당 펼치기 횟수, 읽기당 재공유 횟수, 읽기당 +1 횟수, 댓글/읽기, 사용자당 댓글 수, 

사용자당 재공유 횟수 등을 측정하여 서빙 시 게시물의 풀질을 계산하는 데 사용합니다.

또한 사용자를 버킷으로 그룹화하고 실험 통계를 집계할 수 있는 실험 프레임워크를 갖추는 것이 중요합니다.

규칙#12를 참조하세요.

측정항목을 적극적으로 수집할수록 시스템을 전반적으로 파악하기가 쉬워집니다. 문제점을 찾았나요?

측정항목을 추가하여 추적하세요. 최근 릴리스에서 만족스러운 수준의 정량적 변화가 있었나요?

측정항목을 추가하여 추적하세요.

3부 (규칙#3) : 휴리스틱이 복잡하다면 머신러닝을 선택하라.

단순한 휴리스틱만 갖춰도 제품을 출시할 수 있습니다. 휴리스틱이 복잡하면 유지보수가 불가능합니다.

데이터가 확보되었고 달성하려는 목표가 가시화되었다면 머신러닝으로 이행할 수 있습니다.

휴리스틱모델인지 아니면 머신러닝 모델인지에 관계없이, 대부분의 소프트웨어 엔지니어링 작업에서 그러하듯이 접근 방식에

대해 끊임없는