ML system design 때의 유의할 점

[data]

• time dependent 한 feature 라면 -> 지금까지 user 가 click 을 몇번 했는가 등 -> training time 동안 계산해서 넣는건 쉽지 않다(그 이전까지만의 값으로 잘 넣아야한다.)

• 데이터 수집 자체에 문제가 있을 수 있음 -> 이들에 있어서 큰 변화가 없는지 모니터링하는 시스템이 있어야한다.

[offline evaluation]

• baseline model(simplest possible model) - 과의 비교 필요

데이터의 분리

• gold standard 는 데이터를 세개로 나누는 것
  • training, evaluation, test
• 교과서에서는 세개로 random하게 나눈 후 k-fold cross validation 하라고 나옴.
• 현실에서는 progressive evaluation을 많이 사용한다
  • older data로 학습, newer data로 evauation, test

Evaluation

뭘 위해 모델을 만드느냐에 따라서 evaluation 방법이 달라져야한다.

• first clicker를 위한 모델이라면
  • training할때에 first clicker가 아닌사람들을 다 빼버리는거는 데이터 손실이 클 것
  • (small amount of specific data) vs (lots of non-specific data)
    -> 이럴때는 실험을 통해 결정하자
    e.g. training 에서는 다 쓰고, validation, test 할때에 first clicker에 대한 정보만 쓰기 와 training 부터 first clicker만 쓴 것을 비교해서 효과가 나은걸 쓴다!
• 만약 evaluation 결과가 통계적으로 유의하지 않다면 데이터의 양을 늘려야할텐데, 이때에 recent data를 쓰는건 여전해야함을 잊지 말것(online 에서도 유효하게 만들어야함)

calibration

• calibration
  • (sum of predictions/sum of labels)의 값이 training 결과, validation 결과, test 결과에서 계속 유지되는지 확인해야한다.
  • 더 정확하게는 데이터를 특정 기준으로 나눈 후에도 계속 유지되는지까지 꼼꼼하게 확인하는게 좋다
• evaluation 자체를 (first clicker로 나눴던 것 처럼) 작은 그룹들로 나눠보는게 의미가 있을 수 있다! -> 어디서 성과가 나오는지를 알아볼 수 있게될 것

[feature]

• output 에 대한 정보를 갖고있어서는 안된다 -> feedback loop 에 빠질 수 있음(model 에 의해 영향받는 feature 가 될 수 있는 것), 다른 feature 들의 정확한 영향력을 계산할 수 없음
• outlier 나 dramatic change 가 있는지에 대한 monitoring 이 있어야함
• training때에 feature 마는 코드와 online testing 할때에 feature 마는 코드는 동일해야한다.
• feature 의 semantic 은 어떻게 해도 변하지 않음.(ranking team 이 front team과 함께 일하는 그림이 좋은 그림)
• 뭔가 semantic 을 변화시키고 싶다면, 기존 feature 를 삭제하지 말고, 변화시킨 후 대신 적용해보고, 성능이 기존보다 좋을때 그때 deprecate한다.

feature leakage

training time 에는 사용한 feature 를 prediction time 에 사용할 수 없는 경우.

• prediction 할 당시에 모를만한 데이터는 제거한다
• data cross validation을 할 것
• leaky 하다고 여겨지는 변수가 있다면 빼고 다시 돌려봐라
• near-perfect model accuracy 는 경고신호
• 과하게 feature importance가 높은 feature 가 있는지 확인하라

feature coverage

• 특정 feature 가 corruption, noise가 있을 수 있을 것
• 이때 해당 feature 의 믿을 만한 정도를 feature coverage라고 함.
• e.g. birth day 같은 feature 들

[model]

linear model 에 대한 고려

• linear 하지 않은 상황들이 막 생길 수 있지만 특정 조건을 미리 줘서 각 조건에 대한 linear model 들을 따로 만들수도 있다.
• density feature 들을 decision tree로 만들고 나서 이걸 linear model 의 feature로 만들수도 있다.
• object detection deep learning model 을 만든다음 마지막 layer 를 more specialized 된 형태로 만들수도 있음

bias variance model

• calibration 이 잘 된 것 같아도 데이터를 쪼개가면서 보다보면 특정 그룹에서는 calibration 이 잘 안맞게 마련. 여기서 뭐가 잘못됐는지를 확인해봐야한다.

[Experiment]

1. Minimize the time to first online experiment

• negative feedback 을 잘 예측하는 모델을 만들었어도 전체의 sentiment 가 어떻게 변했는지는 여기서 확인해야함

2. Isolate engineering bugs from ml performance issues

• 코드를 바꿔서 생긴문제인가, 모델을 바꿔서 생긴 문제인가를 고려해봐야함.
• identity transform 으로 비교해봐야한다.

3. test model in the presence of real world(feedback loops)

• 어제는 이걸로 서빙하고, 오늘은 이걸로 서빙해서 발생하는 문제라면 backtest 를 해본다 (old test model 99%, new candidate 1%로 테스트(front test) 했다면 갈아치운 후에는 1% old model, 99% new model 로 테스트(back test)해볼것)

4. Tips

• be able to triangulate the cause of any changes
  • 한번에 하나만 테스트해서 뭐때문인지를 분명히 알 수 있게 해야한다.
• measure the right thing
  • metric 이 제대로 작동하는지 확인해보자 (값에 무조건 1을 더했을때에 어떻게 변하는지 확인해보는 등)
• have a backup plan
• calibrate
  • average prediction 가 average response rate와 일치하는지 확인할 것
  • sanity checking performance
  • miscalibration means
    • training time : hasn't learned properly
    • testing time : doesn't generalize well
    • online testing time: online/offline gap