Posts [발표리뷰] RecSysOps, 대규모 추천 시스템 운영하기
Post
Cancel

[발표리뷰] RecSysOps, 대규모 추천 시스템 운영하기

  • RecSysOps: Best Practices for Operating a Large-Scale Recommender System, RecSys’21 를 정리한 글입니다.
  • 발표영상, 슬라이드, 논문 ==> 발표영상과 논문에서 다루는 내용이 조금씩 달라 합쳐서 정리했습니다.

  • 넷플릭스에서 추천시스템을 운영할 때 고려 요소, 있을법한 문제, 문제 해결 수단, 운영을 개선하기 위한 점들을 다룬다.
  • High level에서만 다루고 있어서 구체적으로 무엇을 어떻게 할지는 각자의 몫이다.
  • 기존에 MLOps에서 말하는 내용과 겹치는 부분도 조금 있다.

1. RecSysOps

넷플릭스에서는 다양한 목적으로 다양한 추천 모델을 운영하고 있다. 많은 데이터 소스와 피쳐, 앙상블, 복잡한 모델을 사용하는 상황에서 모델들이 제대로 작동하는지 확인하기가 쉽지 않다. 다양한 층위의 유저와 아이템 그룹이 있기 때문에 더 복잡해지는데 각 그룹에 optimal한 추천을 하고 있는지 확인하기란 도전적인 일이다. 이런 문제를 해결하기 위해 발전된 로깅, exploration, 모델 해석 툴, procution 모델의 행동을 예측하는 모델이 필요하다.
RecSysOps란 대규모 추천 시스템에서 생기는 문제와 격차를 규명하여 진단하고 해결하기 위한 교훈들이다. 이를 통해,

1
2
3
1. production 이슈를 줄이고
2. 어느 영역에서 성능을 높일지 규명하여 추천 퀄리티를 높이고
3. 디버깅과 이슈 대응에 신경을 덜 쓰게하여 혁신에 시간을 쏟을 수 있다

image-20211010205814565

2. Issue Detection

제일 어려운 파트이다. 끝없이 많은 이슈가 있을 수 있고 뭐가 문제인지도 모르기도 한다.

  1. 보통 Software Engineering에서 하는 CI/ CD, unit test, 자동화된 재학습 프로세스 확인하기.

  2. 다른 파이프라인과의 수치 비교

    • 이전 파이프라인과(e.g. 어제 수치)의 상대적인 데이터 수치(Input 데이터 양, 분포) 비교하기.

    • popularity, random 추천 모델같은 less error prune모델이나 어제 모델과 현재 모델의 메트릭 비교.

  3. Stakeholder의 concern을 이해하기. 넷플릭스의 경우는 member와 Item.

    • memberlow ranked 아이템을 선택하는 경우 suboptimal일 가능성이 있다.
      • 이런 경우를 분석하고 모니터링 한다.
      • 이유는 다양할 수 있음. 잘못된 모델 가정, 불충분한 데이터, 학습 데이터셋에 있는 편향과 에러.
    • Item을 운영하는 팀의 concern을 이해해야 한다.
      • 새로운 아이템이 적절히 cold-start되고 있는지?
        (발표에서 cold-start를 동사처럼 씁니다. 카탈로그에 새로 추가된 아이템이 합리적으로 충분히 노출되는 긍정적인 의미로 추측됩니다.)
      • production bias로 인해 손해보고 있지 않는지?


3. Issue Prediction

이슈가 생기기 전에 예측할 수 있을까?

넷플릭스의 경우 새로운 아이템이 공개되기 7일 전에 아이템이 cold-start 될지 예측할 필요가 있다.

다시 말해, 적절한 유저 군에 적절한 score값을 가져서 추천이 되는지 확인해야 한다.

이 때문에 production model의 behaviour를 예측하는 모델을 만들 필요가 있었다.

이 모델을 활용해 예상에서 벗어난 아이템에 관심을 갖고 조사해본다.


4. Issue Diagnosis

  1. 이슈를 재현할 수 있어야 한다.

    • 추천 시스템의 환경은 dynamic하게 변하기 때문에 이 역시 쉽지 않다.
    • 때문에 Advanced logging이 필요하다.
    • 정기적으로 사용자 샘플에 대한 모델의 입력과 출력을 기록해야 한다.
    • (자세히 설명을 안 해주었는데 로깅이 발생했을 시점의 유저 피쳐나 아이템 피쳐를 재현하는 것도 일일 듯하다.
  2. 먼저 Input data의 문제일지 Model의 문제일지 구분하자.

    • 인풋의 피쳐 값이 valid한지 확인해야 한다.

    • 피쳐가 valid하다면 피쳐의 어떤 부분이 모델에 unexpected output을 내게 했는지 조사한다. (e.g. SHAP, LIME, …)

5. Issue Resolution

  • 소프트웨어 엔지니어링과 비슷하다. hotfix와 Long term으로 해결해야 하는 문제가 있다.
  • 그런데 ML에서 hotfix는 suboptimality에 빠질 위험이 높다.
  1. hotfix 콜렉션을 준비해두어라. 그것들의 cost와 trade-off를 이해해라.
    • (내생각) 이전 추천 모델로 롤백을 하는 hotfix를 했을 때 생길 수 있는 trade-off를 알아두기.
  2. 어떤 이슈에 대한 패턴이 밝혀지고 fix가 이루어졌으면 이슈를 잡아낼 수 있는 테스트를 만들어 RecSysOps를 개선하자.

6. Make RecSysOps frictionless

  • RecSysOps를 매끄럽게 만들자
  • 사람의 판단이 필요한 경우라면 판단에 필요한 모든 정보를 준비해두자
  • 클릭 몇 번으로 hotfix를 배포할 수 있게하자

.

This post is licensed under CC BY 4.0 by the author.

[번역] System Design for Recommendations and Search

[발견문록] 동네 정보를 발견하는 정겨움, 당근마켓

Loading comments from Disqus ...