머신러닝 규칙:

ML 엔지니어링 권장사항

마틴 진케비치

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

마틴 진케비치는 머신러닝의 10가지 규칙을 소개합니다. 43가지 규칙을 모두 알아보세요.

용어

효과적인 머신러닝을 설명하는 과정에서 다음과 같은 용어가 반복적으로 언급될 것입니다.

  • 인스턴스: 예측하려는 대상물을 의미합니다. 예를 들어 '고양이와 관련됨' 또는 '고양이와 무관함'으로 분류하려는 웹페이지가 인스턴스가 될 수 있습니다.
  • 라벨: 예측 작업에 대한 답으로서, 머신러닝 시스템이 도출하거나 학습 데이터에서 제공된 정답입니다. 예를 들어 웹페이지의 라벨은 '고양이 정보'일 수 있습니다.
  • 특성: 예측 작업에 사용되는 인스턴스의 속성입니다. 예를 들어 웹페이지에 '고양이라는 단어를 포함'하는 특성이 있을 수 있습니다.
  • 특성 열: 사용자가 거주할 수 있는 모든 국가의 집합과 같이 관련 특성의 집합입니다. 하나의 예시 특성이 특성 열에 하나 이상 있을 수 있습니다. '특성 열'은 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. 변경되는 사항과 동일하게 유지되는 사항이 표시됩니다. 예를 들어 일일 활성 사용자를 직접 최적화한다고 가정해 보겠습니다. 그러나 시스템을 초기에 조작하는 과정에서 사용자 환경의 변경사항이 중요하더라도 이 측정항목이 눈에 띄게 변경되지 않을 수 있습니다.

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

측정항목 수집에 대해 좀 더 철저히 이해하면 시스템을 보다 넓은 시각에서 이해할 수 있습니다. 문제가 있나요? 측정항목을 추가하여 추적하세요. 마지막 출시에서 양적 변화와 관련해 관심이 있으신가요? 측정항목을 추가하여 추적하세요.

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

간단한 휴리스틱으로 제품을 선보일 수 있습니다. 복잡한 휴리스틱은 유지관리할 수 없습니다. 데이터가 확보되고 달성하려는 기본 목표가 확보되었으면 머신러닝으로 넘어갑니다. 휴리스틱 모델이든 머신러닝 모델이든 대부분의 소프트웨어 엔지니어링 작업에서와 같이 접근 방식을 지속적으로 업데이트해야 하며 머신러닝 모델은 더 쉽게 업데이트하고 유지보수할 수 있습니다 (규칙 #16 참고).

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

첫 번째 파이프라인의 시스템 인프라에 집중합니다. 하게 될 모든 머신러닝의 개념을 생각해 보는 것은 재밌지만, 파이프라인을 먼저 신뢰하지 않으면 어떤 일이 일어나는지 알아내는 것은 어렵습니다.

규칙 #4: 첫 번째 모델은 단순하게 유지하고 인프라를 제대로 잡으세요.

첫 번째 모델은 제품에 가장 큰 이점을 제공하므로 고급 모델이 아니어도 됩니다. 그러나 예상보다 많은 인프라 문제가 발생합니다. 멋진 머신러닝 시스템을 사용하려면 먼저 다음 사항을 확인해야 합니다.

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

간단한 특성을 선택하면 다음을 쉽게 확인할 수 있습니다.

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

이 세 가지 작업을 안정적으로 실행하는 시스템이 구축되었다면 대부분의 작업을 완료한 것입니다. 간단한 모델에서는 더 복잡한 모델을 테스트하는 데 사용할 수 있는 기준 측정항목 및 기준 동작을 제공합니다. 일부 팀은 '중립적인' 최초 출시를 목표로 합니다. 첫 번째 출시는 산만해지지 않도록 머신러닝의 이득을 명시적으로 우선순위에서 낮춥니다.

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

인프라를 테스트할 수 있는지, 그리고 시스템의 학습 부분이 캡슐화되어 모든 항목을 테스트할 수 있는지 확인합니다. 특히 다음에 주의해야 합니다.

  1. 알고리즘에 데이터를 가져오는 것을 테스트합니다. 채워야 하는 특성 열이 채워지는지 확인합니다. 개인 정보가 허용되는 경우 학습 알고리즘에 대한 입력을 수동으로 검사합니다. 가능한 경우 파이프라인의 통계를 다른 곳에서 처리된 동일한 데이터의 통계와 비교하여 확인합니다.
  2. 학습 알고리즘에서 모델을 가져오는 것을 테스트합니다. 학습 환경의 모델이 서빙 환경의 모델과 동일한 점수를 받아야 합니다 (규칙 #37 참고).

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

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

종종 기존 파이프라인 (예: 화물 컬트 프로그래밍)을 복사하여 파이프라인을 만들며, 이전 파이프라인은 새 파이프라인에 필요한 데이터를 삭제합니다. 예를 들어 Google+ HOT 소식의 파이프라인은 최신 게시물의 순위를 매기는 것이 목적이므로 이전 게시물을 삭제합니다. 이 파이프라인은 Google+ 스트림에 사용하도록 복사되었습니다. 이 경우 이전 게시물에는 여전히 의미가 있지만 파이프라인에는 여전히 이전 게시물이 삭제되었습니다. 또 다른 일반적인 패턴은 사용자가 확인한 데이터만 로깅하는 것입니다. 따라서 모든 부정적인 예시가 삭제되었기 때문에 사용자가 특정 게시물을 보지 못한 이유를 모델링하려는 경우에는 이 데이터가 유용하지 않습니다. Play에서도 비슷한 문제가 발생했습니다. Play 앱 홈에서 작업하는 동안 Play 게임즈 방문 페이지의 예시도 각 예시의 출처를 구분하기 위한 특성이 없는 새로운 파이프라인을 만들었습니다.

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

일반적으로 머신러닝으로 해결하려는 문제는 완전히 새로운 것은 아닙니다. 순위 지정, 분류, 해결하려는 문제 해결을 위한 기존 시스템이 있습니다. 즉, 다양한 규칙과 휴리스틱이 있습니다. 머신러닝을 사용하면 동일한 휴리스틱으로 상승도를 높일 수 있습니다. 어떤 방법으로든 휴리스틱을 채굴해야 합니다. 두 가지 이유가 있습니다. 첫째, 머신러닝 시스템으로의 전환이 더욱 순조롭습니다. 둘째, 일반적으로 이러한 규칙은 폐기하고 싶지 않은 시스템에 관한 많은 직관을 포함합니다. 기존 휴리스틱을 사용하는 방법은 4가지입니다.

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

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

모니터링

일반적으로 알림을 실행 가능하게 하고 대시보드 페이지를 만드는 등 적절한 알림 정제를 이행합니다.

규칙 #8: 시스템의 업데이트 요구사항을 파악하세요.

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

규칙 #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 참고). Google에서는 이러한 확률적 예측을 사용하여 결정을 내리는 경우가 많습니다. 예를 들어 게시글의 순위를 예상값 (예: 클릭/다운로드 가능성)에서 순위를 매깁니다. 하지만 사용할 모델을 선택할 때가 되면 모델을 적용한 데이터의 가능성보다 결정이 더 중요합니다 (규칙 #27 참고).

규칙 #15: 정책 레이어에서 스팸 필터링과 품질 순위 구분하기

품질 순위는 좋은 기술이지만 스팸 필터링은 전쟁입니다. 고품질 게시물을 결정하는 데 사용하는 신호는 시스템을 사용하는 사용자에게 명확하게 표시되고 이러한 속성을 갖도록 게시물을 조정합니다. 따라서 품질 순위는 선의로 게시된 콘텐츠의 순위를 매기는 데 중점을 두어야 합니다. 스팸의 순위를 높게 매긴 품질 순위 학습자를 평가해서는 안 됩니다. 마찬가지로 '선정적인' 콘텐츠는 품질 순위와 별도로 처리해야 합니다. 스팸 필터링은 완전히 다른 개념입니다. 생성해야 하는 특성은 끊임없이 변화할 것으로 예상해야 합니다. 시스템에 명확하게 규칙을 정하는 경우가 많습니다 (게시물에 스팸 투표가 3번 이상 포함되면 검색할 수 없음). 학습한 모델은 속도가 빠르지 않더라도 매일 업데이트해야 합니다. 콘텐츠 제작자의 평판은 큰 역할을 합니다.

어느 정도는 이 두 시스템의 출력을 통합해야 합니다. 검색결과에서 스팸을 필터링하는 것은 이메일 메시지에서 스팸을 필터링하는 것보다 더 공격적일 수 있습니다. 정규화가 없고 알고리즘이 수렴한다는 가정에서 이는 사실입니다. 일반적으로는 사실입니다. 또한 품질 분류를 위해 학습 데이터에서 스팸을 삭제하는 것은 표준 관행입니다.

ML 2단계: 특성 추출

머신러닝 시스템 수명 주기의 첫 번째 단계에서 중요한 문제는 학습 데이터를 학습 시스템에 가져오고, 관심 있는 측정항목을 모두 계측하고, 서빙 인프라를 만드는 것입니다. 단위 및 시스템 테스트를 계측하는 제대로 작동하는 엔드 투 엔드 시스템이 준비되면 2단계가 시작됩니다.

두 번째 단계에는 쉽게 익힐 수 있는 과일이 많습니다. 시스템에 가져올 수 있는 다양한 명확한 기능이 있습니다. 따라서 머신러닝의 두 번째 단계에서는 가능한 한 많은 특성을 가져와 직관적인 방식으로 결합하는 것입니다. 이 단계에서는 모든 측정항목이 상승합니다. 출시가 많을 텐데, 정말 훌륭한 학습 시스템을 만드는 데 필요한 모든 데이터를 종합할 수 있는 엔지니어를 많이 모을 때입니다.

규칙 #16: 출시와 반복을 계획하라.

현재 작업 중인 모델이 마지막에 출시되거나 모델 출시가 중단될 수도 있습니다. 따라서 이번 출시로 추가하는 복잡성으로 인해 향후 출시 속도가 느려질 수 있는지 고려하세요. 많은 팀이 수년 동안 분기당 1회 이상 모델을 출시한 바 있습니다. 새 모델을 출시하는 데는 기본적으로 3가지 이유가 있습니다.

  • 새로운 기능이 곧 제공됩니다.
  • 정규화를 조정하고 이전 특성을 새로운 방식으로 결합하는 중입니다.
  • 목표를 조정하는 중입니다.

모델에 약간의 애정을 주는 것도 좋은 방법입니다. 예시의 데이터 피드를 살펴보면 새로운 신호뿐만 아니라 깨진 신호도 찾을 수 있습니다. 따라서 모델을 빌드할 때 특성을 얼마나 쉽게 추가하거나 삭제하고 다시 조합할 수 있을지 생각해 보세요. 파이프라인의 새 사본을 만들고 정확성을 확인하는 것이 얼마나 쉬운지 생각해 보세요. 2개 또는 3개의 사본을 동시에 실행할 수 있는지 생각해 보세요. 마지막으로, 특성 36개 중 16개가 이 파이프라인 버전에 포함되는지 걱정하지 마세요. 다음 분기에 제공될 예정입니다.

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

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

외부 시스템을 사용하여 특성을 만드는 경우 외부 시스템에는 자체 목표가 있습니다. 외부 시스템의 목표는 현재 목표와 약하게 관련이 있을 수 있습니다. 외부 시스템의 스냅샷을 가져오면 최신 정보가 아닐 수 있습니다. 외부 시스템에서 기능을 업데이트하면 의미가 달라질 수 있습니다. 외부 시스템을 사용하여 기능을 제공하는 경우 이 접근 방식에 많은 주의가 필요합니다.

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

규칙 #18: 맥락 전반에서 일반화되는 콘텐츠 특성을 탐색해 보세요.

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

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

데이터가 엄청나게 많기 때문에 몇 가지 복잡한 특성보다 수백만 개의 간단한 특성을 학습하는 것이 더 간단합니다. 검색되는 문서 식별자와 표준화된 쿼리는 많이 일반화되지는 않지만, 헤드 쿼리의 라벨에 맞게 순위를 조정합니다. 따라서 각 특성이 데이터의 극히 일부에만 적용되지만 전체 적용 범위는 90%를 초과하는 특성 그룹을 두려워하지 마세요. 정규화를 사용하여 너무 적은 예에 적용되는 특성을 제거할 수 있습니다.

규칙 #20: 기존 특성을 조합하고 수정하여 사람이 이해할 수 있는 방식으로 새 특성을 생성한다.

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

이산화는 연속 특성을 취하고 이로부터 여러 불연속 특성을 생성하는 것으로 구성됩니다. 연령과 같은 연속 특성을 고려합니다. 나이가 18세 미만이면 1인 특성, 18~35세이면 1인 특성 등을 만들 수 있습니다. 히스토그램의 경계를 너무 깊이 생각하지 마세요. 기본적인 분위가 대부분의 영향을 미칩니다.

교차는 둘 이상의 특성 열을 결합합니다. TensorFlow 용어에서 특성 열은 동질 특성의 집합입니다(예: {남성, 여성}, {미국, 캐나다, 멕시코} 등). 교차는 {남성, 여성} × {미국, 캐나다, 멕시코}의 특성을 갖는 새 특성 열입니다. 이 새로운 특성 열에는 특성 (남성, 캐나다)이 포함됩니다. TensorFlow를 사용하고 TensorFlow에 이 교차 생성을 자동으로 지시하는 경우 캐나다 남성 남성을 나타내는 예시에 이 (남성, 캐나다) 특성이 표시됩니다. 3개, 4개 또는 그 이상의 기본 특성 열이 교차된 모델을 학습하려면 방대한 양의 데이터가 필요합니다.

매우 큰 특성 열을 생성하는 교차는 과적합이 발생할 수 있습니다. 예를 들어 일종의 검색을 수행하고 쿼리에 특성이 있는 특성 열이 있으며 문서에 단어가 포함된 특성 열이 있다고 가정해 보겠습니다. 이를 교차하여 결합할 수 있지만, 그러면 많은 특성이 생성됩니다 (규칙 #21 참고).

텍스트로 작업할 때 두 가지 대안이 있습니다. 가장 엄격한 방법은 내적입니다. 가장 간단한 형태의 내적은 쿼리와 문서 간 공통 단어 수를 세는 것입니다. 그런 다음 이 특성을 분산할 수 있습니다. 또 다른 접근 방식은 교집합을 구하는 것입니다. 즉, 'pony'라는 단어가 문서와 검색어에 모두 있는 경우에만 존재하는 특성과 'the'라는 단어가 문서와 검색어에 모두 있는 경우에만 존재하는 또 다른 특성이 있습니다.

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

모델의 적절한 수준과 관련하여 흥미로운 통계 학습 이론 결과가 있지만, 이 규칙은 기본적으로 알고 있어야 하는 것입니다. 1, 000개의 예시에서 학습할 수 있는지, 아니면 100만 개가 넘는 예시가 필요할지 궁금할 수 있는 대화를 나누었습니다. 왜냐하면 이러한 예시가 특정 학습 방식에 고착되어 있기 때문입니다. 핵심은 학습을 데이터 크기에 맞게 확장하는 것입니다.

  1. 검색 순위 시스템을 작업 중이고 문서 및 쿼리에 수백만 개의 단어가 있고 라벨이 지정된 예 1,000개가 있다면 문서 및 쿼리 특성, TF-IDF와 사람이 추출한 기타 50개의 특성 사이에 내적을 사용해야 합니다. 1,000개의 예, 12개의 특성,
  2. 예시가 100만 개라면 정규화 및 특성 선택을 사용하여 문서 및 쿼리 특성 열을 교차합니다. 이를 통해 수백만 개의 특성이 산출되지만 정규화를 통해 특성이 감소합니다. 1,000만 개의 특성, 10만 개의 특성일 수 있습니다.
  3. 예시가 수십억 또는 수천 개라면 특성 선택 및 정규화를 사용해 특성 열을 문서 및 쿼리 토큰과 교차할 수 있습니다. 10억 개의 예시에 1, 000만 개의 특성이 있습니다. 통계적 학습 이론은 절대적인 근거를 거의 제공하지 않지만 시작점으로 삼기에는 충분합니다.

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

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

사용하지 않는 특성은 기술 부채가 됩니다. 기능을 사용하지 않는 것을 발견하고 다른 기능과 결합해도 효과가 없다면 인프라에서 삭제합니다. 가장 유망한 기능을 가능한 한 빨리 사용해 볼 수 있도록 인프라를 깨끗하게 유지해야 합니다. 필요한 경우 다른 사용자가 특성을 다시 추가할 수 있습니다.

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

동시에 일부 기능은 체중을 치르기도 합니다. 예를 들어 데이터의 1% 만을 포괄하는 특성이 있지만 해당 특성을 갖는 예의 90% 가 양성인 경우 추가하기 좋은 특성입니다.

인간의 시스템 분석

머신러닝의 세 번째 단계로 넘어가기 전에, 어떤 머신러닝 클래스에서도 배우지 않은 부분에 초점을 맞춰야 합니다. 즉, 기존 모델을 확인하고 개선하는 것입니다. 이는 과학보다 예술에 더 가깝지만, 피해야 할 몇 가지 안티패턴이 있습니다.

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

이것이 팀이 난관에 부딪히는 가장 쉬운 방법일 것입니다. 물고기 먹이 주기 (팀 내 프로토타입 사용)와 dogfood (회사 내 프로토타입 사용)에는 많은 이점이 있지만 직원들은 실적이 올바른지 확인해야 합니다. 당연히 바람직하지 않은 변화는 사용해서는 안 되지만, 크라우드소싱 플랫폼에서 일반인에게 비용을 지불하거나 실제 사용자를 대상으로 하는 실험을 통해 합리적으로 보이는 모든 것을 추가로 테스트해야 합니다.

여기에는 두 가지 이유가 있습니다. 첫 번째는 코드에 너무 가깝다는 것입니다. 게시물의 특정 측면을 찾으려고 하거나 지나치게 정서적인 개입 (예: 확증 편향)이 있을 수 있습니다. 두 번째로는 시간이 너무 소중합니다. 엔지니어 9명이 1시간 동안 회의를 하는 데 드는 비용을 고려하고 크라우드소싱 플랫폼에서 구입하는 계약된 인간 라벨의 수를 생각해 보세요.

사용자 의견을 꼭 확인하려면 사용자 경험 방법론을 사용하세요. 사용자 캐릭터 (하나의 설명은 Bill Buxton의 Sketching User Experience)를 미리 만들고 나중에 사용성 테스트를 실행합니다 (하나의 설명은 Steve Krug의 Don't Make Me Think에 있음). 사용자 캐릭터는 가상의 사용자를 만드는 데 관여합니다. 예를 들어 팀이 모두 남자라면 35세 여성 사용자 캐릭터 (사용자 기능 포함)를 설계하고 25~40세 남성에 대한 결과 10개가 아닌 그 결과를 살펴보는 것이 도움이 됩니다. 또한 사용성 테스트에서 로컬 또는 원격으로 사이트에 대한 사용자 반응을 유도하면 새로운 관점을 얻을 수 있습니다.

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

새 모델을 확인하기 전에 가장 쉽고 측정 가능한 방법은 새 결과와 프로덕션 결과가 얼마나 다른지 계산하는 것입니다. 예를 들어 순위 지정 문제가 있으면 전체 시스템을 통해 쿼리 샘플에서 두 모델을 모두 실행하고 결과의 대칭 차 크기 (순위 위치에 따른 가중치)를 확인합니다. 차이가 매우 작다면 실험을 실행하지 않아도 변경사항이 거의 없다는 것을 알 수 있습니다. 차이가 매우 크다면 변경사항이 양호한지 확인하는 것이 좋습니다. 대칭 차이가 높은 쿼리를 살펴보면 변화가 어떻게 이루어졌는지 질적으로 이해하는 데 도움이 될 수 있습니다. 그러나 시스템이 안정적인지 확인하세요. 모델 자체와 비교할 때 대칭 차가 낮은지 확인하는 것이 좋습니다.

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

모델에서 클릭률을 예측하려고 할 수 있습니다. 그러나 결국 중요한 질문은 그 예측으로 무엇을 할 것인가입니다. 이를 사용하여 문서의 순위를 매기는 경우 최종 순위의 품질이 예측 자체보다 중요합니다. 문서가 스팸일 확률을 예측하고 차단 항목에 대한 차단이 설정된 경우 허용되는 대상의 정확성이 더 중요합니다. 대부분의 경우 이 두 가지는 합의를 이뤄야 합니다. 일치하지 않으면 약간의 이득을 얻을 가능성이 큽니다. 따라서 로그 손실은 개선하지만 시스템 성능은 저하되는 변경사항이 있으면 다른 기능을 찾아보세요. 이러한 상황이 더 자주 발생하면 모델의 목표를 다시 살펴볼 때입니다.

규칙 #26: 측정된 오류에서 패턴을 찾아 새로운 특성을 생성하라.

모델이 '틀렸다'는 학습 예시를 본다고 가정하겠습니다. 분류 작업에서 이 오류는 거짓양성 또는 거짓음성일 수 있습니다. 순위 결정 작업에서는 양성 순위가 음성 양성보다 낮은 쌍으로 표시될 수 있습니다. 가장 중요한 점은 이것이 머신러닝 시스템에서 문제가 있다는 것을 알고 있고 기회가 있을 때 해결하고자 한다는 점입니다. 오류 수정을 허용하는 특성을 모델에 지정하면 모델은 이를 사용하려고 시도합니다.

반면 시스템에 잘못된 것으로 보이지 않는 예를 기반으로 특성을 만들려고 하면 특성이 무시됩니다. 예를 들어 Play 앱 검색에서 '무료 게임'을 검색한다고 가정해 보겠습니다. 상위 결과 중 하나가 덜 의미 있는 개그 앱입니다. 따라서 '개그 앱'에 관한 특성을 만든다고 가정해 보겠습니다. 그러나 설치 수를 최대화하고 있고 사람들이 무료 게임을 검색할 때 개그 앱을 설치한다면 '개그 앱' 기능은 원하는 효과를 얻지 못합니다.

모델에 잘못된 예가 있다면 현재 특성 집합을 벗어나는 추세를 찾아보세요. 예를 들어 시스템에서 긴 게시물의 순위를 낮추는 것 같다면 게시물 길이를 추가합니다. 추가할 특성을 너무 구체적으로 고민하지 마세요. 게시물 길이를 추가할 생각이라면 길다는 의미를 짐작하려고 하지 말고 12개의 특성을 추가한 후 모델이 해야 할 일을 알아내도록 하세요 (규칙 #21 참고). 이렇게 하면 원하는 것을 쉽게 얻을 수 있습니다.

규칙 #27: 관찰된 바람직하지 않은 동작을 수량화해 보세요.

팀원 중 일부는 기존 손실 함수로는 포착되지 않는 시스템 특성으로 인해 불만을 느끼게 됩니다. 이 시점에 어떤 수를 써서라도 그립을 정확한 숫자로 변환해야 합니다. 예를 들어 Play 검색에 '개그 앱'이 너무 많이 표시된다고 생각되면 인간 평가자에게 개그 앱을 식별하도록 요청할 수 있습니다. (이 경우 쿼리 비율의 상대적으로 적은 부분이 트래픽의 상당 부분을 차지하므로 이 경우 사람이 라벨을 지정한 데이터를 사용할 수 있습니다.) 측정 가능한 문제라면 기능, 목표 또는 측정항목으로 사용할 수 있습니다. 일반적인 규칙은 '측정 후 최적화'입니다.

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

모든 doc_id와 accurate_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: 위치 특성을 사용하여 피드백 루프를 방지하라.

콘텐츠의 위치는 사용자가 콘텐츠와 상호작용할 가능성에 큰 영향을 미칩니다. 앱을 첫 번째 위치에 배치하면 더 자주 클릭되고 클릭될 가능성도 높아집니다. 이를 처리하는 한 가지 방법은 위치 특성, 즉 페이지에서 콘텐츠 위치에 관한 특성을 추가하는 것입니다. 위치 특성으로 모델을 학습시키고 '1위' 특성과 같은 가중치에 대해 학습합니다. 따라서 모델은 '1stposition=true'인 예에 대해 다른 요소에 가중치를 덜 부여합니다. 서빙 시에는 후보군을 먼저 채점한 후 표시 순서를 결정하므로 인스턴스에 위치 특성을 지정하지 않거나 동일한 기본 특성을 지정합니다.

위치 특성은 학습과 테스트 간의 이러한 비대칭으로 인해 모델의 나머지 부분과 어느 정도 분리된 상태로 유지하는 것이 중요합니다. 모델을 위치 특성의 함수와 나머지 특성의 함수로 합성하는 것이 좋습니다. 예를 들어 위치 특성과 문서 특성을 교차하면 안 됩니다.

규칙 #37: 학습/서빙 편향을 측정하라.

왜곡은 가장 일반적인 의미로 이어질 수 있습니다. 또한 다음과 같이 여러 부분으로 나눌 수 있습니다.

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

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

두 번째 단계가 거의 마무리되었다는 특정 징후가 있습니다. 먼저, 월별 포인트가 줄어들기 시작합니다. 측정항목 간에 장단점이 나타나기 시작합니다. 일부 실험에서 수치가 상승하거나 하락합니다. 여기서부터가 흥미롭습니다. 이득을 달성하기가 더 어렵기 때문에 머신러닝을 더욱 정교하게 조정해야 합니다. 주의사항: 이 섹션에는 이전 섹션보다 푸른 하늘 규칙이 더 많이 있습니다. 많은 팀이 1단계와 2단계 머신러닝의 즐거운 시간을 보냈습니다. 3단계에 도달하면 팀에서 각자의 경로를 찾아야 합니다.

규칙 #38: 일치하지 않는 목표가 문제가 된다면 새로운 기능에 시간을 낭비하지 말라.

측정이 정체기에 접어들면 팀은 현재 머신러닝 시스템의 목표 범위를 벗어나는 문제를 조사하기 시작합니다. 앞서 언급했듯이 제품 목표에 기존 알고리즘 목표가 포함되지 않는 경우 목표나 제품 목표를 변경해야 합니다. 예를 들어 클릭수, +1 또는 다운로드 수를 최적화할 수 있지만 출시 평가는 사람의 평가자를 기반으로 일부 내릴 수 있습니다.

규칙 #39: 출시 결정은 장기적인 제품 목표의 프록시이다.

앨리스는 설치 예측의 로지스틱 손실을 줄일 수 있는 아이디어를 가지고 있습니다. 특성을 추가합니다. 로지스틱 손실이 감소합니다. 실시간 실험을 진행하자 설치율이 증가했습니다. 그러나 출시 검토 회의에 참석했을 때 일일 활성 사용자 수가 5% 감소했다고 지적합니다. 팀에서 모델을 출시하지 않기로 결정합니다. 앨리스는 실망했지만, 이번에는 출시 결정이 여러 기준에 따라 달라지며 그중 몇 가지만 ML을 사용해 직접 최적화할 수 있음을 깨달았습니다.

진실은 던전과 드래곤이 아니라 제품의 상태를 식별하는 '히트 포인트'가 없다는 것입니다. 팀은 수집하는 통계를 사용하여 시스템이 미래에 얼마나 효과적으로 작동할지 예측해야 합니다. 참여도, 1일 활성 사용자 (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과 외부 머신러닝에 관한 수많은 문서가 있습니다.

감사의 말씀

감사합니다. 또한 이전 버전에 도움을 주신 Kristen Lefevre, Suddha Basu, Chris Berg에게도 감사드립니다. 오류나 누락, 또는 헛소리를 듣습니다.

부록

이 문서에서는 다양한 Google 제품에 관한 참조를 제공합니다. 자세한 내용을 설명하기 위해 가장 일반적인 예를 아래에 간단히 설명하겠습니다.

YouTube 개요

YouTube는 스트리밍 동영상 서비스입니다. YouTube 다음 볼만한 동영상 팀과 YouTube 홈페이지 팀은 모두 ML 모델을 사용하여 추천 동영상의 순위를 매깁니다. 다음 볼만한 동영상에는 현재 재생 중인 동영상이 끝난 후 시청할 동영상이 추천되는 반면, 홈페이지에서 홈페이지를 둘러보는 사용자에게는 동영상이 추천됩니다.

Google Play 개요

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

Google+ 개요

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