
"CTO님, 이번 모델 Recall이랑 NDCG가 기존보다 15%나 올랐습니다. 바로 배포하시죠."
저는 이런 말을 하는 주니어 개발자에게 대답 대신 AWS 청구서를 던져줍니다.
"그 15% 상승이 우리 회사 매출 15% 상승을 보장합니까? 아니면 그냥 학습 데이터에 과적합(Overfitting)된 겁니다?"
많은 엔지니어들이 착각합니다. 추천 시스템(Recommendation System)을 단순한 분류 문제(Classification)로 접근하니까요. 이미지넷(ImageNet) 대회 나가는 게 아닙니다.
[팩트] 여러분이 로컬에서 돌린 오프라인 평가(Offline Evaluation) 지표는 대부분 거짓말입니다.
왜냐하면 여러분은 '관찰(Observational)' 문제를 풀고 있다고 착각하지만, 실제 비즈니스에서의 추천은 '개입(Interventional)' 문제이기 때문입니다.
이 차이를 모르면 GPU 비용만 태우는 '디지털 난로'를 만드는 꼴이 됩니다.
기존 데이터는 '과거의 추천 모델'이 보여준 결과물(Biased Data)일 뿐입니다. 유저는 화면에 노출된 것만 클릭할 수 있습니다.
그런데 여러분은 새 모델이 "과거 모델이 보여줬던 그 아이템을 얼마나 잘 맞추는지"만 채점하고 있습니다.
이건 마치 내일 주가를 맞추라니까, 어제 신문을 얼마나 잘 외웠는지 테스트하는 것과 같습니다.
우리가 진짜 알고 싶은 건 P(view=iphone | prev_model) 따위가 아닙니다.P(click=True | recommend=iphone) 즉, 우리가 개입(Interventional)했을 때 고객의 행동이 변하느냐는 겁니다.
가장 확실한 건 A/B 테스트입니다. 하지만 이건 돈과 시간이 듭니다. 엉망인 모델을 라이브에 올리면 매출은 박살 나고 PM들은 저를 죽이려 들 겁니다.
그래서 내부적으로만 공유하는 '반사실적 평가(Counterfactual Evaluation)' 기법을 소개합니다.
"만약 우리가 A 대신 B를 보여줬다면 어땠을까?"를 수학적으로 추정하는 겁니다.
핵심은 IPS(Inverse Propensity Scoring)입니다.
직관은 간단합니다. 과거 모델(π0)보다 새 모델(πe)이 특정 아이템을 더 자주 추천한다고 가정해 봅시다.
이때 발생한 클릭(Reward)에 가중치(Importance Weight)를 더 주는 겁니다.
공식은 대략 이렇습니다: Weight = 새 모델의 추천 확률 / 구 모델의 추천 확률
예를 들어, 과거 모델이 아이폰을 추천할 확률이 40%였는데, 새 모델은 60%라고 칩시다. Weight = 0.6 / 0.4 = 1.5.
이 경우 발생한 클릭은 평소보다 1.5배의 가치를 가집니다. 반대로 새 모델이 추천을 덜 하는 아이템에서의 클릭은 가치를 낮춥니다.
이렇게 데이터의 분포(Distribution) 차이를 보정(Reweighting)해야 비로소 '진짜 성능'이 보입니다.
물론, 이것도 만능은 아닙니다.
IPS에는 치명적인 약점이 있습니다. 구 모델이 추천 확률을 0으로 뒀던 아이템(아예 노출 안 시킨 아이템)은 분모가 0이 되어 계산이 불가능합니다.
이걸 '불충분한 지지(Insufficient Support)'라고 부릅니다.
이 문제를 해결하겠다고 일부 트래픽에 랜덤 아이템을 노출해서 데이터를 쌓겠다고 하면? PM들이 당장 쫓아와서 "유저 경험 망친다"며 따질 겁니다.
또 다른 문제는 '분산(Variance)' 폭발입니다. 구 모델의 확률이 0.001인데 새 모델이 0.1이라면 가중치가 100배로 뻥튀기됩니다. 클릭 한 번에 지표가 요동칩니다.
그래서 현업에서는 SNIPS(Self-Normalized IPS)나 CIPS(Clipped IPS)를 씁니다.
CIPS는 가중치가 10을 넘어가면 강제로 10으로 잘라버리는(Clipping) 식이고, SNIPS는 전체 가중치 합으로 나눠서 정규화(Normalize)하는 방식입니다.
복잡해 보인다면 이것만 기억하십시오.
- Recall/Precision만 보고 배포하지 마십시오. 그건 과거의 망령입니다.
- 추천은 유저의 행동을 '바꾸는' 행위입니다. 인과관계(Causality)를 고민하십시오.
- IPS 같은 반사실적 추정기를 도입해서, A/B 테스트 전에 오프라인에서 최대한 리스크를 걸러내십시오.
주니어 여러분, 밤새워 모델 아키텍처 튜닝할 시간에 로그 데이터에 action_prob(추천 확률)이 남고 있는지부터 확인하세요.
그게 없으면 IPS고 뭐고 아무것도 못 합니다. 데이터 엔지니어링 없는 AI는 허상입니다.
오늘도 삽질하는 여러분을 위해, 제가 작성한 SNIPS 파이썬 코드 스니펫은 슬랙에 남겨두겠습니다.
제발 이번 배포 때는 롤백하는 일이 없기를 바랍니다.

![[브루킹스 연구소] 50개국 현장 조사: AI가 인간의 뇌를 '퇴화'시킨다는 결정적 증거](/_next/image?url=https%3A%2F%2Fstorage.googleapis.com%2Fpoooling-blog%2Fblog-images%2F2026%2F02%2F02%2F2620_b8418316.png&w=3840&q=75)
