머신러닝의 규칙:

ML 엔지니어링 권장사항

마틴 진케비치

이 문서는 기계에 대한 기본 지식이 있는 사용자를 돕기 위해 작성되었습니다. Google의 머신러닝 권장사항을 활용할 수 있습니다. 그것은 은 Google C++ 스타일 가이드와 유사하게 머신러닝을 위한 스타일을 나타냅니다. 실용적인 프로그래밍에 대한 기타 인기 가이드를 찾아볼 수 있습니다. 수업을 받은 경우 머신러닝 모델을 빌드하거나 작업한 경우 이 문서를 읽는 데 필요한 배경지식이 있어야 합니다.

마틴 진케비치가 소개하는 규칙 10가지 바로 머신러닝입니다 43가지 규칙을 모두 읽어보세요.

용어

다음 용어는 효과적인 방법론을 설명할 때 반복적으로 등장할 것입니다. 머신러닝:

  • 인스턴스: 무엇인가를 만들려고 하는 대상 학습합니다. 예를 들어 인스턴스를 가고자 하는 웹 페이지가 '고양이에 관한 정보'로 분류 또는 '고양이에 대한 것이 아님' 등이 포함될 수 있습니다
  • 라벨: 예측 작업에 대한 답변 또는 또는 학습 데이터에서 제공된 정답일 수 있습니다. 대상 예를 들어 웹페이지의 라벨은 '고양이 정보'일 수 있습니다.
  • 특성: 예측 작업에 사용되는 인스턴스의 속성입니다. 대상 예를 들어 웹페이지에 '고양이라는 단어를 포함'이라는 특성이 있을 수 있습니다.
  • 특성 열: 관련된 특성의 집합입니다. 예: 가능한 모든 특성 집합 거주할 국가. 예에는 하나 이상의 특성이 있을 수 있습니다. 특성 열에 나와 있습니다. '특성 열' Google에서만 사용하는 용어입니다. 특성 열을 '네임스페이스'라고 함 (예: Yahoo/Microsoft) 또는 필드로 구성됩니다.
  • 예: 인스턴스 (특성 포함) 및 라벨
  • 모델: 예측 작업의 통계적 표현입니다. 모델을 학습시키는 작업 또는 모델을 사용하여 예측을 수행합니다.
  • 측정항목: 중요하게 생각하는 수치입니다. 직접 최적화될 수도 있고, 그렇지 않을 수도 있습니다.
  • 목표: 알고리즘에서 최적화하려는 측정항목입니다.
  • 파이프라인: 머신러닝 알고리즘의 기반을 이루는 인프라입니다. 프런트엔드에서 데이터를 수집하여 학습 데이터에 저장하는 작업이 포함됩니다. 하나 이상의 모델을 학습시키고 모델을 프로덕션으로 내보내면 됩니다.
  • 클릭률: 웹페이지 방문자가 링크 내에 있어야 합니다.

개요

좋은 제품을 만드는 방법은 다음과 같습니다.

Google의 뛰어난 엔지니어가 아닌 당신의 위대한 엔지니어처럼 머신러닝 전문가가 아닙니다

실제로 직면하게 될 문제는 대부분 엔지니어링 문제입니다. 균등 훌륭한 머신러닝 전문가의 모든 리소스와 함께 머신러닝 알고리즘이 아닌 우수한 특성에서 비롯됩니다 기본적인 접근 방식:

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

이 방법은 시간이 오래 걸릴 수 있다는 사실을 알고 있을 겁니다 더 이상 더 이상 할 일이 없는 경우에만 이 접근 방식에서 탈피 더 멀리 갈 수 있는 간단한 트릭. 복잡성이 가중되면 향후 출시 속도가 느려집니다.

간단한 트릭을 모두 해냈다면 최첨단 머신러닝은 도움이 될 것입니다 자세한 내용은 3단계 Vertex AI Feature Store의 핵심 기능을 살펴봤습니다

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

  1. 1부에서는 게시자가 머신러닝 시스템을 구축할 적기입니다.
  2. 2부에서는 살펴보겠습니다
  3. 세 번째 부분은 머신러닝을 위한 파이프라인에 새 특성을 추가하는 동안 반복하기, 모델을 평가하는 방법 학습-서빙 편향을 조정할 수 있습니다
  4. 이 마지막으로 정점에 도달했을 때 해야 할 일에 관한 것입니다
  5. 다음으로 관련 저작물 목록과 일부에 대한 부록 자세한 배경 정보를 알아보겠습니다.

머신러닝 전

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

머신러닝은 멋진 도구지만 데이터가 필요합니다. 이론적으로는 데이터를 새 제품에 맞게 모델을 조정할 수 있지만 기존 키워드보다 실적이 저조할 가능성이 휴리스틱입니다. 만약 머신러닝은 100% 부스트를 제공했지만 휴리스틱은 50%의 성능을 제공합니다. 큰 도움이 되었습니다.

예를 들어 앱 마켓플레이스에서 앱의 순위를 매기는 경우 휴리스틱으로 간주하는 설치율 또는 설치 수 스팸을 감지하는 경우 이전에 스팸을 보낸 적이 있는 게시자를 필터링합니다. 인간적인 면모를 사용하는 것을 두려워하지 마세요 수정할 수도 있습니다 연락처의 순위를 지정해야 하는 경우 가장 최근에 사용한 연락처의 순위를 지정하세요. 또는 알파벳순으로 순위가 매겨질 수도 있습니다. 머신러닝이 머신러닝 모델을 필수 속성이며 데이터가 있을 때까지 사용하지 마세요.

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

머신러닝 시스템이 수행할 작업을 공식화하기 전에 어떻게 해야 할까요? 이렇게 하는 이유는 다음과 같습니다.

  1. 시스템 사용자로부터 미리 사용 권한을 얻는 것이 더 쉽습니다.
  2. 나중에 문제가 될 수 있다고 생각되면 과거 데이터를 가져오는 것이 더 좋습니다.
  3. 측정항목 계측을 염두에 두고 시스템을 설계한다면 더 나아질 것입니다 도움이 될 것입니다. 특히, greping하고 있지만 를 사용하여 측정항목을 계측할 수 있습니다.
  4. 무엇이 바뀌고 무엇이 그대로인지 알게 될 것입니다. 예를 들면 다음과 같습니다. 일일 활성 사용자를 직접 최적화하려 한다고 가정해 보겠습니다. 하지만 시스템을 조기에 조작하는 동안 사용자 환경의 극적인 변화로 인해 이러한 변화가 측정항목입니다.

Google Plus팀은 읽기당 확장, 읽기당 재공유 횟수, +1회 사용자가 사용하는 읽기, 댓글/읽기, 사용자당 댓글, 사용자당 다시 공유 등 게시물의 장점을 계산하는 데 사용됩니다. 또한 실험 프레임워크로, 사용자를 버킷으로 그룹화하고 통계를 제공하는 것이 중요합니다 자세한 내용은 규칙 #12.

측정항목을 보다 적극적으로 수집하면 더 넓은 시각을 얻을 수 있습니다. 시스템에 액세스할 수 있습니다 문제를 발견하셨나요? 추적할 측정항목을 추가하세요. 흥미진진한 물고기 양적 변화가 있었을까요? 추적할 측정항목을 추가하세요.

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

간단한 휴리스틱만으로도 제품을 출시할 수 있습니다. 복잡한 휴리스틱은 유지가 불가능할 수 있습니다 데이터와 목표에 대한 기본 아이디어가 있으면 머신러닝으로 넘어갑니다 대부분의 소프트웨어 엔지니어링과 마찬가지로 비효율적 인지, 경제적이든, 고집적이든 휴리스틱 또는 머신러닝 모델을 사용하며, 업데이트 및 유지 관리가 더 쉽습니다 (자세한 내용은 규칙 #16).

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

첫 번째 파이프라인을 만들 때는 시스템 인프라에 집중하세요. 재미있으면서도 수행할 모든 창의적인 머신러닝을 생각해 보세요. 데이터를 먼저 신뢰할 수 없으면서 무슨 일이 일어나는지 살펴봤습니다

규칙 #4: 첫 번째 모델을 단순하게 유지하고 인프라를 바르게 구축하라.

첫 번째 모델이 제품에 가장 큰 효과를 가져다 주므로 있습니다. 하지만 인프라 문제가 훨씬 더 많을 것입니다. 있습니다. 사용자가 멋진 새로운 머신러닝 시스템을 사용할 수 있으려면 먼저 다음을 결정합니다.

  • 학습 알고리즘에 예시를 가져오는 방법
  • 무엇이 '좋은'지에 대한 첫 번째 장면 '나쁨' 시스템에 영향을 줄 수 있습니다.
  • 모델을 애플리케이션에 통합하는 방법 다음 중 하나를 적용하거나 모델을 라이브로 배포하거나 오프라인으로 예시에 대해 모델을 미리 계산하고 결과를 테이블에 저장합니다. 예를 들어 웹페이지를 사전 분류하고 결과를 채팅 메시지를 실시간으로 분류하는 것이 좋습니다.

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

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

이 세 가지 작업을 안정적으로 수행하는 시스템이 있으면 할 수 있습니다. 간단한 모델은 기준 측정항목과 더 복잡한 모델을 테스트하는 데 사용할 수 있는 기본 동작입니다. 일부 팀의 목표 '중립적'인 경우 최초 실행: 출시의 우선순위를 명시적으로 낮추는 첫 번째 실행입니다. 방해가 되지 않도록 하는 방법을 알아보겠습니다.

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

인프라가 테스트 가능한지, 그리고 인프라의 학습 부분이 시스템은 캡슐화되므로 그 주변의 모든 것을 테스트할 수 있습니다. 특히 다음에 주의해야 합니다.

  1. 알고리즘에 데이터를 가져오는 것을 테스트합니다. 이전에 선택한 채워져야 합니다 개인 정보가 허용되는 경우 학습 알고리즘에 대한 입력값을 검사할 수 있습니다. 가능한 경우 동일한 데이터의 통계와 비교하여 다른 곳에서 처리됩니다
  2. 모델을 학습 알고리즘에서 꺼내는 것을 테스트합니다. 그런 다음 모델의 점수가 모델과 동일한 경우 ( 규칙 #37).

머신러닝에는 예측할 수 없는 요소가 있으므로 학습 및 서빙에서 예를 만들기 위한 코드 테스트가 있습니다. 서빙 중에 고정 모델을 로드하고 사용할 수 있습니다. 또한 자세히 알아보려면 대규모 복잡한 데이터 세트 분석에 관한 실용적인 조언

규칙 #6: 파이프라인을 복사할 때는 데이터가 누락되지 않도록 주의하세요.

우리는 종종 기존 파이프라인 (즉, 화물 컬트 프로그램 이전 파이프라인에서 새 파이프라인에 필요한 데이터가 삭제됩니다. 예를 들어 Google+ HOT 소식의 파이프라인은 최신 게시물의 순위를 지정하기 위해 이전 게시물을 삭제합니다. 이 파이프라인은 Google Plus 스트림에 사용(이전 게시물 포함) 여전히 의미가 있지만 파이프라인에서 여전히 오래된 게시물을 누락시켰습니다. 다른 일반적인 패턴은 사용자가 본 데이터만 기록하는 것입니다. 따라서 이 데이터는 사용자가 특정 게시물을 보지 못한 이유를 모델링하려는 경우 제외 예시가 모두 삭제되었기 때문입니다. 유사한 문제가 다음 지역에서 발생했습니다. 재생. Play 앱 홈에서 작업하는 동안 새로운 파이프라인이 만들어졌으며 Play 게임즈 방문 페이지의 예시가 포함되어 있지 않으며 출처가 명확하지 않은 경우에 유용합니다

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

머신러닝으로 해결하려는 문제는 보통 완전히 새로운 기능입니다. 순위 지정, 분류 또는 분류를 위한 기존 시스템이 있음 해결할 수 있습니다. 이것은 머신러닝 규칙 및 휴리스틱입니다. 이러한 휴리스틱을 조정하면 살펴봤습니다 휴리스틱은 어떤 경우든 그 이유는 두 가지입니다. 먼저, 머신으로 전환하면 더 매끄러워집니다 둘째, 일반적으로 이러한 규칙에는 버리고 싶지 않은 시스템에 대한 직관을 이해할 수 있어야 합니다 4가지 다음과 같은 방법으로 기존 휴리스틱을 사용할 수 있습니다.

  • 휴리스틱을 사용하여 전처리합니다. 이 특성이 매우 훌륭한 경우 이 옵션을 사용할 수 있습니다 예를 들어 스팸 필터에서 발신자가 이미 블랙리스트에 등록되어 있습니다. '블랙리스트'에 포함된 항목을 다시 알아보려고 하지 마세요. 의미합니다 메시지를 차단합니다. 이 접근 방식은 바이너리 데이터 처리에서 가장 합리적이며 분류 태스크에 해당합니다.
  • 특성을 만듭니다. 휴리스틱에서 직접 특성을 생성하면 좋습니다. 예를 들어 휴리스틱을 사용하여 검색어의 관련성 점수를 계산하는 경우 점수를 특성 값으로 포함할 수 있습니다. 나중에 머신러닝 기법을 사용하여 값을 조정하는 것이 (예: 값을 불연속 유한 집합 중 하나로 변환 다른 특성과 결합)을 사용하지만, 처음에는 원시 데이터를 휴리스틱에 의해 생성된 값입니다.
  • 휴리스틱의 원시 입력을 마이닝합니다. 앱에 휴리스틱이 있는 경우 설치 수, 설치 수 그런 다음, 조각을 따로 떼어 낼 수 있습니다. 이러한 입력을 학습에 별도로 제공하는 것입니다. 일부 기법 적용되는 속성입니다 (자세한 내용은 규칙 #40).
  • 라벨을 수정합니다. 이 옵션은 휴리스틱이 더 이상 필요하지 않을 때 현재 라벨에 포함되지 않은 정보를 캡처합니다. 예를 들어 다운로드 수를 극대화하려 하지만 동시에 해답은 라벨에 질 높은 값을 곱하여 평균 별점 수 여기에는 많은 선택이 있습니다. '첫 번째 목표'를 참조하세요.

ML에서 휴리스틱을 사용할 때 추가되는 복잡성에 유의하세요. 있습니다. 새로운 머신러닝 알고리즘에 기존의 휴리스틱을 사용하면 원활한 전환을 위해 도움이 되지만, 동일한 효과를 얻을 수 있는 더 간단한 방법입니다.

모니터링

일반적으로 경보를 실행 가능한 상태로 만드는 것과 같이 적절한 경보 정제를 실천합니다. 대시보드 페이지가 있습니다.

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

모델이 하루가 지나면 성능이 얼마나 저하되나요? 1주일 오래된 것인가요? 한 분기는 어떤가요? 이 정보는 모니터링할 수 있습니다 중요한 제품의 손실이 있는 경우 모델이 업데이트되지 않은 경우의 품질 엔지니어가 하루 동안 지속적으로 동영상을 지켜보는 것이 합리적입니다. 대부분의 광고 매일 처리해야 하는 새로운 광고가 있으며 매일 예를 들어 ML 모델을 학습시키고 Google Play 검색은 업데이트되지 않으며 부정적인 영향을 미쳤습니다. '인기 급상승 동영상'에 대한 일부 모델 Google Plus의 모델에는 게시물 식별자가 없으므로 그들은 할 수 있습니다 내보낼 필요가 없습니다 게시물 식별자가 있는 다른 모델은 훨씬 더 자주 업데이트됩니다. 또한 업데이트 빈도는 시간이 지남에 따라 특히 특성 열이 모델에서 추가되거나 모델에서 삭제될 때 유용합니다

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

많은 머신러닝 시스템에는 모델을 학습시키기 위해 있습니다. 내보낸 모델에 문제가 발생하는 경우 있습니다.

모델을 내보내기 직전에 상태 검사를 수행합니다. 특히 홀드아웃 데이터에서 모델의 성능이 합리적임을 확인할 수 있습니다. 또는 문제가 지속되는 경우 모델을 내보내지 마세요. 여러 팀 모델이 지속적으로 배포되는 ROC 곡선 (또는 AUC) 확인하세요. 내보내지 않은 모델 관련 문제를 해결하려면 이메일 알림을 받고 싶지만 사용자 대상 모델에 문제가 있는 경우 페이지가 필요할 수 있습니다. 매우 좋음 사용자에게 영향을 미치기 전에 기다려야 합니다

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

다른 머신러닝 시스템보다 머신러닝 시스템에서 더 많이 발생하는 문제입니다. 생각해야 합니다. 조인되는 특정 테이블이 더 이상 업데이트되지 않습니다. 머신러닝 시스템이 조정하면 계속 합리적으로 좋아서 서서히 낮아질 것입니다 때로는 테이블을 교체할 수 있으며, 간단한 업데이트로 성능이 개선됨 50% 증가했습니다. 이 커버리지 범위 구현 변경사항으로 인해 기능이 변경될 수 있음(예: 특성 열) 예의 90% 에 채워질 수 있었고, 갑자기 60% 로 떨어집니다. 예로 들 수 있습니다 Play에서 테이블이 6개월 동안 비활성 상태였고 새로고침된 적이 있음 표만 봐도 설치율이 2% 증가했습니다. 특정 기간에 대한 통계를 추적하면 때때로 데이터를 수동으로 검사할 뿐만 아니라 수동으로 검사하는 대신 이러한 장애를 방지할 수 있습니다.

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

시스템이 크고 특성 열이 많은 경우 누가 생성했는지 확인합니다. 각 특성 열을 유지 관리하거나 만약 특성 열이 나가고 있다는 것을 이해하는 경우 누군가가 확인할 수 있습니다 많은 특성 열에 설명이 포함된 이름이 있지만 이 기능이 무엇인지, 어디에서 왔는지 자세히 설명할 수 있었음 도움이 될 것이라고 예상할 수 있습니다

첫 번째 목표

관심 있는 시스템에 대한 측정항목 또는 측정값이 많기 때문에 그러나 머신러닝 알고리즘에는 종종 하나의 목표, 즉 알고리즘이 '시도하는' 숫자입니다. 최적화됩니다 CANNOT TRANSLATE 목표 및 측정항목 간: 측정항목은 시스템에서 사용하는 모든 숫자입니다. 이는 중요할 수도 있고 그렇지 않을 수도 있습니다. 참고 항목 규칙 #2.

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

사용자는 수익을 창출하고, 사용자의 만족도를 높이고, 더 나은 세상을 만들고자 합니다. 있습니다. 중요하게 생각하는 측정항목은 수없이 많습니다. (규칙 #2 참조) 하지만 머신러닝 프로세스의 초기 단계인 경우 모두 증가하지만 제외 키워드도 있습니다 예를 들어, 사용자가 클릭수 및 사이트에 머문 시간 1,000회 노출로 클릭하면 소요 시간이 증가할 가능성이 큽니다.

따라서 간결하게 유지하고 서로 다른 측정항목의 균형을 맞추는 데 너무 신경 쓰지 마세요. 모든 측정항목을 손쉽게 늘릴 수 있는 경우 이 규칙도 적용하지 마세요. 하지만 목표를 캠페인의 궁극적인 상태와 혼동해서는 안 됩니다. 시스템( 규칙 #39). 또한 예산을 직접 늘려 측정항목을 최적화했지만, 출시하지 않기로 결정하면 목표 수정이 확인할 수 있습니다

규칙 #13: 첫 번째 목표로는 간단하고 관측 가능하며 기여 가능한 측정항목을 선택하라.

때로는 진짜 목표가 무엇인지 모를 때가 많습니다. 그렇게 생각하지만 그런 다음 이전 시스템과 새로운 ML을 나란히 놓고 분석한 데이터와 목표를 조정하고 싶을 수 있습니다. 또한 회원들이 진정한 목표에 동의하지 못하는 경우가 많습니다 ML 목표는 측정이 용이하고 '실제'를 나타내는 확인할 수 있습니다 사실, 'true'라는 단어는 ( 규칙#39). 그래서 '정책 레이어' 마련을 고려하세요 맨 위에 추가 로직 (매우 간단한 로직)을 추가하여 최종 순위도 확인할 수 있습니다.

가장 모델링하기 쉬운 대상은 직접 관찰되고 특정 활동으로 인해 발생한 사용자 행동입니다 합니다.

  • 순위가 매겨진 링크를 클릭했나요?
  • 순위가 매겨진 객체가 다운로드되었나요?
  • 순위가 지정된 객체가 전달/답장/이메일로 전송되었나요?
  • 순위가 매겨진 개체가 평가되었습니까?
  • 표시된 객체가 스팸/포르노/불쾌감을 주는 것으로 표시되었나요?

처음에는 간접적인 효과 모델링을 피하세요.

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

간접 효과는 훌륭한 측정항목이 되며 A/B 테스트 및 출시 중에 사용할 수 있습니다. 있습니다.

마지막으로, 다음 사항을 파악하기 위해 머신러닝을 활용하지 마세요.

  • 사용자가 제품 사용에 만족하나요?
  • 사용자가 경험에 만족하나요?
  • 제품이 사용자의 전반적인 웰빙을 개선하나요?
  • 회사의 전반적인 건전성에 어떤 영향을 미칠까요?

모두 중요하지만 측정하기가 매우 어렵습니다. 대신 프록시: 사용자가 만족하면 사이트에 더 오래 머무를 것입니다. 사용자가 내일 다시 방문할 것입니다. 웰빙과 문제가 있는 경우, 인간의 판단이 필요한 경우 판매하는 제품의 특성에 맞게 머신러닝 목표를 설정하고 사업 계획서가 될 수 있습니다.

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

선형 회귀, 로지스틱 회귀, 푸아송 회귀는 확률적 모델에 의해 동기가 부여됩니다. 각 예측은 확률 또는 기댓값입니다. 이렇게 하면 모델보다 디버그하기가 더 쉽습니다. 목표 (예: 0-1 손실, 다양한 힌지 손실 등)를 사용하여 분류 정확성이나 순위 성능을 직접 최적화할 수 있습니다 대상 예를 들어 학습의 확률이 프로덕션 시스템을 검사하거나 정렬하면 이 편차가 문제를 드러낼 수 있습니다

예를 들어 선형, 로지스틱, 푸아송 회귀에는 하위 집합도 있습니다. 평균 예측 기대치가 평균 라벨 (1- 또는 방금 보정된 시점 중 하나)를 선택합니다. 이는 알고리즘이 수렴되었는지를 확인할 수 있으며, 일반적으로 true입니다. 각 예시에서 1 또는 0인 특성이 있는 경우 특성이 1인 예 3개로 이루어진 세트가 보정됩니다. 또한 특성이 모든 예시에 대해 1이면 모든 예시의 집합은 보정되었습니다.

간단한 모델을 사용하면 피드백 루프( 규칙 #36). 우리는 종종 이러한 확률 예측을 사용하여 결정을 내립니다. 예를 들어 순위 게시물의 예상값이 감소합니다 (예: 클릭/다운로드 등). 그러나 사용할 모델을 선택할 때는 모델이 주어진 데이터가 있을 가능성보다 더 중요하다고 생각합니다 (자세한 내용은 규칙 #27)

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

품질 순위는 예술이지만 스팸 필터링은 전쟁입니다. 사용자가 고품질의 게시물을 판단하는 데 사용하는 정보는 이러한 속성을 포함하도록 게시물을 수정할 것입니다. 따라서 품질 순위는 '우수'하게 게시된 콘텐츠의 순위를 매기는 데 믿음에 뿌리를 두고 있습니다. 스팸 순위 지정을 위해 품질 순위 학습자를 무시해서는 안 됩니다. 매우 높습니다. 마찬가지로 '선정적인' 콘텐츠 콘텐츠는 품질과 별도로 처리되어야 함 순위. 스팸 필터링은 완전히 다릅니다. 첫 번째 입력의 끊임없이 변화하기 때문입니다. 종종 시스템에 적용하는 명확한 규칙이 됩니다 (게시물에 사용하지 마세요. 등). 모든 학습된 모델은 매일 업데이트됩니다 콘텐츠가 큰 역할을 할 것입니다.

이 두 시스템의 출력을 어느 정도 통합해야 합니다. 유지 검색 결과에서 스팸을 필터링하는 것이 더 격렬하게 이메일 메시지의 스팸을 필터링하는 것보다 더 효율적입니다. 또한 일반적으로 스팸을 찾아냅니다.

ML 2단계: 특성 추출

머신러닝 시스템 수명 주기의 첫 번째 단계에서는 중요한 문제는 학습 데이터를 학습 시스템으로 가져오고, 빌드하고 서빙 인프라를 구축할 수 있었습니다. 이후 단위 테스트와 시스템 테스트를 계측하여 작동하는 엔드 투 엔드 시스템이 있으며 2단계가 시작됩니다.

두 번째 단계에서는 달성하기 쉬운 과일이 많이 있습니다. Vertex AI Feature Store에는 몇 가지 명백한 특징이 있을 것입니다. 따라서 두 번째 최대한 많은 특성을 추출하여 이를 직관적인 방식으로 조합하는 것입니다. 이 단계에서는 모든 측정항목이 계속 증가하고 있습니다 많은 출시가 있을 예정입니다. 이번 기회에 수많은 엔지니어를 고용해 데이터를 수집하고 훌륭한 학습 시스템을 만들 수 있었습니다.

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

지금 작업하고 있는 모델이 문제가 되는 마지막 모델이 될 것이라고 기대하지 모델을 출시하거나 출시를 중단할 수도 있습니다 따라서 이번 출시로 더 복잡해지는 복잡성이 느려질지 고려해 보세요. 향후 출시 예정. 많은 팀에서 분기당 또는 그 이상의 기간 동안 있습니다. 새 모델을 출시하는 기본적인 세 가지 이유는 다음과 같습니다.

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

어떤 경우든, 모델에 약간의 애정을 불어넣으면 유용할 수 있습니다. 즉, 데이터 검토 예시를 제공하면 새 신호는 물론 오래되고 깨진 잘못된 신호를 찾는 데 도움이 될 수 있습니다. 있습니다. 모델을 빌드할 때는 모델을 얼마나 쉽게 추가하거나 제거하기가 쉬운지 특성을 재조합할 수 있습니다 새 제품 사본을 만드는 것이 정확성을 검증합니다 한 가지 가능한 모든 것들에 대해 두 개 또는 세 개의 사본이 동시에 실행되는 것을 볼 수 있습니다. 마지막으로 특성 16/35가 이 버전의 파이프라인에 포함되는지 여부를 결정합니다 사용자는 다음 분기에 꼭 받아보실 수 있습니다.

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

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

외부 시스템을 사용하여 특성을 만드는 경우 자체적인 목표가 있습니다 외부 시스템의 목표는 미약할 수 있음 현재 목표와 상관관계가 있는지를 나타낼 수 있습니다 외부 IP 주소가 오래된 정보가 될 수 있습니다 새 창에서 기능을 업데이트하면 바꾸면 의미가 바뀔 수 있습니다 외부 시스템을 사용하여 제공하는 경우 이 접근 방식에는 상당한 주의가 필요하다는 점에 유의하세요.

분해 모델과 심층 모델의 가장 큰 문제는 비볼록입니다. 따라서 최적의 솔루션이 근사치 또는 발견된 결과를 구할 수 있고, 각 반복에서 찾은 국소 최솟값은 다릅니다. 이러한 차이로 인해 특정 키워드의 효과를 판단하기가 의미가 있는지 또는 무작위적인지 확인해야 합니다. 선행 학습된 BERT 모델을 사용하지 않고 높은 기본 성능을 얻을 수 있습니다. 이후 더 난해한 접근 방식을 시도할 수 있습니다.

규칙 #18: 다양한 맥락에서 일반화되는 콘텐츠 특성을 이용해 탐색하라.

머신러닝 시스템은 훨씬 큰 그림에서 작은 일부에 불과한 경우가 많습니다. 대상 예를 들어 'HOT 소식'에 사용될 수 있는 게시물이 있다고 상상하면 댓글이 '무엇'에 표시되기 전에 소식에 +1하거나 다시 공유하거나 댓글을 남김 뜨겁습니다. 학습자에게 이러한 통계를 제공하면 새 게시물을 홍보할 수 있습니다. 데이터가 없다는 것을 의미합니다. YouTube의 다음 볼만한 동영상 기능에 시청 횟수 또는 조회수 (다른 동영상을 본 후 특정 동영상을 시청한 횟수 YouTube 검색에서 시청한 동영상)를 표시합니다. 또한 명시적 사용자 평가 마지막으로, 라벨로 사용 중인 사용자 액션이 있는 경우 문서에 대한 작업을 다른 맥락에서 보는 것이 기능을 사용할 수 있습니다. 이러한 모든 기능을 통해 새로운 콘텐츠를 맥락에 맞게 적용할 수 있습니다. 개인화가 아니라는 점에 유의하세요. 사용자가 내 콘텐츠를 좋아하는지 먼저 이 문맥에서 콘텐츠를 살펴본 다음 누가 그 콘텐츠를 더 좋아하거나 덜 좋아하는지 파악하세요.

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

방대한 데이터를 기반으로 수백만 개의 간단한 특성을 배우는 것이 몇 가지 복잡한 기능을 알아봅니다. 검색 중인 문서의 식별자 및 정규화된 쿼리는 많은 일반화를 제공하지 않지만 라벨로 순위를 매길 수 있습니다. 따라서 IT 지원 전문가 집단을 두려워하지 마세요. 각 특성이 데이터의 극히 일부에만 적용되지만 전체 노출 범위가 90%를 넘습니다 정규화를 사용해 몇 가지 예시에만 적용되는 특성을 가질 수 있습니다

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

특성을 결합하고 수정하는 방법은 다양합니다. 머신러닝 TensorFlow와 같은 시스템을 사용하면 전처리 기능을 통해 변환입니다. 가장 표준적인 두 가지 접근 방식은 '불연속화' '십자가'가 있습니다.

이산화는 연속적인 특성을 취하여 여러 개의 분리할 수 있습니다. 연속 특성(예: 연령)을 생각해 보세요. 다음을 수행할 수 있습니다. 나이가 18세 미만이면 1인 특성을 생성하고, 1을 표시합니다. IT 지원의 한계를 너무 깊이 생각하지 마세요. 이 히스토그램: 기본 분위수를 사용하면 대부분의 효과를 얻을 수 있습니다.

교차는 둘 이상의 특성 열을 결합합니다. TensorFlow의 동질 집단의 집합(예: {남성, 여성}, {미국, 캐나다, 멕시코} 등). 교차는 특성이 포함된 새로운 특성 열입니다. 예: {남성, 여성} × {미국, 캐나다, 멕시코}. 이 새로운 특성 열은 지형지물 (남성, 캐나다)을 포함합니다. TensorFlow를 사용 중이고 이 교차를 생성하도록 TensorFlow에 지시하면 이 (남성, 캐나다) 특성이 캐나다 남성을 대표하는 예에 등장할 수 있습니다. 이 작업을 수행하려면 3, 4 또는 그 이상의 기수를 교차하여 모델을 학습하기 위한 데이터의 양 특성 열을 살펴보겠습니다.

매우 큰 특성 열을 생성하는 교차는 과적합될 수 있습니다. 예를 들면 다음과 같습니다. 일종의 검색을 수행하는데 특성 열이 있다고 가정해 보겠습니다. 포함되어 있고 이 특성에 해당 단어의 단어가 포함된 문서를 참조하세요. 이를 교차로 조합할 수 있지만 결국에는 많은 (규칙 #21 참조)

텍스트로 작업할 때 두 가지 대안이 있습니다. 가장 엄격한 방법은 내적이라고 합니다. 가장 단순한 형태의 내적은 단순히 더 많은 단어가 표시됩니다. 그러면 이 특성을 있습니다. 또 다른 접근 방식은 교차로입니다. 따라서 'pony'라는 단어가 가 문서 및 그리고 단어 'the'가 검색될 때만 표시되는 위치: 모두 쿼리합니다.

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

인공지능과 관련하여 매우 뛰어난 통계적 학습 이론 결과가 모델의 복잡도 수준을 높여줄 수 있지만, 기본적으로 이 규칙은 알아야 할 것입니다. 사람들이 무엇이든지 1, 000개의 예를 통해 배울 수 있거나 특정 메서드에 고착하기 때문에 100만 개 이상의 예시가 필요합니다. 중요한 역할을 합니다 핵심은 학습 규모를 데이터 규모에 맞게 확장하는 것입니다.

  1. 검색 순위 시스템을 개발하는 중인데 수백만 개의 1,000개의 단어가 포함된 문제가 있는 경우 문서 사이에 내적을 사용해야 합니다. 쿼리 특성, TF-IDF, 고도로 인간이 설계되어 있는 기능을 살펴보겠습니다 예시 1,000개, 특성 12개
  2. 예시가 100만 개라면 문서와 쿼리를 교차시킵니다. 정규화 및 특성 선택을 사용하여 특성 열을 생성합니다. 이를 통해 수백만 개의 특성을 얻을 수 있지만 정규화를 통해 감소합니다. 1,000만 개의 예시, 10만 개의 특성
  3. 예시가 수십억 또는 수천억 개라면 문서 및 쿼리 토큰이 있는 특성 열(특성 선택 사용) 살펴보겠습니다 10억 개의 예시와 1, 000만 개의 예시가 기능을 살펴보겠습니다 통계적 학습 이론은 엄격한 기준을 거의 제시하지 않지만 시작점으로 활용할 수 있습니다

마지막에는 규칙 #28 사용할 기능을 결정합니다

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

사용되지 않는 특성은 기술적 부채를 발생시킵니다. 당신이 사용하는 것을 발견할 수 있다면 다른 기능과 결합해도 되지 않는 경우 분리할 수 있습니다 인프라를 깨끗하게 유지하여 최대한 빨리 시험해 볼 수 있을 것입니다. 만약 누군가 언제든지 지형지물을 다시 추가할 수 있습니다.

추가하거나 유지할 특성을 고려할 때는 적용 범위를 고려하세요. 개수 기능이 포함된 예시 예를 들어, 8% 의 사용자만 맞춤설정을 사용 기능을 사용하면 그다지 효과적이지 않을 것입니다.

동시에 일부 특성은 무게를 넘을 수 있습니다. 예를 들어 데이터의 1% 만 커버하는 특성이 있는데, 예시의 90% 는 이 특성이 긍정적이면 추가하는 것이 좋은 특성이 될 것입니다.

시스템에 대한 인적 분석

머신러닝의 세 번째 단계로 넘어가기 전에 머신러닝 수업에서 가르치지 않는 주제인 기존 모델을 살펴보고 개선해야 합니다. 예술에 가깝고 그러나 그것이 피하는 데 도움이 되는 몇 가지 안티패턴이 있습니다.

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

이는 팀이 어려움을 겪는 가장 쉬운 방법일 것입니다. 여러 많은 이점을 누리고 있습니다 (팀 내에서 프로토타입 사용). 사내 프로토타입을 사용해 dogfood하는 경우 직원들은 확인할 수 있습니다. 당연히 나쁜 변화는 사용하지 말아야 하는 경우, 프로덕션 직전에 합리적으로 보이는 것은 질문에 답하기 위해 일반인에게 돈을 지불하거나 크라우드소싱 플랫폼이나 실제 사용자를 대상으로 한 실시간 실험을 통해 수익을 창출할 수 있습니다.

여기에는 두 가지 이유가 있습니다. 첫 번째는 가까운 시일 내지에 너무 가깝다는 있습니다. 게시물의 특정 측면을 찾고 있거나 너무 감정적으로 묶여 있을 수 있습니다 (예: 확증 편향). 두 번째는 시간이 너무 소중합니다 9명의 엔지니어가 한 명당 한 명씩 몇 개의 계약자 라벨이 크라우드소싱 플랫폼입니다.

사용자 의견이 정말로 필요한 경우 사용자 환경을 이용하세요. 방법론을 고안했습니다. 사용자 캐릭터 생성 (설명은 Bill Buxton의 사용자 환경 스케치) 사용성 테스트를 진행하여 설명은 Steve Krug의 Don’t Make Me Think) 확인할 수 있습니다 사용자 캐릭터 가상의 사용자를 만드는 것입니다. 예를 들어 팀원이 모두 남성인 경우 35세의 여성 사용자 페르소나를 설계하는 것이 10개가 아닌 그 결과로 생성된 결과를 확인해 보세요. 대상: 만 25~40세 남성. 실제 사람들이 리액션을 볼 수 있도록 유도 사용성 테스트를 통해 사이트가 로컬 또는 원격으로 살펴봤습니다

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

한 달 전에 측정이 가능한 가장 쉽고 유용한 방법 중 하나는 사용자가 새 모델을 본 적이 있는 모든 사용자가 프로덕션에서 가져온 것입니다 예를 들어 순위 문제가 있는 경우 전체 시스템에서 쿼리 샘플에 대해 두 모델을 실행하고 결과의 대칭 차 크기 (순위로 가중치 적용) 위치)로 이동합니다. 차이가 매우 작다면 직접 실행하지 않고도 알 수 있습니다. 실험을 할 때는 변화가 거의 없을 것이라고 합니다. 차이가 크다면 변경이 좋은지 확인하는 것이 좋습니다. 바라보기 대칭 차이가 큰 쿼리를 사용하면 어떤 변화가 있었는지를 정성적으로 분석해 보았습니다 하지만 시스템이 있습니다. 모델을 자체와 비교할 때 모델이 낮은지 확인합니다 (이상적으로는 0) 대칭 차이를 나타냅니다.

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

모델에서 클릭률을 예측하려고 할 수 있습니다. 그러나 결국 핵심은 질문은 해당 예측으로 무엇을 하는지입니다. 이 도구를 사용하여 최종 순위의 품질이 학습합니다. 문서가 스팸일 가능성을 예측하고 차단되는 항목을 컷오프하면 허용되는 항목의 정밀도가 더 잘 대처할 수 있습니다 대부분의 경우 이 두 가지가 동의하지 않으면 작은 이득을 볼 가능성이 큽니다. 따라서 로그 손실은 개선하지만 로그 손실의 성능을 저하시키는 몇 가지 변경사항이 있습니다. 다른 기능을 찾아보세요. 이러한 상황이 더 자주 발생하기 시작하면 모델의 목표를 재검토할 때입니다.

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

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

반면에 인코더-디코더 아키텍처의 예시를 기반으로 시스템이 실수로 식별하지 않는 경우 기능은 무시됩니다. 예를 들면 다음과 같습니다. Play 앱 검색에서 사용자가 '무료 게임'을 검색한다고 가정해 보겠습니다. 가정 상위 검색 결과 중 하나가 관련성이 낮은 개그 앱입니다. 즉, 특성 추출을 사용하여 '개그 앱'이 포함됩니다. 그러나 설치 수를 최대화하고 무료 게임을 검색할 때 '개그 앱'을 설치함 특성 원하는 효과를 얻지 못할 수 있습니다.

모델이 틀린 예시가 있으면 적용할 수 있습니다 예를 들어 시스템이 게시물 길이를 추가한 다음 게시물 길이를 추가하세요. 너무 구체적으로 추가할 수 있습니다. 게시물 길이를 추가할 경우 특성을 십여 개 추가하기만 하면 모델이 알아서 하도록 할 수 있습니다. 함께 사용할 수 있습니다 (자세한 내용은 규칙 #21 ). 그것이 원하는 것을 얻는 가장 쉬운 방법입니다.

규칙 #27: 바람직하지 않은 동작이 관찰되면 정량화를 시도하라.

팀원 중 한 명은 기존 손실 함수로 포착되지 않는 시스템을 예로 들 수 있습니다 위치 이 지점에서 불만이 확고한 것으로 바뀌려면 뭐든지 해야 합니다. 있습니다. 예를 들어 '개그 앱'이 너무 많다고 생각한다면 게재 중 개그 앱을 찾아내기도 했습니다. ( 사람이 라벨이 지정된 데이터를 사용하는 것이 일부 검색어가 트래픽의 많은 부분을 차지합니다.) 만약 측정 가능하고 이를 기능, 목표, 측정항목 등이 있습니다 일반적인 규칙은 '측정 후 최적화'입니다.

규칙 #28: 단기적인 행동이 같다고 해서 장기적인 행동이 같다는 의미는 아니라는 점을 명심하라.

모든 doc_id와exact_query를 확인하는 새로운 시스템이 있다고 가정해 보겠습니다. 그런 다음 모든 쿼리에 대해 모든 문서의 클릭 가능성을 계산합니다. 두 영역에서 모두 현재 시스템과 거의 동일하다는 것을 알 수 있습니다. 비교 및 A/B 테스트를 진행할 수 있어 간편합니다. 그런데 새 앱이 표시되지 않습니다. 왜냐하면 왜냐하면 해당 쿼리의 자체 기록을 기반으로 문서만 표시하므로 학습하는 데 도움이 됩니다.

이러한 시스템이 장기적으로 어떻게 작동할지 이해하는 유일한 방법은 모델이 활성 상태일 때 획득한 데이터로만 학습합니다. 이것은 있습니다.

학습-서빙 편향

학습-서빙 편향은 학습 도중 성능과 성능을 향상할 수 있습니다. 이 편향은 다음과 같은 이유로 발생할 수 있습니다.

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

Google에서 프로덕션 머신러닝 시스템을 살펴보면서 성능에 부정적인 영향을 주는 서빙 편향을 줄일 수 있습니다 가장 좋은 해결책은 시스템 및 데이터 변경으로 인해 편향이 발생하지 않도록 명시적으로 모니터링 발견되지 않았습니다.

규칙 #29: 서빙하는 것과 같은 방식으로 학습하도록 하는 가장 좋은 방법은 서빙 시 사용된 특성 세트를 저장한 다음 이러한 특성을 로그에 파이핑하여 학습 시에 사용하는 것입니다.

모든 예시에서 이 작업을 실행할 수는 없더라도 서빙과 학습 사이의 일관성을 확인할 수 있습니다 (자세한 내용은 규칙 #37). 지금까지 그 결과에 놀라는 경우가 있었습니다. YouTube 홈페이지 서빙 시점에 고품질 로깅 특성으로 전환됨 코드 복잡성이 감소하고 개선이 이루어졌으며, 많은 팀에서 몇 가지 기본 인프라를 제공합니다

규칙 #30: 샘플링된 데이터에 중요도에 따른 가중치를 부여하고 임의로 삭제하면 안 된다.

데이터가 너무 많으면 파일을 1-12로 가져가고, 파일 13~99는 무시합니다. 이는 잘못된 생각입니다. 이전에 사용되었던 데이터가 삭제될 수 있지만 중요도 가중치는 있습니다. 중요도 가중치는 가중치를 부여해야만 30% 의 확률로 샘플 예 X를 생성한 다음 가중치 10/3을 부여합니다. 대상: 보정에 대해 설명한 것처럼, 중요도 가중치 부여와 규칙 #14 유지될 수 있습니다

규칙 #31: 학습 및 서빙 시에 테이블의 데이터를 조인하면 테이블의 데이터가 변경될 수 있다는 점에 유의한다.

문서 ID를 해당 문서의 기능 (예: 댓글 수 또는 클릭수). 학습과 서빙 시간 사이에 테이블이 변경될 수 있습니다 동일한 문서에 대한 모델의 예측이 학습과 서빙 간에 차이가 있습니다 이러한 분류를 피하는 가장 쉬운 방법은 가장 큰 문제는 서빙 시간에 특성을 기록하는 것입니다 규칙 #32 ). 테이블이 천천히만 변경되므로 1시간 또는 일별로 테이블의 스냅샷을 생성하여 데이터를 수집해야 합니다. 이 방법으로도 문제가 완전히 해결되지는 있습니다.

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

일괄 처리는 온라인 처리와 다릅니다. 온라인 처리에서는 각 요청이 도착할 때마다 처리해야 합니다 (예: 각 쿼리에 대해)이지만 일괄 처리에서는 작업 (예: 합니다. 서빙 시에는 온라인 처리를 수행하는 반면, 학습은 일괄 처리 작업입니다. 하지만 설정 시 주의해야 할 몇 가지 방법을 알아보겠습니다. 예를 들어, 2012년 3월 31일까지 쿼리 또는 조인의 결과가 매우 사람이 읽을 수 있는 방식으로 저장되며 오류를 쉽게 테스트할 수 있습니다. 그런 다음 서빙이나 학습 중에 모든 정보를 수집한 후에는 공통 메서드를 실행하여 사람이 읽을 수 있는 객체와 그리고 머신러닝 시스템의 형식에 관계없이 있습니다 이렇게 하면 학습-서빙 편향의 원인을 없앨 수 있습니다. 결국 학습 프로세스 간에 서로 다른 두 가지 프로그래밍 언어를 사용하지 살펴보겠습니다 그렇게 결정하면 다른 사람과 있습니다.

규칙 #33: 1월 5일까지의 데이터를 기반으로 모델을 생성한다면 1월 6일 이후의 데이터로 모델을 테스트하라.

일반적으로 데이터가 수집된 후에 수집된 데이터를 기준으로 모델의 성능을 측정합니다. 모델이 학습할 작업을 더 잘 반영하기 때문입니다. 있습니다 1월 5일까지 데이터를 기반으로 모델을 생성하는 경우 모델을 학습시키는 작업도 반복해야 합니다 이때 성능은 새로운 데이터만큼 좋지는 않지만 근본적으로 나빠져서는 안 됩니다. 일일 영향이 있을 수 있으므로 평균 클릭수를 예측하지 못할 수 있음 평균 1,500회 노출률을 나타내지만 양성 예제에 음성보다 높은 점수를 줄 가능성 상당히 비슷해야 합니다.

규칙 #34: 필터링을 위한 이진 분류 (스팸 감지 또는 관심 있는 이메일 파악)에서는 단기적인 성능을 희생해야만 매우 정제된 데이터를 얻을 수 있다.

필터링 작업에서 음성으로 표시된 예는 있습니다. 제외 예의 75% 를 차단하는 필터가 있다고 가정해 보겠습니다. 제공합니다. 아마도 데이터에서 추가 학습 데이터를 추출하고 사용자에게 표시되는 인스턴스입니다 예를 들어 사용자가 필터링이 통과되었는지 여부를 확인하는 것이 좋습니다.

그러나 이 접근 방식은 샘플링 편향을 초래합니다. 다음과 같은 경우에 더 깨끗한 데이터를 수집할 수 있습니다. 대신 게재 중에는 전체 트래픽의 1% 에 대해 '홀드아웃' 라벨을 지정하고 사용자에게 예시를 제시했습니다. 이제 필터가 제외 예시 이러한 홀드아웃 예시는 학습 데이터가 될 수 있습니다.

필터가 음성 예시의 95% 이상을 차단하는 경우 실현 가능성이 떨어집니다 그럼에도 불구하고 더 작은 샘플을 만들 수 있습니다 (예: 0.1% 또는 0.001%). 십 천 개의 예시가 있으면 성능을 상당히 정확하게 추정하기에 충분합니다.

규칙 #35: 순위 문제의 내재적 편향에 유의하세요.

서로 다른 결과가 나올 정도로 순위 알고리즘을 급격히 전환하는 경우 알고리즘이 가져올 데이터를 효과적으로 변경했고 볼 수 있습니다. 이런 종류의 편향이 나타날 것입니다. 모델을 기반으로 합니다. 여기에는 여러 가지 방법이 있습니다. 이러한 접근 방식은 모델이 이미 확인한 데이터를 우선시할 수 있습니다.

  1. 보다 많은 쿼리를 포괄하는 특성에 대해 더 높은 정규화를 모든 특성을 정의하는 데 도움이 될 수 있습니다 이렇게 하면 모델이 몇 가지 쿼리에 국한되는 특성을 일반화할 수 없습니다. 이 방법을 사용하면 결과를 필터링할 수 있습니다. 이것은 특성 열에 더 많은 정규화를 적용하라는 기존의 권장사항 사용할 수 있습니다.
  2. 특성에 양수 가중치만 허용합니다. 따라서 좋은 특성은 더 낫습니다.
  3. 문서 전용 기능을 사용하지 않습니다. 이것은 #1의 극단적인 버전입니다. 대상 예를 들어 앱이 무엇을 다운로드하든 모든 곳에 표시하고 싶지는 않을 것입니다. 문서 전용 기능이 없음 기능을 간소화합니다 특정 광고를 게재하지 않으려는 이유는 사람들의 삶을 좌우하는 것이 원하는 모든 앱에 연결할 수 있습니다. 예를 들어 사용자가 '앵그리 버드'를 다운로드할 수는 있지만 의도가 아니었습니다. 이러한 앱을 표시하면 다운로드율이 높아질 수 있지만, 사용자의 니즈가 궁극적으로 불만족스러울 수 있습니다

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

콘텐츠의 위치는 사용자의 상호작용 가능성에 큰 영향을 미칩니다. 사용할 수 있습니다. 앱을 첫 번째 위치에 배치하면 더 자주 클릭되기 때문에 클릭 가능성이 더 높다는 확신을 줄 수 있습니다. 한 가지 방법은 이는 위치 지형지물, 즉 해당 객체의 위치에 대한 지형지물을 추가하는 것입니다. 있습니다. 위치 특성을 사용하여 모델을 학습시킵니다. 예를 들어 '1stposition' 특성은 가중치를 부여하도록 학습합니다. 크게 늘었습니다. 내 모델 따라서 '1stposition=true'인 예의 경우 다른 요인에 더 적은 가중치가 부여됩니다. 서빙 시에는 인스턴스에 위치 특성을 부여하지 않거나 모두 동일하게 기본 기능을 사용할 수 있습니다. 표시할 순서를 정했습니다.

모든 위치 특성을 모델의 나머지 부분을 대체하는 것으로 나타났습니다. 모델이 위치 특성의 함수와 함수가 이상적입니다. 예를 들어 위치 특성을 지정할 수 있습니다.

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

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

  • 학습 데이터와 홀드아웃의 성능 차이 데이터를 수집하는 데 사용됩니다 일반적으로 이는 항상 존재하며 항상 나쁜 것은 아닙니다.
  • 홀드아웃 데이터와 '다음날' 실적의 차이 데이터를 수집하는 데 사용됩니다 마찬가지로 이는 항상 존재합니다. 정규화를 조정하여 다음 날 실적을 최대화할 수 있습니다 하지만 홀드아웃 데이터와 다음날 데이터 간의 차이는 일부 특성이 시간이 민감하고 모델 성능이 저하될 수 있습니다.
  • '다음날'의 실적 차이 라이브 관제실에서 데이터를 수집하는 데 사용됩니다 학습 데이터의 예에 모델을 적용한 다음 정확하게 동일한 결과를 얻어야 합니다 (참고: 규칙 #5 ). 따라서 이 불일치는 엔지니어링 오류를 의미할 수 있습니다.

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

2단계가 마무리되고 있음을 나타내는 구체적인 징후가 있습니다. 우선, 월별 수익이 감소하기 시작합니다. 여러분은 측정항목 간의 장단점: 상승하는 측정항목도 있고 하락하는 측정항목도 있습니다. 실험합니다. 이 지점에서 흥미로운 결과가 발생합니다. 이득을 취하기가 더 어렵기 때문에 머신러닝이 더 정교해져야 합니다. 주의사항: 이전 섹션보다 더 많은 규칙이 있습니다. 많은 팀이 1단계와 2단계 머신러닝의 해피 타임을 살펴보겠습니다 1단계 III에 도달했으므로 각 팀은 자신만의 길을 찾아야 합니다.

규칙 #38: 목표가 맞지 않는 것이 문제라면 새로운 특성에 시간을 낭비하지 말라.

측정값이 정체되면 팀은 다음과 같은 문제를 찾기 시작합니다. 현재 머신러닝 시스템의 목표 범위를 벗어납니다. 따라서 기존 알고리즘이 제품 목표를 충족할 수 없다면 목표 또는 제품 목표를 변경해야 합니다. 대상 예를 들어 클릭수, 플러스원 또는 다운로드를 최적화할 수 있지만 부분적으로는 인간 평가자에 의해 결정될 수 있습니다.

규칙 #39: 출시 결정은 제품의 장기적인 목표를 반영한다.

앨리스는 설치 수 예측의 로지스틱 손실을 줄이는 아이디어를 갖고 있습니다. 그럼퍼스는 는 특성을 추가합니다. 로지스틱 손실이 감소합니다. 실시간 실험을 하면서 설치율이 증가하는 것을 확인할 수 있습니다. 하지만 출시 검토 단계에서는 일일 활성 사용자 수가 5% 감소했다고 지적합니다. 팀은 모델을 출시하지 않기로 결정했습니다. 실망한 앨리스 출시 결정이 여러 기준에 따라 달라진다는 사실을 깨달았습니다. 직접 최적화할 수 있습니다

현실 세계는 던전이나 드래곤이 아니라 포인트" 제품 상태 식별 팀은 시스템이 얼마나 우수한지를 효과적으로 예측하기 위해 수집하는 통계 있습니다. 참여도, 1일 활성 사용자 (DAU), 30일 DAU, 수익, 광고주의 투자수익입니다. 이러한 측정항목은 A/B 테스트에서 측정 가능하다는 점 자체는 장기적인 지표일 뿐입니다 목표: 사용자 만족, 사용자 증가, 파트너 만족, 수익 그럼에도 불구하고 유용한 고품질의 프록시가 5년 후 다시 한 번 활약하는 회사가 될 것입니다.

시작을 위한 단 하나의 쉬운 결정은 모든 측정항목이 개선되거나 적어도 악화되지 않음). 팀이 정교한 머신 중 하나를 선택할 수 있다면 간단한 휴리스틱이 학습 알고리즘과 단순 휴리스틱을 모두 더 나은 결과를 얻기 위해서는 휴리스틱을 선택해야 합니다. 또한 가능한 모든 측정항목 값의 명시적인 순위가 없습니다. 특히 다음 두 가지 시나리오가 있습니다.

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

현재 시스템이 A라면 팀이 B로 전환할 가능성이 낮습니다. 만약 현재 시스템이 B라면 팀은 A로 전환할 가능성이 낮습니다. 이 합리적 행동과 충돌하는 것처럼 보입니다. 2012년 3월 12일에만 측정항목이 진행될 수도 있고 그렇지 않을 수도 있으므로 둘 중 하나입니다. 각 측정항목은 팀에서 우려하는 위험을 수반합니다.

게다가 "내 제품이 어디에 있는가?"라는 팀의 궁극적인 우려를 충족하는 측정항목은 없습니다. 어떻게 될까요?

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

규칙 #40: 앙상블을 단순하게하라.

원시 특성을 가져와서 콘텐츠의 순위를 직접 매기는 통합 모델은 디버깅 및 이해가 가장 쉬운 모델 그러나 모델의 앙상블( '모델' 를 사용하는 것이 더 효과적일 수 있습니다. 각 모델은 입력값만 취하는 앙상블이거나 둘 다 아닌 여러 특성을 갖는 기본 모델일 수 있습니다 만약 별도로 학습된 다른 모델 위에 생성한 후 이를 결합하여 오작동으로 이어질 수 있습니다.

앙상블에는 'base'의 출력만 취하는 간단한 모델을 사용합니다. 모델을 입력으로 사용합니다 또한 이러한 앙상블 모델에 속성을 적용하는 것이 좋습니다. 예를 들어 기본 모델이 생성한 점수가 높아져도 감소시킬 수도 있습니다. 또한 새로 추가되는 모델이 보정된 경우와 같이 의미상으로 해석될 수 있어야 혼동하지 않는다는 것을 의미합니다. 또한 기본 분류기의 예측 확률 증가는 앙상블의 예측 확률을 낮춥니다.

규칙 #41: 실적이 정체되어 있으면 기존 신호를 다듬기보다는 정성적으로 새로운 정보 소스를 찾아 추가해야 한다.

사용자의 인구통계 정보를 추가했습니다. 항목을 추가했습니다. 단어에 대한 정보를 추출할 수 있습니다. 템플릿을 살펴보았습니다. 정규화를 조정했습니다. 지금까지 이는 몇 분기 만에 주요 측정항목이 1% 개선되는 것입니다. 이제 어떻게 해야 할까요?

이제 근본적으로 다른 사용자를 위한 인프라 구축을 시작할 때입니다. 문서 기록과 같은 지난 1일, 1주, 1년 또는 다른 속성의 데이터가 표시됩니다. 사용 위키데이터 법인 또는 귀사 내부의 무언가 (예: Google의 지식 정보 참조). 딥 링크 사용 있습니다. 수익에 대한 기대치를 조정합니다. 그에 따라 노력을 확대하세요 여느 때와 같음 새 특성을 추가할 때의 이점을 저울질해 보고 비용을 절감할 수 있습니다

규칙 #42: 다양성, 개인화 또는 관련성이 인기도와 상관관계가 있을 것이라고 생각하지 말라.

콘텐츠 집합의 다양성은 많은 것을 의미할 수 있습니다. 콘텐츠 소스는 가장 일반적입니다. 맞춤설정의 의미는 결과를 얻을 수 있습니다. 관련성은 특정 검색어에 대한 결과가 검색어에 더 적합할 수 있습니다. 따라서 세 가지 모두 일반적인 것과 다른 것으로 정의됩니다

문제는 평범함을 능가하기 어려운 경향이 있다는 것입니다.

시스템에서 클릭수, 시청 시간, 시청 시간, +1, 재공유 등을 측정한다면 콘텐츠의 인기도를 측정하고 있는 것입니다. 팀 때로는 다양성을 갖춘 개인 모델을 학습하려고 노력하죠. 맞춤설정하기 위해 시스템 맞춤설정에 사용할 수 있는 특성( 다각화 (이 문서에 사용자의 관심사가 있는지 여부를 나타내는 기능) 반환된 다른 문서와 공통된 기능(예: 작성자 또는 콘텐츠) 이러한 특성의 가중치가 줄어들거나 다른 기호 (부호)가 감소하는 것을 훨씬 커질 수 있습니다

그렇다고 해서 다양성, 맞춤화 또는 관련성이 중요하지 않은 것은 아닙니다. 이전 규칙에서 지적한 것처럼 후처리를 수행하여 관련성이 있습니다. 장기 목표가 증가한다면 인기와는 달리 다양성/관련성이 중요하다고 선언하는 콘텐츠 다음을 수행할 수 있습니다. 그런 다음 후처리를 계속 사용하거나 다양성이나 관련성을 토대로 목표를 다르게 설정합니다

규칙 #43: 제품은 달라도 친구는 비슷하나, 관심사는 그렇지 않은 경우가 많습니다.

Google의 팀은 2015년 1분기부터 2010년 10월 18일까지 한 제품의 유대감이 다른 제품과 잘 어우러지는 느낌을 줍니다. 친구는 그 모습 그대로입니다. 한편 나는 여러 팀의 제품 부문 전반에서 개인 맞춤 기능을 제공하는 데 어려움을 겪고 있음 예, 그렇습니다 알 수 있습니다. 현재로서는 그렇지 않은 것 같습니다. 때로는 한 속성의 원시 데이터를 사용하여 다른 속성의 행동을 예측하는 것입니다. 또한 사용자가 다른 사이트를 방문한 적이 있다는 것을 알더라도 도움이 됩니다. 예를 들어 두 제품에서 사용자 활동이 있으면 그 자체로 나타낼 수 있습니다.

머신러닝에 관한 다양한 문서가 Google 및 외부에서 확인할 수 있습니다.

감사의 말씀

David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei에게 감사드립니다. 미찰리스 포타미아스, 에반 로젠, 배리 로젠버그, 크리스틴 롭슨, 제임스 파인 탈 쉐이크, 투샤르 찬드라, 무스타파 이스피르, 예레미야 함센, 콘스탄티노스 캣시피스, 글렌 앤더슨, 댄 덕워스, 시시르 버미왈, 갈 엘리단, 수 린 Wu, Jaihui Liu, Fernando Pereira, Hrishikesh Aradhye의 다양한 교정본 이 문서에 대한 권장사항 및 유용한 예시를 살펴봅니다. 또한 Kristen 덕분에 Lefevre, Suddha Basu, Chris Berg가 초기 버전을 지원했습니다. 모든 문자 오류, 누락, 호의적이지 않은 견해는 저만의 것입니다.

부록

이 문서에서는 Google 제품을 다양하게 참조합니다. 받는사람 더 많은 컨텍스트를 제공하고 가장 일반적인 예시에 대해 간략히 설명합니다. 참조하세요.

YouTube 개요

YouTube는 스트리밍 동영상 서비스입니다. YouTube 다음 볼만한 동영상 및 YouTube 홈 페이지팀은 ML 모델을 사용하여 동영상 추천의 순위를 매깁니다. 다음 볼만한 동영상 추천 홈페이지에서 추천하는 동영상 중 현재 재생 중인 동영상 다음에 시청할 동영상 홈페이지를 탐색하는 사용자에게 동영상을 추천할 수 있습니다

Google Play 개요

Google Play는 다양한 문제를 해결하는 여러 모델을 보유하고 있습니다. Play 검색, Play 홈페이지 맞춤 추천과 '함께 설치한 사용자' 앱 모두 사용 머신러닝으로 나눌 수 있습니다

Google+ 개요

Google Plus는 다양한 상황에서 머신러닝을 사용했습니다. '스트림' '인기 소식'으로 순위를 매긴 게시물의 비율 게시물 (게시물) 아는 사람 순위를 매길 수도 있습니다. Google+ 2019년에 모든 개인 계정을 폐쇄했으며 Google Currents로 대체됨 2020년 7월 6일부터 비즈니스 계정에 적용됩니다.