머신러닝의 규칙:

ML 엔지니어링 권장사항

마틴 징케비치

이 문서는 머신러닝에 대한 기본 지식이 있는 사용자가 머신러닝에 관한 Google의 권장사항을 활용하는 데 도움이 되도록 작성되었습니다. Google C++ 스타일 가이드 및 기타 인기 있는 실용적인 프로그래밍 가이드와 마찬가지로 머신러닝 스타일을 제시합니다. 머신러닝 수업을 수강했거나 머신러닝 모델을 빌드하거나 작업한 적이 있다면 이 문서를 읽는 데 필요한 배경지식이 있는 것입니다.

마틴 징케비치가 자신이 가장 좋아하는 머신러닝 규칙 10가지를 소개합니다. 43가지 규칙을 모두 알아보려면 계속 읽어보세요.

용어

효과적인 머신러닝에 관해 논의할 때 다음 용어가 반복적으로 등장합니다.

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

개요

우수한 제품을 만들려면 다음 단계를 따르세요.

훌륭한 머신러닝 전문가가 아닌 훌륭한 엔지니어처럼 머신러닝을 수행하세요.

실제로 직면하게 되는 대부분의 문제는 엔지니어링 문제입니다. 뛰어난 머신러닝 전문가의 모든 리소스를 활용하더라도 대부분의 이익은 뛰어난 머신러닝 알고리즘이 아닌 우수한 기능에서 비롯됩니다. 따라서 기본 접근 방식은 다음과 같습니다.

  1. 파이프라인이 처음부터 끝까지 확실한지 확인합니다.
  2. 합리적인 목표로 시작합니다.
  3. 상식적인 기능을 간단하게 추가하세요.
  4. 파이프라인이 안정적으로 유지되는지 확인합니다.

이 접근 방식은 장기간에 걸쳐 효과적입니다. 더 나아갈 수 있는 간단한 방법이 더 이상 없을 때만 이 접근 방식에서 벗어나세요. 복잡성을 추가하면 향후 출시 속도가 느려집니다.

간단한 트릭을 모두 사용해 본 후에는 최신 머신러닝을 사용해 볼 수 있습니다. 3단계 머신러닝 프로젝트 섹션을 참고하세요.

이 문서는 다음과 같이 구성됩니다.

  1. 첫 번째 부분에서는 머신러닝 시스템을 구축하기에 적절한 시점인지를 파악하는 데 도움이 됩니다.
  2. 두 번째 부분에서는 첫 번째 파이프라인을 배포하는 방법을 설명합니다.
  3. 세 번째 부분에서는 파이프라인에 새 기능을 추가하면서 시작하고 반복하는 방법, 모델 및 학습-서빙 편향을 평가하는 방법을 설명합니다.
  4. 마지막 부분에서는 정체기에 도달했을 때 취해야 할 조치에 대해 설명합니다.
  5. 그다음에는 관련 작업 목록과 이 문서에서 예로 자주 사용되는 시스템에 관한 배경 정보가 포함된 부록이 나옵니다.

머신러닝 이전

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

머신러닝은 멋지지만 데이터가 필요합니다. 이론적으로는 다른 문제의 데이터를 가져와 새 제품에 맞게 모델을 조정할 수 있지만, 이 경우 기본 휴리스틱보다 성능이 저하될 가능성이 높습니다. 머신러닝이 100% 의 실적 향상을 가져다줄 것이라고 생각한다면 휴리스틱은 50%의 실적 향상을 가져다줄 것입니다.

예를 들어 앱 마켓플레이스에서 앱 순위를 매기는 경우 설치율 또는 설치 수를 휴리스틱으로 사용할 수 있습니다. 스팸을 감지하는 경우 이전에 스팸을 보낸 게시자를 필터링합니다. 사람의 손으로 수정하는 것도 두려워하지 마세요. 연락처 순위를 지정해야 하는 경우 가장 최근에 사용한 연락처를 가장 높은 순위로 지정하거나 알파벳순으로 지정합니다. 제품에 머신러닝이 절대적으로 필요하지 않은 경우 데이터가 확보될 때까지 사용하지 마세요.

규칙 2: 먼저 측정항목을 설계하고 구현합니다.

머신러닝 시스템이 수행할 작업을 공식화하기 전에 현재 시스템에서 최대한 많은 항목을 추적합니다. 다음과 같은 이유로 이 작업을 수행합니다.

  1. 시스템 사용자로부터 권한을 얻는 것이 더 쉽습니다.
  2. 향후 문제가 될 수 있다고 생각되면 지금 과거 데이터를 가져오는 것이 좋습니다.
  3. 측정항목 계측을 염두에 두고 시스템을 설계하면 향후 더 나은 결과를 얻을 수 있습니다. 특히 측정항목을 계측하기 위해 로그에서 문자열을 grep하는 것은 바람직하지 않습니다.
  4. 변경되는 사항과 변경되지 않는 사항을 확인할 수 있습니다. 예를 들어 하루 동안의 활성 사용자를 직접 최적화하려고 한다고 가정해 보겠습니다. 하지만 시스템을 조작하는 초기에는 사용자 환경을 크게 변경해도 이 측정항목이 눈에 띄게 달라지지 않을 수 있습니다.

Google Plus팀은 게시물 게재 시 게시물의 품질을 계산하는 데 사용하는 읽기당 확장, 읽기당 재공유, 읽기당 +1, 읽기당 댓글, 사용자당 댓글, 사용자당 재공유 등을 측정합니다. 또한 사용자를 버킷으로 그룹화하고 실험별로 통계를 집계할 수 있는 실험 프레임워크도 중요합니다. 규칙 12를 참고하세요.

측정항목 수집에 더 관대하게 임하면 시스템을 더 폭넓게 파악할 수 있습니다. 문제가 있나요? 측정항목을 추가하여 추적하세요. 지난 출시에서 양적 변화가 있었나요? 측정항목을 추가하여 추적하세요.

규칙 3: 복잡한 휴리스틱 대신 머신러닝을 선택하세요.

간단한 휴리스틱을 사용하면 제품을 출시할 수 있습니다. 복잡한 휴리스틱은 유지 관리할 수 없습니다. 데이터와 달성하려는 목표에 대한 기본적인 아이디어를 얻은 후 머신러닝으로 넘어갑니다. 대부분의 소프트웨어 엔지니어링 작업과 마찬가지로 휴리스틱 모델이든 머신러닝 모델이든 접근 방식을 지속적으로 업데이트해야 하며, 머신러닝 모델은 업데이트하고 유지관리하기가 더 쉽습니다 (규칙 16 참고).

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

첫 번째 파이프라인의 시스템 인프라에 집중하세요. 머신러닝으로 할 수 있는 다양한 작업을 생각하는 것은 즐겁지만, 먼저 파이프라인을 신뢰하지 않으면 어떤 일이 일어나고 있는지 파악하기 어렵습니다.

규칙 4: 첫 번째 모델은 간단하게 유지하고 인프라는 올바르게 설정합니다.

첫 번째 모델은 제품에 가장 큰 부스트를 제공하므로 화려할 필요가 없습니다. 하지만 예상보다 훨씬 더 많은 인프라 문제가 발생합니다. 다른 사용자가 멋진 새 머신러닝 시스템을 사용하려면 먼저 다음을 결정해야 합니다.

  • 학습 알고리즘에 예시를 가져오는 방법
  • 시스템에 '좋음'과 '나쁨'이 어떤 의미인지에 대한 첫 번째 기준입니다.
  • 모델을 애플리케이션에 통합하는 방법 모델을 실시간으로 적용하거나 예시에서 모델을 오프라인으로 사전 계산하고 결과를 테이블에 저장할 수 있습니다. 예를 들어 웹페이지를 사전 분류하고 결과를 표에 저장할 수 있지만 채팅 메시지는 실시간으로 분류해야 할 수 있습니다.

간단한 기능을 선택하면 다음을 더 쉽게 할 수 있습니다.

  • 기능이 학습 알고리즘에 올바르게 도달합니다.
  • 모델은 합리적인 가중치를 학습합니다.
  • 기능이 서버의 모델에 올바르게 도달합니다.

이러한 세 가지 작업을 안정적으로 실행하는 시스템을 갖추면 대부분의 작업이 완료된 것입니다. 단순한 모델은 더 복잡한 모델을 테스트하는 데 사용할 수 있는 기준 측정항목과 기준 동작을 제공합니다. 일부 팀은 '중립적' 첫 출시를 목표로 합니다. 즉, 방해받지 않도록 머신러닝 이득의 우선순위를 명시적으로 낮추는 첫 출시입니다.

규칙 5: 머신러닝과 별개로 인프라를 테스트합니다.

인프라가 테스트 가능하고 시스템의 학습 부분이 캡슐화되어 있어 주변의 모든 항목을 테스트할 수 있는지 확인합니다. 구체적으로는 다음과 같습니다.

  1. 알고리즘에 데이터를 가져오는 것을 테스트합니다. 채워야 하는 지형지물 열이 채워졌는지 확인합니다. 개인 정보 보호가 허용하는 경우 학습 알고리즘의 입력을 수동으로 검사합니다. 가능하면 파이프라인의 통계를 다른 곳에서 처리된 동일한 데이터의 통계와 비교하세요.
  2. 학습 알고리즘에서 모델을 가져오는 것을 테스트합니다. 학습 환경의 모델이 제공 환경의 모델과 동일한 점수를 산출하는지 확인합니다 (규칙 37 참고).

머신러닝에는 예측할 수 없는 요소가 있으므로 학습 및 제공 시 예시를 만드는 코드에 관한 테스트가 있고 제공 중에 고정된 모델을 로드하고 사용할 수 있는지 확인하세요. 또한 데이터를 이해하는 것도 중요합니다. 대규모의 복잡한 데이터 세트 분석을 위한 실용적인 조언을 참고하세요.

규칙 6: 파이프라인을 복사할 때 누락된 데이터에 주의합니다.

종종 기존 파이프라인을 복사하여 파이프라인을 만들고 (카고 컬트 프로그래밍) 이전 파이프라인이 새 파이프라인에 필요한 데이터를 삭제합니다. 예를 들어 Google 플러스 인기 급상승의 파이프라인은 최신 게시물의 순위를 매기려고 하므로 이전 게시물을 삭제합니다. 이 파이프라인은 이전 게시물이 여전히 의미가 있는 Google Plus 스트림에 사용하기 위해 복사되었지만 파이프라인에서 여전히 이전 게시물을 삭제했습니다. 또 다른 일반적인 패턴은 사용자가 본 데이터만 로깅하는 것입니다. 따라서 이 데이터는 모든 부정적 예시가 삭제되었기 때문에 특정 게시물이 사용자에게 표시되지 않은 이유를 모델링하는 데는 쓸모가 없습니다. Play에서도 유사한 문제가 발생했습니다. Play 앱 홈을 작업하는 동안 각 예시의 출처를 구분하는 기능 없이 Play 게임즈 방문 페이지의 예시도 포함된 새 파이프라인이 만들어졌습니다.

규칙 7: 휴리스틱을 기능으로 전환하거나 외부에서 처리합니다.

일반적으로 머신러닝이 해결하려는 문제는 완전히 새로운 문제가 아닙니다. 해결하려는 문제를 순위 지정하거나 분류하는 기존 시스템이 있습니다. 즉, 여러 규칙과 휴리스틱이 있습니다. 이러한 휴리스틱을 머신러닝으로 조정하면 실적을 높일 수 있습니다. 휴리스틱은 두 가지 이유로 보유한 모든 정보를 위해 마이닝해야 합니다. 첫째, 머신 학습 시스템으로의 전환이 더 원활해집니다. 두 번째로, 이러한 규칙에는 보통 버리고 싶지 않은 시스템에 관한 직관이 많이 포함되어 있습니다. 기존 휴리스틱을 사용하는 방법에는 다음 4가지가 있습니다.

  • 휴리스틱을 사용하여 사전 처리합니다. 기능이 정말 멋진 경우 이 옵션을 사용할 수 있습니다. 예를 들어 스팸 필터에서 발신자가 이미 차단 목록에 추가된 경우 '차단 목록'의 의미를 다시 배우려고 하지 마세요. 메시지를 차단합니다. 이 접근 방식은 이진 분류 작업에 가장 적합합니다.
  • 지형지물을 만듭니다. 휴리스틱에서 직접 특성을 만드는 것이 좋습니다. 예를 들어 휴리스틱을 사용하여 검색 결과의 관련성 점수를 계산하는 경우 점수를 특징의 값으로 포함할 수 있습니다. 나중에 머신러닝 기법을 사용하여 값을 수정할 수 있습니다(예: 값을 개별 값의 유한 집합 중 하나로 변환하거나 다른 기능과 결합). 하지만 먼저 휴리스틱에서 생성된 원시 값을 사용합니다.
  • 휴리스틱의 원시 입력을 마이닝합니다. 설치 수, 텍스트의 문자 수, 요일을 결합하는 앱에 대한 휴리스틱이 있는 경우 이러한 부분을 분리하고 이러한 입력을 학습에 별도로 제공하는 것이 좋습니다. 앙상블에 적용되는 일부 기법이 여기에도 적용됩니다 (규칙 40 참고).
  • 라벨을 수정합니다. 휴리스틱이 현재 라벨에 포함되지 않은 정보를 포착한다고 생각되는 경우에 사용할 수 있는 옵션입니다. 예를 들어 다운로드 수를 최대화하면서 양질의 콘텐츠도 제공하려는 경우 라벨에 앱이 받은 평균 별표 수를 곱하는 것이 해결책일 수 있습니다. 여기서는 여유가 많습니다. '첫 번째 목표'를 참고하세요.

ML 시스템에서 휴리스틱을 사용할 때는 추가되는 복잡성에 유의하세요. 새 머신러닝 알고리즘에 이전 휴리스틱을 사용하면 원활한 전환을 만드는 데 도움이 될 수 있지만, 동일한 효과를 얻는 더 간단한 방법이 있는지 생각해 보세요.

모니터링

일반적으로 알림을 실행 가능한 알림으로 만들고 대시보드 페이지를 만드는 등 알림 위생을 잘 지키는 것이 좋습니다.

규칙 8: 시스템의 최신성 요구사항을 숙지합니다.

하루 된 모델을 사용하면 성능이 얼마나 저하되나요? 1주일 전 4분의 1 정도? 이 정보는 모니터링의 우선순위를 파악하는 데 도움이 될 수 있습니다. 모델이 하루 동안 업데이트되지 않으면 제품 품질이 크게 저하되는 경우 엔지니어가 지속적으로 모니터링하는 것이 좋습니다. 대부분의 광고 게재 시스템에는 매일 처리해야 할 새로운 광고가 있으며 매일 업데이트해야 합니다. 예를 들어 Google Play 검색의 ML 모델이 업데이트되지 않으면 한 달 이내에 부정적인 영향을 미칠 수 있습니다. Google 플러스의 인기 급상승에 관한 일부 모델에는 게시물 식별자가 없으므로 이러한 모델은 자주 내보낼 수 없습니다. 게시물 식별자가 있는 다른 모델은 훨씬 더 자주 업데이트됩니다. 또한 최신성은 시간이 지남에 따라, 특히 모델에서 특성 열이 추가되거나 삭제될 때 변경될 수 있습니다.

규칙 9: 모델을 내보내기 전에 문제를 감지합니다.

많은 머신러닝 시스템에는 모델을 제공하도록 내보내는 단계가 있습니다. 내보낸 모델에 문제가 있는 경우 사용자에게 표시되는 문제입니다.

모델을 내보내기 직전에 유효성 검사를 실행합니다. 특히 홀드아웃 데이터에서 모델의 성능이 적절한지 확인합니다. 또는 데이터에 관해 우려되는 점이 있는 경우 모델을 내보내지 마세요. 모델을 지속적으로 배포하는 많은 팀은 내보내기 전에 ROC 곡선(또는 AUC) 아래 영역을 확인합니다. 내보내지 않은 모델에 관한 문제는 이메일 알림이 필요하지만 사용자 대상 모델의 문제는 페이지가 필요할 수 있습니다. 따라서 사용자에게 영향을 미치기 전에 기다렸다가 확실히 하는 것이 좋습니다.

규칙 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단계가 시작됩니다.

두 번째 단계에는 손쉬운 과제가 많습니다. 시스템에 가져올 수 있는 명백한 기능이 다양합니다. 따라서 머신러닝의 두 번째 단계는 최대한 많은 기능을 가져와 직관적인 방식으로 결합하는 것입니다. 이 단계에서는 모든 측정항목이 계속 증가해야 합니다. 출시가 많이 있을 예정이므로 정말 멋진 학습 시스템을 만드는 데 필요한 모든 데이터를 결합할 수 있는 엔지니어를 많이 영입할 수 있는 좋은 기회입니다.

규칙 16: 출시 및 반복 계획

지금 작업 중인 모델이 마지막으로 출시할 모델이거나 모델 출시를 중단할 것이라고 기대하지 마세요. 따라서 이번 출시에서 추가하는 복잡성으로 인해 향후 출시 속도가 느려질지 고려하세요. 많은 팀이 수년 동안 분기당 하나 이상의 모델을 출시해 왔습니다. 새 모델을 출시하는 데는 세 가지 기본적인 이유가 있습니다.

  • 새로운 기능을 개발하고 있습니다.
  • 정규화를 조정하고 기존 기능을 새로운 방식으로 결합하고 있습니다.
  • 목표를 조정하고 있습니다.

어쨌든 모델을 조금만 살펴보는 것이 좋습니다. 예시로 제공되는 데이터를 살펴보면 새 신호와 오래된 손상된 신호를 찾는 데 도움이 될 수 있습니다. 따라서 모델을 빌드할 때는 특성을 추가, 삭제 또는 재조합하는 것이 얼마나 쉬운지 생각해 보세요. 파이프라인의 새 사본을 만들고 올바른지 확인하는 것이 얼마나 쉬운지 생각해 보세요. 두 개 또는 세 개의 사본을 동시에 실행할 수 있는지 고려합니다. 마지막으로 35개 기능 중 16개 기능이 이 버전의 파이프라인에 포함되는지 여부는 걱정하지 마세요. 다음 분기에 지급됩니다.

규칙 17: 학습된 기능이 아닌 직접 관찰되고 보고된 기능으로 시작합니다.

이는 논란의 소지가 있지만 많은 함정을 피할 수 있습니다. 먼저 학습된 특성이 무엇인지 설명하겠습니다. 학습된 특성은 외부 시스템 (예: 비감독 클러스터링 시스템) 또는 학습자 자체 (예: 분해된 모델 또는 딥 러닝을 통해)에서 생성된 특성입니다. 둘 다 유용할 수 있지만 문제가 많을 수 있으므로 첫 번째 모델에는 포함해서는 안 됩니다.

외부 시스템을 사용하여 기능을 만드는 경우 외부 시스템에 자체 목표가 있음을 기억하세요. 외부 시스템의 목표는 현재 목표와 약하게만 관련될 수 있습니다. 외부 시스템의 스냅샷을 가져오면 오래될 수 있습니다. 외부 시스템에서 기능을 업데이트하면 의미가 변경될 수 있습니다. 외부 시스템을 사용하여 기능을 제공하는 경우 이 접근 방식에는 각별한 주의가 필요합니다.

분해된 모델과 심층 모델의 주요 문제는 이들이 ­볼록하지 않다는 것입니다. 따라서 최적의 솔루션을 근사하거나 찾을 수 있다는 보장은 없으며 각 반복에서 발견된 로컬 최솟값이 다를 수 있습니다. 이러한 변동으로 인해 시스템 변경사항의 영향이 의미 있는 것인지 무작위인지 판단하기가 어렵습니다. 심층 기능이 없는 모델을 만들면 우수한 기준 성능을 얻을 수 있습니다. 이 기준을 달성한 후에는 더 난해한 접근 방식을 시도할 수 있습니다.

규칙 18: 컨텍스트 전반에서 일반화되는 콘텐츠 기능을 사용하여 탐색합니다.

머신러닝 시스템은 훨씬 더 큰 그림의 일부인 경우가 많습니다. 예를 들어 인기 급상승에 사용될 수 있는 게시물을 생각해 보세요. 인기 급상승에 표시되기 전에 많은 사용자가 게시물에 좋아요를 누르거나 다시 공유하거나 댓글을 달 것입니다. 학습자에게 이러한 통계를 제공하면 최적화하는 맥락에 데이터가 없는 새 게시물을 홍보할 수 있습니다. YouTube의 '다음 볼만한 동영상'은 YouTube 검색의 조회수 또는 공동 시청수 (한 동영상을 시청한 후 다른 동영상을 시청한 횟수)를 사용할 수 있습니다. 명시적인 사용자 평점을 사용할 수도 있습니다. 마지막으로 라벨로 사용하는 사용자 작업이 있는 경우 문서에서 다른 컨텍스트로 해당 작업을 확인하는 것이 유용할 수 있습니다. 이러한 모든 기능을 통해 컨텍스트에 새로운 콘텐츠를 가져올 수 있습니다. 이는 맞춤설정에 관한 것이 아닙니다. 먼저 사용자가 이 맥락에서 콘텐츠를 좋아하는지 확인한 다음 콘텐츠를 더 좋아하거나 덜 좋아하는 사용자를 파악합니다.

규칙 19: 가능하면 매우 구체적인 기능을 사용하세요.

대량의 데이터를 사용하면 복잡한 기능 몇 개를 학습하는 것보다 간단한 기능 수백만 개를 학습하는 것이 더 쉽습니다. 검색되고 정규화된 쿼리의 문서 식별자는 일반화를 많이 제공하지 않지만, 상위 쿼리의 라벨과 순위를 조정합니다. 따라서 각 지형지물이 데이터의 일부분에만 적용되지만 전체 노출 범위가 90%를 초과하는 지형지물 그룹은 두려워하지 마세요. 정규화를 사용하여 너무 적은 수의 예에 적용되는 특성을 제거할 수 있습니다.

규칙 20: 기존 기능을 결합하고 수정하여 인간이 이해할 수 있는 방식으로 새로운 기능을 만듭니다.

지형지물을 결합하고 수정하는 방법에는 여러 가지가 있습니다. TensorFlow와 같은 머신러닝 시스템을 사용하면 변환을 통해 데이터를 사전 처리할 수 있습니다. 가장 표준적인 두 가지 접근 방식은 '디스크리트화'와 '교차'입니다.

디스크리트화는 연속적인 특성을 취하여 여러 개의 불연속적인 특성을 만드는 것으로 구성됩니다. 연령과 같은 연속형 특성을 고려해 보세요. 연령이 18세 미만일 때 1이고, 연령이 18~35세일 때 1인 다른 기능을 만들 수 있습니다. 이러한 히스토그램의 경계를 너무 깊게 생각하지 마세요. 기본 중앙값으로 대부분의 영향을 확인할 수 있습니다.

교차는 두 개 이상의 지형지물 열을 결합합니다. TensorFlow 용어로 특성 열은 동질적인 특성 집합입니다(예: {남자, 여자}, {미국, 캐나다, 멕시코} 등). 교차는 {남자, 여자} × {미국, 캐나다, 멕시코}와 같이 특성이 포함된 새 특성 열입니다. 이 새로운 기능 열에는 기능 (남성, 캐나다)이 포함됩니다. TensorFlow를 사용 중이고 TensorFlow에 이 교차를 생성하도록 지시하면 이 (남성, 캐나다) 특성이 캐나다 남성을 나타내는 예시에서 표시됩니다. 기본 기능 열이 3개, 4개 또는 그 이상 교차되는 모델을 학습하려면 대량의 데이터가 필요합니다.

매우 큰 특성 열을 생성하는 교차는 오버핏할 수 있습니다. 예를 들어 어떤 종류의 검색을 하고 있는데 검색어에 단어가 포함된 특성 열이 있고 문서에 단어가 포함된 특성 열이 있다고 가정해 보겠습니다. 이를 교차로 결합할 수 있지만 그러면 많은 지형지물이 표시됩니다 (규칙 21 참고).

텍스트를 사용할 때는 두 가지 대안이 있습니다. 가장 엄격한 것은 내적입니다. 가장 단순한 형태의 내적은 쿼리와 문서 간에 공통된 단어 수를 계산하기만 합니다. 그러면 이 기능을 디스크리트화할 수 있습니다. 다른 접근 방식은 교집합입니다. 따라서 '말'이라는 단어가 문서와 쿼리 모두에 있는 경우에만 존재하는 특성과 'the'라는 단어가 문서와 쿼리 모두에 있는 경우에만 존재하는 다른 특성이 있습니다.

규칙 21: 선형 모델에서 학습할 수 있는 특성 가중치 수는 보유한 데이터의 양에 대략 비례합니다.

모델에 적합한 복잡도 수준에 관한 흥미로운 통계 학습 이론 결과가 있지만 기본적으로 알아야 할 것은 이 규칙뿐입니다. 특정 학습 방법에 갇혀 1,000개의 예시로 무언가를 배울 수 있을지 의심하거나 100만 개 이상의 예시가 필요할 것이라고 말하는 사람들을 만난 적이 있습니다. 중요한 점은 학습을 데이터의 크기에 맞게 확장하는 것입니다.

  1. 검색 순위 시스템을 개발 중이며 문서와 검색어에 수백만 개의 다른 단어가 있고 라벨이 지정된 예시가 1,000개 있다면 문서 및 검색어 기능 간의 내적, TF-IDF, 기타 6가지의 고도로 인간이 설계한 기능을 사용해야 합니다. 예시 1,000개, 기능 12개
  2. 예시가 100만 개 있는 경우 정규화 및 기능 선택을 사용하여 문서 열과 검색어 열을 교차합니다. 이렇게 하면 수백만 개의 특성이 생성되지만 정규화를 사용하면 특성이 줄어듭니다. 1,000만 개의 예시, 10만 개의 특성
  3. 수십억 개 또는 수백억 개의 예가 있는 경우 특성 선택 및 정규화를 사용하여 특성 열을 문서 및 쿼리 토큰과 교차할 수 있습니다. 예시가 10억 개, 기능이 1,000만 개 있습니다. 통계적 학습 이론은 엄격한 경계를 제공하는 경우는 거의 없지만 시작점으로 삼기에 좋은 지침을 제공합니다.

마지막으로 규칙 28에 따라 사용할 기능을 결정합니다.

규칙 22: 더 이상 사용하지 않는 기능을 정리합니다.

사용하지 않는 기능은 기술적 부채를 야기합니다. 기능을 사용하지 않고 있고 다른 기능과 결합해도 작동하지 않는 경우 인프라에서 해당 기능을 삭제합니다. 가장 유망한 기능을 최대한 빨리 시도할 수 있도록 인프라를 깔끔하게 유지해야 합니다. 필요한 경우 언제든지 다른 사용자가 기능을 다시 추가할 수 있습니다.

추가하거나 유지할 기능을 고려할 때는 적용 범위를 염두에 두세요. 이 기능이 적용되는 예시는 몇 개인가요? 예를 들어 맞춤설정 기능이 있지만 사용자의 8% 만 맞춤설정 기능을 사용하는 경우 그다지 효과적이지 않습니다.

반면 일부 기능은 기대 이상의 실적을 거두기도 합니다. 예를 들어 데이터의 1% 만 다루는 특성이 있지만 이 특성이 있는 예시의 90% 가 긍정적인 경우 추가할 만한 좋은 특성입니다.

시스템의 인간 분석

머신러닝의 세 번째 단계로 넘어가기 전에 머신러닝 수업에서는 가르치지 않는 주제, 즉 기존 모델을 살펴보고 개선하는 방법에 집중하는 것이 중요합니다. 이는 과학보다는 예술에 가깝지만, 이를 피하는 데 도움이 되는 여러 반패턴이 있습니다.

규칙 23: 일반적인 최종 사용자가 아닙니다.

이는 팀이 가장 쉽게 지체되는 원인일 수 있습니다. 피쉬푸딩 (팀 내에서 프로토타입 사용) 및 도그푸딩 (회사 내에서 프로토타입 사용)에는 많은 이점이 있지만 직원은 실적이 올바른지 확인해야 합니다. 분명히 나쁜 변경사항은 사용해서는 안 되지만 프로덕션에 가까워 보이는 변경사항은 크라우드소싱 플랫폼에서 질문에 답변하도록 일반인에게 비용을 지불하거나 실제 사용자를 대상으로 실험을 통해 추가로 테스트해야 합니다.

여기에는 두 가지 이유가 있습니다. 첫 번째 이유는 코드에 너무 가까이 있기 때문입니다. 게시물의 특정 측면을 찾고 있거나 단순히 감정적으로 너무 몰입되어 있을 수 있습니다 (예: 확증 편향). 두 번째는 고객님의 시간이 너무 소중하다는 것입니다. 1시간 회의에 참석하는 엔지니어 9명의 비용과 크라우드소싱 플랫폼에서 계약한 수동 라벨러 수를 생각해 보세요.

사용자 의견을 정말로 얻으려면 사용자 경험 방법론을 사용하세요. 프로세스 초기에 사용자 캐릭터를 만들고 (빌 버크스턴의 Sketching User Experiences 참고) 나중에 사용성 테스트를 진행합니다 (스티브 크루그의 Don’t Make Me Think 참고). 사용자 캐릭터는 가상의 사용자를 만드는 것을 말합니다. 예를 들어 팀원 모두 남성인 경우 35세 여성 사용자 캐릭터 (사용자 기능 포함)를 설계하고 25~40세 남성의 결과 10개 대신 이 캐릭터를 통해 생성된 결과를 살펴보는 것이 좋습니다. 사용성 테스트에서 실제 사용자를 참여시켜 사이트에 대한 반응을 로컬 또는 원격으로 확인하면 새로운 관점을 얻을 수도 있습니다.

규칙 24: 모델 간의 델타를 측정합니다.

사용자가 새 모델을 보기 전에 할 수 있는 가장 쉽고 때로는 가장 유용한 측정 중 하나는 새 결과가 프로덕션 결과와 얼마나 다른지 계산하는 것입니다. 예를 들어 순위 문제가 있는 경우 전체 시스템을 통해 샘플 검색어에 두 모델을 모두 실행하고 결과의 대칭 차이 크기 (순위별 가중치 적용)를 확인합니다. 차이가 매우 작으면 실험을 실행하지 않고도 큰 변화가 없을 것이라고 알 수 있습니다. 차이가 매우 큰 경우 변경사항이 적절한지 확인해야 합니다. 대칭 차이가 큰 쿼리를 검토하면 변화가 어떠했는지 질적으로 파악하는 데 도움이 됩니다. 하지만 시스템이 안정적인지 확인해야 합니다. 모델이 자체와 비교할 때 대칭 차이가 낮은지 (이상적으로는 0) 확인합니다.

규칙 25: 모델을 선택할 때는 실용적인 성능이 예측력보다 중요합니다.

모델이 클릭률을 예측하려고 할 수 있습니다. 하지만 결국 중요한 것은 예측을 어떻게 활용하느냐는 것입니다. 문서 순위에 이를 사용하는 경우 예측 자체보다 최종 순위의 품질이 더 중요합니다. 문서가 스팸일 가능성을 예측한 후 차단되는 항목에 기준을 적용하는 경우 허용되는 항목의 정확성이 더 중요합니다. 대부분의 경우 이 두 가지가 일치해야 합니다. 일치하지 않는 경우 소폭 상승할 가능성이 높습니다. 따라서 로그 손실을 개선하지만 시스템 성능을 저하시키는 변경사항이 있는 경우 다른 기능을 찾아보세요. 이러한 상황이 더 자주 발생하면 모델의 목표를 다시 검토해야 합니다.

규칙 26: 측정된 오류에서 패턴을 찾고 새로운 기능을 만듭니다.

모델이 '잘못' 학습한 학습 예시가 있다고 가정해 보겠습니다. 분류 작업에서 이 오류는 거짓양성 또는 거짓음성일 수 있습니다. 순위 지정 작업에서 오류는 양성이 음수보다 순위가 낮은 쌍일 수 있습니다. 가장 중요한 점은 머신러닝 시스템이 잘못된 것을 알고 있으며 기회가 주어지면 수정하고자 한다는 예시라는 것입니다. 모델에 오류를 수정할 수 있는 기능을 제공하면 모델은 이를 사용하려고 시도합니다.

반면에 시스템에서 실수로 간주하지 않는 예시를 기반으로 기능을 만들려고 하면 기능이 무시됩니다. 예를 들어 사용자가 Play 앱 검색에서 '무료 게임'을 검색한다고 가정해 보겠습니다. 상위 결과 중 하나가 관련성이 낮은 농담 앱이라고 가정해 보겠습니다. 그러면 '농담 앱'용 기능을 만듭니다. 하지만 설치 수를 극대화하고 있고 사용자가 무료 게임을 검색할 때 농담 앱을 설치하는 경우 '농담 앱' 기능이 원하는 효과를 내지 못합니다.

모델이 잘못 예측한 예시가 있으면 현재 특성 세트 외부의 동향을 찾습니다. 예를 들어 시스템에서 더 긴 게시물의 순위가 낮아지는 것처럼 보이면 게시물 길이를 추가합니다. 추가하는 기능에 대해 너무 구체적으로 설명하지 마세요. 게시물 길이를 추가하려면 긴 게시물의 의미를 추측하려고 하지 말고 12개 정도의 기능을 추가한 다음 모델이 이를 어떻게 처리할지 알아보도록 하세요 (규칙 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 참고). 테이블이 천천히만 변경되는 경우 시간별 또는 일별로 테이블을 스냅샷하여 비교적 근접한 데이터를 얻을 수도 있습니다. 그래도 문제가 완전히 해결되지는 않습니다.

규칙 32: 가능하면 학습 파이프라인과 제공 파이프라인 간에 코드를 재사용하세요.

일괄 처리는 온라인 처리와 다릅니다. 온라인 처리에서는 각 요청이 도착할 때마다 처리해야 하지만 (예: 각 쿼리에 대해 별도로 조회해야 함) 일괄 처리에서는 태스크를 결합할 수 있습니다 (예: 조인). 게재 시에는 온라인 처리가 이루어지지만 학습은 일괄 처리 작업입니다. 하지만 코드를 재사용하기 위해 할 수 있는 몇 가지 작업이 있습니다. 예를 들어 쿼리 또는 조인의 결과를 사람이 읽을 수 있는 방식으로 저장하고 오류를 쉽게 테스트할 수 있는 시스템에만 적용되는 객체를 만들 수 있습니다. 그런 다음 모든 정보를 수집한 후, 게재 또는 학습 중에 공통 메서드를 실행하여 시스템에 특화된 사람이 읽을 수 있는 객체와 머신러닝 시스템에서 예상하는 형식 간에 다리를 놓습니다. 이렇게 하면 학습-서빙 편향의 원인이 제거됩니다. 따라서 학습과 제공 간에 두 가지 프로그래밍 언어를 사용하지 않는 것이 좋습니다. 이렇게 하면 코드를 공유할 수 없게 됩니다.

규칙 33: 1월 5일까지의 데이터를 기반으로 모델을 생성하는 경우 1월 6일 이후의 데이터로 모델을 테스트합니다.

일반적으로 모델을 학습한 데이터 이후에 수집된 데이터에서 모델의 성능을 측정합니다. 이렇게 하면 프로덕션에서 시스템이 실행할 작업을 더 잘 반영할 수 있습니다. 1월 5일까지의 데이터를 기반으로 모델을 생성하는 경우 1월 6일 이후의 데이터로 모델을 테스트합니다. 새 데이터의 성능이 기존 데이터에 비해 좋지 않을 것으로 예상되지만 크게 나빠지지는 않습니다. 일일 효과가 있을 수 있으므로 평균 클릭률 또는 전환율을 예측하지 못할 수도 있지만 긍정 예시의 점수가 부정 예시의 점수보다 높을 가능성을 나타내는 곡선 아래 영역은 상당히 근접해야 합니다.

규칙 34: 필터링을 위한 이진 분류 (예: 스팸 감지 또는 관심 있는 이메일 확인)에서 매우 정리된 데이터를 위해 단기적으로 성능을 약간 희생합니다.

필터링 작업에서 '부정적'으로 표시된 예시는 사용자에게 표시되지 않습니다. 게재 시 제외 사례의 75% 를 차단하는 필터가 있다고 가정해 보겠습니다. 사용자에게 표시되는 인스턴스에서 학습 데이터를 추가로 가져오고 싶을 수 있습니다. 예를 들어 사용자가 필터링을 통과한 이메일을 스팸으로 표시하는 경우 이를 토대로 학습할 수 있습니다.

하지만 이 접근 방식에는 샘플링 편향이 있습니다. 대신 게재 중에 모든 트래픽의 1% 를 '보류됨'으로 라벨링하고 보류된 모든 예시를 사용자에게 전송하면 더 정확한 데이터를 수집할 수 있습니다. 이제 필터가 74% 이상의 부정적 예시를 차단합니다. 이러한 예시를 보류하면 학습 데이터가 될 수 있습니다.

필터가 부정적인 예시의 95% 이상을 차단하는 경우 이 접근 방식은 실행하기 어려워집니다. 그렇더라도 게재 실적을 측정하려면 훨씬 더 작은 샘플 (예: 0.1% 또는 0.001%)을 만들 수 있습니다. 10,000개의 예시면 실적을 매우 정확하게 추정할 수 있습니다.

규칙 35: 순위에 내재된 왜곡에 주의하세요.

순위 알고리즘을 완전히 전환하여 다른 결과가 표시되면 향후 알고리즘에서 볼 데이터가 효과적으로 변경된 것입니다. 이러한 종류의 왜곡이 표시되므로 이를 중심으로 모델을 설계해야 합니다. 여러 가지 접근 방식이 있습니다. 이러한 접근 방식은 모두 모델이 이미 본 데이터를 선호하는 방법입니다.

  1. 하나의 쿼리에만 사용 설정된 기능이 아닌 더 많은 쿼리를 다루는 기능에 더 높은 정규화를 적용합니다. 이렇게 하면 모델이 모든 검색어에 일반화된 특징보다 하나 또는 몇 개의 검색어에만 해당하는 특징을 선호하게 됩니다. 이 접근 방식을 사용하면 매우 인기 있는 결과가 관련 없는 검색어로 유출되는 것을 방지할 수 있습니다. 이는 고유한 값이 더 많은 특성 열에 더 많은 정규화를 적용하라는 기존의 조언과는 반대입니다.
  2. 지형지물에만 양수 가중치를 허용합니다. 따라서 좋은 특성은 '알 수 없는' 특성보다 낫습니다.
  3. 문서 전용 기능이 없습니다. 이는 1번의 극단적인 버전입니다. 예를 들어 특정 앱이 검색어와 관계없이 인기 있는 다운로드 항목이더라도 모든 위치에 표시하고 싶지는 않을 것입니다. 문서 전용 기능이 없으므로 간단하게 유지할 수 있습니다. 특정 인기 앱을 모든 위치에 표시하고 싶지 않은 이유는 원하는 모든 앱에 액세스할 수 있도록 하는 것이 중요하기 때문입니다. 예를 들어 사용자가 '새 관찰 앱'을 검색했다가 '앵그리버드'를 다운로드할 수 있지만, 의도한 것은 아닙니다. 이러한 앱을 표시하면 다운로드율이 개선될 수 있지만 결국 사용자의 요구사항이 충족되지 않습니다.

규칙 36: 위치 지정 기능으로 피드백 루프를 피하세요.

콘텐츠의 위치는 사용자가 콘텐츠와 상호작용할 가능성에 큰 영향을 미칩니다. 앱을 첫 번째 위치에 배치하면 더 자주 클릭되고 클릭될 가능성이 더 높다는 확신이 생깁니다. 이를 해결하는 한 가지 방법은 위치 기능, 즉 페이지에서 콘텐츠의 위치에 관한 기능을 추가하는 것입니다. 위치 특성으로 모델을 학습하면 모델은 예를 들어 '1st­position' 특성에 가중치를 크게 두는 것을 학습합니다. 따라서 모델은 '1st­position=true'인 예시의 다른 요인에 더 적은 가중치를 부여합니다. 그런 다음 게재 시 인스턴스에 위치 지정 기능을 제공하지 않거나 모두 동일한 기본 기능을 제공합니다. 표시 순서를 결정하기 전에 후보에 점수를 부여하기 때문입니다.

학습과 테스트 간의 비대칭성 때문에 위치 기능을 나머지 모델과 약간 분리하는 것이 중요합니다. 모델이 위치 지형지물의 함수와 나머지 지형지물의 함수의 합계인 것이 이상적입니다. 예를 들어 위치 지형지물과 문서 지형지물을 교차하지 마세요.

규칙 37: 학습/서빙 편향을 측정합니다.

가장 일반적인 의미에서 왜곡을 일으킬 수 있는 요인은 여러 가지가 있습니다. 또한 다음과 같이 여러 부분으로 나눌 수 있습니다.

  • 학습 데이터와 홀드아웃 데이터의 성능 차이입니다. 일반적으로 이러한 차이는 항상 존재하며 항상 나쁜 것은 아닙니다.
  • 홀드아웃 데이터의 실적과 '다음 날' 데이터의 실적 간의 차이입니다. 이 값은 항상 존재합니다. 다음 날 실적을 극대화하도록 정규화를 조정해야 합니다. 하지만 홀드아웃 데이터와 다음 날 데이터 간에 성능이 크게 하락하면 일부 기능이 시간에 민감하여 모델 성능이 저하될 수 있음을 나타낼 수 있습니다.
  • '다음 날' 데이터의 실적과 실시간 데이터의 실적 간의 차이입니다. 학습 데이터의 예와 제공 시 동일한 예에 모델을 적용하면 정확히 동일한 결과가 나와야 합니다 (규칙 5 참고). 따라서 여기에서 불일치가 발생하면 엔지니어링 오류를 나타내는 것일 수 있습니다.

ML 3단계: 성장 속도 저하, 최적화 미세 조정, 복잡한 모델

두 번째 단계가 종료되고 있음을 나타내는 특정 신호가 표시됩니다. 우선 월별 수익이 감소하기 시작합니다. 측정항목 간에 절충점이 발생하기 시작합니다. 일부 실험에서는 측정항목이 상승하고 다른 실험에서는 하락하는 것을 볼 수 있습니다. 여기서부터 흥미로워집니다. 이익을 얻기가 더 어려워지므로 머신러닝이 더 정교해져야 합니다. 주의: 이 섹션에는 이전 섹션보다 더 많은 블루스카이 규칙이 있습니다. 많은 팀이 머신러닝 1단계와 2단계의 즐거운 시간을 보냈습니다. 3단계에 도달하면 팀에서 자체적인 방법을 찾아야 합니다.

규칙 38: 목표가 일치하지 않는 문제가 발생한 경우 새 기능에 시간을 낭비하지 마세요.

측정값이 정체되면 팀에서 현재 머신러닝 시스템의 목표 범위를 벗어난 문제를 살펴보기 시작합니다. 앞서 언급한 대로 제품 목표가 기존 알고리즘 목표에 포함되지 않는 경우 목표 또는 제품 목표 중 하나를 변경해야 합니다. 예를 들어 클릭수, 좋아요 또는 다운로드를 최적화하지만, 사람 평가자의 평가를 부분적으로 참고하여 출시 결정을 내릴 수 있습니다.

규칙 39: 출시 결정은 장기적인 제품 목표를 대변합니다.

앨리스는 설치 예측의 물류 손실을 줄이는 아이디어를 가지고 있습니다. 기능을 추가합니다. 로지스틱 손실이 감소합니다. 실험을 진행한 결과 설치율이 증가한 것을 확인했습니다. 하지만 출시 검토 회의에 참석했을 때 누군가 일일 활성 사용자 수가 5% 감소했다고 지적합니다. 팀에서 모델을 출시하지 않기로 결정합니다. 앨리스는 실망했지만 이제 출시 결정이 여러 기준에 따라 달라지며 그중 일부만 ML을 사용하여 직접 최적화할 수 있다는 것을 깨닫습니다.

사실 실제 환경은 던전 앤 드래곤이 아닙니다. 제품의 상태를 식별하는 '히트 포인트'는 없습니다. 팀은 수집한 통계를 사용하여 향후 시스템의 성능을 효과적으로 예측해야 합니다. 참여도, 일일 활성 사용자 수 (DAU), 30일 DAU, 수익, 광고주의 투자수익을 고려해야 합니다. A/B 테스트에서 측정할 수 있는 이러한 측정항목은 그 자체로 더 장기적인 목표인 사용자 만족, 사용자 증가, 파트너 만족, 이익을 대변하는 것일 뿐입니다. 5년 후에도 유용하고 고품질의 제품과 번창하는 회사를 보유하기 위한 대리 변수로 간주할 수 있습니다.

모든 측정항목이 개선되거나 (또는 최소한 악화되지 않는) 경우에만 쉽게 출시 결정을 내릴 수 있습니다. 정교한 머신러닝 알고리즘과 간단한 휴리스틱 중에서 선택할 수 있는 경우 간단한 휴리스틱이 모든 측정항목에서 더 나은 결과를 보인다면 휴리스틱을 선택해야 합니다. 또한 가능한 모든 측정항목 값에 대한 명시적인 순위는 없습니다. 특히 다음 두 가지 시나리오를 고려해 보세요.

실험 일일 활성 사용자 수 수익/일
A 100만 400만 달러
B 200만 200만 달러

현재 시스템이 A인 경우 팀에서 B로 전환할 가능성이 낮습니다. 현재 시스템이 B인 경우 팀에서 A로 전환할 가능성이 낮습니다. 이는 합리적인 행동과 상반되는 것처럼 보이지만, 측정항목 변경에 대한 예측이 맞을 수도 있고 틀릴 수도 있으므로 두 가지 변경사항 모두에 큰 위험이 따릅니다. 각 측정항목은 팀이 우려하는 일부 위험을 다룹니다.

또한 팀의 궁극적인 관심사인 '5년 후 내 제품은 어디에 있을까?'라는 질문을 다루는 측정항목도 없습니다.

반면 개인은 직접 최적화할 수 있는 하나의 목표를 선호하는 경향이 있습니다. 대부분의 머신러닝 도구는 이러한 환경을 선호합니다. 새로운 기능을 개발하는 엔지니어는 이러한 환경에서 지속적으로 출시할 수 있습니다. 이 문제를 해결하기 시작하는 머신러닝 유형인 다중 목표 학습이 있습니다. 예를 들어 각 측정항목에 하한선이 있고 측정항목의 선형 조합을 최적화하는 제약 조건 충족 문제를 공식화할 수 있습니다. 하지만 그렇다고 해서 모든 측정항목을 머신러닝 목표로 쉽게 구성할 수 있는 것은 아닙니다. 문서가 클릭되거나 앱이 설치되는 이유는 콘텐츠가 표시되었기 때문입니다. 하지만 사용자가 사이트를 방문하는 이유를 파악하는 것은 훨씬 어렵습니다. 사이트 전체의 향후 성공을 예측하는 방법은 컴퓨터 비전이나 자연어 처리만큼 어렵고 AI 완성형입니다.

규칙 40: 앙상블을 단순하게 유지하세요.

원시 기능을 수신하고 콘텐츠를 직접 순위 지정하는 통합 모델은 디버그하고 이해하기 가장 쉬운 모델입니다. 하지만 모델의 앙상블 (다른 모델의 점수를 결합한 '모델')은 더 효과적일 수 있습니다. 간단하게 하려면 각 모델이 다른 모델의 입력만 사용하는 앙상블이거나 여러 특성을 사용하는 기본 모델이어야 합니다. 둘 다를 사용할 수는 없습니다. 별도로 학습된 다른 모델 위에 모델이 있는 경우 이를 결합하면 잘못된 동작이 발생할 수 있습니다.

앙상블링에 '기본' 모델의 출력만 입력으로 사용하는 간단한 모델을 사용합니다. 또한 이러한 앙상블 모델에 속성을 적용하려고 합니다. 예를 들어 기본 모델에서 생성된 점수가 증가하면 앙상블의 점수가 감소해서는 안 됩니다. 또한 기본 모델의 변경사항이 앙상블 모델을 혼동하지 않도록 수신되는 모델이 의미론적으로 해석 가능 (예: 보정됨)한 것이 가장 좋습니다. 또한 기본 분류자의 예측 확률이 증가해도 앙상블의 예측 확률이 감소하지 않도록 적용합니다.

규칙 41: 실적이 정체되면 기존 신호를 미세 조정하는 대신 새로운 정보 소스를 찾아 추가하세요.

사용자에 대한 인구통계 정보를 추가했습니다. 문서의 단어에 관한 정보를 추가했습니다. 템플릿 탐색을 진행하고 정규화를 조정했습니다. 몇 분기에 걸쳐 주요 측정항목이 1% 이상 개선된 출시가 없었습니다. 이제 어떻게 해야 할까요?

이제 이 사용자가 지난 1일, 1주 또는 1년 동안 액세스한 문서 기록이나 다른 속성의 데이터와 같이 완전히 다른 기능을 위한 인프라를 빌드할 때입니다. wikidata 항목 또는 회사 내부 항목 (예: Google의 지식 그래프)을 사용합니다. 딥 러닝을 사용하세요. 투자에 대한 기대 수익에 대한 기대치를 조정하고 그에 따라 노력을 확대하세요. 다른 엔지니어링 프로젝트와 마찬가지로 새 기능을 추가하는 이점과 복잡성 증가로 인한 비용을 비교 검토해야 합니다.

규칙 42: 다양성, 맞춤설정, 관련성이 생각만큼 인기도와 상관이 있다고 기대하지 마세요.

콘텐츠 집합의 다양성은 여러 가지 의미를 가질 수 있으며, 콘텐츠 소스의 다양성이 가장 일반적인 의미 중 하나입니다. 맞춤설정은 각 사용자에게 고유한 결과가 제공된다는 것을 의미합니다. 관련성은 특정 검색어의 결과가 다른 검색어의 결과보다 해당 검색어에 더 적합하다는 것을 의미합니다. 따라서 이 세 가지 속성은 모두 일반적인 속성과 다르게 정의됩니다.

문제는 평범한 콘텐츠는 이길 수 없다는 것입니다.

시스템에서 클릭수, 시간, 시청수, +1, 리셰어 등을 측정하는 경우 콘텐츠의 인기도를 측정하는 것입니다. 팀에서는 다양성이 있는 개인 모델을 학습하려고 시도하는 경우가 있습니다. 맞춤설정하기 위해 시스템이 맞춤설정 (사용자의 관심분야를 나타내는 일부 기능) 또는 다양화 (이 문서가 반환된 다른 문서와 공통적인 기능 (예: 저자 또는 콘텐츠)이 있는지 나타내는 기능)할 수 있는 기능을 추가하고 이러한 기능이 예상보다 가중치가 낮거나 다른 부호를 갖는다는 것을 발견합니다.

그렇다고 해서 다양성, 맞춤설정, 관련성이 중요하지 않다는 의미는 아닙니다. 이전 규칙에서 지적한 바와 같이 후처리를 통해 다양성 또는 관련성을 높일 수 있습니다. 장기 목표가 증가하면 인기도 외에도 다양성/관련성이 중요하다고 선언할 수 있습니다. 그런 다음 후처리를 계속 사용하거나 다양성 또는 관련성을 기반으로 목표를 직접 수정할 수 있습니다.

규칙 43: 친구는 여러 제품에서 동일한 경향이 있습니다. 내 관심분야는 그렇지 않은 경향이 있습니다.

Google의 여러 팀은 한 제품에서 연결의 밀도를 예측하는 모델을 사용하여 다른 제품에서 잘 작동하도록 하는 방법을 통해 많은 관심을 얻었습니다. 친구는 친구입니다. 반면 제품 간 개인 맞춤 기능으로 어려움을 겪는 여러 팀을 지켜봤습니다. 예, 작동할 것 같습니다. 현재로서는 그렇지 않은 것 같습니다. 한 속성의 원시 데이터를 사용하여 다른 속성의 동작을 예측하는 것이 효과적인 경우가 있습니다. 또한 사용자가 다른 속성에서 거래한 이력이 있는지 알면 도움이 될 수 있습니다. 예를 들어 두 제품에 사용자 활동이 있는 것은 그 자체로 의미가 있을 수 있습니다.

Google뿐만 아니라 외부에도 머신러닝에 관한 문서가 많이 있습니다.

감사의 말씀

이 문서에 대한 수정사항, 제안사항, 유용한 예시를 제공해 주신 David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsiapis, Glen Anderson, Dan Duckworth, Shishir Birmiwal, Gal Elidan, Su Lin Wu, Jaihui Liu, Fernando Pereira, Hrishikesh Aradhye님께 감사드립니다. 또한 이전 버전 제작에 도움을 준 크리스틴 레페브르, 수다 바수, 크리스 버그에게도 감사드립니다. 오류, 누락 또는 (헉!) 인기 없는 의견은 제 의견입니다.

부록

이 문서에는 Google 제품에 대한 다양한 참조가 포함되어 있습니다. 더 많은 맥락을 제공하기 위해 아래에서 가장 일반적인 예를 간단히 설명합니다.

YouTube 개요

YouTube는 스트리밍 동영상 서비스입니다. YouTube의 다음 볼만한 동영상팀과 YouTube 홈 페이지팀 모두 ML 모델을 사용하여 맞춤 동영상 순위를 매깁니다. 다음 볼만한 동영상은 현재 재생 중인 동영상 다음에 볼만한 동영상을 추천하고, 홈페이지는 홈페이지를 탐색하는 사용자에게 동영상을 추천합니다.

Google Play 개요

Google Play에는 다양한 문제를 해결하는 여러 모델이 있습니다. Play 검색, Play 홈페이지 맞춤 추천, '사용자가 설치한 다른 앱'은 모두 머신러닝을 사용합니다.

Google+ 개요

Google Plus에서는 다양한 상황에서 머신러닝을 사용했습니다. 사용자에게 표시되는 게시물의 '스트림'에서 게시물 순위를 지정하고, '인기' 게시물 (현재 인기가 높은 게시물) 순위를 지정하고, 아는 사람 순위를 지정하는 등 다양한 상황에서 머신러닝을 사용했습니다. Google+는 2019년에 모든 개인 계정을 폐쇄했으며 2020년 7월 6일에 비즈니스 계정의 Google Currents로 대체되었습니다.