[머신러닝 시스템 디자인 스터디 Part2]Setting up a Machine Learning System

Machine Learning System 셋업의 키포인트

---

문제를 준비해라

우선, 질문들을 던져라

머신러닝 인터뷰에서 면접관의 질문은 다양하고 스펙트럼이 넓다. 

질문을 해서 문제에 대한 자신의 이해도와 면접관의 기대치의 간격을 줄여야한다. 이를 통해 문제의 크기를 좁혀나갈 수 있고, 시스템의 요구사항의 각을 잡을 수 있게되어 결국 머신 러닝 문제의 상태를 정확하게 파악할 수 있을 것이다. 

---

예시:

면접자가 사용자의 쿼리들의 응답결과와 가장 유사한 것들을 찾는 검색엔진을 설계하라는 문제를 받았다. 

문제를 Narrow Down 하기 위해 다음과 같은 질문들을 하는 것이 좋다. 

• 이 문제에서 검색 엔진이 뜻하는 것은 구글이나 Bing 같은 일반 검색 엔진인가, 혹은 아마존 상품 검색과 같은 특정한 검색 엔진인가?
• 정답으로서 어떠한 종류의 쿼리를 예상하는가?

위의 질문들을 통해 ML Problem 를 정밀하게 정의하면, '"Rechard Nixon", 혹은 "Programming languages" 등의 검색을 요청할 때 가장 관련있는 결과들을 반환하는 일반적인 검색엔진을 설계해라' 가 될 수도 있다. 

혹은 사용자를 위한 트위터 피드를 화면에 출력하는 시스템을 설계하라고 할 수도 있다. 이 경우, 현재 그 피드가 어떻게 화면에 나타나고 어떻게 하면 사용자들에게 더 나은 경험을 제공할 수 있도록 기능을 향상시킬 수 있도록 의견을 나눌 수 있을 것이다. 

여러가지 상황을 고려하여 토의하고 질문했을 때 다음과 같은 결과를 얻을 수도 있다. '머신 러닝 모델을 훈련시켜 트윗의 참여 확률을 예측하고, 그 결과의 점수를 활용하여 트윗을 주문할 수 있는 트윗 리스트를 설계해라'

• 아마 몇몇의 문제들은 아마 머신러닝 모델들의 입력값으로 제공될 수 있었던 하드웨어 구성요소들에 대한 생각을 요청할 수도 있다. 

---

Understanding Scale and Latency Requirement

문제를 정의하는데 매우 중요한 부분중 다른 하나는 바로 성능과 시스템의 크기 고려사항에 대해 의견을 나누는 것이다. 각각의 예시를 들어보자.

Latency Requirement 

• 검색엔진 문제: 검색결과를 100 밀리세컨드 혹은 500 밀리세킨드 안에 얻어야하나?
• 트위터 문제: 관련된 트윗 리스트를 300 밀리세컨드 혹은 400 밀리세컨트 안에 얻어야하나?

Scale of the data

검색엔진 문제:

• 초당 얼마나 많은 요청들을 다루어야하나?
• 검색엔진을 사용할때 얼마나 많은 웹사이트들을 사용할 수 있도록 하는가?
• 만약 쿼리가 100억개의 일치하는 문서들을 가지고 있다면, 모델을 통해 얼마나 많은 순위 결과가 나와야 하는가?

트위터 문제:

• 한 유저의 한번 사용하는데, 얼마나 많은 트윗들의 순위를 매겨야만 하는가?

---

 Defining Metrics

Metrics는 시스템이 잘 작동하는지를 확인하는데 도움을 줄 것이며, 문제의 성공 기준을 아는것이 머신러닝 문제를 이해하고 구조적 구성들의 중요점을 찾는데 도움을 줄것이다. 

 Metrics for Offline Testing

개발기간에 모델의 성능을 측정하기 위해 Offline Metrics 를 빠르게 사용할 수 있을것이다. 예를 들어, 만약 Binary Classification 을 사용했다면 AUC, Log Loss, Precision, Recall, and F1-score 를 활용할 수 있다. 

• AUC: The Area Under the Curve: 두가지 클래스들의 분류자에 대한 능력을 평가
• Log Loss: 모델의 출력값과 정답의 오차를 정의하는 함수
• Precision: 검출된 결과가 얼마나 정확한지를 나타냄
• Recall: 대상 물체들을 빠뜨리지 않고 얼마나 잘 잡아내는지를 나타냄

https://darkpgmr.tistory.com/162

• F1-score: 정밀도와 재현율의 조화 평균
  
  

https://bhcboy100.medium.com/%EB%A8%B8%EC%8B%A0%EB%9F%AC%EB%8B%9D-%EB%B6%84%EB%A5%98-%ED%8F%89%EA%B0%80%EC%A7%80%ED%91%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-%EC%A0%95%ED%99%95%EB%8F%84-%EC%A0%95%EB%B0%80%EB%8F%84-%EC%9E%AC%ED%98%84%EC%9C%A8-f1-%EC%8A%A4%EC%BD%94%EC%96%B4-6bf91535a01a

• 다른 경우 특정한 문제에 따른 특정한 메트릭스를 활용해야만 한다. 예를 들어, NDCG 메트릭이 있다.
  • Normalized Discounted Cumulative Gain: 추천 시스템에서 랭킹 추천 분야에 많이 쓰이는 평가지표
    https://sungkee-book.tistory.com/11
  • 기존 정보검색에서 많이 쓰였으며, 특히 상위 랭킹 리스트가 하위 랭킹 리스트 보다 중요한 도메인에서 유용함
  • Top K개 아이템을 추천하는 경우, 추천 순서에 가중치를 두어 평가한다.
    • Cumulative Gain (CG): 추천한 아이템의 Relevance 합이다.
      
    • Discounted Cumulative Gain (DCG): CG에 순서에 따른 할인 개념을 도입한것이다.
    • Normalized DGC (NDCG): DCG에 정규화를 적용한 것이다.