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


카일스쿨 유튜브 채널을 만들었습니다. 데이터 분석, 커리어에 대한 내용을 공유드릴 예정입니다.

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

이 글이 도움이 되셨거나 의견이 있으시면 댓글 남겨주셔요.

Buy me a coffeeBuy me a coffee



© 2017. by Seongyun Byeon

Powered by zzsza