Rules of Machine Learning: Best Practices for ML Engineering 정리

in Data on Machine-Learning


  • Google의 Research Scientist인 Martin Zinkevich가 작성하신 Rules of Machine Learning: Best Practices for ML Engineering 나름대로 번역하고 정리한 글입니다
  • Machine Learning Guides에 언어를 한국어로 조정하면 번역본이 나오지만, 개인 학습 목적으로 정리했습니다(4부까지만 번역하고 그 이후는 번역하지 않았으니 원본이 궁금하시면 꼭 링크를 참고해주세요)
    • 정리하며 제가 이해한 상태로 정리했고, 추가적으로 제가 아는 내용을 덧붙였습니다

Best Practices for ML Engineering

  • 이 문서는 머신러닝에 대한 기본 지식을 가진 사람들이 Google의 머신러닝 best practice의 장점을 얻을 수 있도록 돕기 위한 문서
  • Google C++ 스타일 가이드처럼 머신러닝 관련한 실용적인 내용을 전달함
  • 머신러닝 모델을 개발하거나 다뤄본 경험이 있다면 이 문서를 읽기 위한 배경 지식을 갖춘 것



Terminology(용어)

  • 반복적으로 사용될 용어 정의
  • Instance : 예측하려는 대상. 웹페이지를 “고양이와 관련”, “고양이와 무관”으로 분류하려는 경우 웹페이지가 인스턴스임
  • Label : 예측 작업에 관한 답으로, 머신러닝 시스템이 도출하거나 학습 데이터에서 제공된 정답
  • Feature : 예측 작업에 사용되는 인스턴스의 속성. ‘웹페이지에 고양이란 단어가 나온 횟수’ 등을 예로 들 수 있음
  • Feature Column : 관련된 feature의 집합. 예를 들어 사용자가 거주할 수 있는 모든 국가의 집합. Feature column은 Google에서만 사용되는 용어고, Yahoo/Microsoft에선 namespace라고 함
  • Example : Instance(Feature 포함) 및 Label
  • Model : 예측 작업의 통계적 표현(statistical representation) example을 사용해 모델을 학습한 후, 그 모델을 사용해 예측함
  • Metric : 관심이 있는 수치. 직접 최적화될 수 있고, 아닐수도 있음
  • Objective : 알고리즘에서 최적화하려는 Metric
  • Pipeline : 머신러닝 알고리즘을 둘러싼 인프라. 프론트엔드는 데이터를 수집하고, Train 데이터 저장, 모델 Train, 모델 Production으로 내보내는 것을 포함함
  • Click-through Rate : 광고에서 링크를 클릭하는 비율



Overview

  • 멋진 제품을 만들기 위해, 머신러닝 전문가 흉내를 내지 말고 훌륭한 엔지니어처럼 머신러닝을 활용해야 함
  • 실제로 직면하는 문제는 대부분 엔지니어링 문제임. 결국 좋은 Feature를 갖는 것이 중요함
  • 기본 접근 방법
    • 1) 파이프라인이 end to end로 견고하게 되어있는지 확인
    • 2) 합리적인 objective로 시작
    • 3) 간단한 방법으로 상식적인 feature 추가
    • 4) 파이프라인이 견고하게 되어있는지 확인
  • 이 접근법은 오래 사용할 수 있고, 혹시 기본 접근 방법으로 더 이상 진행할 수 없는 경우 다른 방식을 찾아야 함
  • 복잡성을 증가시키면 개발은 느려짐
  • 기본 접근 방법으로 부족하면 최첨단 머신러닝 기법을 도전할 때고, 3단계 섹션을 참고하면 됨
  • 이 문서의 구성
    • 1부 : 머신러닝 시스템을 구축하기에 적절한 시점에 대한 이야기
    • 2부 : 첫 파이프라인을 구축하는 방법
    • 3부 : 파이프라인에 새 Feature를 추가하며 계속 출시, 반복하는 과정에 대한 이야기 + 모델 training-serving의 skew를 평가하는 방법
    • 4부 : 개선이 한계에 부딪힌 경우 대처하는 방법
    • 부록 : 자주 사용되는 시스템에 관한 배경 지식

1부. Before Machine Learning

  • Rule #1: 머신러닝 없이 제품을 출시하는 것을 두려워하지 말기
    • 머신러닝은 매우 cool하지만, 데이터가 필요함
    • 다른 문제로 데이터를 가져와서 모델을 살짝 수정해 적용하는 방법은 이론적으론 가능하지만 휴리스틱보다 성능이 떨어질 가능성이 높음
    • 머신러닝의 효과를 100% 기대한다면 휴리스틱을 사용해도 50%의 효과는 볼 수 있음
    • 예 : 앱 마켓플레이스에서 앱 순위를 매길 때 설치율, 설치 횟수를 휴리스틱으로 사용할 수 있음, 스팸을 감지할 때 전에 스팸을 보낸 적이 있는 발신자를 걸러내면 됨. 연락처의 순위를 매길시 최근에 자주 사용한 연락처 순으로 해도 됨
    • 머신러닝이 제품에 정말 필요한 기능이 아니면 데이터를 충분히 수집하기 전엔 사용하지 말기
  • Rule #2: 가장 먼저 측정 항목(Metric)을 설계하고 구현하기
    • 머신러닝 시스템을 구축하기 전에 현재 시스템을 최대한 많이 알고 있어야 함. 그 이유는 다음과 같음
      • 1) 시스템 사용자에게 미리 사용 권한을 받기 쉽다
      • 2) 미래에 발생할 수 있는 문제가 있다면 지금부터 과거 데이터를 수집하는 것이 좋음
      • 3) metric 측정을 염두에 두고 시스템을 설계하면 나중에 편함. 구체적으로 metric을 위해 로그에서 문자열을 모두 grep할 필요가 없이 설계하면 됨
      • 4) 무엇이 바뀌고 무엇이 동일하게 유지되는지 알 수 있음. 예를 들어 1일 활성 사용자 수를 최적화하려고 할 때, 사용자 경험을 크게 바꿔도 metric에 눈에 띄는 변화가 없을 수 있음
    • Google Plus 팀은 read당 exapand 수, read당 reshare 수, read당 plusones 수, 댓글/읽기, 유저당 댓글 수, 유저당 재공유 횟수 등을 측정해 게시물의 품질을 계산할 때 사용함. 그리고 사용자를 그룹화해 실험할 수 있는 실험 프레임워크를 갖추는 것이 중요함. Rule #12 참고
    • Metric을 적극적으로 모니터링할수록 시스템을 전반적으로 파악하기 쉬워짐. 문제를 찾았다면 metric에 추가해 모니터링. 최근 릴리즈에 만족할만한 정량적 변화가 있었다면 metric에 추가하자
  • Rule #3: 휴리스틱이 복잡하면 머신러닝을 선택하기
    • 단순한 휴리스틱만 갖춰도 제품을 출시할 수 있음
    • 휴리스틱이 복잡하면 유지보수가 불가능
    • 데이터가 확보되고 달성하려는 목표가 확실해지면 머신러닝으로 진행할 수 있음
    • 소프트웨어 엔지니어링 작업에서 휴리스틱/머신러닝 모델인지 상관없이 계속 업데이트가 필요함
    • 머신러닝 모델이 휴리스틱보다 업데이트 및 유지보수가 쉬움. Rule 16 참고



2부. ML 1단계: Your First Pipeline

  • 첫 파이프라인에선 시스템 인프라에 집중하기
  • 머신러닝의 가능성에 대해 상상하는 것도 재미있지만, 파이프라인을 먼저 믿지 않으면 어떤 일이 일어나는지 파악하기 어려움(=파이프라인이 확실해야 현재 상황을 제대로 파악할 수 있음)
  • Rule #4: 최초 모델은 단순하게 가져가고 인프라를 제대로 만들기
    • 첫 모델은 제품 개선에 가장 크게 기여하기 때문에 처음부터 화려한 기능을 갖추지 않아도 됨
    • 그러나 인프라가 예상보다 더 문제를 겪을 수 있음
    • Facny한 새 머신러닝 시스템을 사용하기 전에 다음과 같은 내용을 결정해야 함
      • 학습 알고리즘에 example을 제공할 방법
      • 시스템의 good과 bad를 판단할 기준
      • 모델을 Application에 통합할 방법. 모델을 실시간으로 적용할 수 있고, 미리 예측해 결과를 Table에 저장할 수 있음. 예를 들어 웹페이지는 미리 분류해 테이블에 결과를 저장하고, 채팅 메세지는 실시간으로 분류할 수 있음

      (역자) : 실시간으로 적용하는 경우엔 Flask, TF Serving 등을 사용해 API로 제공하는 방식이 있고, 배치성으로(1시간에 1번) 진행할 경우엔 Database에 저장하는 방식이 있음

    • 단순한 Feature를 선택하면 다음 작업을 쉽게 진행할 수 있음
      • Feature가 학습 알고리즘에 정확히 도달함
      • 모델이 합리적인 weight를 학습함
      • Feature가 서버의 모델에 정확히 도달함
    • 이런 3가지 과제를 안정적으로 달성할 시스템을 만들었으면, 대부분의 일을 한 것임
    • 이제 단순한 모델에서 baseline metric과 baseline behavior를 얻어 더 복잡한 모델을 테스트할 때 활용할 수 있음
    • (구글의) 어떤 팀에선 “중립적”인 최초 런칭을 목표로 하는데, 이는 머신러닝으로 얻을 당장의 이익에 집착하지 않고 본질의 목표에 집중하기 위함임
  • Rule #5: 머신러닝과 별도로 인프라 테스트하기
    • 인프라틑 테스트할 수 있어야하고, 시스템의 train 부분은 캡슐화해야 모든 관련 부분을 테스트할 수 있음. 특히 다음과 같은 작업이 필요함
      • 1) 알고리즘에 데이터를 넣는 기능 테스트
        • 생성되야 하는 Feature가 잘 채워졌는지 확인
        • 개인정보 보호하는 범위 내에서 input 값을 직접 조사
        • 가능하면 파이프라인의 통계를 다른 곳에서(로컬 등) 데이터 처리해 나온 통계와 비교
      • 2) 모델을 알고리즘에서 추출하는 기능 테스트
        • Train 환경의 모델이 주는 점수와 Serving 환경의 모델과 동일한지 확인. Rule 37 참조
    • 머신러닝엔 예측 불가능성이 있어서, Train 및 Serving시 Example을 생성하는 코드를 테스트할 준비하고, Serving 중 고정된 모델을 로드해 사용할 수 있는지 확인해야 함
    • 또한 데이터를 이해하는 것이 중요함. Practical advice for analysis of large, complex data sets 참고
  • Rule #6: 파이프라인을 복사할 땐 데이터 누락 주의하기
    • 기존 파이프라인을 복사해 새로운 파이프라인을 만들었는데, 새 파이프라인에 필요한 데이터가 기존 파이프라인에 누락되는 경우가 종종 있음
    • 예를 들어 Google+ HOT 소식의 파이프라인은 최신 게시물의 순위를 매기는 것이 목적이라 과거 게시물들이 유의미한데, 복사해온 파이프라인에서 과거 게시물들을 누락시킴
      • 이 파이프라인을 Google+ 스트림에 사용하기 위해 복사했더니 이 기능에선 과거 게시물들이 누락됨
      • 사용자가 트정 게시물을 조회하지 않은 이유를 모델링할 경우 negative example이 모두 누락되므로 결국 쓸모없는 데이터가 됨
      • Play에도 비슷한 문제가 있었음. Play 앱 홈 화면을 만들며 Play 게임 방문 페이지의 Example을 포함한 파이프라인을 새로 만들었는데, 각 example의 출처를 구분짓지 않았음
  • Rule #7: 휴리스틱을 Feature로 변환하거나 외부에서 처리하기
    • 머신러닝으로 해결하려는 문제들은 보통 새로 등장한 Problem은 아님. 순위 결정, 분류 등 어떤 문제든 과거에 사용하던 기존 시스템이 있음
    • 따라서 수많은 규칙(Rule base), 휴리스틱이 이미 존재함
    • 휴리스틱 + 머신러닝의 조합
    • 기존 휴리스틱을 철저히 분석해야 함. 첫번째로 머신러닝 시스템으로 전환이 더 원활해짐. 둘째로 이런 규칙은 시스템에 대한 직관을 풍부하게 담고 있음. 다음 4가지 방법으로 휴리스틱을 사용할 수 있음
      • 1) 휴리스틱을 사용해 전처리
        • 믿을 수 없을만큼 awesome한 feature인 경우 고려할 수 있음
        • 예를 들어 스팸 필터에서 보낸 사람이 이미 차단 목록에 들어있으면 차단 목록을 다시 학습할 필요없음. 단순히 메세지를 차단하면 됨
      • 2) Feature 생성
        • 휴리스틱에서 직접 Feature 생성
        • 예를 들어 휴리스틱을 사용해 쿼리 결과의 유사도 점수를 계산할 경우 이 점수를 Feature로 넣을 수 있음
        • 이후에 머신러닝 기법을 사용해 값을 조정할 수 있지만 처음엔 휴리스틱에서 나오는 값을 그대로 사용해도 됨
      • 3) 휴리스틱의 input을 Feature로 사용
        • 앱의 설치 횟수, 텍스트 문자 수, 요일을 결합하는 휴리스틱이 있다면 이런 값을 학습에 제공하는 것이 좋음. 이 때 앙상블에 적용되는 기법이 일부 적용됨. Rule 40 참조
      • 4) Label을 수정
        • 휴리스틱이 현재 Label에 포함되지 않는 정보를 포착하면 이 방법을 사용할 수 있음
        • 예를 들어 다운로드 횟수를 극대화하며 컨텐츠 품질에도 중점을 두려면 앱이 받은 평균 별점 수로 label을 곱하는 것이 답일 수 있음. 정해진 방식은 없음. 첫 목표 참고
    • ML 시스템에서 휴리스틱을 사용하는 경우 복잡도가 추가되는 것을 주의해야 함. 새로운 머신러닝 알고리즘에 기존 휴리스틱을 사용하면 전환이 원활할 수 있지만, 더 간단한 방법으로 같은 효과를 낼 수 없는지 고민해보면 좋음



모니터링

  • 일반적으로 알림에 실제 정보를 추가하고 모니터링할 수 있는 대시보드 페이지를 마련하곤 함
  • Rule #8: 시스템의 갱신(freshness) 요구사항을 파악하기
    • 모델이 하루, 1주일, 1분기 뒤에 성능이 얼마나 떨어지는지?
    • 이 정보는 모니터링의 우선순위를 판단할 때 도움이 됨
    • 하루동안 모델을 업데이트하지 않았더니 제품의 품질이 떨어지는 경우 모델을 지속적으로 모니터링하는 엔지니어를 두는 것이 좋음
    • 광고 시스템같이 매일 새로운 광고가 유입되는 경우 업데이트가 매일 진행되야 함
    • 예를 들어 Google Play 검색의 모델이 업데이트되지 않으면 1개월 이내에 부정적인 영향을 미침
    • Google+의 HOT 소식에서 게시물 id를 갖지 않는 일부 모델은 자주 내보낼 필요가 없고, 게시물 id를 갖는 모델은 자주 업데이트됨
    • 갱신 기준은 시간에 따라 변화할 수 있음(특히 모델에서 feature column이 추가되거나 삭제될 경우)
  • Rule #9: 모델을 내보내기 전에 문제를 탐지하기
    • 많은 머신러닝 시스템엔 모델을 서빙 환경으로 내보내는 단계가 있음. 내보낸 모델에 문제가 있는 경우 유저가 바로 알아차림
    • 모델을 내보내기 전에 sanity check(품질 검사)를 해야 함
    • 홀드아웃 데이터에 대해 모델의 성능이 적절한지 확인해야 함
    • 또는 데이터의 신빙성이 의심되면 모델을 내보내지 말아야 함
    • 계속 모델을 내보내는 팀은 대부분 AUC를 확인한 후 내보냄
    • 모델을 제때 내보내지 못하는 것은 이메일 알림으로 해결할 수 있지만, 문제 있는 모델을 제공하면 사태가 커짐
    • 따라서 유저에게 영향을 미치는 것보다 늦는게 나을 수 있음
  • Rule #10: 조용한 실패(silent failures)에 주의하기
    • 개발 시스템보다 머신러닝 시스템에서 자주 나타나는 문제
    • Join 대상이 되는 특정 테이블이 더 이상 업데이트되지 않는 경우, 이 테이블 기반으로 머신러닝 시스템을 구축하면 겉보기엔 특별한 문제가 없어도 실제론 성능이 점점 떨어짐
      • 몇 달 동안 그대로였던 테이블을 갱신하는 것으로 놀라운 성능 개선 효과를 거둘 수 있음
    • 구현 변경으로 Feature의 포함 범위가 바뀌기도 함
      • Feature column이 90%에서 60%로 급락할 수 있음
    • 데이터의 통계를 모니터링하면 이런 유형의 실패를 줄일 수 있음
  • Rule #11: Feature column에 소유자를 지정하고 문서화하기
    • 시스템의 규모가 크고 Feature column이 많은 경우 각 컬럼을 누가 만들었고, 관리하는지 알아야 함
    • 담당자가 조직을 떠날 경우 철저한 인수인계가 이루어져야 함
    • 이름만 봐도 의미를 알 수 있는 Feature column도 많지만, 특성의 의미, 출처, 유용성을 자세히 기록해두는 습관을 들이는 것이 좋음



첫 목표(Objective)

  • 시스템에서 중요한 metric이 아무리 많아도 머신러닝 알고리즘에 필요한 목표(objective), 알고리점에서 최적화할 수치는 일반적으로 단 하나
  • Objective와 Metric을 잘 구분해야 함
  • Metric은 시스템에서 보고하는 다양한 숫자들로 중요할 수도, 중요하지 않을 수도 있음. Rule #2 참조
  • Rule #12: 어떤 objective를 직접 최적화할지 너무 고민하지 말기
    • 당신은 돈을 벌거나, 유저를 행복하게 만들거나, 세상을 더 좋게 만드는데 기여하는 것을 원할것임
    • 중요하게 생각할 metric은 무수히 많고, 이것들을 모두 측정해야 함
    • 그러나 머신러닝 초기엔 모든 metric이 증가하는 것을 알 수 있음
      • 예를 들어 클릭수 및 사용 시간이 중요하다고 가정한 경우, 클릭수를 최적화하면 사용 시간도 증가할 가능성이 높음
    • 모든 metric이 쉽게 증가할 수 있으므로, 다양한 metric 간 균형을 맞추려고 고민하지 말고 단순하게 생각하면 됨
    • 하지만 이 규칙에도 한계가 있음. objetive와 시스템의 절대적 안전성을 혼돈해선 안됨(Rule 39 참조)
    • 또한 직접 최적화하는 metric은 개선되지만 결국 출시에 실패하는 상황이 반복되면 objective를 수정해야 할 수 있음
  • Rule #13: 단순하고 관찰 가능하고 추적 가능한 metric을 첫 목표로 선택하기
    • 궁극적인 목표를 미리 알지 못하는 경우도 많음
    • 목표를 일단 정하고, 기존 시스템과 새로운 머신러닝 시스템 데이터를 나란히 분석하면 목표를 수정하고 싶어짐
    • 궁극적인 목표에 대해 팀원들의 의견이 다를 수 있음
    • ML Objective는 측정하기 쉬우면서 진정한 목표를 반영해야 함
    • 단순한 ML 목표를 기준으로 학습하되, 다른 로직(이왕이면 단순한)을 추가해 최종 순위를 결정할 수 있도록 “policy layer”를 상단에 두는 것이 좋음
    • 가장 모델링하기 쉬운 대상은 직접 관찰되고 시스템 동작과 인과성을 추적할 수 있는 사용자 행동
      • Ranked list가 클릭되었는가?
      • Ranked object가 다운되었는가?
      • Ranked object가 전달, 회신, 이메일로 발성되었는가?
      • Ranked object가 평가되었는가?
      • 보이는 object가 스팸/음란물/불쾌감을 주는 컨텐츠로 신고되었는가?
    • 간접 효과는 처음에 모델링하지 말기
      • 사용자가 다음 날 방문했는가?
      • 사용자가 사이트를 얼마나 오래 방문했는가?
      • 일일 활성 사용자 수는 몇인가?
    • 간접 효과도 좋은 metric으로 AB Test 및 출시 결정에 활용될 수 있음
    • 다음과 같은 의문을 해결할 때 머신러닝을 사용하지 말기
      • 사용자가 제품을 만족하고 있는가?
      • 사용자 경험이 만족스러운가?
      • 제품이 사용자의 전반적인 삶의 질을 높여주는가?
      • 회사의 전반적인 건강함에 어떤 영향을 주는가?
    • 모두 중요하지만 측정하기가 매우 어려움. 간접적인 기준으로 대신하자
    • 사용자가 만족감을 느낀다면 사이트에 더 오래 머무르고, 다음 날 다시 방문할 것임
    • 삶의 질이나 회사의 건강함과 관련되는 부분은 사람의 판단이 필수적
  • Rule #14: 해석 가능한 모델부터 시작하면 디버깅이 쉬움
    • 선형 회귀, 로지스틱 회귀, 푸아송 회귀는 확률론 모델에서 나온 것들임
    • 각 예측은 확률 또는 기대값으로 해석할 수 있음
    • 예를 들어 Train 시스템의 확률이 병렬로 운영되거나 별도로 조사된 프러덕션 시스템의 확률과 차이가 나면 이를 통해 문제가 드러날 수 있음
    • 단순 모델에선 feedback loop를 다루는 방법이 더 쉬움(Rule #36 참조) 이런 확률 예측을 근거로 결정내리는 경우가 많음
    • 클릭 확률, 다운로드 확률 등의 기대값에 따라 내림차순으로 게시물의 순위를 매길 수 있음
    • 그러나 어떤 모델을 사용할지 선택할 땐 모델에 제공된 데이터의 확률보다 Decision이 더 중요함(Rule #26 참조)
  • Rule #15: Policy Layer에 스팸 필터링과 Quality Ranking을 분리하자
    • Quality Ranking이 예술이라면 스팸 필터링은 전쟁임
    • 사용자들은 게시물의 품질을 판단하는데 사용하는 지표를 금방 알아차리고 게시물을 적당히 손질해 이런 속성을 갖게 만듬(인스타그램 생각하면 쉬울듯)
    • 따라서 Quality Ranking에선 정상적인 의도로 게시된 컨텐츠의 순위를 매기는 데 집중해야 함
    • 스팸의 순위를 높게 매겼다고 해서 Quality Ranking 학습 시스템을 평가절하해선 안됨
    • 선정적인 컨텐츠도 마찬가지 이유로 Quality Ranking과 별도로 처리해야 함
    • 때론 시스템에 규칙을 도입하기도 함 : 스팸 신고가 3회 초과하면 게시물은 제외한다
    • 학습 모델은 최소 하루 1번 이상 업데이트되야 하고, 컨텐츠 작성자의 평판도 큰 역할을 함
    • 이런 두 시스템의 출력을 일정 수준에서 통홥해야 함
    • 주의 : 검색 결과의 스팸 필터링은 이메일보다 더 공격적이어야 함
      • 정규화를 사용하지 않고 알고리즘이 수렴한다는 전제 하에 이 사실은 참임
    • 스팸은 품질 분류용 학습 데이터에서 제외하는 것이 일반적인 관행임



3부. ML 2단계: Feature Engineering

  • 머신러닝 시스템 lifecycle의 첫 단계에서 중요한 이슈는 Train 시스템에 데이터를 공급하고, 의미있는 metric을 측정하고 서빙 인프라를 구축하는 것
  • unit test와 system test를 갖춘 정상적인 end to end 시스템을 구축했다면 2단계로 넘어가자
  • 2단계는 다양하고 알기 쉬운 Feature를 시스템에 넣으면 됨
    • 머신러닝 2단계에서선 최대한 많은 Feature를 직관적인 방식으로 넣는 것에 관심을 가짐
    • 이 단계는 모든 metric이 상승세를 보여야 함
    • 출시를 반복하며 필요한 데이터를 모두 모아 train 시스템의 성능을 극대화해야 함
  • Rule #16: 출시와 반복을 계획하기
    • 지금 작업 중인 모델이 마지막 출시 버전이 될 것이라거나, 반복적인 모델 출시가 언젠가 끝날거라는 기대는 버리면 좋음
    • 이번 출시에서 추가되는 복잡성으로 인해 이후 출시가 늦춰질 가능성이 있는지 고려해야 함
    • 많은 팀에서 지금까지 분기당 1회 이상 출시를 진행함
    • 새 모델을 출시하는 기본적인 3가지 이유
      • 새로운 Feature 도입
      • 정규화 조정 및 이전 Feature를 새로운 방식으로 결합
      • objective 조정
    • 모델에 관심을 기울이면 좋은 결과가 나올 수 있음. Example에 공급되는 데이터를 조사해 새로운 지표 또는 잘못된 기존 지표를 찾을 수 있음
    • 모델을 만들며 Feature 추가, 삭제, 재결합이 쉬어야 함
    • 파이프라인의 사본을 만들고 정확성을 검증하기가 쉬울까?
    • 둘 이상의 사본을 동시에 실행하는 방법은 어떻게 할까?
    • 특정 Feature가 이번 파이프라인 버전에 포함될지 고민하지 말기. 다음 출시에 포함해도 됨
  • Rule #17: 학습된(learned) feature이 아닌 직접 관찰하고 보고된 feature부터 시작하기
    • 논란의 여지가 있는 주장이지만, 많은 함정을 피할 수 있음
    • 우선 학습된 feature는 외부 시스템(예 : 비지도 클러스터링 시스템) 또는 학습 시스템 자체(예 : Factored model이나 딥러닝)에서 생성된 Feature
      • 이런 Feature가 유용할 수 있지만 여러 문제점을 가질 수 있으므로 최초 모델에는 포함해서 안됨
    • 외부 시스템을 사용해 Feature를 만드는 경우 외부 시스템엔 그 시스템의 목표가 있다는 것을 기억해야 함
      • 그 외부 시스템의 목표와 나의 현재 목표와 상관이 낮을 수 있음
    • 외부 시스템에서 스냅샷을 가져오는 경우 최신 데이터가 아닐 수 있음
    • 외부 시스템의 특성을 업데이트하는 경우 의미가 변질될 수 있음
    • 따라서 외부 시스템을 사용해 Feature를 제공하는 방식을 사용하려면 매우 신중한 접근법이 필요함

    역자 : 날씨나 공공 데이터 API를 받아서 학습하는 경우, 데이터 제공측에서 바꾸면.. 파이프라인이 망가지는데 그 예시와 비슷한 느낌

    • Factored model과 딥러닝 모델은 nonconvex(볼록하지 않다)는 성질이 있음
      • 따라서 최적 해를 구하거나 근사할 수 있단 보장이 없고, 반복할 때마다 다른 local minima가 발견될 수 있음
      • 이런 variation이 시스템 변경에 따르는 영향인지 무작위적인지 판단하기 어렵게 만듬
    • deep feature 없이 모델을 만들면 탁월한 baseline 성능을 얻을 수 있고, 이 기준이 확보된 이후 특이하고 복잡한 접근법을 시도하면 좋음
  • Rule #18: 여러 Context로 일반화되는 컨텐츠의 feature 찾기
    • 머신러닝 시스템은 더 거대한 시스템의 일부인 경우가 많음
    • 예를 들어 HOT 소식에 올라갈만한 게시물은 HOT 소식에 올라가기 전에 많은 사람의 +1, 재공유, 댓글을 받음
      • 학습 시스템에 이런 통계를 제공하면 최적화 컨텍스트와 관련해 어떤 데이터도 갖지 않는 새로운 게시물이 추천될 수 있음
      • 유튜브의 다음 볼만한 동영상 기능에는 시청 횟수, 연계 시청 횟수를 사용할 수 있음
      • 또한 명시적인 사용자 평가를 사용할 수도 있음
    • 마지막으로 label로 사용 중인 사용자 행동이 있다면 다른 컨텍스트의 자료에 대해 같은 행동을 파악해 좋은 feature를 생성할 수 있음
    • 이런 모든 feature가 새로운 컨텐츠를 가져오도록 기여함
    • 단, 개인화는 여기에 포함되지 않음. 이 컨텍스트에서 컨텐츠를 좋아하는 사람이 있는지 알아낸 후 누가 컨텐츠를 좋아하거나 싫어하는지 알아내는 방식으로 진행함
  • Rule #19: 가능하면 매우 구체적인 Feature를 사용하기
    • 소수의 복잡한 feature보다 다수의 단순한 feature를 학습하는 것이 더 간편함
    • 검색 대상 문서의 id 및 규격화된 쿼리는 일반화에 크게 기여하지 못하지만, head query에서 순위와 label을 맞춰주는 역할을 함
    • 따라서 feature 그룹에서 각 feature가 데이터의 매우 작은 부분에만 적용되더라도 전체 coverage가 90% 넘으면 걱정할 필요가 없음
    • 정규화를 사용하면 작은 example에 적용되는 feature를 배제할 수 있음
  • Rule #20: 사람이 이해할 수 있는 방식으로 기존 feature를 결합하고 수정해 새로운 feature를 만들자
    • feature를 결합하고 수정하는 방법은 다양함. Tensorflow에선 Transformation을 이용해 데이터 전처리하는 방법을 제공함
    • 가장 표준적인 방식은 이산화(discretization)와 교차(cross)임
    • Discretization : continuous feature를 불연속 feature로 만드는 것. 나이를 10세, 15세 보지 않고 10대, 20대 등으로 하는 것. 히스토그램의 경계를 너무 고민하지 않고 기본적인 분위 사용해도 효과를 얻을 수 있음
    • Cross : 둘 이상의 feature column을 결합. {남성, 여성} x {미국, 캐나다, 멕시코}의 특성으로 구성된 새로운 feature
      • 매우 큰 feature column을 생성하는 교차는 오버피팅을 초래할 수 있음
      • 예를 들어 검색 기능을 만들며 검색어 단어를 포함하는 feature와 문서의 단어를 포함하는 feature를 준비할 수 있음. 이걸 교차하면 매우 많음 feature가 생김(Rule #21 참고)
    • Text를 다룰 때 두가지 대안이 있음
      • 가장 엄격한 방법은 내적을 구함
      • 가장 단순한 내적은 검색어와 문서가 공통적으로 갖는 단어의 수를 세는 것
        • 그 후 이 feature를 불연속화
      • 내적을 구하는 다른 방식은 교집합을 구하는 것
  • Rule #21: 선형 모델에서 학습 가능한 feature weight의 수는 데이터 보유량에 대략적으로 비례함
    • 모델의 적절한 복잡도에 관한 훌륭한 통계 이론은 많지만, 지금은 이 규칙만 명심하면 됨
    • Example이 1,000개에 불과한데 학습할 수 있는지 의심하는 사람들도 있고, 예시가 100만개 정도 있으면 특정 학습 방식에 고착되므로 그 이상 필요 없다고 생각하는 사람도 있음. 비결은 데이터 사이즈에 학습 규모를 맞추는 것
      • 1) 검색 랭킹 시스템에서 문서와 쿼리에 수백만가지 단어가 있는데 라벨이 있는 example은 1000개뿐이라면 문서 특성과 쿼리 특성의 내적, TFIDF 및 인위적으로 추출된 feature를 사용해야 함. 1000개의 example에 대략 10개 정도의 feature가 생김
      • 2) example이 100만개라면 정규화 및 feature selection을 사용해 문서와 쿼리의 교집함을 구함. 이를 통해 수백만 개의 feature가 나오지만 정규화를 통해 feature가 감소함. 1,000만개의 example에서 대략 10만개 정도의 feature가 생김
      • 3) example이 수십억 또는 수천억 개라면 feature selection과 정규화를 사용해 feature column을 문서 및 쿼리 토큰을 cross할 수 있음. 10억 개의 example에 1,000만개의 feature가 생김
    • 마지막에는 Rule #28에 따라 사용할 feature를 결정함
  • Rule #22: 더 이상 사용되지 않는 feature를 정리하기
    • 사용하지 않는 feature는 기술 부채가 됨
      • 더 이상 사용되지 않고 다른 feature와 결합해도 유용하지 않다면 인프라에서 삭제하자
      • 인프라를 깔끔하게 유지해야 가장 유망한 feature를 가장 빠르게 시험해볼 수 있음. feature가 다시 필요해지면 언제든지 다시 추가할 수 있음
    • 추가하거나 유지할 feature를 결정할 땐 coverage를 고려하자. Feature가 얼마나 많은 example을 포괄하는지? 예를 들어 개인별 맞춤 feature가 있는데 사용자 중 이 feature를 사용하는 비율이 8%에 불과하면 높은 효율을 기대할 수 없음
    • 어떤 Feature는 생각보다 큰 역할을 하기도 함. 예를 들어 데이터 중 1%만 포괄하는 feature가 있는데, 이 feature를 갖는 example 중 90%가 양성이라면 꼭 추가해야할 feature임



인간에 의한 시스템 분석

  • 머신러닝의 세 번째 단계로 넘어가기 전에, 어떤 머신러닝 강의에서도 다뤄지지 않는 주제를 짚고 넘어가려고 함
  • 바로 기준 모델을 어떻게 바라보고 개선할지에 관한 것
  • 이것은 과학이라기보단 예술에 가깝지만, 바람직하지 않은 몇 가지 패턴을 피할 때 도움이 됨
  • Rule #23: 당신은 전형적인 최종 유저가 아니다
    • 팀이 궁지에 몰리는 가장 쉬운 방법
    • fishfood(팀 내에서 프로토타입 사용) 및 dogfood(회사 내에서 프로토타입 사용)에는 많은 장점이 있지만, 직원들이 성능의 정확성에 대해 잘 살펴야 함
    • 단점이 분명한 변경사항을 피하는 것도 중요하지만, 프러덕션 단계가 안정적이라고 판단할 요소를 철저히 테스트하는 것이 중요함
    • 크라우드소싱 플랫폼에서 일반인을 대상으로 유료 설문조사를 진행하거나 실제 사용자를 대상으로 실험하는 방법이 있음
    • 이렇게 하는 이유
      • 1) 개발자는 코드부터 신경을 쓰기 마련. 특정 측면에만 주목하거나 지나치게 감정이 개입되어 확증 편향이 휩쓸릴 수 있음
      • 2) 개발자의 시간은 소중합니다. 엔지니어 9명이 1시간 동안 회의하는데 사용되는 비용과 크라우드소싱 플랫폼에서 유료 설문조사를 진행해 얻을 수 있는 라벨 수를 비교해보자
    • 사용자 의견이 꼭 필요하다면, 사용자 경험 방법론(uesr experience methodologies)을 사용해보자. 프로세스 초기에 사용자 페르소나를 만들고 이후에 사용성 테스트를 진행하자
      • 사용자 페르소나는 가상적인 사용자를 의미함. 예를 들어 팀원이 모두 남성이면 35세 여성 사용자 페르소나를 만들어보자. 또한 사용성 테스트를 진행해 실제 사용자 반응을 조사하면 새로운 관점을 접할 수 있음
  • Rule #24: 모델 사이의 delta를 측정하자
    • 유저가 새 모델을 접하기 전에 측정할 수 있는 가장 쉽고 유용한 항목으로 새로운 모델이 프러덕션의 기존 결과와 얼마나 다른지 계산하는 것을 뜻함
    • 예를 들어 ranking 문제에서 동일한 쿼리 샘플을 두 모델에 실행한 후 결과의 symmetric 차이 크기에 순위별 가중치를 적용해 살펴볼 수 있음
      • 차이가 매우 작다면 별도의 실험을 거치지 않아도 변화가 거의 없을 것을 짐작할 수 있음
      • 차이가 매우 크다면 긍정적인 변화임을 확신할 수 있음
    • symmetric 차가 크게 나온 쿼리를 살펴보면 변화의 본질적인 측면을 이해할 때 도움이 됨
    • 그러나 중요한 것은 시스템의 안정성임. 모델 자체를 비교할 때(이상적으로 0) 대칭 차이가 낮은지 확인하자
  • Rule #25: 모델을 선택할 땐 예측 파워보다 실용적인 성능을 우선시하자
    • 모델에서 클릭률을 예측하려고 한다. 그러나 결국 중요한 질문은 그 예측으로 무엇을 할지?임
      • 문서의 순위를 결정할 때 활용할 생각이라면 예측 자체보다 최종적인 순위의 품질이 더 중요함
      • 문서가 스팸일 확률을 예측해 차단 기중늘 정할 계획이라면 허용할 대상의 정확성이 가장 중요함
    • 대부분 이런 두 관점의 조화를 이루지만, 그렇지 않다면 소탐대실의 상황이 될 수 있음
    • 따라서 어떤 변화가 log loss는 개선하지만 시스템의 성능을 떨어트린다면 다른 feature를 사용해야 함. 이런 상황이 자주 나타나기 시작하면 모델의 objective를 재검토해야 함
  • Rule #26: 측정된 오차에서 패턴을 찾아 새 feature 만들기
    • 모델에서 잘못 예측한 training example을 발견했다고 가정
      • 분류 작업의 경우 false positive나 false negative가 여기에 해당함
      • Ranking task에선 positive와 negative로 이루어진 쌍에서 positive가 negative보다 순위가 낮게 매겨진 경우일 수 있음
      • 중요한 점은 해당 예시는 머신러닝 시스템에서 예측이 잘못된 것을 스스로 알고 있으므로 기회가 있으면 수정이 가능하다는 점
      • 오류를 수정할 수 있는 feature를 모델에 제공하면 모델은 이 feature를 사용하려고 함
    • 반면 시스템에서 실수를 깨닫지 못한 example을 사용한 feature는 무시됨
      • 예를 들어 Play 앱 검색에서 사용자가 무료 게임을 검색했는데 최상위 결과 중 하나에 관련성이 떨어지는 개그 앱이 포함되었음. 따라서 개그 앱에 관한 특성을 만들었음
      • 설치 횟수를 극대화하는 것이 목표인 경우 무료 게임을 검색하는 사용자들이 개그 앱을 많이 설치한다면 개그 앱 feature는 의도한 효과를 낼 수 없음
    • 모델에서 잘못 예측한 example을 확보했으면 현재 feature set을 벗어나는 추세를 찾자
      • 예를 들어 시스템에서 긴 게시물의 순위를 낮추는 경향이 발견되면 게시물 길이를 추가하자. 추가할 feature를 너무 구체적으로 고민하지 말자. 단순히 10개의 feature를 추가한 후 모델이 알아서 판단하도록 놔두자(Rule 21 참조) 이 방식이 원하는 효과를 얻는 가장 쉬운 방법임
  • Rule #27: 부적절한 동작이 관찰되면 정량화를 시도하자
    • 시스템에 바람직하지 않은 속성이 있는데 기존 loss 함수로는 포착되지 않아서 이슈가 되는 경우가 있음
    • 이러한 경우 무슨 수를 써서라도 불만족스러운 포인트를 구체적인 숫자로 바꿔야함
      • 예를 들어 Play 검색에 ‘개그 앱’이 너무 많이 표시된다고 생각되면 평가 전문가에게 개그 앱을 판별하도록 의뢰할 수 있음
      • 이 경우 사람이 라벨링한 데이터를 사용해도 무리가 없음
    • 이렇게 측정 가능한 문제라면 이제 feature, objective, metric으로 사용할 수 있음
    • 일반적인 규칙은 우선 측정하고 최적화
  • Rule #28: 단기적인 동작이 같더라도 장기적인 동작은 다를 수 있음
    • 모든 doc_id와 exact_query를 조사해 모든 문서, 모든 쿼리에 관한 클릭 확률을 계산하는 시스템을 새로 구축했다고 가정
    • 현재 시스템보다 단순하고 AB 테스트 결과가 현재 시스템과 거의 일치하는 것으로 나타나서 출시를 결정함
    • 그런데 새 앱이 표시되지 않는 문제를 발견
      • 왜 그럴까?
      • 이 시스템은 자체 기록을 기반으로 해당 쿼리에 관한 문서만을 보여주므로 새 문서를 표시해야 한다는 사실을 학습할 방법이 없음
      • 이런 시스템이 장기적으로 어떻게 작동할지 알아내는 유일한 방법은 모델이 실제로 운영될 때 획득한 데이터로만 학습하는 것인데, 이는 매우 어려운 일임



Training-Serving Skew

  • Training-Serving Skew란 Train 성능과 Serving 성능 간의 차이
  • 차이가 나타나는 이유
    • Train 파이프라인과 Serving 파이프라인에서 데이터를 처리하는 방법의 차이
    • 학습시 데이터와 제공 시 데이터 간의 변화
    • 모델과 알고리즘 간의 피드백 루프
  • Google의 프로덕션 머신러닝 시스템에도 Training-Serving Skew로 인해 성능이 저하된 경우가 있었음
  • 가장 좋은 해법은 시스템과 데이터의 변화로 인해 예기치 않은 격차가 생기지 않도록 직접 모니터링하는 것
  • Rule #29: Training 환경을 Serving 환경과 일치시키는 최고의 방법은 Serving할 때 사용된 feature set을 저장하고 그 데이터를 기반으로 Training시 사용하는 것
    • 모든 example에 대해서 불가능하다면 일부 example에 대해서라도 실천하여 서빙과 학습의 일관성을 검증할 방법을 강구해야 함(Rule #37 참조)

    역자 : Serving은 보통 실시간 데이터로 적재가 되고 Training 셋은 ETL 파이프라인으로 실시간 데이터가 아닐 수 있음. 이럴 경우 Serving용 실시간 데이터를 바로 적재해 한번에 쓰자는 이야기

    • Google의 여러 팀에서 이런 측정을 통해 의외의 결과를 얻은 적 있음
    • YouTube 홈페이지는 Serving시 특성 로그 기록을 도입하여 품질을 크게 높이고 코드의 복잡성을 낮추었으며, 지금 이 순간에도 여러 팀에서 인프라를 전환하고 있음
  • Rule #30: 표본 추출된 데이터를 임의로 무시하지 말고 중요도에 따라 가중치를 매기기
    • 데이터가 너무 많으면 파일 1~12만 사용하고, 나머지 파일 13~99는 무시하고 싶을 수도 있음
    • 하지만 잘못된 생각
    • 사용자에게 한 번도 표시되지 않은 데이터는 삭제해도 무방하지만, 나머지 데이터에는 중요도 가중치를 적용하는 것이 가장 좋음
    • 중요도 가중치(importance weight)란 예시 X를 샘플링할 확률이 30%라면 10/3의 가중치를 준다는 의미
    • 중요도 가중치를 사용하는 경우에도 규칙 #14에서 설명한 calibration 속성이 모두 적용됨
  • Rule #31: Training 및 Serving시 (DB) 테이블 데이터를 조인하는 경우 테이블 데이터는 달라질 수 있음을 명심하자
    • 문서 ID를 해당 문서의 댓글수 또는 클릭수 등의 특성을 담은 테이블과 조인한다고 가정
    • 학습 시점과 서빙 시점 사이에 테이블의 특성이 달라질 수 있음

    역자 : 특히 시계열성 데이터에서 많이 실수함(Lag 변수)

    • 이런 경우 학습과 서빙 간에 같은 문서에 관한 모델의 예측이 서로 달라짐
    • 이런 문제를 피하는 가장 쉬운 방법은 서빙 시에 특성을 기록하는 것(Rule #32 참조)
    • 테이블의 변화가 비교적 느리다면 1시간 또는 하루마다 테이블의 스냅샷을 만들어 적당히 근접한 데이터를 얻을 수 있음
    • 그러나 문제가 완벽하게 해결되는 것은 아님
  • Rule #32: 가능하면 학습 파이프라인과 서빙 파이프라인 간에 코드를 재사용하자
    • Batch 처리는 Online 처리와 다름
    • 온라인 처리는 도착하는 각 요청을 실시간으로 처리해야 하므로 각 쿼리에 대해 별도의 조회를 수행하는 반면, 배치 처리에서는 여러 작업을 조인 등의 방법으로 결합할 수 있음
    • 서빙 시에는 온라인 처리를 수행하는 반면, 학습은 일괄 처리 작업
    • 그러나 코드를 재사용할 수 있는 방법이 몇 가지 있음
      • 예를 들어 모든 쿼리 또는 조인의 결과를 사람이 읽을 수 있는 방식으로 저장하면 오류를 쉽게 테스트할 수 있음
      • 그런 다음 모든 정보가 수집되었으면 서빙 또는 학습 중에 공통 메소드를 실행하여 사람이 읽을 수 있는 객체와 머신러닝 시스템에 사용되는 형식을 연결하자
      • 이렇게 하면 학습-서빙 격차가 근본적으로 방지됨
      • 이렇게 하려면 우선 학습 코드와 서빙 코드에 동일한 프로그래밍 언어를 사용해야 합니다
      • 그렇지 않으면 코드를 공유하기가 거의 불가능함

      역자 : 우버는 Spark로 Training / Serving을 모두 통합함

  • Rule #33: 1월 5일까지 수집된 데이터를 기준으로 모델을 생성하는 경우 1월 6일 이후의 데이터로 모델을 테스트하자
    • 일반적인 규칙은 모델 학습에 사용된 데이터보다 이후에 수집된 데이터로 모델의 성능을 측정하는 것
    • 이렇게 하면 시스템의 프로덕션 성능을 더 정확히 예상할 수 있음
    • 1월 5일까지 수집된 데이터를 기준으로 모델을 생성하는 경우 1월 6일 이후의 데이터로 모델을 테스트하자
    • 새 데이터에 관한 성능은 기존 데이터보다 다소 저하되는 것이 정상이지만 크게 나빠져서는 안됨
    • 우연히 daily로 변동이 생길 수 있으므로 평균적인 클릭률 또는 전환율이 변경되지 않을 수 있지만, 양성 예시가 음성 예시보다 1점 높게 나올 가능성을 나타내는 AUC는 합리적인 유사도를 보여야 함
  • Rule #34: 스팸 감지, 관심 이메일 판단 등 필터링을 위한 이진 분류에서는 단기적으로 다소의 성능 저하를 감수하더라도 데이터를 철저히 정제하자
    • 필터링 작업에서는 음성으로 판정된 예시를 사용자로부터 숨긴다
      • 서빙 시 음성 예시의 75%를 차단하는 필터가 있다고 가정하자
      • 사용자에게 표시된 instance로 추가적인 학습 데이터를 추출하려는 생각을 할 수 있음
      • 예를 들어 필터를 통과했지만 사용자가 스팸으로 신고한 이메일은 학습 데이터로 활용할 수 있음
    • 그러나 이 방식은 샘플링 편향을 유발함
      • 더 정제된 데이터를 얻는 방법은 서빙 시 전체 트래픽 중 1%를 ‘홀드아웃’으로 라벨링하고 모든 홀드아웃 예시를 사용자에게 보내는 것
      • 이제 필터는 음성 예시 중에서 최소 74%를 차단함
      • 이러한 홀드아웃 예시는 학습 데이터가 될 수 있음
    • 필터가 음성 예시의 95% 이상을 차단한다면 이 접근법은 현실성이 낮음
    • 그렇더라도 서빙 성능을 측정하려는 경우 소량의 샘플(0.1% 또는 0.001%)을 추출할 수 있음
    • 1만 개 정도의 예시가 있으면 성능을 비교적 정확히 추정할 수 있음
  • Rule #35: Ranking 문제에선 특유의 왜곡이 나타날 수 있음
    • 표시되는 결과가 바뀔 정도로 ranking 알고리즘을 급격히 변경하면 알고리즘에서 이후에 접하게 될 데이터 자체가 변화함
    • 이러한 유형의 왜곡이 나타날 것을 대비하여 모델을 설계해야 함
    • 여기에는 여러 가지 접근법이 있으며, 공통점은 모델에서 기존에 접한 데이터를 우선시함
    • 1) 쿼리 하나에만 해당하는 특성 보다 여러 쿼리를 포괄하는 특성에 더 높은 정규화를 적용
      • 이렇게 하면 모델에서 모든 쿼리로 일반화되는 특성보다 하나 또는 소수의 쿼리에 국한되는 특성이 우선시됨
      • 이 방식은 자주 나타나는 결과가 이와 무관한 쿼리에까지 영향을 주지 않도록 차단할 때 도움이 됨
      • unique 값이 많은 feature에 더 높은 정규화를 적용하라는 기존의 권장사항과는 정반대임
    • 2) featue에 positive weight만 허용
      • 따라서 양호한 모든 특성이 ‘미지의’ 특성보다 우선시됨
    • 3) 문서에만 국한된 feature를 배제
      • 이는 #1의 극단적인 경우
      • 예를 들어 특정 앱이 쿼리와 무관하게 많은 다운로드를 기록했더라도 무조건 항상 표시할 수는 없음
      • 문서에만 국한된 특성을 배제하면 문제가 단순해짐
      • 특정한 인기 앱을 무조건 표시하지 않으려는 이유는 모든 추천 앱을 골고루 제공하는 것이 중요하기 때문
        • 예를 들어 ‘조류 관찰 앱’을 검색한 사용자가 ‘앵그리 버드’를 다운로드할 수는 있지만 기존 의도에 분명히 어긋난 결과
      • 이러한 앱을 표시하면 다운로드율은 올라가지만 사용자의 궁극적인 요구사항이 해결되지는 않음
  • Rule #36: positional feature를 사용해 피드백 루프를 방지하자
    • 콘텐츠의 위치는 사용자와 상호작용에 막대한 영향을 줌
    • 앱을 1번 위치에 표시하면 실제로 클릭수가 올라가며, 앞으로도 그러할 것으로 확신할 수 있음
    • 이 문제를 다루는 방법 중 하나는 positional feature, 즉 페이지에서 콘텐츠가 차지하는 위치에 관한 특성을 추가하는 것
      • 모델 학습에 위치 특성을 사용하면 ‘1st­position’과 같은 특성에 높은 가중치를 부여하도록 모델이 학습됨
      • 따라서 ‘1st­position=true’를 갖는 예시에서 다른 요소에 적은 가중치가 부여됨
      • Serving 시에는 후보의 점수를 매긴 후에 표시 순서를 결정하게 되므로 모든 인스턴스에 위치 특성을 지정하지 않거나 동일한 기본 특성을 지정함
    • 위치 특성은 이와 같이 Training과 Testing 간에 비대칭성을 가지므로 모델의 나머지 부분과 별도로 유지하는 것이 중요함
    • 모델을 positional feature의 함수와 나머지 특성의 함수를 더한 합으로 만드는 것이 가장 좋음(앙상블)
    • 예를 들어 위치 특성과 문서 특성을 교차해선 안됨
  • Rule #37: Training/Serinvg Skew를 측정하자
    • 격차가 발생할 수 있는 원인은 보통 몇 가지로 정리되며, 다음과 같이 나눌 수 있음
      • 학습 데이터와 홀드아웃 데이터의 성능 차이
        • 일반적으로 이 차이는 불가피하며 반드시 나쁜 것은 아님
      • 홀드아웃 데이터와 ‘다음날’ 데이터 간의 성능 차이
        • 이 차이도 불가피함
        • 다음날 성능을 극대화하는 방향으로 정규화를 조정해야 함
        • 홀드아웃 데이터와 다음날 데이터 간에 상당한 격차가 있다면 일부 feature에 시간 민감성이 있어 모델의 성능을 저하한다는 증거일 수 있음
      • ‘다음날’ 데이터와 실시간 데이터 간의 성능 차이
        • 학습 데이터의 example에 모델을 적용할 때와 serving시 동일한 example에 모델을 적용할 때 완전히 같은 결과가 나와야 함(Rule #5 참조)
        • 따라서 이 차이는 엔지니어링 오류를 시사할 가능성이 높음



4부. ML 3단계: Slowed Growth, Optimization Refinement, and Complex Models

  • 2단계가 마무리되고 있음을 나타내는 구체적인 징후
    • 가장 먼저, 월별 개선 폭이 둔화하기 시작
    • 측정항목 간에 절충 관계가 나타나기 시작
      • 즉, 몇몇 실험에서 상승하는 측정항목과 하락하는 측정항목이 동시에 나타남
    • 여기서부터 문제가 복잡해짐
    • 개선을 이루기가 어려워졌기 때문에 머신러닝 시스템을 정교화해야 함
  • 이 섹션에는 이전 섹션보다 다소 비현실적인 규칙이 포함될 수 있으므로 주의!

  • 머신러닝 1단계와 2단계는 일사천리로 진행할 수 있지만 3단계부터는 스스로 길을 찾아 나가야 함

  • Rule #38: unaligned된 objective가 문제가 된다면 새로운 Feature에 시간 낭비하지 말자
    • Metric 개선이 한계에 다다르면 현재 머신러닝 시스템의 목표에서 벗어난 문제점을 찾기 시작할 때
    • 앞에서도 설명했듯, 기존의 알고리즘 목표로는 제품의 목표를 해결할 수 없다면 알고리즘 목표와 제품 목표 중 하나를 변경해야함
    • 예를 들어 클릭수, +1 또는 다운로드 횟수를 최적화할 수 있지만 출시 결정을 내릴 때는 인간 평가자의 의견도 참고할 수 있음
  • Rule #39: 출시 결정은 제품의 장기적인 목표를 반영해야함
    • 설치 횟수 예측의 logistic loss를 줄일 수 있는 아이디어를 생각했다
      • 해당 feature를 추가했더니 로지스틱 손실이 감소했다
      • 실시간 실험 결과 설치율 상승이 관찰됨
      • 그런데 출시 검토 회의에서 일일 활성 사용자 수가 5% 하락했다는 지적이 나옴
      • 따라서 모델을 출시하지 않기로 결정
    • 실망스러운 결과지만 출시 결정에는 여러 가지 기준이 작용하며 ML을 통해 최적화할 수 있는 것은 그중 일부에 불과하다는 점을 알게 됨
    • 현실 세상은 게임과 달라서, 제품의 상태를 일률적으로 판단할 수 있는 ‘체력 수치’ 같은 개념이 없음
      • 팀에서는 수집 가능한 통계를 총 동원하여 시스템의 미래 성능을 효과적으로 예측하기 위해 노력해야함
      • Engagement, 1일 활성 사용자(DAU), 30일 DAU, 광고주의 투자수익 등을 고려해야 함
      • 이런 metric은 AB 테스트로 측정할 수 있지만 사용자 만족도, 사용자 수 증가, 파트너 만족도, 수익 등의 더욱 장기적인 목표를 대변하는 역할을 함
      • 제품의 유용성과 품질 향상 및 5년 후의 회사 발전과 같은 목표에 대해서도 이를 대변하는 metric을 생각할 수 있음
    • 출시 결정을 내리기 쉬운 유일한 경우는 모든 측정항목이 개선되거나 적어도 악화되지 않을 때
      • 팀에서 정교한 머신러닝 알고리즘과 단순한 휴리스틱 사이에서 선택할 수 있으며 단순한 휴리스틱이 모든 측정항목에서 더 나은 결과를 보인다면 휴리스틱을 선택해야함
      • 또한 가능한 모든 metric 값 사이에 명백하게 우열이 가려지지도 않음
    • 구체적으로 다음과 같은 두 가지 시나리오를 살펴보자
실험DAURevenue/Day
A1 million$4 million
B2 million$2 million
  • 현재 시스템이 A라면 B로 전환할 가능성은 낮음
    • 현재 시스템이 B라면 A로 전환할 가능성은 낮음
    • 이러한 상황은 모순적으로 보이지만, 측정항목에 관한 예측은 적중한다는 보장이 없으므로 어떠한 변화에도 상당한 위험이 뒤따름
    • 두 metric 모두 팀에서 우려하는 위험을 수반함
  • 뿐만 아니라 어떠한 측정항목도 팀의 궁극적인 관심사인 ‘지금부터 5년 후에 제품이 어떠한 위치에 있을까?’라는 의문을 해결해 주지 못함
  • 사람들은 자신이 직접 최적화할 수 있는 측정항목 하나를 중시하는 경향이 있음
    • 대부분의 머신러닝 도구는 이러한 환경에 적합함
    • 이러한 환경에서 새로운 feature를 개발하는 엔지니어가 끊임없이 계속되는 출시에 대응해야함
    • 머신러닝 유형 중 이 문제를 다루기 시작하는 유형이 multi-objective learning임
      • 예를 들어 각 측정항목에 관한 하한선을 갖는 제약조건 충족 문제를 작성하고 측정항목의 특정한 선형 조합을 최적화
      • 그러나 이렇게 하더라도 모든 측정항목을 머신러닝 목표로 손쉽게 규격화할 수 있는 것은 아님
      • 문서가 클릭되거나 앱이 설치되는 이유는 콘텐츠가 표시되었기 때문
      • 그러나 사용자가 사이트를 방문한 계기를 알아내기는 훨씬 어려움
      • 사이트의 미래 실적을 전반적으로 예측하는 문제는 AI-Complete 문제로 컴퓨터 시각인식 또는 자연어 처리만큼이나 어려움
  • Rule #40: 앙상블을 단순하게 유지하기
    • Raw feature를 사용해 컨텐츠의 순위를 바로 결정하는 통합 모델은 디버깅 및 파악이 가장 쉬운 모델임
      • 그러나 모델의 앙상블(다른 모델의 점수를 종합하여 만든 단일 ‘모델’)은 더 우수한 성능을 발휘할 수 있음
      • 단순성을 유지하려면 각 모델은 다른 모델의 입력만을 취하는 앙상블이거나 여러 특성을 취하는 기본 모델이어야 하며, 두 가지 입력을 모두 취해서는 안 됨
      • 별도로 학습되는 다른 모델을 기반으로 하는 여러 모델이 있는 경우 이러한 모델을 결합하면 부적합한 동작이 나타날 수 있음
    • 앙상블에는 ‘기본’ 모델의 출력만을 입력으로 취하는 단순 모델을 사용하자
      • 그리고 앙상블 모델의 속성을 직접 규정할 필요가 있음
      • 예를 들어 기본 모델이 산출하는 점수가 상승하는 경우 앙상블의 점수가 하락해서는 안됨
      • 또한 가급적이면 입력 모델이 semantically적으로으로 해석 가능하도록 보정 등의 작업을 거쳐야함
      • 그래야 underlying(기반) 모델의 변화가 앙상블 모델에 혼선을 주지 않음
      • 또한 underlying(기반) 분류자가 예측한 확률이 상승할 때 앙상블이 예측한 확률이 하락하지 않도록 강제해야함
  • Rule #41: 성능 개선이 한계에 다다르면 기존 신호를 다듬기보다는 본질적으로 새로운 정보를 추가하자
    • 사용자의 인구통계 정보를 추가함
      • 문서에 포함된 단어에 관한 정보도 추가함
      • 템플릿 탐색을 수행하여 정규화를 조정함
    • 그런데 핵심 측정항목이 1% 이상 개선된 출시가 몇 분기 동안 단 한 번도 없었습니다. 이제 어떻게 해야 할까요?
    • 이제 완전히 다른 feature를 위한 인프라 구축을 시작할 때
      • 예를 들면 사용자가 어제, 지난주, 작년에 액세스한 문서 내역, 다른 출처에서 가져온 데이터 등
      • 위키데이터 항목 또는 사내 보유 데이터(예: Google의 지식 정보)를 사용하자
      • 딥러닝을 활용하자
      • ROI를 조정하고 새로운 feature를 위한 업무량을 늘려야함
      • 다른 엔지니어링 프로젝트와 마찬가지로, 새 feature를 추가하는 데 따르는 편익과 복잡성이 올라가는 데 따르는 비용을 저울질해야함
  • Rule #42: Diversity, Personalization, Relevance는 polularity와 상관관계가 의외로 낮을 수 있음
    • 컨텐츠 집합의 Diversity은 여러 가지 의미를 가질 수 있는데, 가장 흔한 것은 컨텐츠 출처의 다양성을 의미함
      • Personalization란 각 사용자에게 자신만의 결과를 제공하는 것
      • Relevance이란 특정 쿼리의 결과가 다른 어떠한 결과보다도 해당 쿼리에 적합하다는 의미
      • 따라서 이러한 세 가지 속성은 특별한 속성으로 규정됨
      • 그러나 평범함이 최선인 경우도 많다는 것이 문제
    • 시스템에서 클릭수, 사용 시간, 시청 횟수, +1, 재공유 등을 측정한다면 결과적으로 컨텐츠의 인기도를 측정하는 것
    • 어떤 팀에선 다양성을 갖춘 개인별 모델을 학습시키려고 함
      • 이를 위해 시스템의 personalize(사용자의 관심사를 나타내는 특성) 또는 diversify(이 문서가 다른 반환 문서와 저자, 콘텐츠 등의 특성을 공통적으로 갖는지를 나타내는 특성)에 기여하는 특성을 추가하지만, 가중치가 생각보다 낮거나 부호가 반대라는 사실을 알게됨
    • Diversity, Personalize, Relevance가 중요하지 않다는 의미는 아님
      • 이전 규칙에서 설명했듯이 후처리를 통해 Diversity 또는 Relevance을 강화할 수 있음
      • 더 장기적인 목표가 개선되는 것으로 나타난다면 popularity와 별개로 Diversity/Relevance이 중요하다고 판단할 수 있음
      • 후처리를 계속 사용할 수도 있고, Diversity 또는 Relevance 기준으로 목표를 직접 수정할 수도 있음
  • Rule #43: 당신의 친구들은 다른 제품에 같은 경향이 있지만 당신의 관심사는 그렇지 않은 경향이 있음(해석이 어려워서 원문을 남깁니다 : Your friends tend to be the same across different products. Your interests tend not to be)
    • Google의 여러 팀에서는 한 제품에서 관계의 긴밀함을 예측하는 모델을 취하여 다른 제품에 성공적으로 적용함으로써 큰 성과를 거둠
    • 반면, 여러 제품 분야를 넘나드는 맞춤화 특성으로 인해 고생하는 팀도 있음
      • 이론적으로는 성공해야 할 것 같은데, 실제로는 잘 되지 않음
    • 한 부문의 원시 데이터를 사용하여 다른 부문의 사용자 행동을 예측하는 방법은 성공을 거두기도 함
    • 또한 사용자가 다른 부문에서 활동한 적이 있다는 사실만 알아도 도움이 될 수 있음
    • 예를 들어 사용자가 두 제품을 사용했다는 사실 자체가 큰 의미를 가질 수 있음

Reference


카일스쿨 유튜브 채널을 만들었습니다. 데이터 사이언스, 성장, 리더십, BigQuery 등을 이야기할 예정이니, 관심 있으시면 구독 부탁드립니다 :)

PM을 위한 데이터 리터러시 강의를 만들었습니다. 문제 정의, 지표, 실험 설계, 문화 만들기, 로그 설계, 회고 등을 담은 강의입니다

이 글이 도움이 되셨거나 다양한 의견이 있다면 댓글 부탁드립니다 :)

Buy me a coffeeBuy me a coffee



© 2017. by Seongyun Byeon

Powered by zzsza