[추천 시스템 입문] CH07. 추천 시스템 평가 - (2) 온라인 평가

들어가는 글 

---

실제 서비스 사용자에게 영향을 주지 않고 평가를 수행하는 오프라인 평가와 달리, 실제 사용자에게 미치는 영향을 평가하는 온라인 평가에 대해서 알아본다.

온라인 평가는 시스템의 변경점을 실제로 사용자에게 제시해, 평가하는 방법을 온라인 평가라고 부른다.

온라인 평가로 사용되는 A/B테스트와 인터리빙 테스트 방식에 대해 알아보자.

또한 온라인 평가에 사용되는 지표가 있는데, 온라인 평가지표는 어떤 종류가 있으며, 어떤 역할을 하는지에 대해 알아보자.

7.3 온라인 평가

---

7.3.1 A/B테스트

---

• A/B테스트는 무작위 비교 실험(Randomized Controlled Trial_RCT) 중 하나의 방식이다.
  • 사용자를 Treatment그룹(실험그룹), Control그룹(대조군) 나눠서 평가를 수행한다.

A/B 테스트 예

7.3.1.1 가설

---

가설 세우기

• A/B 테스트 전에는 테스트 대상의 효과에 대해 가설을 세우는 것이 좋고 아래와 같은 가설 템플릿을 사용할 수 있다.

가설 템플릿 예시

• 가설 템플릿 예시
  • 콘텍스트 : 실험의 배경 설명
  • 변경점 : 무엇을 어떻게 바꾸는가?
  • 대상 : 대상 사용자는 누구인가?
  • 지표 영향 : 변경점이 지표에 어떤 영향을 미치는가?
  • 비지니스 목표 : 이니셔티브를 통해 달성하고 싶은 최종 비지니스 목표는 무엇인가?
• → 조직에서 올바른 의사결정을 내리기 위해서는 이런 형태로 가설을 미리 문서로 명확히 해두는 것이 중요하다.
• → 템플릿을 통해 (+) 사전에 지표를 정의하고 비지니스 목표와의 연결을 명확히 할 수 있다.
• → 템플릿을 통해 (+) 비지니스 관점에서 이니셔티브의 우선 순위를 결정할 수 있다.
• → 템플릿을 통헤 (+) 팀 전체가 이니셔티브의 효과를 확인할 때 커뮤니케이션 부하를 낮추는 효과도 있다.

 

진행방법

 

• 사용자 그룹을 나눌 때는 난수를 사용한다. 예를들면 ID를 해시함수에 넣어서 나온 값에 따라 나누는 방법을 생각해볼 수 있다.
• A/B테스트는 실제로 사용자에게 변경점을 보여주므로 사용자 만족도를 저하시킬 수 있습니다.
  → 따라서, 먼저 적은 수의 사용자에게 실시할 내용이 의도대로 동작하는 지 확인
  → 이후에, 정의한 지표를 수집할 수 있도록 사용자 수를 늘려가는 것을 권장

 

주의점

• 그룹편향(group bias) 주의 : 이 그룹 편향은 A그룹과 B그룹에 같은 이니셔티브를 수행하고 그 평가 지표에 차이가 없을 확인하는 A/A 테스트로 확인할 수 있다.
• 로그혼합 주의 : A그룹과 B그룹의 로그 혼합 주의
• 집계기간 유의 : 사용자는 새로운 변화에 과도하게 반응하는 경우가 있다. 이런 경우 단기간의 테스트보다는 장기간 테스트를 했을 때 그 결과가 달라질 수 있다. 또한 요율이나 계절 조건에 따라 효과가 크게 달라지는 대상이 테스트에 포함되면 단기간 집계하였을 때, 잘못된 결과가 나올 위험이 있으므르 주의해햐한다.

 

7.3.1.2 지표의 역할

---

OEC 지표

• OEC(Overall Evaluation Criteria) 지표 : A/B 테스트의 성공과 실패를 최종적으로 판단하는 지표
  • 서비스/비지니스의 성공을 위해 시스템을 움직이는 것을 돕기 위해 정의된 지표이다.
  • OEC지표는 장기적인 서비스 KPI와 연관되어야한다. 동시에 단기간에는 팀이 행동할 때 충분히 공감해야한다. 또한 팀 단위 뿐만 아니라 조직 전체가 OEC지표에 대해 합의하는 것이 바람직하다.
• OEC 설계 방식
  • 사용자에게 초점을 맞춰서 설계한다. “Focus on the user and all else will flow”라는 구글의 철학 중 하나와 일치한다.사용자 만족도를 측정하는 지표를 설계하는 관점으로 다음을 생각할 수 있다.
  • = 사용자가 서비스/상품을 통해 무엇을 달성하고 싶고 무엇을 경험하고 싶은가에 초점을 맞춘 OEC지표를 개선하는 것이 기업의 장기적인 성공으로 이어진다.
  • <HEART 프레임워크>
    • Happiness : 서비스에 대한 사용자의 감각이다. 만족도 / 시각적 매력 / 쉬운 사용성 등 사용자의 주관적인 측면과 관계가 있다. 또한 행동 로그로 추정하기 어려운 경우 사용자 설문을 추가해 실시할 수 있다.
    • Engagement : 상품에 대한 사용자의 관여 수준. 예를들면 기간동안의 서비스 실행빈도나 인터랙션의 깊이
    • Adoption : 어떤 기간에 새로 상품을 사용하기 시작한 신규 사용자.
    • Retention : 어떤 기간의 사용자 중 몇 명이 그 뒤의 기간까지 여전히 서비스 사용을 지속하고 있는가와 관련되어있음.
    • Task success : 효율성(태스크 종료까지의 기간), 유효성(태스크 완료율 등), 에러율 등 기존 사용자의 만족도와 관련되어있다.

가드레일 지표

• 가드레일(guardrail) 지표 : 저하되어서는 안되는 제약을 표시한다.
  • 페이지 열람 수, 서비스 기동률, 응답속도, 주간 액티비 사용자 수, 수익금 등
    • 참고 ) 응답속도는 매우 중요 : 100ms(0.1s)의 차이가 0.6% 수익금 차이로 이어진다는 보고 (by MS bing검색)
• 사용자 행동에는 다양한 트레이드 오프(trade - off)가 존재함에 주의해야한다.
  • ex. 개인화 모듈의 클릭 정밀도가 향상된 결과 → 연관 아이템 모듈의 클릭수가 감소 : 실제로 자주 발생한다~
  • 그러므로, A/B 테스트에서는 최종적인 어떤 이니셔티브의 효용을 OEC 지표로 측정하면서 서비스 전체의 트레이드오프를 고려해 가드레일 지표를 설계해야한다.

 

7.3.1.3 지표 설계 방침

• 다양한 OEC지표와 가드레일 지표를 고려할 수 있는 경우 어떤 지표를 선택하는게 좋을까?
• “온라인으로 통제되는 실험 결과 평가에 관한 여려움, 모범 사례 및 위험 (Challenges, Best Practices and Pitfalls in Evaluating Results of Online Controlled Experiments)” 에서 5가지 특성(STEDI)를 기준으로 좋은 지표를 정의할 수 있다.

STEDI

• 감도(Sensitivity)
  • 지표는 감도가 좋아야한다.
  • 이동 확률(Movement Probabilty) : 지표가 얼마나 빈번하게 변동하는가
    → 좋은 지표는 크게 변화할 확률이 적고 안정적으로 측정할 수 있다
  • 통계력(Statistical Power) : 효과에 변동이 있을 때 그것을 얼마나 정확하게 특정할 수 있는가
    →이 통계력은 검출력이라고도 불리며 → 업계에서는 A/B테스트의 검출력을 최소 80%로 요구한다.
• 신뢰성(Trushworthiness)
  • 지표를 얻는 것은 쉽지만, 신뢰할 수 있는 지표를 얻는 것은 녹록지 않다.
    • 서버 문제 등 수치가 결손되는 경우도 빈번하다.
    • 로그 사양과 실측값에 괴리가 있는 경우도 종종 있다.
    • 웹서비스의 봇(Bot)의 접근은 제거해야한다. ” 흥미로우며 차이가 명확한 데이터는 대부분 오류이다” 라는 트위만의 법칙과 같이 구체적으로 강한 결과가 나타났을 때에는 먼저 어떤 외적 원인이나 측정 실수를 의심하고 그 신뢰성을 확인해야한다.
• 효율성(Efficiency)
  • 지표는 효율이 좋은 의사결정으로 연결되어야한다.
  • 성숙한 조직이고 실험 체제가 정리되어 있으면, 수행하는 테스트 수도 점점 증가한다.
  • 즉, 성숙한 조직에서 평가의 효율은 매우 중요!
    • 효율에는 “시간”, “복잡성”, “비용”의 3가지가 있다.
    • “시간”
      • “An appriximate answer today is worth much more than a presumed better answer three months out” = 3개월 후에 얻게 될 정확한 답보다는 오늘 얻을 수 있는 대략적인 답이 더 가치가 있다 라는 뜻
      • ex. 넷플릭스
        • 재생 시간 : 1개월 지속할 확률의 대리변수로 사용
      • ex. 코세라
        • 과정 자료의 인터랙션과 퀴즈 사용률 : 과장 완주율의 대리 지표로 사용
        → 대략적으로 보다 빠르게 결과를 얻을 수 있는 변수를 찾는 것이 중요.
    • “복잡성”
      • 복잡한 지표도 효율성을 떨어뜨림
        • ex. 아웃랭킹(out ranking)
        • ex. 설문 → 이러한 인지적 지표는 규모를 확장하기 어려움.
    • “비용”
      • 데이터를 얻는 비용도 중요!
        • ex.메일의 스팸 판정이나 광고의 적합성 판정을 사람 손으로 수행하는 것도 규모를 확장하기 어렵고 비용도 높아짐.
• 디버깅 가능성(Debuggability)과 액션 가능성(Actionability)
  • 테스트에 이상이 있을 때 그 이상의 원인을 추적해 수정하는 것과 연결되는 지표도 준비해야한다.
  • 버그나 크래시를 감지할 수 있는 구조를 지표로 설계
  • 설명한 숫자가 크게 변동했을 때는 버그일 가능성이 있다.
• 해석 가능성(Interpretability)과 방향성(Directionality)
  • 해석 가능성 : 지표는 쉽게 해석할 수 있어야한다.
    • ex. 사용자의 불만을 집계하고 싶은경우, 만족도를 5단계로 평가했을 때 5단계의 평균을 구하는 경우는 해석이 어렵다. → 이 경우, 불만이 있다고 대답한 사용자의 비율을 집계하는 편이 해석하기 쉽다.
  • 방향성 : 해당 변수가 개선되었을 때, 비지니스 목표가 달성되는가를 나타낸다.
    • ex. 뉴스 어플리케이션에서 사용자 참여(user engagement) 향상을 목적으로 하는 경우, 어떠한 기능의 클릭률이 향상돼도 전체 클릭률이 저하된다면 목적을 달성했다고 할 수 없다.

 

7.3.2 인터리빙

---

• 온라인 평가의 또 다른 방법으로 인터리빙(interleaving)이 있다.
• A/B 테스트에서는 테스트 대상의 수만큼 사용자 그룹을 나눠야한다. 결국 테스트 대상이 늘어남에 따라 테스트 사용자 수도 선형적으로 늘어나기 때문에, 평가 효율이 문제될 수 있다.
• 인터리빙은 순위 평가에서 A/B테스트보다 10배~100배 더 효율적인 방법으로 알려져 있다.
• 인터리빙은 평가 시 A/B 테스트처럼 사용자 그룹을 나누지 않는다. 그 대신 평가 대상의 각 순위를 하나의 순위로 섞어 사용자에게 제시한다. 뒤섞인 순위에 대한 클릭으로 원래 순위끼리 평가한다.
• 2개의 순위를 섞에서 평가 → 인터리빙 
• 3개의 이상의 순위를 섞어 평가 → 멀티리빙
  멀티리빙은 많은 모델이나 파라미터를 동시에 테스트하고 싶을 때, A/B테스트 실시 전 테스트 대상의 필터링에 사용되기도 한다.

A/B테스트와 인터리빙

 

• 인터리빙의 각 방법은 순위를 섞는 방법과 사용자의 클릭을 집계하는 종류에 따라 다양하다.
• 대표적인 인터리빙(멀티리빙) 방법의 특징은 다음과 같다.

Team Draft Multileaving(TDM)

• 2개의 검토 결과를 선택할 때마다 선공/후공을 무작위로 결정하면서 양 순위에서 하나씩 아직 사용되지 않은 검색결과를 상위부터 순서대로 제공한다.

 

Probabilistic Multileaving(PM)

• 가능한 한 각 순위 안의 검토 결과 순서를 유지하면서 상대적으로 낮은 확률로 임의의 순서에서 검토 결과를 선택하도록 허용

 

Optimized Multileaving(OM)

• 먼저 출력 후보가 되는 순위를 다수 준비하고 최적화 문제를 풀어냄으로써 출력 후보의 순위 출력 확률을 조정한다. 

 

Pairwise Preference Multileaving(PPM)

• 속도가 빠르면서도 Considerateness, Fidelity 라는 이론적 보증이 가능한 방법이다. 
• Considerateness : 섞어서 만든 순위는 원래의 입력 순위보다 품질이 나쁘지 않다는 성질 = 테스트 시 입력 순위 이상으로는 사용자의 만족도를 저하시키지 않는다는 것을 보증한다는 의미 
• Fidlity : 무작위로 클릭을 부여한 경우 모든 순위 점수의 기댓값이 같아지고 동시에 보다 우수한 순위 점수의 기댓값은 더 높아진 다는 성질 

 

• 대표적인 인터리빙 방법의 장단점은 다음과 같다. 

인터리빙의 방법별 특성

• PPM은 속도가 빠르면서도 이론적으로 보증하는 한편 구현이나 집계가 상당히 복잡하여, 먼저 인터리빙을 시험할 때에는 TDM부터 도입하는 것을 권장한다. 
• TDM은 구현과 집계가 용이하다.
• 인터리빙 구현한 예에 대해 참고할 수 있는 깃 : https://github.com/mpkato/interleaving

GitHub - mpkato/interleaving: A python library for conducting interleaving, which compares two or multiple rankers based on obse

 

• 마지막으로 A/B테스트와 인터리빙의 장단점은 다음과 같다.

AB테스트 vs 인터리빙

 

 

마무리 글 

---

온라인 평가에 대표적인 AB테스트는 어떤 방식인지 대략 이해를 했는데, 인터리빙은 잘 와닿지가 않는다.

인터리빙쪽은 다시 공부해볼 필요가 있는 것 같당.. ㅎㅎ 

 

그리고 해당 챕터의 구성이 약간 희한했는데, 해당 챕터를 통해 OEC지표가 무엇이고 가드레일지표가 무엇인지 알게 되었다. 

실무적으로도 좀 더 생각해볼 필요가 있겠다.