머신러닝 규칙

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

Martin Zinkevich

본 문서의 목적은 머신러닝에 관한 기초 지식을 갖춘 독자들이 Google의 머신러닝 관련 권장사항을 참고할 수 있도록 돕는 것으로, Google C++ 스타일 가이드 등의 인기 있는 실무 프로그래밍 가이드처럼 머신러닝에 관한 스타일을 제시합니다. 머신러닝 수업을 들은 적이 있거나 머신러닝 모델을 개발하거나 다뤄본 경험이 있다면 이 문서를 읽는 데 필요한 배경 지식을 갖춘 것입니다.

용어

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

• 인스턴스: 예측하려는 대상물을 의미합니다. 예를 들어 웹페이지를 '고양이와 관련됨' 혹은 '고양이와 무관함'으로 분류하려는 경우 이 웹페이지가 인스턴스가 될 수 있습니다.
• 라벨: 예측 작업에 관한 답으로서, 머신러닝 시스템이 도출하거나 학습 데이터에서 제공된 정답입니다. 예를 들어 웹페이지에 관한 라벨은 '고양이와 관련됨'일 수 있습니다.
• 특성: 예측 작업에 사용되는 인스턴스의 속성입니다. 예를 들어 웹페이지는 '고양이라는 단어를 포함'한다는 특성을 가질 수 있습니다.
• 특성 열: 서로 관련된 특성의 집합입니다. 예를 들어, 사용자가 거주할 수 있는 모든 국가의 집합이 있습니다. 하나의 예는 특성 열에 하나 이상의 특성을 가질 수 있습니다. '특성 열'은 Google에서만 쓰는 용어입니다. Yahoo/Microsoft의 VW 시스템에서는 특성 열을 '네임스페이스'라고 하며, 필드라고 지칭하는 경우도 있습니다.
• 예시: 인스턴스(특성 포함) 및 라벨을 함께 지칭합니다.
• 모델: 예측 작업의 통계적 표현입니다. 예시를 사용하여 모델을 학습한 후 그 모델을 사용하여 예측합니다.
• 측정항목: 내가 관심이 있는 수치입니다. 직접 최적화될 수도 있고, 그렇지 않을 수도 있습니다.
• 목표: 알고리즘에서 최적화하려는 측정항목입니다.
• 파이프라인: 머신러닝 알고리즘의 기반을 이루는 인프라입니다. 프런트 엔드에서 데이터를 수집하고, 데이터를 학습 데이터 파일에 넣어, 하나 이상의 모델을 학습하며, 모델을 프로덕션 환경으로 내보내는 과정이 포함됩니다.
• 클릭률: 웹페이지 방문자가 광고의 링크를 클릭하는 비율입니다.

개요

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

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

실제로 직면하게 될 문제들은 대부분은 엔지니어링 문제입니다. 뛰어난 머신러닝 전문가의 모든 리소스를 갖추었다 해도, 결국 실익을 안겨주는 것은 좋은 머신러닝 알고리즘이 아니라 좋은 특성입니다. 따라서 기본적인 접근법은 다음과 같습니다.

1. 파이프라인에 처음부터 끝까지 빈틈이 없는지 확인합니다.
2. 합리적인 목표부터 시작합니다.
3. 상식선에서 단순한 방식으로 특성을 추가합니다.
4. 파이프라인에 빈틈이 없는지 확인합니다.

이 접근법을 사용하면 오랫동안 효과를 볼 수 있을 것입니다. 단순한 방식으로 더 이상 진전을 기대할 수 없는 경우에만 이외에 다른 접근법을 모색해야 합니다. 복잡성이 더해지면 개발은 느려집니다.

단순한 방식으로는 부족하다면 이제 최첨단 머신러닝 기법에 도전할 때입니다. 3단계 머신러닝 프로젝트의 섹션을 참조하세요.

이 문서의 구성은 다음과 같습니다.

1. 1부에서는 머신러닝 시스템을 구축하기에 적절한 시점을 판단하는 데 도움을 드립니다.
2. 2부에서는 첫 번째 파이프라인을 구축하는 방법을 설명합니다.
3. 3부에서는 파이프라인에 새 특성을 추가해가며 출시와 반복을 거듭하고, 모델 및 학습-서빙 격차를 평가하는 방법을 설명합니다.
4. 마지막 4부에서는 개선이 한계에 부딪히면 무엇을 해야 하는지 설명합니다.
5. 끝으로 관련 저술 목록 및 이 문서에서 예시로 자주 사용되는 시스템에 관한 배경 지식을 소개하는 부록이 준비되어 있습니다.

머신러닝 시작 전

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

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

예를 들어 앱 마켓플레이스에서 앱의 순위를 매길 때는 설치율 또는 설치 횟수를 휴리스틱으로 사용할 수 있습니다. 스팸을 감지할 때는 전에 스팸을 보낸 적이 있는 발신자를 걸러내면 됩니다. 사람이 직접 편집하는 방법도 얼마든지 가능합니다. 연락처의 순위를 매기려면 최근에 자주 사용한 연락처 순으로 하거나, 단순히 알파벳 순으로 해도 됩니다. 머신러닝이 제품에 절대적으로 필요한 기능이 아니라면 데이터를 충분히 수집하기 전까지는 사용하지 마세요.

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

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

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

Google+팀은 읽기당 펼치기 횟수, 읽기당 재공유 횟수, 읽기당 +1 횟수, 댓글/읽기, 사용자당 댓글 수, 사용자당 재공유 횟수 등을 측정하여 서빙 시 게시물의 품질을 계산하는 데 사용합니다. 또한 사용자를 버킷으로 그룹화하고 실험 통계를 집계할 수 있는 실험 프레임워크를 갖추는 것이 중요합니다. 규칙 #12를 참조하세요.

측정항목을 적극적으로 수집할수록 시스템을 전반적으로 파악하기가 쉬워집니다. 문제점을 찾았나요? 측정항목을 추가하여 추적하세요. 최근 릴리스에서 만족스러운 수준의 정량적 변화가 있었나요? 측정항목을 추가하여 추적하세요.

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

단순한 휴리스틱만 갖춰도 제품을 출시할 수 있습니다. 휴리스틱이 복잡하면 유지보수가 불가능합니다. 데이터가 확보되었고 달성하려는 목표가 가시화되었다면 머신러닝으로 이행할 수 있습니다. 휴리스틱 모델인지 아니면 머신러닝 모델인지에 관계없이, 대부분의 소프트웨어 엔지니어링 작업에서 그러하듯이 접근 방식에 대해 끊임없는 업데이트가 필요합니다. 다만 한 가지 분명한 사실은 머신러닝 모델이 업데이트 및 유지보수가 더 쉽다는 것입니다. 규칙 #16을 참조하세요.

ML 1단계: 첫 번째 파이프라인

첫 번째 파이프라인에서는 시스템 인프라를 갖추는 데 집중하세요. 앞으로 펼쳐질 머신러닝의 모든 가능성에 대해 상상해 보는 것도 재미있지만, 우선 파이프라인을 신뢰할 수 있어야 현상을 제대로 파악할 수 있습니다.

규칙 #4: 최초 모델은 단순하게 유지하고 인프라를 제대로 갖춰라.

첫 번째 모델은 제품 개선에 가장 크게 기여하게 되므로 처음부터 화려한 기능을 갖출 필요는 없습니다. 그러나 인프라 문제가 발목을 잡는 경우가 생각보다 많습니다. 사용자에게 새롭고 멋진 머신러닝 시스템을 제공하기 전에 다음과 같은 사항을 결정해야 합니다.

• 학습 알고리즘에 예시를 제공할 방법
• 시스템의 '양호함'과 '불량함'을 판단할 최초 기준
• 모델을 애플리케이션에 통합할 방법. 모델을 실시간으로 적용할 수도 있고, 오프라인에서 예시를 가지고 모델을 미리 연산하여 결과를 테이블에 저장할 수도 있습니다. 예를 들어 웹페이지는 미리 분류하여 테이블에 결과를 저장하는 한편, 채팅 메시지는 실시간으로 분류할 수 있습니다.

단순한 특성을 선택하면 다음과 같은 과제를 달성하기가 쉬워집니다.

• 특성이 학습 알고리즘에 정확히 도달합니다.
• 모델이 합리적인 가중치를 학습합니다.
• 특성이 서버의 모델에 정확히 도달합니다.

이러한 3가지 과제를 안정적으로 달성하는 시스템을 갖추었다면 준비가 거의 끝난 것입니다. 이제부터 이 단순한 모델에서 기준 측정항목과 기준 동작을 얻어 더 복잡한 모델을 테스트하는 데 사용할 수 있습니다. 어떤 팀에서는 '중립적'인 최초 실행을 목표로 하는데, 이는 머신러닝으로 얻을 수 있는 당장의 이익에 집착하지 않음으로써 애초 목표에 집중하기 위함입니다.

규칙 #5: 머신러닝과 별도로 인프라를 테스트하라.

인프라는 테스트할 수 있어야 하며, 시스템의 학습 부분을 캡슐화해야 모든 관련 부분을 테스트할 수 있습니다. 특히 다음과 같은 작업이 필요합니다.

1. 알고리즘에 데이터를 넣는 기능을 테스트합니다. 채워져야 하는 특성 열이 채워지는지 확인합니다. 개인정보를 보호하는 범위 내에서 학습 알고리즘의 입력값을 직접 조사합니다. 가능한 경우 파이프라인의 통계를 다른 곳에서 데이터를 처리해 나온 통계와 서로 비교해 봅니다.
2. 모델을 학습 알고리즘에서 꺼내는 기능을 테스트합니다. 학습 환경의 모델이 주는 점수가 서빙 환경의 모델과 동일한지 확인합니다. 규칙 #37을 참조하세요.

머신러닝에는 예측 불가능성이 있으므로 학습 및 서빙 시 예시를 생성하는 코드를 테스트할 준비를 하고, 서빙 중에 고정 모델을 로드하여 사용할 수 있는지 확인하세요. 또한 데이터를 이해하는 것이 중요합니다. 복잡한 대규모 데이터 세트의 분석에 대한 실무 조언을 참조하세요.

규칙 #6: 파이프라인을 복사할 때는 데이터 누락에 주의하라.

화물 숭배(cargo cult) 프로그래밍의 경우와 같이 기존 파이프라인을 복사하여 파이프라인을 만들었는데, 새 파이프라인에 필요한 데이터가 이전 파이프라인에서 누락되는 경우가 종종 있습니다. 예를 들어 Google+ HOT 소식의 파이프라인은 최신 게시물의 순위를 매기는 것이 목적이므로 이전 게시물을 누락시킵니다. 이 파이프라인을 Google+ 스트림에 사용하기 위해 복사했더니, 이 기능에서는 이전 게시물이 의미를 가짐에도 불구하고 파이프라인에서 여전히 이전 게시물이 누락되었습니다. 흔히 나타나는 또 다른 패턴은 사용자가 조회한 데이터만 기록하는 것입니다. 사용자가 특정 게시물을 조회하지 않은 이유를 모델링하려는 경우 이렇게 하면 음성 예시가 모두 누락되므로 결국 쓸모없는 데이터가 됩니다. Play에서도 비슷한 문제가 있었습니다. Play 앱 홈 화면을 만들면서 Play 게임 방문 페이지의 예시까지 포함된 파이프라인이 새로 만들어졌는데, 각 예시의 출처를 구분 짓는 특성을 준비하지 않은 것입니다.

규칙 #7: 휴리스틱을 특성으로 변환하거나 외부에서 처리하라.

머신러닝으로 해결하려는 문제들은 일반적으로 새로 등장한 문제는 아닙니다. 순위 결정, 분류 등 어떠한 문제든 이를 해결하는 기존 시스템이 있습니다. 따라서 수많은 규칙과 휴리스틱이 이미 존재하고 있습니다. 이러한 휴리스틱을 머신러닝과 조합하면 돌파구를 마련할 수 있습니다. 기존 휴리스틱을 철저히 분석해야 하는 두 가지 이유는 다음과 같습니다. 첫 번째로, 머신러닝 시스템으로 더욱 매끄럽게 전환할 수 있습니다. 두 번째로, 이러한 규칙은 시스템에 대해 버리기 아까운 직관을 풍부하게 담고 있습니다. 다음 네 가지 방법으로 기존 휴리스틱을 활용할 수 있습니다.

• 휴리스틱을 사용하여 전처리합니다. 품질이 뛰어난 특성인 경우에는 고려해볼 만합니다. 예를 들어 스팸 필터에서 보낸 사람이 이미 차단 목록에 들어 있다면 '차단 목록'이라는 개념을 다시 학습할 필요는 없습니다. 단순히 메시지를 차단하면 됩니다. 이진 분류 작업에서는 이 방식이 가장 합리적입니다.
• 특성을 만듭니다. 휴리스틱에서 직접 특성을 만들면 좋습니다. 예를 들어 휴리스틱을 사용하여 쿼리 결과의 관련성 점수를 계산하는 경우 이 점수를 특성값으로 포함할 수 있습니다. 이후에 값을 불연속 값의 유한집합 중 하나로 변환하거나 값을 다른 특성과 합하는 등의 머신러닝 기법을 사용하여 값을 조정할 수 있지만, 처음에는 휴리스틱으로 산출되는 값을 그대로 사용해도 됩니다.
• 휴리스틱의 원시 입력값을 마이닝합니다. 앱에 대해 설치 횟수, 텍스트 문자 수, 요일을 결합하는 휴리스틱이 있다면 이러한 값을 따로따로 가져와서 학습에 별도로 제공하는 것이 좋습니다. 이때 앙상블에 적용되는 기법 중 일부가 적용됩니다. 규칙 #40을 참조하세요.
• 라벨을 수정합니다. 휴리스틱이 현재 라벨에 포함되지 않은 정보를 포착한다고 생각될 때 이 방법을 사용할 수 있습니다. 예를 들어 다운로드 횟수를 극대화하면서 콘텐츠 품질에도 중점을 두려면 앱이 받은 평균 별점 수로 라벨을 곱하는 것이 해답이 될 수 있습니다. 정해진 방식은 없습니다. '첫 번째 목표'를 참조하세요.

ML 시스템에서 휴리스틱을 사용하는 경우 복잡성이 더해진다는 점에 유의하세요. 새로운 머신러닝 알고리즘에 기존 휴리스틱을 사용하면 전환 과정이 원활해질 수 있지만, 더 간단한 방법으로 같은 효과를 낼 수는 없을지 고민해 보시기 바랍니다.

모니터링

일반적인 권장사항은 알림을 깔끔하게 유지하는 것입니다. 예를 들어 알림에 실질적인 정보를 기재하고 대시보드 페이지를 준비해야 합니다.

규칙 #8: 시스템의 갱신 요구사항을 파악하라.

모델이 하루가 지나면 성능이 얼마나 떨어지나요? 일주일은 어떤가요? 한 분기는 어떤가요? 이 정보는 모니터링의 우선순위를 판단하는 데 도움이 됩니다. 하루 동안 모델을 업데이트하지 않으면 제품의 품질이 심각하게 저하되는 경우 모델을 지속적으로 모니터링하는 엔지니어를 두는 것이 좋습니다. 대부분의 광고 게재 시스템에는 매일같이 새로운 광고가 유입되므로 업데이트가 매일 이루어져야 합니다. 예를 들어 Google Play 검색의 머신러닝 모델이 업데이트되지 않으면 1개월 이내에 부정적인 영향을 미칠 수 있습니다. Google+의 HOT 소식에서 게시물 식별자를 갖지 않는 일부 모델은 자주 내보낼 필요가 없습니다. 게시물 식별자를 갖는 다른 모델은 훨씬 더 자주 업데이트됩니다. 또한 갱신 기준은 시간에 따라 변화할 수 있습니다. 특히 모델에서 특성 열이 추가 또는 삭제될 때 그러합니다.

규칙 #9: 모델을 내보내기 전에 문제를 탐지하라.

많은 머신러닝 시스템에는 모델을 서빙 환경으로 내보내는 단계가 있습니다. 내보낸 모델에 문제가 있는 경우 사용자가 곧바로 알아차리게 됩니다.

모델을 내보내기 전에 상태 확인을 수행하세요. 특히 홀드아웃 데이터에 관한 모델의 성능이 적절한지 확인해야 합니다. 또는 데이터의 신빙성이 의심되는 경우 모델을 내보내지 마세요. 계속해서 모델을 내보내는 팀들은 대부분 AUC(ROC 곡선 아래 영역)를 확인한 후에 내보냅니다. 모델을 제때 내보내지 못하는 이슈는 이메일 알림으로 해결할 수 있지만, 문제가 있는 모델을 사용자에게 제공하면 사태가 커집니다. 따라서 늦더라도 최대한 만전을 기하는 것이 좋습니다.

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

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

규칙 #11: 특성 열에 소유자를 지정하고 문서화하라.

시스템의 규모가 크고 특성 열이 많은 경우 각 특성 열을 누가 만들었고 누가 관리하는지를 알아야 합니다. 특성 열의 담당자가 조직을 떠날 경우 철저한 인수인계가 이루어져야 합니다. 이름만 봐도 의미를 알 수 있는 특성 열도 많긴 하지만 특성의 의미, 출처, 유용성을 자세히 기록해 두는 습관을 들이는 것이 좋습니다.

첫 번째 목표

시스템에서 중요하다고 생각하는 측정항목이 아무리 많더라도 머신러닝 알고리즘에 필요한 목표, 즉 알고리즘에서 최적화를 '시도'하는 수치는 일반적으로 단 하나입니다. 목표와 측정항목을 잘 구분해야 합니다. 측정항목은 시스템에서 보고하는 모든 수치로서 중요할 수도, 그렇지 않을 수도 있습니다. 규칙 #2를 참조하세요.

규칙 #12: 어떤 목표를 직접 최적화할지 지나치게 고민하지 말라.

우리의 목표는 수익을 올리고, 사용자의 만족도를 높이고, 살기 좋은 세상을 만드는 데 기여하는 것입니다. 중요하게 생각할 만한 측정항목은 수없이 많으며, 이들을 모두 측정해야 합니다(규칙 #2 참조). 그러나 머신러닝 과정의 초기에는 직접 최적화하지 않는 대상을 포함하여 모든 측정항목이 증가하는 것을 알 수 있습니다. 예를 들어 클릭수 및 사이트 사용 시간이 중요하다고 가정해 보겠습니다. 이 경우 클릭수를 최적화하면 사용 시간도 증가할 가능성이 높습니다.

모든 측정항목이 쉽게 증가할 수 있으므로, 다양한 측정항목 간에 균형을 맞추려고 지나치게 고민하지 말고 단순하게 생각하면 됩니다. 하지만 이 규칙에도 한도가 있습니다. 목표와 시스템의 궁극적인 건전성을 혼동해서는 안 됩니다(규칙 #39 참조). 또한 직접 최적화하는 측정항목은 개선되지만 결국 출시에 실패하는 상황이 반복된다면 목표를 수정해야 할 수 있습니다.

규칙 #13: 단순하고 관찰 가능하며 추적 가능한 측정항목을 첫 번째 목표로 선택하라.

궁극적인 목표를 미리 알지 못하는 경우도 많습니다. 목표를 일단 정했다가도, 데이터를 관찰하고 이전 시스템과 새로운 ML 시스템을 나란히 분석하다 보면 목표를 수정하고 싶어집니다. 또한 궁극적인 목표에 대해 팀원들의 의견이 갈리기도 합니다. ML 목표는 측정하기 쉬우면서도 '진정한' 목표를 반영해야 합니다. 실제로는 '진정한' 목표가 존재하지 않는 경우도 많습니다(규칙 #39 참조). 따라서 단순한 ML 목표를 기준으로 학습하되, 또다른 로직(가급적 매우 단순한 로직)을 추가해 최종 순위를 결정할 수 있도록 '정책 레이어'를 상단에 두는 것이 좋습니다.

가장 모델링하기 쉬운 대상은 직접 관찰되고 시스템 동작과의 인과성을 추적할 수 있는 사용자 행동입니다.

• 순위 결정 대상 링크가 클릭되었는가?
• 순위 결정 대상 개체가 다운로드되었는가?
• 순위 결정 대상 개체가 전달되거나, 회신되거나, 이메일로 발송되었는가?
• 순위 결정 대상 개체가 평가되었는가?
• 표시 대상 개체가 스팸/음란물/불쾌감을 주는 콘텐츠로 신고되었는가?

간접 효과는 처음에는 모델링하지 마세요.

• 사용자가 다음 날 방문했는가?
• 사용자가 사이트를 얼마나 오래 방문했는가?
• 일일 활성 사용자 수는 몇인가?

간접 효과도 유용한 측정항목으로서 A/B 테스트 및 출시 결정에 활용될 수 있습니다.

마지막으로, 다음과 같은 의문을 해결하는 데 머신러닝을 동원하지 마세요.

• 사용자가 제품에 만족하고 있는가?
• 사용자 경험이 만족스러운가?
• 제품이 사용자의 전반적인 삶의 질을 높여주는가?
• 회사의 전반적인 건전성에 어떠한 영향을 줄 것인가?

이 모두가 중요한 의문점이지만 측정하기란 무척 어렵습니다. 간접적인 기준으로 대신하세요. 사용자가 만족감을 느낀다면 사이트에 더 오래 머무를 것입니다. 그뿐만 아니라 다음 날 다시 방문할 것입니다. 삶의 질이나 회사의 건전성과 관련해서는 머신러닝으로 도출된 목표를 판매할 제품 및 비즈니스 계획의 성격과 연결짓는 데 사람의 판단이 필수적입니다.

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

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

예를 들어 선형, 로지스틱 또는 푸아송 회귀에서는 데이터 중에서 평균 예측 기대값이 평균 라벨(1모멘트 보정 또는 균등 보정)과 일치하는 부분집합이 존재합니다. 이 사실은 정규화를 사용하지 않고 알고리즘이 수렴한다는 전제하에 항상 참이며, 일반적인 경우에는 근사적으로 참입니다. 각 예시에서 1 아니면 0인 특성이 있는 경우 해당 특성이 1인 예시 3개를 포함하는 집합이 보정됩니다. 또한 어떤 특성이 모든 예시에서 1이라면 모든 예시를 포함하는 집합이 보정됩니다.

단순 모델에서는 피드백 루프를 다루는 방법이 더 쉽습니다(규칙 #36 참조). 이러한 확률적 예측을 근거로 결정을 내리는 경우가 많습니다. 예를 들어 클릭 확률, 다운로드 확률 등의 기대값에 따라 내림차순으로 게시물의 순위를 매길 수 있습니다. 그러나 어떠한 모델을 사용할지 선택할 때는 모델에 제공된 데이터의 확률보다 결정 그 자체가 더욱 중요합니다(규칙 #27 참조).

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

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

이러한 두 시스템의 출력을 일정 수준에서 통합해야 합니다. 주의할 점으로, 검색결과의 스팸 필터링은 이메일 메시지의 스팸 필터링보다 더 과감해야 할 가능성이 높습니다. 이 사실은 정규화를 사용하지 않고 알고리즘이 수렴한다는 전제하에 항상 참이며, 일반적인 경우에는 근사적으로 참입니다. 또한 스팸은 품질 분류용 학습 데이터에서 제외하는 것이 일반적인 관행입니다.

ML 2단계: 특성 추출

머신러닝 시스템 수명 주기의 첫 단계에서 중요한 과제는 학습 시스템에 학습 데이터를 공급하고, 의미 있는 측정항목을 모두 계측하고, 서빙 인프라를 구축하는 것입니다. 단위 테스트와 시스템 테스트를 갖춘 정상적으로 작동하는 전체 시스템을 구축했다면 2단계로 넘어갈 수 있습니다.

2단계에서는 손쉬운 목표들이 널려 있습니다. 다양하고 알기 쉬운 특성들을 시스템에 집어넣으면 됩니다. 따라서 머신러닝 2단계에서는 최대한 많은 특성을 가져와서 직관적인 방식으로 결합하는 것이 관건입니다. 이 단계에서는 모든 측정항목이 상승세를 보여야 합니다. 출시를 여러 번 반복해야 하며, 많은 엔지니어를 동원하여 필요한 데이터를 모두 모아 학습 시스템의 역량을 극대화해야 할 시점입니다.

규칙 #16: 출시와 반복에 대비하라.

지금 작업 중인 모델이 마지막 출시 버전이 될 것이라거나, 반복적인 모델 출시가 언젠가는 끝나리라는 기대를 버리세요. 따라서 이번 출시에서 추가되는 복잡성으로 인해 이후 출시가 늦춰질 가능성이 있는지를 고려해야 합니다. 많은 팀에서 지금까지 몇 년 동안 분기당 1회 이상 출시를 진행했습니다. 새 모델을 출시하는 기본적인 3가지 이유는 다음과 같습니다.

• 새로운 특성 도입
• 정규화 조정 및 이전 특성을 새로운 방식으로 결합
• 목표 조정

모델에 애정이 어린 관심을 기울이면 좋은 결과가 나올 수 있습니다. 예시에 공급되는 데이터를 조사하여 새로운 지표 또는 잘못된 기존 지표를 찾아낼 수 있습니다. 따라서 모델을 만들어 나가면서 특성 추가, 삭제 또는 재결합이 얼마나 용이한지를 생각해야 합니다. 파이프라인의 사본을 새로 만들고 정확성을 검증하기가 얼마나 쉬운지 생각해 보세요. 둘 이상의 사본을 동시에 실행하는 방법이 가능한지 생각해 보세요. 마지막으로, 특정한 특성이 이번 파이프라인 버전에 포함될지 여부를 고민하지 마세요. 다음번 출시에 포함해도 됩니다.

규칙 #17: 학습된 특성이 아닌 직접 관찰 및 보고된 특성부터 시작하라.

논란의 여지가 있는 주장이지만, 많은 함정을 피해갈 수 있습니다. 우선 학습된 특성이란 무엇인지 알아보겠습니다. 학습된 특성은 외부 시스템(예: 비지도 클러스터링 시스템) 또는 학습 시스템 자체(예: 팩터링이 된 모델 또는 딥 러닝)에 의해 생성된 특성입니다. 이러한 특성도 유용할 수 있지만 여러 가지 문제점을 가질 수 있으므로 최초 모델에는 포함해서는 안 됩니다.

외부 시스템을 사용하여 특성을 만드는 경우 외부 시스템에는 자체의 목표가 있다는 점을 기억하세요. 외부 시스템의 목표는 나의 현재 목표와 상관성이 낮을 수 있습니다. 외부 시스템에서 스냅샷을 가져오는 경우 최신 데이터가 아닐 수 있습니다. 외부 시스템의 특성을 업데이트하는 경우 의미가 변질될 수 있습니다. 외부 시스템을 사용하여 특성을 제공하는 방식을 사용하려면 매우 신중한 접근법이 필요합니다.

팩터링 모델과 심층 모델의 가장 큰 문제는 볼록하지 않다는 성질에 있습니다. 따라서 최적의 해를 구하거나 근사할 수 있다는 보장이 없으며, 반복 시마다 서로 다른 국소적 최저점이 발견될 수 있습니다. 이러한 변이는 시스템 변경에 따르는 영향이 의미를 갖는지 아니면 무작위적인지를 판단하기 어렵게 만듭니다. 심층 특성이 없는 모델을 만들면 탁월한 기준 성능을 얻을 수 있습니다. 이 기준이 확보된 이후에 특이하고 복잡한 접근법을 시도하시기 바랍니다.

규칙 #18: 여러 컨텍스트로 일반화되는 콘텐츠 특성을 살펴라.

머신러닝 시스템은 더욱 거대한 시스템의 일부인 경우가 많습니다. 예를 들어 HOT 소식에 올라갈 만한 게시물은 HOT 소식에 올라가기도 전에 많은 사람의 +1, 재공유 또는 댓글을 받을 것입니다. 학습 시스템에 이러한 통계를 제공하면 최적화 컨텍스트와 관련하여 어떠한 데이터도 갖지 않는 새로운 게시물이 추천될 수 있습니다. YouTube의 다음 볼만한 동영상 기능에는 YouTube 검색에서 가져온 시청 횟수 또는 연계 시청 횟수(다른 동영상을 본 후 특정 동영상을 본 횟수)를 사용할 수 있습니다. 명시적인 사용자 평가를 사용할 수도 있습니다. 마지막으로, 라벨로 사용 중인 사용자 행동이 있다면 다른 컨텍스트의 자료에 대해 같은 행동을 파악하여 좋은 특성을 만들 수 있습니다. 이러한 모든 특성이 새로운 콘텐츠를 조명하는 데 기여합니다. 단, 개인별 파악은 여기에 해당하지 않습니다. 이 컨텍스트에서 콘텐츠를 좋아하는 사람이 있는지부터 알아낸 후에 누가 콘텐츠를 좋아하거나 싫어하는지를 알아내는 것이 순서입니다.

규칙 #19: 가능하면 매우 구체적인 특성을 사용하라.

수많은 데이터 속에서, 소수의 복잡한 특성보다는 다수의 단순한 특성을 학습하는 것이 더 간편합니다. 검색 대상 문서의 식별자 및 규격화된 쿼리는 일반화에 크게 기여하지 못하지만, 헤드 쿼리에서 순위와 라벨을 서로 맞춰주는 역할을 합니다. 따라서 특성 그룹에서 각 특성이 데이터의 매우 작은 부분에만 적용되더라도 전체 포함률이 90%를 넘는다면 걱정할 필요가 없습니다. 정규화를 사용하면 너무 적은 예시에 적용되는 특성을 배제할 수 있습니다.

규칙 #20: 사람이 이해할 수 있는 방식으로 기존 특성을 결합하고 수정하여 새 특성을 만들어라.

특성을 결합하고 수정하는 방법은 다양합니다. 텐서플로우 같은 머신러닝 시스템은 변환을 통해 데이터를 전처리하는 방법을 제공합니다. 가장 표준적인 두 가지 방식은 '불연속화' 및 '교차'입니다.

불연속화란 연속 특성으로부터 여러 불연속 특성을 만들어내는 과정입니다. 연속 특성의 예로 나이를 생각해 보겠습니다. 나이가 18세 미만이면 1인 특성, 18~35세이면 1인 특성 등을 차례로 만들 수 있습니다. 이러한 히스토그램의 경계에 대해 너무 고민하지 마세요. 기본적인 분위만 사용해도 대부분의 효과를 얻을 수 있습니다.

교차란 둘 이상의 특성 열을 결합한다는 의미입니다. 텐서플로우에서 사용하는 '특성 열'이라는 용어는 동질 특성으로 구성된 집합(예: {남성, 여성}, {미국, 캐나다, 멕시코})을 나타냅니다. 교차는 {남성, 여성} × {미국, 캐나다, 멕시코}의 특성으로 이루어진 새로운 특성 열입니다. 여기에는 (남성, 캐나다)와 같은 특성이 포함됩니다. 텐서플로우를 사용하는 경우 텐서플로우에 교차 생성을 지시하면 캐나다 남성을 나타내는 예시에 이(남성, 캐나다) 특성이 지정됩니다. 3가지, 4가지 또는 그 이상의 기본 특성 열을 교차하여 모델을 학습시키려면 막대한 양의 데이터가 필요합니다.

매우 큰 특성 열을 산출하는 교차는 과적합을 초래할 수 있습니다. 예를 들어 검색 기능을 만들면서 검색어의 단어를 포함하는 특성 열과 문서의 단어를 포함하는 특성 열을 준비할 수 있습니다. 이때 두 특성 열을 교차하여 결합하면 지나치게 많은 특성이 생성됩니다(규칙 #21 참조).

텍스트를 다룰 때는 두 가지 대안이 있습니다. 가장 엄격한 방법은 내적을 구하는 것입니다. 가장 단순한 형태의 내적은 검색어와 문서가 공통적으로 갖는 단어의 수를 세는 것입니다. 그런 다음 이 특성을 불연속화합니다. 다른 방법은 교집합을 구하는 것입니다. 즉, 'pony'라는 단어가 문서와 검색어에 모두 있을 때만 존재하는 특성 및 'the'라는 단어가 문서와 검색어에 모두 있을 때만 존재하는 특성을 준비하면 됩니다.

규칙 #21: 선형 모델에서 학습 가능한 특성 가중치의 개수는 데이터 보유량에 대략적으로 비례한다.

모델의 적절한 복잡도에 관한 훌륭한 통계 학습 이론이 많지만, 지금은 이 규칙만 명심하면 됩니다. 예시가 1,000개에 불과한데 무엇을 학습할 수 있을지 의심하는 사람들도 있었고, 예시가 100만 개 정도 있으면 특정한 학습 방식에 고착되므로 그 이상은 필요 없다고 생각하는 사람들도 있었습니다. 비결은 학습 규모를 데이터 규모에 맞추는 것입니다.

1. 검색 순위 시스템을 다루고 있으며 문서와 검색어에 수백만 가지 단어가 있는데 라벨이 있는 예는 1,000개뿐이라면 문서 특성과 검색어 특성의 내적, TF-IDF 및 인위적으로 추출된 몇 가지 특성을 사용해야 합니다. 1,000개의 예시에 10개 정도의 특성이 생깁니다.
2. 예시가 100만 개라면 정규화 및 특성 선택을 사용해 문서 특성 열과 검색어 특성 열의 교집합을 구합니다. 이를 통해 수백만 개의 특성이 산출되지만 정규화를 통해 특성이 감소합니다. 1,000만 개의 예시에 10만 개 정도의 특성이 생깁니다.
3. 예시가 수십억 또는 수천억 개라면 특성 선택 및 정규화를 사용해 특성 열을 문서 및 검색어 토큰과 교차할 수 있습니다. 10억 개의 예시에 1,000만 개의 특성이 생깁니다. 통계적 학습 이론은 절대적인 기준을 거의 제시하지 않지만 출발점으로 삼기에는 충분합니다.

마지막에는 규칙 #28에 따라 사용할 특성을 결정합니다.

규칙 #22: 더 이상 사용하지 않는 특성을 정리하라.

미사용 특성은 기술 부채가 됩니다. 더 이상 사용되지 않는 특성이 있고 다른 특성과 결합해도 유용성이 없는 경우 인프라에서 삭제하세요. 인프라를 깔끔하게 유지해야 가장 유망한 특성을 최대한 빠르게 시험해 볼 수 있습니다. 특성이 다시 필요해지면 언제든지 다시 추가할 수 있습니다.

추가하거나 유지할 특성을 결정할 때는 포괄 범위를 고려하세요. 특성이 얼마나 많은 예시를 포괄하나요? 예를 들어 개인별 맞춤 특성이 있는데 사용자 중 이 특성을 사용하는 비율이 8%에 불과하다면 높은 효율을 기대할 수 없습니다.

어떤 특성은 생각보다 큰 역할을 하기도 합니다. 예를 들어 데이터 중 1%만을 포괄하는 특성이 있는데 해당 특성을 갖는 예시 중 90%가 양성이라면 꼭 추가해야 할 특성입니다.

인간에 의한 시스템 분석

머신러닝의 세 번째 단계로 넘어가기 전에, 어떠한 머신러닝 강의에서도 다뤄지지 않는 주제를 짚고 넘어가겠습니다. 바로 기존 모델을 어떻게 바라보고 개선할지에 관한 것입니다. 이는 과학이라기보다 예술에 가깝지만, 바람직하지 않은 몇 가지 패턴을 피하는 데 도움이 됩니다.

규칙 #23: 나는 전형적인 최종 사용자가 아니다.

팀에서 난관에 부딪히는 가장 흔한 원인입니다. fishfood(팀 내에서 프로토타입 사용) 및 dogfood(회사 내에서 프로토타입 사용)에는 많은 장점이 있지만, 직원들은 성능의 정확성에 대해 살펴야 합니다. 단점이 분명한 변경사항을 피하는 것도 중요하지만, 프로덕션 단계에 근접했다고 판단되는 요소를 철저히 테스트하는 것이 더 중요합니다. 크라우드소싱 플랫폼에서 일반인을 대상으로 유료 설문조사를 진행하거나 실제 사용자를 대상으로 실험하는 방법이 있습니다.

여기에는 두 가지 이유가 있습니다. 우선, 개발자는 코드부터 신경을 쓰기 마련입니다. 게시물의 특정한 측면에만 주목하거나 지나치게 감정이 개입되어 확증 편향에 휩쓸릴 수 있습니다. 두 번째로, 개발자의 시간은 소중합니다. 엔지니어 9명이 1시간 동안 회의를 하는 데 소요되는 비용과, 그 비용으로 크라우드소싱 플랫폼에서 유료 설문조사를 진행하여 얻을 수 있는 라벨 수를 비교해 보세요.

사용자의 의견이 꼭 필요하다면 사용자 경험 방법론을 사용해 보세요. 프로세스 초기에 사용자 페르소나를 만들고(Bill Buxton의 Sketching User Experiences 참조) 이후에 사용성 테스트(Steve Krug의 Don’t Make Me Think 참조)를 진행하세요. 사용자 페르소나는 가상적인 사용자를 의미합니다. 예를 들어 팀원들이 전부 남성이라면 모든 사용자 특성을 갖춘 35세 여성 사용자 페르소나를 만들어 보세요. 그 결과는 25~40세 남성에 대한 결과 10개보다 더 도움이 됩니다. 또한 로컬이나 원격으로 사용성 테스트를 진행하여 사이트에 대한 실제 사용자의 반응을 조사하면 새로운 관점을 접할 수 있습니다.

규칙 #24: 모델 사이의 델타를 측정하라.

사용자가 새 모델을 접하기 전에 측정할 수 있는 가장 쉽고도 유용한 항목으로, 새로운 결과가 프로덕션의 기존 결과와 얼마나 다른지를 계산하는 것을 들 수 있습니다. 예를 들어 순위 결정 문제에서는 전체 시스템을 통해 쿼리 샘플을 대상으로 두 모델을 실행한 후 결과의 대칭 차 크기에 순위별 가중치를 적용하여 살펴볼 수 있습니다. 차이가 매우 작다면 별도의 실험을 거치지 않아도 변화가 거의 없을 것을 짐작할 수 있습니다. 차이가 매우 크다면 긍정적인 변화임을 확증할 수 있어야 합니다. 대칭 차가 크게 나온 쿼리를 살펴보면 변화의 본질적인 측면을 이해하는 데 도움이 됩니다. 그러나 중요한 것은 시스템의 안정성입니다. 모델을 자기 자신과 비교했을 때의 대칭 차가 낮은지 확인하세요. 0으로 나오면 가장 좋습니다.

규칙 #25: 모델을 선택할 때는 예측 능력보다 실용적인 성능을 우선시하라.

모델에서 클릭률을 예측하려고 할 수 있습니다. 그러나 결국 중요한 질문은 그 예측으로 무엇을 할 지입니다. 문서의 순위를 결정하는 데 활용할 생각이라면 예측 자체보다는 최종적인 순위의 품질이 더 중요합니다. 문서가 스팸일 확률을 예측하여 차단 기준을 정할 계획이라면 허용되는 대상의 정확성이 가장 중요합니다. 대부분의 경우에는 이러한 두 관점이 조화를 이루지만, 그렇지 않다면 소탐대실의 상황이 될 수 있습니다. 따라서 어떠한 변화가 로그 손실은 개선하지만 시스템의 성능을 떨어뜨린다면 다른 특성으로 눈을 돌려야 합니다. 이러한 상황이 자주 나타나기 시작하면 모델의 목표를 재검토하시기 바랍니다.

규칙 #26: 측정 오차에서 패턴을 찾아 새 특성을 만들어라.

모델에서 '잘못' 예측한 학습 예시를 발견했다고 가정해 보겠습니다. 분류 작업의 경우 거짓양성이나 거짓음성이 여기에 해당합니다. 순위 결정 작업에서는 양성과 음성으로 이루어진 쌍에서 양성이 음성보다 순위가 낮게 매겨진 경우일 수 있습니다. 가장 중요한 점은, 해당 예시는 머신러닝 시스템에서 예측이 잘못되었음을 스스로 알고 있으므로 기회가 있으면 수정이 가능하다는 것입니다. 오류를 수정할 수 있는 특성을 모델에 제공하면 모델은 이 특성을 사용하려고 합니다.

반면, 시스템에서 실수를 깨닫지 못한 예시를 기반으로 만들어진 특성은 무시됩니다. 예를 들어 Play 앱 검색에서 사용자가 '무료 게임'을 검색했는데, 최상위 결과 중 하나에 관련성이 떨어지는 개그 앱이 포함되었습니다. 따라서 '개그 앱'에 관한 특성을 만들었습니다. 그러나 설치 횟수를 극대화하는 것이 목표인 경우 무료 게임을 검색하는 사용자들이 개그 앱을 많이 설치한다면 '개그 앱' 특성은 의도한 효과를 낼 수 없습니다.

모델에서 잘못 예측한 예시를 확보했으면 현재 특성 집합을 벗어나는 추세를 찾습니다. 예를 들어 시스템에서 긴 게시물의 순위를 낮추는 경향이 발견되면 게시물 길이를 추가합니다. 추가할 특성을 너무 구체적으로 고민하지 마세요. 게시물 길이를 추가할 생각이라면 길다는 의미의 기준을 어림짐작하려 애쓸 필요가 없습니다. 단순히 10여 개의 특성을 추가한 후 모델이 알아서 판단하도록 놔두세요(규칙 #21 참조). 이것이 원하는 효과를 얻는 가장 쉬운 방법입니다.

규칙 #27: 부적절한 동작이 관찰되면 정량화를 시도하라.

시스템에 바람직하지 않은 속성이 있는데 기존 손실 함수로는 포착되지 않아서 난관에 부딪히는 상황이 나올 수 있습니다. 이러한 경우 어떤 수를 써서라도 불만족스러운 점을 구체적인 숫자로 바꿔놓아야 합니다. 예를 들어 Play 검색에 '개그 앱'이 너무 많이 표시된다고 생각되면 인간 평가자에게 개그 앱을 판별하도록 의뢰할 수 있습니다. 이 경우에는 쿼리 중 비교적 적은 비율이 트래픽에서 큰 비중을 차지하므로 사람이 라벨링한 데이터를 사용해도 무리가 없습니다. 이렇게 측정 가능한 문제점이라면 이제부터 특성, 목표 또는 측정항목으로 사용할 수 있습니다. 일반적인 규칙은 '측정 후 최적화'입니다.

규칙 #28: 단기적인 동작이 같더라도 장기적인 동작은 다를 수 있다.

모든 doc_id와 exact_query를 조사하여 모든 문서, 모든 쿼리에 관한 클릭 확률을 계산하는 시스템을 새로 구축했다고 가정해 보겠습니다. 현재 시스템보다 단순하면서도 병렬 운용 및 A/B 테스트 결과가 현재 시스템과 거의 일치하는 것으로 나타나자 출시를 결정했습니다. 그런데 새 앱이 표시되지 않는 문제를 발견했습니다. 왜 그럴까요? 이 시스템은 자체 기록을 기반으로 해당 쿼리에 관한 문서만을 보여주므로 새 문서를 표시해야 한다는 사실을 학습할 방법이 없습니다.

이러한 시스템이 장기적으로 어떻게 작동할지 알아내는 유일한 방법은 모델이 실제로 운영될 때 획득한 데이터로만 학습하는 것인데, 이는 매우 어려운 일입니다.

학습-서빙 격차

학습-서빙 격차란 학습 시 성능과 서빙 시 성능 간의 차이를 뜻합니다. 이러한 격차의 원인은 다음과 같습니다.

• 학습 파이프라인과 서빙 파이프라인에서 데이터를 처리하는 방법의 차이
• 학습 시 데이터와 제공 시 데이터 간의 변화
• 모델과 알고리즘 간의 피드백 루프

Google의 프로덕션 머신러닝 시스템에서도 학습-서빙 격차로 인해 성능이 저하된 경우가 있었습니다. 가장 좋은 해법은 시스템과 데이터의 변화로 인해 예기치 않은 격차가 생기지 않도록 직접 모니터링하는 것입니다.

규칙 #29: 학습 환경을 서빙 환경과 일치시키는 최선의 방법은 서빙 시에 사용된 특성 세트를 저장해 두었다가 로그에 공급하여 학습 시에 사용하는 것이다.

모든 예시에 대해서 불가능하다면 일부 예시에 대해서라도 실천하여 서빙과 학습의 일관성을 검증할 방법을 강구해야 합니다(규칙 #37 참조). Google의 여러 팀에서도 이러한 측정을 통해 의외의 결과를 얻은 바 있습니다. YouTube 홈페이지는 서빙 시 특성 로그 기록을 도입하여 품질을 크게 높이면서 코드의 복잡성을 낮추었으며, 지금 이 순간에도 여러 팀에서 인프라를 전환하고 있습니다.

규칙 #30: 표본 추출된 데이터를 임의로 무시하지 말고 중요도에 따라 가중치를 매겨라.

데이터가 너무 많으면 파일 1~12만 사용하고, 파일 13~99는 무시하고 싶을 수도 있습니다. 하지만 잘못된 생각입니다. 사용자에게 한 번도 표시되지 않은 데이터는 삭제해도 무방하지만, 나머지 데이터에는 중요도 가중치를 적용하는 것이 가장 좋습니다. 중요도 가중치란 예시 X를 샘플링할 확률이 30%라면 10/3의 가중치를 준다는 의미입니다. 중요도 가중치를 사용하는 경우에도 규칙 #14에서 설명한 보정 속성이 모두 적용됩니다.

규칙 #31: 학습 및 서빙 시에 테이블의 데이터를 조인하는 경우 테이블의 데이터는 달라질 수 있음을 명심하라.

문서 ID를 해당 문서의 댓글수 또는 클릭수 등의 특성을 담은 테이블과 조인한다고 가정해 보겠습니다. 학습 시점과 서빙 시점 사이에 테이블의 특성이 달라질 수 있습니다. 이러한 경우 학습과 서빙 간에 같은 문서에 관한 모델의 예측이 서로 달라집니다. 이와 같은 문제를 피하는 가장 쉬운 방법은 서빙 시에 특성을 기록하는 것입니다(규칙 #32 참조). 테이블의 변화가 비교적 느리다면 1시간 또는 하루마다 테이블의 스냅샷을 만들어 적당히 근접한 데이터를 얻을 수 있습니다. 그러나 문제가 완벽하게 해결되는 것은 아닙니다.

규칙 #32: 가능하면 학습 파이프라인과 서빙 파이프라인 간에 코드를 재사용하라.

일괄 처리는 온라인 처리와 다릅니다. 온라인 처리에서는 도착하는 각 요청을 실시간으로 처리해야 하므로 각 쿼리에 대해 별도의 조회를 수행하는 반면, 일괄 처리에서는 여러 작업을 조인 등의 방법으로 결합할 수 있습니다. 서빙 시에는 온라인 처리를 수행하는 반면, 학습은 일괄 처리 작업입니다. 그러나 코드를 재사용할 수 있는 방법이 몇 가지 있습니다. 예를 들어 모든 쿼리 또는 조인의 결과를 사람이 읽을 수 있는 방식으로 저장하는 시스템 고유 개체를 만들면 오류를 쉽게 테스트할 수 있습니다. 그런 다음 모든 정보가 수집되었으면 서빙 또는 학습 중에 공통 메소드를 실행하여 사람이 읽을 수 있는 시스템 고유 개체와 머신러닝 시스템에 사용되는 형식 사이에 다리를 놓습니다. 이렇게 하면 학습-서빙 격차가 근본적으로 방지됩니다. 이렇게 하려면 우선 학습 코드와 서빙 코드에 동일한 프로그래밍 언어를 사용해야 합니다. 그렇지 않으면 코드를 공유하기가 거의 불가능합니다.

규칙 #33: 1월 5일까지 수집된 데이터를 기준으로 모델을 생성하는 경우 1월 6일 이후의 데이터로 모델을 테스트하라.

일반적인 규칙은 모델 학습에 사용된 데이터보다 이후에 수집된 데이터로 모델의 성능을 측정하는 것입니다. 이렇게 하면 시스템의 프로덕션 성능을 더 정확히 예상할 수 있습니다. 1월 5일까지 수집된 데이터를 기준으로 모델을 생성하는 경우 1월 6일 이후의 데이터로 모델을 테스트하세요. 새 데이터에 관한 성능은 기존 데이터보다 다소 저하되는 것이 정상이지만 크게 나빠져서는 안 됩니다. 우연한 일별 변동이 작용할 수 있으므로 평균적인 클릭률 또는 전환율이 나오지 않을 수도 있지만, 양성 예시가 음성 예시보다 1점 높게 나올 가능성을 나타내는 AUC는 합리적인 수준의 유사성을 보여야 합니다.

규칙 #34: 스팸 감지, 관심 이메일 판단 등 필터링을 위한 이진 분류에서는 단기적으로 다소의 성능 저하를 감수하더라도 데이터를 철저히 정제하라.

필터링 작업에서는 음성으로 판정된 예시를 사용자로부터 숨깁니다. 서빙 시 음성 예시의 75%를 차단하는 필터가 있다고 가정해 보겠습니다. 사용자에게 표시된 인스턴스로부터 추가적인 학습 데이터를 추출하려는 생각이 들 수 있습니다. 예를 들어 필터를 통과했지만 사용자가 스팸으로 신고한 이메일은 학습 데이터로 활용할 수 있습니다.

그러나 이 접근법은 샘플링 편향을 유발합니다. 더 정제된 데이터를 얻는 방법은 서빙 시 전체 트래픽 중 1%를 '홀드아웃'으로 라벨링하고 모든 홀드아웃 예시를 사용자에게 보내는 것입니다. 이제 필터는 음성 예시 중에서 최소 74%를 차단합니다. 이러한 홀드아웃 예시는 학습 데이터가 될 수 있습니다.

필터가 음성 예시의 95% 이상을 차단한다면 이 접근법은 현실성이 낮습니다. 그렇더라도 서빙 성능을 측정하려는 경우 소량의 샘플(0.1% 또는 0.001%)을 추출할 수 있습니다. 1만 개 정도의 예시가 있으면 성능을 비교적 정확히 추정할 수 있습니다.

규칙 #35: 순위 결정 문제에서는 특유의 왜곡이 나타날 수 있다.

표시되는 결과가 바뀔 정도로 순위 결정 알고리즘을 급격히 변경하면 알고리즘에서 이후에 접하게 될 데이터 자체가 변화하는 결과를 낳습니다. 이러한 유형의 왜곡이 나타날 것을 대비하여 모델을 설계해야 합니다. 여기에는 여러 가지 접근법이 있으며, 공통점은 모델에서 기존에 접한 데이터를 우선시한다는 점입니다.

1. 쿼리 하나에만 해당하는 특성 보다 여러 쿼리를 포괄하는 특성에 더 높은 정규화를 적용합니다. 이렇게 하면 모델에서 모든