이 페이지는 Cloud Translation API를 통해 번역되었습니다.

머신러닝의 규칙:

ML 엔지니어링 권장사항

마틴 진케비치

이 문서는 머신러닝에 대한 기본 지식이 있는 사용자가 Google의 머신러닝 권장사항을 활용할 수 있도록 돕기 위해 작성되었습니다. Google C++ 스타일 가이드 및 기타 인기 실습 가이드와 비슷한 머신러닝 스타일을 제시합니다. 머신러닝 수업을 수강했거나 머신러닝 모델을 빌드 또는 작업해 본 사용자라면 이 문서를 읽는 데 필요한 배경지식이 있어야 합니다.

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

용어

효과적인 머신러닝을 논할 때는 다음과 같은 용어가 반복적으로 사용됩니다.

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

개요

우수한 제품을 만드는 방법:

머신러닝 전문가 가 아니라 엔지니어처럼 머신러닝을 진행해 나가는 것이 좋습니다.

직면하게 될 대부분의 문제는 사실 엔지니어링 문제입니다. 뛰어난 머신러닝 전문가의 모든 리소스를 보유하고 있음에도 불구하고, 대부분은 좋은 머신러닝 알고리즘이 아니라 훌륭한 특성에서 발생합니다. 따라서 기본 접근 방식은 다음과 같습니다.

파이프라인에 처음부터 끝까지 견고한지 확인하세요.
합리적인 목표로 시작합니다.
상식에 기반한 기능을 간단한 방법으로 추가하세요.
파이프라인이 안정적인지 확인합니다.

이 접근 방식은 장기적으로 효과적일 것입니다. 더 이상 간단한 비법이 없는 경우에만 이 접근 방식을 피하세요. 복잡성이 더해지면 향후 출시가 느려집니다.

간단한 방법을 모두 익혔다면 최첨단 머신러닝이 미래에 도입될 수 있습니다 3단계 머신러닝 프로젝트의 섹션을 참조하세요.

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

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

머신러닝 시작 전

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

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

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

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

머신러닝 시스템의 기능을 공식화하기 전에 현재 시스템의 작업을 최대한 많이 추적해야 합니다. 이렇게 하는 이유는 다음과 같습니다.

시스템 사용자로부터 조기에 권한을 얻는 것이 더 쉽습니다.
향후 문제가 될 수 있다고 생각되면 지금 과거 데이터를 얻는 것이 좋습니다.
측정항목 계측을 염두에 두고 시스템을 설계한다면 나중에 작업이 편해집니다. 특히 측정항목을 계측하기 위해 로그에서 문자열을 grep으로 반복하지 않아도 됩니다.
무엇이 변하고 무엇이 동일하게 유지되는지 확인할 수 있습니다. 예를 들어 1일 활성 사용자를 직접 최적화한다고 가정해 보겠습니다. 그러나 시스템을 초기에 조작하는 동안 사용자 환경을 급격하게 바꾸어도 이 측정항목은 눈에 띄게 변경되지 않을 수 있습니다.

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

측정항목을 더 자유롭게 수집하면 시스템을 더 넓게 파악할 수 있습니다. 문제가 있나요? 측정항목을 추가하여 추적하세요. 마지막 버전의 정량적 변화가 기대되나요? 측정항목을 추가하여 추적하세요.

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

단순한 휴리스틱으로 제품을 출시할 수 있습니다. 복잡한 휴리스틱은 유지할 수 없습니다 데이터가 있고 달성하려는 목표에 대한 기본 아이디어가 있다면 머신러닝으로 넘어갑니다. 대부분의 소프트웨어 엔지니어링 작업에서 그렇듯이 휴리스틱 모델이든 머신러닝 모델이든 접근 방식을 지속적으로 업데이트하는 것이 좋습니다. 그러면 머신러닝 모델이 업데이트와 유지가 더 쉽다는 것을 알게 될 것입니다 (규칙 #16을 참조하세요).

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

첫 번째 파이프라인의 경우 시스템 인프라에 집중하세요. 앞으로 수행할 모든 상상력 있는 머신러닝을 생각해 보는 것은 재미있지만, 파이프라인을 먼저 신뢰하지 않으면 무슨 일이 벌어지고 있는지 파악하기가 어렵습니다.

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

첫 번째 모델은 제품에 가장 큰 효과를 발휘하므로 화려한 디자인은 하지 않아도 됩니다. 하지만 인프라 문제가 생각보다 많이 발생할 수 있습니다. 새로운 머신러닝 시스템을 사용하려면 먼저 다음을 결정해야 합니다.

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

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

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

이 세 가지를 안정적으로 실행하는 시스템을 갖추면 대부분의 작업을 완료한 것입니다. 간단한 모델은 보다 복잡한 모델을 테스트하는 데 사용할 수 있는 기준 측정항목과 기준 동작을 제공합니다. 일부 팀은 '중립적인' 최초 출시를 목표로 합니다. 첫 출시는 머신러닝의 이점을 명시적으로 떨어뜨려서 주의가 분산되지 않도록 하는 것입니다.

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

인프라를 테스트할 수 있어야 하며 시스템의 학습 부분을 캡슐화하여 주변을 모두 테스트할 수 있어야 합니다. 특히 다음에 주의해야 합니다.

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

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

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

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

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

일반적으로 머신러닝이 해결하려는 문제들은 완전히 새로운 것이 아닙니다. 순위 지정, 분류 또는 해결하려는 모든 문제를 위한 기존 시스템이 있습니다. 즉, 수많은 규칙과 휴리스틱이 있습니다. 동일한 휴리스틱을 머신러닝으로 조정하면 상승 효과를 얻을 수 있습니다. 휴리스틱을 마이닝해야 하는 이유는 두 가지입니다 첫째, 머신러닝 시스템으로의 전환이 더 원활해집니다 둘째, 일반적으로 이러한 규칙에는 시스템에 대해 버리고 싶지 않은 직관이 많이 포함되어 있습니다. 기존 휴리스틱을 사용하는 방법에는 4가지가 있습니다.

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

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

모니터링

일반적으로 알림을 깔끔하게 만들고, 알림을 실행할 수 있도록 하고, 대시보드 페이지를 만드는 것이 좋습니다.

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

모델이 하루가 지나면 성능이 얼마나 저하되나요? 1주일은 어떤가요? 한 분기는요? 이 정보는 모니터링 우선순위를 파악하는 데 도움이 됩니다. 하루 동안 모델이 업데이트되지 않아 상당한 제품 품질이 저하될 경우 모델을 지속적으로 관찰하는 엔지니어를 고용하는 것이 좋습니다. 대부분의 광고 게재 시스템에는 매일 처리해야 하는 새로운 광고가 있으며, 이러한 광고는 매일 업데이트해야 합니다. 예를 들어 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: 해석 가능한 모델부터 시작하면 디버깅이 더 쉬워집니다.

선형 회귀, 로지스틱 회귀, 푸아송 회귀는 확률적 모델의 직접적인 동기를 유발합니다. 각 예측은 확률 또는 예상값으로 해석할 수 있습니다. 따라서 분류 정확도나 순위 성능을 직접 최적화하려는 목표 (제로 원 손실, 다양한 힌지 손실 등)를 사용하는 모델보다 디버그하기 쉽습니다. 예를 들어 학습 중 확률이 병렬로 또는 프로덕션 시스템을 검사하여 예측한 확률에서 벗어날 경우, 이 편차로 인해 문제가 드러날 수 있습니다.

예를 들어 선형, 로지스틱, 푸아송 회귀에서는 데이터의 하위 집합에서 평균 예측 기대값이 평균 라벨 (1모먼트 보정 또는 보정됨)과 같은 것을 알 수 있습니다. 이는 정규화를 사용하지 않고 알고리즘이 수렴되었다는 가정하에 참이며, 일반적으로 거의 참입니다. 각 예시에서 1 또는 0인 특성이 있는 경우 해당 특성이 1인 예 3개의 집합이 보정됩니다. 또한 특성이 모든 예에 1인 경우 모든 예의 집합이 보정됩니다.

단순 모델에서는 피드백 루프를 처리하기가 더 쉽습니다 (규칙 #36 참조). Google에서는 종종 이러한 확률적 예측을 사용하여 결정을 내립니다. 예를 들어 게시물의 순위를 기대하는 값 (즉, 클릭/다운로드 가능성 등)이 낮아지는 경우가 있습니다. 그러나 사용할 모델을 선택할 때는 모델에 따른 데이터 가능성보다 결정이 더 중요합니다 (규칙 #27 참조).

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

품질 순위는 예술이지만 스팸 필터링은 전쟁입니다. 시스템 사용자는 높은 품질의 게시물을 결정하는 데 사용하는 신호를 명확하게 알 수 있으며, 그들은 이러한 속성을 보유하도록 게시물을 조정합니다. 따라서 품질 순위는 선의로 게시된 콘텐츠의 순위를 매기는 데 중점을 두어야 합니다. 스팸의 순위를 높게 지정했다고 해서 품질 순위화 학습자를 무시해서는 안 됩니다. 마찬가지로 '선정적인' 콘텐츠도 품질 순위와 별도로 취급해야 합니다. 스팸 필터링은 완전히 다른 분야입니다. 생성해야 하는 특성은 끊임없이 변화할 것이라는 점을 예상해야 합니다. 시스템에는 명확한 규칙을 따라야 하는 경우가 많습니다. 스팸 투표가 3회를 넘긴 게시물은 검색하지 마세요. 학습된 모델은 더 빨리 업데이트하지 않아도 매일 업데이트해야 합니다 콘텐츠 크리에이터의 평판이 중요한 역할을 합니다

이 두 시스템의 출력을 어느 정도 통합해야 합니다. 검색결과에서 스팸을 필터링하는 것은 이메일 메시지의 스팸을 필터링하는 것보다 더 과감할 수 있습니다. 또한 품질 분류기의 학습 데이터에서 스팸을 삭제하는 것이 표준 관행입니다.

ML 2단계: 특성 추출

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

두 번째 단계에는 쉽게 달성할 수 있는 과일이 많이 있습니다. 다양한 특징들을 시스템으로 가져올 수 있습니다. 따라서 머신러닝의 두 번째 단계에는 최대한 많은 특성을 가져와 직관적인 방식으로 결합하는 것이 포함됩니다. 이 단계에서는 모든 측정항목이 상승세를 보입니다. 많은 출시가 있을 것입니다. 따라서 훌륭한 학습 시스템을 만드는 데 필요한 모든 데이터를 결합할 수 있는 많은 엔지니어를 고용할 수 있는 좋은 기회입니다.

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

지금 작업 중인 모델이 마지막으로 출시되거나 모델 출시를 중단할 것이라고 기대하지 마세요. 따라서 이 출시에 추가되는 복잡성으로 인해 향후 출시가 느려지는지 고려하세요. 많은 팀에서 몇 년 동안 분기별로 또는 그 이상 모델을 출시해 왔습니다. 새 모델을 출시하는 기본적인 세 가지 이유는 다음과 같습니다.

새로운 기능을 준비하고 있습니다.
정규화를 조정하고 이전 특성을 새로운 방식으로 결합하고 있습니다.
목표를 조정하는 중입니다.

어쨌든 모델에 애정을 주면 도움이 될 수 있습니다. 예시에 피드되는 데이터를 살펴보면 새 신호는 물론 손상된 기존 신호도 찾는 데 도움이 될 수 있습니다. 따라서 모델을 만들 때 특성을 추가, 삭제 또는 재결합하기가 얼마나 쉬운지 생각해 보세요. 파이프라인의 새 복사본을 만들고 정확성을 확인하는 것이 얼마나 쉬운지 생각해 보세요. 두 개 또는 세 개의 사본을 동시에 실행할 수 있는지 생각해 보세요. 마지막으로, 특성 35 중 16이 이 파이프라인 버전에 적용되는지 여부는 걱정하지 마세요. 다음 분기에 받으실 수 있습니다.

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

논란의 여지가 있는 주장일 수 있지만 많은 함정을 피할 수 있습니다. 먼저 학습된 특성이 무엇인지 설명하겠습니다. 학습된 특성은 외부 시스템 (예: 비지도 클러스터링 시스템) 또는 학습자 자체 (예: 인수분해 모델 또는 딥 러닝)에 의해 생성된 특성입니다. 두 가지 모두 유용할 수 있지만 문제가 많을 수 있으므로 첫 번째 모델에는 적합하지 않습니다.

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

인수 분해 모델과 심층 모델의 주요 문제는 볼록하지 않다는 점입니다. 따라서 최적의 해를 근사치화하거나 찾을 수 있다는 보장이 없으며, 각 반복에서 발견되는 국소 최솟값이 다를 수 있습니다. 이러한 변화로 인해 시스템 변경사항이 미치는 영향이 유의미한지 무작위인지 판단하기가 어렵습니다. 딥 특성 없이 모델을 만들면 훌륭한 기준 성능을 얻을 수 있습니다. 이 기준을 달성한 후에는 좀 더 복잡한 접근 방식을 시도할 수 있습니다.

규칙 #18: 여러 맥락에서 일반화되는 콘텐츠의 특징을 탐색하라.

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

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

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

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

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

이산화는 연속 특성으로부터 여러 불연속 특성을 만드는 것으로 구성됩니다. 연속적인 특성(예: 연령)을 생각해 보세요. 연령이 18세 미만이면 1인 특성, 18~35세이면 1인 특성 등을 만들 수 있습니다. 히스토그램의 경계에 대해 너무 고민하지 마세요. 기본 분위수로도 대부분의 효과를 얻을 수 있습니다.

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

매우 큰 특성 열을 생성하는 교차는 과적합될 수 있습니다. 예를 들어 검색을 할 때 검색어에 포함된 단어가 포함된 특성 열이 있고 문서에 단어가 포함된 특성 열이 있다고 가정해 보겠습니다. 이때 두 특성을 교차하여 결합하면 지나치게 많은 특성이 생성됩니다 (규칙 #21 참조).

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

규칙 #21: 선형 모델에서 배울 수 있는 특성 가중치의 수는 가지고 있는 데이터의 양에 대략적으로 비례한다.

모델의 적절한 복잡도에 관한 놀라운 통계 학습 이론 결과가 있지만, 이 규칙만 알면 됩니다. 저는 예시가 1,000개나 있으면 무엇을 배울 수 있는지 확신이 서지 않는 대화도 있었어요. 특정 학습 방법에 갇혀 있다면 백만 개 이상의 예시가 필요하겠지요. 핵심은 학습 범위를 데이터 규모에 맞추는 것입니다.

검색 순위 시스템을 사용 중이고 문서 및 검색어에 서로 다른 단어가 수백만 개 있고 라벨이 지정된 예가 1,000개 있는 경우, 문서와 쿼리 특성 간의 내적(TF-IDF), 사람이 직접 설계한 6개의 기타 특성을 사용해야 합니다. 1,000개의 예시, 12가지 특성
예시가 100만 개라면 정규화 및 특성 선택을 사용해 문서 특성 열과 검색어 특성 열을 교차시킵니다. 이를 통해 수백만 개의 특성이 제공되지만 정규화를 사용하면 특성이 줄어들게 됩니다. 1,000만 개의 예시, 10만 개의 특성이 있을 수도 있습니다.
예시가 수십억 또는 수천억 개라면 특성 선택과 정규화를 사용해 특성 열을 문서 및 쿼리 토큰과 교차할 수 있습니다. 그러면 10억 개의 예시와 1, 000만 개의 특성이 생깁니다. 통계적 학습 이론은 절대적인 기준을 거의 제공하지 않지만 시작점으로 삼을 수 있는 훌륭한 지침을 제공합니다.

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

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

미사용 특성은 기술 부채를 발생시킵니다. 사용하지 않는 기능을 다른 기능과 결합해도 소용이 없다면 인프라에서 해당 기능을 중단하세요. 가장 유망한 기능을 가능한 한 빨리 시험해 볼 수 있도록 인프라를 깨끗하게 유지하는 것이 좋습니다. 필요한 경우 다른 사용자가 언제든지 내 기능을 다시 추가할 수 있습니다.

어떤 특성을 추가하거나 유지할지 고려할 때는 적용 범위를 고려하세요. 특성이 얼마나 많은 예를 다루나요? 예를 들어 맞춤설정 기능이 있지만 사용자 중 8% 만 맞춤설정 기능을 사용한다면 그다지 효과적이지 않을 것입니다.

그러나 일부 특성은 중요한 역할을 하기도 합니다. 예를 들어 데이터의 1% 만 포괄하는 특성이 있지만 해당 특성이 있는 예 중 90% 가 양성이라면 그 특성은 추가하는 것이 좋습니다.

인간에 의한 시스템 분석

머신러닝의 세 번째 단계로 넘어가기 전에, 어떤 머신러닝 수업에서도 배우지 않는 주제인 기존 모델을 살펴보고 개선하는 방법에 초점을 맞춰야 합니다. 이것은 과학이라기보다는 예술에 가깝지만 피하는 데 도움이 되는 몇 가지 안티패턴이 있습니다.

규칙 #23: 여러분은 일반적인 최종 사용자가 아니야.

이것이 아마도 팀의 업무 과몰에 빠지는 가장 쉬운 방법일 것입니다. fishfood (팀 내 프로토타입 사용)와 dogfood (회사 내 프로토타입 사용)에는 많은 이점이 있지만 직원들은 성능이 올바른지 확인해야 합니다. 명백하게 잘못된 변경사항은 사용해서는 안 되지만, 프로덕션 단계에 가까울 정도로 합리적으로 보이는 변경사항은 일반 사용자에게 크라우드소싱 플랫폼에서 질문에 답변하거나 실제 사용자를 대상으로 한 실시간 실험을 통해 추가로 테스트되어야 합니다.

여기에는 두 가지 이유가 있습니다. 첫 번째 이유는 코드에 너무 가깝다는 것입니다. 게시물의 특정 측면을 찾고 있거나 지나치게 감정적으로 관여하고 있을 수 있습니다 (예: 확증 편향). 두 번째는 여러분의 시간이 너무 소중하다는 것입니다. 엔지니어 9명이 한 시간 회의에 참석하는 비용을 고려하고 크라우드소싱 플랫폼에서 구매하는 수동 라벨 수가 얼마나 되는지 생각해 보세요.

사용자 의견을 꼭 받고 싶다면 사용자 경험 방법론을 사용하세요. 프로세스 초기에 사용자 캐릭터 (하나는 Bill Buxton의 Sketching User Experiences에 있음)를 만들고 나중에 사용성 테스트를 수행합니다 (설명 1개는 Steve Krug의 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%)을 만들 수 있습니다. 1만 개의 예시로도 성능을 매우 정확하게 예측할 수 있습니다.

규칙 #35: 순위 문제에 내재된 편향에 유의해야 한다.

다른 결과가 표시될 정도로 순위 알고리즘을 급격하게 전환하면 알고리즘이 향후에 보게 될 데이터를 효과적으로 변경한 것입니다. 이러한 유형의 편향이 나타나면 이를 중심으로 모델을 설계해야 합니다. 여러 가지 접근 방식이 있습니다. 이러한 접근 방식은 모두 모델에서 이미 본 데이터를 우선시하는 방법입니다.

쿼리 하나에만 해당하는 특성보다 더 많은 쿼리를 포괄하는 특성에 대해 더 높은 정규화를 적용합니다. 이렇게 하면 모델에서 모든 쿼리로 일반화되는 특성보다 하나 또는 소수의 쿼리에 국한되는 특성이 우선시됩니다. 이 방법을 사용하면 매우 일반적인 결과가 관련 없는 쿼리에 유출되는 것을 방지할 수 있습니다. 이는 고유한 값이 더 많은 특성 열에 더 많은 정규화를 적용하라는 기존의 권장사항과는 반대입니다.
특성에 양수 가중치만 허용합니다. 따라서 좋은 특성이 '알려지지 않은' 특성보다 낫습니다.
문서 전용 기능이 없음 이것은 #1의 극단적인 버전입니다. 예를 들어 쿼리와 관계없이 특정 앱이 인기 있는 다운로드라고 해도 모든 곳에 표시할 수는 없습니다. 문서에만 국한된 특성을 갖지 않아도 문제는 단순해집니다 특정 인기 앱을 모든 곳에 표시하지 않으려는 이유는 원하는 모든 앱에 도달할 수 있도록 하는 것이 중요하기 때문입니다. 예를 들어 '조류 관찰 앱'을 검색하는 사용자가 '앵그리 버드'를 다운로드할 수는 있지만 이는 의도된 것이 아닙니다. 이러한 앱을 표시하면 다운로드율은 높아질 수 있지만 사용자의 궁극적인 니즈는 만족스럽지 않습니다.

규칙 #36: 위치 특성으로 피드백 루프를 방지하라.

콘텐츠의 위치는 사용자가 콘텐츠와 상호작용할 가능성에 크게 영향을 미칩니다. 앱을 첫 번째 위치에 배치하면 더 자주 클릭되므로 클릭될 가능성이 높다는 확신을 가질 수 있게 됩니다. 이 문제를 처리하는 한 가지 방법은 위치 특성, 즉 페이지에서 콘텐츠의 위치에 관한 특성을 추가하는 것입니다. 위치 특성으로 모델을 학습시키면 모델이 '1번째 위치' 특성과 같은 가중치를 많이 학습합니다. 따라서 '1stposition=true'인 예의 경우 모델이 다른 요소에 가중치를 적게 부여합니다. 그러면 서빙 시 어떤 인스턴스에도 위치 특성을 지정하지 않거나 모든 인스턴스에 동일한 기본 특성을 부여합니다. 이는 후보를 표시할 순서를 결정하기 전에 채점되기 때문입니다.

위치 특성은 학습과 테스트의 비대칭성으로 인해 모델의 나머지 부분과 다소 별개로 유지하는 것이 중요합니다. 모델을 위치 특성의 함수와 나머지 특성의 함수의 합으로 하는 것이 이상적입니다. 예를 들어 위치 특성과 문서 특성을 교차하지 마세요.

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

가장 일반적인 측면에서 편향을 일으킬 수 있는 몇 가지 요인이 있습니다. 또한 다음과 같이 여러 부분으로 나눌 수 있습니다.

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

ML 3단계: 성장 둔화, 최적화 개선, 복잡한 모델

2단계가 마무리되고 있음을 나타내는 확실한 징후가 있습니다. 우선, 월별 증가폭이 줄어들기 시작합니다. 그러면 측정항목 간에 절충이 나타나기 시작합니다. 즉, 일부 실험에서 상승하는 측정항목과 하락하는 측정항목이 있습니다. 여기서부터 흥미로워집니다. 개선을 이루기가 더 어렵기 때문에 머신러닝은 더욱 정교해질 필요가 있습니다 주의사항: 이 섹션에는 이전 섹션보다 복잡한 규칙이 더 많습니다. 많은 팀이 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의 여러 팀은 한 제품에서 연결의 밀접성을 예측하는 모델을 가져와서 다른 제품에서 효과적으로 작동하게 함으로써 많은 견인력을 얻었습니다. 친구들이 바로 그 존재입니다. 한편, 제품 부문을 넘나드는 맞춤설정 기능으로 인해 고전하는 팀도 있었습니다. 지금은 그렇지 않은 것 같습니다. 한 가지 속성의 원시 데이터를 사용하여 다른 속성의 동작을 예측하는 것은 효과적이었습니다. 또한 사용자가 다른 서비스에서 활동한 이력이 있다는 것을 아는 것도 도움이 될 수 있습니다. 예를 들어 두 제품에서 사용자 활동이 발생하는 경우 그 자체가 좋은 지표가 될 수 있습니다.

감사의 말씀

데이비드 웨스트브룩, 피터 브랜트, 자무엘 수용, 첸유 자오, 리 웨이, 미칼리스 포타미아스, 크리스틴 로젠, 제임스 파인, 탈 샤케드, 투샤르 찬드라, 무스타파 이스피르, 제레미아 함센노, 무스타파 이스피르, 제레미아 함센노, 무스타파 이스피르, 제레미야 함센노, 무스타파 이스피르, 제레미아 함센노, 무스타파 이스피르, 제레미아 함센노, 무스타파 이스피르, 제레미야 함센노, 무스타파 이스피르, 제레미야 함센노, 무스타파 이스피르, 제레미아 함센노, 무스타파 이스피르, 제레미아 함센노, 무스타파 이스피르, 제레미아 함센노, 무스타파 이스피르, 제레미아 함슨, 댄쉬르 또한 이전 버전에 도움을 주신 Kristen Lefevre, Suddha Basu, Chris Berg에게도 감사드립니다. 오류, 누락 또는 (헐떡임) 인기 있는 의견은 모두 제 것입니다.

부록

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

YouTube 개요

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

Google Play 개요

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

Google+ 개요

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